From owner-freebsd-security Sun Feb 25 4:13: 5 2001 Delivered-To: freebsd-security@freebsd.org Received: from btclick.com (mta01.btfusion.com [62.172.195.11]) by hub.freebsd.org (Postfix) with ESMTP id 932AC37B401 for ; Sun, 25 Feb 2001 04:12:58 -0800 (PST) (envelope-from marcr@closed-networks.com) Received: from fubar.closed-networks.com ([213.123.161.77]) by btclick.com (Netscape Messaging Server 4.05) with ESMTP id G9BB9J01.017 for ; Sun, 25 Feb 2001 12:12:55 +0000 Message-Id: <5.0.2.1.0.20010225114958.00b10858@pop3.demon.co.uk> X-Sender: myphone@pop3.demon.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 25 Feb 2001 12:13:18 +0000 To: freebsd-security@FreeBSD.ORG From: Marc Rogers Subject: Re: /etc/rc.firewall fixes In-Reply-To: <3A982224.893F76AF@gorean.org> References: <200102202005.f1KK5kv83619@medusa.kfu.com> <3A93A9CC.BC1D39FB@algroup.co.uk> <3A93C2FB.3E160997@ocsinternet.com> <3A94AE05.965BC5E4@gorean.org> <3A9526AA.19D00D47@ocsinternet.com> <3A954152.C7887C3@gor.com> <3A97A4E6.C53ECF27@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 13:05 24/02/2001 -0800, Doug Barton wrote: >Adam Laurie wrote: > > > > Doug Barton wrote: > > > > > > Mikel King wrote: > > > > > > > > rc.conf.local and rc.local weree deprecated around the release of 4.x. > > > > > > Don't be silly. Both are fully supported, and there is no > plan to remove > > > support at any time in the future (and I will vigorously oppose any > plan to > > > do so). The only thing that has actually changed is that the system no > > > longer ships with an rc.local file installed. > > > > so what's the point in putting it in there instead of rc.conf then? > > The original question I responded to suggested putting the > settings for >rc.firewall into a whole new conf file. My point was that there were >already several locations that would be more appropriate. > >Doug I agree. This thread seems to have gotten sidetracked. Im still going to chuck in my two-pence worth though.... "Typically, the /usr/local/etc/rc.d mechanism is used instead of rc.local these days but if you do want to use rc.local, /etc/rc still supports it. In this case, rc.local should source /etc/rc.conf and contain additional custom startup code for your system." - /usr/bin/man "The file /etc/rc.conf.local is used to override settings in /etc/rc.conf for historical reasons." - /usr/bin/man If my interpretation of that is correct, then rc.local and rc.conf.local have been left in to support people with existing setups so they don't have to move to the preferred rc.d mechanism immediately. The simple fact that they have been left in for historical reasons & alternative newer mechanisms suggested means to me that they have been depreciated. Thats just my interpretation though. Also, and more importantly rc.local / rc.conf.local / rc.d are there for "local" configurations. What we are discussing here is a potential commit to all FreeBSD configurations and as such would be far more appropriately placed within the rc.conf mechanism. anyway thats my two-pence worth on that. I would like to see configuration code for ipfw AND ipfilter placed into rc.conf (and thus ipnat as well as natd). Anyway I wont hold my breath for a commit. By the way keeping state on UDP connections is a bad idea. UDP is stateless. Tyring to make it otherwise opens you up to all kinds of abuse...... "Held UDP state is timed out, as is TCP state for entries added which do not have the SYN flag set. If an entry is created with the SYN flag set, any subsequent matching packet which doesn't have this flag set (ie a SYN-ACK) will cause it to be "timeless" (actually, the timeout defaults to 5 days), until either a FIN or RST is seen" -http://coombs.anu.edu.au/~avalon/examples.html#packetstate Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message