[Oisf-devel] [Emerging-Sigs] SSL Renegotiation
victor at inliniac.net
Wed Nov 9 09:00:53 EST 2011
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?
> -L0rd C.
> On Mon, Oct 31, 2011 at 6:12 PM, Kevin Ross <kevross33 at googlemail.com> wrote:
>> This detection is better:
>> 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?
>>> 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,
>>> 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
>>> 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
>>> 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.
>>> Emerging-sigs mailing list
>>> Emerging-sigs at emergingthreats.net
>>> Support Emerging Threats! Subscribe to Emerging Threats Pro
>>> The ONLY place to get complete premium rulesets for Snort 2.4.0 through
>> Emerging-sigs mailing list
>> Emerging-sigs at emergingthreats.net
>> Support Emerging Threats! Subscribe to Emerging Threats Pro
>> The ONLY place to get complete premium rulesets for Snort 2.4.0 through
> Oisf-devel mailing list
> Oisf-devel at openinfosecfoundation.org
More information about the Oisf-devel