Shorewall users - Jan 2003 - Block packets based on content

Is it possible to block packets based on content? I would specifically like
to block the script kiddies " GET /script/*" packets from reaching my
webserver.
Thanks for your time,
Steve

On Tue, 2003-01-28 at 11:58, Steve Postma wrote:
> Is it possible to block packets based on content? I would specifically like
> to block the script kiddies " GET /script/*" packets from
reaching my
> webserver.
> Thanks for your time,
> Steve
Look at the netfilter.org site in the patch-o-matic section. They have
at least one patch, STRING, with will allow you to match a string inside
a whole packet. This is about as close as you''re going to get with
iptables, I think, to doing what you want. 

Z

--On Tuesday, January 28, 2003 12:07 PM -0500 Zachariah Mully 
<zmully@smartbrief.com> wrote:
> On Tue, 2003-01-28 at 11:58, Steve Postma wrote:
>> Is it possible to block packets based on content? I would specifically
>> like to block the script kiddies " GET /script/*" packets
from reaching
>> my webserver.
>> Thanks for your time,
>> Steve
>
> Look at the netfilter.org site in the patch-o-matic section. They have
> at least one patch, STRING, with will allow you to match a string inside
> a whole packet. This is about as close as you''re going to get with
> iptables, I think, to doing what you want.
>
I don''t recommend that approach (and neither do the folks on the
netfilter
list). You want to use a Proxy to do content filtering; using STRING 
matching leaves you open to DOS attacks and STRING is easy to defeat anyway.

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://www.shorewall.net
Washington USA \ teastep@shorewall.net

--On Tuesday, January 28, 2003 9:12 AM -0800 Tom Eastep 
<teastep@shorewall.net> wrote:
>
>
> --On Tuesday, January 28, 2003 12:07 PM -0500 Zachariah Mully
> <zmully@smartbrief.com> wrote:
>
>
> I don''t recommend that approach (and neither do the folks on the
> netfilter list). You want to use a Proxy to do content filtering; using
> STRING matching leaves you open to DOS attacks and STRING is easy to
> defeat anyway.
>
Scratch that about the DOS attacks -- I was thinking of something else 
(senior moment).

-Tom
--
Tom Eastep   \ Shorewall - iptables made easy
Shoreline,    \ http://www.shorewall.net
Washington USA \ teastep@shorewall.net

On Tue, 2003-01-28 at 12:12, Tom Eastep wrote:
> 
> I don''t recommend that approach (and neither do the folks on the
netfilter
> list). You want to use a Proxy to do content filtering; using STRING 
> matching leaves you open to DOS attacks and STRING is easy to defeat
anyway.
> 
> -Tom
Yeah, I know, but like I said, it''s as close as you''re going
to get
using IPTABLES... I remember all the furor over STRING usage during the
code-red outbreaks. But you''re right, I should have mentioned proxying,
my bad.

Z

> -----Original Message-----
> From: Tom Eastep
> Sent: Tuesday, January 28, 2003 11:16 AM
> Subject: Re: [Shorewall-users] Block packets based on content
> 
> --On Tuesday, January 28, 2003 9:12 AM -0800 Tom Eastep 
> <teastep@shorewall.net> wrote:
> 
> >
> > --On Tuesday, January 28, 2003 12:07 PM -0500 Zachariah Mully
> > <zmully@smartbrief.com> wrote:
> >
> >
> > I don''t recommend that approach (and neither do the folks on
the
> > netfilter list). You want to use a Proxy to do content filtering;
> > using STRING matching leaves you open to DOS attacks and STRING
> > is easy to defeat anyway.
> >
> 
> Scratch that about the DOS attacks -- I was thinking of 
> something else (senior moment).
But using the strings patch to block nimda does have a "similar"
effect to a
DoS attack.

The following is a cut/paste from a post I made to this list back on
6-15-2002. I think this is actually a cut/paste from a thread on the
netfilter list that I reposted on the shorewall list. Unfortunately, using
search on both lists did not yeild a match. So I thought I would just repost
the relevant content. FYI

Steve Cowles

> Hello,
> I used the p-o-m string match support to detect,
> log and reject the "GET /default.ida?NNNN" we all love
> so dearly on a filtering bridge. After 25 requests from
> the same address, it gets dynamically blocked. It worked
> fine, until two days ago (or so).
> The match still works, in a way, but now some of these
> requests come through anyway (while others are detected).
> My guess was that there''s a new variant which fragments
> the request packets so the string is spread over two
> (or more) packets now.
> My question: is the good old "always defragment" option
> from 2.2 still there somehow?
> I tried to find this in the sources, but only found that
> defragmenting is done on connection tracking, which I
> don''t want to use (there are a _lot_ of connections
> going through that bridge, and it''s under heavy load even
> without conntracking).
This is just one of the reasons why you shouldn''t use the
string match to replace a full blown traditional HTTP proxy.
The packets don''t have don''t be fragmented to have only a part
of the
HTTP query string, so even defrag won''t help. And there are many other
concerns (check the archive to see what I''m talking about).
What you need is a filtering HTTP proxy, and you can redirect
all HTTP traffic through it.

--------- archive 2 ----------------

hi,
	As discussed somewhere in this list, filtering apache with the
string match will leave not only these logs but lots of open connections.
I mean:

client starts connection to server
server syn-ack''s to client
client ack''s to server
-- connection stablished --
client issues first packet with HTTP request, that never gets to the
server because of the string match ==> server sits in a wait state,
and makes those logs.

There is a thread called "apache and nimda" AFAIR... you can use
twhttpd
to secure your webserver, look for it in freshmeat.