tcp match silently drops packets

tcp match silently drops packets

[Philip Craig]

If you send a 20 byte IP packet that has the protocol set to 6,
(ie TCP packet with no TCP header) then the following rule will match:

iptables -I FORWARD -p tcp

and the following rule will match and silently drop the packet:

iptables -I FORWARD -p tcp --syn

I think the behaviour of the first rule is fine, but the second one
should simply not match.  These packets probably should be dropped,
but this is a policy decision, and shouldn't be implemented in the
tcp match.  And if it must drop it, then a log message or counter
somewhere would be nice.

Conntracking marks the packet as INVALID, so you can use that to
drop it, and also log it if desired.

This isn't a big issue for me.  I had a TCPMSS rule before the INVALID
check, so I just need to reorder that.

There is a similar issue in TCPMSS itself: it has a few tests
that drop the packet.  In particular, it drops TCP SYN packets that
contain data.  Since TCPMSS isn't a firewall match (it is a hack to
try to avoid dropped packets), I don't think it makes sense for
it to drop packets that it can't handle.  I can submit a patch for
this if needed.

(Note: I tested this on 2.4.31.  There was some change to the tcp
hotdrop code as part of the skb linearization in 2.6, but from
reading the code, the behaviour looks the same.)

Re: tcp match silently drops packets

[Yasuyuki KOZAKAI]

Hi, Philip,

From: Philip Craig <philipc@snapgear.com>
Date: Mon, 10 Oct 2005 13:01:14 +1000

> If you send a 20 byte IP packet that has the protocol set to 6,
> (ie TCP packet with no TCP header) then the following rule will match:
> 
> iptables -I FORWARD -p tcp
> 
> and the following rule will match and silently drop the packet:
> 
> iptables -I FORWARD -p tcp --syn
>
> I think the behaviour of the first rule is fine, but the second one
> should simply not match.  These packets probably should be dropped,
> but this is a policy decision, and shouldn't be implemented in the
> tcp match.  And if it must drop it, then a log message or counter
> somewhere would be nice.

I cannot reproduce this situation with linux-2.4.31 and recent iptables.
tcp_match() return 0 for such packet because it doesn't have tcp header and
datalen is 0.

	if (offset == 1) {
		duprintf("Dropping evil TCP offset=1 frag.\n");
		*hotdrop = 1;
		return 0;
	} else if (offset == 0 && datalen < sizeof(struct tcphdr)) {
		/* We've been asked to examine this packet, and we
		   can't.  Hence, no choice but to drop. */
		duprintf("Dropping evil TCP offset=0 tinygram.\n");
		*hotdrop = 1;
		return 0;
	}

Could you tell me what you mean 'match and silently drop' in detail ?

Regards,
-----------------------------------------------------------------
Yasuyuki Kozakai @ USAGI Project <yasuyuki.kozakai@toshiba.co.jp>

Re: tcp match silently drops packets

[Henrik Nordstrom]

On Sun, 16 Oct 2005, Yasuyuki KOZAKAI wrote:

> I cannot reproduce this situation with linux-2.4.31 and recent iptables.
> tcp_match() return 0 for such packet because it doesn't have tcp header and
> datalen is 0.
>
> 	if (offset == 1) {
> 		duprintf("Dropping evil TCP offset=1 frag.\n");
> 		*hotdrop = 1;
> 		return 0;
> 	} else if (offset == 0 && datalen < sizeof(struct tcphdr)) {
> 		/* We've been asked to examine this packet, and we
> 		   can't.  Hence, no choice but to drop. */
> 		duprintf("Dropping evil TCP offset=0 tinygram.\n");
> 		*hotdrop = 1;
> 		return 0;
> 	}
>
> Could you tell me what you mean 'match and silently drop' in detail ?

The above code forces such packets to be dropped with no visible traces to 
why. (*hotdrop = 1, and also hinted by the debug message and comment)

What he ment was "the match will silently drop the packet", not that the 
rule as such will match the packet..

Regards
Henrik

Re: tcp match silently drops packets

[Henrik Nordstrom]

On Sun, 16 Oct 2005, Henrik Nordstrom wrote:

> The above code forces such packets to be dropped with no visible traces to 
> why. (*hotdrop = 1, and also hinted by the debug message and comment)

Just a comment on why the tcp port match hotdrops "too small" packets:

The reason why this match hotdrops such packets is to deal with attacks 
using fragmented packets in a reasonably secure manner without having to 
rely on "UNCLEAN" or similar. A TCP packet so small that it does not even 
include the TCP header is below the minimum MTU allowed and you should not 
see any such fragments in normal traffic.

As the match can not tell it it matches or not when the packet is 
fragmented in this odd manner the safest path is taken to drop the packet 
on the floor, preventing hackers to too easily bypass the firerewall rule 
by using unnaturally fragmented IP packets.

For the exact same reason the match also hotdrops fragments which would 
overwrite the TCP header.

In theory just the second criteria is a must (drop fragments which could 
override an earlier decision), but as it's there the first also makes 
sense to drop the first as we can not allow a fragment filling in the 
missing pieces.

The third hotdrop condition in the tcp_match is perhaps a bit more 
questionable (hotdrop if rule looks for an tcp option, and the data 
pointer is corrupted).

The fourth hotdrop condition can very much be questioned. (hotdrop if 
matching for an tcp option and not all options fit in the first fragment). 
The list of TCP options can get farily long, especially if some 
experimental options are used and there may in theory be perfectly natural 
cases where the IP packet got fragmented within the options  (in practise 
no such large amounts of tcp options are used making this a problem..)

Regards
Henrik

Re: tcp match silently drops packets

[Herbert Xu]

Henrik Nordstrom <hno@marasystems.com> wrote:
> 
> The reason why this match hotdrops such packets is to deal with attacks 
> using fragmented packets in a reasonably secure manner without having to 
> rely on "UNCLEAN" or similar. A TCP packet so small that it does not even 
> include the TCP header is below the minimum MTU allowed and you should not 
> see any such fragments in normal traffic.

Not having any TCP header at all or not having the complete TCP header?

The latter is possible because the minimum fragment payload length is
8 bytes.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: tcp match silently drops packets

[Philip Craig]

On 10/17/2005 03:35 AM, Henrik Nordstrom wrote:
> What he ment was "the match will silently drop the packet", not that the 
> rule as such will match the packet..

That's right.  I worded that rather poorly.

Re: tcp match silently drops packets

[Philip Craig]

On 10/17/2005 07:07 AM, Henrik Nordstrom wrote:
> Just a comment on why the tcp port match hotdrops "too small" packets:

Thanks for the explanation.

What is the best way to log these then?
Perhaps modify the dropped table patch to catch hotdrops?

Re: tcp match silently drops packets

[Henrik Nordstrom]

On Mon, 17 Oct 2005, Philip Craig wrote:

> What is the best way to log these then?

Good question.

> Perhaps modify the dropped table patch to catch hotdrops?

Hasn't the dropped table been abandoned entirely?

Today there is no logging of hotdropped packets from what I can tell. But 
adding a log function on hotdropped packets should not be very hard.. look 
for "if (hotdropped)" in ip_tables.c.

Regards
Henrik

Re: tcp match silently drops packets

[JC]

> For the exact same reason the match also hotdrops fragments which would
> overwrite the TCP header.
>
> In theory just the second criteria is a must (drop fragments which could
> override an earlier decision), but as it's there the first also makes
> sense to drop the first as we can not allow a fragment filling in the
> missing pieces.

Could someone please explain these two?

Re: tcp match silently drops packets

[Henrik Nordstrom]

On Mon, 17 Oct 2005, JC wrote:

>> For the exact same reason the match also hotdrops fragments which would
>> overwrite the TCP header.
>>
>> In theory just the second criteria is a must (drop fragments which could
>> override an earlier decision), but as it's there the first also makes
>> sense to drop the first as we can not allow a fragment filling in the
>> missing pieces.
>
> Could someone please explain these two?

An IP fragment with offset 1 can overwrite parts of the TCP header, and if 
this check is not there an attacker could bypass port matches in iptables 
by sending the packet in two fragments where the first fragment (which is 
used by the tcp match) has ports which is allowed by the ruleset and later 
the second fragment (which is ignored by the tcp match) overwrites the 
port numbers with ports which would not be allowed by the ruleset.

Regards
Henrik

Re: tcp match silently drops packets

[JC]

On 17/10/05, Henrik Nordstrom <hno@marasystems.com> wrote:
> On Mon, 17 Oct 2005, JC wrote:
>
> >> For the exact same reason the match also hotdrops fragments which would
> >> overwrite the TCP header.
> >>
> >> In theory just the second criteria is a must (drop fragments which could
> >> override an earlier decision), but as it's there the first also makes
> >> sense to drop the first as we can not allow a fragment filling in the
> >> missing pieces.
> >
> > Could someone please explain these two?
>
> An IP fragment with offset 1 can overwrite parts of the TCP header, and if
> this check is not there an attacker could bypass port matches in iptables
> by sending the packet in two fragments where the first fragment (which is
> used by the tcp match) has ports which is allowed by the ruleset and later
> the second fragment (which is ignored by the tcp match) overwrites the
> port numbers with ports which would not be allowed by the ruleset.

and that doesnt get picked up by conntrack as a different connection??

Re: tcp match silently drops packets

[Henrik Nordstrom]

On Mon, 17 Oct 2005, JC wrote:

> and that doesnt get picked up by conntrack as a different connection??

conntrack always refragments packets completely, making this largely a 
non-issue.

the hotdrop is only when you use the tcp match without conntrack.

Regards
Henrik

Re: tcp match silently drops packets

[Cedric Blancher]

Le lundi 17 octobre 2005 à 15:52 +0200, Henrik Nordstrom a écrit :
> An IP fragment with offset 1 can overwrite parts of the TCP header, and if 
> this check is not there an attacker could bypass port matches in iptables 
> by sending the packet in two fragments where the first fragment (which is 
> used by the tcp match) has ports which is allowed by the ruleset and later 
> the second fragment (which is ignored by the tcp match) overwrites the 
> port numbers with ports which would not be allowed by the ruleset.

I always though conntrack was defragmenting datagrams before filtering.
Thus, if we filter on defragmented datagrams, then we can't get foold by
fragmentation overlapping based attacks. Am I wrong ?


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: tcp match silently drops packets

[JC]

> > and that doesnt get picked up by conntrack as a different connection??
>
> conntrack always refragments packets completely, making this largely a
> non-issue.
>
> the hotdrop is only when you use the tcp match without conntrack.

ok, got you. thanx for the explanation

JC

Re: tcp match silently drops packets

[Henrik Nordstrom]

On Mon, 17 Oct 2005, Herbert Xu wrote:

>> The reason why this match hotdrops such packets is to deal with attacks
>> using fragmented packets in a reasonably secure manner without having to
>> rely on "UNCLEAN" or similar. A TCP packet so small that it does not even
>> include the TCP header is below the minimum MTU allowed and you should not
>> see any such fragments in normal traffic.
>
> Not having any TCP header at all or not having the complete TCP header?

Not having the complete TCP header (excluding TCP options unless you 
also match for options).

> The latter is possible because the minimum fragment payload length is
> 8 bytes.

Yes, but not if the minimum allowed MTU of the available transports (not 
including ATM) is accounted for. If you account for the minimum allowed 
MTU on these transports then the smallest possible fragment is a bit 
larger and these very small fragments is only seen if explicitly created 
by "hacker" or similar trying to avoid packet filters (and quite 
succesfully so in many simpler implementations).

Regards
Henrik

Re: tcp match silently drops packets

[Herbert Xu]

On Mon, Oct 17, 2005 at 09:30:21PM +0200, Henrik Nordstrom wrote:
> 
> >The latter is possible because the minimum fragment payload length is
> >8 bytes.
> 
> Yes, but not if the minimum allowed MTU of the available transports (not 
> including ATM) is accounted for. If you account for the minimum allowed 
> MTU on these transports then the smallest possible fragment is a bit 
> larger and these very small fragments is only seen if explicitly created 
> by "hacker" or similar trying to avoid packet filters (and quite 
> succesfully so in many simpler implementations).

This is not true if tunnels are involved.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: tcp match silently drops packets

[Henrik Nordstrom]

On Tue, 18 Oct 2005, Herbert Xu wrote:

> This is not true if tunnels are involved.

True, and perhaps the tcp match should be relaxed slightly to only hotdrop 
packets if it's the first fragment and what is needed to evaluate the 
match is not there..

The port matches can evaluate just fine if the first fragment is minimal. 
It's only the flags matches etc which would fail (and drop the packet 
to be safe)..

Regards
Henrik

Re: tcp match silently drops packets

[Herbert Xu]

Henrik Nordstrom <hno@marasystems.com> wrote:
> 
> An IP fragment with offset 1 can overwrite parts of the TCP header, and if 

IP fragment offset is measured in units of 8 bytes so this can't happen.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: tcp match silently drops packets

[Henrik Nordstrom]

On Tue, 18 Oct 2005, Herbert Xu wrote:

> Henrik Nordstrom <hno@marasystems.com> wrote:
>>
>> An IP fragment with offset 1 can overwrite parts of the TCP header, and if
>
> IP fragment offset is measured in units of 8 bytes so this can't happen.

I know. I tried to correct myself in a later message. The port numbers can 
not be overwritten by fragments, but the TCP flags such as SYN can. The 
first 8 bytes only contains the ports and sequence number.

Regegards
Henrik