DNS Tunnel Mitigation v2
Problem this snippet solves: (Solution from Pedro Haoa) Due to some people attempt DNS tunneling to pass data frames inside of DNS records to the Internet and the lack of information around here, I'm going to share with you some basic code for DNS Tunnel Mitigation on the BIG-IPs. This irule put some overhead in your CPU so check it with caution. The idea is to improve this code (I'm looking for less overhead) here in DevCentral and try to build a better base solution for the most common techniques. You can use the DNS Protocol Security, DNS Anti-DDoS and IP Intelligence features to get the most comprehensive solution. Remember that there are a lot of DNS Tunneling utilities with a wide range of capabilities and options, so this is one of many forms to mitigate some of the attacks. How to use this snippet: LTM + AFM + DNS Services BIG-IP AFM (Protocol Security) In Security ›› Protocol Security : Security Profiles : DNS ›› Create a New Security Profile and exclude obsolete record types like MD, MF, MAILA, NULL, HINFO, SPF, etc. Then apply to your DNS profile associated with your Listener. BIG-IP DNS (LTM Data Groups and iRule) Creating DNS Tunnel Query type Data Group BIG-IP AFM (Protocol Security) In Security ›› Protocol Security : Security Profiles : DNS ›› Create a New Security Profile and exclude obsolete record types like MD, MF, MAILA, NULL, HINFO, SPF, etc. Then apply to your DNS profile associated with your Listener. BIG-IP DNS (LTM Data Groups and iRule) Creating DNS Tunnel Query type Data Group create ltm data-group internal TunnelType records replace-all-with { CNAME { } } type string modify ltm data-group internal TunnelType records add { TXT { } } modify ltm data-group internal TunnelType records add { SRV { } } modify ltm data-group internal TunnelType records add { KEY { } } Creating Whitelist Data Group create ltm data-group internal Dominios_Lista_Blanca records replace-all-with { facebook.com { data facebook.com } } type string modify ltm data-group internal Dominios_Lista_Blanca records add { instagram.com { data instagram.com } } modify ltm data-group internal Dominios_Lista_Blanca records add { fbcdn.net { data fbcdn.net } } modify ltm data-group internal Dominios_Lista_Blanca records add { google.com { data google.com } } modify ltm data-group internal Dominios_Lista_Blanca records add { googleapis.com { data googleapis.com } } Creating Blacklist Data Group create ltm data-group internal Dominios_Lista_Negra records replace-all-with { dnstunnel.de { data dnstunnel.de } } type string modify ltm data-group internal Dominios_Lista_Negra records add { cutheatergroup.cn { data cutheatergroup.cn } } modify ltm data-group internal Dominios_Lista_Negra records add { demodomain.cz { data demodomain.cz } } modify ltm data-group internal Dominios_Lista_Negra records add { buo.cc { data buo.cc } } modify ltm data-group internal Dominios_Lista_Negra records add { pdk.lcn.cc { data pdk.lcn.cc } } Code : when RULE_INIT { # Max DNS queries during detection period per source IP / destination domain set static::maxq 180 # Detection & Blocking Period set static::btime 60 } when DNS_REQUEST { set srcip [IP::remote_addr] set qtype [DNS::question type] set DomOrigen [domain [DNS::question name] 4] set key "$srcip:$DomOrigen" if { ([class match $qtype equals TunnelType]) and [DNS::len] > 512 } { if {[class match $DomOrigen ends_with Dominios_Lista_Blanca] }{ return } elseif {[class match $DomOrigen ends_with Dominios_Lista_Negra] }{ DNS::drop return } elseif {[table lookup $key] ne ""} { set count [table incr $key] if {$count > $static::maxq} { DNS::drop return } } else { table add $key 1 indef $static::btime } } } Tested this on version: No Version Found
AWS Advanced HA iApp
Problem this snippet solves: SUMMARY For customers who want to deploy Public Internet-facing services on a traditional High Availability pair but also leverage the benefits of AWS’s Availability Zones, we introduce the AWS Advanced HA iApp. The AWS Advanced HA iApp helps facilitate the HA Across AZs deployment, an additional deployment option to those discussed in: F5 in AWS Part 1 - AWS Networking Basics F5 in AWS Part 2 - Running BIG-IP in an EC2 Virtual Private Cloud F5 in AWS Part 3 - Advanced Topologies and More on Highly Available Services As well as enable traditional HA pairs to perform basic route management of AWS route tables (whether in “Single AZ” or the “Across AZ” deployments introduced above). By having the Active BIG-IP take ownership of your client’s or application’s “default” or specific routes, this enables: Virtual Servers to avoid using SNAT* Manage Access Traffic (ex. point clients/servers to BIG-IP APM VPN for specific on-prem networks)* Facilitate various outbound proxy use cases (NAT, URI filtering, etc) For more information, see the Deployment Guide Minimum required BIG-IP version: 12.1.0 HF2. Supported BIG-IP versions: 12.1.0 HF2. Various Cloud Formation Templates that automate the installation of this solution are available on github. They are listed under the naming format "full-stack-across-az-cluster-*" We recommend you first start with "full-stack-" examples to get a fully functioning reference deployment and the "existing-*" ones once you're comfortable with the general requirements (security groups, route tables, etc). RELEASES v1.0.0 iApp template to configure HA Across Availability Zones in AWS by managing EIP mappings. v1.0.1 iApp template to configure HA Across Availability Zones in AWS by managing EIP and route mappings. v1.0.1rc1 This version 1.0.1rc1 of the iApp template is available at downloads.f5.com. This official release candidate version contains the same functionality as the previous version (v1.0.1 on DevCentral), but the presentation has been updated. There is also a new F5 deployment guide to accompany the iApp template. Go to https://downloads.f5.com/esd/index.jsp.2. Click Find a Download. Click iApp Templates. Accept the EULA, and then download the iapps zip file to a location accessible from your BIG-IP system. Extract (unzip) the f5.aws_advanced_ha.v1.0.1rc1.tmpl file, found in the **_RELEASE CANDIDATE_** directory of the zip file. v1.1.0rc1 This version 1.1.0rc1 template is available for download on this page. F5 has released version 1.1.0rc1 of the iApp. This official release candidate version contains the same functionality as the previous version (v1.0.1rc1 on DevCentral), with further checks and support added for AWS EIP ownership. In previous versions, EIP ownership was indicated by which device owns the default floating traffic-group-1. As there was only one floating traffic group, this affected the global Active/Standby status of the devices. This iApp has been updated to validate EIP ownership after an active-active state scenario and ensures the current EIP owner is Active for traffic-group-1 (the traffic-group tied to the EIP mappings). CAVEATS Both BIG-IP devices will now report active for their global status, as each device will now own a device specific traffic group. The active status of the default floating traffic-group-1 will indicate which BIG-IP device is actively serving EIP production traffic. The BIG-IP hostname should not be changed during an active deployment of this iApp. This solution only supports the 3 traffic groups as described above. INSTALLATION If you are using a previous version of this iApp and need to update the application service with this updated iApp, there are two prerequisites before you run this iApp: Remove from the file /config/failover/active this line "python /config/failover/aws_advanced_failover.py” Delete the file /config/failover/aws_advanced_failover.py entirely Reparent the application service to use the new version of iApp template This new version will modify the following files in /config/failover on first configuration run tgactive (modify) tgstandby (modify) and install the following aws_af_tgactive aws_af_tgstandby aws_advanced_failover.py aws_advanced_failover.dat On subsequent reconfiguration, it updates the above 4 files listed. v1.2.0rc1 This version 1.2.0rc1 template is available for download on this page. F5 has released version 1.2.0rc1 of the iApp. This official release candidate version contains the same functionality as the previous version (v1.0.1rc1 on DevCentral, or v1.1.0rc1), with further checks and support added for AWS EIP ownership. In previous versions, EIP ownership was indicated by which device owns the default floating traffic-group-1. As there was only one floating traffic group, this affected the global Active/Standby status of the devices. This iApp has been updated to validate EIP ownership after an active-active state scenario and ensures the current EIP owner is Active. CAVEATS Noted caveats from v1.1.0rc1 removed. INSTALLATION If you are using a previous version of this iApp and need to update the application service with this updated iApp, there are a few prerequisites before you run this iApp: Remove from the file /config/failover/active this line "python /config/failover/aws_advanced_failover.py” Delete the file /config/failover/aws_advanced_failover.py entirely Delete the file /config/failover/aws_af_tgactive (if previous version is v1.1.0rc1) Delete the file /config/failover/aws_af_tgstandby (if previous version is v1.1.0rc1) Reparent the application service to use the new version of iApp template This new version will modify the following files in /config/failover on first configuration run tgactive (modify) tgstandby (modify) tgrefresh (modify) and install the following aws_advanced_failover.py aws_advanced_failover.dat On subsequent reconfiguration, it updates the above 2 files listed. Code : 70828
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.0
