Dropping RST of SYN

Dropping RST of SYN

[Atsushi Nakagawa]

Hi,

What iptables table/rule can I use to drop RST (TCP) packets that're in
reply to SYN?

Below is a picture of how I think it does it if everything is accepted. 
(Final conntrack states in square brackets.)

_Client_  _Firewall_  _Server_
-SYN->    [NEW]        -SYN->
<-RST-    [CLOSED]     <-RST-


This is what I want it to do:

-SYN->    [NEW]        -SYN->
          [CLOSED]     <-RST-
            ^
          IF TCP & [NEW]: DROP '<-RST-' & SET [CLOSED]


I've tried mucking around with some rules but instead of getting the NEW
state when SYN comes along, I always get ESTABLISHED.  (I think I'm
using the wrong table.)

_Client_'s interface is ethC, _Server_'s interface is ethS.  _Server_'s
IP address is 10.0.0.1, port PORT.  _Client_'s address is arbitary.

Regards,


-- 
Atsushi Nakagawa
<atnak@chejz.com>
Changes are made when there is inconvenience.

Re: Dropping RST of SYN

[Ralf Spenneberg]

Am Don, 2003-09-04 um 10.50 schrieb Atsushi Nakagawa:
> What iptables table/rule can I use to drop RST (TCP) packets that're in
> reply to SYN?
> This is what I want it to do:
> 
> -SYN->    [NEW]        -SYN->
>           [CLOSED]     <-RST-
>             ^
>           IF TCP & [NEW]: DROP '<-RST-' & SET [CLOSED]
Using the current state implementation, AFAIK this is not possible.
The RST is already an established packet. There is no way to
differentiate between this RST and a later valid and needed RST packet.
You can only drop all RST packets
-m state --state ESTABLISHED -p tcp --tcp-flags RST,ACK RST,ACK -j DROP

Cheers,

Ralf
-- 
Ralf Spenneberg
RHCE, RHCX

Book: Intrusion Detection für Linux Server   http://www.spenneberg.com
IPsec-Howto				     http://www.ipsec-howto.org
Honeynet Project Mirror:                     http://honeynet.spenneberg.org

Re: Dropping RST of SYN

[Dharmendra.T]

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

On Thu, 2003-09-04 at 14:43, Ralf Spenneberg wrote:

    Am Don, 2003-09-04 um 10.50 schrieb Atsushi Nakagawa:
    > What iptables table/rule can I use to drop RST (TCP) packets that're in
    > reply to SYN?
    > This is what I want it to do:
    > 
    > -SYN->    [NEW]        -SYN->
    >           [CLOSED]     <-RST-
    >             ^
    >           IF TCP & [NEW]: DROP '<-RST-' & SET [CLOSED]
    Using the current state implementation, AFAIK this is not possible.
    The RST is already an established packet. There is no way to
    differentiate between this RST and a later valid and needed RST packet.
    You can only drop all RST packets
    -m state --state ESTABLISHED -p tcp --tcp-flags RST,ACK RST,ACK -j DROP
    
    Cheers,
    
    Ralf
    -- 
    Ralf Spenneberg
    RHCE, RHCX
    
    Book: Intrusion Detection für Linux Server   http://www.spenneberg.com
    IPsec-Howto				     http://www.ipsec-howto.org
    Honeynet Project Mirror:                     http://honeynet.spenneberg.org
    

Hi,

Blocking the RST packets on the firewall is not recommended. If the
attacker comes to know that the server is dropping RST packets then he
can flood the servers by initiating lacks of connections, which inturn
result closewait state.

-- 
Regards
Dharmendra.T
dharmu@nsecure.net
Linux Security and Admin

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

Re: Dropping RST of SYN

[Chris Brenton]

Dharmendra.T responded:
 >
> On Thu, 2003-09-04 at 14:43, Ralf Spenneberg wrote:
> 
> /Am Don, 2003-09-04 um 10.50 schrieb Atsushi Nakagawa:///
> /> What iptables table/rule can I use to drop RST (TCP) packets that're in///
> /> reply to SYN?///
> /> This is what I want it to do:///
> /> ///
> /> -SYN->    [NEW]        -SYN->///
> />           [CLOSED]     <-RST-///
> />             ^///
> />           IF TCP & [NEW]: DROP '<-RST-' & SET [CLOSED]///

> Blocking the RST packets on the firewall is not recommended. If the 
> attacker comes to know that the server is dropping RST packets then he 
> can flood the servers by initiating lacks of connections, which inturn 
> result closewait state.

Ya know, I missed this the first time through but Dharmendra is 
absolutely right. This will make you far more susceptible to SYN flood 
attacks.

It is extremely rare for a system to generate a RST immediately after a 
SYN. The only time I've seen this in the wild are:

Load balancers
Port scanners
Response to SYN flood fallout

With a SYN flood attack, the attacker spoofs someone else's address 
space when they send you the SYN. You reply with a SYN/ACK which gets 
routed to the legitimate system. Since the true system did did not 
originate the session, it has no idea why you are sending it a SYN/ACK 
and responds with a RST. This clears your connection queue of the bogus 
entry. If you where to block this RST packet, the entry would stay in 
queue for a longer period of time (2 minutes or more) leaving less 
memory to handle legitimate connection attempts.

So I totally agree with Dharmendra. Blocking these packets is a real bad 
idea and would make it much easier for an attacker to knock your host 
off-line.

HTH,
C

Re: Dropping RST of SYN

[Atsushi Nakagawa]

Chris Brenton <cbrenton@chrisbrenton.org> wrote:
> Dharmendra.T responded:
> > On Thu, 2003-09-04 at 14:43, Ralf Spenneberg wrote:
> > > Am Don, 2003-09-04 um 10.50 schrieb Atsushi Nakagawa:
> > > > What iptables table/rule can I use to drop RST (TCP) packets
> > > > that're in reply to SYN?
> > >
> > > There is no way to differentiate between this RST and a later valid
> > > and needed RST packet.  You can only drop all RST packets
> > > -m state --state ESTABLISHED -p tcp --tcp-flags RST,ACK RST,ACK -j DROP
> >
> > Blocking the RST packets on the firewall is not recommended. If the 
> > attacker comes to know that the server is dropping RST packets then he 
> > can flood the servers by initiating lacks of connections, which inturn 
> > result closewait state.
> 
> Ya know, I missed this the first time through but Dharmendra is 
> absolutely right. This will make you far more susceptible to SYN flood 
> attacks.
>
> ...

Both Dharmendra and Chris have pointed out perfectly legitimate reasons
why it is a bad idea to drop RSTs in general.  However, these warnings
have taken the original proposition slightly out of context. --AFAIS

Ralf's response was to a question regarding the removal of outgoing RST
packets that are generated in reply to incoming SYN packets.  (These
RSTs being the kind that causes the "Connection Refused" TCP message)

Hence, "dropping all RST packets", should implicitly have meant, "all
outgoing RST packets".  (The -m state ... -j DROP line is ambiguous.)

In this case, there should be no consequences with SYN flood-type
attacks.  The only ill-effect, AFAIK, is with abortive disconnects not
reaching remote host (and remote host will resend obselete packets
little more times).  --A problem enough to deter me from implmementing
this.

Regards,


-- 
Atsushi Nakagawa
<atnak@chejz.com>
Changes are made when there is inconvenience.

Re: Dropping RST of SYN

[Chris Brenton]

Atsushi Nakagawa wrote:
> 
> Ralf's response was to a question regarding the removal of outgoing RST
> packets that are generated in reply to incoming SYN packets.  (These
> RSTs being the kind that causes the "Connection Refused" TCP message)

DOOOOH!

> In this case, there should be no consequences with SYN flood-type
> attacks.  The only ill-effect, AFAIK, is with abortive disconnects not
> reaching remote host (and remote host will resend obselete packets
> little more times).  --A problem enough to deter me from implmementing
> this.

Guess that's what I get for jumping in mid thread. :(

I think I'm at a loss as to why we are trying to do it this way. In 
other words, if you want to stop a scanner from getting a reply from all 
of your closed ports, would it not be easier to only let SYN packets in 
to legitimate services?

Or is this another "we're a .edu stuck in Dante's fourth circle of hell 
and are not permitted to filter out services". ;-)

C

Re: Dropping RST of SYN

[Stephen Satchell]

At 08:58 PM 9/8/2003 +1000, Atsushi Nakagawa wrote:
>Both Dharmendra and Chris have pointed out perfectly legitimate reasons
>why it is a bad idea to drop RSTs in general.  However, these warnings
>have taken the original proposition slightly out of context. --AFAIS
>
>Ralf's response was to a question regarding the removal of outgoing RST
>packets that are generated in reply to incoming SYN packets.  (These
>RSTs being the kind that causes the "Connection Refused" TCP message)
>
>Hence, "dropping all RST packets", should implicitly have meant, "all
>outgoing RST packets".  (The -m state ... -j DROP line is ambiguous.)

There is a corner case when communicating with certain older stacks that 
have, er, unusual takes on the RFCs regarding TCP connections.  The Bay 
Networks (now Nortel) modem concentrators want to see RSTs in response to 
an unusual probe done by the stack when closing a connection:  if I 
remember correctly those things will close the connection (using FIN) and 
then send out an empty ACK, expecting a RST back from the other end.  I 
suspect this was some programmer's bright idea to avoid having to implement 
all the "overhead" of implementing a true TIME_WAIT state for a closed 
connection.

I ran into this as the software developer for an analog modem testing 
package that tests V.90 and V.92 modems, and it caused no end of grief for 
me as the old 2.0.0 kernels didn't react the way that Bay Networks wanted 
them to.  This caused the particular modem module to go out of service for 
45 seconds, so there were several failed connection attempts as the 
multiplexor did the active timeout thing instead of just moving to a 
different 6-tuple for IP connections.

I don't know where else this "idea" might have taken hold.

Stephen Satchell
Satchell Evaluations
OTTO:3800 and LOTTO modem testing products



-- 
Human beings, who are almost unique in having the ability to learn from the 
experience of others, are also remarkable for their apparent disinclination 
to do so.  -- Douglas Adams