|
Reverse lookup is the process by which a server
receiving a request for service from a remote machine ascertains
whether the identity claimed by the machine is in fact its true
one. The process goes like this:
- The request arrives in a packet with an IP address indicating
the point of origin.
- The server queries name service on the net to find out what
host name is associated with that IP address.
- The server then queries name service to find out what IP
address is associated with that host-name.
- If this last request fails to find an IP address, or finds one
that doesn't match the original, the request for service is
rejected.
Domain Name Service (DNS) is the bedrock of the Internet.
Whenever you make a request for Internet service (whether
Secure Shell network (SSH) or Secure FTP (SFTP) to a machine with a name, or surfing to a Web
URL, or whatever), the SSH, SFTP, or browser program you are
using has to determine the IP-address (Internet
numerical address) of the server machine that offers the service
you are requesting.
So DNS converts between "text" names (such as
"inform.umd.edu") and numeric IP addresses (such
as "128.8.10.29").
In order for an Internet Service Provider (ISP) to offer this
name service for machines under its "care," it has to put these two
pieces of information, known as BIND (Berkeley
Internet Name Daemon) data records, into tables on its Internet
domain name servers. These two data records are:
| Type |
Function |
Explanation |
| "PTR" (pointer) record |
IP-addr ---> name |
returns an internet name
when given a numeric IP address |
| "A" (address) record |
name ---> IP address |
returns a numeric IP address
when given an internet name
(i.e., a host name, "mx" mail-exchange record, etc.) |
Obviously, if the ISP fails to place both of these two
records in its DNS tables for any machine for which it is
responsible, reverse lookups done on that machine will fail. The
PTR record seems to be the usual one missing, but it can happen
with either.
A machine for which reverse lookup fails will not be able
to get service (telnet connections, ftp service, Web page
retrieval) from any server that does reverse lookup on machines
requesting service.
However, this behavior can also be caused by a server
being down. Reverse-lookup failure is more likely to be
involved
- if the problem occurs consistently over a period of time,
OR
- if the problem has existed since you first tried to get service
using the machine in question.
If you have reason to suspect a reverse-lookup problem, get
- the date/time of the apparent rejection
- the (supposed) name and IP address of the
machine requesting service, and
- the name of the server rejecting the request
Contact the Office of Information Technology (OIT)
Help Desk
and give this information to the staff, who will get in touch with
the relevant system administrator to see if there is any evidence
of this problem in the server logs.
If reverse lookup failure turns out to be the problem, you will
have to contact your ISP and tell them explicitly what the problem
is.
WAM and Glue
WAM and Glue, while not identical in this regard, are close. The
degree to which reverse lookup is used varies from service to
service.
- ftp -- yes
- telnet / rlogin -- to some degree
- sendmail -- yes
- pop / imap -- not yet
- http (web) -- for restricted resources
The need to limit access to services
If you run a server, there are various reasons you might want to
have control over who connects to it, such as
- verifying who you are talking to
- limiting service(s) to certain groups of people, who have some
aspect of their internet address in common (such as if you have a
relatively weak server)
- offering software that is licensed in such a way that only
certain groups of people may download it
- protecting your group from junk-mail (SPAMs) or other types of
attacks from known problem sources
- detecting other activity by people who are trying to hide what
they are doing
To limit access in this way, you need to know where the request for
service is coming from. The "packets" of information which contain
the request also contain information about where it is coming from.
However, since there are (unfortunately) many ways to fake this
information, you need to have ways to double-check on its
authenticity. Reverse lookup is one of those ways. Let's
look at "IP-spoofing" as an example of a trick that is
easily foiled by reverse-lookup.
What is IP Spoofing?
How can you identify a University machine? Well, their names all
end in .umd.edu. Let's say someone from outside the
University wants her machines to have access to certain services
that are only available to people coming from a University machine.
So she buys a group of IP (numeric) Internet addresses for her
machines and sets up a name server. She loads the name server
with
- pointer records which say that each IP
address in the impostor group has a name that ends with
.umd.edu, and
- address records which say that these
supposed UMD machines are all located in this group of IP
addresses.
Now the impostor machines using these addresses look like they are
part of UMD's domain. Will they succeed in gaining unauthorized
access to UM-only resources? No.
How Eoes Reverse Lookup Defeat IP Spoofing?
Name service on the Internet -- In order to understand
how this works, you need to know that there is a world-wide
hierarchy of name servers, where each step up in the hierarchy
tends to know about a wider range of machines. When a name-service
lookup request goes out, it is passed on up the hierarchy until a
name server is found sufficiently high in the hierarchy (often one
of the top-of-the-heap root name servers) to know which
local name server handles the machine in question. The request is
then directed to that local name server.
So what happens? -- When a request from one of the
impostor "UM" machines arrives at a UM server, the request is
accompanied by the IP address of the impostor. The UM server,
wanting to be sure the request is from a UM machine, sends out a
lookup inquiry to make sure that that IP address has a name
ending in .umd.edu.
The inquiry is passed on up the chain until it hits a name
server which knows that the IP address in question is handled by
the impostor's name server. The impostor server gets the inquiry
and hands back a name which, of course, DOES end in
.umd.edu. So, if no further checking is done, an unauthorized
person will get the service.
However, what happens if a second, reverse lookup is
done, to check whether the alleged UM name actually has the claimed
IP address?
When this name lookup is sent out, the high-level name servers
will know that names ending in .umd.edu are handled by
our own name server here at UMD -- not the impostor's. There is
no way for a name server to claim authorization for UM domain
service without explicit permission from authorized UM personnel.
So the impostor name server never gets a chance to send back the IP
addresses for the fake UM machines in its address
records.
Instead, the UM name server gets the request, and either reports
back that there is no such machine at UM by that name, or, if the
name happens to match one of UM's existing machines, returns that
machine's IP address -- which won't match the impostor's.
Either way, the reverse lookup fails and the impostor's request
for service is rejected.
|
