[Emerging-Sigs] Detect non SSL traffic

Matt Jonkman jonkman at jonkmans.com
Thu Jul 10 09:41:51 EDT 2008


Hey Jason. We have some sigs for a positive detection of ssl on off 
ports, we could probably do something for non-ssl using the same set. 
Here's what's there now, it's in Policy:

http://www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/POLICY/POLICY_SSL_TLS_on_High_Port?rev=1.2

There are essentially 3 or 4 opening patterns we can detect to pretty 
reliably say it's going to be an SSL session, then set a flowbit to 
ignore the stream.

We've thought about trying this before, and I think what we all 
discussed about it was the possibility of false positives. There are 
surely real apps using 443 but not ssl. Maybe if we could write these 
rules and test them in a few live nets to see it'd be safer. Any volunteers?

Matt

Jason Chips wrote:
> I have recently run into a couple cases where hackers who managed to get 
> their malware installed on systems behind our corporate firewall, would 
> use outbound tcp/443 connections to their C&C servers to report in, 
> control the infected system, etc.  I imagine they chose tcp/443 because 
> many people have historically ignored it at the firewall, web usage 
> monitor, and IDS because they assumed it to only carry legitimate 
> encrypted data.  I have seen cases of these C&C channels being 
> plaintext or encrypted with an algorithm besides SSL/TLS.  Of course a 
> good outbound web proxy will reject tcp/443 traffic which is not SSL/TLS 
> compliant.
>  
> Can someone gve me a pointer on how to create a Snort rule to do the 
> following:
>  
> Alert on tcp/443 traffic which is not a valid SSL/TLS connection.  More 
> specifically, I know that snort recently introduced the ssl 
> preprocessor, and it has the "noinspect encrypted" option[1].  I am 
> afraid that this option just looks for the presence of defined SSL 
> handshake error messages, and will only engage if it detects one of 
> these.  If I am wrong about this, the rule should be easy to write.  The 
> other way that I thought about approaching this was to check for the 
> presence of the SSL Client Hello pattern on the FIRST packet seen after 
> an established tcp connection with the Push flag set.  Is there a way to 
> accomplish this in Snort? 
>  
>  Thanks for any opinions or help,
>  
> Jason
>  
>  
> 1.  http://www.snort.org/docs/snort_htmanuals/htmanual_282/node135.html
>  
>  
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs

-- 
--------------------------------------------
Matthew Jonkman
Emerging Threats
Phone 765-429-0398
Fax 312-264-0205
http://www.emergingthreats.net
--------------------------------------------

PGP: http://www.jonkmans.com/mattjonkman.asc




More information about the Emerging-sigs mailing list