I got the following output from "ipfw show" in my daily security run output email. +++ /tmp/security.yri47lgA Mon Dec 12 03:01:45 2005 +00522 3530 1204158 deny ip from 10.0.0.0/8 to any via sis1 +02522 18 784 deny tcp from any to any in via sis1 setup +65530 0 0 deny ip from any to any +65535 2 688 deny ip from any to any Could somebody please explain to me how those packets got past rule 65530 to be stopped by (the identical) rule 65535? The ipfw rules have not changed since the machine rebooted. The only explanation I have is that the packets arrived between the time when the machine started accepting incoming packets and when the rules were loaded in /etc/rc.d/ipfw. If that's the case, it's a pretty good argument for defaulting to rejecting packets. Didn't somebody here suggest that this wasn't really necessary a few weeks ago (something to do with using pf)? Graham
On Mon, 12 Dec 2005 19:09+1100, Graham Menhennitt wrote:> The only explanation I have is that the packets arrived between the > time when the machine started accepting incoming packets and when > the rules were loaded in /etc/rc.d/ipfw.You just explained this yourself. One solution to this small problem could be to change part of the boot sequence into this: a. Create VLAN interfaces etc if configured, assign IP addresses to each configured interface, but do not UP them. b. Load the firewall rules, and optionally turn on forwarding. c. Set all configured interfaces to UP. One last question: Why do you need rule 65530 when the built-in rule 65535 does the same job? -- ---------------------------------------------------------------------- Trond Endrest?l | trond@fagskolen.gjovik.no Patron of The Art of Computer Programming| FreeBSD 4.8-S & Pine 4.55
On 12/12/05, Graham Menhennitt <gmenhennitt@optusnet.com.au> wrote:> I got the following output from "ipfw show" in my daily security run output email. > > +++ /tmp/security.yri47lgA Mon Dec 12 03:01:45 2005 > +00522 3530 1204158 deny ip from 10.0.0.0/8 to any via sis1 > +02522 18 784 deny tcp from any to any in via sis1 setup > +65530 0 0 deny ip from any to any > +65535 2 688 deny ip from any to any > > Could somebody please explain to me how those packets got past rule 65530 to be stopped by (the identical) rule 65535? The ipfw rules have not changed since the machine rebooted. The only explanation I have is that the packets arrived between the time when the machine started accepting incoming packets and when the rules were loaded in /etc/rc.d/ipfw. > > If that's the case, it's a pretty good argument for defaulting to rejecting packets. Didn't somebody here suggest that this wasn't really necessary a few weeks ago (something to do with using pf)? >This is exactly what compiling your kernel with IPFIREWALL does, it defaults to denying packets by default. You can change this behavior by adding IPFIREWALL_DEFAULT_TO_ACCEPT but is strongly discouraged. See sys/conf/NOTES ( http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/NOTES?rev=1.1337&content-type=text/x-cvsweb-markup ) for pf you need to add IPFILTER_DEFAULT_BLOCK to block packets by default. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised.
> Date: Mon, 12 Dec 2005 09:39:44 +0100 (CET) > From: Trond Endrest?l <Trond.Endrestol@fagskolen.gjovik.no> > Subject: Re: puzzling "ipfw show" output > To: FreeBSD stable <freebsd-stable@freebsd.org> > Message-ID: <20051212092932.T40542@ramstind.gtf.ol.no> > Content-Type: TEXT/PLAIN; charset=ISO-8859-1 > > On Mon, 12 Dec 2005 19:09+1100, Graham Menhennitt wrote: > > One last question: > > Why do you need rule 65530 when the built-in rule 65535 does the same > job?Having rule 65530 there allows the ruleset to function consistently on systems configured to accept by default or deny by default.
On Mon, 12 Dec 2005 22:03-0800, James Long wrote:> > Date: Mon, 12 Dec 2005 09:39:44 +0100 (CET) > > From: Trond Endrest?l <Trond.Endrestol@fagskolen.gjovik.no> > > Subject: Re: puzzling "ipfw show" output > > To: FreeBSD stable <freebsd-stable@freebsd.org> > > Message-ID: <20051212092932.T40542@ramstind.gtf.ol.no> > > Content-Type: TEXT/PLAIN; charset=ISO-8859-1 > > > > Why do you need rule 65530 when the built-in rule 65535 does the same > > job? > > Having rule 65530 there allows the ruleset to function consistently > on systems configured to accept by default or deny by default.Good point. -- ---------------------------------------------------------------------- Trond Endrest?l | trond@fagskolen.gjovik.no Patron of The Art of Computer Programming| FreeBSD 4.8-S & Pine 4.55
Graham Menhennitt <gmenhennitt@optusnet.com.au> wrote:
> I got the following output from "ipfw show" in my daily security
run output email.
>
> +++ /tmp/security.yri47lgA Mon Dec 12 03:01:45 2005
> +00522 3530 1204158 deny ip from 10.0.0.0/8 to any via sis1
> +02522 18 784 deny tcp from any to any in via sis1 setup
> +65530 0 0 deny ip from any to any
> +65535 2 688 deny ip from any to any
>
> Could somebody please explain to me how those packets got past rule 65530
to be
> stopped by (the identical) rule 65535?
In addition to the explanations already given, the above
output from "ipfw show" could also be caused by a rule
saying "skip 65535" somewhere. ;-)
Of course, I assume that you wrote the whole rule set
yourself, so you would be aware of such a skip rule.
I just wanted to mention the possibility that rules need
not be evaluated in strict numerical order.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"C++ is the only current language making COBOL look good."
-- Bertrand Meyer