Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 29 Sep 2001 13:36:35 +0800
From:      Igor Podlesny <poige@morning.ru>
To:        "Mire, John" <jmire@lsuhsc.edu>
Cc:        Mike Tancsa <mike@sentex.net>, security@FreeBSD.ORG
Subject:   Re[2]: inspecting data with ipfw (ala hogwash)
Message-ID:  <15566616118.20010929133635@morning.ru>
In-Reply-To: <DAC809EAC7E4594AA0696EF512F6ABF104521B90@sh-exch>
References:  <DAC809EAC7E4594AA0696EF512F6ABF104521B90@sh-exch>

next in thread | previous in thread | raw e-mail | index | archive | help


> our use of snort seems to indicate that fragmenting the code doesn't work
> b/c of the frag2 preprocessor that reassembles packets and sends them
> through the detection engine...

snort is snort, it has tcp processor :-)

> -----Original Message-----
> From: Igor Podlesny [mailto:poige@morning.ru]
> Sent: Thursday, September 27, 2001 22:50
> To: Mike Tancsa
> Cc: security@FreeBSD.ORG
> Subject: Re: inspecting data with ipfw (ala hogwash)



>> Does anyone know of any patches similar in function to what hogwash does ?

>> (http://hogwash.sourceforge.net).  Basically something to deny packets 
>> based on the content of the packets.  With the latest iptables on LINUX, 
>> you can now do matching on data portion as well.  Something like

>> ipfw add 666 deny log tcp from any to me 80 data "*scripts/cmd.exe*" ?

> What  if  somebody  just  wanted to PUT a description containing these
> strings? ;-)

> Then,  really  cool  nuts  could  fragment  up the exploit code to the
> unrecognizeable (sorry for that term ;-), by this approach, state.

> Another  interesting  question  is  "What  should  be done to this TCP
> session".  For  e.g.,  this data wasn't in initial SYN segment, so the
> connection has been established. At least I can say that 'deny' is too
> harmful here, I suggest using 'reset' or 'unreach'. And one more thing
> to remember -- lots of ppl use statefull firewall set-up.

> In  common,  I agree that the idea is interesting... and in freebsd it
> could be implemented with something like 'divert' and 'NATPd' (Network
> Attack Tracking & Preventing ;-) which could be a userland daemon just
> like NATd is.

> BTW, thanx for the URL!

>> would be what I am after

>>         ---Mike

>> --------------------------------------------------------------------
>> Mike Tancsa,                                      tel +1 519 651 3400
>> Sentex Communications,                            mike@sentex.net
>> Providing Internet since 1994                    www.sentex.net
>> Cambridge, Ontario Canada                         www.sentex.net/mike


>> To Unsubscribe: send mail to majordomo@FreeBSD.org
>> with "unsubscribe freebsd-security" in the body of the message






-- 
 Igor                            mailto:poige@morning.ru


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15566616118.20010929133635>