Security iRules 101: Logging, why we do it?

Introduction

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?

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

Can we iRule that?

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"> </form>

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

when HTTP_REQUEST {
   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]"
}
when SERVER_CONNECTED {
    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: 192.168.0.1:1031 To 172.22.0.1:80 Request: GET acmebank.com/bob.php  Payload:

 

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

 

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

 

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

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 10.10.1.30:5678 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]
}
when HTTP_REQUEST {
   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.