Defending against denial of service attacks

The recent distributed denial of service (DDoS) attacks have been

labeled a wake-up call. If that is the case then many have been hitting the snooze button repeatedly, since the warnings started as early as 1983. They were aware of the threat and aware of the technology available to eliminate this threat. This was not a failure on the part of the government to spread the warning, it was a failure of organizations with networks connected to the Internet to exercise due diligence in protecting their networks with available technology.

Covert channels are the principle enablers in a DDoS attack. Without covert channels, attackers would not have the ability to command distributed agents used to launch these attacks. If you eliminate the ability to communicate with the agent that launches the attack you effectively eliminate the threat of the attack.

A covert channel is essentially a method of communication that is not part of an actual computer systems design but can be used to transfer information to users or system processes that normally would not be allowed access to the information.

The DDoS Attack model consists of:

— a client, which can initiate commands to hundreds of masters.

— masters, who are typically hidden on compromised systems with moderate bandwidth availability that processes client commands for up to 1000 agents.

— agents (Daemons), which are typically hidden on compromised systems with high bandwidth availability, which carry out these commands.

In this model, the attacker can distribute the ‘work’ of the denial of service attack effectively across potentially thousands of compromised computers. The client issues a single command to the masters, and they in turn contact their respective agents and the attack commences against the defined target.

In a DDoS, it is the communications between the client, master and agent that takes advantage of the covert channel flaws in most protective mechanisms such as firewalls. Specifically in the recent DDoS attacks, the ICMP protocol was used as the covert channel to issue the commands to the distributed agents. Additional stealth was gained by using encryption to further hide the DDoS commands within the covert channel.


Employees must be trained to recognize the risks they are taking when they download software from the Internet, open executable files attached to email and load software from any source on a PC in the organization’s network. Education of your employees should be an ongoing effort to keep pace with the ever-changing threat.

Prevention of a breach that would allow an attacker to deploy a Trojan on your network is critical. In many cases it is not necessary to attack the firewall to gain entry into the corporate network. Operating a supposedly strong firewall on an unsecured operating system is equivalent to locking the front door but leaving the back door and all the windows of your home open.

The attacker can attack weak services — i.e. WUFTP, IIS4, or Send Mail — to find a known weakness that provides entry.

Using strong proxy technology to verify the length of protocol headers to reduce the possibility of protocol header-based buffer overruns is also an often-overlooked defense.


In the days of slower microprocessors, many firewall vendors chose to sacrifice security for overall firewall performance. In minimizing the security-related work they perform to increase performance, they do not provide the capability to inspect the packets passing through the firewall in enough detail to determine if a covert channel is being utilized.

These type of firewalls are only typically concerned with source – destination address, source – destination ports, communications state and to a limited degree the filtering of specific application level commands contained within the payload of the packet. Often the inspection is limited to known protocol header fields specific to a given protocol. Malicious data can be passed through in a multitude of areas that are not used for normal transmission or are optional fields to be set as needed by the sender of the packet.

In many cases the packet can carry all of the necessary correct information for an allowed protocol while in fact the data portion of the packet contains the malicious data specific for a protocol that would otherwise not be permitted. Typically these packets would be sent to a Trojan program running on a server behind the firewall that would have the ability to properly decode these packets in to a usable form for the attacker.

As network security has advanced, so has malicious covert channel technology.

Unfortunately, as processor speeds increased, many vendors chose to add additional bells and whistles rather than increasing the overall level of security of their products.


Many firewall vendors irrationally claim that not breaking the client-server model offers some form of security advantage. With older slow microprocessors this did effectively increase performance as less work is physically done, but it reduces the level of security that can be attained and in fact subverts the purpose of a firewall: securing the Internet connection. This misguided approach in failing to break the client-server model provides a direct path for the attacker to implement a covert channel.

With today’s faster microprocessors and the incorporation of Symmetrical Multiprocessing capability in firewall software, performance is simply no longer an issue. Stronger security methodologies can be exercised without an unacceptable negative impact on performance.

Strong proxy technology breaks the client-server model and solves in part the covert channel dilemma. Acting on behalf of the user, the proxy terminates the connection at the proxy within the firewall. The proxy creates a new ‘blank’ empty packet.

The proxy is ‘application aware’ and fully inspects the original packet. If a permitted command is found in a protocol header, then that command alone is entered into the new packet. Any data that may have been encoded in unused headers in the original packet is dropped, as it is simply not included in the new packet. All protocol headers are inspected to verify header length is RFC compliant.

The proxy creates a new connection between the proxy and the protected server. The proxy sends the newly created packet to the protected server.

In a strong application proxy there is no direct connection between the malicious user and the protected server. Any malicious data that is hidden in unused protocol header fields is simply dropped and is not passed to the protected server. Strong proxy technology is not new and can be found in existing firewall offerings.

A firewall can only be as strong as the operating system upon which it operates. The technology exists which effectively eliminates the issue of covert channels in the operating system. Vendors basing their firewall design on the published guidelines of the NCST Orange Book “B” Level of Trust are quickly becoming more popular as organizations recognize the inherent value of operating their firewall application integrated with a Secure Operating System.


Here are some recommendations for effectively dealing with the threat of DDoS attacks.

If you do not have a firewall, apply anti-IP spoofing rules at your boundary routers (Network Ingress Filtering).

If you have a firewall apply anti-IP spoofing rules on the external interface to block incoming spoofing attempts. Also, apply anti-IP spoofing rules to your firewall’s internal interfaces to prevent your internal users from IP spoofing packets that are leaving your network destined to external servers.

Secure your network connection to the Internet with a firewall operating on a secured operating system, which has been independently certified to offer a Level of Trust that meets with the requirements of your organization’s security policy.

Scan your internal network for detection of DDOS master and daemon programs on compromised systems.

Block any and all protocols to your internal network that cannot be examined with strong application proxies.

Do not allow remote users access to internal servers without strong authentication and encrypted communications (VPN).

Move all public access servers to an isolated DMZ.

Block all access from internal users to servers located on the DMZ.

Separate all offered public services on independent servers within the DMZ.

Remove all unused services on all public access servers on the DMZ.

Remove all unnecessary services on client computers within the protected network.

Profile network traffic flows for changes that may be an indicator of malicious use.

Keep regular Audit Trails – Do not allow log files to roll over thereby overwriting potential evidence.

Adjust your organization’s security policy continuously to match the ever changing current security threats

Review and update your organization’s security policy to establish, monitor and enforce acceptable use policies to prevent introduction (downloading) of malicious applications.

The response to a DDoS attack goes well beyond the target organization capabilities to defend itself and requires a coordinated effort between the target and the target’s ISP. As your Internet access may be effectively eliminated during a DDoS attack you must plan for out -of -band communications to your ISP to support a coordinated effort in blocking hostile connections well before they reach your Internet gateway.

Pre-determine (1) whom to contact to elicit the assistance of local, state and federal authorities and (2) how to contact them on an out-of-band channel.

Have the necessary tools and training for rapid log file analysis to define offending source network IP addresses.

Make intrusion scanning and vulnerability assessments with current signature files on your gateway and internal network a regular practice.

Monitor the status of critical programs on your gateway, public access servers and important internal servers with a program like TripWire for changes that may be an indicator of malicious activity.

Regularly educate employees on the ever-changing threats to network security and their respective individual responsibilities to uphold the organization’s network security policy.

This is an excerpt from a white paper by Paul A. Henry, General Manager, Asian Operations, CyberGuard Corp.