Re: TCP packets with RST flag set but **not** ACK flag OK??

[Grant Taylor <gtaylor@riverviewtech.net>]

> <semi-rant>
> Actually, this is incorrect. Consider the following:
> Port is open = SYN/ACK returned
> Port is closed = RST/ACK returned
> System down = ICMP type 3, code 1 returned
> Net down = ICMP type 3, code 0 returned
> Packet blocked = ICMP type 3, code 13 returned
> Firewall with drop rule = nothing comes back
> 
> Note the *only* time you will see nothing coming back consistently is
> when a firewall is in the way. So by dropping packets, you are
> confirming the existence of a firewall. As an example, run nmap against
> a firewall with a drop policy. It will actually report that a firewall
> is in the way when nothing comes back. No head scratching required. ;-)
> 
> If you are looking to go stealthy, host unreachables (ICMP type 3, code
> 1) are a better choice. Now your firewall looks like a simple up stream
> router with no filtering in place.
> 
> Now, a drop policy does have some benefits. For example it will slow
> down a port scanner as the scanner tries to determine if its packets are
> getting lost or if there is a firewall in the way. However a default
> drop policy also has its drawbacks in that it returns nothing makes the
> address space far more appealing to an attacker to spoof as part of a
> TCP SYN flood attack (no response from your network allows them to tie
> up the connection pool for a longer period of time on the victim's
> system). So by implementing a default drop rule you are actually helping
> the attacker perform a successful flood. This one of the reasons why the
> RFC's define dropping packets as "A Bad Idea" (TM). See RFC 1812 for
> more details.
> </semi-rant>

Hmm, I will probably have to modify my firewall scripts to send back ICMP 3/1 (-j REJECT --reject-with icmp-host-unreacahbel) Responses in this case.

One reason that some institutions decide to DROP verses REJECT is so that someone can not spoof their source IP while performing some sort of attack on the institutions system expecting the REJECT to go to the spoofed source IP thus becoming part of what I think is considered a reflected attack.  Some people / institutions say yes to dropping and no to rejecting while others say no to dropping and yes to rejecting.

These issues and many more like them are some of the things that I would like to spend some more time reading about and gaining a better understanding than I presently have.  But alas I don't have the time for it unless I make it and at the moment other thing(s) (Asterisk) are higher on my priority list.  Though now that you have said something I may have to go do some RFC reading while I'm on the thinking stool.



Grant. . . .