ICMP (Fragmentation needed) Between Firewall and LTM
We have been working for a while with Fortinet about an issue between the firewall and the LTM (r10600 with tenant 15.1.9.1), this issue is causing a loop with some ICMP packets. The flow goes like this: internet (ISP) --- firewall --- LTM --- customer network (client) So yes, the LTM is in the middle between the client and the firewall So to be much clear, the client is sufing the internet through the LTM up ot the firewall, and then traffic sent to ISP. The issue: When client tries to reach the internet, for some packets, we noticed a packets with fragmentation issue. Packets captured with "ICMP Frag Needed" on the firewall which has been sent to the LTM, for some reason the LTM is sending it back to the firewall, causing a loop. According to F5 the routing table, the next hop for 10.0.0.0/9 is the client, but it does not check the routing table for those kind of packets "ICMP Frag Needed" In F5 we see a lot of "need to frag" ICMP messages: [root@f5-r10600-abc:Active:Standalone] config # tcpdump -i Internet 'icmp[0] = 3' | grep "need to frag" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on Internet, link-type EN10MB (Ethernet), capture size 65535 bytes 14:15:25.497395 IP 72.246.151.107 > 10.76.174.197: ICMP 72.246.151.107 unreachable - need to frag (mtu 1448), length 556 in slot1/tmm0 lis= 14:15:25.497399 IP 72.246.151.107 > 10.76.174.197: ICMP 72.246.151.107 unreachable - need to frag (mtu 1448), length 556 in slot1/tmm0 lis= 14:15:25.498314 IP 72.246.151.171 > 10.51.131.240: ICMP 72.246.151.171 unreachable - need to frag (mtu 1448), length 556 in slot1/tmm0 lis= We are concerned that the F5 is not behaving accordingly to this kind of ICMP traffic. We read some articles about PMTUD while not being sure if this is the issue: https://my.f5.com/manage/s/article/K000138230 https://my.f5.com/manage/s/article/K13948 We tried the TAC support but we have 15.1.9.1 and it is EOS two weeks ago an upgrade will be done but only next month, and I don't this will be solved by an upgrade. Has anyone faced this issue? Thanks
Missing Security section for Network Firewall
Hello, I want to run this lab: https://clouddocs.f5.com/training/community/firewall/html/class1/module1/lab2.html 1. On the BIG-IP UI, navigate to Security > Network Firewall > Rule Lists There is no Security section. BigIP version running is 14.1.5.1 Please let me know what I can do to run a network firewall. Thanks, .userid to ip mapping - F5 APM
I have been wrestling with how I can share user to ip mappings for VPN connections with internal security devices(namely palo alto firewalls). I found a few great suggestions on here regarding leveraging an irule to accomplish this, and while they appeared to work, adding DTLS broke most of the examples provided. reference: https://devcentral.f5.com/questions/userid-to-leasepool-ip-mapping So I spent some time attempting to figure out how I could accomplish this with DTLS enabled and this is what I came up with: when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable set hsl [HSL::open -proto UDP -pool hsl_pa-uid_pool] } when HTTP_REQUEST { if { [HTTP::uri] starts_with "/vdesk/timeoutagent-i.php" } { set vpnip [ACCESS::session data get "session.assigned.clientip"] log local0. "timeout beacon received" if { $vpnip != "" }{ set user [ACCESS::session data get "session.logon.last.username"] If pa-vpn table entry for ip does not equal the current user we need to update the firewall if { [table lookup -notouch "pa-vpn:$vpnip"] != $user } { HSL::send $hsl "<190>F5_PA_UID_Event uid:$user vpnip:$vpnip\n" log local0. "periodic: F5_PA_UID_Event uid:$user vpnip:$vpnip" table set "pa-vpn:$vpnip" "$user" "indef" 600 } } } } when ACCESS_SESSION_CLOSED { set hsl [HSL::open -proto UDP -pool hsl_pa-uid_pool] set vpnip [ACCESS::session data get "session.assigned.clientip"] if { $vpnip != "" }{ set user [ACCESS::session data get "session.logon.last.username"] HSL::send $hsl "<190>F5_PA_LOGOUT_Event uid:$user vpnip:$vpnip\n" log local0. "periodic: F5_PA_LOGOUT_Event uid:$user vpnip:$vpnip" } } My only concern with this implementation is performance impact. The /vdesk/timeoutagent-i.php happens every 10 seconds or so, which means the set vpnip [ACCESS::session data get "session.assigned.clientip"] and [table lookup -notouch "pa-vpn:$vpnip"] will also occur. Is my concern warranted? Is there possibly a better implementation out there? Any possible alleys that I might have missed?
Restricting traffic between Vlans.
We have an F5 servicing our DMZ. It hosts the external IPs and acts a router for the DMZ servers. +--- [ VLAN_2110 ] [ Internet ] ---- [ F/W ] ---- [ F5 ] --+ +--- [ VLAN_2310 ] Recently a new requirement has emerged to keep one group of Vlans from talking to another group. A for instance would be that VLAN_2110 and VLAN_2310 in the above sketch would not be allowed to talk to each other. Can the F5 do this?
Can someone take a look and make sure I understand this right about reverse proxy
Preface: Yes I know not a whole lot but I'm trying. If someone could just take a look at this and maybe it will help me find what piece I am missing. We have an internal server that needs to be accessed on the outside, but they don't want it actually touching the internet so we run it through the BIG-IP F5 LTM. The internal IIS has an internal IP and an external IP assigned. The DNS entry is bound to the External IP address. A lot of what I setup has been copied from a currently working site that utilizes this exact same process. From my understanding the connection "route" is as follows: Internet-->ExtIP-->F5virtualIP-->IntIP The External IP gets natted on the firewall to the F5 internal IP of the virtual server, and then the F5 virtual server is linked to the actual internal server IP. We have access rules in place to allow public access to the external IP as well as the F5 IP. There are NAT rules in place that *should* point anyone going to the external IP towards the F5 address, and then through that to the internal server. There's an F5 rule in place that redirects from http to https as well. Internally, on my work PC, I can navigate to the site via it's FQDN. Externally though, I get a Not Secure Site message(we haven't gotten the cert in place yet so that is expected), but then after a while of trying to load, we receive an ERR_CONNECTION_RESET page and it can't load. I feel like there is something I am missing but I just can't think of what it is. If anyone has any ideas I will be eternally grateful. Thank you in advance.Orchestrated Infrastructure Security - Protocol Inspection with AFM
The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latest here. Introduction This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM. It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series Implementing SSL Orchestrator here. This article focuses on configuring Protocol Inspection (IPS) with AFM deployed as a Layer 2 solution. It covers the configuration of Protocol Inspection on an F5 BIG-IP running version 16.0.0. Configuration of BIG-IP deployed as AFM can be downloaded from here from GitLab. Please forgive me for using SSL and TLS interchangeably in this article. This article is divided into the following high level sections: Protocol Inspection (IPS) with AFM Network Configuration Create an AFM Protocol Inspection Policy Attach Virtual Servers to an AFM Protocol Inspection Policy Protocol Inspection (IPS) with AFM: Network Configuration The BIG-IP will be deployed with VLAN Groups. This combines 2 interfaces to act as an L2 bridge where data flows into one interface and is passed out the other interface. From the F5 Configuration Utility go to Network > VLANs. Click Create on the right. Give it a name, ingress1 in this example. Set the Interface to 5.0. Set Tagging to Untagged then click Add. Interface 5.0 (untagged) should be visible like in the image below. Click Repeat at the bottom to create another VLAN. Note: In this example interface 5.0 will receive decrypted traffic from sslo1. Give it a name, egress1 in this example. Set the Interface to 6.0. Set Tagging to Untagged then click Add. Interface 6.0 (untagged) should be visible like in the image below. Click Finished when done. Note: In this example interface 6.0 will receive decrypted traffic from sslo1. Note: This guide assumes you are setting up a redundant pair of SSL Orchestrators. Therefore, you should repeat these steps to configure VLANs for the two interfaces connected to sslo2. These VLANs should be named in a way that you can differentiate them from the others. Example: ingress2 and egress2 It should look something like this when done: Note: In this example Interface 3.0 and 4.0 are physically connected to sslo2. Click VLAN Groups then Create on the right. Give it a name, vlg1 in this example. Move ingress1 and egress1 from Available to Members. Set the Transparency Mode to Transparent. Check the box to Bridge All Traffic then click Finished. Note: This guide assumes you are setting up a redundant pair of SSL Orchestrators. Therefore, you should repeat these steps to configure a VLAN Group for the two interfaces connected to sslo2. This VLAN Group should be named in a way that you can differentiate it from the other, example: vlg1 and vlg2. It should look like the image below: For full Layer 2 transparency the following CLI option needs to be enabled: (tmos)# modify sys db connection.vgl2transparent value enable Create an AFM Protocol Inspection Policy You can skip this step if you already have an AFM Protocol Inspection policy created and attached to one or more virtual servers. If not, we’ll cover it briefly. In this example we configured Protocol Inspection with Signatures and Compliance enabled. From Security select Protocol Security > Inspection Profiles > Add > New. Give it a name, IPS in this example. For Services, select the Protocol(s) you want to inspect, HTTP in this example. Optionally check the box to enable automatic updates and click Commit Changes to System. Attach Virtual Servers to an AFM Protocol Inspection Policy Attach the Protocol Inspection Profile to the Virtual Server(s) you wish to protect. From Local Traffic select Virtual Servers. Click the name of the Virtual Server you want to apply the profile to, 10.4.11.52 in this example. Click Security > Policies. Set the Protocol Inspection Profile to Enabled, then select the Profile created previously, IPS in this example. Click Update when done. Repeat this process to attach the IPS Profile to the remaining Virtual Servers. Summary In this article you learned how to configure BIG-IP in layer 2 transparency mode using VLAN groups. We also covered how to create an AFM Protocol Inspection policy and attach it to your Virtual Servers. Next Steps Click Next to proceed to the next article in the series.
Defending against the Low-Orbit-Ion-Cannon (LOIC)
It’s been a busy week for the security analysts at F5. The SOPA bill has been getting its technical teeth pulled out by the likes of Dan Kaminsky during congressional hearings but passions around the social implications of the bill are running high. On Wednesday, January 18 th , federal agencies from the US and New Zealand moved in on media-distribution site MegaUpload.com, citing unauthorized media distribution as their charge. This was interpreted as the modern-day sinking of the USS Merrimack in this skirmish between SOPA-backers and their opponents. The hactivist group Anonymous, always ready for fight, have rallied around the MegaUpload.com seizures and launched distributed denial-of-service (DDoS) attacks against the United States Department of Justice (www.justice.gov) and Warner Brother’s Universal Music group (www.universalmusic.com). Both sites were down on Wednesday and Thursday. In an insightful tweet, cryptographer Matt Blaze (author of my pseudo random number generator), pointed out the irony of the situation: For the attack distribution, members of Anonymous modified the JavaScript version of their tool, dubbed the Low-Orbit-Ion-Cannon (LOIC), so that not only would it attack the Justice Department, it would do so if a user simply browsed to a page containing the JavaScript itself . This particular version of the LOIC only performs HTTP floods (unlike the Windows client which also does SYN floods and UDP floods). As you can see from this JavaScript version of the LOIC, there is a message that the individual attacker can send in as part of the payload of their attack: in this case, the default message is “Somos legión!” (“We are legion!”). The message is appended to the URI as “msg=Somos%20legión!"” Security vendors can customized their defense solutions to watch for this string and block those connections (or even black-list the originating IPs if they so choose – the LOIC has never bothered to cloak its users). Scanning a URI for specific strings is something that is particularly easy to do with F5’s iRules. With just a few minutes spent on the DevCentral site’s tutorial section, you can create a simple iRule that looks for the default message and then drops the associated connection. However, since Anonymous (or some other group or subgroup) may change the message in the future, the iRule can be enhanced to reference a string class to which one can add more strings should the message change. In the iRule below, we’ve added the original LOIC message that was used during the Wikileaks attacks of 2010, “U dun goofed.” First, create a string class and add additional payload strings as you see it (replaces spaces with %20). ltm data-group anonmsgs { records { Somos%20legi { } U%20dun%20goofed { } } type string } Then create this iRule that references the string class. ltm rule loic_defense_class { when HTTP_REQUEST { if { [class match [HTTP::uri] contains anonmsgs] } { log local0. "2012 attack from [IP::client_addr]:[TCP::client_port]" drop } } } While this particular iRule is written and tested specifically against the JavaScript version of the LOIC, the technique is applicable against any attack that includes a static payload. If your site is being attacked by any such tool using a recognizable payload simply deploy this iRule or a similar one on the BIG-IPs in front of your servers. If you are the victim of a more sophisticated DDoS campaign, perhaps one using synfloods, connfloods and UDP floods there is an existing DevCentral article that details how to tune your BIG-IP for the best defense. The Windows version of LOIC, for example, launches synfloods and UDP floods in addition to its HTTP floods. Happily, the SynCheck feature will kick in automatically on the BIG-IP, but temporarily blocking UDP at the virtual level is something that may require manual configuration if UDP is already being allowed by the application (an atypical configuration for most enterprise and data center applications). Debate around SOPA, PIPA and the new OPEN bill is still ongoing. Though some view the current controversy as a digital media vs. internet freedom, a colleague of mine suggested a more nuanced analysis: “It’s not about internet freedom vs. media piracy, it’s about the shifting terrain of intellectual property rights, and the business models of the major industries involved being put at risk by changing consumer consumption patterns. “
