Block IP Addresses With Data Group And Log Requests On ASM Event Log
Problem this snippet solves: This is Irule which will block IP Addresses that are not allowed in your organization. instead of adding each IP Address in Security ›› Application Security : IP Addresses : IP Address Exceptions you can create a data group and use a simple IRULE to block hundreds of Addressess. Also,createing a unique signature to specify the request of the illigile IP Address. First, You will need to create Data Group under Local Traffic ›› iRules : Data Group List and add your illigile IP Addresses to the list. If you have hundreds of IP's that you want to block, you can to it in TMSH using this command: TMSH/modify ltm data-group internal <Data-Group-Name> { records add {IP-ADDRESS} } Now, We are ready to create the IRULE under Local Traffic ›› iRules : iRule List Last, Create violation list under Security ›› Options : Application Security : Advanced Configuration : Violations List Create -> Name:Illegal_IP_Address -> Type:Access Violation -> Severity:Critical -> Update Don't forgat to enable trigger ASM IRULE events with "Normal Mode" How to use this snippet: Code : when HTTP_REQUEST { set reqBlock 0 if { [class match [IP::remote_addr] equals ] } { set reqBlock 1 # log local0. "HTTP_REQUEST [IP::client_addr]" } } when ASM_REQUEST_DONE { if { $reqBlock == 1} { ASM::raise "Illegal_IP_Address" # log local0. "ASM_REQUEST_DONE [IP::client_addr]" } } Tested this on version: 13.0
Format objectGUID attribute from hexadecimal to bindable string (hyphen-separated format)
Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’. Short Description Format objectGUID attribute from hexadecimal to bindable string (hyphen-separated format) Problem solved by this Code Snippet Claims recipients might require an Active Directory objectGUID to be represented as a bindable string (hyphen seperated format). The code snippet will help you to format the received objectGUID attribute from Active Directory from hexadecimal format "0xDE96F75DA1E135438C0F229A952D1432" to bindable string format "5df796de-e1a1-4335-8c0f-229a952d1432" How to use this Code Snippet In the VPE: add a "Variable Assign" item after the "AD Query" or "LDAP Query" used to get the "objectGUID" attribute in the left-side choose "custom variable" and choose a variable name. For example "session.sso.token.custom.formatedObjectGUID" in the righ-side choose "custom expression" and paste the code below Code Snippet Meta Information Version:1.0 Coding Language:TCL Full Code Snippet set hexGUID [mcget {session.ad.last.attr.objectGUID}] set substr1 "[string range $hexGUID 8 9][string range $hexGUID 6 7][string range $hexGUID 4 5][string range $hexGUID 2 3]" set substr2 "[string range $hexGUID 12 13][string range $hexGUID 10 11]" set substr3 "[string range $hexGUID 16 17][string range $hexGUID 14 15]" set substr4 "[string range $hexGUID 18 21]" set substr5 "[string range $hexGUID 22 33]" return "[string tolower "$substr1-$substr2-$substr3-$substr4-$substr5"]"POC: Create and sign a JWT with iRule
Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’. Short Description This snippet creates and signes a JWT. Signing algorithm is RS256. Problem solved by this Code Snippet This is a simple way to create a valid JWT for testing purposes. How to use this Code Snippet Add a private key Assign it to a VS and request "/jwt" to get a signed token Code Snippet Meta Information Version: POC Coding Language: TCL Full Code Snippet https://github.com/JuergenMang/f5-irules-jwt/blob/main/jwt-signPOC: Validate JWT with iRule
Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’. Short Description This is a proof of concept iRule to decode and validate a JWT submitted in the HTTP Authorization header. It supports only JWT's signed with RS256 and was roughly tested with Azure, Okta and ADFS tokens. It is not designed for production usage, especially there are more checks required to comply with https://datatracker.ietf.org/doc/html/rfc7519#section-7.2. Problem solved by this Code Snippet Decode and validate a JWT with an iRule. How to use this Code Snippet Attach it to a VS and adapt the public key(s) and key id(s). Code Snippet Meta Information Version: POC Coding Language: iRule Full Code Snippet https://github.com/JuergenMang/f5-irules-jwt/blob/main/jwt-validate
CitrixBleed Mitigation CVE-2023-4966
Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’. Short Description The Citrix Bleed exploit https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4966against Netscaler ADC and Netscaler Gateway is being seen in the wild and impacting many organisations https://www.malwarebytes.com/blog/news/2023/11/citrix-bleed-widely-exploitated-warn-government-agencies. If you have a BIG-IP providing access to your Citrix platform, you can gain visibility of this explit and potentially mitigate malicious requests. Problem solved by this Code Snippet This iRule will catch requests to the exploit URL and create a log and iStat, and potentially drop malicious requests where the Host header is set to be a large length. How to use this Code Snippet Create the iRule and assign it to the virtual server in front of the Citrix device. Code Snippet Meta Information Version: TMOS v11+ Coding Language: iRule Full Code Snippet when RULE_INIT priority 500 { # This is an iRule to be used to capture and possibly mitigate against known Citrix Bleed attacks # https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4966 # There is no support implied in using this iRule, you use it at your own risk # Version 1 Peter White # Note that all requests to /oauth/idp/.well-known/openid-configuration will be logged in /var/log/ltm for later checking of source address etc # and all requests with a hostname of more than 100 characters will be assumed to be malicious # Set the variable below to 1 or 0 to turn on blocking of known malicious requests set static::cb_block 1 # Set the host header max length. Note that the PoC uses a length of 24576 set static::cb_host_max_length 100 # Log prefix - set the log prefix for the warning logs for this iRule set static::cb_log_prefix "CB" } when HTTP_REQUEST priority 100 { if { [HTTP::path] equals "/oauth/idp/.well-known/openid-configuration" } { log local0.warn "$static::cb_log_prefix [virtual name] [IP::client_addr] [TCP::client_port] [whereis [IP::client_addr] continent] [whereis [IP::client_addr] country]" # Note that you can see the iStat using the command 'tmsh show ltm virtual <virtual server name>' and look at User-defined stats at the bottom ISTATS::incr "ltm.virtual [virtual name] counter CB_log" 1 if { $static::cb_block && ([string length [HTTP::header Host]] > $static::cb_host_max_length) } { drop } } }
After applied ASM Policy to Virtual Server, connections will reset with Internal error in log
Whether the ASM policy is in Transparent mode or Blocking, when applied to Virtual Server, the connection is reset. The packet captures shows: Internal error (ASM requested abort (plugin abort error))] tmm1[29648]: 01230140:3: RST sent from *.*.*.*:443 to *.*.*.*:51570, [0x223b824:820] Internal error (ASM requested abort (plugin abort error)) However, when I remove the ASM policy from the VS , the service works fine. Has anyone had any experience getting this sort of setup working? TMOS Version : 16.0.1iRule to modify a content-security-policy header
Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’. Short Description This short iRule snippet can change specific directives in a content-security-policy header. The script is only roughly tested, but maybe we can improve it together. Full Code Snippet when HTTP_RESPONSE_RELEASE priority 800 { # init set csp_fields "" set csp(directives) "" set csp(values) "" # configure lappend csp(directives) "frame-ancestors" lappend csp(values) "*" # iterate through directives from backend set org_csp_fields [split [HTTP::header Content-Security-Policy] ";"] foreach field $org_csp_fields { set directive [getfield [string trim $field] " " 1] set idx [lsearch -exact $csp(directives) $directive] if { $idx > -1 } { # append enforced value lappend csp_fields "$directive [lindex $csp(values) $idx]" } else { # append original value lappend csp_fields $field } } # add missing directives set i 0 foreach field $csp(directives) { set idx [lsearch -glob $csp_fields "${field}*"] if { $idx == -1 } { # missing, add it lappend csp_fields "${field} [lindex $csp(values) $i]" } incr i } # replace the header HTTP::header remove Content-Security-Policy HTTP::header insert Content-Security-Policy [join $csp_fields "; "] }Python script to test if a F5 BIG-IP is vulnerable to cve-2023-46747
Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’. Short Description Python script to test if a F5 BIG-IP is vulnerable to cve-2023-46747 Problem solved by this Code Snippet This script can help to determine if a F5 BIG-IP is vulernable toK000137353: BIG-IP Configuration utility unauthenticated remote code execution vulnerability CVE-2023-46747. How to use this Code Snippet Download the script and run it with Python 3. This script takes as input the F5 BIG-IP management IP-adres. $ ./test_cve-2023-46747.py 10.23.92.6 Connecting to 10.23.92.6:443. Connected to 10.23.92.6:443. Send HTTP-request trying to add an account. Try to login with new account. Login successful. Server 10.23.92.6 is vulnerable to CVE-2023-46747. $ Code Snippet Meta Information Version: 0.1 Coding Language: Python Full Code Snippet https://github.com/nvansluis/test_cve-2023-46747APM Kerberos Auth or fallback to another authentication method
Problem this snippet solves: This iRule can be used when it is required to offer both Kerberos authentication and for example SAML or another authentication method in a mixed environment for devices that are domain joined and devices that are not domain joined. This iRule uses javascript and HTML5 Web Workers to determine if the browser can successfully authenticate by using Kerberos or will need to fallback to another authentication method. I've been testing this iRule with Internet Explorer, Edge, Firefox and Chrome. All these browsers seem to be working fine. Only Chrome seems to do things a bit differently and is showing a login prompt for a split second, but it's working. How to use this snippet: The screenshot below shows an example of an Access Policy that uses either Kerberos or SAML authentication. The first agent in the policy is an 'Empty Agent' which will read the session.custom.domainjoined variable to determine which authentication method to use. The session.custom.domainjoined variable is set by the kerberos_auth_or_fallback_auth iRule. Tested this on version: 13.0 Link to iRule https://github.com/nvansluis/f5.kerberos_auth_or_fallback_auth
