Forum Discussion

Thomas_Schocka1's avatar
Thomas_Schocka1
Icon for Altocumulus rankAltocumulus
Nov 12, 2014

A Protocol Profiler In a Few iRules

Protocol Profiler

Hi everyone,

 

In light of all the "packets you don't want on your F5 anymore" like TLS Heartbeat messages, certain TLS Cipher Suites, certain DNS messages, etc., etc.,... I have created something I dubbed a "protocol profiler". It's a longshot, and I'm pretty certain nobody will give it a try, but if you're curious, read on :)

 

I must warn you, it's not your average iRule-to-go; if you're bold enough to want to see it in action, you'll probably have a hard time setting it up the first time. I've included a rough step-by-step process below.

 

What is it?

It's a protocol mapper that allows you to log/drop/reject/... based on any and all fields of any L5/6/7 protocol, without having to attach a protocol profile to the virtual server. The code is fairly well documented, but definitely not optimized for speed or efficiency, although I did run a full 100Mbit of continuous HTTPS POST connections through it, without crash/block/slowdown on a virtual edition. It is probably way to complex to ever put in production, but I'm having fun creating it, so if you're an iRule geek, try it out. :D

 

What is it good for?

A lot, and nothing at the same time. You can log, drop, reject, create statistics,... based on any and all fields of any protocol. Below are a few examples of possible usecases:

 

  • F5 has no IMAP, POP3, IMAPS, ... profiles. You could create a protocol map that allows you to loadbalance based on recipient email address, or implement a "poor man's mail firewall".
  • If you want to know which TLS Cipher Suite your F5 uses most in its ServerHello responses to clients, you can make this iRule log just that field.
  • If you want to know how many people still connect to your F5s using SSLv3 in comparison to the other versions.
  • You can protect the F5's or your backendserver's SSL/TLS-stacks by dropping connections based on something you detect on the wire, even before the F5 starts speaking SSL/TLS. Some examples of this are 'dropping connections using TLS heartbeat messages' or 'dropping connections from clients that support old/insecure/disallowed ciphers'.
Hoe does it work?
  • You describe a protocol in an array of hierarchical indexes.
  • Each described field has a name, a length and a decoder-type.
  • Fields can be grouped into containers.
  • Each field can be used as reference for the lengthvalue in bytes of another field in the tree.
  • Each field can be used as marker for another container in the protocol-tree. (Example: in TLS, there is a certain field that says if the record is a ClientHello or ServerHello; the value of this field is matched with the actual data, so the algorithm can continue mapping the correct part of the tree)
  • The decoder types are actually references to procedures, so you can interpret any piece of the data the way you want. For example: 'represent the field's datavalue as a readable string', or 'parse the next 20 bytes as a DNS A query'. Decoders are created in the iRule named 'ProtocolProfilerDecoders'.
How do I use it?
  • It uses the TCL's 'proc' feature, so make sure you have v11.4 or better.
  • Upload all the attached iRules to your F5.
  • The iRules with names starting with 'ProtocolProfiler' are libraries, just upload them, let them sit.
  • You will need to make the traffic pass through an 'analyzer virtual-server' first. The iRule linked to this analyzer virtual server allows you to set the name of the 'real' virtual-server to which it needs to forward the traffic post-analysis.
  • The iRules with names starting with 'rule_' are the iRules you link to the 'analyzer virtual-servers'.
  • This means that you need to change the original destination IP of the real virtual server to something 'useless' like 1.1.1.1 and use the original destination IP as destination IP on the analyzer virtual-server. This way, the traffic is received by the analyzer and the iRule linked to that analyzer makes sure the traffic is sent to your own virtual server with irules, profiles, persistence stuff and pool.
  • In the CLIENT_ACCEPTED event of the iRule that you linked to the analyzer virtual-server you'll find a 'virtual ' statement. change the to the name of your real virtual server. This is the 'thing' that forwards traffic to your original virtual server, regardless of its destination address.
  • I created a (good but incomplete) map for SSLv3/TLSv1.x and a very incomplete map for DNS; but it demonstrates the iRule's 'power'.
  • You can link the rule_sslprofiler.tcl iRule to your analyzer virtual-server and watch the magic happen.
  • For the lazy, here are some tmsh commands to set you up (beware though, modifying the real virtual server to another destination IP will render it useless until you add the next virtual server with correct iRule) tmsh modify ltm virtual vs_real-virtual-server { destination 1.1.1.1:443 } tmsh create ltm virtual vs_analyzer-virtual-server { destination 11.11.11.12:443 profiles add { tcp } rules { rule_sslprofiler }}
  • With the last command executed, modify the iRule rule_sslprofiler to have the CLIENT_ACCEPTED event contain a statement "virtual vs_real-virtual-server"; remove any other 'virtual' statements.
The code, the code, where is the code? Is this going anywhere?
  • No, not really, it's a fun project and can teach you a lot about the underlying protocols and iRules in general.
  • I'm not far off making it capable of decrypting 'normal' TLS on the wire, provided RSA key exchange is being used. The code can see both client- and server-random values, the public key for the server and the encrypted premaster secret; one could feed it the server's private key and generate the keys necessary to decrypt the data, much like Wireshark does, by using PMS-files or the actual private keys. Imagine that: no SSL profiles, no SSL offloading, full visibility, totally useless, but epically cool! :) Look ma' no profiles!

Greets,

 

Thomas Schockaert

 

3 Replies

  • Very impressive work Thomas! A few of us are checking out your code examples.

     

    Thanks, Aaron

     

  • Very cool! It'll take me a while to dig in but very nice work. Would love to hear community feedback on this one!
  • Hi Aaron,

     

    Thanks! Jason Rahm asked me to create some sort of design-thingy around the howto, but I haven't found the time yet. I like how there are actually people digging into it... Imagine having a profile that implements the code's functionality... like LTM policies did with a lot of things you used to need an iRule for; this functionality with a GUI would be epic.

     

    I must admit though... I'm pouring it into an iApp that'll allow you to choose the fields on which to take action... experimenting never stops :D

     

    Greets,

     

    Thomas Schockaert