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>