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 latesthere. 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. “F5 Firewall Like No Other - Ruling the Application
“Vive la différence!” I’ve been here in Europe at our Agility Conference in Monte Carlo (the theme: GO BIG) talking with customers and partners about what makes the F5 firewall different. F5’s European Conference at Monte Carlo Bay, Monaco Old School Excel As I made my presentation to a packed room of customers, I noticed that one story really got them nudging each other. We had an early customer of the Advanced Firewall Manager (AFM) module. This customer used to organize their firewall rules in an old-school way – with an Excel spreadsheet. The spreadsheet was 300 pages long! This is how that happens: Imagine a new firewall operator. A bizdev team builds a new application and asks him to open a hole in the firewall for it. He checks, and sees that there is already a working rule for an existing marketing application, so he doesn’t create a new one. Six months later, the bizdev application is retired, and he is asked to remove the firewall rule. By now he has forgotten that he didn’t create a rule for this application and he removes the one that is there. This stops traffic to the original marketing application as well. When the marketing team realizes that they have stopped receiving traffic, they come and yet at him. He quickly learns that it is “safe” to create a firewall rule but “unsafe” to remove one. This is the opposite of good security posture but it is a scenario that many, many, many organizations face today. This explains why so many in the audience were nodding and nudging each other. Ruling the Application The reason that F5’s firewall is different is because we build the application firewall rule into the application itself. It is part of the definition of the application, right there next to the http options, the pool definition and the tcp profile parameters. ltm virtual bizdev1 { ip-protocol tcp pool bizdev_pool profiles { http tcp } fw-rules { reject1020 { action reject log yes source { addresses { 10.128.20.0/24 } } } allow_http { action accept destination { ports { http } } ip-protocol tcp } } } When the application is retired, the associated firewall rules are automatically retired with it. This has three benefits. No accretion of stale rules. While the initial management overhead may be the same for defining the network, over time the active set of firewall rules will remain identical to the active set of applications. Performance. This automatic pruning process will have performance benefits because, as firewall operators should know, the smaller the rule set, the faster the firewall. Application Mobility. As applications moves between datacenters and/or clouds, the firewall rules move with them. This makes application migration easier and less error prone. Changing the Firewall World That’s just one way that F5 is changing the firewall world. There are other benefits associated with this “application-centric firewall policy management." If you want to see them all in one place, check out the white paper: “Replacing Abstract Zones with Real Application Security Policy.”
Forward UDP traffic to different Pool using iRule
Hello, I made an iRule to forward traffic to other F5 Pool if source is Different , seems it does not work. If source is other than Defined in iRule expectation is traffic should be processed by default pool. But when I see from F5 , it always hitting to the default pool even traffic is sourcing from defined sources from iRule. What could be the issue from iRule ? when CLIENT_ACCEPTED { #Firewall set FW1 "10.7.10.10" #Firewall set FW2 "10.7.11.10" #Firewall set FW3 "10.7.12.10" #Firewall set FW4 "10.7.13.10" switch [IP::client_addr] { $FW1 { if { [LB::status pool ASA_Pool member 10.8.11.23 1514] eq "up" or [LB::status pool ASA_Pool member 10.8.11.24 1514] eq "up" } { pool ASA_Pool } else { pool Default_Pool } } $FW2 { if { [LB::status pool ASA_Pool member 10.8.11.23 1514] eq "up" or [LB::status pool ASA_Pool member 10.8.11.24 1514] eq "up" } { pool ASA_Pool } else { pool Default_Pool } } $FW3 { if { [LB::status pool ASA_Pool member 10.8.11.23 1514] eq "up" or [LB::status pool ASA_Pool member 10.8.11.24 1514] eq "up" } { pool ASA_Pool } else { pool Default_Pool } } $FW4 { if { [LB::status pool ASA_Pool member 10.8.11.23 1514] eq "up" or [LB::status pool ASA_Pool member 10.8.11.24 1514] eq "up" } { pool ASA_Pool } else { pool Default_Pool } } default { pool Default_Pool } } }
