| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
How TCP/IP Permits Spoofing To understand how spoofing can happen; we need to go back to the origins of TCP/IP itself. TCP/IP was originally developed by the Advanced Research Projects Agency (ARPA), which was the research arm of the Department of Defense, in the 1960s and 1970s. Its goals included flexibility (to handle applications from file transfer to voice over IP), redundancy (allowing for multiple routes between two sites, so that communication didnt depend on a particular path through the inter-network being available) and decentralization (so that the destruction of one machine couldnt bring down the network). TCP/IP is very good at adapting to changes in the network structure, since it is packet-switched rather than circuit-switched. For example, if you are sending packets from site A to site D, and in between the packets pass through sites B and C, if site C goes down TCP/IP detects the problem and finds another route to D, and the conversation continues normally. The applications communicating with each other dont even need to know that there was a problem. This packet-switching approach is part of what makes TCP/IP a viable protocol suite for decentralized networks like the Internet since administrators of Internet sites control only their own networks, the Internet needs to be smart enough to maintain communications even if some intermediate site disappears in the middle of a conversation. At the time TCP/IP was designed, ordinary users of machines on TCP/IP networks were expected to not possess elevated user privileges, such as Administrator or root. Most TCP/IP protocol details were implemented inside the operating system and this model meant that unprivileged users would never have the chance to interfere with packet structures or sequencing. The designers appear to have figured, If you have physical access to a network device, or a privileged account on it, it must be OK for you to do whatever you wish with it. This led to network nodes trusting the packets they received, despite the lack of any failsafe way to guarantee that each packet really did originate from the source IP address it claimed, adhered to the protocol specs, and had not been tampered with in between. This blind trust caused a few problems when TCP/IP began to be used outside of trusted networks. Because TCP is inherently a 2-way communication protocol (unlike UDP, which is a fire and forget protocol) with acknowledgements and packet delivery guarantees, there has to be a way to identify where the data is coming from and where replies should be sent. The origin of the packet is called the source IP address and is held inside every TCP packets header (a packet header is a section of information at the start of every packet sent across a network). Under normal circumstances, a user would load an application such as a web browser and type in the address of the website they wished to view. The network stack in their machine would create the appropriate packet (in this example, an HTTP request packet), add the packet header including the users machines IP address in the source IP field, and send it off across the network. However, if the user has sufficient privileges on their machine, it is possible for them to change the contents of the packet header before the packet is sent. This allows them to change the source IP address in the packet header, thus spoofing their IP address by making the packet appear to originate from a different source.
Home - Table Of Contents - Contact Us CertiGuide for Security+ (http://www.CertiGuide.com/secplus/) on CertiGuide.com Version 1.0 - Version Date: November 15, 2004 Adapted with permission from a work created by Tcat Houser et al. CertiGuide.com Version © Copyright 2004 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |