Security iRules 101: Logging, why we do it?


iRules are a powerful tool in the F5 administrators arsenal. They allow administrators to adapt and customize the F5 to their needs.  They provide extensive power for security engineers as well. We’ve decided it’s time to revisit the Security iRules 101, with updated content, and 100% more monkeys!

In our first section of the series, we are going to cover a vital part of the security infrastructure, logging. Good logs make all the difference for identification and prevention of attacks. We have to know we are under attack, before we can respond to it.

What’s in a Security Log?

This is often the hardest part of building a security logging profile. What should we log?  In a perfect world, we would log every bit that comes across the wire in an perfectly secure storage device.  But the worlds not perfect, and we have limitations. Limited storage space, limited logging capabilities, limited bandwidth. To work within these limitations, we have to build a baseline of log data to include in all logs.

What data is always useful for a security engineer, no matter the application?

Date and time of request

Any forwarding Data we can get

Source and Destination (IP and port)

Actions of the request

These four basic items should be a part of every log entry being used.

Can we iRule that?

Can an iRule log these items? Of course we can, and more!  Let’s prove it.  I highly recommend taking a moment to read Colin Walkers “iRules – Logging and Comments” tech tip, as we will reference many of the commands discussed there.  Let’s set the scene. 

Application: Bank transfer

Protocol: HTTP

<--Code Snippet—>
<form name="transfer" action="transfer.php" method="post">
Transfer to:    <input type="text" name="who"><br>
Transfer amount:<input type="text" name="amount"><br>
<input type="submit" value="Send Money">

Each time someone submits a transfer request, we want to record all the relevant data.  For round one, we start with a local logging:

   log local0. " Client Request: [IP::client_addr]:[TCP::client_port] To [IP::local_addr]:[TCP::local_port] Request: [HTTP::method] [HTTP::host][HTTP::path]  Payload: [HTTP::payload]"
    log local0. "[IP::client_addr]:[TCP::client_port] Sent to server:[IP::server_addr]:[TCP::server_port]"

Breaking it down,  the rule looks for HTTP Requests. When they occur, it grabs all the relevant data it can, and sends it into a local logging facility.  The logs look something like this(/var/log/ltm):

Nov  1 03:42:33 tmm info tmm[7215]: Rule /Common/htttp-logger <HTTP_REQUEST>:  Client Request: To Request: GET  Payload:


Nov  1 03:42:33 tmm info tmm[7215]: Rule /Common/htttp-logger <SERVER_CONNECTED>: Sent to server:


Nov  1 03:42:48 tmm info tmm[7215]: Rule /Common/htttp-logger <HTTP_REQUEST>:  Client Request: To Request: POST  Payload: who=monkey+george&amount=5%2C000.00


Nov  1 03:42:48 tmm info tmm[7215]: Rule /Common/htttp-logger <SERVER_CONNECTED>: Sent to server:

This has allowed us to log all the requests coming over.  But who wants to keep their log local? A quick change, and we start popping all the logs over to our central log server (In our case, netcat –u(udp) –l(listen) 5678(port):

With the modification of log rule:

  log local0. " Client Request: [IP::client_addr]:[TCP::client_port] To [IP::local_addr]:[TCP::local_port] Request: [HTTP::method] [HTTP::host][HTTP::path]  Payload: [HTTP::payload]"

High Speed Remote Logging

Is just normal remote logging good enough for us?  Heck no, we want more power! This is were High Speed Logging comes it.  The HSL allows us to send the log data out to the log servers at an extremely high speed.  It takes a little more configuration in the iRule, but it's very much worth it.

when CLIENT_ACCEPTED {        
    set hsl [HSL::open -proto UDP -pool syslog_server_pool]
   HSL::send $hsl " Client Request: [IP::client_addr]:[TCP::client_port] To [IP::local_addr]:[TCP::local_port] Request: [HTTP::method] [HTTP::host][HTTP::path]  Payload: [HTTP::payload]"

With the high speed logging, we need to create a syslog pool and declare it in the set hsl variable.  A side benefit to the HSL, is that it sends the log message in the exact format we specify, with none of the TMM Prefix.

There is a lot of power that stems from these simple iRule commands. As a security engineer, we can build out some terrific, tailored logging messages, to provide useful data. We can also standardize the logs (akin to w3c format) to any format our SIEM may require.  With these tools, we can make sure our log monkeys are being put to good use:
Published Oct 31, 2012
Version 1.0

Was this article helpful?

No CommentsBe the first to comment