Today, we're going to delve into a particularly useful iRule that enables the logging of HTTP request and response headers. This functionality can be invaluable for troubleshooting, monitoring, and security analysis.

Understanding the iRule

The iRule provided captures HTTP request and response headers and logs them for analysis. Let's break down its structure:

HTTP_REQUEST {
   set LogString "Client [IP::client_addr]:[TCP::client_port] [TCP::local_port] -> [HTTP::host][HTTP::uri]"
   log local0. "#DEBUG# ============================================="
   log local0. "#DEBUG# $LogString (request)"
   foreach aHeader [HTTP::header names] {
      log local0. "#DEBUG# $aHeader: [HTTP::header value $aHeader]"
   }
   log local0. "#DEBUG# ============================================="
}
when HTTP_RESPONSE {
   log local0. "#DEBUG# "
   log local0. "#DEBUG# ============================================="
   log local0. "#DEBUG# $LogString (response) - status: [HTTP::status]"
   foreach aHeader [HTTP::header names] {
      log local0. "#DEBUG# $aHeader: [HTTP::header value $aHeader]"
   }
   log local0. "#DEBUG# ============================================="   
}
💡
Note the starting "#DEBUG#" at the beginning of each log line.
I have used this to avoid mixing these debug logs with the system ones. Take a look at my old post: https://somoit.net/f5/f5-bigip-send-logs-to-custom-syslog-file/
  • HTTP_REQUEST Block: This block is triggered whenever an HTTP request is received. It constructs a log string containing information about the client, ports, host, and URI. Then, it iterates over each HTTP header, logging its name and value.
  • HTTP_RESPONSE Block: Similarly, this block is triggered upon receiving an HTTP response. It logs the same client information along with the response status and iterates over response headers for logging.

Example

This is how the result looks like:

#DEBUG#  ====================== Request Headers ============================
#DEBUG# Client xxx.xxx.xxx.xxx:60749 443 -> <URL> (request)
#DEBUG# sensorid: 4148
#DEBUG# Host: <DOMAIN>
#DEBUG# Accept: text/html,*/*
#DEBUG# User-Agent: Mozilla/5.0 (compatible; xxxxxxxxxxx; Windows)
#DEBUG# Proxy-Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
#DEBUG# X-Forwarded-For: xxx.xxx.xxx.xxx
#DEBUG# X-Forwarded-Proto: https
#DEBUG# Access-Control-Allow-Credentials: true
#DEBUG# =============================================

#DEBUG#  ====================== Response Headers ============================
#DEBUG# Client xxx.xxx.xxx.xxx%1:60749 443 -> <URL> (response) - status: 200
#DEBUG# Cache-Control: no-cache, must-revalidate, no-transform, no-store
#DEBUG# X-XSS-Protection: 1; mode=block
#DEBUG# X-Frame-Options: SAMEORIGIN
#DEBUG# Referrer-Policy: no-referrer
#DEBUG# Content-Security-Policy: frame-src 'self'; frame-ancestors 'self'; object-src 'none';
#DEBUG# Date: Tue, 12 Mar 2024 15:04:19 GMT
#DEBUG# Connection: keep-alive
#DEBUG# X-Robots-Tag: none
#DEBUG# Strict-Transport-Security: max-age=31536000; includeSubDomains
#DEBUG# X-Content-Type-Options: nosniff
#DEBUG# Content-Type: text/html;charset=utf-8
#DEBUG# Content-Length: 2740
#DEBUG# =============================================

Conclusion

Custom iRules like the one we've explored here exemplify the power and flexibility of the F5 BIG-IP platform. By logging HTTP request and response headers, administrators can gain valuable visibility into traffic patterns, diagnose issues efficiently, and enhance security posture.

Do you use custom iRules in your F5 deployments? Share your experiences and insights in the comments below!