Technical Article

Security Irules 101: Engage Cloak!

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 section 3 of the series, let’s talk about cloaking. Those of you whose first response was “I canna doit captain, I doona hav the powe”, get a gold star for geek awesome. (Scratching you head? You need more Star Trek in your life!) But no, not that kind of cloaking. Here we are talking about server cloaking. Servers like to let everyone know who they are, what they do, what time they have, and what is for lunch. A raw server is a lot like the chatty human in the queue at the grocer, willing to tell you their life story.

Why is this bad?

Attackers aren’t just sitting on the internet launching random attacks at a whim. There is an entire portion of the process devoted to scouting (aka information gathering). An attacker wants to know as much as he/she can before they begin the assault. Server headers provide a lovely amount of information, if they are allowed to. The technique is often called “Banner Grabbing”, and essentially boils down to connecting to a service and seeing what banners(data) is returned. An FTP might return the application that is being used, smtp might tell you what version its at, and HTTP… HTTP can tell you many a things.

Example:

# echo -e "HEAD / HTTP\1.1\r\nhost:1.1.1.1\r\n\r\n"|nc 1.1.1.1 80

All this does is opens a Netcat connection to the server on port 80, and sends over a simple head request

What does an attacker do next? I grab the server and go to exploit-DB and see what vulnerabilities might be publically known for the application. The banner grab has made the attackers life easier, and no security monkey wants to do that.

iRule Response:

We can use an iRule to implement a good positive security model. First we want to define what we should allow the headers to show. To do that, let’s create a datagroup called allowed_headers:

You can also restrict HTTP Response Headers with the LTM HTTP Profile.Use the "Response Headers Allowed" flied to specify a whitespace delimeted list of allowed headers. Of course you wouldn't have any logging, but it's faster.