On Thu, 2004-03-25 at 23:29, Jay Levitt wrote: > > Fairly often - as in a few times an hour on a very, very underused > server - I get repeated RST packets from hosts I've recently been > talking to, but that conntrack thinks aren't part of a connection. My > rule: > > iptables -A INPUT -p tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state > --state NEW -j LOG --log-prefix "Stealth scan attempt" > iptables -A INPUT -p tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state > --state NEW -j DROP Maybe I'm reading this wrong, but I would expect you would only get a match with this rule if SYN was set. I'm surprised your grabbing RST packets. Perhaps another rule that uses the same prefix? Also, not so sure you can consider RST's a "stealth scan" as a receiving host is just going to ignore bogus RST's and not reply, regardless of whether the port is open or not. Best an attacker could hope to receive is a host unreachable. > Mar 25 23:19:05 linux kernel: Stealth scan attemptIN=eth0 OUT= > MAC=00:50:2c:01:62:8e:00:20:78:d0:44:8f:08:00 SRC=208.185.179.12 > DST=192.168.1.150 LEN=40 TOS=0x00 PREC=0x00 TTL=47 ID=6376 PROTO=TCP > SPT=2046 DPT=25 WINDOW=0 RES=0x00 RST URGP=0 What's the time stamp on the accepted packet? If you are logging/dropping RST packets prior to processing ESTABLISHED that would explain this entry. I very rarely see legit RST packets get dropped so if you are seeing them fairly often I would guess a config problem as RSTs are a last resort. > with occasional, "related" (semantically, not conntrack-ily) outbound > traffic: > > Mar 25 23:19:05 linux kernel: Rejected output by default:IN= OUT=eth0 > SRC=192.168.1.150 DST=208.185.179.12 LEN=100 TOS=0x00 PREC=0x00 TTL=64 > ID=58139 DF PROTO=TCP SPT=25 DPT=2046 WINDOW=9216 RES=0x00 ACK PSH FIN > URGP=0 Actually, this would be ESTABLISHED, not RELATED, but these are a bit less rare. If you were to watch this session, you would probably see 208.185.179.12 initialize the FIN/ACK close and 192.168.1.150 continue to send data. It does so longer than the connection tracking expire and an entry like this one appears. The other time I've seen it is when there is an IDS on the wire kicking out RST packets when a suspect packet is seen, but the IDS does not get the sequence numbers right in the RST. HTH, Chris
