Leaked Credential Check with Advanced WAF
Description In this article you will learn how to configure and use Leaked Credential Check (LCC).LCC provides access to a database of compromised credentials, which can be used to detect and prevent a Credential Stuffing Attack. LCC is a subscription-based service which can be added to BIG-IP Advanced WAF. Summary Leaked Credential Check stops leaked or stolen credentials from being used to access personal or business applications. It automatically detects and mitigates compromised credential use. If compromised credentials are detected during an attempted login, Leaked Credential Check enables several mitigation options for SecOps teams to enact, individually or collectively, including: Requiring the user to employ multi-factor authentication (MFA) before granting access. Redirecting the user to another application page; for example, a customer support web page. Responding to the suspicious login with a preset page requesting further action by the user, such as contacting customer support. Blocking the user and their login from accessing the application. Sending an alert to the SecOps team to take additional action This article assumes you have Advanced WAF configured and deployed for one or more Virtual Servers and you have purchased the add-on subscription for LCC. Typical Steps Involved in a Credential Stuffing Attack High Level Network Topology Configuration Steps From the BIG-IP Configuration Utility select Security > Application Security > Security Policies > Policies List. Notice the Policy name in this example is Leaked-Credential-Check.There are 2 Virtual Servers attached to this policy, vs_arcadia.emea.f5se.com_II and vs_Hackazon_IV. LCC is configured from Security > Cloud Services > Cloud Security Services Applications. Click the name of the Cloud Security Application, f5-credential-stuffing-cloud-app in this example. Note: if the application has not been created yet click the Create button on the right. Give it a name if creating a new app.Set the Service Type to Blackfish Credential Stuffing Service.Enter your API Key ID and Secret.Specify the Endpoint, f5-credential-stuffing-blackfishin this example. Click Save when done LCC is enabled in Security > Application Security > Brute Force Attack Prevention. Check the box to Enable Detection Under Action you can choose different mitigation Actions. Alarm: report the Leaked Credentials Detection violation in the Event Log Alarm and Blocking Page: report the Leaked Credentials Detection violation in Event Log and send the Blocking Response Page Alarm and Honeypot Page: report the Leaked Credentials Detection violation in Event Log and send the Honeypot Response Page Alarm and Leaked Credentials Page: report the Leaked Credentials Detection violation in Event Log and send the Leaked Credentials Page Select Learning and Blocking Settings to configure them. For Sessions and Logins set Leaked Credentials Detection to Alarm and Block. The Honeypot Page and Leaked Credentials Page can be configured from Security > Application Security > Security Policies > Policies List Select the Leaked-Credential-Check Policy Select Response and Blocking Pages on the left. Scroll down and the Failed Login Honeypot response and Leaked Credentials response can be configured here. Test Leak Credentials Detection Attempt to login to your web application using known leaked credentials.In this example we’ll use “HACKAZON”.Click the Sign In link near the top on the right. Attempt to login using the following: Username: demo33@fidnet.com Password: mountainman01 The login should fail. Try to login with the following credentials: Username: admin Password: 12345678 Check the BIG-IP Event Log From the Configuration Utility go to Security > Event Logs > Application > Requests. There are two requests at the top that look important. Select the first one.Here we can see details about the request.As suspected, the violation was due to the Leaked Credentials Detection policy. Scroll down under Request and you can see the username and password that triggered the violation. Now select the second one.As you can see, this violation was triggered by the login attempt with the username “demo33@fidnet.com”. Conclusion Congratulations!You have successfully configured and test Leak Credential Checking.
iRule Limit the number of HTTP requests by a client within a specified time
This iRule block all the traffic from the clientes with the ip addresses listed inside the iRule, doesnt work like the logic code, can you help me to understand which is the issue with theiRule? when RULE_INIT { #This defines how long is the sliding window to count the requests. This example allows 10 requests in 1 seconds* set static::windowSecs 1 #IP Client address maximun request for each oneand the vlan id %819 for the partition set class::conn_limit_dg{ host 52.205.169.24%819 {"4"} host 52.205.60.156%819 {"4"} host 52.205.89.86%819 {"4"} host 71.201.163.113%819 {"4"} host 34.197.3.255%9819 {"26"} } } when CLIENT_ACCEPTED { #Max connections per client IP set limit [class match -value [IP::client_addr] equals conn_limit_dg] log local0. "[IP::client_addr]: \$limit: $limit" } when HTTP_REQUEST { #Check if client IP is in the connection limit data group and the request is a GET if { $limit ne "" and [HTTP::method] eq "GET"} { set getCount [table key -count -subtable [IP::client_addr]] log local0. "[IP::client_addr]: getCount=$getCount" if { $getCount < $limit} { incr getCount 1 table set -subtable [IP::client_addr] $getCount "" indefinite $static::windowSecs } else {log local0. "[IP::client_addr]: exceeded the number of requests allowed. $getCount / $limit" #HTTP header with connection limit exceed the count request HTTP::respond 429 content "Too Many Requests" } } }
How to check if a string parameter can be an IPv4 or an IPv6 or nothing in an iRule ?
How to deal with that question in the best optimized way to code it versus cycles ? "How to check if a string parameter can be an IPv4 or an IPv6 or nothing in an iRule ?" I have already looked at "IP::addr .... mask ...scan ..." without any simple efficient way. Some helps ? Some few lines ? or TCL function or undocumentated iRule command ? Many thanks :-)Quick check for TLS vulnerability CVE-2016-9244
Hi, to run a quick recursive search across all client-ssl profiles regarding vulnerability CVE-2016-9244 you can run the following one-liner: tmsh -q -c 'cd /; list ltm profile client-ssl one-line recursive' | \ grep -w 'session-ticket enabled' | grep -E --colour '(ltm profile client-ssl|session-ticket) [^ ]+' In case there is a (non-default) setting in an affected profile i.e. the following will be returned: ltm profile client-ssl Common/profile_lb-net.bit_clientssl { app-service none cert Common/cert_lb-net.bit.crt cert-key-chain { cert_lb-net.bit { cert Common/cert_lb-net.bit.crt key Common/cert_lb-net.bit.key } } chain none defaults-from Common/clientssl inherit-certkeychain true key Common/cert_lb-net.bit.key passphrase none session-ticket enabled } According to the Ask F5 solution the setting may be modified from WebUI in the affected client-ssl profiles advanced settings. To modify a vulnerable profile from CLI you may want to use i.e. the following syntax (make sure to set the trailing / in front of the admin partition: tmsh modify ltm profile client-ssl /Common/profile_lb-net.bit_clientssl session-ticket disabled tmsh save sys config partitions all Make sure to save the configuration and to config-sync. Thanks, Stephan PS: The setting for session-ticket (now disabled ) will remain in the partition specific bigip.conf.
