Re: Thanks! Re: iptables --tcp-option ! 2

I saw this thread and just incase you haven't progressed any further with
research (if any) on why you may want to use said option, I thought I'd
mention what I understand it to be used for ...

A line such as the one used in the stock openwrt firmware reads:

iptables -A INPUT -p tcp --tcp-flags SYN SYN --tcp-option \! 2 -j DROP

Checks the validity of a SYN packet.

You can see quite obviously how powerful it could be if you were to align
this kind of mask to attacks that break RFC. More useful in a production
environment than anywhere else ;)

Sarton

> "Doug" <SupportList@dougtheslug.ca> writes:
>
> > I keep seeing this in firewall scripts on the net, but I am unable to
> > find an explanation or listing/table of tcp-options. The command in
> > question is the following
> >
> > iptables -A INPUT -p tcp --tcp-option ! 2 -j REJECT --reject-with
tcp-reset
> >
> > Why are [we] only allowing tcp-options of 2?
>
> I have no earthly idea, since this is going to make your life *way*
> miserable, especially on asymmetric like the common ADSL services.
>
> > what are tcp packets with option 2?
>
> Option 2 is the "Maximum Segment Size" option, which tells the computer
> what size, at most, the data part of the packet should be.
>
> > what are the other options, and why do we not want them?
>
> http://www.networksorcery.com/enp/protocol/tcp.htm#Options
>
> I see no options in that list that you do not want. A number of them,
> like SACK and window scaling, will make your life very miserable if you
> do reject them in this way, since they are standard features of the
> initial connection attempt.
>
> Rejecting the packets like that will, for example, completely prevent my
> system here talking to a server on your system, since it will send a
> SACK and window scaling option by default...
>
> > I'm sure it's safe, and likely a good idea to have in, given the
> > number of tutorials that have it in,
>
> Ho-ho-ho. Nope. Very broken. If you want to know why, have a quick
> check on the history of ECN deployment and the problems that a similar
> assumption about reserved fields in the IP header had.
>
> > but I just dislike the idea of having something in my to be firewall
> > script that I have little understanding of.
>
> That is /such/ a nice attitude to run into. Most people blindly copy
> this sort of problematic garbage without any though about /why/ they
> might want to do it.
>
> Anyway, the executive summary: people who recommend a line like that
> are giving you bad, stupid advice that *will* break your ability to
> communicate with some proportion of the Internet.
>
> Don't do it.
> Daniel
>
>
>
> --
> To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
>

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org