Date: Sat, 07 Oct 2000 16:51:51 +0100 From: David Pick <D.M.Pick@qmw.ac.uk> To: Craig Cowen <craig@allmaui.com> Cc: "freebsd-security@FreeBSD.ORG" <freebsd-security@FreeBSD.ORG> Subject: Re: Check Point FW-1 Message-ID: <E13hwGN-000Njf-00@dialup-janus.css.qmw.ac.uk> In-Reply-To: Your message of "Sat, 07 Oct 2000 01:22:03 PDT." <39DEDD2B.E5BF4463@allmaui.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> They are going to put it on an NT machine. > They don't trust ipfilter or anything else that is not commercial. > Maybe I could get some suits to guarentee it with a corporate label. You can certainly get a support contract for FreeBSD - speak to BSDi. I don't know if ipfilter would need to be specifically included or if it is covered as a part of FreeBSD. I'd also point out that in many cases the *real* situation is not that thet don't trust anything that's not commercial; they don't trust alything *at all* and are really concerned that there is some external company that can point the finger of blame at and/or sue when/if anything untoward *does* happen. The other, less common, situtation I've seen is that the bosses don't want their local "expert" to be a real expert on whom they depend; they're frightened you'll be able to override them with *their* bosses and/or that you'll demand more money and make their budget(s) look bad; or even earn more money than they do... (Slightly) changing the subject: I've been looking at ipfilter myself recently although I wouldn't claim to be an expert, and I'd make the following comments on the rules you posted recently: 1) If the three rules you commented as "to keep the guys at work out explicitly" are intended to keep a separate set of counts, &c, from the next three rules that block *any* source; then I *think* you need to reverse the two blocks of three because you havn't used the "quick" keyword, and without that the rule that gains the credit is the *last* rule that matches. 2) There's very little point in using "keep state" for *tcp* unless you're doing so on the first call-setup packet. A "keep state" that gets triggered on a subsequent packet will cause a state table entry with incomplete status information and this will time out rather more quickly, causing calls to jam for no good reason. -- David Pick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E13hwGN-000Njf-00>