Apache Log4j2 (CVE-2021-44228) mitigation iApp
Problem this snippet solves: There is a CVE released related to Apache log4j, which could be a vulnerability on a server located behind the BIG-IP. F5 SIRT have helpfully created an iRule to mitigate this vulnerability, this is an iApp to simplify creation and management of the iRule. How to use this snippet: Install the iApp Template Download and unpack the archive Login to BIG-IP TMUI and navigate to iApps>Templates Hit Import button, select the template and hit Upload Create an iRule instance Navigate to iApps>Application Services>Applications Hit Create button, enter a relevant Name and select the log4j2_mitigation template Set the Debug Level ( Off, Attack or Debug ). Off = no logs, Attack = logs in the case of an attack detected, Debug = more detailed logs Hit Finished - iRule should be created Assign iRule to virtual server Navigate to LTM>Virtual Servers. Click on the Virtual Server, navigate to Resources tab Click Manage button under iRules section, add iRule. Note the Virtual Server must have an assigned http profile for this iRule, otherwise it will throw an error. Manage iRule If you have issues with the iRule or want to modify logs, navigate to iApps>Application Services>Applications and click on the deployed service. Navigate to the Reconfigure tab, make changes and hit Finished Tested this on version: 15.1
Apache Style Logging with HSL
Problem this snippet solves: When SNATing to servers, the client IP is lost. This was information our security group and developers wanted to have available, so I created an iRule to use the HSL functionality in BigIP 10 to do that. Without cracking open the HTTP stream, I was unable to get the REMOTE_USER CGI variable, so I used that field to log the HTTP::host instead (since that information is lost with several VIPs logging to the same location). Code : # Apache: ClientIP - Username 10/Oct/2000 # iRule: ClientIP - Host 10/Oct/2000 when CLIENT_ACCEPTED { set hsl [HSL::open -proto UDP -pool syslog.example.com_syslog_pool] set clientip [IP::remote_addr] } when HTTP_REQUEST { set method [HTTP::method] set uri [HTTP::uri] set host [HTTP::host] } when HTTP_RESPONSE { set now [clock format [clock seconds] -format "%d/%b/%Y:%H:%M:%S %z"] set contentlength [HTTP::header "Content-Length"] # Log HTTP request via syslog protocol as local7.info; see RFC 3164 for more info # local7 = 23; info = 6; 8*23 + 6 = 190 HSL::send $hsl "<190> $clientip $host - $now \"$method $uri HTTP/[HTTP::version]\" [HTTP::status] $contentlength\n" #log local0. "<190> $clientip $host - $now \"$method $uri HTTP/[HTTP::version]\" [HTTP::status] $contentlength" } Tested this on version: 10.2
Apache mod_auth_tkt Single Sign On
Problem this snippet solves: This iRule is designed to parse and verify the digest from a auth_tkt cookie. This is a proof-of-concept that can be leveraged to offload authentication and/or verification from the apache servers when used in conjunction with the LTM authentication module. Using "AUTH::response_data", you can include additional tokens from the authentication server in the cookie that can help LTM to make more intelligent load-balancing decisions based on the users. As these cookies are unique per user, you can use them as a source of persistence information as well. If performance is a must, you can use the session table to cache verified cookies and store necessary information about the authenticated user and look them up by hash. This session entry could be used to maintain a precision based inactivity timeout as well. Code : rule mod_auth_tkt { when RULE_INIT { set cookie_name "auth_tkt_sso" set secret "auth_tkt_shared_secret" set tokens "AUTH_TKT_TOKEN1,AUTH_TKT_TOKEN2" set data "" } when HTTP_REQUEST { if { ! [HTTP::cookie exists $::cookie_name] } { return } set cookie [HTTP::cookie $::cookie_name] set ticket [b64decode $cookie] scan $ticket {%32s%8s%[^!]!} master_digest time_stamp user_id set rawip "\000\000\000\000" set rawts [binary format H* $time_stamp] binary scan $rawts H* rets set rawstring $rawip$rawts$::secret$user_id\000$::tokens\000$::data binary scan [md5 $rawstring] H* digest0 binary scan [md5 $digest0$::secret] H* digest if { $digest ne $master_digest } { reject } } }
