Wayward RST packets - what's the right answer?

Wayward RST packets - what's the right answer?

[Jay Levitt]

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

This message has popped up on the list a few times over the years, but I can't find a definitive answer on the best solution for it.

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 

I then get multiple log entries like:

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 

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 

Obviously these aren't genuine scans.  Is there any rule I could use that would let the RST do whatever it's trying to do and gracefully close down the connection instead of logging it?  I am almost to the point of not bothering to log iptables output, since I'm not entirely sure what I would do if I did see an attack anyway... but certainly, right now, what's being logged is noise, and I'd like to improve my SNR.  Suggestions?

Jay Levitt

[-- Attachment #2: Type: text/html, Size: 2654 bytes --]

Re: Wayward RST packets - what's the right answer?

[Chris Brenton]

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

Re: Wayward RST packets - what's the right answer?

[Jay Levitt]

Chris Brenton wrote:


> 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?

Nope, it's the other way around - this rule matches any packet that is in a
NEW state but has flags other than 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 and not reply, regardless of
> whether the port is open or not. Best an attacker could hope to receive
> is a host unreachable.

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

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

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

> > 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.

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

> 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.

What's an IDS?

Jay Levitt

Re: Wayward RST packets - what's the right answer?

[Jay Levitt]

[-- Attachment #1: Type: text/plain, Size: 2588 bytes --]

Chris Brenton wrote:


> 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?

Nope, it's the other way around - this rule matches any packet that is in a
NEW state but has flags other than 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 and not reply, regardless of
> whether the port is open or not. Best an attacker could hope to receive
> is a host unreachable.

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

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

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

> > 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.

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

> 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.

What's an IDS?

Jay Levitt

[-- Attachment #2: Type: text/html, Size: 3212 bytes --]