[ Pobierz całość w formacie PDF ]
.RFC 1788 proposes an alternative to DNS reverse lookups: all machines would respond to anew ICMP message requesting the set of names that correspond to the IP address on which theICMP message was received.These responses can then be cross-checked through forward DNSlookups.Although this proposal aims to increase the security of DNS, it is not clear how itwould have helped in the case study involving Frank and Mary described earlier.Name-basedauthentication is fundamentally insecure when the name is not coming directly from atrustworthy source.The simplest thing a name server administrator can do to prevent a DNS spoof from corrupt-ing the name server cache is to have the most recent version of the operating system s DNSname server software.The most common implementation of a DNS name server is BIND(Berkeley Internet Name Daemon) on Unix.Newer versions of BIND incorporate modifica-tions made with a more security conscious attitude than older versions.For the most currentversion, consult the Web at http://www.dns.net.dnsrd/servers.html. IP Spoofing and Sniffing 309Tip For a more detailed treatment of the security weaknesses of the DNS system, see thepaper Countering Abuses of Name-based Authentication by Christoph Schuba andEugene Spafford of the COAST security lab at Purdue University.The COASTdepartment supplies useful security-related information and many useful tools.COAST has a site on the World Wide Web at http://www.cs.purdue.edu/coast/coast.html.Spoofing TCP ConnectionsTCP builds a connection-oriented, reliable byte stream on top of IP that can sendconnectionless, unreliable datagrams.It is possible for an attacker s machine to spoof bysending IP datagrams that have an IP source address belonging to another machine.Suchspoofing provides a mechanism for an attack on the security of any machine using IP to receivecommands.The attacker s machine can send IP datagrams with a forged source address to other machineswhile the machine legitimately possessing that IP address is active.It can do so with nointention of getting replies to those datagrams.The other machines will accept these datagramsas coming from the legitimate holder of the IP source address of these forged datagrams.Theywill 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 informationexchanged at startup, which is used to identify the two parties to each another during theactive part of the session.One effect of the information exchange is that a third party cannotpose as one of the initial two parties.If a sniffer is being used by the attacker, it becomes easyfor the attacker to pose as either party.For example, in the NFS protocol, a client will firstexchange information with the server s mount daemon.After this exchange, the client will beable to open and read or write files on the server by making requests of the NFS daemon.Anattacker can wait for the client to mount a file system and open a file.If the attacker sends outan appropriately formatted UDP datagram, the server will process an NFS request and sendthe results back to the client.Regardless of the client s reaction to the unexpected reply, if therequest was a write request, the attacker will have succeeded in writing some information tothe server s disk.If the request was a read request and the attacker has a sniffer between theclient and server, the attacker will succeed in finding out some of the contents of the disk viathe sniffer.Through the use of datagrams with forged IP addresses, an attacker can get datagrams holdingrequests accepted as valid but cannot get replies to those requests without a sniffer.In the NFSscenario described earlier, you were using UDP and assumed the attacker had a sniffer toobtain the credentials that allowed acceptance of the request as valid.You might assume that ifyou use a connection-oriented protocol, such as TCP, you might be more secure.If you canrule out an attacker having a sniffer between the client and the server, the attacker would beunable to obtain the needed credentials.Unfortunately, these assumptions are valid. 310 Part II: Gaining Access and Securing the GatewayIntroduction to TCP/IP End-to-End HandshakingTo understand how an attacker might be able to send datagrams accepted as valid, you need tounderstand the information exchanged between the parties of a TCP connection.A TCPconnection proceeds through three stages:Connection setupData exchangeConnection tear-downTCP Connection SetupTCP connection setup requires a three-way handshake between the two parties.Initially, oneparty is passively waiting for the establishment of a connection.This passive party is said to be listening. The passive party is typically a server.The other party actively opens the TCPconnection by sending the first IP datagram.The active party is typically a client.The defini-tion of client and server is separate from active and passive parties during the setup phase.Thisdiscussion refers to the parties as client and server merely to be more suggestive of the typicalroles they will play later.The client starts things off by sending a TCP header with the SYN flag set.SYN stands for synchronize and refers to the synchronization of initial sequence numbers.The TCPprotocol assigns each data byte sent on a connection its own sequence number.Every TCPheader contains a sequence number field corresponding to the sequence number in the firstdata byte of the field.Initial sequence numbers should be random rather than merely arbitrary.Randomness of initial sequence number is important for handling the situation when aconnection is established, the machine on one side crashes, and then attempts to reestablish aconnection.The other machine needs to be able to detect wild out-of-range sequence andacknowledgment numbers to close its side of the connection to the program that is no longerrunning.TCP only sets the SYN flag when the connection is started.The server replies to the SYN header with a header containing both a SYN and an ACK flagset.ACK stands for acknowledgment. The SYN lets the client know its initial sequencenumber TCP connections are bi-directional.The ACK flag lets the client know that itreceived the initial sequence number.Whenever the acknowledgment number field is valid,corresponding to the sequence number of the next data byte expected, the TCP sets ACK flag.To complete the connection, the client responds back to the server with a TCP header thathas the ACK flag set.The acknowledgment lets the server know that it is now ready to beginreceiving data.Understanding the sequence of events with SYN and ACK flags during theestablishment of a connection is also important when configuring firewalls (see Chapter 7, How to Build a Firewall, for more information)
[ Pobierz całość w formacie PDF ]