Re: Dropping RST of SYN

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux