[Snort-users] SHUN

ams67 ams67 at ...3655...
Tue Dec 3 12:20:24 EST 2002


Thank you for your clear explanation.
However, I still have a possible 'lame' question to ask. :-)
Please correct me if I am wrong. If I am the attacker and I do not want
my ip address blocked by SnortSam, I could lunch a syn-flood attack so I
achieve a kind of 'fail-open' status. In the meantime, I lunch the real
attack that will not be blocked as I managed to reach the threshold from
my previous syn-attack. In this way I can easily evade the functionality
of SnortSam.
I understand that in security, nothing is foolproof, however I still
think that now tool like SnortSam or Guardian are still too 'fool' to be
used in a productive/operational environment. 
Probably until the TCP/IP protocol is not rewritten with 'security' in
mind, the attackers will always be one-step forward...



-----Original Message-----
From: Frank Knobbe [mailto:fknobbe at ...652...] 
Sent: Wednesday, 4 December 2002 4:29 a.m.
To: ams67
Cc: snort-users at lists.sourceforge.net
Subject: RE: [Snort-users] SHUN

>again, Snort and SnortSam are two different programs. Snort still does
>analysis. It's just that SnortSam doesn't block white-listed IP's. I
>think that's what you mean though.
>There is no fancy AI involved. SnortSam uses a simple threshold
>mechanism to detect 'attacks'. If SnortSam exceeds a defineable amount
>of blocking requests in a definable amount of time, it will unblock the
>last <definable> IP addresses, and then just wait until the current
>of blocking requests receeds below the threshold level. It then waits
>additional definable time before it acts on blocking requests again.
>So under normal conditions, you may see a maximum of, for example, 5
>blocks (read, unique IP's) per 10 seconds. If you try to DoS SnortSam
>with your syn-flood attack, you will probably exceed, 10 blocks ber 10
>secs (let's use that as an example for the set threshold). SnortSam
>then unblock the last <x> blocks it 'mistakenly' blocked, waits until
>you quit DoS'ing the system. It then waits a time to make sure you're
>really gone, and then get's back to work.
>Not a fool-proof method, but it seems to work pretty good. 

More information about the Snort-users mailing list