Network security: DoS vs DDoS attacks
Date: December 02, 2005Source: Computer Crime Research Center
By:
... (called IP tunneling).
NextCommunications on the Internet is based on Trust
Our examples so far confirm that "IP packets are unreliable datagrams in that IP does nothing to ensure that IP packets are delivered in sequential order or are not damaged by errors ... in other words, the IP address forms the basis of authentication ..."[7] Put another way, "The Internet protocol by itself provides no reliability".[28] RFC791 states that "the Internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an Internet datagram) from a source to a destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability ...".[29]
In short, the IP data transfer protocol is the basis of packet delivery and therefore the basis for communications on the Internet. The IP data transfer protocol is based on trust. "The IP protocol is designed around the concept of unreliable datagram. Its one purpose is to get a packet of data from one machine to the destination machine."[30] There is no inherent concept of security; each system processing a packet trusts the information within the packet. Further, each layer of the communication (frame, packet, IP, TCP or UDP) ... "has a single job to do, and doesn't know anything about what is going on in the other layers".[8] This means that the detection of a change made at one layer will not occur at another layer and will be trusted by other layers.
Given that the entire structure (IP version 4 and less) is based on trust, it is not surprising that cr/hackers and others are succeeding, by exploiting these trust relationships.
Security Issues with ARP and Routing
In non-switched Ethernet environments, everyone on the wire can hear everything occurring on the segment. Therefore, unless some form of encryption is in place, access to the segment at any spot means complete access to all data flowing on the segment. The attacker must simply place their system in 'promiscuous mode' (there are many hacker programs available to do this) and the attacker can 'sniff' the complete network. One popular security response is to "switch" or bridge off sections of the Ethernet so that only one machine is on a segment. This stops most aspects of 'sniffing' since the only traffic on the segment is your own, or is broadcast traffic. However, DoS attacks are still possible (as are some types of packet intercepts utilizing weaknesses within ARP and attacks that utilize other aspects of broadcasting).
Several DoS, DDoS and directed attacks exist within the default structure of ARP. Many are based on the fact that when a user asks (via broadcast message) for another user's Ethernet address (known as a MAC or Machine Address Code) every one in the room (on the segment or on the Ethernet switch) hears the response and all ARP tables are updated. Everyone else updates their ARP as this lowers the total number of broadcast messages on the segment and increases throughput by increasing the likelihood that the required MAC is in the ARP table before it is required.
"... therefore you can subvert [the Ethernet switch] by sending out ARP's claiming to be somebody else as the source address. You can broadcast out an ARP claiming to be the router, in which case everyone will try to route though you." [9] In this case, all communication in the net is cut off (a DoS) if you do not forward packets (since all requests will go to you as systems change their ARP tables in response). An ARP packet could also be forged to elect the victim's system as a router, providing the same DoS effect but obfuscating the audit trail by not leaving your IP address in ARP tables on the system. Note that if you do forward packets (become a router) then you will see (and have an opportunity to change and re-route) all routed traffic on that switch.
"Or you can send an ARP request ... to the victim's MAC address claiming to be the router, at which point just the victim will forward packets to you." [10] This provides the opportunity for a directed DoS against the communications capability of a target system by substituting their router with a system of your choice (or, if you wish, an opportunity to change or re-route that systems traffic).
Conversely you can send an ARP to the router's MAC address claiming to be the victim." [11] This will serve to have all requests for the victim come to you (therefore replacing the victim with your system) or act as a DoS by eliminating all incoming packets to them.
Attacks can also be directed against the victim's MAC address. "You can do this simply by sending out frames with the source address of the victim"[12] This will cause the Ethernet switch to change its tables in response, therefore directing some packets to the attacker. However the victim system will also be broadcasting their MAC so the switch will quickly be re-programmed. This in itself can become a DoS against both the switch (by overloading it with higher priority routing requests) or against the target (by periodically denying packets which were directed to you causing sequence problems and eventual communications failure.)
While some of these attacks require special software (for example to change the MAC content in an Ethernet frame before you send it), "... most adapters allow you to reconfigure the runtime MAC address. For example, some cards allow you to reconfigure the address within the Windows control panel."[13] It should also be noted that the special software required to forge packets and frames is readily available on the Internet, along with prewritten scripts that implement most of these attacks with a minimum required user skill set.
All of these attacks could become DDoS attacks by writing s/w (such as an infected game or even a virus) that caused selected machines to generate ARP packets. Even mis-configured or blatantly incorrect ARP packets can initiate a Dos or DDoS attack as they will be of a high enough priority to continually interrupt the network.
Network Communications - TCP/IP
TCP/IP is a suite of protocols including TCP and IP, UDP (User Datagram Protocol), ICMP (Internet Control Message Protocol) and several others. The IP layer receives packets delivered by lower levels (such as an Ethernet device driver) and passes these packets either 'up' to TCP or UDP or 'down' from TCP or UDP to the device layer. TCP and UDP in turn communicate with application-level programs such as telnet (through TCP) or NFS - Network File Services (through UDP). ICMP is at the same relative layer as IP and is used to transmit information needed to control IP traffic. Some applications (such as PING) use ICMP directly.
TCP and UDP packets communicate using a combination of ports and IP addresses. UDP or TCP packets will include the source and destination IP address and port (communication channel) on that system in their communication. Each port on a computer can have a service (application program) attached to it. A system will support ports for both UDP and TCP based services. Usually, the first 1024 ports are reserved for the operating system and are well defined (though these port mappings are completely artificial and could be re-mapped by the system administrator with little effort). A complete list of assigned port numbers (allocations) is available from the IANA web site and is defined in RFC-1700.
A message and a response might look like this:
From 12.34.56.789-3097 to 1.234.567.89-23 (data)
And a return message might look like this
From 1.234.567.89-23 to 12.34.56.789-3097 (data)
In this example, the system 12.34.56.789 sends (data) to port 23 (an already opened communication channel) on the system 1.234.567.89 and expects a reply back on port 3097. The port-service construct is in place to let TCP or UDP know what program on the computer will process the data in the packet. The RPC-Portmapper service tells what services are available on a system and what port number the service runs on.
IP itself is 'stateless'. IP simply passes packets from source to destination, much like the traditional postman delivers letters -- by looking at the address information on the 'envelope'. Like the aforementioned postman, IP trusts that the address is correct and does not examine the contents of the letter to determine where it should go.
IP is unreliable. One estimate is that "... roughly 1 in 100 IP datagrams gets lost on the Internet". [14]
For many applications, such as IP Phone and other real time applications such as audio and games, this is an acceptable loss rate, and these applications will typically use UDP. UDP doesn't acknowledge the receipt of packets and doesn't require a connection. UDP packets arrive at a destination port and will be processed by the service assigned to the port. If there is a response, then that response will be sent to the source port and source IP address provided on the original UDP datagram. The next packet to arrive will be similarly dealt with (without acknowledgement, error checking or retransmission). A simple example of a UDP datagram request for service is a request to port 37 (the time service). A UDP datagram arriving at port 37 will cause the time service attached to that port (if available) to send back the time-of-day to the requesting IP address and port. The next packet arriving at that port will cause the same thing to happen.
Other applications such as Telnet demand strict packet accountability. If a packet does not arrive, it must be resent. Each packet is verified as being received. If an application requires reliability, then the application will use TCP. TCP keeps track of the datagrams going back and...
Add comment
Email to a Friend
| Discussion is closed - view comments archieve |
| 2008-11-29 12:41:15 - very good article!!!... dmitriy |
| Total 1 comments |
