IP-Intelligence and IP-Shunning
Dear Reader, With this article we have arrived at the “last” layer of protection, which is actually the first one from the hud-chain point of view: Blocking on the IP layer. The idea is rather simple: When you know that an IP address (or multiple IP addresses) is doing bad things, you block them as early as possible at the speed of line. IP-Intelligence Policy You can create IP-Intelligence (IPI) policies, which describe what should happen (Drop or Allow) with IPs (source or destination) belonging to a specific category. BIG-IP already has a bunch of pre-defined categories, but you can also add your own. Figure 1: Example on an IPI-Policy Important: A great benefit of using this, is that the “Drop” action is done on the FPGA level, which means in hardware. Basically, as soon as a packet hits the BIG-IP. But this is only possible when you set the logging to “No” (no logging, only dropping) or “Limited”. “Limited” means that some packets get leaked into software (CPU) for dropping them there and then they can be logged here as well. By default, every 256th packet goes into software when logging is set to “limited”. This is controlled by the sys db variable “dos.blleaklimit”. You can modify it to values like 1, 3, 7, 15, 31, 63, 127, 255, 511, 1023, and so on. The default value is 255. When you set the logging to “Yes”, then all packets will get logged, because the action (Drop) is done always in software. My recommendation is to use “Limited” logging to enable FPGA support for this feature. This is also what we call “shunning” when we drop on FPGA level. You can create multiple policies and assign them to different contexts: VS/PO or Route Domains to have individual configurations for your protected objects (services, networks, etc.) and you can also assign an IPI policy to the global level of BIG-IP, which means this will be executed first and for the whole box. Even when you want to block via IPI only on VS/PO level, my recommendation is to have a global IPI policy attached. It can be empty. Figure 2: Global Policy assignment Figure 3: Per VS/PO Policy assignment Figure 4: Per Route Domain Policy assignment Order of Mitigation Mitigation using the hardware (FPGA) is always done first. Next, traffic goes into software and can be dropped here as well. For IPI the following order takes place. Note that IPI mitigation done on Route Domain level is always in software. Figure 5: Mitigation Order How to get information about “bad” IPs? There are multiple options available. One is to use an external service (3 rd party), which does the categorization of IPs based on their reputation. If you have the IP Intelligence feature licensed, the information is being updated every 5 minutes. Another one is to use BIG-IP to automatically identify “bad actors” via DoS vectors. In my article Increasing accuracy using Bad Actor and Attacked Destination detection, I described how that works and for what it is useful for. But when BIG-IP identifies “bad actors” and this source IP(s) are behaving aggressive for a configurable amount of time, then it may make sense to drop everything coming from this IP(s) for a specific time interval. Figure 6: Bad Actor Detection In this example, the IP(s) which are identified as bad actors and behaving “bad” for 30 seconds get added to the category “denial_of_service” for 600 seconds. Once the “duration time” is over, they get released from the category and the process starts from the beginning, if they are still “bad”. Drop Attacked Destination Another use case to carefully consider is to drop based on attacked destination. Here you can drop all traffic going to a specific destination which is under attack. True, you stop the attack hitting the target, but you also drop all legitimate traffic going there, which would be a great success for the attacker. But, of course, if for whatever reason the attack would potential bring the BIG-IP to its knees this is an option you can choose. You would loose the destination that is under brutal attack but at least you safe all other services on the BIG-IP from being impacted. Figure 7: Attacked Destination Detection Use your up-stream router Think of the following scenario: An attack is about to saturate your Internet-pipe. You mitigate the bad actors on BIG-IP, but your pipe is still full. Why not “signal” the information of bad actors to your upstream router and drop the attackers already there, even before your pipe gets saturated? This is what you can do with using Remote Triggered Black Hole routing (RTBH) or Flowspec. By enabling “Allow External Advertisement” within your “Bad Actor Detection” or “Attacked Destination Detection” you can enable that functionality. Figure 8: External Advertisement I will cover the topic on how to use the Blacklist Publisher to “signal” bad actors including an action (Drop, Rate-limit, DSCP) to an upstream router via RTBH or Flowspec in a dedicated article. I will also explain in the same article how to use the “Scrubbing profile” to execute an action (redirect, rate-limit, DSCP, drop) on networks, PO/VS when these objects reach a certain bandwidth utilization. More options to add bad actors into categories Returning to how you can add IP(s) into categories. In addition to the already discussed options of using F5 subscription service and DoS vectors you can also add manually IPs. You may have your own sources and want to add this information into the categories. Here you have multiple options again. GUI On the Blacklist Categories page, you can manually add/delete IPs for a selected category. Figure 9: Add IP/Geo/FQDN to categories Feed List You can create your own Feed List using HTTP(s) or FTP to regularly download a file and update your categories. Figure 10: External Feed List Don´t forget to then enable your Feed List within your IPI-Policy! Figure 11: Enable Feed Lists TMSH Using tmsh you can also add IPs to categories. Here is an example: $ tmsh run security ip-intelligence category name denial_of_service ip-ttl add { 123.123.123.123,300 } Rest-API Another way is to use Rest-API. Here is an example: $ curl -sk -u sVen:mySecrectPW -H "Content-Type: application/json" -X POST -d '{"command":"run","utilCmdArgs":"name denial_of_service ip-ttl add {123.123.123.123,300}"}' https://mgmnt-address-big-ip/mgmt/tm/security/ip-intelligence/category/ | python -m json.tool Whitelist IPs for IPI/shunning If you want to whitelist IP(s) from not being shunned on IPI level, you need to add this IP(s) to the “whitelist” category. Please we aware that this only works when you use an external feed to add the IP(s). Figure 12: Feed List Properties More useful CLI commands To get an idea on hits per category, you can use a “tmctl” command: # tmctl -w 180 ip_intelligence_stat It gives you an overview of hits per context, category and drop list type. Figure 13: Stats for categories Here you can also see that you can not only drop based on IP. You can also use GEO information and FQDN. If you want to verify the status of an IP, you can use this command: # tmsh show security ip-intelligence info address <ip-address> Figure 13: Example of status of a GEOIP Conclusion IPI/shunning is a very effective and hardware driven way of blocking traffic based on IP information. Especially on amplification and reflection attacks it is a very useful because you are mostly able to identify IP addresses causing the high load. Often operators do also block traffic from countries on which they are sure they do not communicate with for specific services. After finishing the explanation of this last (first) mitigation layer, you hopefully have a better understanding on how F5 L3/4/DNS DDoS mitigation works. Hardware (FPGA) support is an essential element of successful blocking high packet rates. These high-performance chips get dynamically programmed via the “smart” component, the software which runs on CPU, and which also needs to be protected. Therefore, you can configure the DoS mitigation mechanism for protecting your services (server, network, …) behind the BIG-IP, but also BIG-IP itself! Figure 14: Multi-layer DDoS mitigation architecture F5 also provides the ability to protect with hardware (FPGA) support in virtualized environments. Since more and more data center go virtual, the requirement of running DDoS mitigation in virtualized environments has increased. But, because FPGA support is needed for this type of DDoS mitigation, since CPU alone is usually not powerful enough, it can present a problem. Together with Intel F5 provides a strong solution. This solution uses SmartNICs (network card with FPGA on board) within your Hypervisor. DHD (DDoS Hybrid Defender) and AFM (Advanced Firewall Manager) can program these FPGAs in basically the same way as it can be done on dedicated Hardware appliances. This again gives you the power needed for DDoS mitigation, plus the flexibility of virtualized environments. If you are interested in learning more about this, I would like to recommend the article of my colleague Ryan Howard: https://devcentral.f5.com/s/articles/Mitigating-40Gbps-DDoS-Attacks-with-the-new-BIG-IP-VE-for-SmartNICs-Solution My next article will focus on logging and reporting DDoS events. Together, my colleague Mohamed Shaath and I created a DDoS Dashboard including DDoS statistics visibility on all vectors based on an ELK stack. We will share in that article how to install and use it. Thank you, Sven Mueller
See what IP Reputation has to say about your firewall traffic
Reputation matters. Imagine a service that scores the behavior of millions of computers on the Internet. Imagine that your aunt’s computer is infected and sending out spam. Or a host in the cloud is compromised and port scanning your neighborhood. The service records that information and then distributes it to threat intelligence teams and security devices all around the world. That service already exists – it’s available as the BrightCloud IP Reputation service from the company Webroot, which is just down the way from my house. I went over there one day and asked them how it worked. Webroot uses honeypots, sensors and endpoints all across the Internet to collect millions of malicious addresses into their reputation database. The reason I was interested is because this is an IP reputation service behind our threat intelligence feed that we deliver to our own customers. We call this reputation subscription IP Intelligence (IPI). The service is delivered every day to each subscribing F5 BIG-IP. The service is maintained in real-time and incremental updates are sent to the subscribers every few minutes. This means that when a new malicious host is detected by Webroot, each subscribing BIG-IP around the world can block it. The reputation of each IP address is stored as a tuple in the database. Each address is accompanied by a field that describes which malicious behaviors the address is exhibiting: Sending spam email (open mail relays) Phishing end users into divulging credentials (phishing proxies) Attack coordination (botnet command and control hosts) Anonymized traffic (TOR exit nodes) Network reconnaissance (known scanners) Customers using the F5 Access Policy Manager (APM) module or the F5 web application firewall (ASM) can configure how those modules use IPI with pretty screens.All other customers can check the reputation of incoming or outgoing traffic by applying this categorization in the Local Traffic Manager (LTM). Check out how simple an IPI iRule is. That particular iRule would drop any incoming connection that had a bad reputation of any kind – but it could be tweaked to allow some types while blocking others. Webroot and F5 recently collaborated on a demonstration tool to show the threat intelligence value of IPI. A firewall administrator can feed a firewall log file into a local copy of the “Threat Intelligence Analyzer” to see the analysis. Here’s what the tool looks like: By the way, keeping security in mind, we figured that administrators would rather download a tool rather than upload their firewall logs somewhere else. Who is attacking my home network? I run what I consider to be a fairly sophisticated router at my house. I use the D-Link DIR-655 Xtreme N Wireless router. Yes it has three antennas, a rudimentary firewall, virtual applications and, of course, it can log to an external syslog server. I collected a few weeks’ worth of firewall logs, applied some greps and seds and fed the log into the IP Threat Analyzer. It categorized just over 33% of the addresses hitting my house as malicious. Most of the evil traffic (53%) comes from compromised hosts trying to send spam through my house. I used to run my own mailer so maybe my domain is remembered out there in spam world. Around a third (29%) of the addresses are from probes looking for vulnerable Windows (XP?) hosts. These will always be with us I think – it’s just like the background radiation from the big bang. Mostly I’m worried about the 3% that are anonymous proxy addresses. Real hackers use anonymous proxies all the time to stay ahead of law-enforcement. I wonder what they are looking for at my place. Interesting, isn’t it? I think my next step will be to reroute all incoming traffic through the BIG-IP in my home lab so that I can block all of these attacks at layer 3 with IP Reputation and just stop worrying about it. Here’s a comprehensive video on the Threat Analyzer. Download the tool Try it yourself – download and run the IP Threat Analyzer tool and see the analysis of the malicious traffic hitting your data center.The Top Ten Hardcore F5 Security Features in BIG-IP 11.5.0
that went unsung at #RSAC 2014. There’s lots of new security stuff in BIG-IP that shouldn’t be overlooked amidst all the press releases and hoopla at #RSAC 2014. Don’t get me wrong, hoopla has its place: for example, the banking community is excited about the new anti-fraud thing we bought. And Pete Silva’s video interview of Joel Moses for the new Secure Web Gateway forward proxy is great. But the features I’m talking about are too low-level to warrant a press release, interview, or media dinner. In a way they’re even more important because platform-level security features are often the basis for the higher-level software-defined applications services that reside upon them. Just before the RSA 2014 conference, we upgraded the BIG-IP platform to version 11.5.0. The upgrade has hundreds of new features and bug fixes, but these following security features are particularly cool. The Top 10 Hardcore F5 Security Features in BIG-IP 11.5.0 UDP Flood protection in AFM –The new UDP flood protection in the Advanced Firewall Manager (AFM) module automatically detects and mitigates UDP floods. It even categorizes incoming UDP packets so that you don’t end up rate-limiting legitimate DNS requests. Full ECC and DSA Support for client SSL profiles -- on the same virtual server with RSA profiles! A single client SSL profile can now have up to three certificate/key pairs associated with it to support the full range of cipher suites now available! This is huge; people have been asking for it since before germs. Heavy URL DDoS Protection in ASM. Smart attackers may attempt to slow a website by repeatedly requesting heavy URLs such as large media objects or slow database queries. The new Heavy URL DDoS feature of ASM identifies your vulnerable URLs and then defends them. AES-GCM mode for TLS1.2! The crypto community has been waiting for GCM to become prevalent enough to start switching away from simple block and streaming ciphers. This is a big step toward enabling the whole world to be ready for GCM, and what we hope is a future reduction in TLS protocol weaknesses. Improved whitelist and blacklist support in AFM. IP addresses that are blacklisted or whitelisted can be assigned to pre-existing or user-defined blacklist classes (called categories in tmsh), and firewall actions can be applied based on those categories. AFM can be configured to query dynamic lists of blacklist or whitelist addresses, called feeds, and update the configuration accordingly. SafeNet Luna SA HSM integration. For the last few years we’ve been getting requests to integrate with Networked Hardware Security Modules (HSM). We’ve been supporting nCipher (née Thales) HSMs, and now with 11.5.0 we’re announcing our integration with Thales (née SafeNet). Hook your virtual BIG-IPs up to this and you have a pretty compelling security story. F5 HSM Feature Comparision 11.5.0 Features BIG-IP FIPS nCipher (née Thales) Thales (née SafeNet) VIPRION ✔ ✔ ✔ vCMP ✔ ✔ GTM/DNSSEC ✔ ✔ PKCS#11 N/A ✔ ✔ Virtual Edition ✔ ✔ AWS CloudHSM ✔ FIPS 140-2 Level 2 ✔ ✔ ✔ FIPS 140-2 Level 3 ✔ ✔ Perfect Forward Secrecy ✔ ✔ ✔ EAL4+ ✔ ✔ Performance 9000 TPS 3000 TPS 1500 TPS 45 Hardware-level DDoS protections in AFM. The firewall team has added and refactored the network DDoS code to make the hardware vectors exactly match the software vectors. See the complete list of pathological packets that will be dropped before the CPU even sees them. Full PKCS#12 support for key import. The paranoid among us point to the Edward Snowden files and say they’ve never had more reason to be paranoid. For them, we’re making it possible to import SSL keys directly to BIG-IP without them ever being available in the clear. Appliance Mode for vCMP guests. Appliance mode disables the root account and prevents access to the bash system shell. Appliance mode can now be configured on a guest-by-guest basis in multi-tenant environments where a particular guest virtual instance may be less trusted than others. BER-encoding iRule commands. When I was a lazy software developer, one of my goals was to get through life without ever having to write an ASN1 decoder. Guess what, someone has done just that for iRules! Check out the BER/DER iRule command reference. Honestly, this is kind of amazing. These were just the top 10 - there are a ton more features in 11.5.0 (release notes). You can play with them all in your cloud with the virtual edition of BIG-IP – download it here and have fun!
