F5 BIG-IP ASM – L7 DDoS attack Protection (TPS, Behavioral & Stress Based detection)
I would like to extend a big thank you to Mr.Mohamed_Ahmed_Kansoh for his invaluable help in creating this article on the F5 BIG-IP ASM - L7 DDoS protection You can also check this article on: https://nishalrai.com.np/2023/07/14/f5-big-ip-asm-l7-ddos-attack-protection/ F5 BIG-IP ASM DoS profile provided two distinct types of detection of DoS protection – TPS-based detection and Behavioral & Stress-based detection. TPS Based detection On threshold mode, if it is configured automatic then the TPS-based DoS protection is triggered, “If the ratio of the transaction rate during the detection interval to the transaction rate during the history interval is greater than the percentage indicated in the TPS increased by setting, the system considers the URL to be under attack, or the IP address to be suspicious.” Reference:Preventing DoS Attacks for Layer 7 Traffic On this post, We will discuss about the DoS protection profile especially the Behavioral and Stress Based detection features available on the F5 BIG-IP ASM module. One can find the DoS security profile protection profile on F5 Main Dashboard > Security > DOS Protection Behavioral & Stress based detection The server-based detection only implements the mitigation when there is significant latency from the backend server responses. In case of the occasional high spike of CPU usage on the backend server, it does trigger the stress-based DoS but when you view the output of the event timestamp. This sums up the significant latency on the server response, that ends up the stress-based DoS. To view the server response latency: Statistics > Dashboard > Behavioral DoS Regarding the behavior DoS protection of F5 BIG-IP ASM, the behavioral method is an intelligent way to identify and mitigate DoS attacks by creating a good baseline from normal traffic – users from normal or legitimate traffic. One needs to allocate sufficient time for F5 BIG-IP to create its baseline of learning good traffic. One can monitor the learned baseline of traffic on F5 BIG-IP: [root@bigipo01:Active:Standalone] config # admd -s vs./Common/vs_hackazon_http+/Common/hackazon_bados.info.learning - /Common/vs_hackazon_http – is the name of the virtual server - /Common/hackazon_bados – is the name of the DoS profile. **It may take several minutes for baseline numbers to be generated** Ref: Base Configuration and Traffic Baseline Behavioral Detection and mitigation stage When the F5 BIG-IP discovers any abnormal pattern of traffic that violates its learned baseline and observes the latency increased in Sever. It starts to create signatures for these attack patterns and starts to slow down / rate limits the request on the basis of the implemented mitigation technique – standard protection, aggressive protection, and others. F5 BIG-IP takes some headers from the violating/attack requests “abnormal requests ones” and stores it in a signature form, then these headers are bundled with each other within a single signature to identify the attacked request. So these are the parameters that F5 BIG-IP ASM DoS protection uses to create the signatures. In the ASM DoS profile, if “Use approved signature only” has been enabled then the administrator needs to open the signature and review its headers and information in order to approve it. In case you feel that it’s an attack then you need to disable it. If “Use approved signature only” is enabled in F5 BIG-IP ASM DoS profile, it will use the created signatures immediately without the administrator’s approval and will start to block any request that does not match the approved signature. Reference: Behavioral and stress-based detection settings Stress-Based detection The stress-based detection can be configured for detection criteria for server latency and transactions-per-second (TPS). F5 BIG-IP ASM marks the IP address as suspicious if any attacks trigger the set latency thresholds by the F5 BIG-IP. Once it has been triggered, the DoS engine starts collecting TPS information for the suspicious IP then analyzes TPS history rate to determine if it is a real DoS attack or a false positive. When the suspicious criteria TPS is reached, the BIG-IP ASM drops connections based on the policy - either by source IP or per URL. If the TPS (per IP address) is reached, the prevention policy switches to Source IP-Based Rate Limiting mode. If the TPS (per URL) is reached, URL-Based Rate Limiting is applied, and connections are reset. If the request is still considered an attack, the second and third policy are attempted with a two-minute interval between them. The BIG-IP ASM allows you to set a Prevention Duration to limit connections during a DoS attack. This defines the F5 BIG-IP ASM to considered the configured time period to either escalate or deescalate the configured mitigation methods – client-side integrity, CAPTCHA challenger or even block the request. Rate-Limit Prevention The rate-limiting is a mechanism used by the F5 BIG-IP ASM to prevent DDoS attacks on the protected applications or services. The F5 BIG-IP ASM calculates the average Transactions per seconds (TPS) for both the Detection Interval that lasts 10 seconds and the Historical Interval (last hour). Then, it updates them every 10 seconds. To rate-limit incoming traffic, F5 BIG-IP ASM uses a simple equation as: (History Interval TPS + Configured Threshold) / 2 For instance, if the absolute threshold is set to 200 TPS and the Historical Interval TPS average is 100 TPS, then the BIG-IP ASM will rate-limit incoming traffic to 150 TPS. The F5 BIG-IP ASM will rate-limit incoming traffic if the TPS exceeds the absolute threshold or if the sum of the relative threshold and the current TPS exceeds the absolute threshold. Note: You can review it from logs when attack was initiated, you can observe the limit which F5 BIG-IP was set and how it violated by crossing those configured threshold when the attack started. You have the option to record the DoS traffic on the DoS protection profile. During a DDoS attack, the recorded packet capture file shows that some traffic receives RST packets from the BIG-IP ASM, while other traffic receives normal responses (200 OK). This indicates that, while rate-limiting can prevent some traffic from passing through the BIG-IP ASM, it is not a foolproof method. Compared to blocking all traffic, rate-limiting allows some traffic to pass through the BIG-IP ASM, while blocking all traffic resets all traffic from a specific source. Bad Actors behavior detection On the bad actor’s behavior detection, F5 BIG-IP monitors and tracks the server response time. Once significant server latency is observed then starts to keep the track of all the ingress traffic request ip address, monitors their request and calculates the value (kind of score either to quarantine or discard the further request). To display the IP greylist: ipidr -l /Common/<vs-profile>+/Common/<dos-profile> To view the current maximum TPS of the DoS profile. tmsh show security dos profile my_dos_profile In-Sight of F5 BIG-IP ASM DoS Profile Sometimes the spike in CPU usage on the backend server triggers the attached ASM DoS profile. So, what would be the F5 BIG-IP approach to learn and detect those spike patterns as a DoS attack like for certain intervals of time - will it ignore those spikes and only after a certain interval of time with a predefined % of CPU usage of the backend server like +90% for 5 minutes or less that triggers the DoS profile. and if so, can we customize those defined parameters on the DoS profile. Such behavior has resulted into a lot of false positive. Stress-based mitigation will not be triggered if only configured TPS was exceeded and high latencies coming from servers are in AND Boolean condition. With such configuration, even if servers encountered spike due to high number of transactions TPS, F5 BIG-IP will not start mitigation if only there is high latency in server side. In short, even if the dos profile is triggered when the server-side latency is automatically spiked without any violation of the configured baseline TPS, the implemented mitigation will not be enforced on the new inbound traffic. Moreover, we cannot manually configure the baseline of those CPU usage and server latency percentage threshold. Even though F5 has released the white paper addressing those changes can be possible in the F5 BIG-IP, those changes are not possible on the major version or may not be possible on the preceding version too. Reference: Intelligent Layer 7 DoS and Brute Force Protection for Web Applications | F5 White Paper dosl7d dosl7d daemon runs in the background which will continuously monitor the two major variables – Memory Usage and TMM count. The services and scripts attached to the dosl7d process All those logics and algorithms to detect those DoS detection based on the behavioral and stress-based detection has been compiled and stored on the dosl7 dosl7d daemon responsible for detection of the DoS attacks (when triggered) and the log are stored on the /var/log/dosl7d In the directory, /etc/bigstart/startup Scripts of dosl7d - /etc/bigstart/scripts Sample of dosl7d logs (CLI & GUI) F5 BIG-IP GUI Why can't we configure SNMP alert for L7 dos attack on F5 BIG-IP, right now? In F5 Big-IP v 11.3.0 and later, messages generated by the dosl7d daemon cannot trigger commands or custom scripts because they are not processed by the alertd SNMP process. This is because the dosl7d daemon writes directly to its log file (/var/log/dosl7d/dosl7d.log) instread of using syslog facilities. As a result, the messages the dosl7d daemon issues do not pass through the syslog pipe. So, the alertd daemon cannot see the dosl7d messages and unable to trigger SNMP traps. The only current options for detecting a DoS attack is through an external logging device. The other workaround which will implicitly solve the existing issue by creating an email alert notification when the configured threshold (manual TPS of the DoS profile or server latency or others) has been triggered on the selected virtual instances, pools or application. However, the limitation of this configuration can be the inability to select the specific virtual instances and pools to configure separate threshold values to trigger. But it can somehow mitigate the issues of implementing dos protection mitigation without being noticed by the F5 administrator on high critical business oriented applications or services.
custum reponse page for api
here is a custom response specific to aWaf adapted for the API and status code (406), ex for Maximum Length : when ASM_REQUEST_BLOCKING { set violationDetails [ASM::violation details] set supportID [ASM::support_id] if { [regexp {json_error.error \{Maximum Length Violation\}} $violationDetails] } { set maxLengthViolation 1 regexp {json_error.tag \{(.+?)\}} $violationDetails _ jsonErrorTag regexp {json_error.received ([0-9.]+)} $violationDetails _ jsonErrorReceived regexp {json_error.expected ([0-9.]+)} $violationDetails _ jsonErrorExpected set customResponse "{\"error\": \"Maximum Length Violation\", \"json_error.tag\": \"$jsonErrorTag\", \"json_error.received\": $jsonErrorReceived, \"json_error.expected\": $jsonErrorExpected, \"SupportID\": \"$supportID\"}" ASM::payload replace 0 [ASM::payload length] "" } } when HTTP_RESPONSE_RELEASE { catch { if { [info exists maxLengthViolation] } { HTTP::respond 406 content $customResponse "Content-Type" "application/json" } } } result : { "error": "Maximum Length Violation", "json_error.tag": "$.livraison.adresse_l42_rue", "json_error.received": 53.000000, "json_error.expected": 38.000000, "SupportID": "7413896671462963248" }
Case insensitivity in ASM Brute Force username and/or password elements
I have a login page I'm attempting to enable brute force protection for (JSON/AJAX auth type), and it supports username and password JSON elements that are case insensitive from our application's perspective, meaning we expect clients to send them with inconsistent casing. The help text shows that the F5 BIG-IP expects these parameters to be case sensitive, which makes me think that even if we used an ASM policy with case sensitivity disabled during creation, it would still be treated as case sensitive. Frankly even if this did work as a workaround, I'm not sure I'd want to do this because I don't want everything in the policy to be case insensitive - just these few login elements. Also I'm not able to create a "duplicate" login URL where each one uses a different case for the username and/or password elements - the ASM policy prevents this. What is the recommendation for how to implement brute force protection for username and/or password parameters that can be sent with multiple cases?How's your API security strategy since last year?
Last year, API security was an overwhelming theme across the security events that I attended, RSA and BlackHat. As myself,PSilvaandAubreyKingF5head to RSA Conference 2023, I'm interested to see if the theme will change. But ahead of that, I'm wondering how you all in the Community have been dealing with APIs? Have you actually had API security projects? Or, is it being pushed out for the time being? Or, is it even being looked at?Prevent BIG-IP Edge Client VPN Driver to roll back (or forward) during PPP/RAS errors
If you (like some of my customers) want to have the BIG-IP Edge Client packaged and distributed as a software package within your corporate infrastructure and therefore have switched off automatic component updates in your connectivity profiles, you might still get the covpn64.sys file upgraded or downgraded to the same version as the one installed on the BIG-IP APM server. Background We discovered that on some Windows clients the file covpn64.sys file got a newer/older timestamp in and started to investigate what caused this. The conclusion was that sometimes after hibernation or sleep, the Edge Client is unable to open the VPN interface and therefore tries to reinstall the driver. However, instead of using a local copy of the CAB file where the covpn64.sys file resides, it downloads it from the APM server regardless of if the version on the server and client match each other or not. In normal circumstances when you have automatic upgrades on the clients, this might not be a problem, however when you need to have full control on which version is being used on each connected client, this behavior can be a bit of a problem. Removing the Installer Component? Now you might be thinking, hey… Why don't you just remove the Component Installer module from the Edge Client and you won't have this issue. Well the simple answer to this is the fact that the Component Installer module is not only used to install/upgrade the client. In fact, it seems like it's also used when performing the Machine Check Info from the Access Policy when authenticating the user. So by removing the Component Installer module result in other issues. The Solution/workaround The Solution I came up with is to store each version of the urxvpn.cab file in an IFile and then use an iRule to deliver the correct version whenever a client tries to fetch the file for reinstallation. What's needed? In order to make this work we need to Grab a copy of urxvpn.cab from each version of the client Create an IFile for each of these versions Install iRule Attach iRule to the Virtual Server that is running the Access Policy Fetching the file from the apmclients ISOs For every version of the APM client that is available within your organization a corresponding iFile needs to be created. To create the iFiles automatically you can do the following on the APM server. Login to the CLI console with SSH Make sure you are in bash by typing bash Create temporary directories mkdir /tmp/apm-urxvpn mkdir /tmp/apm-iso Run the following (still in bash not TMSH) on the BIG-IP APM server to automatically extract the urxvpn.cab file from each installed image and save them in the folder /tmp/apm-urxvpn. for c in /shared/apm/images/apmclients-* do version="$(echo "$c" | awk -F. \ '{gsub(".*apmclients-","");printf "%04d.%04d.%04d.%04d", $1, $2, $3, $4}')" && \ (mount -o ro $c /tmp/apm-iso cp /tmp/apm-iso/sam/www/webtop/public/download/urxvpn.cab \ /tmp/apm-urxvpn/URXVPN.CAB-$version umount /tmp/apm-iso) done Check the files copied ls -al /tmp/apm-urxvpn Import each file either with tmsh or with GUI. We will cover how to import with tmsh below. If you prefer to do it with the GUI, more information abour how to do it can be found in K13423 You can use the following script to automatically import all files cd /tmp/apm-uxrvpn for f in URXVPN.CAB-* do printf "create sys file ifile $f source-path file:$(pwd)/$f\ncreate ltm ifile $f file-name $f\n" | tmsh done Save the new configuration tmsh -c “save sys config” Time to create the iRule when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable } when HTTP_REQUEST { set uri [HTTP::uri] set ua [HTTP::header "User-Agent"] if {$uri starts_with "/vdesk" || $uri starts_with "/pre"} { set version "" regexp -- {EdgeClient/(\d{4}\.\d{4}\.\d{4}\.\d{4})} $ua var version if {$version != ""} { table set -subtable vpn_client_ip_to_versions [IP::client_addr] $version 86400 86400 } else { log local0.debug "Unable to parse version from: $ua for IP: [IP::client_addr] URI: $uri" } } elseif {$uri == "/public/download/urxvpn.cab"} { set version "" regexp -- {EdgeClient/(\d{4}\.\d{4}\.\d{4}\.\d{4})} $ua var version if {$version == ""} { log local0.warning "Unable to parse version from: $ua, will search session table" set version [table lookup -subtable vpn_client_ip_to_versions [IP::client_addr]] log local0.warning "Version in table: $version" } if {$version == ""} { log local0.warning "Unable to find version session table" HTTP::respond 404 content "Missing version in request" "Content-Type" "text/plain" } else { set out "" catch { set out [ifile get "/Common/URXVPN.CAB-$version"] } if {$out == ""} { log local0.error "Didn't find urxvpn.cab file for Edge Client version: $version" HTTP::respond 404 content "Unable to find requested file for version $version\n" "Content-Type" "text/plain" } else { HTTP::respond 200 content $out "Content-Type" "application/vnd.ms-cab-compressed" } } } } Add the iRule to the APM Virtual Server Known Limitations If multiple clients with different versions of the Edge Client are behind the same IP address, they might download the wrong version. This is due to the fact that the client doesn't present the version when the request for the file urxvpn.cab reaches the iRule. This is why the iRule tries to store IP addresses based on the source IP address of other requests related to the VPN. More information about this problem can be found in K000132735
REMOTE AUTHENTICATION OF BIGIP THROUGH LDAP AND LDAPS ( MICROSOFT AD)
Hello Guys , Today we are going to discuss about configuration of F5's Remote Authentication using Microsoft AD over LDAP and LDAP over SSL Firstly , To discuss about the difference between AD and LDAP , AD ( Active directory) is the database where the Schema of information present about a user for Authentication whereas LDAP is the open source protocol used to access the information present in the database For this Exercise , We are using Microsoft 2012 R2 server for ADDS ( Active directory Domain Services ) and also for ADCS(Active directory certificate services) and also windows 7 professional client from where we will access the BIGIP and also the BIGIP device accessed through remote authentication what is important in configuration of ADDS? Firstly Login to the server and change the computer name accordingly on the start-->Run-->control panel --> System and Security --->System--->Properties--->Computer name I have given a Computer name to LDAPSTEST Now Add the ADDS Feature and ADCS feature to the server Go to server manager ---> Add Roles and Features ---> Check the ADDS feature --->Next By Default DNS server is created when adding AD so need of adding any DNS feature Once the ADDS is installed , In the event manager , ADDS service prompts to prompote a Domain controller As we are configuring AD for the first time , Start by creating a Forest ( To understand what is forest It is a combination of one or more domains with one domain controller managing different domains ) Forest name has to be fully qualified name , So I have configured ldapstest.com as the forest name Then the Menu prompts for a suggested Netbios name , Accept as default Then Menu prompts for selected the Common name , Domain names , Select the common name as ldapstest and leave DN as default that is given Then the domain will be prompted To see the hierarchy of my AD , Kindly check below Go to Server manager --> Tools ---> Active directory users and forests Here ldapstest.com is the domain in the forest and also the same server is acting as a domain controller. I have created an organisation unit called engineering where i have created the users under that , If we see my directory hierarchy it is same as below We are done with Configurations on AD and now LDAP listens on Non SSL port 386 To Configure BIGIP Host is the IP address of the server and port is the non-ssl port for LDAP , Remote directory tree is the LDAP hierarchy on the server , How did i found out that This can be easily figured out using ldp.exe , Go to server powershell and type ldp.exe and an ldp client opens Click on Connection on the client and click on Bind --->select simple bind and add users which is created in the AD's Organization unit and give the password , Type the domain ( In my case ldapstest.com) Click OK and once the Credentials are authenticatied on the LDP client , click on View and tree ,and input the Base DN ( which is Distinguished name ( Here in our case it is ldapstest.com) , Hierarchy will be seen In my case I have created a user called lab in engineering OU's for LDAP bind operation How does LDAP connection establishes and Authentciation happens LDAP connection from the BIGIP to LDAP server starts when we input the credentials and the first message is LDAP Bind request where BIGIP provides the CN( Common name ) The user name with which BIGIP authenticate to LDAP Server DC ( Distinguished component of the Domain name , in this case DC=ldapstest , DC=com) Once the credentials are authenticted BING success message is seen Then the client sends the SAMACCOUNTNAME that the user inputted to login to BIGIP and the that happens with a searchRequest , This search request searches the entire subdirectories provides in the DN ( in our case it searches all the hierachical directories presented in the above snapshot) and finds if the user is already present in the AD database If the SAMaccountname is identified in the database , Searchresponse provides the LDAP references and the attributes of the SAM account name and the client uses those references to form a bind request , On successful authentication Bind response is sent to the client and the device gets authenticated Drawback of LDAP is all the communication between BIGIP and the LDAP server happens over clear text just like we see in the above screenshot To overcome this we can use LDAP over SSL for the communication between BIGIP and the LDAP server and everything will be encrypted over a secured TLS communication To get that , We are using ADCS ( Active directory certificate services ) to get the certificate Step1 would be enabling the roles of ADCS from server manager --->Manage --->ADCS Once the ADCS is enabled , Go to tools and certificate authorities and create a certificate for a common name , I prefer using the Comman name as ldapstest.com (you can use as you prefer) After successful creation we will be seeing two certificates in our servers trust store From the start--> go to manage certificates Export the root certificate without the private key by clicking on the certificate-->All tasks-->Export , The menu prompts you if you need the private key to be exported , you can say it as no and export the cert in .cer format This certicate we will be using for server authentication while establishing the communication between BIGIP and the LDAP server Once this is done , Import this certificate on the BIGIP Now navigate to users-->Authentication Changed the port to 636 as it is default port for LDAP over SSL Have enabled the SSL and added the SSL CA certificate which we have imported in the last step Now the communication will be secured between BIGIP and LDAP server over SSL
Insufficient permissions BIG-IQ login error.
Hi, Problem: Initial setup ofBIG-IQ CM orBIG-IQ DCD Unable to login into the BIG-IQ GUI but able to login using SSH This type of problem happens when your local machine and BIG-IQ have much time difference. Step for solution: Step_1&2: Configure NTP Server on BIG-IQ & Set timezone tmsh modify sys ntp servers add {10.12.30.1 10.50.30.10} modify sys ntp timezone Asia/Dhaka save sys config Some show command for cross check time is change or not. Show NTP Server List tmsh list sys ntp servers Show NTP TImezone List tmsh list sys ntp timezone Show date date Additional Information: You can set time manually following article K3381. ------------------------- Regards, Md. Emon Hossain
F5 BIG-IP Automatic email notification for system live update (ASM/AWAF signature)
Recently had some request from Security team askingan email to be sent from the F5 BIG-IP when it installs an live update such as ASM signature updates via the automatic schedule. upon looking at KBs it doesn't seem to be a natively embedded function for now. So my idea is to trace system log for signature updates, and generate an SNMP message to trigger email notification. Most syslogs and updates could be found from /log/var/ directory while as some event based log such as Signature updates are located in a different place. https://support.f5.com/csp/article/K82512024 The system live update info is located in /var/log/tomcat/liveupdate.log So the thinking is once the system generate a log after the signature Update, you could try to grab log info and use a unique key word to identify completion of update, and use the key word a customised OID to trigger SNMP trap for system notification. Once you schedule or completed an installation: You should be able to see the log generated with following info: cat /var/log/tomcat/liveupdate.log | grep modifiedEntitiesCount XXXX… {"link":"https://localhost/mgmt/tm/asm/signatures/y5tmU8gG6VdfPFaVbRSPLg","name":"Java code injection - java.util.concurrent.ScheduledThreadPoolExecutor"},{"link":"https://localhost/mgmt/tm/asm/signatures/7KeqKA8hHqv2cfJBXRMz9Q","name":"Java code injection - oracle.jms.AQjmsQueueConnectionFactory"},{"link":"https://localhost/mgmt/tm/asm/signatures/-NXlVMOujg3EvdVKd7PVQA","name":"btoa() (URI)"},{"link":"https://localhost/mgmt/tm/asm/signatures/sqa3ct3N1gOjMZLc3KiNsw","name":"SQL-INJ \"UNION SELECT\" (3) (URI)"},{"link":"https://localhost/mgmt/tm/asm/signatures/J4R4I5KgY8akJtm3TOc55w","name":"\"/etc/php4/apache2/php.ini\" access (Parameter)"},{"link":"https://localhost/mgmt/tm/asm/signatures/S2IcFP11pOpAHjFOSBIi3Q","name":"\"mail\" execution attempt (2) (Header)"},{"link":"https://localhost/mgmt/tm/asm/signatures/HUqMOwJ9SHU6mJF0y3HjBg","name":"SQL-INJ convert(db_name) (Header)"}],"modifiedEntitiesCount":1599} The word: modifiedEntitiesCount seemed to only poppulate upon a installation of signature update completion. so we could use the log key world modifiedEntitiesCount to customise a System OID associate with email alerts https://support.f5.com/csp/article/K3727 add something like the following in to/config/user_alert.conf: alert ASM_update_STATUS " modifiedEntitiesCount(.*)" { snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.xxx" } and create an email alert with SNMP Trap https://support.f5.com/csp/article/K3667 alert BIGIP_SIG_UPDATE_COMPLETE { snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.XXX"; email toaddress="demo@askf5.com" fromaddress="root" body="The Signature has been updated!" } This tricks could also apply to any event based notification you 'd like to sent using keyword from log files. https://support.f5.com/csp/article/K16197 If you would like to put some feed from BIG-IP notification instead of using you log server to filter some tailored events, I hope this could be helpful. Any comments for improvement or correction would be highly appreciated
