| Previous | Table of Contents | Next |
How Likely Is Impersonation?
Executing a successful address impersonation attack depends on several factors. First, the hacker must be able to drop packets with forged addresses onto the IP stack either by writing a program or using one of the readily available tools for doing so. Next, the location of the user’s attacking station must be such that it is possible for the forged packet to be delivered. Some network routers and firewalls are configured to drop a packet unless the source address of the packet is within a range, fits a pattern, or matches an entry in a table. Therefore, the network on which the attacker is working may not deliver the packet beyond the attacker’s network boundary. If such filters exist on the network, the hacker also needs to compromise the filter source (firewall or router). Because many ISPs do not bother to block outbound source address impersonation, attacks often originate from public Internet provider locations.
When the attacker’s node is on the same subnet as the forged address, the impersonation attack is easier. The same is true if (as standard policy) the faked packets are routed to the subnet of the attacked node, such as the routing of packets between subnets of a university network.
What else is necessary if the goal is to receive traffic for a forged node and not just flood the victim with ICMP Reply messages? The simple answer is that the impersonated system must be unable to carry out its half of the communication session. The forged node must be unavailable. You can disable a node in a number of ways. The hacker with physical access can walk up to the node and turn it off. As a fallback, the node can be flooded with network packets, even from another dedicated node acting in cohort with the attacker’s node.
Open Networks and Denial-of-Service Attacks
Can you stop an unknown person from continually barraging your publicly published phone number with prank calls? Unfortunately, the answer is “No.” A determined person can reprogram cell phone numbers, migrate from one public pay phone to another, enlist the help of numerous helpers to initiate calls from public phones all over the world, or choose from a variety of other techniques that hide true identity. This is the problem with anonymous source connections. Only if you forced all inbound calls to your house to provide strong authentication could you prevent this attack. Oh, you also can request an unlisted number, but that would hardly be useful if the phone number was for your business. If the number must be public, you can do little to prevent denial-of-service attacks.
The corollary in the Internet is true as well. If you have a publicly visible IP address, such as the one that identifies your business Web server to the world, you always will be open to some denial-of-service attacks. Some threats can be lessened by putting a filter, such as a router that blocks known denial-of-service attacks, between your node and the Internet. However, the attack has merely been shifted to the router, which will be burdened with analyzing and dropping the attack packets. Your Web server throughput will still be lessened if someone is launching denial-of-service packets in your direction.
Impersonation and Tracking
Another unfortunate consequence of open networks is that tracing activities to a specific, prosecutable individual is very difficult. A serious hacker will obtain stolen credit cards, use these to obtain Internet access from ISPs, and launch attacks from these accounts even if address impersonation is not needed. Poor physical and configuration security at publicly available Internet terminals also offer nodes from which address impersonation attacks can be launched. As long as the network is open by design, and anonymous connections are permitted, true accountability for network behavior will remain illusive.
Address impersonation is a particularly threatening attack because it can lead to loss of confidentiality, integrity, and availability. A hacker, who can trick another node into sending information, might be able to gain access to confidential information such as passwords. The ability to fake an address and inject forged messages into the network can be used to trick another node into altering data and violating its integrity. Finally, the pizza attack shows how availability can be impacted. All of these concerns about IP can be summed up in one statement:
To improve upon the security of IP, the IPsec standard was introduced. The purpose of IPsec is to provide confidentiality, integrity, authentication, and nonrepudiation of IP packets in a network. The design of IPsec is flexible enough to support a variety of encryption and hashing algorithms to protect the packets. At the heart of IPsec is the notion of a security association between two endpoints. The security association contains various parameters about the communication exchange including cryptographic algorithm options and choices, as well as session status information. IPsec does not define how the keys used in the session are obtained.
IPsec provides two alternatives called Authentication Header (AH) and Encapsulation Security Payload (ESP).
Authentication Header
If the environment is trying to prevent only tampering or impersonation of IP headers, and consequently of IP addresses, AH is sufficient. A cryptographic hash can be computed on the IP header and attached to the IP packet to provide authenticity and integrity. If public-key cryptography is exploited, nonrepudiation is also guaranteed. All values in the packet appear in the clear with AH because privacy is not a concern.
How does this prevent address impersonation? Each half of the session shares a secret key. The packets sent between the communication endpoints are protected with a digital signature or secure message hash. In the simplest case, a cryptographic checksum is added to each packet to ensure its authenticity and optionally its integrity. Without knowledge of the secret key, impersonation is impossible. IPsec also provides facilities to prevent replay attacks based on previously authenticated packets.
| Previous | Table of Contents | Next |