|
|
| Previous | Table of Contents | Next |
The use of local name servers on workstations also may reduce total network traffic and aids in fault tolerance. If a network-wide name server goes down, it will not create any delays for information stored in the local name servers.
Warning: You are still at risk of a DNS spoof if local name servers on workstations are configured to process queries recursively when they consult the network-wide name server. You are also at risk if the local name server refers its local clients to query the network-wide name server for names for which the network-wide name server is also non-authoritative. In either case, a corrupted network-wide name server cache will affect the workstations.The use of local name servers will limit, not eliminate, risks. Local name servers are also subject to cache corruption. The reduced risk comes from fewer interactions with any single cache. You should be sure local name servers only process queries from the local machine to prevent an active attacker from directly contaminating their cache. Hiding the workstations behind a firewall will also help.
You might also modify local name server software to be more selective about the information it caches. Again, doing so will be of limited value if the erroneous data is coming from the cache of an unmodified name server being consulted by the local name server. Selective caching by doing such things as ignoring information in the additional information section of DNS replies will certainly have an adverse impact on efficiency. Response times will also be lengthened by any cross-checking or authority checking done by the modified name server, but cached authority checks may ease the problem somewhat.
RFC 1788 proposes an alternative to DNS reverse lookups: all machines would respond to a new ICMP message requesting the set of names that correspond to the IP address on which the ICMP message was received. These responses can then be cross-checked through forward DNS lookups. Although this proposal aims to increase the security of DNS, it is not clear how it would have helped in the case study involving Frank and Mary described earlier. Name-based authentication is fundamentally insecure because it is really just identification without any proof of authentication.
The simplest thing a name server administrator can do to prevent a DNS spoof from corrupting the name server cache is to have the most recent version of the operating system’s DNS name server software. The most common implementation of a DNS name server is BIND ( Berkeley Internet Name Daemon) on Unix. Newer versions of BIND incorporate modifications made with a more security conscious attitude than older versions. For the most current version, consult the web at http://www.isc.org/isc/bind.html or ftp://ftp.isc.org/isc/bind/src.
Tip: For a more detailed treatment of the security weaknesses of the DNS system, see the paper “Countering Abuses of Name-based Authentication” by Christoph Schuba and Eugene Spafford of the COAST security lab at Purdue University. The COAST department supplies useful security-related information and many useful tools. COAST has a site on the World W i d e Web at http://www.cs.purdue.edu/coast/coast.html.
TCP builds a connection-oriented, reliable byte stream on top of IP that can send connectionless, unreliable datagrams. It is possible for an attacker’s machine to spoof by sending IP datagrams that have an IP source address belonging to another machine. Such spoofing provides a mechanism for an attack on the security of any machine using IP to receive commands.
The attacker’s machine can send IP datagrams with a forged source address to other machines while the machine legitimately possessing that IP address is active. It can do so with no intention of getting replies to those datagrams. The other machines will accept these datagrams as coming from the legitimate holder of the IP source address of these forged datagrams. They will carry out actions not actually requested by the user of the legitimate machine.
Typically, IP-based application protocols have some notion of a session with some information exchanged at startup, which is used to identify the two parties to each another during the active part of the session. One effect of the information exchange is that a third party cannot pose as one of the initial two parties. If a sniffer is being used by the attacker, it becomes easy for the attacker to pose as either party. For example, in the NFS protocol, a client will first exchange information with the server’s mount daemon. After this exchange, the client will be able to open and read or write files on the server by making requests of the NFS daemon. An attacker can wait for the client to mount a file system and open a file. If the attacker sends out an appropriately formatted UDP datagram, the server will process an NFS request and send the results back to the client. Regardless of the client’s reaction to the unexpected reply, if the request was a write request, the attacker will have succeeded in writing some information to the server’s disk. If the request was a read request and the attacker has a sniffer between the client and server, the attacker will succeed in finding out some of the contents of the disk via the sniffer.
Through the use of datagrams with forged IP addresses, an attacker can get datagrams holding requests accepted as valid but cannot get replies to those requests without a sniffer. In the NFS scenario described earlier, you were using UDP and assumed the attacker had a sniffer to obtain the credentials that allowed acceptance of the request as valid. You might assume that if you use a connection-oriented protocol, such as TCP, you might be more secure. If you can rule out an attacker having a sniffer between the client and the server, the attacker would be unable to obtain the needed credentials. Unfortunately, these assumptions are valid.
Introduction to TCP/IP End-to-End Handshaking
To understand how an attacker might be able to send datagrams accepted as valid, you need to understand the information exchanged between the parties of a TCP connection. A TCP connection proceeds through three stages:
| Previous | Table of Contents | Next |