Date: Thu, 25 Sep 1997 10:20:37 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: Chris Stenton <jacs@gnome.co.uk> Cc: security@freebsd.org Subject: Re: rc.firewall weakness? Message-ID: <199709251620.KAA18291@rocky.mt.sri.com> In-Reply-To: <199709251454.PAA06399@hawk.gnome.co.uk> References: <199709251454.PAA06399@hawk.gnome.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> I have just been looking at the latest rc.firewall for 2.2.2-stable
> and it appears to me that it is somewhat weak. As far as I can see
> the following rules:-
>
> # Allow DNS queries out in the world
> $fwcmd add pass udp from any 53 to ${oip}
> $fwcmd add pass udp from ${oip} to any 53
>
> # Allow NTP queries out in the world
> $fwcmd add pass udp from any 123 to ${oip}
> $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?
>
Yes, that is true. This is also the case with TCP ports that have
similar rulesets, most notably FTP-DATA.
> The whole area of UDP as far as I can see is difficult to administer
> under ipfw. What I feel is required is "dynamic packet filtering" on
> UDP connections so that ipfw remembers the outgoing UDP packets it has
> seen.
I think the above solution is adequate, so both the source/destination
port are the same.
> It can then let in corresponding packets from the host and port
> that has been sent to. This I think is the case for products from
> Morning Star et. al.
It wasn't that way when I first used MorningStar, but that was a couple
of years ago.
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709251620.KAA18291>