From owner-freebsd-security Sat Oct 7 8:53:24 2000 Delivered-To: freebsd-security@freebsd.org Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by hub.freebsd.org (Postfix) with ESMTP id A14AC37B502 for ; Sat, 7 Oct 2000 08:53:20 -0700 (PDT) Received: from dialup-janus.css.qmw.ac.uk ([138.37.11.110]) by zeta.qmw.ac.uk with esmtp (Exim 3.02 #1) id 13hwHG-0003nT-00; Sat, 07 Oct 2000 16:52:47 +0100 Received: from david by dialup-janus.css.qmw.ac.uk with local (Exim 2.12 #1) id 13hwGN-000Njf-00; Sat, 7 Oct 2000 16:51:51 +0100 X-Mailer: exmh version 2.0.2 2/24/98 To: Craig Cowen Cc: "freebsd-security@FreeBSD.ORG" Subject: Re: Check Point FW-1 In-reply-to: Your message of "Sat, 07 Oct 2000 01:22:03 PDT." <39DEDD2B.E5BF4463@allmaui.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Oct 2000 16:51:51 +0100 From: David Pick Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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