Chris Brenton wrote:

> On Thu, 2004-03-25 at 23:29, = Jay=20 Levitt wrote:
> >
> > Fairly often - as in a few times = an hour=20 on a very, very underused
> > server - I get repeated RST = packets from=20 hosts I've recently been
> > talking to, but that conntrack = thinks=20 aren't part of a connection. My
> > rule:
> = >
>=20 > iptables -A INPUT -p tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m = state
>=20 > --state NEW -j LOG --log-prefix "Stealth scan attempt"
> > = iptables -A INPUT -p tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m = state
> >=20 --state NEW -j DROP
>
> Maybe I'm reading this wrong, but I = would=20 expect you would only get a
> match with this rule if SYN was set. = I'm=20 surprised your grabbing RST
> packets. Perhaps another rule that = uses the=20 same prefix?

Nope, it's the other way around - this rule matches = any=20 packet that is in a
NEW state but has flags other than=20 SYN-and-only-SYN.

> Also, not so sure you can consider RST's a = "stealth scan" as a receiving
> host is just going to ignore bogus = RST's=20 and not reply, regardless of
> whether the port is open or not. = Best an=20 attacker could hope to receive
> is a host unreachable.

OK, = so it'd=20 be perfectly safe to add this?

iptables -A INPUT -p -tcp = --tcp-flags=20 FIN,SYN,RST,ACK RST -m state --state
NEW -j ACCEPT

One problem = is that=20 although I can read about the TCP protocol and valid
states, I don't = know=20 what failure/DOS/etc modes I'm protecting against, and
therefore I'm = not sure=20 what invalid-yet-possible states I should be = letting
through.

>=20 > Mar 25 23:19:05 linux kernel: Stealth scan attemptIN=3Deth0 = OUT=3D
> >=20 MAC=3D00:50:2c:01:62:8e:00:20:78:d0:44:8f:08:00 = SRC=3D208.185.179.12
> >=20 DST=3D192.168.1.150 LEN=3D40 TOS=3D0x00 PREC=3D0x00 TTL=3D47 ID=3D6376 = PROTO=3DTCP
>=20 > SPT=3D2046 DPT=3D25 WINDOW=3D0 RES=3D0x00 RST = URGP=3D0
>
> What's the=20 time stamp on the accepted packet? If you are
> logging/dropping = RST=20 packets prior to processing ESTABLISHED that would
> explain this = entry. I=20 very rarely see legit RST packets get dropped so
> if you are = seeing them=20 fairly often I would guess a config problem as
> RSTs are a last=20 resort.

Not sure what you're asking about the timestamp... the = rule does=20 log/drop
RST packets in a NEW state (or, more likely, after a = connection has=20 been
"closed" in conntrack). I see them a few times an hour; = any idea=20 what sort
of config problem I'd be looking for?

> The other = time=20 I've seen it is when there is an IDS on the wire kicking
> out RST = packets=20 when a suspect packet is seen, but the IDS does not get
> the = sequence=20 numbers right in the RST.

What's an IDS?

Jay=20 Levitt