From owner-freebsd-security Sun Oct 8 4:21:58 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 01B7637B503 for ; Sun, 8 Oct 2000 04:21:44 -0700 (PDT) Received: (qmail 19769 invoked by uid 0); 8 Oct 2000 11:21:41 -0000 Received: from unknown (HELO speedy.gsinet) (213.21.23.82) by mail.gmx.net with SMTP; 8 Oct 2000 11:21:41 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id RAA12972 for freebsd-security@FreeBSD.ORG; Sat, 7 Oct 2000 17:11:53 +0200 Date: Sat, 7 Oct 2000 17:11:53 +0200 From: Gerhard Sittig To: "freebsd-security@FreeBSD.ORG" Subject: Re: Default Deny Message-ID: <20001007171153.P31338@speedy.gsinet> Mail-Followup-To: "freebsd-security@FreeBSD.ORG" References: <200010060056.LAA11152@cairo.anu.edu.au> <39DCC1CB.5FDD7F90@allmaui.com> <20001006204807.M31338@speedy.gsinet> <39DE8D1B.923D86DF@allmaui.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <39DE8D1B.923D86DF@allmaui.com>; from craig@allmaui.com on Fri, Oct 06, 2000 at 07:40:27PM -0700 Organization: System Defenestrators Inc. Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ 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