BIG-IP AFM Blacklisting Magic
Have you ever wondered which IP addresses floating around out there on the Internet are the good ones? The benign ones? The malicious ones? You get the idea. Peter Silva recently published an article that discusses the IP Intelligence feature of the BIG-IP where each IP address is examined and an intelligent decision is made about how good or bad the address is. As the BIG-IP compiles all the data from the IP Intelligence feeds, it can automatically add IP addresses to one or more Blacklist categories for a specified period of time. Blacklist(noun) : a list of items (usernames, IP addresses, etc) that are denied access to a system It’s nice to know that you don’t have to manually add all the Blacklist IP addresses any more. However, you certainly still have the flexibility to add items to a Blacklist category if you’d like. To view the Blacklist category names on the BIG-IP AFM, navigate to Security >> Network Firewall >> IP Intelligence >> Black List Categories and you will see the default categories listed there. The BIG-IP AFM comes preloaded with several Black List categories (i.e. botnets, phishing, spam_sources, etc). Check out the screenshot below for a view of the Black List category page. In addition to the categories already loaded on the BIG-IP, you can create your own categories as well. To do this, simply click the “Create” button on the upper/right portion of the Black List Category page, and you can create a name, description, and Match Type (Source, Destination, or Both) for your category. These categories are important when creating IP Intelligence policies because, when you create an IP Intelligence policy, you can specify what action to take on an IP address from a particular feed list when it matches an IP address in one of your Black List categories. See the screenshot below for details on creating a new Black List Category. Now that you have a new Black List category, it will show up in the full listing of Black List categories. Notice in the screenshot below that my newly created Black List Category is listed. While the BIG-IP AFM will take care of automatically adding bad IP addresses to the various Black List Categories, you can still manually add IP addresses and assign them to a Black List Category as well. To do this, you navigate to the Black List Category page and type in the IP address in top portion of the page and select a Black List Category from the dropdown menu. Finally, you specify (in seconds) the amount of time the IP address should stay in that particular Black List category. See the screenshot below for details: Auto-Shun in Version 12.0 In BIG-IP version 12.0, the "auto-shun" feature was introduced. It allows you to configure a DoS protection profile to watch for a Source IP address and, if it exceeds the detection threshold for a given period of time, it is automatically added to a Blacklist category for a configurable period of time. See the chart below for more details: Many organizations struggle with maintaining a good and timely list of bad IP addresses, but now you have the power of the BIG-IP AFM that can do it all for you automatically!
IP-Intelligence Manual Additions and Bad Actor Additions Not Working
Greetings dev central community, I have come to impasses in two goals on a 15.1.0.5 VE running in esxi related to IP-Intelligence configuration and I would very much appreciate direction for resolution. Impasse 1: Having my manually added IP address be respected by the IP-Intelligence policy.Though pre-existing blacklisted sources are dropped with my configuration, my manually added IP addresses added via are not respected. I'm adding the IP addresses to my categories configured for drop in my IP-Intelligence policy via Security ›› Network Firewall : IP Intelligence : Blacklist Categories >> Add to Category. I've tried with public and private IP's. I've tried with pre-existing and custom blacklist categories. My license is valid. iprep_lookup from the CLI shows no verdict/category for the manually added IP's. Where as the GUI "Check Entry" button shows the IP address as present in the blacklisted category. Impasse 2: DoS blacklisting via Bad Actor Detection is not updating the blacklist category with the offending IP address. My tests have been done via Device DoS Protection via ICMPv4 flooding. I can see the attack vector being rate limited in DoS logs. My settings to add to the bad actor to the blacklist category are set low (Sustained Attack Detection Time of 10 seconds). Even if my test source attacks for a prolonged period of time and is mitigated for this prologed period of time, the address never shows up in the blacklist category specified. I have tried custom categories as well as the pre-made denial-of-service category. I have selected to advertise externally and I have BGP setup to redistribute kernel. Regardless, the IP address that should be shunned does not show up in the routing table as a local blackholed kernel route nor does it show up in the upstream BGP peer as a blackholed route. Manually configured blackholed routes are propogated properly via redistribute kernel. GUI "Check Entry" button does not show the IP address as present in the specified bad actor specified category. I have tried triggering the attack vector/bad actor protection private IP's as well as spoofed public IP's. list security dos device-config dos-device-vector icmpv4-flood allow-advertisement enabled allow-upstream-scrubbing disabled attacked-dst disabled auto-blacklisting enabled auto-scrubbing disabled auto-threshold disabled bad-actor enabled blacklist-category denial_of_service blacklist-detection-seconds 10 blacklist-duration 14400 ceiling 200000 default-internal-rate-limit 100000 detection-threshold-percent 500 detection-threshold-pps 10000 enforce enabled floor 100 multiplier-mitigation-percentage 300 packet-types none per-dst-ip-detection-pps infinite per-dst-ip-limit-pps infinite per-source-ip-detection-pps 1000 per-source-ip-limit-pps 10000 scrubbing-category attacked_ips scrubbing-detection-seconds 10 scrubbing-duration 900 simulate-auto-threshold disabled state mitigate suspicious false threshold-mode manual-multiplier-mitigation valid-domains noneGet Smart with IP Intelligence
There are always threats out there on the big bad internet. The majority of breaches happen at the application layer and many OWASP Top 10s like SQL injection are still malicious favorites to gain entry. Add to that the availability of DDoS tools, anonymous proxies and the rise of hacktivism means networks and systems are bigger targets than ever. Threat detection today relies on a couple elements: Identifying suspicious activity among the billions of data points and refining a large set of suspicious incidents down to those that matter. Today’s cyber-criminals use various techniques to hide their identities and activity. Keeping them out of your systems requires constant vigilance. Every packet that transverses the internet has a source IP address so disabling inbound communications from known malicious IPs can be highly effective. You may not know but F5 offers IP Intelligence Services which provides the functionality to block known malicious IP addresses. It is a layer of IP threat protection and an additional way to allow BIG-IP customers to defend against malicious activity and infrastructure attacks. The IP Intelligence service is offered on several BIG-IP platforms. With IP Intelligence, BIG-IP AFM can be configured to block or allow traffic entering the system based on the reputation of the source IP address. BIG-IP AFM determines reputation using two methods. One is a continuous feed of known or suspected malicious IP addresses provided by a third-party service Webroot BrightCloud. You can also create custom feed lists that specifies IP addresses that have been blacklisted or whitelisted by the organization. The BrightCloud feed is updated every 5 minutes by default and custom feed lists are unique to the AFM and are polled at intervals of your choosing. These two methods are jointly referred to as IP Intelligence and can be used independently or in tandem to filer traffic on the BIG-IP systems. The BrightCloud option is licensed separately through F5 and requires internet connectivity and DNS resolution from your BIG-IP system. Custom feed lists do not need connectivity since it is local to the BIG-IP. IP Intelligence can be applied via AFM firewall policy to the Route Domain or Virtual Server. Once enabled, it will affect all traffic that arrives on your BIG-IP system no matter the access point. The IP Intelligence data is organized into categories that help you differentiate between types of listed IP addresses. There are 11 pre-defined categories including botnets, scanners, infected sources, illegal websites and more. These correspond to the categories in the BrightCloud feed. You can also create up to 51 custom categories to meet your own specific needs. Networks, infrastructures, systems and applications are all under attack these days. While you can do your best at securing your data, sometimes a little call blocking can go a long way in ensuring these known rascals cannot get through. Peace of mind is always a secure feeling. ps
DDoS IPI List - Whitelist NTP Servers
Problem this snippet solves: Legitimate IP address ranges of valid NTP Servers. Additional info can be found: https://github.com/c2theg/DDoS_lists How to use this snippet: Add to IPI feeds. Security >> Network Firewall >> IP Intelligence : Feed Lists Create new list: DDoS_Feeds Add rule. Give a good name, IE: whitelist_ntp_servers List Type: whitelist Update frequency: 3600 Default Blacklist Category: (Create new one) Whitelisted_Source Admin / Password: <Leave Blank> Tested this on version: 13.0DDoS IPI List - Whitelist DNS Servers
Problem this snippet solves: Legitimate IP address ranges of valid DNS Servers Additional info can be found: https://github.com/c2theg/DDoS_lists How to use this snippet: Add to IPI feeds. Security >> Network Firewall >> IP Intelligence : Feed Lists Create new list: DDoS_Feeds Add rule. Give a good name, IE: whitelist_dns_servers List Type: whitelist Update frequency: 3600 Default Blacklist Category: (Create new one) Whitelisted_Source Admin / Password: <Leave Blank> Tested this on version: 13.0DDoS IPI List - Bogons
Problem this snippet solves: Bogon IP address ranges to block traffic from Additional info can be found: https://github.com/c2theg/DDoS_lists How to use this snippet: Add to IPI feeds. Security >> Network Firewall >> IP Intelligence : Feed Lists Create new list: DDoS_Feeds Add rule. Give a good name, IE: blacklist_bogon List Type: blacklist Update frequency: 432000 Default Blacklist Category: (Create new one) Blacklisted_Source Admin / Password: <Leave Blank> Tested this on version: 13.0DDoS IPI List - Whitelist Update Domains
Problem this snippet solves: Legitimate IP address ranges and Domain Names of valid update servers. Additional info can be found: https://github.com/c2theg/DDoS_lists How to use this snippet: Add to IPI feeds. Security >> Network Firewall >> IP Intelligence : Feed Lists Create new list: DDoS_Feeds Add rule. Give a good name, IE: whitelist_update_servers List Type: whitelist Update frequency: 3600 Default Blacklist Category: (Create new one) Whitelisted_Source Admin / Password: <Leave Blank> Tested this on version: 13.0Whitelist Blacklist iRule using data group for multiple clients
We are testing single VIP configuration in our test lab, where single public IP will be assigned to multiple clients, using an iRule with a data group. iRule looks like this --- when HTTP_REQUEST { set pool [class match -value -- [HTTP::host] equals test_url] if {$pool ne ""} { pool $pool } } test_url is data group which has strings mapped to appropriate pools of each client. For example, string client1.com mapped to pool client1.net. string client2.com mapped to pool client2.net Now the issue is we want to include whitelist/blacklist for these clients in the same iRule if possible or even a separate iRule would be OK. Could someone suggest the syntax for whitelising/blacklisting based on client string and remote IP pair in data group? For example, if string has client1 and matches dg_whitelist_1, allow. if string has client2 and matches dg_whitelist_2, allow. if string has client3 and matches dg_blacklist_1, deny. There are also clients with no whitelist/blacklist, so it should work just fine for them within same iRule.
Simple GTM Domain Generation Algorithm dynamic blacklist
Problem this snippet solves: Simple GTM DGA dynamic blacklist used to reduce load on backend DNS servers. This iRule should be applied to GTM listener. Here are a list of all the configurable options: static::debug - enable/disable verbose logging to /var/log/ltm static::timeout - blacklist timeout static::threshold - threshold to enable dns blacklisting of a domain You need to set timeout and threshold according to your needs before enabling this irule. Code : when RULE_INIT { set static::debug 0 set static::timeout 60 set static::threshold 10 } when DNS_REQUEST { regexp {([-A-Z,a-z,0-9]+.[-A-Z,a-z,0-9]+)$} [DNS::question name] domain set count [table lookup ddbl_$domain] if { $count >= $static::threshold} { if { $static::debug } { log local0. "\[DDBL\] Dropping question [DNS::question name], $domain is on dynamic dns blacklist" } table timeout ddbl_$domain $static::timeout DNS::drop } } when DNS_RESPONSE { if { [DNS::ptype] == "NXDOMAIN" } { set count [ table incr ddbl_$domain ] table timeout ddbl_$domain $static::timeout if { $static::debug } { log local0. "\[DDBL\] NXDOMAIN HIT [DNS::question name], hitcount is $count, threshold is $static::threshold" } } } Tested this on version: 11.6
