From owner-freebsd-security Fri Sep 28 22:36:26 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id 115C537B406 for ; Fri, 28 Sep 2001 22:36:21 -0700 (PDT) Received: from NDNM ([195.161.98.250]) by ns.morning.ru (8.11.5/8.11.5) with ESMTP id f8T5aDG28846; Sat, 29 Sep 2001 13:36:13 +0800 (KRAST) Date: Sat, 29 Sep 2001 13:36:35 +0800 From: Igor Podlesny X-Mailer: The Bat! (v1.53d) UNREG / CD5BF9353B3B7091 Organization: Morning Network X-Priority: 3 (Normal) Message-ID: <15566616118.20010929133635@morning.ru> To: "Mire, John" Cc: Mike Tancsa , security@FreeBSD.ORG Subject: Re[2]: inspecting data with ipfw (ala hogwash) In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > 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