From owner-freebsd-security Thu Sep 25 23:21:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA12121 for security-outgoing; Thu, 25 Sep 1997 23:21:16 -0700 (PDT) Received: from oskar.nanoteq.co.za (oskar.nanoteq.co.za [163.195.220.170]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA12104 for ; Thu, 25 Sep 1997 23:21:10 -0700 (PDT) Received: (from rbezuide@localhost) by oskar.nanoteq.co.za (8.8.7/8.8.5) id IAA14479; Fri, 26 Sep 1997 08:20:14 +0200 (SAT) From: Reinier Bezuidenhout Message-Id: <199709260620.IAA14479@oskar.nanoteq.co.za> Subject: Re: rc.firewall weakness? In-Reply-To: <199709260009.RAA19119@salsa.gv.tsc.tdk.com> from Don Lewis at "Sep 25, 97 05:09:07 pm" To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Fri, 26 Sep 1997 08:20:14 +0200 (SAT) Cc: nate@mt.sri.com, jacs@gnome.co.uk, security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi ... > } > $fwcmd add pass udp from ${oip} to any 123 > } > > } > allows anyone from outside to connect to any udp port and get a reply if they > } > can get their hacking prog to connect from port 53 or 123 on their own machine? > } > > > You've got it, which is why I only permit UDP 53<->53 and 123<->123. You > loose the ability to point a DNS client at an external DNS server (though > you can still do this safely for testing purposes if you use TCP queries), > and you can't query external NTP servers. The server to server traffic > for DNS and NTP still works fine. > > } Yes, that is true. This is also the case with TCP ports that have > } similar rulesets, most notably FTP-DATA. > > Unless you ban that and only allow passive FTP. The ftp data port is really a bad case (if you allow active connections). I once re-compiled a kernel with the low port set to 20 (or 19 , I can't remember) and was able to telnet through a firewall to a machines telnet port. Since then, we have added the followinf rule to our packet filtering: add 100 deny tcp from any 20 to 1.2.3.4 1-1023 in recv , because they should not be going to low port numbers. How about this idea ... letting the ftp daemon be able to manipulate the packet filtering rules. Thus, when it knows WHERE and on what PORT the data connection is arriving, let it open the data port for that period for that ip. When the data connection closes, it removes the rule from the table again ... The same might be true even for the DNS ... when the DNS wants to do a query, let it open the ports and when it is finished, let it close them again ... This is only if you're REALLY into having more security, it doesn't give you more of an advantage, but it closes down the window for an attack. Reinier ################################################################### # # # R.N. Bezuidenhout NetSeq Firewall # # rbezuide@oskar.nanoteq.co.za http://www.nanoteq.co.za # # # ###################################################################