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
Follow-Ups:
|
|
