From Firewalls-Owner Sun Oct 4 20:55:40 1992
Return-Path: brent@GreatCircle.COM
Return-Path: <brent@GreatCircle.COM>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA09421; Sun, 4 Oct 92 20:55:40 PDT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA09405; Sun, 4 Oct 92 20:55:07 PDT
Message-Id: <9210050355.AA09405@mycroft.GreatCircle.COM>
To: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum)
Cc: firewalls@GreatCircle.COM
Subject: Reverse and double-reverse IP address lookups as service prerequisites
In-Reply-To: Your message of Sun, 4 Oct 92 18:27:37 -0400
Reply-To: Brent@GreatCircle.COM
Date: Sun, 04 Oct 92 20:55:06 -0700
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) writes:
# Inside of Digital, we configure our FTP proxy to reject all
# hosts that don't have a reverse address mapping. This way, if a
# subnet isn't set up right, they don't get to use the FTP proxy. It
# is amazing how quickly people will fix things if you give them a
# reason to.
A variety of implementations of a number of services, particularly
SMTP and FTP servers, do this. I find it mildly annoying, but not
really a problem.
One sticky issue is: what if I desire to hide the internal naming
structure of my network? I think this is a valid goal, given that
project information can sometimes be inferred simply by knowing what
the machines are named, and that any such handle you get is something
that "the bad guys" can for "social engineering" their way past an
unwitting receptionist or security staff.
I resolve this by using a wildcard PTR record in my DNS data so that
all but hosts with explicit PTR records (the gateway/firewall hosts,
for instance) return "unknown" (actually "unknown.domain.net", for
whatever the appropriate "domain.net" is) when you do an
address-to-name translation through DNS. This satisfies the service
provider's desire to know who they're talking to (they know what
domain it is, at least), and satisfies my desire to to keep my
internal network structure and naming private.
The thing I _really_ think is a problem is so-called "double reverse"
lookups. In a double reverse lookup, after you do the address-to-name
translation to find the name of the host that's calling you, you then
do a name-to-address translation on that name to see if the address
you get back matches the address that's calling you. If the two
addresses don't match, you disallow the connection.
I don't know what that's really supposed to provide in the way of
security, but it sure screws up systems which hide internal hostnames
as descirbed above, and systems where machines with multiple network
interfaces appear to be separate machines in the DNS databases (I know
this _shouldn't_ be necessary, but it often _is_ necessary to work
around routing and configuration limitations in today's software). If
you look up "unknown.MyDomain.COM", which IP address from a hidden
internal machine should I give you? And what if you look up
143.191.19.66 and get back "nb.MyDomain.COM", and then look up
"nb.MyDomain.COM" and get back 143.191.20.66 (because that's the
_other_ interface on nb.MyDomain.COM)?
What we've got here is a dilemna: on the one hand, we've got the
desire of the service provider to know exactly who they're talking to.
On the other hand, we've got the desire of the service user to hide
their internal network naming and structure. Whose desire should win
out?
In the long run, I think double-reverse is going to go away. I don't
see that it really buys you any security as a service provider; it
just trips you up over everybody else's buggy DNS databases and
security measures.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Mon Oct 5 00:14:52 1992
Return-Path: Firewalls-Owner@GreatCircle.COM
Return-Path: <Firewalls-Owner@GreatCircle.COM>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA09635; Mon, 5 Oct 92 00:14:52 PDT
Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA09629; Mon, 5 Oct 92 00:14:47 PDT
Message-Id: <9210050714.AA09629@mycroft.GreatCircle.COM>
Received: by inet; Mon Oct 5 03:12 EDT 1992
From: smb@ulysses.att.com
To: Brent@GreatCircle.COM
Cc: firewalls@GreatCircle.COM
Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites
Date: Mon, 05 Oct 92 03:12:19 EDT
Sender: Firewalls-Owner@GreatCircle.COM
The thing I _really_ think is a problem is so-called "double reverse"
lookups. In a double reverse lookup, after you do the address-to-name
translation to find the name of the host that's calling you, you then
do a name-to-address translation on that name to see if the address
you get back matches the address that's calling you. If the two
addresses don't match, you disallow the connection.
I don't know what that's really supposed to provide in the way of
security, but it sure screws up systems which hide internal hostnames
as descirbed above, and systems where machines with multiple network
interfaces appear to be separate machines in the DNS databases (I know
this _shouldn't_ be necessary, but it often _is_ necessary to work
around routing and configuration limitations in today's software).
It's very necessary. Since the forward and reverse trees are entirely
separate, if I control a reverse tree for my address space -- either
legitimately or because I've subverted a machine -- I can change the
reverse mapping to name a machine I know you trust.
The multiple interface case isn't a problem. Here's how I set things
up. The real name of the machine maps to multiple addresses. If I
need more than one, I'll have additional names that map to each individual
address. The inverse map generally maps back to the major name; since
the code checks the entire list of addresses, it's not a problem.
Ultimately, that whole notion may go away, but that won't happen until
a real (i.e., cryptographic) authentication system is deployed.
From Firewalls-Owner Mon Oct 5 07:00:21 1992
Return-Path: Firewalls-Owner@GreatCircle.COM
Return-Path: <Firewalls-Owner@GreatCircle.COM>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA10313; Mon, 5 Oct 92 07:00:21 PDT
Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA10305; Mon, 5 Oct 92 07:00:03 PDT
Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma)
id AA28541; Mon, 5 Oct 92 10:00:13 -0400 XXX
Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791);
id AA01527; Mon, 5 Oct 92 09:59:54 -0400
Date: Mon, 5 Oct 92 09:59:54 -0400
From: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum)
Message-Id: <9210051359.AA01527@hussar.dco.dec.com>
To: firewalls@GreatCircle.COM
Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites
Sender: Firewalls-Owner@GreatCircle.COM
>One sticky issue is: what if I desire to hide the internal naming
>structure of my network? I think this is a valid goal, given that
>project information can sometimes be inferred simply by knowing what
>the machines are named, and that any such handle you get is something
>that "the bad guys" can for "social engineering" their way past an
>unwitting receptionist or security staff.
Usually, I like to take the approach that hiding host names is
"security through obscurity" and as such should not be respected as
improving your situation noticeably.
There are just too many ways to get host information - I'd
rather try to secure my network than hide it. Consider that many
sendmails put
Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791);
kind of crud in messages as they fly by. You need to strip
all that out at the firewall, and soon you're finding yourself
back in an "arms race".
Another way of looking at it is to realize that concern about
"social engineering" should be across the board. If you're afraid that
I might find a hostname in your network and call your help desk and
say "I forgot my password on 'mumble'" you also need to take into
account the staff members who will ignorantly give out their address
as "joe@mumble.bar.com" -- the information is GOING to leak out. Worry
about how to secure mumble.bar.com and make sure that people don't
name their machines "top-secret-project.bar.com" and you're better
off.
mjr.
From Firewalls-Owner Mon Oct 5 11:17:10 1992
Return-Path: brent@GreatCircle.COM
Return-Path: <brent@GreatCircle.COM>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA11330; Mon, 5 Oct 92 11:17:10 PDT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA11323; Mon, 5 Oct 92 11:17:07 PDT
Message-Id: <9210051817.AA11323@mycroft.GreatCircle.COM>
To: firewalls@GreatCircle.COM
Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites
In-Reply-To: Your message of Mon, 5 Oct 92 09:59:54 -0400
Reply-To: Brent@GreatCircle.COM
Date: Mon, 05 Oct 92 11:17:06 -0700
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) writes:
# Usually, I like to take the approach that hiding host names is
# "security through obscurity" and as such should not be respected as
# improving your situation noticeably.
I agree that it's security through obscurity, and should not be
counted on to protect anything, BUT every little bit helps. Why give
folks ammunition, in the way of host names that can be used for
"social engineering" or password attempts or anything else? Sure,
not making the host names trivially available doesn't solve much, but
it's one more piece of the puzzle.
Now, all that said, only a couple of the firewalls I've worked on
bother to do that. Most of my clients feel the way Marcus does about
hiding host names: why bother? My point is, it's possible IF you
think it's valuable, and some folks think it's valuable.
# There are just too many ways to get host information - I'd
# rather try to secure my network than hide it.
I was definitely NOT suggesting hiding it rather than securing it. I
was suggesting hiding it AFTER you've done your best to secure it;
that gives you one more layer (perhaps trivial) that someone has to
work their way through to get to you.
I don't believe in absolute security; I don't believe that it's
possible. I believe that it's a worthy _GOAL_, but I don't have any
illusions that I'm going to actually ACHIEVE the goal. Therefore, I
do every little thing I can to tighten up security on the firewall
systems I build. Some are big things, like setting up packet
filtering in the routers. Some are little things, like hiding
internal host names. They all matter, to a greater or lesser degree.
Hiding host names is way down on my list of what steps are important
to take in securing a network, but it IS on the list. Some of my
clients, for whatever reason, never get that far down the list, but
some do.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Mon Oct 5 12:25:27 1992
Return-Path: Firewalls-Owner@GreatCircle.COM
Return-Path: <Firewalls-Owner@GreatCircle.COM>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA12107; Mon, 5 Oct 92 12:25:27 PDT
Received: from alpha.CES.CWRU.Edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA12100; Mon, 5 Oct 92 12:25:22 PDT
Received: from sentinel.CES.CWRU.Edu by alpha.CES.CWRU.Edu with SMTP (5.64+/ane.07.08.91.01)
id AA13982; Mon, 5 Oct 92 15:25:34 -0400
From: Aydin Edguer <edguer@alpha.CES.CWRU.Edu>
Message-Id: <9210051925.AA13982@alpha.CES.CWRU.Edu>
Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites
To: Brent@GreatCircle.COM
Date: Mon, 5 Oct 92 15:21:22 EDT
In-Reply-To: <9210051817.AA11323@mycroft.GreatCircle.COM>; from "Brent Chapman" at Oct 5, 92 11:17 aX-Mailer: ELM [version 2.3 PL11]
Sender: Firewalls-Owner@GreatCircle.COM
> I agree that it's security through obscurity, and should not be
> counted on to protect anything, BUT every little bit helps. Why give
> folks ammunition, in the way of host names that can be used for
> "social engineering" or password attempts or anything else? Sure,
> not making the host names trivially available doesn't solve much, but
> it's one more piece of the puzzle.
But the point is that if "I" am trying to break into "your" hosts, then
"I" don't really care about the hostname, all "I" need is the IP address.
Unless you are going to hide your IP addresses, then hiding the hostnames
seems rather pointless (except for mail). If you do hide IP addresses then
I fully agree that hiding your hostnames is important and useful.
The point of doing a "double reverse" name lookup is security/authentication.
It helps to prevent spoofing of the nameserver by people forging PTR records
in their nameservers. Thus I think that a "double reverse" name lookup is
under normal usage [with or without firewall] going to help cut down on
"forgeries" more than hiding only the names is going to help.
Aydin Edguer
From Firewalls-Owner Mon Oct 5 14:15:45 1992
Return-Path: brent@GreatCircle.COM
Return-Path: <brent@GreatCircle.COM>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA12995; Mon, 5 Oct 92 14:15:45 PDT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA12986; Mon, 5 Oct 92 14:15:42 PDT
Message-Id: <9210052115.AA12986@mycroft.GreatCircle.COM>
To: Firewalls@GreatCircle.COM
Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites
Reply-To: Brent@GreatCircle.COM
Date: Mon, 05 Oct 92 14:15:40 -0700
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Aydin Edguer <edguer@alpha.CES.CWRU.Edu> writes:
# > I agree that it's security through obscurity, and should not be
# > counted on to protect anything, BUT every little bit helps. Why give
# > folks ammunition, in the way of host names that can be used for
# > "social engineering" or password attempts or anything else? Sure,
# > not making the host names trivially available doesn't solve much, but
# > it's one more piece of the puzzle.
#
# But the point is that if "I" am trying to break into "your" hosts, then
# "I" don't really care about the hostname, all "I" need is the IP address.
# Unless you are going to hide your IP addresses, then hiding the hostnames
# seems rather pointless (except for mail). If you do hide IP addresses then
# I fully agree that hiding your hostnames is important and useful.
Some people (including some but not most of my clients) consider host
names to be useful information in and of themselves, regardless of
what IP address the host maps to. The host names might give outsiders
a clue about projects inside the company, they give outsiders more
ammunition for their password cracking programs, and they let
outsiders appear to be knowledgable about the site if they try to
engage in social engineering to get past human security measures
(i.e., if somebody who looks like a repair tech shows up at your
receptionist's desk and says "I'm here to work on <some internal
machine name> and it's an emergency; they're waiting for me in the
machine room", what's your receptionist going to do?
# The point of doing a "double reverse" name lookup is security/authentication.
# It helps to prevent spoofing of the nameserver by people forging PTR records
# in their nameservers. Thus I think that a "double reverse" name lookup is
# under normal usage [with or without firewall] going to help cut down on
# "forgeries" more than hiding only the names is going to help.
I don't think knowing the name that goes with an IP address really
tells you any more than the IP address itself, which you've got regardless.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Mon Oct 5 14:40:40 1992
Return-Path: Firewalls-Owner@GreatCircle.COM
Return-Path: <Firewalls-Owner@GreatCircle.COM>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA13305; Mon, 5 Oct 92 14:40:40 PDT
Received: from alpha.CES.CWRU.Edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA13275; Mon, 5 Oct 92 14:40:20 PDT
Received: from sentinel.CES.CWRU.Edu by alpha.CES.CWRU.Edu with SMTP (5.64+/ane.07.08.91.01)
id AA14553; Mon, 5 Oct 92 17:40:22 -0400
From: Aydin Edguer <edguer@alpha.CES.CWRU.Edu>
Message-Id: <9210052140.AA14553@alpha.CES.CWRU.Edu>
Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites
To: Firewalls@GreatCircle.COM
Date: Mon, 5 Oct 92 17:40:13 EDT
X-Mailer: ELM [version 2.3 PL11]
Sender: Firewalls-Owner@GreatCircle.COM
> (i.e., if somebody who looks like a repair tech shows up at your
> receptionist's desk and says "I'm here to work on <some internal
> machine name> and it's an emergency; they're waiting for me in the
> machine room", what's your receptionist going to do?
[your examples of why to protect hostnames are very good. I guess I
would just want to point out that even with no hostnames, you are
still at risk from similar attacks]
Well, I realize that the "right" answer is not always the "practical"
or "realistic" answer but IMHO the receptionist better call in first...
or else.
First, because the repair tech will not be able to get through the
security stops within the building without an escort and secondly
because they will not be able to get into the machine room without
the presence of a staff member.
If physical security is any more lax then hostnames are not going to
save you once the intruder gets physical access to one machine. At
one company where I consult, you do not get in without an employee
accompanying you. Period. Unless you are the fire department and
in that case security is already on the scene.
Furthermore, how many receptionists really know the names and locations
of all computers in the company? If they really do know the names
and locations, does the gateway hostname change internally? If not,
then the intruder can just use the gateway hostname to get in.
> # It helps to prevent spoofing of the nameserver by people forging PTR records
> # in their nameservers. Thus I think that a "double reverse" name lookup is
> # under normal usage [with or without firewall] going to help cut down on
> # "forgeries" more than hiding only the names is going to help.
>
> I don't think knowing the name that goes with an IP address really
> tells you any more than the IP address itself, which you've got regardless.
Well, when tracking things down _after_ the fact, you are correct.
But for screening I disagree. Many sites are now using FQDN's for
configuration purposes to help prevent problems when machines are
changed [e.g. contact SMTP.do.main or NNTP.do.main]. Without verifying
the PTR lookup with a further A lookup, the PTR lookup can take place
on a remote [cracked] system and return a valid FQDN, that will not
be detected until much later.
Aydin Edguer
From Firewalls-Owner Fri Oct 9 16:15:19 1992
Return-Path: Firewalls-Owner@GreatCircle.COM
Return-Path: <Firewalls-Owner@GreatCircle.COM>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA26535; Fri, 9 Oct 92 16:15:19 PDT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA26265; Fri, 9 Oct 92 15:28:55 PDT
Message-Id: <9210092228.AA26265@mycroft.GreatCircle.COM>
To: firewalls@GreatCircle.COM
Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites
In-Reply-To: Your message of Mon, 05 Oct 92 03:12:19 EDT
Date: Fri, 09 Oct 92 15:28:54 -0700
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Steve Bellovin <smb@ulysses.att.com> writes, in response to one of my
earlier postings:
# The thing I _really_ think is a problem is so-called "double reverse"
# lookups. In a double reverse lookup, after you do the address-to-name
# translation to find the name of the host that's calling you, you then
# do a name-to-address translation on that name to see if the address
# you get back matches the address that's calling you. If the two
# addresses don't match, you disallow the connection.
#
# I don't know what that's really supposed to provide in the way of
# security, but it sure screws up systems which hide internal hostnames
# as descirbed above, and systems where machines with multiple network
# interfaces appear to be separate machines in the DNS databases (I know
# this _shouldn't_ be necessary, but it often _is_ necessary to work
# around routing and configuration limitations in today's software).
#
# It's very necessary. Since the forward and reverse trees are entirely
# separate, if I control a reverse tree for my address space -- either
# legitimately or because I've subverted a machine -- I can change the
# reverse mapping to name a machine I know you trust.
Ah, but I don't trust anything based on name. All of my packet
filters are set up to filter by address, not name. None of the
services on my gateway machines (the one that provides the SMTP, FTP,
NNTP, and DNS servers that the outside world can see) do any sort of
authentication by name (except for NNTP, which I'm not real concerned
about anyway; if I was, I could do it by IP address as well).
Here's another way to look at the double reverse issue: what does
useful information knowing the name, and being sure of the name, get
you that knowing simply the IP address (which you can read directly
from the packet) doesn't? I contend that you can't trust the names
you get from DNS even if you do a double-reverse lookup, so why should
services be obnoxious about it and disallow connections if the
double-reverse lookup fails? Certainly you should probably log the
failed double-reverse lookups, and perhaps you should warn the client,
but is it really reasonable to disallow the connection based on
information you can't trust anyway?
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Sat Oct 10 08:48:55 1992
Return-Path: Firewalls-Owner@GreatCircle.COM
Return-Path: <Firewalls-Owner@GreatCircle.COM>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA28076; Sat, 10 Oct 92 08:48:55 PDT
Received: from seas.smu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA28070; Sat, 10 Oct 92 08:48:40 PDT
Received: by seas.smu.edu (/\==/\ Smail3.1.25.1 #25.1)
id <m0mdj3O-000QyNC@seas.smu.edu>; Sat, 10 Oct 92 10:48 EDT
Message-Id: <m0mdj3O-000QyNC@seas.smu.edu>
From: doug@seas.smu.edu (Doug Davis)
Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites
To: avalon@coombs.anu.edu.au
Date: Sat, 10 Oct 92 10:48:30 EDT
Cc: firewalls@GreatCircle.COM
In-Reply-To: <9210101240.AA03741@coombs.anu.edu.au>; from "Darren Reed" at Oct 10, 92 10:40 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: Firewalls-Owner@GreatCircle.COM
>
> In this area, I think it is DNS libraries which are a bit on the deficient
> side; it would be nice to be able to set the a preference of /etc/hosts or
> a DNS server for each lookup AND also know from which the answer came.
Ultrix 4.xx provides this thru the svc config file. It allows
you to specifiy one of "local", "yp", and "bind" for resolution
of distributed "services" databases. Where the databases are one of
aliases, auth, group, hosts, netgroup, networks, passwd, protocols, rpc,
or services.
The local resolution would be the representitive file on the local
machine, such as /etc/hosts for the hosts database.
doug
From Firewalls-Owner Sat Oct 10 05:40:26 1992
Return-Path: Firewalls-Owner@GreatCircle.COM
Return-Path: <Firewalls-Owner@GreatCircle.COM>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA27873; Sat, 10 Oct 92 05:40:26 PDT
Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA27865; Sat, 10 Oct 92 05:40:06 PDT
Received: by coombs.anu.edu.au (5.61/1.0)
id AA03741; Sat, 10 Oct 92 22:40:04 +1000
From: avalon@coombs.anu.edu.au (Darren Reed)
Message-Id: <9210101240.AA03741@coombs.anu.edu.au>
Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites
To: firewalls@GreatCircle.COM
Date: Sat, 10 Oct 92 22:40:03 EST
In-Reply-To: <9210092228.AA26265@mycroft.GreatCircle.COM>; from "Brent Chapman" at Oct 9, 92 3:28 pmeply-To: avalon@coombs.anu.edu.au
X-Mailer: ELM [version 2.3 PL11]
Sender: Firewalls-Owner@GreatCircle.COM
In some email I received from Brent Chapman, Sie wrote:
[...]
> Ah, but I don't trust anything based on name. All of my packet
> filters are set up to filter by address, not name. None of the
> services on my gateway machines (the one that provides the SMTP, FTP,
> NNTP, and DNS servers that the outside world can see) do any sort of
> authentication by name (except for NNTP, which I'm not real concerned
> about anyway; if I was, I could do it by IP address as well).
[...]
Your lack of trust in DNS replies is well founded, but it may well be
useful for you to know who is trying to spoof DNS records if you do an
IP#->name lookup (from a DNS server) and get a 'local' machine name
which has a different IP# to that which you're doing a lookup on.
In this area, I think it is DNS libraries which are a bit on the deficient
side; it would be nice to be able to set the a preference of /etc/hosts or
a DNS server for each lookup AND also know from which the answer came.
Then at least you can depend on local mappings (from /etc/hosts) and start
asking questions when you see a clash.
Darren.
From Firewalls-Owner Sat Oct 10 12:16:08 1992
Return-Path: Firewalls-Owner@GreatCircle.COM
Return-Path: <Firewalls-Owner@GreatCircle.COM>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA28293; Sat, 10 Oct 92 12:16:08 PDT
Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA28287; Sat, 10 Oct 92 12:15:43 PDT
Received: by coombs.anu.edu.au (5.61/1.0)
id AA11656; Sun, 11 Oct 92 05:15:46 +1000
From: avalon@coombs.anu.edu.au (Darren Reed)
Message-Id: <9210101915.AA11656@coombs.anu.edu.au>
Subject: Re: DNS lookups
To: firewalls@GreatCircle.COM
Date: Sun, 11 Oct 92 5:15:45 EST
Reply-To: avalon@coombs.anu.edu.au
X-Mailer: ELM [version 2.3 PL11]
Sender: Firewalls-Owner@GreatCircle.COM
In some email I received from Doug Davis, Sie wrote:
>
> > In this area, I think it is DNS libraries which are a bit on the deficient
> > side; it would be nice to be able to set the a preference of /etc/hosts or
> > a DNS server for each lookup AND also know from which the answer came.
>
> Ultrix 4.xx provides this thru the svc config file. It allows
> you to specifiy one of "local", "yp", and "bind" for resolution
> of distributed "services" databases. Where the databases are one of
> aliases, auth, group, hosts, netgroup, networks, passwd, protocols, rpc,
> or services.
>
> The local resolution would be the representitive file on the local
> machine, such as /etc/hosts for the hosts database.
The Ultrix style configuration is also available if you replace your native
resolve library with resolv+ (by Bill Wisner) which lets you choose the
order of lookup.
However, even with either the Ultrix approach or resolv+, what is really
needed is to be able to look "local" and then (optionally) continue to
do a "bind" lookup OR the other way around.
Even still, its only worth doing a lookup on an IP# if it hasn't been
faked, which is where the using packet screens/filters come into things
by removing (obviously) bogus packets. Although mobile hosts could
cause some interesting problems in the future for firewalls.
Darren.
From Firewalls-Owner Sun Oct 11 04:25:19 1992
Return-Path: Firewalls-Owner@GreatCircle.COM
Return-Path: <Firewalls-Owner@GreatCircle.COM>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA00550; Sun, 11 Oct 92 04:25:19 PDT
Received: from eurogate.bnr.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924)
id AA00544; Sun, 11 Oct 92 04:25:12 PDT
Received: from bnr.co.uk by eurogate.bnr.co.uk with SMTP (PP)
id <17832-0@eurogate.bnr.co.uk>; Sun, 11 Oct 1992 12:24:45 +0100
Received: from bnr.co.uk by innergate.bnr.co.uk with SMTP (PP)
id <01518-0@innergate.bnr.co.uk>; Sun, 11 Oct 1992 12:24:40 +0100
To: avalon@coombs.anu.edu.au
Cc: firewalls@GreatCircle.COM
Subject: Re: Reverse and double-reverse IP address lookups as service
prerequisites
In-Reply-To: Message from Darren Reed on Sat, 10 Oct 92 22:40:03 -0500.
Organisation: BNR Europe, HARLOW, Essex CM17 9NA, GB
Phone: +44 279 402423
Date: Sun, 11 Oct 92 12:24:37 +0100
Message-Id: <14297.718802677@alder2.bnr.co.uk>
From: Andrew Macpherson (Postmaster) <A.Macpherson@bnr.co.uk>
Sender: Firewalls-Owner@GreatCircle.COM
Darren Reed wrote:
| Your lack of trust in DNS replies is well founded, but it may well be
| useful for you to know who is trying to spoof DNS records if you do an
| IP#->name lookup (from a DNS server) and get a 'local' machine name
| which has a different IP# to that which you're doing a lookup on.
|
| In this area, I think it is DNS libraries which are a bit on the deficient
| side; it would be nice to be able to set the a preference of /etc/hosts or
| a DNS server for each lookup AND also know from which the answer came.
|
| Then at least you can depend on local mappings (from /etc/hosts) and start
| asking questions when you see a clash.
On a simmilar vein, I've a (yet another) version of libresolv which allows
one to chose any order of `/etc/hosts' `DNS-internal' `DNS-global' and `NIS'
which works well for `gethostby...' but has slight problems for direct res_
calls (you get whichever last succeeded of `DNS-(in|ex)ternal' which is
usually appropriate, but...)
This lives in libc on the gateway to which my users log on to access the
Internet.
It doesn't address the `where did I get this info from?' question, but could
easily --- I havn't felt the need yet.
If there is sufficient interest I could make a file available for FTP
(sufficient > 4)
From Firewalls-Owner Tue Dec 1 10:13:36 1992
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA12057; Tue, 1 Dec 92 10:13:36 PST
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA12048; Tue, 1 Dec 92 10:13:31 PST
Message-Id: <9212011813.AA12048@mycroft.GreatCircle.COM>
To: Firewalls@GreatCircle.COM
Subject: Re: what shall thy firewall hardware be?
In-Reply-To: Your message of Tue, 1 Dec 92 10:47:07 -0600
Date: Tue, 01 Dec 92 10:13:31 -0800
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
stan@tta.com (Stan Hanks) writes
# All of the above restrictions are sort of a minimum set, near as I can tell.
# There are some other things I like to do as well. Probably under the aegis
# of "increased paranoia" although the clients say it's because there are
# serious financial risks involved in connectivity.
Sure; I hadn't intended to reveal _everything_ in my bag of tricks... :-)
# For starters, I perfer to have a seperate network number for the DMZ than the
# internal network, and have proxy TELNET and FTP agents on the DMZ host so that
# internal network addresses never leak past the exterior DMZ router.
I like to use a separate network number for the DMZ, but for another
reason. If the DMZ has a different network number than the internal
network, then the interior router (between the DMZ and the internal
network) can filter out any inbound packet which appears to have an
internal source address and any outbound packet which appears to have
an internal destination address, because such packets would have to be
either spoofs or misrouted.
As we've discussed here before, ad nauseum, I don't like proxy
FTP/TELNET for a lot of reasons, mostly having to do with availability
of clients for heterogeneous internal networks.
# I also like to have an MX for *.domain on the DMZ host, to keep station
# names and sub-domains from leaking out as well. You'd be surprised how
# many people leave useful info laying about in their naming conventions...
# And mail header re-writing as well, so that only gateway.domain shows up
# on outgoing headers...
Absolutely agreed. I've even gone so far on a number of firewalls
that I've built to have the DNS server on the gateway host lie to the
external DNS. It says it's authoritative, but the only data it has is
that relating to machines that the outside world can reach, and a
wildcard PTR record to resolve all external lookups of internal
addresses to "unknown.whoever.com". The DNS _client_ software on the
gateway is set up (via resolv.conf on a UNIX box) to use an _internal_
DNS server, so that inbound mail forwarding and such works. The
internal DNS server has all the "real" data, and is configured to
forward requests for other data to the gateway server, which proxies
the question to the outside world, then relays the answer back to the
internal server.
So, when a client on the gateway asks a question, it asks the internal
server. If the question is about an internal host, the internal
server knows the answer. If it's about an external host, the internal
server forwards the query to the gateway server, which obtains the
answer and passes it back to the internal server, which then hands it
to the gateway client. Internal clients get all their answers from
the internal server, which either answers directly (because it was a
question about an internal host) or forwards the query to the gateway
and passes the answer back to the client. External clients get all
their answers from the gateway server, which only knows about the
things I want the outside world to see.
# If I get maximally paranoid, I tend to use a DMZ host that has two network
# interfaces. In this configuration you have the exterior router connected to
# one interface and the interior router connected to the other. You have to
# run routed and usually gated on the DMZ host, and now have a superior platform
# from which to do gatewayed filtering, by hi-jacking incoming and outgoing
# connection requests and connecting same to the process of your choice, which
# while ultimately doing the same thing as expected, may do additional logging
# or authentication.
I'm far more worried about holes in the UNIX hosts than holes in the routers.
# And, things get really interesting when you start having people who
# need to remotely access the secure side of the DMZ. How do you meet the
# requirements of not having "users" on the DMZ host and still get across?
# How do you keep people from picking passwords off as your TELNET session
# runs through who knows where?
Yeah, this is one of the currently sticky problems, for which I don't
have a really good solution.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Thu Dec 3 08:13:13 1992
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA18043; Thu, 3 Dec 92 08:13:13 PST
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA18035; Thu, 3 Dec 92 08:13:08 PST
Message-Id: <9212031613.AA18035@mycroft.GreatCircle.COM>
To: Firewalls@GreatCircle.COM
Subject: Re: Notes from Firewalls BOF at USENIX LISA Conference
In-Reply-To: Your message of Tue, 1 Dec 92 21:14:22 -0500
Date: Thu, 03 Dec 92 08:13:07 -0800
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Bob Sutterfield <bob@MorningStar.Com> writes:
# Does anybody let UDP packets through firewalls? Never let UDP
# through firewalls.
#
# What about DNS and NTP and other such benign stuff? They should all
# be handled by a proxy on the firewall or in a DMZ, right?
I let DNS through, but only because there's a quirk in BIND that lets
me do it with filters that only look at packet destination ports
(which is all most of the filtering implementations will let you look
at) without exposing any other UDP services.
The quirk is that when a BIND server talks to another name server,
both ends of the connection use port 53. Thus, I can allow only UDP
packets with a destination of port 53 (I don't need to allow all ports
>1023 for the return packets, like you must with most TCP services)
through the firewall, and DNS servers (or at least BIND-based servers)
on both sides of the firewall can talk to each other.
I haven't looked at NTP yet; none of the clients I've set up firewalls
for have requested it. If it uses a random port for one end of the
connection, I don't see any safe way to let NTP traffic through a
firewall that only looks at destination addresses; if you do, you'll
also end up exposing all RPC-based services, like YP and so forth.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Thu Dec 3 10:44:25 1992
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA18397; Thu, 3 Dec 92 10:44:25 PST
Received: from gatekeeper.es.dupont.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA18390; Thu, 3 Dec 92 10:44:17 PST
Received: by gatekeeper.es.dupont.com (5.65/ULTRIX-mjr-062991);
id AA17765; Thu, 3 Dec 92 13:44:38 -0500
Received: by esds01.es.dupont.com (5.65/ULTRIX-mjr-063191);
id AA08250; Thu, 3 Dec 92 13:44:36 -0500
Received: by wind.es.dupont.com (5.57/Ultrix3.0-C)
id AA08265; Thu, 3 Dec 92 13:44:26 -0500
Message-Id: <9212031844.AA08265@wind.es.dupont.com>
To: Brent Chapman <brent@GreatCircle.COM>
Cc: Firewalls@GreatCircle.COM
Subject: Re: Notes from Firewalls BOF at USENIX LISA Conference
In-Reply-To: Your message of "Thu, 03 Dec 92 08:13:07 PST."
<9212031613.AA18035@mycroft.GreatCircle.COM>
Date: Thu, 03 Dec 92 13:44:25 -0500
From: Mike Minnich <minnich@wind.es.dupont.com>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Brent,
NTP is fine as it uses port 123 for both source and destination port.
As for BIND, it's not quite as simple as that. One problem I've run into
is that your firewall host will typically run named, which implies that
UDP socket 23 is bound to it. If you want to point nslookup at
another server, you can't if your incoming filters only allow dest port 23 --
nslookup ends up using a source port >1023 which results in the following:
> server ns.nic.ddn.mil.
Default Server: ns.nic.ddn.mil
Address: 192.112.36.4
> set type=ns
> .
Server: ns.nic.ddn.mil
Address: 192.112.36.4
*** Request to ns.nic.ddn.mil timed-out
>
Mike
From Firewalls-Owner Tue Dec 22 14:07:18 1992
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA11700; Tue, 22 Dec 92 14:07:18 PST
Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA11693; Tue, 22 Dec 92 14:07:11 PST
Received: from sun.Eng.Sun.COM by Sun.COM (4.1/SMI-4.1)
id AA11986; Tue, 22 Dec 92 14:07:19 PST
Received: from sybase.UUCP by sun.Eng.Sun.COM (4.1/SMI-4.1)
id AA26780; Tue, 22 Dec 92 14:07:18 PST
Received: from ubu.sybgate.sybase.com by sybase.com (4.1/SMI-4.1/SybH3.0)
id AA00619; Tue, 22 Dec 92 11:56:54 PST
Received: from localhost by ubu.sybgate.sybase.com (4.1/SMI-4.1/SybEC3.1)
id AA25794; Tue, 22 Dec 92 11:56:52 PST
Message-Id: <9212221956.AA25794@ubu.sybgate.sybase.com>
To: avalon@coombs.anu.edu.au
Cc: firewalls@GreatCircle.COM
Subject: Re: Obvious (?) problem with allowing DNS..
In-Reply-To: Your message of Wed, 23 Dec 92 01:41:22 -0500.
<9212221441.AA23766@coombs.anu.edu.au>
Date: Tue, 22 Dec 92 11:56:51 -0800
From: Donald R. Proctor (510/596-3828) <sybase!donp@Sun.COM>
Content-Length: 1167
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> It has often been said that when setting up a firewall to allow DNS
> packets with both source and dest. of port 53 through. There seems
> to be an obvious flaw with this - what is to stop crackers using
> this 'hole' ? I don't recall if this was allowed just as far as the
> 'DMZ' or all the way through...
> Darren
The best approach is probably to set up an "internal" DNS domain and
an "external" DNS domain. The internal domain servers would talk to
internal root servers, and the external domain servers would talk to
the "real" root servers.
That way you don't need to open up port 53 from the DMZ to the internal
network(s).
Also, you may not have a need to advertise the name of every host on
your network to the outside world. In this case, the "external" DNS
server can operate with a very minimal DNS database configuration.
Of course, a crackers could still conceivably attack your firewall host
using port 53. My philosophy, though, is that your packet filtering
should be configured so that the firewall host can be completely com-
promised, and still not allow a cracker to access hosts on the internal
networks.
Don Proctor
Sybase, Inc.
From Firewalls-Owner Thu Jan 28 17:48:06 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA00630; Thu, 28 Jan 93 17:48:06 PST
Received: from Spectrum.CMC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA00623; Thu, 28 Jan 93 17:47:59 PST
Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum))
id AA25395; Thu, 28 Jan 93 17:46:31 PST
Newsgroups: list.firewalls
Path: lars
From: lars@spectrum.CMC.COM (Lars Poulsen)
Subject: Re: e-mail behind a firewall
Message-Id: <1993Jan29.014617.25357@spectrum.CMC.COM>
Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA
References: <19671.9301290124@nym.ossi.com>
Date: Fri, 29 Jan 93 01:46:17 GMT
Apparently-To: firewalls@greatcircle.com
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
In article <19671.9301290124@nym.ossi.com> aegl@ossi.com (Tony Luck) writes:
[How do we make our machines inside the firewall reachable for email
addressed to <user@machine.our.domain> even if that machine is
blocked by the firewall ?]
>planning on advertising 3 MX records for each host.
machine MX 0 machine
machine MX 10 mailgate1
machine MX 20 mailgate2
>
>Is this an OK plan? Will it even work!?
Works like a charm (this is what we do here).
>Has anyone ever ``fixed'' named to give
>different answers depending on who is asking the questions?
Actually, what you do is you run two different name servers on
different hosts. The root nameservers point to the servers with
the "outside view" zone. Your internal machines have resolver
configurations pointing to the "inside view" server. It is a lot of
hassle, though, and should not be necessary.
--
/ Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM
CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262
Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256
From Firewalls-Owner Sun Jan 31 13:55:36 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA07054; Sun, 31 Jan 93 13:55:36 PST
Received: from rara.ossi.com ([192.240.4.50]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA07047; Sun, 31 Jan 93 13:55:29 PST
Received: from nym.ossi.com ([192.240.2.13]) by rara.ossi.com; Sun, 31 Jan 93 13:55:32 PST
From: Tony Luck <aegl@ossi.com>
Date: Sun, 31 Jan 93 13:55:55 PST
Message-Id: <7798.9301312155@nym.ossi.com>
To: Firewalls@GreatCircle.COM
Subject: Re: e-mail behind a firewall
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
This is a public "thank you" for all the responses to my question about
setting up MX records in DNS. I think that only one of them was posted
to the firewalls list, so here is a summary for anyone else out there in
netland who wants to know:
My proposed idea for MX records for machines behind a firewall was:
MX 10 <points at self>
MX 20 <points at gateway one>
MX 30 <points at gateway two>
Where our filters prevent access to the machine directly from the internet,
but connection to the gateways are permitted.
This will work (and in fact is what *lots* of people are using already).
Several people remined me of the non-desirability of making internal machine
names visible:
1) It may be a security problem ("sensitive" information may be
embedded in hostnames, or the information may be used for "social
engineering" be a bad-guy with a silver tongue to talk their way
into places that they shouldn't be).
2) Its a dumb idea for users to embed their hostname in their e-mail
address (because then, they'll have a heck of a time telling
everyone when they move/rename machines).
I agree with you all, but for political reasons we will continue to have
the machine name visible in out-going mail headers from certain departments
(just don't ask ... if those people want to hang themselves, they can, I'm
fed up with the arguments). I did take a look at our current set of machine
names, and I don't think we are giving anything away (but if a psychiatrist
gets hold of them and does some analysis, we may get a visit from some men
wearing white coats offering to let us wear some of their "special" jackets :-)
Finally I asked if anyone knew of a modified name server that would provide
different answers depending on who was asking. Everyone who replied to this
part of my question advised me to just run the internal and external name
servers on different machines.
-Tony Luck <aegl@ossi.com>
From Firewalls-Owner Thu Feb 11 09:50:20 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA22228; Thu, 11 Feb 93 09:50:20 GMT
Received: from mail.Germany.EU.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA22219; Thu, 11 Feb 93 01:50:03 PST
Received: from sapwdf
by mail.Germany.EU.net with UUCP (5.65c/EUnetD-2.2.3.d)
via EUnet for greatcircle.com
id cF10844; Thu, 11 Feb 1993 10:49:58 +0100
Received: by sap-ag.de (5.52.1/SAP-1.2)
id AA29528; Thu, 11 Feb 93 06:04:11 +0100
for greatcircle.com!firewalls
Received: from tadpole.Tadpole.COM
by mail.Germany.EU.net with SMTP (5.65c/EUnetD-2.2.3.d)
via EUnet for sapwdf
id cA03876; Thu, 11 Feb 1993 05:33:05 +0100
Received: from ono-sendai (ono-sendai.tadtec.co.uk) by tadpole.tadpole.com (4.1/SMI-4.1)
id AA24115; Wed, 10 Feb 93 22:33:24 CST
Received: by ono-sendai (4.1/SPARCbook_POP)
id AA07487; Wed, 10 Feb 93 22:33:33 CST
Date: Wed, 10 Feb 93 22:33:33 CST
From: jim@tadpole.com (Jim Thompson)
Message-Id: <9302110433.AA07487@ono-sendai>
To: firewalls-digest@sap-ag.de, wohler@sap-ag.de
Subject: Re: firewalls and dns
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Since the second nameserver is supposed to be geographicly
diverse from the first, many people make arrangements with
some other organization (typically their IP provider) to
supply a secondary server for their zone(s).
Jim
From Firewalls-Owner Thu Feb 11 16:21:44 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA22937; Thu, 11 Feb 93 16:21:44 GMT
Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA22930; Thu, 11 Feb 93 08:21:20 PST
Received: from alias by yonge.csri.toronto.edu with UUCP id <14489>; Thu, 11 Feb 1993 11:21:34 -0500eceived: from dino.alias.com by barney.alias.com with SMTP id AA02023
(5.65a/IDA-1.4.2 for wohler@sap-ag.de); Thu, 11 Feb 93 10:38:37 -0500
Received: by dino.alias.com id AA07464
(5.65a/IDA-1.4.2 for firewalls@greatcircle.com); Thu, 11 Feb 93 10:38:37 -0500
From: chk@alias.com (C. Harald Koch)
Message-Id: <9302111538.AA07464@dino.alias.com>
Subject: Re: firewalls and dns
To: wohler@sap-ag.de
Date: Thu, 11 Feb 1993 10:38:35 -0500
Cc: firewalls@GreatCircle.COM
In-Reply-To: <9302110226.AA24234@sap-ag.de> from "Bill Wohler" at Feb 10, 93 09:23:55 pm
X-Mailer: ELM [version 2.4 PL8]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1006
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> dns requires that each domain have two name servers. if my firewall
> only allows one host in my network (and domain as well) to be accessed,
> where does this second name server come from?
Your second DNS server shold be at some other friendly site out there, or
your network provider. It's strongly encouraged that your primary
nameservers are on different networks in the Internet, so that even if your
entire net goes down, nameservice for you still works.
Many European sites have this problem; 90% of the time you get
"Authoritative host unknown" errors when trying to contact them, and then
suddenly their network comes back and everything works. This is not good...
--
Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON
action, there is an equal | chk@alias.com (work-related mail)
and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address)
program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet)
From Firewalls-Owner Thu Feb 11 17:36:11 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA23190; Thu, 11 Feb 93 17:36:11 GMT
Received: from sayshell.umd.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA23182; Thu, 11 Feb 93 09:35:51 PST
Received: from localhost by sayshell.umd.edu (NX5.67c/NeXT-1.0)
id AA03115; Thu, 11 Feb 93 12:35:44 -0500
Message-Id: <9302111735.AA03115@sayshell.umd.edu>
To: chk@alias.com (C. Harald Koch)
Cc: wohler@sap-ag.de, firewalls@GreatCircle.COM
From: "Louis A. Mamakos" <louie@NI.umd.edu>
Subject: Re: firewalls and dns
In-Reply-To: Your message of "Thu, 11 Feb 1993 10:38:35 EST."
<9302111538.AA07464@dino.alias.com>
Date: Thu, 11 Feb 1993 12:35:43 -0500
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> > dns requires that each domain have two name servers. if my firewall
> > only allows one host in my network (and domain as well) to be accessed,
> > where does this second name server come from?
Actually, there is nothing in the DNS protocol which requires multiple
servers; its just that the system is much more robust with multiple
servers. Also note that the number of servers required per zone is
more a policy issue of the parent zone that your subdomain is being
registered in.
> Your second DNS server shold be at some other friendly site out there, or
> your network provider. It's strongly encouraged that your primary
> nameservers are on different networks in the Internet, so that even if your
> entire net goes down, nameservice for you still works.
While its helpful to have a DNS server at another site, strictly
speaking, its not necessary. If you network is unreachable, what good
does it to be able to look up DNS info when no one can contact any of
your hosts? (That's assuming that all your hosts are all in one
place). If your network is multi-site, then multiple-sited servers
become more important.
> Many European sites have this problem; 90% of the time you get
> "Authoritative host unknown" errors when trying to contact them, and then
> suddenly their network comes back and everything works. This is not good...
This means that YOUR software is broken, not the DNS or the
configuration of the DNS servers. You should not be getting
"Authoritative host unknown" errors, since you can't reach a server!
I don't experience these problems.
Only the authoriative servers for a zone can return a Non-existant
Domain error. Your software should return a soft error if it doesn't
get a reply from the server, which in the case of mail, should mean
that the operation will be retried later on.
Louis A. Mamakos
University of Maryland, College Park
From Firewalls-Owner Thu Feb 11 18:56:46 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA23485; Thu, 11 Feb 93 18:56:46 GMT
Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA23478; Thu, 11 Feb 93 10:56:35 PST
Received: from shingml.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA01223
(5.65b/HUJI 4.27 for firewalls@greatcircle.com); Thu, 11 Feb 93 20:57:37 +0200
Received: from shuldig.cs.huji.ac.il by shingml.cs.huji.ac.il with SMTP id AA00796
(5.65b/HUJI 4.1 for louie@ni.umd.edu); Thu, 11 Feb 93 20:57:54 +0200
Received: from localhost by shuldig.cs.huji.ac.il with SMTP id AA27933
(5.65c/HUJI 4.1 for firewalls@greatcircle.com); Thu, 11 Feb 1993 20:57:52 +0200
Message-Id: <199302111857.AA27933@shuldig.cs.huji.ac.il>
To: "Louis A. Mamakos" <louie@ni.umd.edu>
Cc: firewalls@GreatCircle.COM
Subject: Re: firewalls and dns
In-Reply-To: Your message of Thu, 11 Feb 1993 12:35:43 -0500 .
<9302111735.AA03115@sayshell.umd.edu>
From: Amos Shapira <amoss@cs.huji.ac.il>
Date: Thu, 11 Feb 1993 20:57:45 +0200
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
In message <9302111735.AA03115@sayshell.umd.edu> you write:
| If you network is unreachable, what good
|does it to be able to look up DNS info when no one can contact any of
|your hosts?
Mail Xchangers for one example. Validating names for another (e.g. I dunno
how sendmail does it, but it might be able to determine the address is wrong
and return it to the sender without having to wait for the net to come up).
I guess you can find many other examples.
|Only the authoriative servers for a zone can return a Non-existant
|Domain error.
Aren't secondary servers also defined "authoritative"? Does the above sentence
invalidates my examples? I think not, but it's a long time since I wrote
DNS code...
Cheers,
--Amos Shapira
CS System Group, Hebrew University, Jerusalem, Israel
amoss@cs.huji.ac.il
From Firewalls-Owner Thu Feb 11 20:38:44 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA23881; Thu, 11 Feb 93 20:38:44 GMT
Received: from sayshell.umd.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA23874; Thu, 11 Feb 93 12:38:37 PST
Received: from localhost by sayshell.umd.edu (NX5.67c/NeXT-1.0)
id AA03793; Thu, 11 Feb 93 15:38:54 -0500
Message-Id: <9302112038.AA03793@sayshell.umd.edu>
To: Amos Shapira <amoss@cs.huji.ac.il>
Cc: firewalls@GreatCircle.COM
From: "Louis A. Mamakos" <louie@NI.umd.edu>
Subject: Re: firewalls and dns
In-Reply-To: Your message of "Thu, 11 Feb 1993 20:57:45 +0200."
<199302111857.AA27933@shuldig.cs.huji.ac.il>
Date: Thu, 11 Feb 1993 15:38:54 -0500
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> Mail Xchangers for one example. Validating names for another (e.g. I dunno
> how sendmail does it, but it might be able to determine the address is wrong
> and return it to the sender without having to wait for the net to come up).
>
> I guess you can find many other examples.
I did qualify my comments with "if all your hosts are in one place"..
> |Only the authoriative servers for a zone can return a Non-existant
> |Domain error.
>
> Aren't secondary servers also defined "authoritative"? Does the above sentenc
e
> invalidates my examples? I think not, but it's a long time since I wrote
> DNS code...
Primary and secondary only reflect the mechanism used to load the zone
data into the authoritative server. They are both equally
authoritative. If a secondary server (which loads the zone by doing a
zone transfer over the internet) is unable to load the zone, it should
respond with "Server Error" rather than "Nonexistant Domain"; that is,
it should still be treated as a temporary failure.
Louis A. Mamakos
University of Maryland, College Park
From Firewalls-Owner Tue Feb 16 23:01:43 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA11546; Tue, 16 Feb 93 23:01:43 GMT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA11533; Tue, 16 Feb 93 15:01:09 PST
Message-Id: <9302162301.AA11533@mycroft.GreatCircle.COM>
To: Tony Luck <aegl@ossi.com>
Cc: Firewalls@GreatCircle.COM
Subject: Re: e-mail behind a firewall
In-Reply-To: Your message of Thu, 28 Jan 93 17:24:29 PST
Date: Tue, 16 Feb 93 15:01:07 -0800
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
# We've almost got our internet connection ... but the question of how to
# make e-mail work is puzzling some of us.
#
# We are using filters in a router to block undesirable packets from reaching
# our local net from the big bad world. Most of our systems are Sun4's of
# various vintages mostly running SunOS 4.1.2.
#
# My question is on how to set up DNS. Currently we don't care if the outside
# world can see our local hostnames ... in fact some parts of the company seem
# to think that it is a neat idea for their workstation name to appear on e-mail
# headers ... this means that we have to support incoming mail with addresses
# like:
# <user@machine.our.domain>
#
# If we ran separate name servers for internal and external consumption, we
# could support this by advertising MX records on the internet for all local
# machines pointing them at our two mail servers ... while internally the
# MX records for each host would point at themselves.
#
# But, we don't think that we want separate name servers. So currently we are
# planning on advertising 3 MX records for each host. The highest priority
# will point to itself, the next two point to each of the mail gateways. Thus
# from inside the firewall, people will choose the first MX record and deliver
# directly. From outside, machines will first try direct delivery and get
# bounced by the filter in the router with ICMP_UNREACHABLE ... and so they
# should fall back to one of the other MX records and deliver to one of our
# gateways.
#
# Is this an OK plan? Will it even work!? Should we really go for different
# internal and external name servers? Has anyone ever ``fixed'' named to give
# different answers depending on who is asking the questions?
#
# -Tony Luck <aegl@ossi.com>
Did you ever get an answer to this? Basicly, yes, it will work. I've
got a couple of sites that are set up that way. The biggest thing you
have to be careful of is that some versions of Sendmail (particularly
on Suns, unless you've installed Sun patch 100377) are buggy, and
don't reliably recognize themselves in a list of MX records for an
internal host. If you're running such a broken Sendmail on your
gateway, and the internal host happens to be down, the gateway will
happily try the next host in the list, which is itself. What it
_should_ do is notice that the next-best-host is itself, and simply
hold on to the message. What it _will_ do is open an SMTP connection
to itself, which trips the "I refuse to talk to myself" or "hostname
configuration error" trap (depending on which version of Sendmail you
have), and bounces the message.
Setting up multiple DNS servers is not difficult. You set up the
gateway machine to have a DNS server that only knows what you want the
outside world to know. You set up another DNS server on an internal
machine that knows about all your hosts and forwards non-local queries
to the gateway DNS server (via a "forwarders" line in the
/etc/named.boot file). You rig all DNS clients (via their
/etc/resolv.conf files), PARTICULARLY including those on the gateway
host, to talk to the internal server. If a client (even on the
gateway) asks a question about an internal machine, it gets the answer
from the internal server. If a client (internal or gateway) asks
about an external machine, the internal server forwards the query to
the gateway server, then forwards the response back to the client. If
somebody out on the Internet asks something, however, they can only
get back what the gateway server knows (which isn't much).
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Fri Feb 19 02:37:51 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA21558; Fri, 19 Feb 93 02:37:51 GMT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA21549; Thu, 18 Feb 93 18:37:18 PST
Message-Id: <9302190237.AA21549@mycroft.GreatCircle.COM>
To: gjkriger@gjk.OCUnix.on.ca (George J. Kriger)
Cc: Firewalls@GreatCircle.COM
Subject: Re: e-mail behind a firewall
In-Reply-To: Your message of Thu, 18 Feb 1993 07:23:49 -0500
Date: Thu, 18 Feb 93 18:37:16 -0800
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
gjkriger@gjk.OCUnix.on.ca (George J. Kriger) writes:
# brent@GreatCircle.COM <Brent Chapman> wrote:
# > Setting up multiple DNS servers is not difficult. You set up the
# > gateway machine to have a DNS server that only knows what you want the
# > outside world to know. You set up another DNS server on an internal
# > machine that knows about all your hosts and forwards non-local queries
# > to the gateway DNS server (via a "forwarders" line in the
# > /etc/named.boot file). You rig all DNS clients (via their
# > /etc/resolv.conf files), PARTICULARLY including those on the gateway
# > host, to talk to the internal server. If a client (even on the
# > gateway) asks a question about an internal machine, it gets the answer
# > from the internal server. If a client (internal or gateway) asks
# > about an external machine, the internal server forwards the query to
# > the gateway server, then forwards the response back to the client. If
# > somebody out on the Internet asks something, however, they can only
# > get back what the gateway server knows (which isn't much).
#
# - Will this work if the gateway server is a dual homed host configured
# not to forward packets (IPFORWARDING=-1) [I can't see why not, but I
# thought I'd check].
It should. The packets are going to and from the in.named server on
the gateway, not through the gateway as a router. The gateway gets a
request from internal host X, and sends out a request from itself to
external host Y; it takes the answer it gets back from external host
Y, and sends it as an answer from itself back to internal host X.
Automated plagarism... :-)
# - I like the setup above, but suppose that I don't have the resources
# to set up the internal DNS server immediately. Can I set things up so
# that internal hosts can get/send mail from/to the gateway, and still
# not reveal the internal hosts when the gateway is queried from the
# Internet ?
Not as far as I know. I'm unaware of any DNS server that will tell
different things to different machines, though it's certainly
something folks have talked about and wished for repeatedly.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Fri Feb 19 15:49:56 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA23682; Fri, 19 Feb 93 15:49:56 GMT
Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA23675; Fri, 19 Feb 93 07:49:31 PST
Received: from alias by yonge.csri.toronto.edu with UUCP id <14466>; Fri, 19 Feb 1993 10:49:35 -0500eceived: from dino.alias.com by barney.alias.com with SMTP id AA16500
(5.65a/IDA-1.4.2 for gjkriger@gjk.OCUnix.on.ca); Fri, 19 Feb 93 10:37:38 -0500
Received: by dino.alias.com id AA03447
(5.65a/IDA-1.4.2 for Firewalls@GreatCircle.COM); Fri, 19 Feb 93 10:37:36 -0500
From: chk@alias.com (C. Harald Koch)
Message-Id: <9302191537.AA03447@dino.alias.com>
Subject: Re: e-mail behind a firewall
To: gjkriger@gjk.OCUnix.on.ca (George J. Kriger)
Date: Fri, 19 Feb 1993 10:37:34 -0500
Cc: Firewalls@GreatCircle.COM
In-Reply-To: <9302190715.AA28908@gjk.OCUnix.on.ca> from "George J. Kriger" at Feb 19, 93 07:15:39 am-Mailer: ELM [version 2.4 PL8]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 952
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> I only have enough resources for now to run one DNS server and that's on
I'm sorry, but I have to protest this comment...
If there are so few hosts in your organization, a DNS server takes almost
no disk/memory/CPU time; surely you can install more than one?
I have six networks here, each with from 5 to 40 machines. Each network has
two DNS servers on it. This is for redundancy; if our routers go down, the
networks still have DNS, so that hostname lookups still succeed.
Unless you're providing name service for thousands of hosts, you should be
able to run a DNS server on every machine and still not "eat resources"...
--
Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON
action, there is an equal | chk@alias.com (work-related mail)
and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address)
program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet)
From Firewalls-Owner Sat Feb 20 02:43:00 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA27066; Sat, 20 Feb 93 02:43:00 GMT
Received: from rain.psg.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA27059; Fri, 19 Feb 93 18:42:54 PST
Received: by rain.psg.com (/\==/\ Smail3.1.25.1 #25.4)
id <m0nPkAs-000bfwC@rain.psg.com>; Fri, 19 Feb 93 18:42 PST
Message-Id: <m0nPkAs-000bfwC@rain.psg.com>
From: randy@psg.com (Randy Bush)
Subject: Re: e-mail behind a firewall
To: gjkriger@gjk.OCUnix.on.ca (George J. Kriger)
Date: Fri, 19 Feb 1993 18:42:41 -0800 (PST)
Cc: Firewalls@GreatCircle.COM
In-Reply-To: <9302190715.AA28908@gjk.OCUnix.on.ca> from "George J. Kriger" at Feb 19, 93 07:15:39 amime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 501
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> I only have enough resources for now to run one DNS server and that's on
> the gateway. Behind the gateway, there will be < 6 hosts that can reach the
> gateway, a subset of the hosts on the Ethernet. A 2nd server should
> arrive ~May/June (famous last words :-)
>
> I want to minimize the info given out to the external world, how can I do
> this ??
You're gonna puke. What we do here in RAINet is to MX the hosts behind the
firewall sites, and use an /etc/hosts file <gasp> for internal hosts.
From Firewalls-Owner Mon Feb 22 06:30:16 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA09736; Mon, 22 Feb 93 06:30:16 GMT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA09725; Sun, 21 Feb 93 22:30:04 PST
Message-Id: <9302220630.AA09725@mycroft.GreatCircle.COM>
To: gjkriger@gjk.OCUnix.on.ca (George J. Kriger)
Cc: firewalls@GreatCircle.COM
Subject: Re: filtering RIP and DNS
In-Reply-To: Your message of Sun, 21 Feb 1993 21:27:51 -0500
Date: Sun, 21 Feb 93 22:30:03 -0800
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
gjkriger@gjk.OCUnix.on.ca (George J. Kriger) writes:
# I'm using a Cisco router and a multi-homed UNIX-based host with
# IPFORWARDING turned off. The host isn't doing any routing.
# Does the router have to pass RIP ?? Why ??
If that router is your sole connection to the Internet, then you don't
need to run RIP or any other routing protocol on it. Just set up
all the internal networks to have a default route that gets them to
the perimeter router.
# Regarding DNS, I understand that server-to-server proxy queries are made
# via UDP with port 53 for both the source and the destination (assuming BIND
# is used). But what about server-to-server bulk data transfer via TCP. I
# assume that when the host gets such a request, the destination is port 53, but
# the source is a "random" port >1023. Similiarly when the host initiates
# such the request. Are these assumptions correct ??
Yes, as far as I know. Allowing zone transfers is not that big a
problem because they use TCP rather than UDP. You want to block all
the random UDP ports, because you don't know where RPC-based services
are going to end up in the UDP port range. Fortunately, most of the
really troublesome RPC-based services (NFS and YP in particular) are
UDP-only on most machines, though there are some TCP versions of NFS
starting to appear.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Thu Feb 25 19:58:32 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA24139; Thu, 25 Feb 93 19:58:32 GMT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA24131; Thu, 25 Feb 93 11:58:21 PST
Message-Id: <9302251958.AA24131@mycroft.GreatCircle.COM>
To: chk@alias.com (C. Harald Koch)
Cc: gjkriger@gjk.OCUnix.on.ca (George J. Kriger), Firewalls@GreatCircle.COM
Subject: Re: e-mail behind a firewall
In-Reply-To: Your message of Fri, 19 Feb 1993 10:37:34 -0500
Date: Thu, 25 Feb 93 11:58:20 -0800
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
# > I only have enough resources for now to run one DNS server and that's on
#
# I'm sorry, but I have to protest this comment...
#
# If there are so few hosts in your organization, a DNS server takes almost
# no disk/memory/CPU time; surely you can install more than one?
It may be that there's only one UNIX machine at the site, and that the
rest are all Macs or PCs. I find that to be a fairly common
configuration; a site that's already an established Mac or PC shop
will buy one UNIX box to be the gateway and run DNS and so forth.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Fri Feb 26 02:44:56 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA25795; Fri, 26 Feb 93 02:44:56 GMT
Received: from gate.demon.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA25787; Thu, 25 Feb 93 18:44:39 PST
Received: from demon.demon.co.uk by gate.demon.co.uk id ad12304;
26 Feb 93 2:43 GMT
Received: from cellnet.uucp by demon.demon.co.uk id aa07064; 26 Feb 93 2:41 GMT
From: Steve Kennedy <steve@gbnet.org>
Message-Id: <10000.9302260028@marvin.gbnet.org>
Subject: Re: e-mail behind a firewall
To: greatcircle.com!brent@gbnet.org
Date: Fri, 26 Feb 93 0:28:51 GMT
Cc: alias.com!chk@gbnet.org, gjk.ocunix.on.ca!gjkriger@gbnet.org,
greatcircle.com!Firewalls@gbnet.org
In-Reply-To: <9302251958.AA24131@mycroft.GreatCircle.COM>; from "Brent Chapman" at Feb 25, 93 11:58
X-Subliminal-Message: Send large quantities of used bills.
X-Mailer: ELM [version 2.3 PL11]
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Brent,
> # > I only have enough resources for now to run one DNS server and that's on
> # I'm sorry, but I have to protest this comment...
> # If there are so few hosts in your organization, a DNS server takes almost
> # no disk/memory/CPU time; surely you can install more than one?
>
> It may be that there's only one UNIX machine at the site, and that the
> rest are all Macs or PCs. I find that to be a fairly common
> configuration; a site that's already an established Mac or PC shop
> will buy one UNIX box to be the gateway and run DNS and so forth.
You can always get a PC DNS server (there is a BIND for PC/TCP+, Chameleon,
Super-tcp etc ...).
Steve
--
___ |_ ___ ___ Tel: +44 (0)71 483 1169 Voice
(___ | (___) \ / (___) Data: 483 2454 WorldBlazer T3000 PEP+/v32bis...
___) | (___ \/ (___ Data: 483 2455 Miracom Courier HST/DS+ V32bis/HST
Email Snail Mail
steve@gbnet.org/steve@gbnet.com [home] Steve Kennedy
steve@marvin.demon.co.uk [DIS dialup internet] Flat 2, 43 Howitt Rd
steve@cellnet.co.uk [work] London, NW3 4LU
From Firewalls-Owner Sun Mar 14 02:22:14 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA12275; Sun, 14 Mar 93 02:22:14 GMT
Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA12268; Sat, 13 Mar 93 18:22:08 PST
Received: by TIS.COM (4.1/SUN-5.64)
id AA28805; Sat, 13 Mar 93 21:22:38 EST
Date: Sat, 13 Mar 93 21:22:38 EST
From: Marcus J Ranum <mjr@TIS.COM>
Message-Id: <9303140222.AA28805@TIS.COM>
To: FireWalls@GreatCircle.COM, mischler@cubic.com
Subject: Re: DNS Client Ports
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
>Should I allow "random" client ports through? What are the security
>implications?
One implication is that anyone with a tunnelling driver can
run IP tunnelled through your firewall using NS packets as the
transport layer.
Yes, I have code that does this. ;)
mjr.
From Firewalls-Owner Sun Mar 14 04:12:16 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA12451; Sun, 14 Mar 93 04:12:16 GMT
Received: from Spectrum.CMC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA12444; Sat, 13 Mar 93 20:12:09 PST
Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum))
id AA16731; Sat, 13 Mar 93 20:10:15 PST
Newsgroups: list.firewalls
Path: lars
From: lars@spectrum.CMC.COM (Lars Poulsen)
Subject: Re: DNS Client Ports
Message-Id: <1993Mar14.041004.16681@spectrum.CMC.COM>
Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA
References: <9303140222.AA28805@TIS.COM>
Date: Sun, 14 Mar 93 04:10:04 GMT
Apparently-To: firewalls@greatcircle.com
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Dave Mischler asks:
>>Should I allow "random" client ports through? What are the security
>>implications?
In article <9303140222.AA28805@TIS.COM> mjr@TIS.COM (Marcus J Ranum) writes:
> One implication is that anyone with a tunnelling driver can
>run IP tunnelled through your firewall using NS packets as the
>transport layer.
>
> Yes, I have code that does this. ;)
You need to allow access to port 53 on your DNS server from ANYWHERE
unless you want to preclude many normal maintenance and troubleshooting
activities. (NSLOOKUP for example).
And no, you probably should not allow access to port 53 of other
machines inside to cross the firewall. The above is a good example why.
--
/ Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM
CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262
Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256
From Firewalls-Owner Thu Mar 18 17:02:33 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA28915; Thu, 18 Mar 93 17:02:33 GMT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA28886; Thu, 18 Mar 93 09:01:47 PST
Message-Id: <9303181701.AA28886@mycroft.GreatCircle.COM>
To: "Scott M. Hinnrichs" <smh@netserv.com>
Cc: firewalls@GreatCircle.COM
Subject: Re: DNS/libresolv/4.1.3/dlopen ld complaints
In-Reply-To: Your message of Thu, 18 Mar 93 02:35:48 PST
Date: Thu, 18 Mar 93 09:01:46 -0800
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
# Well, this may not *really* be a firewall problem, but I am getting this
# problem building code for my firewall. I haven't lived under a DNS
# patched libc.so for while now. I just installed the libresolv.a objs
# in libc.so and now I am getting complaints from ld when making source:
#
# cc -O -DDEBUG dig.c -L`pwd` -lresolv list.o -o dig
# ld: Undefined symbol
# _dlopen
# _dlclose
# _dlsym
# __mbstowcs_xccs
# __mbtowc_xccs
# __wcstombs_xccs
# __wctomb_xccs
#
# This must be due to something obvious I am doing wrong. The patched libc.so
# is working fine and the binary ld creates works too! But, many makefiles
# won't do a build even when using make -k, and it is a real pain... anyone
# seen this already??
#
# Thanks, Scott
In /usr/lib/shlib.etc/Makefile, add a "-ldl" flag to the end of the
"ld" command for the "libc.so" target, then rebuild the shared
library. That will take care of the first problem.
I'll bet the second problem is caused by not renaming
"xccs.multibyte." to "xccs.multibyte.o" after using "ar" to unpack
"libc_pic.a". There are three files in libc_pic.a that have long
filenames, that have to be renamed before the shared library is built.
If I recall correctly, the "README" file lists some but not all of
them. The three files are "rpc_commondata.", "rpc_dtablesize.", and
"xccs.multibyte."; all need to be renamed to end in ".o" instead of
just ".".
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Thu Mar 18 17:08:27 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA29019; Thu, 18 Mar 93 17:08:27 GMT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA28997; Thu, 18 Mar 93 09:07:58 PST
Message-Id: <9303181707.AA28997@mycroft.GreatCircle.COM>
To: peterg@murphy.com (Peter Gutmann)
Cc: Firewalls@GreatCircle.COM
Subject: Re: DNS/libresolv/4.1.3/dlopen ld complaints
In-Reply-To: Your message of Thu, 18 Mar 93 10:33:36 EST
From: Brent Chapman <brent@GreatCircle.COM>
Date: Thu, 18 Mar 93 09:07:57 -0800
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
# > cc -O -DDEBUG dig.c -L`pwd` -lresolv list.o -o dig
# > ld: Undefined symbol
# > _dlopen
# > _dlclose
# > _dlsym
# > __mbstowcs_xccs
# > __mbtowc_xccs
# > __wcstombs_xccs
# > __wctomb_xccs
#
# You need to add the -ldl (dynamic loading libs) to the cc
Doing that makes _that_ cc work, but who wants to add "-ldl" to every
cc in every Makefile on their system?
Adding "-ldl" to the "ld" step of building the shared library, as I
described in my previous message, solves the problem without requiring
you to tweak every Makefile on your system.
- -Brent
- --
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
------- End of Forwarded Message
From Firewalls-Owner Thu Mar 18 17:32:13 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA29100; Thu, 18 Mar 93 17:32:13 GMT
Received: from mail-relay-2.mv.us.adobe.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA29087; Thu, 18 Mar 93 09:31:47 PST
Received: by mail-relay-2.mv.us.adobe.com; id AA06442; Thu, 18 Mar 93 09:32:08 -0800
Received: by guardi.mv.us.adobe.com; id AA20640; Thu, 18 Mar 93 09:32:05 -0800
Message-Id: <9303181732.AA20640@guardi.mv.us.adobe.com>
To: "Scott M. Hinnrichs" <smh@netserv.com>
Cc: firewalls@GreatCircle.COM
Subject: Re: DNS/libresolv/4.1.3/dlopen ld complaints
In-Reply-To: Your message of "Thu, 18 Mar 93 02:35:48 PST."
<9303181035.AA00268@tardis>
Date: Thu, 18 Mar 93 09:32:04 PST
From: Tim Guarnieri <timg@mv.us.adobe.com>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Hmm. When you rebuilt libc.so, did you put -ldl on the following
line:
ld -assert pure-text `${OBJSORT} lorder-sparc tmp` -ldl
^^^^
If you didn't, I can see where this error would occur.
Tim
BTW: Attached is a "How to modify SunOS to use DNS instead of YP" note
that I pulled off the net a while ago. I found it very helpful
when rebuilding libc.so. Hope it helps.
-----------------
NEW BIND FOR SUNS 2/11/91
-----------------
[Partially taken from the document "Making a libc.so for DNS without NIS"
that has been distributed to various SunOS users, and seen on Usenet.
Original document by Paul Balyoz (pab@naucse.cse.nau.edu).
Updated to include OS4.1.2 information, Hal Pomeranz, 3/3/92.
]
This document tells how to install a NEW version of the BIND Name Server
resolver routines into the shared C library of a Sparcstation running
SunOS 4.1 or greater. The procedure is a bit different when you are
trying to install a version of BIND distributed from Berkeley, compared
to the (older) resolver library that comes with SunOS.
A. Get BIND version 4.8.3 or later. We must fix the Makefile in the
resolver directory to do what our sparcstation needs. The whole idea
here is to compile the C source to .o files with the -pic option,
and not do anything fancy to the .o files before putting them into
the new libresolv.a library. Note that we rename your old libresolv.a
file, so that it can be recovered if the new one doesn't work!
cd Bind4.8.3/res
vi Makefile
Comment out all sets of lines that look something like:
-ld -r -x file.o
mv a.out file.o
Add to the "CFLAGS" variable the option
-pic
(so that a global tags entry gets added to each .o file)
Fix paths and options in Makefile as needed.
make
mv /usr/lib/libresolv.a /usr/lib/libresolv.a.orig
make install
This should have created the new /usr/lib/libresolv.a library.
Please also note that the string(3) man-page which comes with SunOS
is more complete than the one distributed with BIND! Therefore you
should NOT replace it as instructed to by BIND's README instructions.
B. Follow the steps below to make a new shared library on your Sun
which includes the new resolver library routines in it.
1. Become super user by logging in as root, or first as a normal
user and then typing:
su
2. Move into the shared-lib area and make a temporary directory:
cd /usr/lib/shlib.etc
mkdir tmp
3. Move into this new directory, extract the pic (position
independent code) object files from libc_pic.a and remove
the SYMDEF file. The renaming (mv commands) is done because
the "ar" command truncates names to 16 characters.
cd tmp
ar x ../libc_pic.a
rm __.SYMDEF
mv rpc_dtablesize. rpc_dtablesize.o
mv rpc_commondata. rpc_commondata.o
mv xccs.multibyte. xccs.multibyte.o
4. We now need to extract the object files from your new libresolv.a
library, making sure not to overwrite two of the Sun objects
already in this directory:
mv mktemp.o mktemp.o2 # else it gets stomped
mv strpbrk.o strpbrk.o2 # else it gets stomped
ar x /usr/lib/libresolv.a
mv strpbrk.o2 strpbrk.o # we gotta use Sun's.
mv mktemp.o2 mktemp.o # we gotta use Sun's.
(Any other object files that get overwritten are ok.)
[ Alternatively you can extract Sun's original mktemp.o
and strpbrk.o files again at this point by typing:
ar x ../libc_pic.a mktemp.o strpbrk.o ]
5. Make sure the old host resolver is not still lying around:
rm gethostent.o
(ignore error "rm: gethostent.o nonexistent" if you see it.)
6. Remove the new resolver's string code because Sun's libraries
already includes this, so it would be redundant:
rm strcasecmp.o
7. Go back up to the shared library building directory and
duplicate the list of object files to use:
cd ..
cp lorder-sparc lorder-sparc.orig
8. Edit this object file list and make the following modifications
if they haven't already been done before to this file:
remove: gethostent.o
add: gethostnamadr.o
sethostent.o
res_query.o
res_mkquery.o
res_send.o
res_debug.o
res_comp.o
res_init.o
herror.o
strerr.o
(the last two are new, which Sun's resolver doesn't use)
After deleting gethostent.o, you can use the following
patch, or make the changes by hand (in this order):
***************
*** 149,154 ****
--- 149,164 ----
listen.o
getwd.o
getnetgrent.o
+ gethostnamadr.o
+ herror.o
+ sethostent.o
+ res_query.o
+ res_mkquery.o
+ res_send.o
+ res_debug.o
+ res_comp.o
+ res_init.o
+ strerror.o
ypxdr.o
ttyname.o
setbuffer.o
9. The Makefile in shlib.etc for building shared libraries
has one problem when you run it as the super user. So
edit it and modify the definition of "OBJSORT" to read:
OBJSORT=./objsort
If you are using SunOS 4.1.2, change the lines (there are two)
in the Makefile which read
ld -assert pure-text `${OBJSORT} lorder-sparc tmp`
to read
ld -assert pure-text `${OBJSORT} lorder-sparc tmp` -ldl
10. Now we can finally build the shared library. Type:
make libc.so
What kind of errors might you get? Here's a couple:
a. It blows up on one of the .o files in tmp, saying
that the object file is in an inconsistent state.
SOLUTION: start over; you did something wrong when you
compiled the new libresolv.a in section A, above.
Make SURE not to let Makefile "ld" the object files!
b. It lists hundreds of error lines about offsets or
addresses being wrong in all your resolver .o files.
SOLUTION: start over; you needed to specify "-pic"
to the C compiler when building the libresolv.a library.
11. If all goes well, you now have a "libc.so.x.y.z" in this
directory. Test it out before installing it systemwide!
You can do this by pointing your shell's library path
variable to the current directory, then trying various
networking commands:
setenv LD_LIBRARY_PATH `pwd`
ping some.host.edu
ftp another.host.com
telnet someone.else.ca
unsetenv LD_LIBRARY_PATH
If anything in the library fails, you need to start
section B over again. Maybe you forgot to use Sun's
versions of mktemp.o and strpbrk.o; things just won't
work with BIND's new versions of these files.
12. When you are sure it's working OK, you can install it
into the system library directory:
cp lib.so.x.y.z /usr/lib
chmod 755 /usr/lib/lib.so.x.y.z
ldconfig
13. You can prove that you're using the new library now,
by watching the output of something like:
trace date
The lastest BIND resolver is now installed on your system.
You can go ahead and compile and install the other BIND
tools such as named, nslookup, etc. You do not need to
specify the "-lresolv" library when compiling these tools.
From Firewalls-Owner Thu Mar 18 19:14:36 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA29437; Thu, 18 Mar 93 19:14:36 GMT
Received: from tardis ([198.37.128.10]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA29430; Thu, 18 Mar 93 11:14:27 PST
Received: by tardis (4.1/netserv-1.0) id AA00528; Thu, 18 Mar 93 11:16:03 PST
Date: Thu, 18 Mar 93 11:16:03 PST
From: Scott M. Hinnrichs <smh@netserv.com>
Message-Id: <9303181916.AA00528@tardis>
To: smh@netserv.com, ckaul@cs.sandia.gov
Subject: Re: DNS/libresolv/4.1.3/dlopen ld complaints
Cc: firewalls@GreatCircle.COM, len@netsys.com
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Ok, Clint wins ;-) He answered correctly first. I *knew* it was a lame
question/answer but *I* didn't know :(
My SunSpots article was from '90, and I hadn't done it since then. Thank
god I didn't suffer for a couple of months like some of the post'ers.
Thanks all!, Scott
> From ckaul@cs.sandia.gov Thu Mar 18 05:51:14 1993
> Date: Thu, 18 Mar 93 06:49:32 MST
> From: ckaul@cs.sandia.gov (Clint Kaul)
> To: smh@netserv.com
> Subject: Re: DNS/libresolv/4.1.3/dlopen ld complaints
> Content-Length: 697
>
> Scott,
>
> You have stumbled across two common problems. You are probably running
> SunOS 4.1.2 or 4.1.3. There are two mods that need to be done:
>
> 1. In /usr/lib/shlib.etc/Makefile under the libc.so target:
> Change: ld -assert pure-text `${OBJSORT} lorder-sparc tmp`
> To: ld -assert pure-text `${OBJSORT} lorder-sparc tmp` -ldl
>
> 2. There is now another file from libc.a which has a forshortened name:
> /usr/lib/shlib.etc/tmp% mv xccs.multibyte. xccs.multibyte.o
>
> Hope this helps,
>
> Clint Kaul Work: 505-845-7557 or 505-250-5105 (mb)
> Sandia National Labs Fax: 505-845-7442
> Department 1421 Home: 505-843-7159 or 505-843-6015
> Albuquerque, NM 87185-5800 Email: ckaul@cs.sandia.gov
>
From Firewalls-Owner Sun Apr 18 16:12:41 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA28459; Sun, 18 Apr 93 16:12:41 GMT
Received: from grasp1.univ-lyon1.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA28452; Sun, 18 Apr 93 09:12:29 PDT
Received: by grasp1.univ-lyon1.fr (5.67a8/IDA-1.5f)
via Rocad id AA02530; Sun, 18 Apr 1993 18:13:03 +0200
From: Christophe Wolfhugel <Christophe.Wolfhugel@grasp.insa-lyon.fr>
Message-Id: <199304181613.AA02530@grasp1.univ-lyon1.fr>
Subject: Re: DNS over TCP
To: avalon@coombs.anu.edu.au
Date: Sun, 18 Apr 1993 18:13:01 +0100 (MEST)
Cc: firewalls@GreatCircle.COM
In-Reply-To: <9304181538.AA14393@coombs.anu.edu.au> from "Darren Reed" at Apr 19, 93 01:38:03 am
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 599
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Darren Reed said:
|so why not ? Are DNS transactions light weight enough to make requiring
|TCP an overkill ? What if the TCP connection were kept open during the
|life of the namesrver rather than on a per-request basis ?
TCP connections are a pain for the DNS. IBM's stupid netstat uses one
such... I just can't imagine all the datagrams and time wasted in TCP
handshaking particularly true on slow lines !
Keeping TCP sockets open ? I can't imagine to have 200 open just for
the pleasure.
Keep it on UDP !
--
Christophe Wolfhugel | Email: Christophe.Wolfhugel@grasp.insa-lyon.fr
From Firewalls-Owner Sun Apr 18 16:53:08 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA28529; Sun, 18 Apr 93 16:53:08 GMT
Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA28522; Sun, 18 Apr 93 09:52:54 PDT
Received: by coombs.anu.edu.au (5.61/1.0)
id AA16561; Mon, 19 Apr 93 02:53:54 +1000
From: avalon@coombs.anu.edu.au (Darren Reed)
Message-Id: <9304181653.AA16561@coombs.anu.edu.au>
Subject: Re: DNS over TCP
To: louie@NI.umd.edu (Louis A. Mamakos)
Date: Mon, 19 Apr 93 2:53:53 EST
Cc: firewalls@GreatCircle.COM
In-Reply-To: <9304181639.AA05598@sayshell.umd.edu>; from "Louis A. Mamakos" at Apr 18, 93 12:39 pm
Reply-To: avalon@coombs.anu.edu.au
X-Mailer: ELM [version 2.3 PL11]
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
In some email I received from Louis A. Mamakos, Sie wrote:
[...]
> > so why not ? Are DNS transactions light weight enough to make requiring
> > TCP an overkill ? What if the TCP connection were kept open during the
> > life of the namesrver rather than on a per-request basis ?
> >
>
> It would greatly increase the amount of traffic and time to perform a
> simple query, as well as increase the resource useage on both the
> "client" machine and the name server. It is impractical to just keep
> a connection open to "the" name server.
>
> Some root name servers, for instance, will refuse to accept TCP
> connections for queries because of the additional overhead. For
> example, the root name server which we run at the University of
> Maryland processes on the order of 5 queries per second, averaged over
> a day.
Okay, what I was getting at here was people often have a normal host in
the 'DMZ' which has less restrictions than the rest of the protected
network and often is used to relay news/email (and maybe do proxy ftp,
telnet, etc) which could be setup to use a TCP connection to the remote
nameserver that it looks up to while allowing UDP from internal machines.
To keep this open for the life of the nameserver as the forwardding point
isn't going to cost much more and could be setup by special arrangement
if the upstream server normally disallows TCP connections.
It is also possible that a TCP DNS tree would be more 'secure' than one
which works using UDP, but there are a lot of other factors that go into
security and doesn't quite fit here.
Darren
From Firewalls-Owner Mon Apr 19 15:24:14 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA01443; Mon, 19 Apr 93 15:24:14 GMT
Received: from norman.li.cubic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA01436; Mon, 19 Apr 93 08:23:48 PDT
Received: by norman.li.cubic.com (5.67/1.34a)
id AA06146; Mon, 19 Apr 93 11:23:43 -0400
Date: Mon, 19 Apr 93 11:23:43 -0400
From: mischler@Cubic.COM (Dave Mischler)
Message-Id: <9304191523.AA06146@norman.li.cubic.com>
To: avalon@coombs.anu.edu.au
Subject: Re: DNS over TCP
Cc: FireWalls@GreatCircle.COM
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Another point I haven't seen anybody bring up is that the way you run
a nameserver so it will handle individual requests but not allow zone
transfers is by filtering TCP packets to port 53 (only recognized
secondaries should be allowed through). Note that CERT has come out
in favor of disallowing unfiltered zone transfers.
Dave Mischler
mischler@cubic.com
From Firewalls-Owner Mon Apr 19 17:09:42 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA01836; Mon, 19 Apr 93 17:09:42 GMT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA01826; Mon, 19 Apr 93 10:09:38 PDT
Message-Id: <9304191709.AA01826@mycroft.GreatCircle.COM>
To: firewalls@GreatCircle.COM (Firewall Mailing List)
Subject: Re: DNS over TCP
In-Reply-To: Your message of Sun, 18 Apr 1993 12:39:29 -0400
Date: Mon, 19 Apr 93 10:09:36 -0700
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
"Louis A. Mamakos" <louie@NI.umd.edu> writes:
# > People have said that they block all UDP packets bar those from and to
# > port 53 (the port assigned to DNS and used by nameservers).
#
# What about other UDP based services, like NTP (Network Time Protocol)?
# It seems that disabling a complete class of network transport is a bit
# of overkill.
Unfortunately, that's about the only option you have to keep folks
from exploiting security holes in RPC-based services such as NFS and
Yellow Pages (aka NIS). By the nature of RPC, you don't know for
certain what UDP port an RPC-based server is going to end up using
(though NFS usually uses 2049; NFS is a special case, though, that's
more predictable than the others). You end up having to block almost
all UDP in order to keep people from getting at your RPC-based
services. Fortunately, most of the troublesome services aren't
offered under TCP, or you'd have the same problem there.
NTP may be able to take advantage of the same loophole as DNS, if the
well-known NTP port number is used as both source and destination port
on NTP server-to-server traffic. client-to-server UDP traffic
(whether it's DNS or NTP or whatever) through the packet filter is
still a problem, though.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Wed Apr 21 17:00:53 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA02203; Wed, 21 Apr 93 17:00:53 GMT
Received: from cs.columbia.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA02196; Wed, 21 Apr 93 10:00:40 PDT
Received: from tiemann.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad+jtt) with SMTP
id AA05372; Wed, 21 Apr 1993 13:01:21 -0400
Received: by tiemann.cs.columbia.edu id AA09431
(5.65c/IDA-1.4.4.5/jba/jtt/ad for firewalls@greatcircle.com); Wed, 21 Apr 1993 13:01:18 -0400
Date: Wed, 21 Apr 93 13:01:18 EDT
From: Alexander Dupuy <dupuy@hudson.cs.columbia.edu>
To: avalon@coombs.anu.edu.au
Cc: firewalls@GreatCircle.COM (Firewall Mailing List)
Reply-To: dupuy@hudson.cs.columbia.edu
Subject: Re: DNS over TCP
In-Reply-To: Your message of Tue, 20 Apr 93 7:52:15 EST
Message-Id: <CMM.0.90.2.735411678.dupuy@tiemann.cs.columbia.edu>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> If zone transfers are a problem, why not use the BIND 4.8.3 source and
> just hack them out all together ?
Actually, bind 4.9, which just went into beta, has support for screening zone
transfers hacked in already. This allows the administrator to specify those
networks or hosts from which zone transfers will be allowed. Note that the
filtering is done at the DNS level, and does not arbitrarily block all DNS/TCP
connections, but only XFR requests. This is especially helpful if you use the
IBM AIX version of netstat, which uses a TCP connection to the DNS nameserver
(apparently because it expects to make a lot of DNS queries).
The current beta is available via anonymous ftp from gatekeeper.dec.com.
Kudos to Paul Vixie at DECWRL for coordinating the bind 4.9 effort, and for
hacking the zone-transfer restriction so that it doesn't just block TCP
requests entirely.
@alex
From Firewalls-Owner Wed May 19 22:45:09 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA02029; Wed, 19 May 93 22:45:09 GMT
Received: from gatekeeper.es.dupont.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA02020; Wed, 19 May 93 15:44:58 PDT
Received: by gatekeeper.es.dupont.com (5.65/ULTRIX-mjr-062991);
id AA10382; Wed, 19 May 93 18:46:13 -0400
Received: from fallst.es.dupont.com by eplrx7.es.duPont.com (4.1/kdm-082991-main)
id AA21216; Wed, 19 May 93 18:44:02 EDT
Received: by fallst.es.dupont.com (Smail3.1.28.1 #1)
id m0nvwfM-000GMIC; Wed, 19 May 93 18:31 EDT
Message-Id: <m0nvwfM-000GMIC@fallst.es.dupont.com>
From: tkevans@fallst.es.dupont.com (Tim Evans)
Subject: SUMMARY: DNS in Firewalled Environment
To: firewalls@GreatCircle.COM
Date: Wed, 19 May 1993 18:31:15 -0400 (EDT)
Phone: (410) 877-7890; (302) 695-9353
Reply-To: tkevans@eplrx7.es.duPont.com
X-Mailer: ELM [version 2.4 PL22beta3]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2189
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Last week, I wrote:
>I'd like to hear peoples' views on appropriate ways to set up
>DNS in firewalled environments, particularly with respect to
>preventing information about hosts inside the firewall from
>being broadcast to the world at large via DNS, while at the
>same time providing info about the world outside to all the
>internal hosts.
>
Paul Sangster (sangster@reston.ans.ne) wrote me about a commercial
hardware/software combination called The InterLock. He wrote:
>The InterLock is a commercial security service (leasable includes hardware/
>software/7x24 support). It provides a security-enhanced AIX kernel and
>versions of FTP, TELNET, SMTP, X, NNTP and other security tools. The
>InterLock falls into the category of ipforwarding turned off (which is
>being discussed on the list currently), although its not a screening
>router firewall. Instead it provides real application layer security with
>user authentication, user-level restrictions, user-level auditing and
>other functions at a higher level (like control over get vs put in ftp).
>
>If you are interested in more information let me know we have a white
>paper available.
I received one other reply, which I could not figure out whether it was
serious or smartass, so won't mention the sender's name. The suggestion
was to "not register my domain". Perhaps I missed something, but I thought
one had to register one's domain to be on the Internet and to use DNS.
How I could do what I wanted with an unregistered domain is beyond me.
If the sender wants to elaborate, I'd appreciate it, and I apologize
in advance if I've offended him/her with my ignorance, if that's what
turns out to be the case.
Meanwhile, I've been studying the new O'Reilly book _DNS and Bind_
and believe the solution to what I'm after is to use "internal
root DNS servers," which know only about the internals of my network
and about a "normal" DNS server on the firewall machine, which knows
only about itself and the outside world. This is discussed in
Chapter 14 of the book.
--
UUCP: {rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans
INTERNET: tkevans@fallst.es.dupont.com
Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047
From Firewalls-Owner Wed May 19 23:38:27 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA02172; Wed, 19 May 93 23:38:27 GMT
Received: from macsch.com (DRACO.MACSCH.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA02165; Wed, 19 May 93 16:38:07 PDT
Received: from [161.34.1.6] by macsch.com (5.61/SMI-4.1-07)
id AA25192; Wed, 19 May 93 16:39:17 -0700
Received: from canismajor.is.macsch.com by convex.is.macsch.com (5.64/2.0)
id AA02473; Wed, 19 May 93 16:37:08 -0700
Received: by canismajor.is.macsch.com (4.1/2.0)
id AA05070; Wed, 19 May 93 16:39:00 PDT
Date: Wed, 19 May 93 16:39:00 PDT
From: todd@macsch.com (Todd Williams)
Message-Id: <9305192339.AA05070@canismajor.is.macsch.com>
To: firewalls@GreatCircle.COM
Subject: Re: SUMMARY: DNS in Firewalled Environment
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
At 6:31pm on Wed May 19 1993, tkevans@fallst.es.dupont.com (Tim Evans) said:
> Last week, I wrote:
>
> >I'd like to hear peoples' views on appropriate ways to set up
> >DNS in firewalled environments, particularly with respect to
> >preventing information about hosts inside the firewall from
> >being broadcast to the world at large via DNS, while at the
> >same time providing info about the world outside to all the
> >internal hosts.
>
> I received one other reply, which I could not figure out whether it was
> serious or smartass, so won't mention the sender's name. The suggestion
> was to "not register my domain". Perhaps I missed something, but I thought
> one had to register one's domain to be on the Internet and to use DNS.
> How I could do what I wanted with an unregistered domain is beyond me.
Right. If you're on the internet, your DNS must be using a registered name.
> Meanwhile, I've been studying the new O'Reilly book _DNS and Bind_
> and believe the solution to what I'm after is to use "internal
> root DNS servers," which know only about the internals of my network
> and about a "normal" DNS server on the firewall machine, which knows
> only about itself and the outside world.
Well, I'm surprisingly disappointed that you didn't get an adequate response.
Maybe nobody understood the question. I haven't tackled this problem at my
site yet, so let me give you my blind-leading-the-blind reply:
Smoot Carl-Mitchell of Texas Internet Consulting has developed something that
will do exactly what you want, I think. I think they are hacks to DNS which
allow you to run DNS out to the Internet from one side of your firewall,
while running a slightly different DNS internal to your firewall. This is a
common problem for people who want to hide internal host names, etc.
His address is smoot@tic.com, or you can just get the package via FTP from
tic.com, I think.
Here's some of the previous discussion about this topic:
At 11:56am on Tue Dec 22 1992, Donald R. Proctor (510/596-3828) <sybase!donp@Sun.COM> said:
>
> Previously, avalon@coombs.anu.edu.au (Darren Reed) said:
> > It has often been said that when setting up a firewall to allow DNS
> > packets with both source and dest. of port 53 through. There seems
> > to be an obvious flaw with this - what is to stop crackers using
> > this 'hole' ? I don't recall if this was allowed just as far as the
> > 'DMZ' or all the way through...
>
> The best approach is probably to set up an "internal" DNS domain and
> an "external" DNS domain. The internal domain servers would talk to
> internal root servers, and the external domain servers would talk to
> the "real" root servers.
>
> That way you don't need to open up port 53 from the DMZ to the internal
> network(s).
>
> Also, you may not have a need to advertise the name of every host on
> your network to the outside world. In this case, the "external" DNS
> server can operate with a very minimal DNS database configuration.
Todd Williams UNIX Systems Supervisor todd@macsch.com (213) 259-4973
MacNeal-Schwendler Corp. ("MSC"), 815 Colorado Blvd., Los Angeles, CA 90041
"Solaris 2.0 -- It's enough to make you leave the company." -Rob Kolstad
From Firewalls-Owner Thu May 20 15:18:12 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA04895; Thu, 20 May 93 15:18:12 GMT
Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA04877; Thu, 20 May 93 08:17:46 PDT
Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1)
id AA02877; Thu, 20 May 93 11:18:34 EDT
Received: from lehman.com by shearson.com (4.1/LB-0.6)
id AA03209; Thu, 20 May 93 11:18:31 EDT
Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1)
id AA02874; Thu, 20 May 93 11:18:29 EDT
Received: from snark.shearson.com by shearson.com (4.1/LB-0.6)
id AA03206; Thu, 20 May 93 11:18:28 EDT
Received: by snark.shearson.com (4.1/SMI-4.1)
id AA11170; Thu, 20 May 93 11:18:27 EDT
Message-Id: <9305201518.AA11170@snark.shearson.com>
To: tkevans@eplrx7.es.dupont.com
Cc: firewalls@GreatCircle.COM
Subject: Re: SUMMARY: DNS in Firewalled Environment
In-Reply-To: Your message of "Wed, 19 May 1993 18:31:15 EDT."
<m0nvwfM-000GMIC@fallst.es.dupont.com>
Reply-To: pmetzger@lehman.com
X-Reposting-Policy: redistribute only with permission
Date: Thu, 20 May 1993 11:18:26 -0400
From: "Perry E. Metzger" <pmetzger@lehman.com>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Tim Evans says:
> Last week, I wrote:
>
> >I'd like to hear peoples' views on appropriate ways to set up
> >DNS in firewalled environments, particularly with respect to
> >preventing information about hosts inside the firewall from
> >being broadcast to the world at large via DNS, while at the
> >same time providing info about the world outside to all the
> >internal hosts.
I'm sorry no one really answered you. I suspect everyone assumed
someone else would.
Here at Lehman, we have an internal and external DNS server.
Externally, we just show a wildcard MX for our domain and the records
for the firewall machine. Internally, we "do the right thing". Setting
this up was quite trivial.
> Paul Sangster (sangster@reston.ans.ne) wrote me about a commercial
> hardware/software combination called The InterLock. He wrote:
>
> >The InterLock is a commercial security service (leasable includes hardware/
ANS basically leases you an RS/6000 with their firewall software. You
can do everything they do for you for free with your own hardware
using software available fro free from the net. Personally, I wouldn't
touch their product with a long pole. They are very agressive about
pushing the stuff to whomever sends out inquiries anywhere on the net,
but I've never seen the utility of leasing an RS/6000 from them with
their proprietary software other than the fact that being an IBM
affiliate this helps them improve IBM's lackluster workstation sales.
> Meanwhile, I've been studying the new O'Reilly book _DNS and Bind_
> and believe the solution to what I'm after is to use "internal
> root DNS servers," which know only about the internals of my network
> and about a "normal" DNS server on the firewall machine, which knows
> only about itself and the outside world. This is discussed in
> Chapter 14 of the book.
A pretty good idea.
Perry Metzger
From Firewalls-Owner Thu May 20 17:17:20 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA05602; Thu, 20 May 93 17:17:20 GMT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA05593; Thu, 20 May 93 10:17:14 PDT
Message-Id: <9305201717.AA05593@mycroft.GreatCircle.COM>
To: Firewalls@GreatCircle.COM
Subject: Re: DNS in Firewalled Environment
Date: Thu, 20 May 93 10:17:13 -0700
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Just noticed that somewhere along the line during this debate,
"Firewalls-Owner" got substituted for "Firewalls", and most of you haven't
been seeing this exchange. I'll ferret out the other messages that got
sent to the wrong address, and forward them.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
------- Forwarded Message
Return-Path: brent@GreatCircle.COM
Return-Path: <brent@GreatCircle.COM>
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA05506; Thu, 20 May 93 10:09:41 PDT
Message-Id: <9305201709.AA05506@mycroft.GreatCircle.COM>
To: rmdupont@irsc.gmeds.com (R. Michael Dupont)
Cc: tkevans@eplrx7.es.duPont.com, Firewalls-Owner@GreatCircle.COM
Subject: Re: DNS in Firewalled Environment
In-Reply-To: Your message of Thu, 20 May 93 10:11:13 EST
Date: Thu, 20 May 93 10:09:40 -0700
From: Brent Chapman <brent@GreatCircle.COM>
Regarding the suggestion of using a bogus domain name as a way of
ensuring that outsiders can't get at your DNS data...
Don't.
Everybody who does that (or similar things, like inventing IP
addresses out of the blue, rather than registering them) because
"WE'll never connect to the Internet" has come to regret it, and it's
a major project to fix it a couple of years down the road.
You might as well do things "right", right from the start. It will
save you untold time and trouble later.
There are other ways to hide your internal DNS data from prying eyes, one
of which I've described before and will again shortly in a separate message.
- -Brent
- --
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
------- End of Forwarded Message
From Firewalls-Owner Thu May 20 17:19:32 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA05634; Thu, 20 May 93 17:19:32 GMT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA05624; Thu, 20 May 93 10:19:24 PDT
Message-Id: <9305201719.AA05624@mycroft.GreatCircle.COM>
To: Firewalls@GreatCircle.COM
Subject: Re: DNS in Firewalled Environment
Date: Thu, 20 May 93 10:19:23 -0700
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Here's the only other misdirected message that I could find.
-Brent
------- Forwarded Message
Return-Path: rmdupont@irsc.gmeds.com
Return-Path: <rmdupont@irsc.gmeds.com>
Received: from irsc.gmeds.com ([192.57.20.10]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)id AA04840; Thu, 20 May 93 08:10:06 PDT
Received: by irsc.gmeds.com (4.1/EDS-1.0)
id AA06861; Thu, 20 May 93 10:11:13 EST
Date: Thu, 20 May 93 10:11:13 EST
From: rmdupont@irsc.gmeds.com (R. Michael Dupont)
Message-Id: <9305201511.AA06861@irsc.gmeds.com>
To: tkevans@eplrx7.es.duPont.com, Firewalls-Owner@GreatCircle.COM
Subject: Re: DNS in Firewalled Environment
Cc: rmdupont@irsc.gmeds.com
>From the SERIOUS SMARTASS . . .
> From tkevans@fallst.es.dupont.com Wed May 19 17:46:31 1993
> From: tkevans@fallst.es.dupont.com (Tim Evans)
> Subject: Re: DNS in Firewalled Environment
> To: rmdupont@irsc.gmeds.com (R. Michael Dupont)
> Date: Wed, 19 May 1993 18:35:40 -0400 (EDT)
> In-Reply-To: <9305142141.AA17179@irsc.gmeds.com> from "R. Michael Dupont" at May 14, 93 04:41:17 p> Phone: (410) 877-7890; (302) 695-9353
> Reply-To: tkevans@eplrx7.es.duPont.com
>
> Quoth R. Michael Dupont:
> >
> >> I'd like to hear peoples' views on appropriate ways to set up
> >> DNS in firewalled environments, particularly with respect to
> >> preventing information about hosts inside the firewall from
> >> being broadcast to the world at large via DNS, while at the
> >> same time providing info about the world outside to all the
> >> internal hosts.
> >>
> >> Thanks.
> >>
> >How about not registering your domain?
> >
> I'm not sure I understand what you mean. If you're being sarcastic,
> I guess I'm too dumb to appreciate the sarcasm. If you have a substantive
> response, please send it.
>
> --
> UUCP: {rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans
> INTERNET: tkevans@fallst.es.dupont.com
> Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047
>
I am serious, but I guess my response needs a little more substance to it.
By not registering a domain, the ROOT servers cannot resolve any unregistered
HOST.DOMAIN.OF.MY.CHOICE because they do not know where the SOA resides. You
(as the Source-Of-Authority) do, and can provide proper resolution for hosts
within your domain. You can also resolve any registered domains because you
are able to access the ROOT server, then the SOA servers containing the info
desired.
Yes, this could be creating conflicts if Ed's Drywall Supplies wanted to use
an unregistered EDS.com domain. Mail from those users would (probably) never
get to users at Electronic Data Systems, and vice-versa.
If you were to use an unregistered domain, I would suggest not ending it with
an acronym of less than three letters, so that there is no conflict with true
registered domains (i.e. those in COM, EDU, GOV, MIL, ORG, NET, US, AZ, etc.)
You might set up (using yourself as an example) a domain such as DUPONT, with
a sub-domain of ES, and a host named FALLST, so that your internal email would
be sent to tkevans@fallst.es.dupont. I might set up my own domain, and have
my internal mail addressed to mike@smartass.dupont. Want to know about my host
addresses? You have to find my SOA nameserver, and I'm not telling!
You MUST apply for an address range that is registered prior to interconnecting
to the Internet, so that there are no duplications. The address is not equal
to a domain name, but is a separate issue for "NAME <--> ADDRESS" resolutions.
No registered domain name ===> no address resolution for users in the Internet.
Heresy!?! I am not suggesting this to create anarchy within the network,
but as a "ONE-WAY MIRROR" method of Internet connectivity.
The fact that there is no resolution could cause you problems with
Anybody know of hitches to this type of a setup?
Tim: No blood, no foul, no offense taken.
- -- Mike
+----------------------------------RMD19------------------------------------+
| R. Michael Dupont, Indiana Regional Support Cntr, Electronic Data Systems |
| Data Networks Manager, Monday - Friday, 0800 - 1700 EST (1300 - 2200 GMT) |
| Voice: (317)240-5823, GM: 8*360-5823, Pager: 928-1361, FAX: (317)240-5622 |
| Paper: 2601 Fortune Circle East, Suite 100C, Indianapolis, IN 46241-5513 |
| Internet: rmdupont@irsc.gmeds.com, DECUServe: dupont@Eisner.DECUS.Org |
+---------------------------------------------------------------------------+
------- End of Forwarded Message
From Firewalls-Owner Thu May 20 17:36:52 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA05718; Thu, 20 May 93 17:36:52 GMT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA05704; Thu, 20 May 93 10:36:45 PDT
Message-Id: <9305201736.AA05704@mycroft.GreatCircle.COM>
To: Firewalls@GreatCircle.COM
Subject: Re: DNS in Firewalled Environment
Date: Thu, 20 May 93 10:36:44 -0700
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Here's a brief overview of how I set up DNS for my Internet-connected
clients that don't want to advertise all their internal hosts.
Basicly, the key realization is that the DNS clients on a machine don't
have to talk to the DNS server on that same machine. In other words,
just because there's a DNS server on a machine, there's nothing wrong
with (and often advantages to) redirecting that machine's DNS client
activity to a DNS server on another machine.
Here's how I use that little factoid to my advantage...
First, you set up a DNS server that the outside world can talk to.
You set this server up so that it claims to be authoritative for your
domains. In fact, all this server knows is what you want the outside
world to know; the names and addresses of your gateways, your wildcard
MX records, and so forth. This is the "public" server.
Then, you set up a DNS server on an internal machine. This server also
claims to be authoritiative for your domains; unlike the public server,
this one is telling the truth. This is your "normal" nameserver, into
which you put all your "normal" DNS stuff. You also set this server
up to forward queries that it can't resolve to the public server (using
a "forwarders" line in /etc/named.boot on a UNIX machine, for example).
Finally, you set up all your DNS clients (the /etc/resolv.conf file on
a UNIX box, for instance), including the ones on the machine with the
public server, to use the INTERNAL server. This is the key.
This is how it works... An internal client asking about an internal host
asks the internal server, and gets an answer; an internal client asking
about an external host asks the internal server, which asks the public
server, which asks the Internet, and the answer is relayed back. A client
on the public server works just the same way. An external client, however,
asking about an internal host gets back the "restricted" answer from the
public server.
I'm assuming that there's a packet filtering firewall between these two
servers that will allow them to talk DNS to each other, but that's it,
but restricts DNS between other hosts. If you don't have a packet
filtering firewall, then this whole scheme is kind of pointless;
somebody can contact your internal name server (all they have to do is
find it) and get all the "real" data.
There's another trick that's useful in this scheme: wildcard PTR
records (bet you didn't know you could do that! :-) in your
IN-ADDR.ARPA domains. These cause an an address-to-name lookup for
any of your non-public hosts to return something like "unknown.YOUR.DOMAIN"
(i.e., "unknown.GreatCircle.COM") rather than an error. This satisfies
anonymous FTP sites like ftp.uu.net that insist on having a name for the
machines they talk to.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Thu May 20 17:50:34 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA05777; Thu, 20 May 93 17:50:34 GMT
Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA05766; Thu, 20 May 93 10:50:03 PDT
Message-Id: <9305201750.AA05766@mycroft.GreatCircle.COM>
From: smb@research.att.com
Received: by gryphon; Thu May 20 13:49:47 EDT 1993
To: Brent Chapman <brent@GreatCircle.COM>
Cc: Firewalls@GreatCircle.COM
Subject: Re: DNS in Firewalled Environment
Date: Thu, 20 May 93 13:49:46 EDT
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
There's another trick that's useful in this scheme: wildcard
PTR records (bet you didn't know you could do that! :-) in
your IN-ADDR.ARPA domains. These cause an an address-to-name
lookup for any of your non-public hosts to return something
like "unknown.YOUR.DOMAIN" (i.e., "unknown.GreatCircle.COM")
rather than an error. This satisfies anonymous FTP sites like
ftp.uu.net that insist on having a name for the machines they
talk to.
No, it won't necessarily satisfy such sites. Many machines validate
the results of gethostbyaddr() by doing a gethostbyname() call; if
the latter doesn't return the actual IP address, the value returned
by the gethostbyaddr() call isn't believed. For your idea to work,
unknown.YOUR.DOMAIN would have to have an A record for every machine
you own that could possibly talk to the outside world. Apart from
the fact that you might not want to give out that information, you'll
break lots of machines that can't handle that many A records coming
back at them.
From Firewalls-Owner Thu May 20 17:52:41 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA05800; Thu, 20 May 93 17:52:41 GMT
Received: from rara.ossi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA05793; Thu, 20 May 93 10:52:13 PDT
Received: from nym.ossi.com (nym.ossi.com [192.240.2.13]) by rara.ossi.com (ALPHA-6.54/6.27) id KAA154; Thu, 20 May 1993 10:53:16 -0700
Received: from localhost (aegl@localhost) by nym.ossi.com (ALPHA-6.54/6.27) id KAA23870; Thu, 20 May993 10:53:15 -0700
Date: Thu, 20 May 1993 10:53:15 -0700
From: Tony Luck <aegl@ossi.com>
Message-Id: <199305201753.KAA23870@nym.ossi.com>
To: Firewalls@GreatCircle.COM
Subject: Re: DNS in Firewalled Environment
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
R. Michael Dupont writes:
> By not registering a domain, the ROOT servers cannot resolve any unregistered
> HOST.DOMAIN.OF.MY.CHOICE because they do not know where the SOA resides. You
> (as the Source-Of-Authority) do, and can provide proper resolution for hosts
> within your domain.
...
> Anybody know of hitches to this type of a setup?
At least one problem ... several of the anonymous ftp servers are already
set up to reject connections if they can't do a reverse lookup on the
address that your connection comes from (and some then convert the name
back to an address again to make sure that they match). This kind of
autentication of connections is becoming more common as the number of bad
guys on the net goes up, resulting in a decrease in the overall level of
trust.
If you don't have a registered domain, then you can't access the services
that do this kind of checking.
-Tony Luck
From Firewalls-Owner Thu May 20 18:41:31 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA06062; Thu, 20 May 93 18:41:31 GMT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA06053; Thu, 20 May 93 11:40:11 PDT
Message-Id: <9305201840.AA06053@mycroft.GreatCircle.COM>
To: smb@research.att.com
Cc: Firewalls@GreatCircle.COM
Subject: Re: DNS in Firewalled Environment
In-Reply-To: Your message of Thu, 20 May 93 13:49:46 EDT
Date: Thu, 20 May 93 11:40:09 -0700
From: Brent Chapman <brent@GreatCircle.COM>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
# There's another trick that's useful in this scheme: wildcard
# PTR records (bet you didn't know you could do that! :-) in
# your IN-ADDR.ARPA domains. These cause an an address-to-name
# lookup for any of your non-public hosts to return something
# like "unknown.YOUR.DOMAIN" (i.e., "unknown.GreatCircle.COM")
# rather than an error. This satisfies anonymous FTP sites like
# ftp.uu.net that insist on having a name for the machines they
# talk to.
#
# No, it won't necessarily satisfy such sites. Many machines validate
# the results of gethostbyaddr() by doing a gethostbyname() call; if
# the latter doesn't return the actual IP address, the value returned
# by the gethostbyaddr() call isn't believed. For your idea to work,
# unknown.YOUR.DOMAIN would have to have an A record for every machine
# you own that could possibly talk to the outside world. Apart from
# the fact that you might not want to give out that information, you'll
# break lots of machines that can't handle that many A records coming
# back at them.
I have yet to encounter one of these sites. Every anonymous FTP site
I've run into so far wanted (at most) a name; they didn't care if that
name mapped back to the address you were coming from.
So yes, in theory, this is a problem. In practice, it doesn't seem to
be a problem.
This is the "double reverse lookup" argument from early in the history
of the Firewalls mailing list. I really didn't mean to start it up
again; anybody who's interested should go back through the archives to
find the old discussions on the subject.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Thu May 20 21:05:21 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA06910; Thu, 20 May 93 21:05:21 GMT
Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA06901; Thu, 20 May 93 14:05:06 PDT
Message-Id: <9305202105.AA06901@mycroft.GreatCircle.COM>
From: smb@research.att.com
Received: by gryphon; Thu May 20 17:04:23 EDT 1993
To: Brent Chapman <brent@GreatCircle.COM>
Cc: Firewalls@GreatCircle.COM
Subject: Re: DNS in Firewalled Environment
Date: Thu, 20 May 93 17:04:22 EDT
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
I have yet to encounter one of these sites. Every anonymous FTP site
I've run into so far wanted (at most) a name; they didn't care if that
name mapped back to the address you were coming from.
So yes, in theory, this is a problem. In practice, it doesn't seem to
be a problem.
I confess that I'm surprised. SunOS's gethostbyaddr() call will return
NULL if the cross-check fails. Perhaps folks sophisticated enough to
have replaced their ftp daemons have also replaced their resolver libraries
without being aware of the division of labor?
From Firewalls-Owner Fri May 21 15:25:17 1993
Return-Path: Firewalls-Owner
Return-Path: <Firewalls-Owner>
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA09922; Fri, 21 May 93 15:25:17 GMT
Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA09913; Fri, 21 May 93 08:25:09 PDT
Received: from cobalt.house.gov by mercury.house.gov with SMTP
(1.37.109.4/16.2) id AA04952; Fri, 21 May 93 11:25:10 -0400
Received: by cobalt.house.gov (AA03617); Fri, 21 May 93 11:26:59 -0700
Date: Fri, 21 May 93 11:26:59 -0700
From: Dorian Deane <dorian@cobalt.house.gov>
Message-Id: <9305211826.AA03617@cobalt.house.gov>
To: brent@GreatCircle.COM, Firewalls@GreatCircle.COM
Subject: Re: DNS in Firewalled Environment
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
rmdupont@irsc.gmeds.com writes:
> By not registering a domain, the ROOT servers cannot resolve any unregistered
> HOST.DOMAIN.OF.MY.CHOICE because they do not know where the SOA resides. You
> (as the Source-Of-Authority) do, and can provide proper resolution for hosts
> within your domain. You can also resolve any registered domains because you
> are able to access the ROOT server, then the SOA servers containing the info
> desired.
...
> You have to find my SOA nameserver, and I'm not telling!
...
> Anybody know of hitches to this type of a setup?
The minor hitches have already been addressed by others. I just want to
point out that there is only minor value in security by obscurity. Just
because there is no _name_ associated with your network doesn't mean you're
not reachable. In fact, adding that kind of secrecy might make the "target"
just that much more attractive.
Dorian Deane House Information Systems
ddeane@cobalt.house.gov
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
