[Courses] [Security] Firewall theory -- UDP and nameservers

[Raven, corporate courtesan]

Heya --

Quoth hobbit at aloss.ukuu.org.uk (Wed, Mar 20, 2002 at 01:31:11PM +0000):
> Of those, I think it's the last suggestion. I asked my husband. And 
> didn't understand it well enough to relay here without garbling it. 

	Okay, this makes sense to me.  This sort of setup, where you
have the outside world (totally untrusted), a firewall, a sort of
semi-trusted area, another firewall, and then your internal network is
commonly called a DMZ.  That's short for demilitarized zone -- the term
was stolen from the military.  [grin]  It allows you to run servers and
services that have to access the public Internet in possibly threatening
ways, and not have your internal workstations trusting them entirely.

> It hinges, I think, on the "some control over nameserver" suggestion,
> in that there's a firewall there too. 

	That, and also that (I am assuming) y'all set up and maintain
both the firewalls and the nameserver.  When you control a box, it's a
lot easier to decide what sort of traffic it can send and recieve.
 
> Over to Alan's ASCII art:
> 
>   Internet --- [ 1-FIREWALL ] --- DNS server --- [ 2-FIREWALL ] --- ME
> 
>   #1 has rules that block any packets coming from the internet with 
>   source addresses that are local to the DNS,ISP,me (ie spoofed)

	Usually in a DMZ setup, the outer firewall (the one closer to
the Internet) has a less strict set of rules than the inner firewall.
So here, it's keeping out anything that obviously shouldn't be.  If the
firewall knows that the machine dahlia is accessible off its inside
interface, and gets a packet on the outside interface "from" dahlia's IP
address, it should discard that packet since it's faked.  The real
dahlia would only be sending from the inside interface.  It's common to
drop packets coming in on the outside interface that have source
addresses that you know to be only on the inside.

	Another common firewall rule blocks packets from the Internet side
that have source IP addresses of RFC 1918 private address space
(anything from 10.0.0.0/8, 172.116.0.0/12, or 192.168.0.0/16), since
those are private IP addresses that should only be used on private LANs,
not on the Internet at large.  

	There are some cable modem providers and other ISPs that
actually use the ten-net space (10.0.0.0/8) to number their internal
network, and then they use NAT when they pass off that traffic to other
ISPs.  If you are a customer of one of these ISPs, using a firewall that
blocks RFC 1918 space will break your Internet connection.  Don't do it.

	How can you tell?  Do a traceroute to something not local to
your ISP.  If you see any RFC 1918 addresses appearing in the
traceroute, blocking them at your firewall would be a bad idea.
 
>   #2 has a specific rule to allow DNS traffic through but only if it 
>   orginates from the DNS server. #1 ensures that wasn't spoofed unless 
>   the DNS box was compromised. Even then they have a bit of a battle 
>   but an attacker could target known UDP services [eg NFS which is port 
>   2049 and best blocked anyway]

	Okay.  So the machines on the internal network (anything behind
the second firewall) only use the DNS server that's between the
firewalls for DNS resolution.  UDP packets from internal machines to the
DNS port on that one DNS server are allowed through the second firewall
outbound, and the replies from that one DNS server are allowed through
the second firewall inbound.  But only that one server is allowed.
That's why if that server breaks, you can't get DNS.  No other DNS
servers are allowed to send DNS replies through your second firewall.
So even if you tried to use another one, the request might be allowed
out, but the reply wouldn't be allowed back in.

	Does that make sense?

	Now, an attacker might look at that and go, "Aha!  I just have
to pretend to be that one DNS server (i.e. spoof my IP address and
pretend it's the same as the IP of that DNS server) and I'll be allowed
through the second firewall!"  Unfortunately for that attacker, all
packets with a source address of something known to be behind the first
firewall (like that DNS server) will be dropped if they try to come in
the outside interface of that first firewall.  So the no-spoofing rule
on the first firewall makes it okay for the machines on your internal
network to believe that that DNS server really is that DNS server, and
not a hacker pretending to be the DNS server.

	Foiled by that rule, the only thing the black hat can do is try
to take over the DNS server directly, rather than just spoofing its IP
address.  They'd have to look for exploitable services it was running
that are allowed through the first firewall, and then try to use those
to get a root shell.  So if there was a big hole found in BIND, for
example, the attacker might be able to use that to compromise the DNS
server, and then use the DNS server to get through the second firewall.

>   There are other tricks you can pull too:
>     - Running DNS through a socks proxy

	Heh.  Not something that I have any experience with.  (Anyone
else that's done this, please speak up.)

>     - Use IPV6 to talk to the nameserver if you have a local IPv6
>         connection (great for screwing with a script kiddies mind)

	[laughs]  IPv6 (version 6 of IP, the Internet Protocol) in
general is great for making folks boggle.  It's not widely deployed
across the Internet, so even most experienced admins are unfamiliar with
it.  When you're expecting to see a nice normal IPv4 packet and instead
you get this huge, unfamiliar... thing!, it's very disturbing.

>     - Patch glibc to allow you to force TCP DNS - this is great for 
>         your own nameserver but if you are using an ISP one don't expect 
>         it to make people happy as it reduces the load it can handle a 
>         fair bit. Diff below, and add "options tcp" to resolv.conf.

	This is what I was thinking of with "or you could custom-hack
the clients to only use TCP".  But TCP is a lot more resource-demanding
than UDP on a server, so this will make your DNS server work a lot
harder.  If the DNS server doesn't belong to you, you may get a "what
the heck is going on here" call from your ISP.
 
> (Back to Telsa again now..) I hear more and more about IPv6. I heard
> a talk on it several years ago, and as time passed and I heard no more
> I presumed it was just one of those neat things which wasn't going to 
> take off after all. Now I have forgotten everything from the talk, of 
> course, suddenly everyone's talking about it again. Unfair, I call it.

	Yeah, I've read a good number of standards documents on it, but
I'm waiting for the O'Reilly book.  (Not that I know if there's going to
be one, but it would be helpful...)
 
> Anyway, that's the "securing nameserver traffic" thing, but I'm still
> not sure how it works.

	Let me know if that explanation makes sense, and if not, what's
still confusing.

Cheers,
Raven
 
"And then we release the killer bees, with dogs in their mouths!"
  -- ChrisJ, on "get away from my router" tactics