The BIG-IP Application Security Manager Part 1: What is the ASM?
tl;dr - BIG-IP Application Security Manager (ASM) is a layer 7 web application firewall (WAF) available on F5's BIG-IP platforms. Introduction This article series was written a while back, but we are re-introducing it as a part of our Security Month on DevCentral. I hope you enjoy all the features of this very powerful module on the BIG-IP! This is the first of a 10-part series on the BIG-IP ASM. This module is a very powerful and effective tool for defending your applications and your peace of mind, but what is it really? And, how do you configure it correctly and efficiently? How can you take advantage of all the features it has to offer? Well, the purpose of this article series is to answer these fundamental questions. So, join me as we dive into this really cool technology called the BIG-IP ASM! The Basics The BIG-IP ASM is a Layer 7 ICSA-certified Web Application Firewall (WAF) that provides application security in traditional, virtual, and private cloud environments. It is built on TMOS...the universal product platform shared by all F5 BIG-IP products. It can run on any of the F5 Application Delivery Platforms...BIG-IP Virtual Edition, BIG-IP 2000 -> 11050, and all the VIPRION blades. It protects your applications from a myriad of network attacks including the OWASP Top 10 most critical web application security risks It is able to adapt to constantly-changing applications in very dynamic network environments It can run standalone or integrated with other modules like BIG-IP LTM, BIG-IP DNS, BIG-IP APM, etc Why A Layer 7 Firewall? Traditional network firewalls (Layer 3-4) do a great job preventing outsiders from accessing internal networks. But, these firewalls offer little to no support in the protection of application layer traffic. As David Holmes points out in his article series on F5 firewalls, threat vectors today are being introduced at all layers of the network. For example, the Slowloris and HTTP Flood attacks are Layer 7 attacks...a traditional network firewall would never stop these attacks. But, nonetheless, your application would still go down if/when it gets hit by one of these. So, it's important to defend your network with more than just a traditional Layer 3-4 firewall. That's where the ASM comes in... Some Key Features The ASM comes pre-loaded with over 2,200 attack signatures. These signatures form the foundation for the intelligence used to allow or block network traffic. If these 2,200+ signatures don't quite do the job for you, never fear...you can also build your own user-defined signatures. And, as we all know, network threats are always changing so the ASM is configured to download updated attack signatures on a regular basis. Also, the ASM offers several different policy building features. Policy building can be difficult and time consuming, especially for sites that have a large number of pages. For example, DevCentral has over 55,000 pages...who wants to hand-write the policy for that?!? No one has that kind of time. Instead, you can let the system automatically build your policy based on what it learns from your application traffic, you can manually build a policy based on what you know about your traffic, or you can use external security scanning tools (WhiteHat Sentinel, QualysGuard, IBM AppScan, Cenzic Hailstorm, etc) to build your policy. In addition, the ASM comes configured with pre-built policies for several popular applications (SharePoint, Exchange, Oracle Portal, Oracle Application, Lotus Domino, etc). Did you know? The BIG-IP ASM was the first WAF to integrate with a scanner. WhiteHat approached all the WAFs and asked about the concept of building a security policy around known vulnerabilities in the apps. All the other WAFs said "no"...F5 said "of course!" and thus began the first WAF-scanner integration. The ASM also utilizes Geolocation and IP address intelligence to allow for more sophisticated and targeted defense measures. You can allow/block users from specific locations around the world, and you can block IP addresses that have built a bad reputation on other sites around the Internet. If they were doing bad things on some other site, why let them access yours? The ASM is also built for Payment Card Industry Data Security Standard (PCI DSS) compliance. In fact, you can generate a real-time PCI compliance report at the click of a button! The ASM also comes loaded with the DataGuard feature that automatically blocks sensitive data (Credit Card numbers, SSN, etc) from being displayed in a browser. In addition to the PCI reports, you can generate on-demand charts and graphs that show just about every detail of traffic statistics that you need. The following screenshot is a representative sample of some real traffic that I pulled off a site that uses the ASM. Pretty powerful stuff! I could go on for days here...and I know you probably want me to, but I'll wrap it up for this first article. I hope you can see the value of the ASM both as a technical solution in the defense of your network and also a critical asset in the long-term strategic vision of your company. So, if you already have an ASM and want to know more about it or if you don't have one yet and want to see what you're missing, come on back for the next article where I will talk about the cool features of policy building. What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Data Guard Username and Session Awareness Tracking Event LoggingOrchestrated 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.
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?
