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

[L0rd Ch0de1m0rt]

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).

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!
>