From owner-freebsd-questions@FreeBSD.ORG Thu Jun 17 19:28:50 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 112F116A4CE for ; Thu, 17 Jun 2004 19:28:50 +0000 (GMT) Received: from frodo.otenet.gr (frodo.otenet.gr [195.170.0.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F0E243D55 for ; Thu, 17 Jun 2004 19:28:47 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-b148.otenet.gr [212.205.244.156]) by frodo.otenet.gr (8.12.10/8.12.10) with ESMTP id i5HJS0XO007885; Thu, 17 Jun 2004 22:28:04 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.12.11/8.12.11) with ESMTP id i5HJRxbx000962; Thu, 17 Jun 2004 22:27:59 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.12.11/8.12.11/Submit) id i5HJRtGW000961; Thu, 17 Jun 2004 22:27:55 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Thu, 17 Jun 2004 22:27:55 +0300 From: Giorgos Keramidas To: "Reuben A. Popp" Message-ID: <20040617192755.GA936@gothmog.gr> References: <200406151832.10733.gobinau@digitalcelt.net> <20040616053526.GA21650@gothmog.gr> <200406161705.05309.gobinau@digitalcelt.net> <20040617071916.GA11923@orion.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406161705.05309.gobinau@digitalcelt.net> cc: freebsd-questions@freebsd.org Subject: Re: ipfw question X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 19:28:50 -0000 Hi Reuben, Sorry for taking so long to reply. My workstation at work which still runs Fedora Core RC3 and not a real OS, like FreeBSD, decided to throw away all outgoing email this morning. Here's a repost extracted from my =posted mailbox in Mutt [...] On 2004-06-16 17:04, "Reuben A. Popp" wrote: > I believe that what I have is correct, and everything seems to be > working well, with a few exceptions. For instance, ftp and ssh still > don't seem to make it into the logs, although the mail, web and > web-ssl do with no problems. Again, following this message is my > revised ruleset. Strange. All incoming they should be logged. Unless, of course, you mean ftp and ssh connections that *you* start to the outside world, in which case by reading the ruleset you will note that they are allowed unconditionally, without logging, by a rule higher up the chain: # Add all TCP connections that originate from us ipfw add allow tcp from any to any out setup keep-state # Pass and log all incoming ftp-data connections. ipfw add allow log tcp from any 20 to any in setup keep-state # Pass and log all incoming connections to: ftp, ssh, mail and www. ipfw add allow log tcp from any to any 21,22,25,80,443 in setup keep-state Since this doesn't log anything, all connections that your machine starts towards another machine are passed through without logging. If you want to log specific connections, you should use something like this instead: # Log ftp and ssh connections that we make. ipfw add allow log tcp from any to any 21,22 out setup keep-state # Let any other outgoing connections through, unlogged. ipfw add allow tcp from any to any out setup keep-state Note that you also have some rules that are useless in there. Trim your ruleset a bit ;-) The general idea with stateful filtering is that you set up a few connections that are allowed to pass through and then let the packets related to those connections pass too, but *nothing* else. This is why the general form of a stateful firewall with IPFW should be: << rules that check states first >> << rules that selectively pass connections *and* create states >> << everything else blocked >> This way only the packets related to one of the states will pass through. Any other packets that require special handling (for instance, ICMP packets) can be handled by other rules. In your ruleset you have this: # First of all state checking. This will allow through any packet # that is marked as "legitimate" by one of the following rules. ipfw add check-state ipfw add deny tcp from any to any established # Add all TCP connections that originate from us ipfw add allow tcp from any to any out setup keep-state which should work without problems, and then you have: # Allow TCP through if setup succeeded ipfw add pass tcp from any to any established This rule will never match with anything, since packets that could possibly match are blocked by the 'established' rule right after check-state above. You can safely delete this rule. Then you have this rule, that handles fragments in a special manner, which is not very useful. # Allow IP fragments to pass through ipfw add pass all from any to any frag AFAIK, any fragment that is related to an existing connection should match with the check-state rule and will never reach this part of the ruleset. I think this can go too. Finally, this rule is absolutely *not* good. You've gone through all the trouble to set up a stateful firewall so as NOT to be forced to allow any incoming TCP connection through. This single rule lets all the connections through, effectively cancelling all of your filtering rules :-( # Allow setup of any other TCP connection ipfw add pass tcp from any to any setup You should definitely delete this one. IMHO, it's a good idea to replace it with a more strict rule like this: # BLock everything else. ipfw add deny ip from any to any If you're too worried that this might break applications or protocols that you're using now, try adding a "log" keyword to this last rule and watch your system logs for dropped packets that are useful and should have been allowed. Then add special rules just for those packets. Regards, - Giorgos