Hello, we are interested to learn how Shorewall can be configured to look into a packet''s payload, say to look for footprints of Red Code or Nimbda (for example). From the site web page features section we understand Shorewall only looks into the packet''s header. Your enlightening answer will be appreciated. Regards Jose.
Shorewall (or rather, iptables, to which Shorewall is a front-end) doesn''t inspect the contents of individual network connections - it only monitors sources and destinations. You may want to check out snort (www.snort.org). On Thursday 13 June 2002 11:16 am, Jose Antonio Cordova wrote:> Hello, we are interested to learn how Shorewall can be configured to look > into a packet''s payload, say to look for footprints of Red Code or Nimbda > (for example). From the site web page features section we understand > Shorewall only looks into the packet''s header. > Your enlightening answer will be appreciated. > > Regards > Jose.
> -----Original Message----- > From: Jose Antonio Cordova [mailto:cordova@asoban.bo] > Sent: Thursday, June 13, 2002 10:17 AM > To: shorewall-users@shorewall.net > Subject: [Shorewall-users] Red Code, Nimbda et. al > > > Hello, we are interested to learn how Shorewall can be > configured to look into a packet''s payload, say to look > for footprints of Red Code or Nimbda (for example). From > the site web page features section we understand Shorewall > only looks into the packet''s header. Your enlightening > answer will be appreciated. >As Scott Merrill pointed out, Shorewall is a front-end to iptables, which does not inspect the data portion of any packet. FWIW: I wrote a shell script which scans my apache logfiles for the code red/nimda signatures and then updates the shorewall blacklist file so these infected systems can no longer access my web server (or any service for that matter). I implemented this as a cronjob. Just another approach to solving this problem. Steve Cowles
On Thu Jun 06/13/02, 2002 at 02:56:43PM -0400, Scott Merrill wrote:> Shorewall (or rather, iptables, to which Shorewall is a front-end) doesn''t > inspect the contents of individual network connections - it only monitors > sources and destinations. > > You may want to check out snort (www.snort.org).Rusty Russell appears to disagree with you: ;) http://online.securityfocus.com/infocus/1531 iptables has had the "string-match" target for awhile now.... -- Greg White
On Thu, 13 Jun 2002, Jose Antonio Cordova wrote:> Hello, we are interested to learn how Shorewall can be configured to look > into a packet''s payload, say to look for footprints of Red Code or Nimbda > (for example). From the site web page features section we understand > Shorewall only looks into the packet''s header. > Your enlightening answer will be appreciated. >Shorewall doesn''t do payload filtering. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On Fri, 14 Jun 2002, Greg White wrote:> On Thu Jun 06/13/02, 2002 at 02:56:43PM -0400, Scott Merrill wrote: > > Shorewall (or rather, iptables, to which Shorewall is a front-end) doesn''t > > inspect the contents of individual network connections - it only monitors > > sources and destinations. > > > > You may want to check out snort (www.snort.org). > > > Rusty Russell appears to disagree with you: ;) > > http://online.securityfocus.com/infocus/1531 > > iptables has had the "string-match" target for awhile now.... > >And most people think that the "string-match" target is very poorly suited for Nimda blocking, etc. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On Fri Jun 06/14/02, 2002 at 04:09:27PM -0700, Tom Eastep wrote:> On Fri, 14 Jun 2002, Greg White wrote: > > > On Thu Jun 06/13/02, 2002 at 02:56:43PM -0400, Scott Merrill wrote: > > > Shorewall (or rather, iptables, to which Shorewall is a front-end) doesn''t > > > inspect the contents of individual network connections - it only monitors > > > sources and destinations. > > > > > > You may want to check out snort (www.snort.org). > > > > > > Rusty Russell appears to disagree with you: ;) > > > > http://online.securityfocus.com/infocus/1531 > > > > iptables has had the "string-match" target for awhile now.... > > > > > > And most people think that the "string-match" target is very poorly suited > for Nimda blocking, etc.Odd -- seems to me to be exactly what it was designed for... It seems to be a poor block of a bad hole in a crummy http server, but a good block of a hole that does not exist in your server -- like if you run publicfile or apache. Could anyone on the list (but especially Tom) tell me why the string-matching target would be a bad idea to block this sort of thing from a server that is not vulnerable? I''ve seen articles which say "put this string in your sensitive documents and watch the firewall stop people from sending the document", and that is obviously crap, but when you''re not vulnerable to an exploit, and the exploit sends a known-bad particular string in each and every packet, why not utilise it? Is it poor coding on the part of the authors of the string-matching code, or something I''m missing? Feel free to simply point me at URLs if you like. -- Greg White
> -----Original Message----- > From: Greg White [mailto:gregw-shorewall@greg.cex.ca] > Sent: Saturday, June 15, 2002 1:03 AM > To: shorewall-users@shorewall.net > Subject: Re: [Shorewall-users] Red Code, Nimbda et. al > > Odd -- seems to me to be exactly what it was designed for... > It seems to be a poor block of a bad hole in a crummy http > server, but a good block of a hole that does not exist in > your server -- like if you run publicfile or apache. Could > anyone on the list (but especially Tom) tell me why the > string-matching target would be a bad idea to block this sort > of thing from a server that is not vulnerable? > > I''ve seen articles which say "put this string in your > sensitive documents and watch the firewall stop people from > sending the document", and that is obviously crap, but when > you''re not vulnerable to an exploit, and the exploit sends a > known-bad particular string in each and every packet, why not > utilise it? Is it poor coding on the part of the authors > of the string-matching code, or something I''m missing? Feel > free to simply point me at URLs if you like.Greg, First, thanks for posting the link about the string-match capabilities. I had no idea that this experimental code existed within the netfilter package. Unfortunately, after searching through the archives, I must agree with Tom in that using the string match feature to block nimda/code red is a BAD idea. I have included a couple of posts that caught my attention. In fact, there are hundreds of other posts that discuss this very topic and most state similar reasons to NOT use string match for code red/nimda blocking. Steve Cowles ------- archive 1 -------------> 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 gets waiting, 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.
On Sat, 15 Jun 2002, Cowles, Steve wrote:> Unfortunately, after searching through the archives, I must agree with Tom > in that using the string match feature to block nimda/code red is a BAD > idea. I have included a couple of posts that caught my attention. In fact, > there are hundreds of other posts that discuss this very topic and most > state similar reasons to NOT use string match for code red/nimda blocking.Thanks for expanding on my cryptic post of yesterday evening. The basis for my statement in that post was in fact the thread that you cited. Given the unsuitability of string-match for the purpose proposed by the original poster, I think that what you are doing with your Apache log processing program is the correct approach. In Shorewall 1.3.2, dynamic blacklisting in such scripts will become easier through the use of four new commands in /sbin/shorewall. shorewall drop <ip address list> shorewall reject <ip address list> shorewall allow <ip address list> shorewall save The first two commands cause packets from the listed addresses to be either dropped or rejected. The third command restores access by the listed addresses. The ''save'' command saves the current ''drop/reject'' configuration so that it can be restored the next time that Shorewall is [re]started. The command "shorewall show dynamic" can be used to list the current set of ip addresses being either dropped or rejected. This facility is available in the current CVS version of Shorewall. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net