Securing against Denial of Service attacks

Q1: What is a Denial of Service attack?

Denial of Service (DoS) is an attack designed to render a computer or network incapable of providing normal services. The most common DoS attacks will target the computer's network bandwidth or connectivity. Bandwidth attacks flood the network with such a high volume of traffic, that all available network resources are consumed and legitimate user requests can not get through. Connectivity attacks flood a computer with such a high volume of connection requests, that all available operating system resources are consumed, and the computer can no longer process legitimate user requests. The high-profile attacks of the week of February 6th, 2000 were primarily bandwidth attacks, and all of the targets were high-profile internet web sites. A complete description of Denial of Service attacks is available from CERT on http://www.cert.org/tech_tips/denial_of_service.html.

Q2: What is a Distributed Denial of Service attack?

A Distributed Denial of Service (DDoS) attack uses many computers to launch a coordinated DoS attack against one or more targets. Using client/server technology, the perpetrator is able to multiply the effectiveness of the Denial of Service significantly by harnessing the resources of multiple unwitting accomplice computers which serve as attack platforms. Typically a DDoS master program is installed on one computer using a stolen account. The master program, at a designated time, then communicates to any number of "agent" programs, installed on computers anywhere on the internet. The agents, when they receive the command, initiate the attack. Using client/server technology, the master program can initiate hundreds or even thousands of agent programs within seconds.

Q3: How is a DDoS executed against a website?

A website DDoS is executed by flooding one or more of the site's web servers with so many requests that it becomes unavailable for normal use. If an innocent user makes normal page requests during a DDoS attack, the requests may fail completely, or the pages may download so slowly as to make the website unusable. DDoS attacks typically take advantage of several computers which simultaneously launch hundreds of thousands of requests at the target website. In order not to be traced, the perpetrators will break into unsecured computers on the internet, hide rogue DDoS programs on them, and then use them as unwitting accomplices to anonymously launch the attack.

Q4: Is there a quick and easy way to secure against a DDoS attack?

No. From a simplistic perspective, the best solution is to secure computers from being hijacked and used as attack platforms. This cuts the problem off before it can ever manifest. Thus many experts suggest that we "pull together as a community" to secure our internet computers from becoming unwitting accomplices to such malicious intruders. Unfortunately, for every business that has the knowledge, budget, and inclination to make such changes, there are many more which lack such resources.

Plus, the attackers are most likely going to use non-commercial computers as attack platforms, because they are usually easier to break into. University systems are a favorite, because they are often understaffed or the systems are set to minimum security levels to allow students to explore the systems as part of their education. Further, this is not just a national problem. Any internet server in the world could be used as an attack platform.

Still, the simplest and most effective solution for preventing DDoS is through a global cooperative effort to secure the internet. The first step in the process, therefore, is concerned with scanning your internet computers to make sure they are not being used as unwitting DDoS attack platforms. This is not just good internet citizenry, however, because this also serves to document and verify that your internet computers are not suspect when DDoS attacks occur.

Q5: Can the U.S. Government make a difference?

Certainly. The government could impose many types of restrictions on the internet that could greatly limit such types of attacks, at least from U.S.-based computers. Getting on the web could require the equivalent of a "Driver's License", having a website could require the equivalent of a "Commercial Permit", and all ISP's could be tightly regulated, much as the public utilities (Water, Power, etc.) are today. However the government is treading a fine line between limiting criminal activity and limiting economic growth, education, freedom of information, and general personal freedoms. For the time being, the U.S. government appears to be looking for approaches that are consistent with a non-intrusive approach.

For example, President Clinton proposed that we develop an information security "cyber-corps" of recent college grads to fight DDoS and other cybercrimes. While this is a sensible proposal, will there be a rush of computer science grads who will want to join such a group? Computer science students are by and large interested in science, not in law enforcement, so if Clinton's proposal goes through, it will be interesting to see if the government can attract the best of the best to join the "cyberpolice".

It should be noted, however, that in all likelihood a more intrusive government role is inevitable if uncontrollable attacks continue. If the government tries to be both helpful and non-intrusive, they may be simply ignored by commercial ventures. For example, during the week of February 6, 2000, a report from Federal Computer Week revealed "that only 2,600 individuals had downloaded a free security tool from the FBI's Web page. That tool, which detects denial-of-service code, has been available since December."

Step by Step

Q6: How do I check my servers to see if they are active DDoS hosts?

• Acquire one or more filesystem scanning tools to determine if any of the known DDoS tools are present on your server file system.
• Compare the available tools from security tool vendors. Like virus software, DDoS tools become obsolete as new DDoS exploits are invented or existing ones are modified to evade detection. Select a tool that has been recently updated to handle the latest DDoS attack methods.
• The FBI offers a tool on their website called "find_ddos" that will search the file system for the Trinoo, TFN, TFN2K and Stacheldraht DDoS tools. It is freely available on http://www.fbi.gov/nipc/trinoo.htm. One may be interested in the fact that the FBI does not make the source code for this program available.
• Note that the FBI tool is not guaranteed to catch every DDoS binary. If the perpetrator has installed a root package, the find_ddos program may or may not be able to overcome it. The readme file says, "The tool was written in C so that it will have minimal reliance on system binaries, so it will not be impacted by most 'root kits'. However, it is susceptible to a kernel loadable module-based root kit."
• For more information about how root kits work, see http://staff.washington.edu/dittrich/misc/faqs/rootkits.faq.
• An alternative scanning tool is freely available on http://www.nessus.org.
• Many commercial tools are also available.
• Use manual methods to double-check for DDoS activity originating from your network (techniques from Kurt Seifried, seifried@securityportal.com).
• Set up a filter on the firewall that sits between the web server and the internet connection or upstream connection to your ISP. Look for "spoofed" packets, i.e., packets that do not originate from your network. This is known as egress filtering. If spoofed packets are being generated on your network, there is a good chance that a DDoS program is generating them. Trace the packets back to their source, take the computer offline and clean the computer.
• Block ports (like 37337) that are typically used to remotely control compromised machines.
• Scan your network for open ports on a regular basis using tools such as nmap or saint - any changes should be investigated and appropriate action taken.

Q7: What should I do if I find a DDoS host program on my server?

• Recognize that the presence of a rogue (Trojan Horse) program on your system indicates that a vulnerability exists which has been exploited. Other subtle and not so subtle changes could have been made to the system, so a complete analysis of your security vulnerabilities is required. While your system may not yet be displaying any overt problems, this is no reason to soften the incident response approach.
• Execute your organization's incident response policy. If no policy has yet been put in place, then perform the following emergency steps, at minimum:
• Write everything down, starting from the first suspicion of an incident. Depending on the severity of the compromise, this will help you both technically and legally.
• Do not broadcast the information regarding the compromise to your organization. This can not be helpful, and could lead to media involvement. Only inform those individuals who can directly assist in helping to fix the problem, your manager, and law enforcement officials.
• Contact the strongest security experts in your organization for assistance. If none are available, ask management to request immediate assistance from a consulting firm that is experienced in incident handling for the operating systems and system software that you are running.
• Physically remove the compromised computer from the network (unplug the network cable). If the computer is mission-critical, then deploy a hot-backup server if available. If no hot-backup is available, then downtime is unavoidable.
• Backup the compromised computer's file system. Before beginning the backup, dump any dynamic data tables maintained by your operating system to standard files so that they can be analyzed later. For example, the lists of currently executing processes, of currently logged-in users, and of current network connections should be dumped to flat files. Then make two backups of the system using two different backup programs.
• Shut down the compromised computer.
• Re-start the computer.
• Reformat the drives used by the system software.
• Reinstall the operating system.
• Apply all operating system patches.
• Perform system "hardening" - this involves establishing operating system-specific settings to negate commonly known vulnerabilities.
• Restore the file system - do not overwrite any system files, and examine any password files manually before the restore.
• Put the computer back on the network.
• Check all other computers on the network to see if the same vulnerability has been exploited elsewhere.
A comprehensive incident handling approach is currently available on http://www.cert.org/tech_tips/root_compromise.html.

Q8: How can I prevent my servers from being used as DDoS hosts in the future?

• Recognize and understand the vulnerabilities of internet servers:
• Unless special measures have been taken, internet servers have host names and IP addresses that can be easily looked up by anyone on the internet.
• Many organizations do not put firewalls in front of their internet servers, leaving them largely unprotected from many of the probes and attacks that firewalls can easily stop.
• By default, servers listen for service requests on standard, well known ports, and they naturally attempt to process all requests.
• Servers are designed to run unattended, so there is rarely a "user" present who could look for unusual activity.
• Servers often need to be administered remotely, from off-site, so they are designed to accept remote connections from users with very powerful permissions.
• Many servers will reboot automatically after a shutdown, which is exactly what certain types of exploits are looking for.
• If your system has already been compromised, then backup the filesystem, re-install the operating system and restore the filesystem.
• Install operating system updates provided by OS vendor.
• If the update is security-related, then it is especially crucial to install it.
• Be sure to read the vendor's documentation carefully. Some updates are less well-tested than others, and an update can actually harm your system if it contains defects.
• Secure the servers.
• Turn off all unnecessary server services. Many of the services offered by your operating system are not required by your web server, for example RPC-based services. Adopt the attitude of "deny first, then allow". Assume a service should be turned off, unless it is absolutely required.
• First determine which of the program-based services can be turned off, such as FTP, telnet, etc. These services are easily found as executable programs in the file system.
• Many systems have been compromised by exploitation of buffer overrun bugs in the RPC services "statd", "cmsd" and "ttdbserverd". These attacks are described in CERT Incident Note 99-04 available on http://www.cert.org/incident_notes/IN-99-04.html.
• Next check your operating system's documentation to see if it is providing services at the kernel level which are not visible as separate programs. For example, the netmask service may be provided at the kernel level. In this case, determine what parameters can be set, if any, to turn off kernel level services that are not required.
• Contact your operating system vendor to find out if there are additional kernel level services that are not in the system documentation, and, if so, how to disable them.
• Once all unnecessary services have been disabled, make cryptographic checksums of the entire system, which can be used later if there has been a suspected breach.
• For UNIX-based systems, Tripwire will handle this, available from TSS.
• More information on cryptographic checksums is available on http://www.cert.org/security-improvement/practices/p043.html
• Configure the web server software.
• Verify that you have the latest version of the web server software installed. If your version is old, get the new one and install it before continuing.
• Turn off all unnecessary services offered by your web server software. For example, Java support, CGI support, and Server-side Script support should be turned off if they are not required.
• Limit physical access to the server.
Take appropriate action to ensure that the server is only accessible to the designated system administrator(s). All the security in the world can be defeated by a simple floppy disk if the perpetrator has physical access to the server.
A comprehensive treatment on server-side security is currently available on http://www.cert.org/security-improvement/modules/m07.html.

Q9: How can I prevent my personal computer from being used as a DDoS host?

• Recognize and understand the vulnerabilities of internet clients:
• Internet clients, i.e., personal computers connected to the internet, can also be compromised and used as agents for DDoS attacks.
• Personal computers with full-time connections to the internet are particularly useful to DDoS perpetrators.
• The easiest way and most common way to compromise a personal computer is through a voluntary file download initiated by the user - malicious programs posing as screen savers, games, and images are common culprits.
• The sophistication of the new personal computer operating systems (e.g., Windows 98, Windows NT Workstation, Linux) which enable background processing and multi-processing, make them viable agents for distributed denial of service attacks.
• If your system has already been compromised, then backup the filesystem, re-install the operating system and restore the filesystem.
• Install operating system updates provided by OS vendor.
• If the update is security-related, then it is especially crucial to install it.
• Be sure to read the vendor's documentation carefully. Some updates are less well-tested than others, and an update can actually harm your system if it contains defects.
• Secure the clients/personal computers.
• All internet users on your network, particularly those with fulltime internet connections, must be informed that their computers could be used as attack agents, and they must be equipped with the latest detection software.
• The new anti-virus updates are now able to detect many rogue DDoS programs. The latest versions of these programs must be downloaded and installed.
• Norton's program is available on http://www.symantec.com/avcenter/venc/data/w32.dos.trinoo.html
• NAI offers similar support on http://vil.nai.com/vil/DoS98506.asp, as do many other vendors.
• Note that if a rogue program is already operating on the client system, these detection programs may not work.
• In the case of Norton, enable real-time protection, then reboot the computer to check for DDoS agent programs already in operation.
A detailed description of client-side DDoS is available on http://www.jmu.edu/info-security/engineering/issues/wintrino.htm.

Q10: What is a "smurf attack" and how do I defend against it?

• smurf is a simple yet effective DDoS attack technique that takes advantage of the ICMP (Internet Control Message Protocol). ICMP is normally used on the internet for error handling and for passing control messages. One of its capabilities is to contact a host to see if it is "up" by sending an "echo request" packet. The common "ping" program uses this functionality. smurf is installed on a computer using a stolen account, and then continuously "pings" one or more networks of computers using a forged source address. This causes all the computers to respond to a different computer than actually sent the packet. The forged source address, which is the actual target of the attack, is then overwhelmed by response traffic. The computer networks that respond to the forged ("spoofed") packet serve as unwitting accomplices to the attack. The basic characteristics and defense strategies against smurf follow. Further information is available from CERT. A complete description of smurf by Craig Huegen is available on http://users.quadrunner.com/chuegen/smurf.txt.
• Attack Platforms: In order for smurf to work, it must find attack platforms that have IP broadcast functionality enabled on their routers. This functionality allows smurf to send a single forged ping packet and have it broadcast to an entire network of computers. To prevent your system from being used as a smurf attack platform, disable IP-directed broadcast functionality on all routers. Generally speaking, this functionality will not be missed.
• The attacker may still be able to launch a smurf attack from inside your LAN, in which case disabling IP broadcast functionality at the router will have no effect. To protect against such an attack, many operating systems provide settings to prevent computers from responding to IP-directed broadcast requests. Check with your O/S provider for more information and review Appendix A of the CERT Advisory number CA-98.01 available on http://www.cert.org/advisories/CA-98.01.smurf.html.
• In order for the attacker to successfully take advantage of you as an attack platform, your routers must allow packets to exit the network with source addresses that do not originate from your internal network. It is possible to configure your routers to filter out packets which do not originate from your internal network. This is known as network egress filtering.
• ISP's should employ network ingress filtering, which drops packets which do not originate from a known range of IP addresses. Ingress filtering is described in detail in RFC 2267.
• Targets: the easiest way to frustrate a smurf attack is to filter for echo reply packets at the border routers and drop them. This will prevent the packets from hitting the web server and the internal network. Another option, for those using Cisco routers, is CAR (Committed Access Rate).
• Dropping all echo reply packets will prevent flooding of your network, but it will not prevent traffic jams in the pipe from your upstream provider.
• If you are the target of an attack, ask your ISP to also filter out and drop echo reply packets.
• If you do not want to completely disable echo reply, then you can selectively drop echo reply packets that are addressed to your high-profile, public web servers.
• CAR is a technology developed by Cisco that allows you to specify the maximum amount of bandwidth that can be used by any particular packet type. Using CAR you can precisely specify the maximum amount of bandwidth that can be used by echo reply packets. For more information, see http://www.cisco.com/warp/public/707/newsflash.html.

Q11: What is "trinoo" and how do I defend against it?

• trinoo is a complex DDoS tool that uses "master" programs to automate the control of any number of "agent" programs which launch the actual attack. The attacker connects to the computer hosting the master program, starts the master, and the master takes care of starting all of the agent programs based on a list of IP addresses. The agent programs then attack one or more targets by flooding the network with UDP packets. Prior to the attack, the perpetrator will have compromised the computer hosting the master programs and all the computers hosting the agent program in order to install the software. The basic characteristics of and suggested defense strategies against the trinoo DDoS attack follow. A complete description of the trinoo was developed by Dave Dittrich and is available on http://staff.washington.edu/dittrich/misc/trinoo.analysis.
• trinoo uses UDP protocol for all communications between the master program and the agents. Intrusion Detection Software can look for flows that use UDP protocol (type 17).
• trinoo master programs listen on port 27655. The attacker will connect via TCP, typically via Telnet, to the computer hosting the master program to launch it. Intrusion Detection Software can look for flows that use TCP (type 6) to connect to port 27655.
• All communications from master to agents must contain the string "l44" (that's the letter l, not the number 1) and will be directed to the agent's UDP port 27444. Intrusion Detection Software can check for connections to UDP port 27444. If packets containing the string l44 are being sent there, the computer receiving the packets is probably a DDoS agent.
• Communications between master and agent are password protected, however currently the password is not sent in encrypted format, so it can be "sniffed" and detected. Using the password, and the script trinotavailable from Dave Dittrich's website, it is possible to positively verify the presence of the trinoo agent. Once an agent is positively identified, the trinoo network can be dismantled:
• Use the "strings" command on the agent daemon to extract the list of master IP addresses.
• Contact all installations serving as trinoo masters to notify them of the incident.
• On the master computer, identify the file (by default named "...") containing the list of agent IP addresses and extract the list.
• Disable the agents by sending them a forged trinoo command to shut down. Note that the agents may restart regularly via an entry in the crontab file (on UNIX systems), so the agents may need to be shut down over and over again until the owner of the agent system can fix the crontab file.
• Check for an active TCP connection to the master program. This indicates live communication between the attacker and the trinoo master program. While the attacker is in all likelihood using a stolen account to initiate the attack, it still may be possible to find the attacker (given high levels of cooperation between the ISP, the telephone company, and law enforcement).
• If you are under trinoo attack, your system will be flooded with UDP packets. trinoo sends the packets from the same source address to random ports on the targeted host. Detection involves finding multiple UDP packets with the same source IP address, the same destination IP address, the same source port, but different destination ports.
• An automated program to detect and eradicate trinoo can be found on http://www.fbi.gov/nipc/trinoo.htm.

Q12: What are "Tribal Flood Network" and "TFN2K" and how do I defend against them?

• Tribe Flood Network, like trinoo, uses a master program to communicate with attack agents located across multiple networks. TFN launches coordinated Denial of Service Attacks that are especially difficult to counter as it can generate multiple types of attacks and it can generate packets with spoofed source IP addresses. Some of the attacks that can be launched by TFN include UDP flood, TCP SYN flood, ICMP echo request flood, and ICMP directed broadcast. The basic characteristics of and suggested defense strategies against the TFN DDoS attack follow. A complete description of the TFN was developed by Dave Dittrich and is available on http://staff.washington.edu/dittrich/misc/tfn.analysis. A TFN incident analysis from CERT is also available.
• To initiate TFN, the attacker accesses the master program and sends it the IP address of one or more targets. The master program proceeds to communicate with all of the agent programs, instructing them to initiate the attack.
• Communications between TFN master programs and agent programs use ICMP echo reply packets, where the actual instruction to be carried out is embedded in the 16-bit ID field in binary format. The use of ICMP (Internet Control Message Protocol) makes packet protocol filtering possible.
• TFN agents can be defeated by configuring your router or intrusion detection system to disallow all ICMP echo and echo reply packets onto your network. However this will break all internet programs (such as "ping") that utilize these functions.
• The TFN master program reads a list of IP addresses containing the locations of the agents programs. This list of addresses may be encrypted, using "Blowfish" encryption.
• If it is not encrypted, then the agents can be identified from the list.
• The TFN agent programs have been found on systems with the filename td and the master programs with the name tfn. They can be positively identified by running the UNIX strings command. See David Dittrich's research for details on the output of strings.
• TFN agents do not check where the ICMP echo reply packets come from. Therefore it is possible to forge ICMP packets to flush out these processes.
• TFN2K is a more advanced version of TFN, that "fixes" some of the weaknesses of TFN. A CERT incident analysis is available.
• Under TFN2K communications between master and agent may use any one of several protocols - TCP, UDP or ICMP - making protocol filtering impossible.
• TFN2K is capable of sending corrupt packets to cause a system to crash or become unstable.
• TFN2K can defeat egress filtering and ingress filtering by spoofing IP source addresses to make packets appear to come from a neighboring machine on the LAN.
• Because this attack tool has just recently been identified, no research (that I could find) has found any significant weaknesses in the program. Until TFN2K can be analyzed more completely, the best defense is to:
• Harden systems and networks to prevent your systems from being used as DDoS hosts.
• Set up egress filltering on the border routers, as perhaps not all TFN2K source addresses will be spoofed using internal network addresses.
• Ask your upstream provider to deploy ingress filtering.

Q13: What is "stacheldraht" and how do I defend against it?

• Stacheldraht, (German for "barbed wire"), developed by Mixter, is also based on the TFN and trinoo client/server model where a master program communicates with potentially many thousands of agent programs. The perpetrator connects to the master program to initiate the attack. Stacheldraht adds the following new features: encrypted communication between the attacker and the master program, as well as automated updates of the agent programs using rcp (remote copy).


• Stacheldraht launches coordinated Denial of Service Attacks that are especially difficult to counter as it can generate multiple types of attacks and it can generate packets with spoofed source IP addresses. Some of the attacks that can be launched by Stacheldraht include UDP flood, TCP SYN flood, ICMP echo request flood, and ICMP directed broadcast. The basic characteristics of and suggested defense strategies against the Stacheldraht DDoS attack follow. A complete description of Stacheldraht was developed by Dave Dittrich and is available on http://staff.washington.edu/dittrich/misc/stacheldraht.analysis.


• To initiate Stacheldraht, the attacker accesses the master program and sends it the IP address of one or more targets. The master program proceeds to communicate with all of the agent programs, instructing them to initiate the attack.
• Communications between Stacheldraht master programs and agent programs are primarily carried out using ICMP echo and echo reply packets.
• Stacheldraht agents can be defeated by configuring your router or intrusion detection system to disallow all ICMP echo and echo reply packets onto your network. However this will also break all internet programs (such as "ping") that utilize these functions.
• The agent program reads a list containing the IP addresses of valid master programs. This list of addresses is encrypted, using "Blowfish" encryption. The agent attempts to contact each of the master programs on the list. If it is successful, then the agent program performs a test to determine if the system it is installed on will allow it to alter ("spoof") packet source addresses. These two activities can be detected by configuring intrusion detection systems or sniffers to look for their signatures:
• The agent will send each master an ICMP echo reply packet with an ID field containing the value 666 and data field containing the string "skillz". If the master receives the packet, it will reply with an ID field containing the value 667 and data field containing the string "ficken". The agent and master periodically "touch base" by exchanging these packets. By monitoring for these packets, Stacheldraht can be detected.
• Once the agent has found a valid master program, it will execute a spoofing test by sending the master an ICMP packet with a spoofed source address. It uses the false address "3.3.3.3". If the master receives the spoofed packet, it will reply to confirm that source address spoofing is working with the string "spoofworks" in the ICMP packet data field. By monitoring for these values, Stacheldraht can also be detected.
• Stacheldraht agents do not check where ICMP echo reply packets come from. Therefore it is possible to forge ICMP packets to flush out these processes.
• The Stacheldraht agent programs, as well as TFN and trinoo can be detected using a C program written by David Dittrich and available on http://staff.washington.edu/dittrich/misc/ddos_scan.tar.

Q14: How should I configure my routers, firewalls, and intrusion detection systems against DDoS attacks?

• Against Smurf
• To determine if you are an attack platform:
• monitor for packets which do not originate from your network.
• monitor for high volumes of echo request and echo reply packets.
• To prevent being used as an attack platform:
• disable IP-directed broadcast functionality on all routers.
• filter out packets which do not originate from your internal network.
• To mitigate attacks:
• filter for echo reply packets at the border routers and drop them.
• for Cisco routers, use CAR to specify the maximum amount of bandwidth that can be used by echo reply packets.
• Against trinoo
• To determine if you are an attack platform:
• UDP protocol is used for all communications between the master program and the agents. Filter for flows that use UDP protocol (type 17).
• attackers connect to the master program over TCP at port 27655. Filter for flows that use TCP (type 6) to connect to port 27655.
• master to agent communications must contain the string "l44" (that's the letter l, not the number 1) and will be directed to the agent's UDP port 27444. Filter for connections to UDP port 27444 containing the string l44.
• To prevent being used as an attack platform:
• filter out packets which do not originate from your internal network.
• To mitigate attacks:
• theoretically, you could filter for sequences of UDP packets with the same source IP address, the same destination IP address, the same source port, but different destination ports and drop them. Whether current firewall technology is up to this task is not known to the author.
• Against TFN and TFN2K
• To determine if you are an attack platform:
• monitor for packets which do not originate from your internal network.
• To prevent being used as an attack platform:
• disallow all ICMP echo and echo reply packets onto your network (note that this will break all internet programs that utilize these functions).
• filter out packets which do not originate from your internal network.
• To mitigate attacks:
• (under research)
• Against Stacheldraht
• To determine if you are an attack platform:
• filter for ICMP echo reply packets with an ID field containing the value 666 and data field containing the string "skillz" or ID field containing the value 667 and data field containing the string "ficken".
• filter for ICMP packet source address "3.3.3.3" and the string "spoofworks" in the ICMP packet data field.
• To prevent being used as an attack platform:
• disallow all ICMP echo and echo reply packets onto your network (note that this will break all internet programs that utilize these functions).
• filter out packets which do not originate from your internal network.
• To mitigate attacks:
• (under research)