thanks for the info. I found another howto, which I based my new firewall off - http://cgi.afc.no-ip.info/svnwiki.cgi/default/firewalls
I am no longer doing anything with tcp options, and this current howto seems a bit more secure. I also liked the layout of creating chains, and adding them to INPUT/OUTPUT/FORWARD instead of doing everything directly in those 3 primary chains. again, thanks for the help, and I believe I am on my way to putting in a new firewall that's much more secure than my old one. (The old machine simply had masquerading and port forwarding, and as such didn't really count as a firewall) -rp ----- Original Message ----- From: "Daniel Pittman" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, August 23, 2005 6:20 PM Subject: Re: iptables --tcp-option ! 2 > "Doug" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
