Date: Wed, 22 Sep 1999 12:22:22 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Eivind Eklund <eivind@FreeBSD.ORG> Cc: John Heyer <john@arnie.jfive.com>, security@FreeBSD.ORG Subject: Re: port-blocking ipfw rules with NAT - necesary? Message-ID: <199909221923.MAA05400@passer.osg.gov.bc.ca> In-Reply-To: Your message of "Tue, 21 Sep 1999 12:45:28 %2B0200." <19990921124528.I12619@bitbox.follo.net>
index | next in thread | previous in thread | raw e-mail
In message <19990921124528.I12619@bitbox.follo.net>, Eivind Eklund
writes:
> On Mon, Sep 20, 1999 at 04:13:41PM -0500, John Heyer wrote:
> >
> > In the firewall section of the handbook, it recommends something like:
> > - Stop IP spoofing and RFC1918 networks on the outside interface
> > - Deny most (if not all) UDP traffic
> > - Protect TCP ports 1-1024,2000,2049,6000-6063 on the internal network
> >
> > These rules make sense, but I think they make the assumption the network
> > you're protecting is routable. If I'm running NAT and my internal network
> is
> > non-routable, do I really need to continue blocking ports? For example,
> > let's say someone was running an open relay mail server or vulnerable FTP
> > server - would it be possible for an intruder to someone access the
> > internal machine assuming I'm not using -redirect_port or
> > -redirect_address with natd?
>
> It shouldn't be - but it is always prudent to use several layers of
> defense.
How true. A few years ago I was able to access (ping, traceroute)
someone's RFC1918 network. More recently a leak, due to a
misconfigured router, of some ARPA addresses were blocked by my
firewall.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca
ITSD Cy.Schubert@gems8.gov.bc.ca
Province of BC
"e**(i*pi)+1=0"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909221923.MAA05400>