Date: Fri, 3 Dec 1999 10:29:16 -0700 From: Nate Williams <nate@mt.sri.com> To: Adam Laurie <adam@algroup.co.uk> Cc: Nate Williams <nate@mt.sri.com>, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, John Baldwin <jhb@FreeBSD.ORG>, freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited Message-ID: <199912031729.KAA11375@mt.sri.com> In-Reply-To: <3847F939.47978597@algroup.co.uk> References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> <3847C0CB.2E9774A@algroup.co.uk> <199912031601.JAA10973@mt.sri.com> <3847F55E.B546B2EB@algroup.co.uk> <199912031658.JAA11193@mt.sri.com> <3847F939.47978597@algroup.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I'm talking about connecting to UDP ports (like NFS) that you're not
> > > supposed to be able to connect to. Since his rule passes UDP that is
> > > sourced from port 53 on the nameserver to ANY UDP port on ANY machine,
> > > you are wide open to *attack*, not misinformation.
> >
> > Huh? How do you figure someone is going to *ATTACK* you by the process
> > of *you* sending out information?
> >
> > > At some point, your chain of name servers has to talk to the outside
> > > world, so this means the machine that does the final relay is open to
> > > attack from the outside world.
> >
> > Right. But, they can only talk to known ports on your machine that you
> > allow (including port 53). And, you only send out data *from* port 53
> > (as well as other known ports). I'm *really* confused as to how you
> > think sending out data from a known port will compromise your machine?
>
> ipfw add X pass udp from any to ${dnsserver} 53
> ipfw add X+1 pass udp from ${dnsserver} 53 to any
> ^^^^^^^^^^^^^^^^^^^^^^
> This rule says the name server can talk to any UDP port on any machine
> (including the firewall itself) as long as it's sourced from port 53.
> Since I, as the attacker, now own the nameserver, I can use port 53 for
> anything I like (as I demonstrated in my original post using netcat).
Ahh, you're assuming that 'dnssever' is compromised? *light bulb*
In this case, you're screwed. There is *NOTHING* (nadda, zero, zilch,
zippo) that can be done to protect from this. If you're nameserver is
compromised, you're hosed. That's why most folks that I know run the
nameserver that they trust either *ON* the firewall, or on a host inside
the firewall. Then you have a bastion DNS server for the world outside
the firewall that gets all of it's information from the internal
firewall, but if it's compromised you don't lose the internal integrity
inside the firewall.
> This works, believe me. I've done it. I can squirt data into a
> "protected" syslog on port 514, which shouldn't be possible. Using my
> rules, this is no longer possible.
What I'm hearing you state is never trust anything outside your
firewall, which is a great rule, but not one that I believe you can rely
on. Sooner or later you must depend on *something* external (other DNS
servers, etc...), but you can tighten them down.
>
> > As long as we don't allow 'spoofed' traffic to appear to be coming from
> > $dnsserver, this is a very safe set of rules (although incomplete, as
> > Rod points out).
>
> How do you tell the difference between a spoofed packet and a
> non-spoofed packet with ipfw?
By the IP address being used. If the source is from an address behind
the firewall, it's spoofed.
Otherwise, you can't know (or care), because 'spoofing' is often used
for legitimate reasons. So, you must assume that any traffic outside is
suspect, and make sure that any 'suspect' traffic is filtered correctly
and hope you catch everything.
Here's my rules. They could be re-ordered, and probably simplified, but
they work pretty well.
1) Drop anything that claims to be you coming from the outside.
2) Drop RFC 1918 unroutable traffic (incoming/outgoing)
3) Don't allow packets with a multicast source address (in/out).
4) Drop anything that isn't using an internal network address from going out.
5) Don't allow broadcast traffic in/out
[ At this point, the traffic is mostly 'sanitized'. You know that
whatever is coming and going is 'legitimate'. The outside stuff is not
to be trusted.
Next, the policy decisions for TCP.
1) Block out silly TCP services from being made from internal hosts
[ Normally, we trust our users not to do stupid things, but that's a
policy decision on our part. However, certain services should
never be attempted. ]
2) Block out all traffic from 'evil.org' hosts. (Local policy)
3) Allow in SMTP *ONLY* to the firewall (I only have to worry about one
version of sendmail now)
4) Block out 'SMTP' from being from internal boxes (just in case)
5) Allow other TCP connections to be made *from* internal hosts (scarey,
but current policy )
6) Allow in secure services (SSH) and certain necessary services in a
limited manner to my internal DNS server (DNS/TCP).
# Next, policy decision for UDP
1) Allow in UDP connections from anywhere to whatever port my service
lives on (DNS/53, NTP/123).
2) Alllow outgoing queries from these server to go out only from the
machines with that service.
3) Filter out responses from low-numbered ports incoming (we've allowed
people to connect to our well-known services, we know block out other
services which may appear to come from well-known ports as responses
to our requests). [ Note, a stateful firewall such as IPFilter
wouldn't need these rules ]
4) Allow outgoing responses from our internal services.
5) Allow incoming responses to our internal server requests.
Block the rest!
Nate
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912031729.KAA11375>