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 Response from server: HTTP/1.1 200 OK Date: Thu, 15 Nov 2012 21:37:32 GMT Server: Apache/2.2.20 (Ubuntu) Last-Modified: Tue, 25 Sep 2012 10:33:29 GMT ETag: "a2b54-b1-4ca843cb6ebf3" Accept-Ranges: bytes Content-Length: 177 Connection: close Content-Type: text/html Request was successful Date: Time on the Server (is their NTP Skewed?) Server: Actual Server data/version Last-Modified: Last time page was changed ETag: Entity Tag for the resource requested Accept-Ranges: Accept Range Request, size of request Content-Length: Length of content Connection: Connection keep alive? Content-Type: Whats in the payload 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: ltm data-group internal /Common/allowed_headers { records { Accept-Range { } Cache-Control { } Content-Encoding { } Content-Length { } Content-Type { } ETag { } Last-Modified { } Pragma { } Set-Cookie { } } type string } These are pretty basic header options (most used in caching, etc). Part two of the equation is the rule itself: when HTTP_RESPONSE { foreach Headr [HTTP::header names] { if {not ([class match $Headr contains allowed_headers])}{ log local0. "Removing: $Headr: [HTTP::header value $Headr]" log local0. "Header: $Headr" HTTP::header remove $Headr } } } That’s it. A loop that goes through each header name in an HTTP_Response and looks for headers that are not on the allowed list. If it’s not on the list, we strip it out. In practice: BEFORE iRule After iRule HTTP/1.1 200 OK Date: Thu, 15 Nov 2012 21:37:32 GMT Server: Apache/2.2.20 (Ubuntu) Last-Modified: Tue, 25 Sep 2012 10:33:29 GMT ETag: "a2b54-b1-4ca843cb6ebf3" Accept-Ranges: bytes Content-Length: 177 Connection: close Content-Type: text/html HTTP/1.1 200 OK Last-Modified: Tue, 25 Sep 2012 10:33:29 GMT ETag: "a2b54-b1-4ca843cb6ebf3" Accept-Ranges: bytes Content-Length: 177 Content-Type: text/html Clean, clear and under control. I think the monkey board sums it up rather nicely:Security Irules 101: You can't always get what you want.. or can you?
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 2 of the series, we are going to talk about controlling our HTTP. Browser based web communication use the power of RFC 2616 (this plus many others) to tell browsers how to get data and what to do with it. A browser uses a defined set of methods to communicate its needs to the servers. The basic set of methods, defined in RFC 2616.9.0 are (in basic humanese): OPTIONS: Request the server tell you what methods are allowed, as well as other optional features implemented on the server GET: Client is asking the server to return a resource/information. HEAD: Just give the client the headers, no message body. POST: Sending data into the server that you expect it to do something with. Posting a message, logging in, etc. PUT: Take what the client sends, and store it. Example here is old school file transfer. DELETE: Please delete what’s at the URI. Pretty please? There is not guarantee that the deletion is honored. TRACE: Trace my request all the way back to the origin server, and tell me where it went. Not a good thing to allow, as it gives out path information. (read: don’t let that be used publically.. ever) CONNECT: Reserved by the original RFC to use with dynamic tunneling. Is that all? Heck no. Check out: Anne’s Blog for a list of some of the lesser known methods. Why do we care? So why do we care about what methods are allowed into a server? If the application team hasn’t taken due diligence with the app (which never happens of course) or the server team just slapped a webserver up and haven’t gotten around to finishing that last bit of configuration. Do we sit around and wait for things to get fixed? Hell no, we charge on! Roll in the iRules We know that iRules can read and effect near every bit and byte that comes across the F5, so what can we do for HTTP method limiting? The amount of built-in HTTP commands in iRules is pretty fantabulous. Pretty much every portion of the HTTP payload is accessible, as seen in the HTTP Wiki on Devcentral. For the matter at hand, we are looking towards HTTP::method. It simply returns the method from the HTTP request. when HTTP_REQUEST { log local0. "HTTP Method: [HTTP::method]" } We could just build a one off iRule to block based on methods hard coded into the rule. That means that anytime we need to add or remove a method from the rule, we have to edit the rule. Meh, I hate having to change variables in the rules, so let’s think. What can an iRule access on the F5, that stores values, and is changeable via the GUI? You got it, it’s data groups time . The rule: when HTTP_REQUEST { if { [class match [string tolower [HTTP::method]] contains disallowed_methods] } { log local0. "BAD METHOD!!! [HTTP::method] -" } The datagroup: ltm data-group internal disallowed_methods { records { post { } } type string } So, here we just log posts to the webserver locally to the F5. Using a Class Match command we compare a lower case version of the method versus the entries in the datagroup disallowed_methods. It’s good, but we can do better, with a positive security model. ltm data-group internal allowed_http { records { get { } post { } } type string } ltm data-group internal allowed_nonhttp { records { copy { } lock { } mkcol { } move { } propfind { } proppatch { } unlock { } } type string } when RULE_INIT { set static::Servers { <html> <head> </head> <body> <p>Disallowed HTTP Method< /p> </body> </html> } } when HTTP_REQUEST { if { [class match [string tolower [HTTP::method]] contains allowed_nonhttp] } { log local0. "Good, but no http!! -- [HTTP::method] --" HTTP::disable return } if { [class match [string tolower [HTTP::method]] contains allowed_http] } { log local0. "Good request [HTTP::method]" return } HTTP::respond 405 content [subst $static::Servers] } So in this Rule, we create a Response page (set Servers variable). Then, on every HTTP_REQUEST, we look for our allowed_nonhttp methods, then look for allowed_http methods. If we don’t match either of them, respond back with the 405 “Method Not allowed” page, from the F5 Platform. How is it a positive security model? Well, it defines what we want to allow through, and everything else, gets dropped to the 405. Why is this nice? Because we can just define the methods we want to allow, not each method we don’t want. It makes it simpler to manage, as new methods come out, we don’t have to update the datagroups. Conclusion A quick iRule that improves the security posture of a web property. We used the power of the data groups, quick HTTP rip aparts, and the ability to return web pages from the platform directly, to quickly solve any METHODS issues.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? 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"> </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. Conclusion 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:Security Irules 101: DNS Gravitational Disturbance
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 4 of the series, let’s talk about DNS. Domain Name System is the address book of the internet. Any time you type letters into a browser and hit enter, some form of DNS action is happening, whether it grabs the IP from local cache or sends out requests to the far corners of the tubes to get the address it needs to go to. I won’t bore you with a long winded DNS lesson. DNS boiled down: Clients ask “Where the hell is devcentral.f5.com” DNS Server responds either “Here: response ” or “ I don’t know” Why do we care about DNS? So, why do we, as security admins care about DNS? DNS is a quick way to implement a layer of control in your network. If your network architecture includes an internal DNS resolver (DNS server that will resolve all requests for internal clients), you could potentially drop all DNS requests headed outside your network that are not sourced from that resolver. What does that get you? Well, if client machines can’t query any DNS servers outside of the internal network, you gain control (not complete, there are always ways around it.. ahem host files.. ahem) over the DNS world. With control of DNS, you can manage what domains resolve for your clients, which in turn can help control acceptable use policy and malware. How does controlling DNS help? Acceptable use policy Working from a negative enforcement security policy (because it could be darn near impossible to create a DNS whitelist for most user browsing), we create a list of domains that we don’t want clients to access. This can be a big task and you are never going to get them all. An example for acceptable use policy list might be: socialmediasite.com .xxx bobssitethatisNSFW.com Malware: Malware lists are dynamic and do better with proper care and feeding. You can get a good start by using something akin to: http://mirror1.malwaredomains.com/ With that data, we would create a data group akin to: “.sacklunch.com” := “harmful”, “.evilmalwaresite.com” := “morrisworm”, “.xxx”:=”adult materials” So, now our clients have no DNS options other than the authorized internal LDNS and we have lists of domains that we don’t want clients to access, what’s next? Well, it wouldn’t be an iRules series without the iRule eh? Much thanks to Hugh O’Donnell and Jason Rahm for the following amazing DNS rules. The iRule Way *Caveat* For the LTM iRule solution below, the DNS Services module or the GTM module is required to be licensed. These frames redirect to the iRules codeshare housing the most up to date version of the code. <p></p> </td> </tr> </tbody></table></div></p></div> </div> </cke:body> </cke:html> Essentially, this rule looks for DNS queries coming into the unit, rips out the question, checks against the naughty list and reacts. If it’s on the naughty list, the requester is given a DNS answer that points them to a simple response server (in our case, hosted on the LTM). If the question is not on the list, it gets allowed through. Check out the response page code below: With these two simple rules, the LTM extends itself to acting as a DNS filtration system. Another slick day in DNS paradise.
