by Terrance A. Roebuck
This paper discusses the concept of DoS (Denial of Service) attacks and Distributed Denial of Service (DDoS) attacks from simple examples through to complex deceptions using packet forgery techniques to create DoS and DDoS attacks on information systems. An overview of networking under TCP/IP and Ethernet is provided as a framework for understanding how and why such attacks work within the framework of IP, including TCP, UDP, IMCP, and Ethernet frames. Examples of typical attacks are presented, as well as a discussion of the role and effectiveness of current firewall and systems technology in controlling these attacks.
In its simplest form, a Denial of Service (DoS) attack is an attack against any system component that attempts to force that system component to limit, or even halt, normal services.
A DoS attack may be directed to a specific computer operating system, to a specific port or service on a targeted system, to a network, or network component, to a firewall or to any other system component. More obscure examples could include human-system communication processes, such as disabling a printer or alarm system, or even human-response systems, such as disabling a key technician's home phone or transportation. The key similarity in all of these examples is that, after a successful attack, the system does not respond to a request for service as before, and some expected service, or group of services, is denied or limited to authorized users.
In its simplest form, a Distributed Denial of Service (DDoS) attack is a DoS attack that occurs from more than one source, and/or from more than one location, at the same time. Often, the DDoS attackers are not aware that they are engaging in a DoS attack against a site, and are duped (technically or physically) into joining the attack by a third party.
"The reader should note that while the DoS attack is deemed low from a threat potential, the frequency of this type of attack is very high. DoS attacks against mission-critical nodes are not included in this rating and any attack of this nature should instead be considered as a "High" threat". 
A simple analogy might clarify the difference between a DoS and a DDoS, and point out some interesting subtleties. If a bored teen-ager repeatedly 'prank' calls your telephone, you may soon get tired of answering, and may start to ignore subsequent incoming calls. The teenager has successfully performed a DoS attack on your telephone service, because you are denied normal telephone services (even though you denied them yourself, by choosing not to answer). However, it is easy to screen incoming calls from the teen-agers number, so in many cases, not all services are interrupted -- just incoming calls from a specific number. This also make the location of the attacker easy to trace, and therefore relatively easy to stop.
If, however, the teen-ager called a local radio station and duped them into believing that you had special concert tickets for sale at a very low price, causing your telephone number to be broadcast, you may be inundated with many 100's of calls, from many people. In this DDoS example, you are again denied normal phone services (the DoS component) but the distributed nature of the attack means that most calls that do not originate from a known number would need to be blocked, and if enough people responded, almost no calls could get through. In this case, questioning or tracing any of the apparent attackers is pointless, since they have been duped into calling, and have no evidence to offer at all about the identity of the real attacker. In fact, only the original point of attack (in this case, a call to the radio station) is of any interest in determining who attacked. The teenager may not have even phoned you (so the real attacker, the initiator of the DDoS, did not participate in the actual DoS attack).
As can be deduced from the 'prank-call' analogy, DoS and DDoS attacks usually take advantage of the way a system is supposed to respond to stimulus and therefore exploit systemic weaknesses. The tools for a DoS and DDoS attack are very simple, the skills required to commit an attack is not high, and therefore, very difficult to defend against. Some authors claim that "the problem with denial of service on the Internet is that it is impossible to prevent".
Consider this real example of an attack on an individual that shows a simple DDoS using email and useNet. An attacker, wishing to take revenge on a victim for some alleged slight, used a public access device (in this case, a system in a University library) to post a series of explicit pornographic images to a popular useNet discussion group (in this case, rec.travel.europe). The attacker forged the return address of the posting to be that of the victim (by changing the return address in the browser) and invited anyone wanting to see even more explicit pictures of young children to "just email me and I'll post'em". In this case, as investigated by the author, over a thousand email-messages flooded the victim's mailbox, the University abuse mailbox, the Office of the President of the University, the postmaster, and others on site within hours of the original posting. The only option was to change the email address of the victim and block incomming mail to the old address. These emails ranged from concerned messages, alerts and warnings, to extreme 'flames', virus-infected email, threats, solicitations as well as a lot of porn spam. The victim, a student, was traumatized by the incident and had emotional problems in dealing with the aftermath. Had the victim's email address been an integral part of their corporate advertising, printed on cards and documents, the damage may have been very expensive, as well. 
In this example, the systemic reaction of individual readers of the newsgroup to a pornographic posting was directed as a targeted attack towards one individual. The emails that arrived came from all over the world, without collusion to attack, or with knowledge that they were individually participating in an attack. The tools required were minimal (brief network and Usenet access) and the skill level required to perform the attack (simple email address forgery) was also low.
An examination of possible defenses to this example of a simple DDoS is also interesting. A firewall would not stop the initial attack/occurrence from happening (as the posting could have easily been made from outside the firewall; and even if inside, the firewall might well allow postings to Usenet groups from the site). A firewall would not block the distributed attack/response either unless all inbound email is denied. The attack is a 'data driven attack'  and the firewall would rightly pass the email (thought some firewalls might scan for virus attachments). As a result of this event, security on individual public access devices was tightened to make it harder to post a forged email (or in fact any email or Usenet posting) from a public device (and this could have been accomplished by a firewall). However, the root issue that made the attack work, the reaction of offended Usenet readers to 'flame' such postings, is beyond site control and systemic to the nature of the Internet. There does not seem to be any 'fix' for this vulnerability (since the original posting could take place from anywhere).
DoS and DDoS attacks take many forms and can be initiated in many ways, up to and including social engineering attack methods. These attacks frequently are initiated at the network packet level, and can be much more technical in nature.
More sophisticated DoS and DDoS attacks often rely on how packet-switching networks such as the Internet, and local networks such as Ethernet operate in order to perform their attack.
These DoS and DDoS attacks often use special techniques such as 'packet-forgery' (creation of a false packet), 'IP spoofing' (altering an IP address within a packet) and other packet-level attacks to initiate (or to continue) an attack. Simply put, the attacker does something on a network packet level that causes the target system, or some other component of an IT system to react, which in turn stimulates the attack on the target system. To understand how this works, you must consider how systems communicate with each other, both over a single segment of a local network, and over the Internet.
Ethernet communicates between systems by use of digital "packets" of information called frames. Each Ethernet "frame contains the destination address, source address type field and data. An Ethernet address is 6 bytes. Every device has it's own Ethernet address and listens for Ethernet frames with that destination address. All devices also listen for Ethernet frames with a wild-card destination address of FF-FF-FF-FF-FF-FF (in hexadecimal), called a 'broadcast address'. "
"Ethernet uses CSMA/CD (Carrier Sense and Multiple Access with Collision Detection) ... [so] ... that all devices communicate on a single medium, that only one device can transmit at a time, and that they can all receive simultaneously. If 2 devices try to transmit at the same instant, the transmit collision is detected and both devices wait a random (but short) period before trying to transmit again." 
A good analogy of Ethernet technology is the 'dark room' analogy presented in RFC1180. This analogy likens an Ethernet to a group of people in a very dark room. Everyone in the room can hear everyone else talk (carrier sense). Everyone in the room can talk if they wish (multiple access) but because they are polite, they limit their conversations to short bursts. Impolite talkers are asked to leave the room (thrown off the Ethernet). It is impolite to talk while another is speaking, but if two start to talk at once, then both stop. After a random, but short amount of time, one or the other starts to talk again (they know about the simultaneous talking because each hears something that they did not say -- collision detection).
Everyone in the room has their own unique name (unique Ethernet address) and every time someone talks, they preface their conversation with the name of the person they are talking to and their own name -- for example, "Hello Fred, this is Terry" (Ethernet destination and source address). If the sender wants to talk to everyone, they might say "Hello everyone, this is Terry" (broadcast message). In most cases, everyone in the room trusts everyone else that is in the room and they will usually be talking without a secret code (non-encrypted data communication is common). It is more difficult and takes longer to communicate if everything has to be coded and decoded (encryption means high system overhead).
To continue this analogy, imagine that a stranger has secretly entered the room (has tapped that Ethernet segment). The stranger may never broadcast any messages so no one knows that they are there, but because they are in the room, they can hear all the messages being sent in the room (their network card is said to be in promiscuous mode). They can understand any messages that are not in code (non-encrypted) but if they hear the key to the code then they can also decrypt the message. This stranger is said to be "sniffing" the network, and is listening for code information such as passwords or secrets such as confidential data or data encryption keys. Because the stranger never says anything, or interupts a conversation it is very difficult to detect that they are listening.
The stranger could decide to interrupt the communication in the room. One example is by talking all the time (continually broadcasting) so that no one else can talk (therefore causing a DoS to that segment of the Ethernet), another by somehow causing other persons in the room to talk continually to some one else (a DDoS).
The stranger could also use their voice impersonation skills to pretend to be someone else in the room (IP spoofing) or send false messages to someone else using a fake name (packet forgery). These approaches would be hard to trace back if the real person was to suddenly leave the room before the impersonation started (be denied access to the net or to be shut down by a directed DoS attack). The stranger could ask someone else in the room to do something for them such as send on a message to someone in another room (act as a router).
It should be noted that since (usually) the people in the room trust each other, the stranger's messages are (usually) considered as trusted messages.
If only a few people wanted to talk, and they were always all in the same room, this conversation method might suffice. However there are many other people who also want to talk. If a room is too full, no meaningful conversations can take place as everyone is always being interrupted (network segment saturation). In addition, many people are remote - either physically in a different building or part of another company in the same building. These people need to talk to each other, and also to people far way.
To resolve this, we can imagine that people are meeting in other rooms at the same time (multiple network segments) and also in many different buildings (the Internet). There are many ways to assign people to different rooms within a building. The assignment of rooms could be purely arbitrary, or based on a physical location within a building, or rooms could be reserved for people who usually discuss the same topics. For example, one room might be reserved for salespersons from company X while another room might be reserved for company X accountants. Each room would have its own name. To allow as much growth as possible, each building (domain) could have as many rooms as needed (sub-nets), and any person could be identified by their complete building, room and name address (domain, sub-net and host or IP address).
In this expanded view of network communications, a more complete addressing structure is required to pass a message to someone else, especially when they are not in the same room. When a person in a room wishes to send a message (the data segment of a TCP/IP packet) to someone in another room, they need to supply more address information than that provided in a simple Ethernet frame. The speaker prepares a script (a packet) that they will read when they get a chance to speak in their room. The person speaks the entire script (a complete packet) if it is small enough (about 1500 bytes or less for an Ethernet). If their message is bigger, the speaker breaks the complete script up into smaller pieces (packet fragmentation) that are each spoken and later put back together when the recipient hears them all (packet re-assembly).
The process of getting the complete address for someone else is called ARP (Address Resolution Protocol). As the speaker prepares their script before speaking (creates an IP packet), they consult their address book (the local host ARP table) to look up the complete address for the recipient. The address book (ARP table) translates Ethernet addresses to IP addresses. If the address of the person is not in the table, the speaker broadcasts to their room (only) saying "Everyone, this is Terry - is anyone here known as "IP address"? If so, would you tell me your Ethernet address". The person who is known as "IP address" sends back a message with the required Ethernet address information and the ARP table is updated, allowing future messages to be created without a broadcast. Everyone else in the room also updates their local address books with the new information in case they need to communicate with that person later.
If the recipient is not in the same room, then the speaker knows that they can not communicate directly with them. The speaker will have to communicate indirectly, by getting someone else (a router) to relay the message to another room somewhere (within the building or even to another room in another building).
In order for this level of communication (Internet communication) to occur, one person in the room must act as a "router" of messages and agree to pass messages between rooms. The router must have connections in at least 2 rooms. For example, a person in the 'dark room' of an Ethernet might also have access to a mail slot (a gateway) that lets them send and receive postcards and letters to another router in another 'dark room'.
The speaker prepares a special address for these indirect messages, and speaks this message. In indirect communication, the speaker states a message of the form "Hello local router (Ethernet router destination address), pass this to personX, buildingY, RoomY (IP destination address), from Terry (Ethernet source address) person Y, buildingX, roomX (IP source address).
The person acting as a router repackages the message into a postcard that it can send out its mail slot. This may mean that the router will have to break up the original message into yet smaller pieces leaving the receiving router in the other room to reassemble them. This is dependant on the capacity of the router's 'mail slot' (the communications gateway to another network; for example, ATM packets, PPP and SLIP packets are all different sizes and are also dependant on connecting media - copper verses coax or fibre optic). The message as received at the destination router (after re-assembly if required) now looks something like "Hello Router2 (Ethernet router2 destination address), pass this to personX, buildinY, RoomY (IP destination address), from Router1 (Ethernet router 1source address) person Y, buildingX, roomX (IP source address). Router2 can now use their ARP table to send the message to personX and can update their ARP table so that replies (if any) to personY can be sent through the address of router1. If the address is not in router2's local address book, or personX is not in this room, the process is repeated until finally the message arrives at the right room.
By convention, we call a device that connects 2 (or more) sub-nets a router while a gateway is a special router that connects 2 (or more) networks. Routers and gateways can be programmed to allow or block specific communications attempts by examining details of the packet header information. This blocking is often referred to as 'firewalling' and a firewall can be as simple as a series of configuration rules in a router explaining what packets to pass (or deny). Usually, the firewall would not examine the contents of the message in deciding to deliver it or not. Much like the traditional surface mail, only the 'envelope information' is used to route the message within the room or deny delivery.
In summary then, people speaking in their own 'dark rooms' may send messages to other people in other 'dark rooms' by depending on a third party to re-transmit their packages of information. The person speaking the original message does not have to know the route the packet must take to reach the destination. The person sending the message relies on their own ARP table for addresses, and if not present, on the receipt of ARP information from other systems. They trust this ARP data because the other systems are trusted. The speaker assumes that the router is at the address found for it in their ARP table and assumes that the ARP table in the router is correct. After the message is spoken to the first router, the original speaker does not typically have the ability to control the route that the message may go to reach the destination. No confirmation is sent each step of the way -- the message is just passed on. The routers passing the message do not examine the contents of the message and all rely that the originating IP address is accurate. As routers fragment and re-assemble packets of data, they add and later remove their own envelope information (headers). The data part of a packet could itself include a packet (called IP tunneling).
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 ..." Put another way, "The Internet protocol by itself provides no reliability". 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 ...".
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." 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". 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.
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."  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."  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."  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" 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." 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.
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 184.108.40.2069-3097 to 1.234.567.89-23 (data)
And a return message might look like this
From 1.234.567.89-23 to 220.127.116.119-3097 (data)
In this example, the system 18.104.22.1689 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". 
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 forth, and if one is lost, retransmits it. In order to do this, TCP must first establish a connection, using a "three way handshake" (the TWHS). A TWHS starts with a request for communication (the SYN packet), an acknowledgement of the request (a SYN-ACK to agree to talk, or a SYN-RST to deny a connection) and finally an acknowledgement from the originator (an ACK). If successful, the TWHS will establish a connection between a port on one system and a port on another. After the connection is made, TCP acknowledges the receipt of each packet so that the sender knows that it has arrived. At the sending side, TCP waits for acknowledgement of receipt of a packet and resends a packet if no acknowledgement has been received (in a reasonable time).
Whereas TCP and UDP carry data, ICMP contains purely control messages. ICMP has no ports like TCP or UDP but does have 2 fields called "type" and "code".
Many system services are often probed or otherwise exploited by cr/hackers to further other exploits. One common example is portmapper/RPCBind (UDP/TCP port #111). This service provides information on what services are enabled on the host. "If the intruder finds the appropriate service enabled, s/he will then run an exploit against the port where the service is running." Examples include wu-ftpd, rpc.amd, Solaris Calender Messaging Service, and NFS mountd (typically these are all exploited by some form of buffer overflow).
In addition, the portmapper command #2 (UNSET) can be used to cause RPC-based programs to unregister themselves so this can be used as a DoS to kill your services (typically with a spoofed packet)
Other examples of system services exploited for information gathering include systat, who and finger
UDP/TCP port 53 (DNS - Domain Name Service) deserves special mention. By changing values in the DNS, it is possible to route communications in favor of the attacker (usually for further exploit, but it could be simply as a DoS attack). "Hackers/crackers may be attempting to do zone transfers (TCP), to spoof DNS (UDP) or even hide other traffic since port 53 is frequently neither filtered or logged by firewalls. An important thing to note is that you will frequently see port 53 used as the 'source' UDP port. Stateless firewalls frequently allow such traffic on the assumption that is a response to a DNS query. Hackers are increasingly using this to pierce firewalls."
Any port can be attacked as a DoS by simply sending a packet to that port. If there is no service attached to that port, then the packet is ignored and the DoS attack fails. If there is a service attached to that port, then the service must deal with the packet, even if it is malformed or incorrect. The service will deal with the incoming packet as a high priority (interrupt) event. The success of the DoS attack is dependent on how effectively the service deals with the inbound packet.
As a rule, any UDP port that sends a response to a packet is subject to a DoS attack (and therefore to a DDoS attack). Since the UDP service is a stateless response, it can simply be flooded with packets, forcing a DoS as the system struggles to keep up with these high priority service interrupts.
Echo - UDP port #7 is a typical example of a DoS and DDoS attack point. "UDP Port #7 is normally the echo service. The function of this service is to transmit whatever data was sent to it back to the source." The echo port is typically available as a service since many networks (and firewalls) use echo response for system management and performance monitoring. As well, "the Harvest Web server sometimes used port #7 to determine whether or not to update a cached web file. This means that any server that provides Web caching has to make UDP port #7 available for this service to work properly."
A simple attack would be to forge a packet from system A, port #7 to system B, port#7. B would process the packet and send it back to A, who would return it to B. The two machines would engage in a high priority packet passing 'ping pong' game, using resources normally assigned to user processing. This can also serve to " ... dominate lower speed communications media, denying communications. But, if we want to be more certain iof this, we might add something else to the packet. For example, if we set the 'type of service' field to 'Network Control, Low delay, High Throughput, High Reliability' by setting the value to all 1's, we will force these packets to override other packets in the path between the two victims."  If the packet was to be sent between 2 systems configured as a cluster, the short communications channel between the 2 devices would serve to disable the entire cluster (which was set up as a cluster in the first place to ensure high reliability in the event of node failure).
A more sophisticated version of this attack is known as a "fraggle" attack (this is similar to a smurf -- discussed later under ICMP ping issues). These attacks are named after the hacker script (available for download on the Internet) that demonstrates them as attacks. A "fraggle" is an attack by originated by a broadcast message and takes adavantage of the 'echo' and 'chargen' UDP services. A forged packet is broadcast to the 'chargen' port (UDP port#19) of all hosts receiving the broadcast. These hosts see the spoofed return IP address of the victim; everyone responds with a packet of random data, flooding the victim. A "fraggle amplifier" is any host that has the echo service available. The forged message is sent to this service, which then acts to broadcast it to all hosts on their net, increasing the 'range' of the attack. Since many web servers sit outside of firewalls (in order to securely process requests) and since many have the echo service enabled, this attack is particularly effective.
In his article on UDP viruses, Dr. Frederick Cohen suggests several "other UDP services that are likely to provide environments for protocol viruses ... " including 'systat' (UDP port #11), 'quote of the day' (UDP port #17), 'chargen' (UDP port#19), 'time' (UDP port#37), 'whois' (UDP port#43) and 'who' (UDP port#513).
Remember that any DoS attack at a UDP port can become a DDoS attack. This must be true if the definition of DDoS is multiple distributed attackers, because distributed hosts can be spoofed into participating by various vectors -- from a programmed virus through to infection from 'bad' html after visiting an infected web site.
TCP attacks differ in that TCP is not a stateless protocol and requires a TWHS (three way hand shake) before initiating service. This does not make TCP ports immune to DoS attacks. In fact the TWHS is itself a major target of cr/hacker DoS attack attempts.
A SYN-Flood and the ACK-Flood DoS takes advantage of the TWHS to perform a DoS on a host. The normal process of SYN followed by RST or ACK is interrupted and the victim is left with an open port awaiting communication that never materializes. The process is repeated until the total number of simultaneous sessions is open (in theory 1024) and the system is hung. "... in order to completely deny services to a given port on your computer until the next system reboot, the attacker need only send 1024 packets to your computer with the SYN bit set ... One second of packets results in a system reboot - that's a big advantage for the attacker ... (but) ... many systems run out of internal space to store the incomplete connections before the second passes and crash on their own."
The SYN-Flood can easily be turned into a DDoS by using distributed hosts to bounce off packets so that the forensic log examination points to these hosts. A compromised web server can also be used so that infected systems participate after visiting the site, and so continue the attack.
Other TCP attacks include attacks against TCP services such as TELNET using combinations of TCP and ICMP forgery to create a "man-in-the-middle" situation that allows a cr/hacker to see (and route) TELNET packets.
Versions of UDP attacks also exist for TCP but are more difficult to initiate (because of the TWHS). However, once initiated, they can be very effective. For example, "on a TCP connection ... (to 'chargen' TCP port#19) ... it will spit out a continual stream of garbage characters until the connection is closed."
Whereas TCP and UDP carry data, ICMP contains purely control messages. ICMP attacks are attacks utilizing the Internet Control Message protocol to change the way a communications channel, or Internet service operates. "Hackers use ICMP messages to attempt to scan networks, DoS machines, or redirect traffic ... ICMP has no ports like TCP or UDP, but it does have two fields called 'type' and 'code'."
One example is Router Advertisement (type=9). In this attack, the attacker uses ICMP to redirect the network router function to some other host. If that host can not provide router services, a DoS of network communications occurs as routing stops. This can also be modified to single out a specific system, so that only that system is subject to attack (because only that system sees the 'false' router). By providing router services from a compromised host, the attacker can also place themselves in a "man-in-the-middle' situation and take control of any open channel at will (as mentioned earlier, this is often used with TCP packet forgery and spoofing to intercept and change open TELNET sessions).
The Ping command is used to determine if a machine is available. The PING application directly communicates with ICMP by sending a ICMP packet of type=8 and returning a packet of type=0.
A well-known DoS is the "Ping of Death". The default packet size for ping is 56 bytes. In most systems, it is possible to set the packet data size from the command line. In many cases (especially MACS and Windows 95 systems) PING is unable to handle an incoming packet size of 1024 bytes or larger and the system crashes.
This attack is primarily an insider attack in that "most network managers block incoming pings (type=8), but allow ping responses (type=0). Therefore hackers have begun using ping replied as ways of bypassing firewalls. For example, in the massive DDoS attacks against internet sites, commands could b imbedded in ping responses, and floods of responses were directed against the sites in order to clog their Internet connections."  Another variation of a PING attack is the 'smurf' attack, which operates much like the aforementioned 'fraggle'; used as a DoS or DDoS in combination with an echo and/or broadcast to cause flooding of a victim by multiple PING responses.
As mentioned, attacks against DNS are common. ICMP level attacks against DNS include Source Quench (ICMP type=4) which are, in theory, "... supposed to be transmitted by routers/destination when traffic level exceeds a certain threshold. Many systems today, however, do not generate them. ... However, hosts still react to Source Quenches by slowing communications, so they can be used as a denial of service. If a DoS is suspected, the source address of the packets will be meaningless, because the IP addresses are spoofed."  A variation of a Source Quench attack is ICMP Host Unreachable (type=3 code=1) and ICMP Port Unreachable (type=3 code=3) which can be used as a system (or application) specific DoS.
It is clear that ICMP is one of the most abused and dangerous of the IP protocols. ICMP security is also extremely difficult to manage because of the critical role that ICMP plays in message delivery. "The correct configuration of ICMP filters in a firewall is hotly debated. The problem is that ICMP are the 'control messages' for TCP/IP. If you block some incoming ICMP, then you will block communication."  "ICMP cannot simply be abandoned like so many other insecure Internet services because it is so deeply embedded in IP. ... The Internet Control Message Protocol is both necessary to Internet operation and a potentially hazerdous source of corruption, denial of services, and information leakage, If properly managed, networks can be kept reasonably secure from threats resulting from ICMP, however, few current networks are properly configured." 
As mentioned, "a 'smurf' is a ping (ICMP Echo Request) whereas a 'fraggle' is a UDP port#7/echo. These attacks are similar in that they rely on volume to flood a victim and deny services.
Using configuration rules in routers, it is possible to 'amplify' the effects of smurf and fraggle attacks. Amplified DoS attacks use broadcasts to cause machines to respond to the (spoofed) victims request, flooding them. "In IP, a directed broadcast has all the 'host' bits set to either 1 or 0. This means that an address that looks something like 192.0.2.0 or 192.0.2.255 is likely a broadcast. ... If that router has this (address) configured as a broadcast in its routing table, it will forward the single IP packet as a broadcast on that (Ethernet) segment, causing all systems on that (Ethernet) segment to receive the packet"  therefore vastly increasing the number of systems that join in the DDoS.
This points out a typical combination of issues that are exploited to create the attack. Firstly, the echo or ping service is available and secondly, the router accepts certain addreses as 'broadcast' addresses and sends packets to all systems on the sub-net.
DoS and DDoS attacks may be internal or external attacks. That is, they may both originate and attack internal systems ('behind' the firewall) or they may be external attack from internal creation or vice versa.
The role of a corporate firewall in limiting DoS and DDoS attack is of primary concern when the attack passes the firewall barrier (incoming or outgoing). In the case of some DoS and DDoS attacks, this might never happen or only happen as a data-driven attack and therefore be passed through by the firewall. In the case of some direct routing attacks, especially against private network space, a firewall may actually aid the attacker, since the firewall may be the only router available to the attacker that knows about the systems behind it. Further, as discussed earlier, some packets (such as ICMP) must be allowed but may be part of a DoS. Any firewall that is mis-configured or allows certain trusted hosts beyond the firewall high access can be subjected to a spoofed packet attack (appearing to be from the trusted host).
Source routed packets are packets that demand that they be sent through a particular router to their destination. There does not seem to be any reason to allow source routed packets, and routers and firewalls should be configured to ignore them.
Failure to do so can result in several harmful effects.
Packets can be source routed to evade firewalls if a path is known.
Packets can invade private network space (10.x.x.x for example) by bouncing packets off the firewall. Packets are sent to the host by source routing to firewall (which acts as router that knows about 10.x.x.x).
Packet routing through a trusted host using IP spoofing will also allow a packet to bypass a firewall.
A firewall is not a panacea for packet level attack. Consideration of possible attack types is required before the design of security rules in the firewall. Information on packet level attacks is readily available on the Internet, both in documentation form, and in attack scripts that can be ran with little effort or knowledge.
DoS attacks, and DDoS attacks are very difficult to stop, since all UDP services that respond to a packet can be victimized by a DoS attack against that port (and therefore a DDoS attack as well). Many TCP-based services can also be used as a basis for a DoS or DDoS attack.
As long as IP packets are considered "trusted" we will continue to see attacks based on the creation of false IP datagrams. IP version 6 (at the time of this writing, version 4 of IP is the standard) may offer some hope of DoS reduction. However, if implementation of IP6 is such that compatibility with IP4 is maintained, then problems could continue. The recent demise of the copyright on the RSA algorithms and the projected coming into Open-Source code of the RSA encryption software may also offer some hope that more packets will be encrypted.
However, IP protocol management is complex and technical. New exploits are arriving all of the time. Responses to these exploits require the prompt and proper application of system security patches and knowledgeable system management.
We are increasingly seeing that the availability of a computer system is becoming a corporate critical service and a successful DoS attack may have a major impact on a company's ability to respond to events (and on their share value and bottom line).
These factors, along with the difficulty of successfully managing systems and networks at any level seem to indicate that protocol level security issues and packet level denial of service attacks will remain critical for many years.
[National Infrastructure Protection Center. NIPC CyberNotes #2000-19 pg. 9 September 11 , 2000]
["Internet Firewalls FAQ - "What About Denial of Service?" see http://pubweb.nfr.net/~mjr/pubs/fwfaq]
[Interestingly, in this particular case, forensic analysis of the posting was able to determine that the attacker used a computer system that was in an area that was monitored by CCTV. Examination if the taped CCTV output subsequently identified and convicted the attacker.]
[see "Firewalls FAQ - Glossary of firewall related terms; "Data Driven Attack: A form of attack in which the attack is encoded in innocuous seeming data ..."]
[RFC1180 - A TCP/IP Tutorial; interestingly this can also be found by searching for "Official Alt.Hackers.Malicious FAQ Part 3]
[ibid. RFC1180 - A TCP/IP Tutorial]
[Wack, John; "Introduction to the Internet and Internet Security"; http://csrc.nist.gov/nistpubs/800-10/nodell.html Feb. 09 1995]
[Sniffing Network Wiretapping FAQ; 4.5 "What is the OSI 7-layer Model?" http:/www.robert.graham.com/pubs/sniffing.faq_html]
[Sniffing Network Wiretapping FAQ; 3.8.2 ARP Redirect; http:/www.robert.graham.com/pubs/sniffing.faq_html]
[Sniffing Network Wiretapping FAQ; 3.8.2 ARP Redirect http:/www.robert.graham.com/pubs/sniffing.faq_html]
[Sniffing Network Wiretapping FAQ; 3.8.2 ARP Redirect http:/www.robert.graham.com/pubs/sniffing.faq_html]
[Sniffing Network Wiretapping FAQ; 3.8.2 ARP Redirect http:/www.robert.graham.com/pubs/sniffing.faq_html]
[Sniffing Network Wiretapping FAQ;1.5.3 "What is the format of the MAC Address" http:/www.robert.graham.com/pubs/sniffing.faq_html]
[Sniffing Network Wiretapping FAQ; 4.5 "What is the OSI 7-layer Model?" http:/www.robert.graham.com/pubs/sniffing.faq_html]
[FAQ: Firewall Forensics (What am I seeing?) page 3.]
[Cohen, Frederick C. Internet Holes - UDP viruses; 1996 pg2]
[Cohen, Frederick C. Internet Holes - UDP viruses; 1996 pg. 4]
[Cohen, Frederick C. Internet Holes - UDP viruses; 1996 pg3.]
[Cohen, Frederick C. Internet Holes - UDP viruses; 1996 pg 3]
[Cohen, Frederick C. Internet Holes - The SYN Flood; 1996 pg. 3]
[FAQ: Firewall Forensics (What am I seeing?) page 2.]
[FAQ: Firewall Forensics (What am I seeing?) page 12.]
[FAQ: Firewall Forensics (What am I seeing?) page 14.]
[FAQ: Firewall Forensics (What am I seeing?) page 16.]
[FAQ: Firewall Forensics (What am I seeing?) page 31.]
[Cohen, Frederick C. Internet Holes - Internet Message Protocol 1996. Page 4]
[FAQ: Firewall Forensics (What am I seeing?) page 25.]
[Cohen, Frederick C. Internet Holes: SYN Flood. 1996. Pg1.]
[as quoted in Cohen, Frederick C. Internet Holes: SYN Flood. 1996. Pg1.] [Sniffing Network Wiretapping FAQ; 4.5 "What is the OSI 7-layer Model?" http:/www.robert.graham.com/pubs/sniffing.faq_html]
[FAQ: Firewall Forensics (What am I seeing?) page 3.]