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
|
|
