Packet Tracing in BIG-IP AFM
New in the v13 release of the BIG-IP Advanced Firewall Manager is the capability to insert a packet trace into the internal flow so you can analyze what component within the system is allowing or blocking packets based on your configuration of features and rule sets. If you recall from our Lightboard Lesson on the BIG-IP Life of a Packet, the packet flow diagram looks like this: The packet tracing is inserted at L3 immediately prior to the Global IP intelligence. Because it is after the L2 section, this means that a) we cannot capture in tcpdump so we can’t see them in flight and b) no physical layer details will matter as it relates to testing. That said, it’s incredibly useful for what is and is not allowing your packets through. You can insert tcp, udp, sctp, and icmp packets, with a limited set of (appropriate to each protocol) attributes for each. To get to the packet trace utility in the GUI, navigate to Network->Network Security->Packet Tester as show below. Note: In v13.1 this feature has been moved to Security -> Debug -> Packet Tester. This will launch the packet testing tool as shown here: Note with this tcp selection, in addition to setting the flags, you can configure the source and destination ip/port, source vlan, and trace options as it relates to policy and logging. An example packet trace shows the output of the trace after it completes: You’ll notice here that IP Intelligence and DoS have no beef with the packet, but there is no virtual match so the default action at the end of the path is to reject. Note that you can also use the packet trace utility in tmsh. The command is tmsh show net packet-tester security and results in an output like below. tmsh show net packet-tester security protocol tcp syn src-addr 192.168.101.2 src-port 21233 dst-addr 192.168.101.55 dst-port 8080 src-vlan external ************************* Packet Tester Data: ************************* Packet SrcIP/Port:192.168.101.2/21233 Src Vlan external Packet DstIP/Port:192.168.101.55/8080 Packet Protocol: tcp Packet Trace Option: Check Staged:Disable, Trigger Log:Disable Stage:Device-IP Intelligence Result: Default Stage:Device-DoS Result: Default Stage:Device-Access Control Result: Drop Stage:Route Domain-IP Intelligence (unset) Result: Default Stage:Route Domain-Access Control (unset) Result: Drop Stage:Listener-IP Intelligence (No Listener) Result: Default Stage:Listener-DoS (No Listener) Result: Default Stage:Listener-Access Control (No Listener) Result: Drop Stage:Device Default Result: Drop Final Result Packet SrcIP/Port:192.168.101.2/21233 Src Vlan external Packet DstIP/Port:192.168.101.55/8080 Packet Protocol: tcp Packet Trace Option: Check Staged:Disable, Trigger Log:Disable Stage:Device-Access Control Policy Name: unset Rule Name: unset Stage:Route Domain-Access Control Route Domain name: unset Policy Name: unset Rule Name: unset Stage:Listener-Access Control Listener name: unset Policy Name: unset Rule Name: unset Default Rule : No Device Default Rule Final Action : Drop Total records returned: 1 And because of tmsh, you can easily script packet generation with bash or even a tmsh script if you’re feeling the Tcl love. Current Limitations Only one packet can be inserted at a time, so even a scripted experience via tmsh will result in very low packets per second, which isn’t likely to really impact DoS for valid tests. Only valid headers are allowed, so a large part of typical red team attack vectors are not covered. No tcpdump visibility. No hardware paths. Basic visibility tools like the packet tester are great additions to the BIG-IP AFM. Whether it’s for testing new rules, validating existing ones, or simply throwing a bone over the fence to your operational security team to know where in your configuration an isolated action is being trapped, the v13 AFM packet tester has you covered!Getting In Shape For Summer With BIG-IP Per App Virtual Edition
What happens when you cross a developer with a fitness instructor? I can't think of a punch line that won't make you hate me. But there's really no joke here. Last January F5 released a new version of BIG-IP and something interesting was lurking under the hood of those extra decimal places. Similar to my discussion of BIG-IP's SELinux updatesthese features don't always get noticed but it's important for you to know when making deployment decisions. Grab your protein shake and let's see what changed so far. Dropping The Weight It's a universal fact that Storage Admins eat their young so the last thing you want to do is ask for excessive amounts of disk space. Our developers took that to heart and trimmed down BIG-IP virtual edition to nearly half of it's predecessor. Don't believe me? Here is a side by side of a vanilla BIG-IP EC2 instance in AWS. Here's BIG-IP v12 after a nice holiday season of figgy pudding and candied yams. BIG-IP v13.1.0.2kept their New Year's resolution intact and shed those gigs! How many BIG-IP virtual editions do you really have deployed, is the storage savings worth it? Some of you can count on one hand, some of you need your hands and toes... or your coworkers hands and toes too. If I deploy 5 BIG-IP v13.1.0.2 (or later)instances I'll save roughly 240GB of storage compared to earlier versions. What if I deployed 25? Over 1TB of storage saved but who's deploying 25 BIG-IP's at a time? Hold that thought. Usain Bolt Has Nothing On Our Deploy Time Cloud deployments expect application availability in minutes not hours. F5's developersarealways looking for more ways to speed up time between pressing the deployment button and actually passing traffic between clients and applications. An internal team didexactly that and here are some results of our initial tests in AWS. Mind you these numbers will always fluctuate depending on how complexyour automation is and how complicated you like to make your configurations. Notes on cloud testing in AWS: Region: Canada Size: m4.xlarge - 4vcpu/16GB RAM Disk: io1/gp2 Image Size: Good 41G And from what I've seen, these numbers are only getting better. We have a faster deploymet times to processing traffic after initial deployment. Now what? Hold thatthought too. Per App VE - Where The Work Pays Off Public or private cloud, administrators still deploy BIG-IP virtual edition similar to how they deploy BIG-IP hardware. A monolithic device providing reliable application delivery controller and security services supporting hundreds or thousands of applications. This is still a popular method to install BIG-IP in traditional or hybrid data centers. Developers can still programmatically configure monolithic BIG-IP virtual instances; application services spin up and down while updating nodes and configurations to BIG-IP via our REST interface. However you'll always have applications who may not have access to the "corporate" BIG-IP infrastructure or an application owner may need a unique instance to test a CI/CD process and they're segregated away productioninfrastructure. Or your teams just like their own application sandboxes. Enter BIG-IP Per App Virtual Edition (VE). BIG-IP Per App VE is a bandwidth and CPU licensed offering that createsa reduced cost solution designed to provide Local Traffic Manager (LTM) and Web Application Firewall (WAF) features programmatically on a per-app need. Combined with BIG-IQ as a full management solution for orchestration management or just using the BIG-IQ License Manager (free) you can deploy BIG-IP wherever developers and application teams need. BIG-IQ is NOT needed to purchase BIG-IP Per App VE but it makes licensing a lot of deviceseasier. What does the license provide and how do you provision? I'm glad you asked. The BIG-IP Per App VE License: 1 virtual IP address 3 virtual servers or 1 (a combination of virtual address and a listening port) 25 Mbps or 200 Mbps throughput (license dependent) LTM or LTM with Advanced WAF 1 Interface BIG-IP Per App VE Instance Requirements Minimum Maximum vCPU 2 4 Memory 4 16 Disk 40 82 Remember you were holding two thoughts? The post-diet VE image available in v13.1.0.2 or later and the improved boot times? Suddenly this should start coming together for you. You can now deploy a realistically sized full featured security and ADC solution whodeploys and processes traffic when your application needs it to and costs a lot less than the traditional "monolithic BIG-IP". Developers can now get work with BIG-IP LTM and Advanced WAF services where they need them insted of being forced to subscribe to the stricter management that come with larger consolidated deployments. Where are we going? The BIG-IP Per App VE is that first step to providing a more robustsolution into continuous delivery/integration platforms and puts security and adc features closer to the developer and applicaiton owners. It's hard to require developers to adopt a security position when traditional infrastructure createroadblocks (ITIL, I'm looking at you). You'll still need those restricted systems for mission critical applicaitons where downtime breaks SLA's and contractural agreements. For all of those high priority applications BIG-IP Per App VE is your answer. F5 is busily working on building on the flexibility of the Per App VE license into emerging products to make deployments and scalability a piece of cake. So I'll ask you to again... hold that thought. ; )AFM DoS Enhancements in BIG-IP v13
Following up on our previous article AFM Enhancements In BIG-IP v13, we'll narrow our discussion for this article to Denial-Of-Service (DoS) updates in v13. Architectural changes in BIG-IP's user interfaces now allows increased flexibility and easier DoS management. These and other changes in to AFM's DoS functionality should make your administrative tasks easier to complete and keep the proverbial firewall migraines to manageable pounding. Let's now journey through the magical world of BIG-IP v13 AFM. Angular For The Win Prior to BIG-IP version 13, viewing your DoS policy and actually managing your DoS policy was a segregated effort requiring separate "pages" to complete basic management tasks of a lot of DoS vectors. BIG-IP v13 retooled the management GUI using Angular framework which allows a dynamic interface so you can edit and view the vector lists at the same time. This is massively helpful when setting thresholds and you need to reference other polices simultaneously. There are now two simplified methods to edit DoS vectors: Individual: A pullout dialogue opens to the right of the selected vector as shown above Bulk Edit: Apply changes to one or more vectors, select the checkbox for each one and click on of the following: Enable AutoThreshold Disable AutoThreshold Enforce Don't Enforce Disable Vector States have 3 possible options: Enforced: Detection and rate limiting are active Not Enforced: Statistics are collected, detection is disabled, rate limiting is disabled Disabled: Statistics are not collected, detection is disabled, rate limiting is disabled Auto Threshold Status have 4 states; it's helpful to understand how these states when switching between static and automated thresholds. Enabled: Device will track historic traffic levels for the vector and set detection and rate limit levels automatically, factoring in the auto threshold sensitivity Disabled: Device uses static detection and rate limit levels for the vector if enabled but detect and rate limit values will be default or user specified static values Allowed: The vector is disabled, but if enabled will use Auto Threshold Not Allowed: The vector does not support Auto Threshold whether enabled or disabled Note: The user interface will set a vector to enforced if you enable/disable Auto Threshold. Updated DoS Overview page Thanks again to the Agular-based user interface improvements, the DoS Overview allows a configuration/edit dynamic view. A user can select a DoS profile and virtual server or select virtual server directly from the filter settings and then view and edit the DoS policies applied to that virtual server (soooo niiiiice). Administrators can filter the displayed vectors by attack status: Show All: Displays all enabled vectors Yellow Triangle (arrow to left): Detected display all vectors that have detected attacks Red Hex (Dropped): Displays all vectors that have rate limited attacks and an attack ID. Red Hex (None): Displays all vectors that have rate limited attacks but are in a transient state with no attack ID. This transient state quickly resolves to a dropped status with attack ID. None: Shows all vectors for which no attacks have ben detected. This is helpful for identifying vectors that should have lower, more aggressive detection thresholds. Virtual Server (Dos Protected) Dos Attack - The user can review all attacks and drill down accordingly Device DoS - The user can review config and status of the global Dos vectors Netflow - User can review all vectors associated with a Netflow collector used fro out-of-band DoS detection. Auto Thresholds added to Dos Profiles Prior to BIG-IP v13, Auto Thresholds were available only at the global device configuration level. Now you may configure Auto Threshold at a profile level and apply them to virtual servers allowing for greater granular control for unique applications. DoS profiles vectors are disabled by default Auto Threshold is enabled by default. If you enable a vector which allows Auto Threshold, it will use it until you change to static. Dynamic signatures are disabled Auto Threshold sensitivity is configured per DoS profile. Once update is clicked, the vector will no longer use it's static values. The UI will still report values from the previous static config. If manual config is selected the configured values are displayed. Below we enable Auto Threshold for the ip-frag-flood DoS vector via TMSH. (tmos)# modify security dos profile dos-sausage dos-network modify { dos-sausage { network-attack-vector modify { ip-frag-flood { auto-threshold enabled } } } } The completed vector modification can be also be viewed via TMSH: (tmos)# list security dos profile dos-sausage security dos profile dos-sausage { app-service none description none dos-network { dos-sausage { dynamic-signatures { detection enabled mitigation low } network-attack-vector { ip-frag-flood { allow-advertisement disabled auto-blacklisting disabled auto-threshold enabled bad-actor disabled blacklist-category denial_of_service blacklist-detection-seconds 60 blacklist-duration 14400 ceiling infinite enforce enabled floor 100 per-source-ip-detection-pps infinite per-source-ip-limit-pps infinite simulate-auto-threshold disabled } ... Other DoS Changes To Make Life A Bit Simpler And Sweeter Bad Actor Detection & Rate Limiting Bad actor detection and rate limiting thresholds can now be automated. Prior to v13, volumetric DoS vectors supported bad actor detection with optional auto blacklisting but enforcement thresholds had to be set manually. Now thresholds can be set to automatic. Auto Blacklist now available for single endpoint flood:Version 12 allowed Single Endpoint Sweep vectors to use Auto Blacklisting. V13 adds Single Endpoint Flood to the Auto Blacklist cool kids club. Eviction Policies can now be viewed under Dos Protection ICMP Type/Code invalid combinations are now tracked in the updated BAD ICMP Dos Vector Syn Cookies are integrated with other DoS defense features via the new TCP Half Open Dos vector It's a lot of random stuff to digest I know, but this is just some of the many changes to AFM's Dos functionality, the rest living under the hood and more geared towards making your life easier without you knowing it (or wanting to know about it). The changes illustrated above are a long time coming and welcome addition to the BIG-IP security stack. I encourage you to check them out either via evaluation or your Developer/Lab edition of BIG-IP. A big shoutout to James in our NPI team for helping out with documenting these and other changes to our AFM feature stack. Let us know what you think and if you have any questions feel free to drop us a line. Happy IT'ing.AFM Enhancements in BIG-IP v13
As you've noticed, DevCentral is covering some new features of F5 BIG-IP version 13 this month. Today we'll review some core updates to Advanced Firewall Manager (AFM). Next week we'll dive deeper into AFM DoS service improvements. In BIG-IP v13, AFM looks to improve performance, expand configuration flexibility, and make your administrative life a bit easier; something we all need. Per-Policy Compilation: YES! Prior to v13, policy compiling could be a lengthy process. Compiling monolithic polices with large rule lists/rules resulted in high memory use and long waits (depending on the depth of the policy). BIG-IP v13 introduces a per-policy compilation variable designed to alleviate these symptoms. (tmos)# show security firewall container-stat field-fmt security firewall security { activation-time-fmt Mar 17 2017 09:44:46-0700 compile-duration-fmt 0:0:0 container-size 14.3K context-name vs_kielbasa context-type virtual ovrlpck-duration-fmt 0:0:0 per-policy-compilation Yes policy-name afm_policy_a policy-type Staged process-mem 54.3M rule-count 5 slot-id 0 } This enables the Packet Correlation Classification Daemon (pccd) to detect changes, and recompile only changed policies. Unchanged policies will have results copied from the compiled policy objects. The above TMSH command displays the enabled variable but it can be turned off for various reasons if needed (talk to F5 support prior to screwing around with db variables). Pccd received several other updates, honorable mentions below: Increased memory usage statistic accuracy - useful for diagnostics Compiler Speed Improvements Improvements to HA handling - Active/Standby delays are reduced and stability improvements Rule overlap check improvements now includes unused policies Send To Virtual Server Enhancements Prior to v13, users were limited to source/destination address and port when selecting virtual servers in rules. Now any attribute used to match firewall rules can be used to select the virtual server. In the above image we are selecting GeoIP-based traffic and sending them to HADES, our honeypot virtual server. We can add additional conditions including: VS & Policy based on Geolocation VS & Policy for non-contiguous port ranges VS & Policy combinations of full 5-tuple (and VLAN/Geo/FQDN) We can expand our use cases with these enhanced conditions and create value add for other BIG-IP modules like AAM/LTM so only specific data classes proceed on to downstream services; think Geolocation/User based DNS/WAF/TCP options policies. These improvements should allow you to reduce firewall complexities and maybe even remove some of the patchworks implemented to get around the previous versions limitations. As with new features, there are some caveats to be aware of (highlights): Send to Virtual rules are applicable in global and route domain contexts No recursive redirects (no re-redirects) You cannot swap protocols with Send to Virtual Traffic and the virtual server addressing must be in the same family (IPv4/IPv6) Traffic and the virtual server must be in the same route domain To review statistics for traffic handled by a Send to Virtual rule use: tmctl fw_sendtovirtual_stats BIG-IP's AFM's increased flexibility and performance is making firewall administration nearly enjoyable at this point. Not that I'd rather build rule sets over going Skiing, but it's a heck of a lot easier. As we investigate more AFM improvements next week, you'll start to see how big BIG-IP v13 really is. If you haven't downloaded an evaluation copy yet, what are you waiting for? Let us know if you want us to dive deeper on these and other changes. Thanks for reading!
