Get this Security+ CertiGuide for your own computer.
Click Here!
Use coupon code "certiguide" to save 20%!
(Expires 2004/12/31)

Also available: 300-question Security+ practice test!
Get It Here!

Custom Search







Table Of Contents  CertiGuide to Security+
 9  Chapter 1:  General Security Concepts (Domain 1.0; 30%)
      9  1.4  Attacks
           9  1.4.3  Spoofing

Previous Topic/Section
1.4.3  Spoofing
Previous Page
Pages in Current Topic/Section
1
Next Page
Problem #1: Spoofing Can Worsen a DoS Attack
Next Topic/Section

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 1960’s and 1970’s. 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 didn’t depend on a particular path through the inter-network being available) and decentralization (so that the destruction of one machine couldn’t 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 don’t 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 packet’s 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 user’s machine’s 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.


Previous Topic/Section
1.4.3  Spoofing
Previous Page
Pages in Current Topic/Section
1
Next Page
Problem #1: Spoofing Can Worsen a DoS Attack
Next Topic/Section

If you find CertiGuide.com useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider buying an inexpensive PDF equivalent of the CertiGuide to Security+ from StudyExam4Less.com. (Use coupon code "certiguide" by December 31, 2004 to save 20%!) Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.