On Fri, Mar 01, 2002 at 02:23:56PM -0600, Seann Herdejurgen wrote: > I am trying to filter out the Nimda virus with the following rule: > > iptables -t filter -A INPUT -i $EXT_IFACE -p tcp -d $IP --dport http \ > -m string --string ".exe?/c+dir" -j REJECT --reject-with tcp-reset > > My understanding is that when this rule sees a packet matching > ".exe?c+dir", it is supposed to send a TCP RST packet back to the sender > that will close the connection. The packet is being blocked, but the > TCP RST packet doesn't appear to go out. > > When I try this in practice, the connection stays in an ESTABLISHED > state for about 5 minutes before the connection is dropped. I was > working with a friend of mine using tcpdump and it doesn't look like a > RST packet is actually being sent out. Is this by design, or is my > interpretation of the REJECT target wrong? > > I received one response to use Snort, but that doesn't answer why the > REJECT target isn't working.
I tried this out with the following simple rules: $IPT0 = "/usr/local/sbin/iptables -A tcprules -i eth0" $IPT0 -p tcp --dport 501 -j LOG --log-prefix "Port501a " #1 $IPT0 -p tcp --dport 501 -j REJECT --reject-with tcp-reset #2 I telneted from the outside in to an internally NATTed machine. Rules #1 and #2 kicked off, supposedly sending back a RST. However I didn't see it and noticed that I was dropping an outbound packet from my internal machine to the outside with a source port of 501. If I replaced #2 with a DROP then it stopped the packet dead in its tracks and didn't get to the internal machine. I think I have something else wrong with my NAT rules for it to go through like that. Anyway I'll look more into it. Chris
