Date: Wed, 21 Mar 2001 17:52:55 -0500 From: "Patrick Bihan-Faou" <patrick@netzuno.com> To: "Paul Richards" <paul@freebsd-services.co.uk> Cc: <cvs-all@freebsd.org> Subject: RE: cvs commit: src/sys/netinet ip_fw.c Message-ID: <HJEEKLMFLKEOKHOKNPBMGECMCMAA.patrick@netzuno.com> In-Reply-To: <3AB92C62.45F0D213@freebsd-services.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> > The reason why having them near the end is properly more > > usefull, is because > > in a normal setup you may want to have other things done before > > the "allow > > tcp from any to me 22" that I need to ensure I don't loose access to the > > box. These things include nat, various anti-spoof rules etc. > > They should be > > done before, the new default rule should be used only when > > everything else > > is in limbo. > > That's not very safe. > > Since the rules are matched from low numbers to high then if you put > your "safety" rule at the end it might never get matched. That's > particularly a danger if you're doing NAT. > > Say using your suggestion we had the following safety rule (only part of > a complete ruleset) > > 65534 add allow ip from office_host to remote_host 22 > > When you flush you end up with your safety rule of 65534 and you're > still connected. So now you load your new rules, but you've made a > mistake so your rules are, > > 1000 divert 8668 ip from any to any via if0 > 2000 add ip form any to 10.0.0.0/8 > > At that point the reload will bomb out because of a syntax error but > you've already started diverting everything through NAT, so now your > screwed because your SSH connection is cut off. > > That's why the protected rules have to be at the bottom, you have to > ensure that your safety net is in place at all times and that everything > else is built on top of it. > With bottom == low numbers (please use a non ambiguous term, for met bottom means "the end of the ruleset" (maybe simply because high numbered rules appear at the bottom of the screen ;-) ) ) You are just pointing out that the problem is essentially not an easily solved one. Remote maintenance of a firewall is always a risky process. There will be always a new way to shoot yourself in the foot, albeit in possible even more interesting ways. FYI I usually don't test out a ruleset on a production machine that is not physically close to me for exactly that reason. So your example is also somewhat invalid (although I understand what the concept is). The proper solution to your problem would be to have the rule set commited only if all the rules were created properly. This is about syntax validation. If you have a syntax error in a C program, the compiler barfs and you don't get a bad .o that would mess up the rest of your work. It would be insane to have the compiler produce a partial output and then carry on. The same type of logic also applies for ipfw. Please not that I am not saying that you should do it today, only that your solution is at best a hack to solve a legitimate problem. An alternative solution is to have your script generate the "access" rule early on, and then let the admin disable it if necessary. This does not require a hack to make some rules "permanent". If (since) you will maintain that hack, please make it flexible enough: use a range rather than only a lower bound. Or even better add a "static" keyword to the rule definition: any rule marked static is not flushed unless specifically requested. Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?HJEEKLMFLKEOKHOKNPBMGECMCMAA.patrick>