Date: Mon, 6 May 2002 11:45:55 +0200 From: "Karsten W. Rohrbach" <karsten@rohrbach.de> To: Jens Rehsack <rehsack@liwing.de> Cc: Michael Riexinger <mailinglists@grindking.de>, freebsd-stable@freebsd.org Subject: Re: ipfilter problem Message-ID: <20020506114555.C91849@mail.webmonster.de> In-Reply-To: <3CD64534.672CD6A7@liwing.de>; from rehsack@liwing.de on Mon, May 06, 2002 at 10:56:20AM %2B0200 References: <20020504223450.GA1025@grind.grind.dom> <20020505152314.B73550@mail.webmonster.de> <20020505133204.GA667@grind.grind.dom> <20020505184630.A76286@mail.webmonster.de> <3CD5B662.26298116@liwing.de> <20020506020820.A82377@mail.webmonster.de> <3CD64534.672CD6A7@liwing.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable for michael's setup i'd add the following at the very beginning of the rule set: # block packets with ip options / short tcp packets block in log quick on isp0 from any to any with ipopts block in log quick on isp0 proto tcp from any to any with short just to be more complete. IIRC, these ones are covered somewhere in the FAQ. Jens Rehsack(rehsack@liwing.de)@2002.05.06 10:56:20 +0000: > Because of the position of the dynamic added rule there seems sometimes p= roblems... huh? on ipfilter dynamic rules are always processed before the actual rule set you supply. the definition of "dynamic rules" for ipf is "state". see http://coombs.anu.edu.au/~avalon/ipfil-flow.html it is a matter of _how_ you add state, please read on. > block in all block in on isp0 all # if you just want to block incoming traffic # from the isdn interface > pass in quick on isp0 proto tcp from any to any port =3D 80 keep state pass in quick on isp0 proto tcp from any to any port =3D 80 flags S/SA keep= state # we want state added when establishing a # session, not for every tcp packet that passes # this rule you're perfectly right in this scenario where you allow packets to pass with "quick" rules and do a general "block all" rule that isn't "quick". for people new to ipfilter, it is quite a challenge to get the concept of its two ways of processing rules ("quick" vs. "last match"), that's why i try to stick to linear "quick" setups for trivial things such as a simple gateway firewall. > Does the same as above, but it's really more intuitive (for me): > block in all except to (port 80/tcp [, ...]), they are ok. adding tcp packet state without matching tcp flags causes that you add a state for every subsequent packet in a session. this doesn't really make sense. don't try your rules on a live firewall with a heavily loaded web server behind it - your state table will fill up quite fast ;-) > > the main problem here might be that he just had _one_ line for _both_ > > protocols, tcp and udp, which might lead to trouble in several points. > > that's a totally different thing. > I have this too, and there is no problem anywhere. Of course, it could be. from my experiences (with firewall code different to ipfilter), it often is a problem if you combine protocols in one rule. think about how tcp and udp state is kept; it's a totally different story for both protocols. in ipfilter, tcp can be tracked easily because tcp already has state. udp is tracked by states that simply time out at some point in time with a somewhat different strategy, udp being stateless in its nature. bottom line:=20 two protocols -> two different concepts of processing =3D two different rules > But I got the idea of changed position of dynamic rules inserting (could > be speed up permormance, AFAIK, depending on internal structures). yup, but you need quite some throughput to really notice a difference... on an isdn router you will hardly notice a difference, it's limited to one or some channels of 64kbit/s which is a piece of cake for nearly every modern firewall implementation out there. > Reading is ok, understanding is ok (as long I can identify the letters :-= )), but > nevertheless I will not write a ruleset to late and use without checking = it > next morning. heh, yep... also, as a sidenote, ipftest(1) is your friend, regardless of the level of intoxication ;-) regards, /k --=20 > Microsoft isn't the answer. Microsoft is the question, and the answer is = no. WebMonster Community Project -- Next Generation Networks GmbH -- All on BSD http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n= et/ GnuPG: 0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4 A113 B393 6BF4 DEC9 48A6 REVOKED: 0x2964BF46 D/E 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 REVOKED: 0x4C44DA59 RSA F9 A0 DF 91 74 07 6A 1C 5F 0B E0 6B 4D CD 8C 44 My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ Please do not remove my address from To: and Cc: fields in mailing lists. 1= 0x --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: For info see http://www.gnupg.org iD8DBQE81lDTs5Nr9N7JSKYRAj9iAJ97dnJZSB6AAN9/qu32e3+J7I1eRACgokM6 FdHDtRu5qzxpbS4GxFXiRN0= =cXqt -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020506114555.C91849>