Date: Sat, 7 Oct 2000 17:11:53 +0200 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: "freebsd-security@FreeBSD.ORG" <freebsd-security@FreeBSD.ORG> Subject: Re: Default Deny Message-ID: <20001007171153.P31338@speedy.gsinet> In-Reply-To: <39DE8D1B.923D86DF@allmaui.com>; from craig@allmaui.com on Fri, Oct 06, 2000 at 07:40:27PM -0700 References: <200010060056.LAA11152@cairo.anu.edu.au> <39DCC1CB.5FDD7F90@allmaui.com> <20001006204807.M31338@speedy.gsinet> <39DE8D1B.923D86DF@allmaui.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ citing Craig Cowen's initial message; I wish one wouldn't have
to go to the end just to learn what the answer at the top is
about at all, this puts additional (and unnecessary) load on
those you want to help you -- it doesn't always work well ]
> > > I have setup ipf with options IPFILTER_DEFAULT_BLOCK in my
> > > kernel. When using ipnat, I have 'pass in on (private
> > > interface) from 192.168.0.0/24 to any keep state' in my
> > > rules. [ ... ] I have no rules specified for the public
> > > interface. The boxen behind the firewall can surf.
On Fri, Oct 06, 2000 at 19:40 -0700, Craig Cowen wrote:
> I appreciate your response and your questions.
> Yes I did compile and install.
> You sound like me talking to my users at work.
I guess we all have been through this at least once. I found
myself in the past configuring, compiling and installing kernels,
even booting them, but not making them the default boot option.
Imagine my surprise not recognizing the machine's behaviour after
the next boot cycle (a few weeks later) ... :)
From what you stated ("I block by default, have only one
permissive rule and yet it works") there was no chance to solve
the riddle. So you either have to help those you expect to help
you with needed information or you will get accused of ignorance
and laziness (or get ignored). It's your presentation
influencing reactions. :>
> ipf -V:
> ipf: IP Filter: v3.4.8 (264)
> Kernel: IP Filter: v3.4.8
> Running: yes
> Log Flags: 0 = none set
> Default: block all, Logging: available
^^^^^^^^^
> Active list: 0
That was the important stuff I wanted to make sure. BTW the
request to do "ipf -V; ipfstat -in; etc" was meant mainly for
yourself (confirming it made its way into ipf code's tables and
gets looked up), unless you wanted to publish your setup.
To be able to read the rules, one would have to know what's your
"private interface" with the "pass in from RFC1918" rule. I
guess it's the following block:
> hope fully paronoia hasn't ruined this
> ipfstat -in
> [ ... ]
> @13 pass in on dc0 proto tcp from 192.168.1.0/24 to any keep state
> @14 pass in on dc0 proto udp from 192.168.1.0/24 to any keep state
> @15 pass in on dc0 proto icmp from 192.168.1.0/24 to any keep state
These packets make it into the machine, get NATed (the rule for
which is missing, here, but shouldn't matter very much) and have
to make their way "out into the world". This is done by these
rules:
> ipfstat -on
>
> @4 pass out log quick proto tcp from publicinterface/32 to any keep
> state #This is necassary to allow me to surf out from my firewall box
> @5 pass out log quick proto udp from publicinterface/32 to any keep
> state #with these commented out I am still able to surf from inside
> @6 pass out log quick proto icmp from publicinterface/32 to any keep
> state
And since you (or ipf, respectively) keep state, the answers are
allowed back in. I don't know what the other rules are meant
for. Maybe it should read "from 192.168.1.x/32 to
192.168.1.0/24" to say "let the fw box talk to internal
machines". (BTW they seemed to have moved since your last
message from the 0.0 net to 1.0 :)
> @7 pass out on dc0 proto tcp from 192.168.1.0/24 to 192.168.1.0/24
> @8 pass out on dc0 proto udp from 192.168.1.0/24 to 192.168.1.0/24
> @9 pass out on dc0 proto icmp from 192.168.1.0/24 to 192.168.1.0/24
I guess instead of running some more circles of catching info on
the freebsd-security list you might want to search the ipf lists
and have a look at the ipftest utility (maybe in reverse order,
ipftest is available locally, already). You feed the latter with
a description of packets you see as legitimate or to be blocked
(e.g. you describe sessions or streams) and the program tells you
what it would to to these and why. There are several modes of
verbosity and you can even use tcpdump captured descriptions when
you don't want to write them yourself. So ipftest lets you
drytest and improve your rules based on the sessions you know to
need and how they've happened.
Look around in /usr/src/contrib/ipfilter and you find more
interesting documentation, including many more examples.
> I use this to reload my settings after changes
>
> #!/bin/sh
> ipf -D
> ipf -Fa -f /etc/ipf.conf -E
> ipnat -CF -f /etc/ipnat.conf
I would prefer something like
ipf -I -Fa -f /etc/ipf.conf -v
( ipf -s; sleep 60; ipf -s; ) &
# heavy testing until the prompt returns
ipf -s # only when you're happy with what the test showed
This will make you recognize syntactic mistakes at load time
without the preceding flush for the active ruleset and works even
at remote machines and still leaves you in a working state in
case you broke your rule set (logical errors in content a parser
cannot tell you about). It's the advantage of having two
swappable rule sets, make use of it! And I wouldn't give the -F
option to ipnat as well as I wouldn't give -E to ipf when it's
about *reloading* -- see the manpages for details. Even for
initial setup -E will be wrong in case you made ipfilter integral
part of your kernel and not a module (when you block by default,
I assume you don't make ipf a module -- it's about minimizing or
even eliminating windows of vulnerability).
*plug* PR conf/20202 (rc hooks for ipf) made it into -CURRENT
yesterday and has to prove to be complete, correct and stable. I
invite ipf users to test it and provide feedback in good and bad
directions. When the patch survives one month in -CURRENT, it
could hopefully make it into 4.2R (scheduled for mid November
IIRC) or start another cycle of improvement in case it misses
something or turns out to be dangerous. :)
> [ ... deleted the fullquote ... ]
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
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?20001007171153.P31338>