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

[Chris Brenton <cbrenton@chrisbrenton.org>]

On Mon, 2005-04-11 at 17:57, Taylor, Grant wrote:
>
> The TCP RST flag looks like it can be sent with out any other flags set in the packet in such a situation where there is no known on going connection

Actually, you are usually going to see ACK set as well as the RST flab
because the receiving system is acknowledging the receipt of the packet.
The except is in reply to a non-established packet with only ACK set.
The proper response here per the RFC's is RST only.

> As to your question as to whether or not it is acceptable for firewalls to drop packets with just the RST packet set inbound to you?  I'd say that you probably should not do that b/c the RST packet is a way to tell your TCP stack that it has done something wrong.

The receipt of these packets should be pretty rare. Off the top of my
head, one possible cause would be an established session where the
remote end gets power cycled. You ACK to continue communications and the
remote end sets RST only because it has no knowledge of the session
(because the original session gets cleared during the power cycle). If
you filter out in inbound RST, you system will fail to kill the session
till it times out and issues its own RST/ACK.

> But if you choose to do this there is nothing technically wrong with it that I can see, just sort of like shooting your self

Agreed, nor is it really buying you anything. If you are maintaining
state Netfilter will dump the RST unless it matches the state table.

> iptables -t filter -A FORWARD -i $INet -o $LAN -d $LAN_Subnet -p tcp --tcp-flags RST RST -m state --state INVALID,NEW -m limit ! --limit 1/second -j LOG --log-prefix 'Bogus inbound false TCP packets with RST flag set more than one time per second!'
> iptables -t filter -A FORWARD -i $INet -o $LAN -d $LAN_Subnet -p tcp --tcp-flags RST RST -m state --state INVALID,NEW -j DROP
> iptables -t filter -A FORWARD -i $INet -o $LAN -d $LAN_Subnet -p tcp --tcp-flags RST RST -m state --state ESTABLISHED,RELATED -j ACCEPT

Hummm. Not sure this is going to do anything. INVALID will be dropped
normally and a better way to deal with NEW is to mask on SYN in your
permit rules. ESTABLISHED should already be permitted as part of a
general permit rule of the state table. 

> This is an institutional political decision as some people feel that rejecting packets in some situations confirms your presence on the net vs just dropping them leaves the possible attacker wondering.

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

HTH,
Chris