Date: Thu, 16 Dec 1999 15:39:58 +0100 From: "BSDman" <usebsd@free.fr> To: "Brendan Conoboy" <synk@swcp.com>, <freebsd-security@FreeBSD.ORG> Subject: RE: rc.firewall, ipf integration Message-ID: <NDBBJDFPGLMLFHLNEEOMMEEEDDAA.usebsd@free.fr> In-Reply-To: <199912102133.OAA17684@inago.swcp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Brendan Conoboy wrote: > ... Part of the reason > for this seems to be a lack of documentation, thus I embarked on > writing the ipf howto. The howto is coming along nicely, but freebsd's > support for ipf doesn't seem to have come along much at all. great! wouldn't this be a good chapter in the handbook? > 2) rc.firewall is being taken seriously as an effective firewall: > > As a learning aid, rc.firewall isn't bad, but it's letting things > in by default that it really shouldn't. I know people want to be > able to turn on a service and have it go, and that's why at present > rc.firewall lets in port 25, 53, 80, 123, but should it really be > doing that if those services aren't running? Shouldn't ipf support > be in rc.firewall too? > 3) rc.firewall doesn't get its configuration from rc.conf: > > The beginning of each set of rules in rc.firewall requires > the setup of what interface, network, netmask, and IP address, > then goes on to assume what ports need to be blocked and passed. > I know that a fine grain firewall requires all that information > and it can't just be guessed at what interface to apply a rule > to, but we could certainly change rc.firewall to only open port > 25/tcp when sendmail_enable is YES and sendmail_flags contains > -q[0-9]+[mh] (probably wrong, but you get the idea). > > The bottom line is, I'd like to see rc.firewall be more useful out > of the box to ipfw and ipf users alike. Whether that means rc.firewall > includes complex logic based on rc.conf, or rc.conf gets a new line > like: > > firewall_allowin="tcp/25/tun0,udp/53,tcp/53,tcp/80" > > or both, it can definitely be better than it is. > You cannot decide to allow smtp connections based on sendmail_enable. here are some cases where this variable does not help: - assume you run sendmail on an internal host (which may have a public address). then you'll allow smtp connections to that host though sendmail is not running on the firewall. - assume you don't wanna run sendmail, but you're using some other program (qmail or a proxy or anything that can hanle smtp). Then you'd like to allow smtp connections. Th ething is that the rc* variables such as sendmail_enable help decide whether a program is to be run at startup or not; and this is a domain which is completely independent of any firewall questions. so it's good to keep different things different. The rc* files (and other config/script files) concern the system, while ipf/firewalling concern the control of traffic between two networks separated by the host in question. while using the rc* variables may seem to ease admin/config of the system, it does not as it would mix things that should not, and also, the "rc grammar" is too much "basic". My suggestion is that the admin should decide to either allow everything or deny everything by default; and then add explicit rules by editing rc.firewall. But you're right, the rc.firwall is not easy for "everybody" (nor are mkfilter things and the like). a gui to handle itshould be a nice thing (at least, a console-based one). mouss Free your Net with BSD 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?NDBBJDFPGLMLFHLNEEOMMEEEDDAA.usebsd>