From owner-freebsd-hackers Tue Jun 3 17:09:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA03231 for hackers-outgoing; Tue, 3 Jun 1997 17:09:35 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03226 for ; Tue, 3 Jun 1997 17:09:32 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id SAA17345; Tue, 3 Jun 1997 18:09:10 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id SAA28483; Tue, 3 Jun 1997 18:01:37 -0600 (MDT) Date: Tue, 3 Jun 1997 18:01:37 -0600 (MDT) From: Marc Slemko To: "Daniel O'Callaghan" cc: Harlan Stenn , hackers@FreeBSD.ORG Subject: Re: Improvements to rc.firewall? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 4 Jun 1997, Daniel O'Callaghan wrote: > > On Tue, 3 Jun 1997, Harlan Stenn wrote: > > > H> I checked this out by doing a tcpdump of my ppp link, and looked at > > H> all of the DNS traffic. Responses to my queries came in to *my* port > > H> 53. > > > > dOc> Are you running your own named locally? That would be why. > > > > Yes, I am. Thanks for the explanation. > > > > Perhaps we should explain that of somebody wants a working firewall > > they'll have to run a local (caching or forwarding only, even) > > nameserver, too. > > It depends on how "working" a firewall you need. If you don't run a > local nameserver, you can simply deny all udp packets arriving with src port > 53 which don't come from the name server defined in /etc/resolv.conf. > If you want to run your own caching named, add a forwarder and the word > 'slave' to your /etc/named.boot, and only allow udp src port 53 from your > forwarder. > If you run your own named, and you don't run it as a slave, you *must* > accept udp packets with src port 53 and dst port 53 from anyone with > ipfw. The alternative is to use ipfilter with 'keep state'. You must accept them to the host, but that doesn't mean you have to allow them through the firewall. At the very least, the current ruleset should be commented with a big "this is a bad thing, it allows packets into your network where they really shouldn't be".