SSL and network monitoring aren’t the most compatible of partners – even with the most sophisticated detection infrastructure in the world, you’ll not derive many useful indicators from the barren randomness of encrypted traffic. Consider the plight of the Sguil sensor shown below: 
The webserver’s use of SSL means that network-based incident detection is problematic. No amount of tuning of the sensor’s Snort instance will help it detect intrusion attempts – the only traffic it will see is HTTPS. Also, if an incident is detected by other means (e.g., customer notification, web server log file monitoring, etc.) the investigative value of Sguil’s full packet capture is greatly diluted. There are a number of ways to get back the visibility stolen by SSL, including the following. You could: Terminate the SSL “in front of” the webserver, perhaps on a reverse-proxying loadbalancer or web application firewall. You can then monitor the decrypted traffic between the loadbalancer and the webserver.
Perform monitoring tasks on the webserver itself, perhaps by increasing the level of web and application logging.
Give your existing sensor platforms the means to decrypt the SSL sessions.Each approach has its pros and cons; this article will show you how to leverage the latter technique to restore the eyesight of your blind Sguil sensors.
SSL DecryptionWe first need to understand a little about the mechanics of SSL decryption; you can read about it in depth here. In a nutshell there are two conditions that must be met before we can proceed: The server must be using the RSA key exchange mechanism (see here, bottom of page, and here, section F.1.1.2). Fortunately, this is the most common form of key exchange for SSL based servers; if you’re using DSA keypairs or the Diffie-Hellman key exchange mechanism you’re probably out of luck.
You must have access to the server’s private RSA key, and be able to copy it onto your Sguil sensor.The latter point means that the only SSL decryption we’re going to be able to pull off is decryption of traffic to and from servers that we own – we’re not going to be able to magically decrypt arbitrary SSL traffic (darn!) However, this is quite adequate from the viewpoint of intrusion detection and network forensics. Read more: InfoSec
QR:
The webserver’s use of SSL means that network-based incident detection is problematic. No amount of tuning of the sensor’s Snort instance will help it detect intrusion attempts – the only traffic it will see is HTTPS. Also, if an incident is detected by other means (e.g., customer notification, web server log file monitoring, etc.) the investigative value of Sguil’s full packet capture is greatly diluted. There are a number of ways to get back the visibility stolen by SSL, including the following. You could: Terminate the SSL “in front of” the webserver, perhaps on a reverse-proxying loadbalancer or web application firewall. You can then monitor the decrypted traffic between the loadbalancer and the webserver.
Perform monitoring tasks on the webserver itself, perhaps by increasing the level of web and application logging.
Give your existing sensor platforms the means to decrypt the SSL sessions.Each approach has its pros and cons; this article will show you how to leverage the latter technique to restore the eyesight of your blind Sguil sensors.
SSL DecryptionWe first need to understand a little about the mechanics of SSL decryption; you can read about it in depth here. In a nutshell there are two conditions that must be met before we can proceed: The server must be using the RSA key exchange mechanism (see here, bottom of page, and here, section F.1.1.2). Fortunately, this is the most common form of key exchange for SSL based servers; if you’re using DSA keypairs or the Diffie-Hellman key exchange mechanism you’re probably out of luck.
You must have access to the server’s private RSA key, and be able to copy it onto your Sguil sensor.The latter point means that the only SSL decryption we’re going to be able to pull off is decryption of traffic to and from servers that we own – we’re not going to be able to magically decrypt arbitrary SSL traffic (darn!) However, this is quite adequate from the viewpoint of intrusion detection and network forensics. Read more: InfoSec
QR:
Posts
0 comments:
Post a Comment