[Oisf-devel] [Emerging-Sigs] SSL Renegotiation

[Victor Julien]

On 11/01/2011 02:27 PM, L0rd Ch0de1m0rt wrote:
> Hello.  It looks like VRT is a week behind ET, lol.  But seriously,
> for the proposed VRT rules in snort you have to disable, 'preprocessor
> ssl: noinspect_encrypted' which means now snort is inspecting *all* of
> your SSL traffic and for many of us who have a lot of public facing
> websites that use SSL, this means inspecting *loads* more traffic,
> 99.999% of it we don't care about anyway.
> 
> I am now curious, does Suricata offer a better way to do this?  If
> not, is there a similar configuration like 'preprocessor ssl:
> noinspect_encrypted' that needs to be disabled?  Or is there an 'alert
> ssl ... ' application layer rule that can be written?  I know Suricata
> (or at least recent versions) support the 'ssl_state' keyword now.  I
> copied the OISF devel list too so maybe they can shed some light on
> this (assuming my email gets through).

Just checked this out and it seems we do something similar, kind of.

There is a setting "tls.no_reassemble" which defaults to true. What it
does is it tells Suricata to stop reassembling the TCP streams (and thus
parsing the SSL/TLS session). What it does not appear to do is stopping
inspection of the packet payloads of that TCP session.

By stopping the reassembly we do loose a significant part of the
detection capabilities for that stream though.

It may actually make sense to change this into the following:

1. keep tracking the SSL/TLS session so we can spot renegotiations.
2. have the SSL/TLS parser flag the parts of the stream that are
encrypted and bypass those in the detection engine.

Would that make sense?

Cheers,
Victor

> Thanks.
> 
> -L0rd C.
> 
> On Mon, Oct 31, 2011 at 6:12 PM, Kevin Ross <kevross33 at googlemail.com> wrote:
>> This detection is better:
>>
>> http://vrt-blog.snort.org/2011/10/ssl-dos-snort-and-you.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Vrt+%28Sourcefire+VRT+-+Vulnerability+Research%2C+Razorback+and+Explosions%29
>>
>>
>>
>>
>> On 31 October 2011 19:24, Rich Rumble <richrumble at gmail.com> wrote:
>>>
>>> On Tue, Oct 25, 2011 at 1:47 PM, Rich Rumble <richrumble at gmail.com> wrote:
>>>> Would it be best to use a threshold rule of some sort, or are there
>>>> other ways
>>>> in Snort and or Suricata that would be better?
>>>> http://www.thc.org/thc-ssl-dos/
>>> This is my first real threshold rule, I'm simply looking for
>>> this string: 14 03 01 00 01 01
>>>
>>> There are other rules that are similar (sid:2003008, 2003009, 2003018,
>>> 2003019)
>>> I'm not sure how to better narrow down to these ports:
>>> 443, 465, 563, 636, 989, 990, 993, 995, 5223
>>> which are typical services over SSL/TLS. Right now the rule might be a
>>> bit costly with
>>> "any" being used.  No "SSL_Ports" variable that I can find in Snort or
>>> Suri, I wonder
>>> if SSL might be port agnostic like Http is in Suri?
>>>
>>> I've been able to get this to FP by holding F5 in a browser and doing a
>>> google
>>> search (https://google.com) or in gmail holding F5. I've tried to tune it
>>> to the
>>> THC tool and a Bash script they also published, it's working well so
>>> far...
>>> http://www.thc.org/thc-ssl-dos/
>>>
>>>
>>> alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET DOS SSL
>>> Renegotiation"; flow:established; ssl_state: server_hello;
>>> content:"|14 03 01 00 01 01|"; detection_filter:track by_src, count 8,
>>> seconds 1; reference:url,http://www.thc.org/thc-ssl-dos; sid:1000001;)
>>>
>>> Maybe the folks on the Pro side would be better suited for such a
>>> rule, but to me the bash
>>> script and the thc-ssl-dos tool look very similar, but are not exact
>>> matches in traffic generated.
>>> -rich
>>> _______________________________________________
>>> Emerging-sigs mailing list
>>> Emerging-sigs at emergingthreats.net
>>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>>
>>> Support Emerging Threats! Subscribe to Emerging Threats Pro
>>> http://www.emergingthreatspro.com
>>> The ONLY place to get complete premium rulesets for Snort 2.4.0 through
>>> Current!
>>
>>
>> _______________________________________________
>> Emerging-sigs mailing list
>> Emerging-sigs at emergingthreats.net
>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>
>> Support Emerging Threats! Subscribe to Emerging Threats Pro
>> http://www.emergingthreatspro.com
>> The ONLY place to get complete premium rulesets for Snort 2.4.0 through
>> Current!
>>
> _______________________________________________
> Oisf-devel mailing list
> Oisf-devel at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
> 


-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------