Best Practices for Preventing DoS/Denial of Service Attacks

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By By Michael Cretzman and Todd Weeks,Microsoft Corporation

Many corporate websites have suffered from illegal denial-of-service (DoS) attacks more than once. The companies that learn how to turn these experiences to their advantage go a long way to ensuring it doesn't happen again.

Sometimes there's nothing like adversity to give you a new look at your surroundings. And the events of a network attack can uncover some very important mistakes and provide you with more than a few lessons. Turning these lessons into best practices is where the rewards of such adversity are realized. You can arrive at these best practices by asking yourself: "How are we vulnerable?" The following best practices are a sample of some of the common conclusions companies have come to following a DoS attack.

Practice 1

Keep an audit trail that describes what was changed and why.

Practice 2

Create interdepartmental Standard Operating Procedures (SOPs) and Emergency Operating Procedures (EOPs).

Practice 3

Understand that success can result in complacency.

Practice 4

Network monitoring isn't enough; your administrators must know your configuration in detail.

Practice 5

Test yourself both locally and over the Internet.

Practice 6

Your processes can harm you just like as hackers.

Practice 7

Keep people aware of old configurations and their purpose.

Practice 8

When something is different, ask why.

Practice 9

Know the trade-offs between simplicity, cost, and survivability.

Practice 10

Protect yourself against hackers.
On This Page

Practices Details
Considerations for Your Network

Practices Details

Practice 1 - Keep an audit trail that describes what was changed and why

Locked in a file cabinet somewhere may be a document explaining the original purpose of your network design and its interdependencies. For any change to the network to be made, the document should be consulted and updated.

The lesson to learn here is to revisit your auditing trail and ensure that it encompasses both the details of your current changes and the reasoning behind your current infrastructure. With this method, both the common and uncommon configurations of your network are protected from the occasional error.

Practice 2 - Create interdepartmental Standard and Emergency Operating Procedures

One of the reasons why network outages take so long to diagnose is because many network admins begin by only looking for errors in their own segments. Granted, the error may be in a single segment, but the evidence that will lead you to diagnose a problem may be across your Intranet and the Internet. You will be slow to respond because you responded to our own servers first. Often, it takes people far too long to realize that everyone in the company is working on the same problem.

The lesson to learn when developing a best practice is that you need better cross-group communication built in to your Standard Operating Procedures (SOPs) and Emergency Operating Procedures (EOPs). You need to know that administrators in your segment are aware of the implications their changes have on other segments of the network, and who to contact at other segments when any emergency occurs.

Practice 3 - Understand that success can result in complacency

For your network team, it may have been a few years since a challenge of considerable magnitude has occurred. During this time, you may have grown comfortable with the high availability of your network and become complacent toward the potential for emergencies. Unfortunately, this attitude may only be changed as the result of a serious emergency.

It can be a difficult change to make because network administrators are so often engaged in firefighting comparatively minor issues within an overall network of high availability. To change this attitude, you must look for the strongest components of your network and conceive of scenarios where their failure transpires. Envision failure in the areas of greatest success.

Practice 4 - Network monitoring isn't enough, your adminstrators must know the configuration in detail

Even the most intuitive monitoring is little more than a magnifying glass. To be all-knowing, it would need to report on the affect of every setting of every program, service, host and router in the network, as well as all the interactions between these services and resources. Still, such an analysis would lack the business logic behind configurations and the needs of customers using the services on the network.

The real knowledge of the network must be something shared and accessible to all administrators so that the reports generated by monitors can be interpreted quickly and correctly. In order for this to work, this knowledge share must become part of the process of running your network.

Practice 5 - Test yourself both locally and over the Internet

When your network serves customers on the Internet you need to test its availability by simulating their activity. This will help you understand the magnitude of a problem and lead you down the path to discovering your network's problems from your customers' experience.

This kind of real-world approach is invaluable if you want to make sure that you and your customers experience the same highs and lows of your network performance, and the long-term result of this approach is an appreciation of your customers' perspective beyond what is offered through you customer support department.

Practice 6 – Your processes can harm you just like hackers

Are your processes an enemy from within? They can be if you don't evaluate them skeptically and with the attitude that they can harm you as severely as malicious attacks from hackers. You can make the assumption that because you have not experienced serious network outages your current processes are fine. But they may not be adequate to maintaining your current level of availability unless they can incorporate the full extent of your network administration, across all departments and along with all initiatives.

The practice to develop is an avoidance of relying on your apparently successful processes and to acquire an inward, critical element in your team that challenges the processes themselves.

Practice 7 - Keep people aware of old configurations and their purpose

To develop and maintain an awareness of older, and often trusted, network configurations you need to pay special attention to your personnel changes during the development of your business and the expansion of your network infrastructure. Because it is unlikely that you will redesign your entire network infrastructure annually, configurations performed one year may stay around in your network until someone stumbles upon them. To prevent configuration settings being missed, you need to make new personnel aware of these configurations during orientation or as part of annual auditing.

Without this type of training, you may do a disservice to your personnel by putting them in a position where they could damage their network and possibly their reputation unknowingly. Keep this potential cause of emergencies on the minds of your new administrators and you will go a long way to encouraging that they investigate configurations before changing them.

Practice 8 - When something is different, ask why

In any company, the work performed by one employee is as important as the work performed by any other employee. For this reason, an administrator auditing the configuration of a network needs to appreciate that each of the network's configurations, and the settings of the programs that use that network, are the work of a colleague and deserve the same respect that the administrator himself would like for his work. Consequently, when discovering a design that is unusual it is important for that administrator to investigate this peculiarity instead of taking it upon himself to force the design into conformity with some new initiative or standard.

The practice to develop is to go further in developing an inquisitive culture amongst your administrators and, in contrast, to discourage the rote or mechanical routine of processing network changes. You may appear to lose efficiency by having changes take longer with this attitude, but the savings are considerable when compared to the loss of service you can experience when administrators make changes without a solid understanding of the network's settings.

Practice 9 - Know the trade-offs between simplicity, cost, and survivability

There is a tendency to praise simplicity above complexity for the benefit of administrative costs. While there is truth behind this approach, you must also consider the affect that simplicity can have on being able to support unforeseen problems. In designing your network in a simplified manner, you leave yourself open to the repercussions of a simple mistake.

The benefit of a complex network design is greater than the stability obtained through fault tolerance and redundancy. A complex design can benefit the complex business needs you are trying to support. When we simplify the way business information travels across our network, we need to consider whether or not we are serving our administrative needs second and our customers and users business first.

Practice 10 - Protect yourself against hackers

Can you predict where a hacker will attack your network? Developing this anticipation comes from facing the reality of being hacked. While we do not want to say anything which could infer that hackers do anyone a service, to develop this intuitive awareness you need to "hack" your network yourself by imagining what a hacker would do to attack it. This will develop a sensitivity to where your network is exposed to hackers and help you in auditing your network's weak points.

Considerations for Your Network

The following information is provided to help you take a close look at your network and protect it from DoS attacks.

Caution: Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.

The following registry key settings can be implemented to enable protection against DoS attacks:

  • hkey_local_machine \system \currentcontrolset \services \tcpip \parameters \synattackprotect=1 REG_DWORD

  • hkey_local_machine \system \currentcontrolset \services \tcpip \parameters \tcpmaxconnectresponseretransmissions=2 REG_DWORD

  • hkey_local_machine \system \currentcontrolset \services \tcpip \parameters \tcpmaxdataretransmissions=3 REG_DWORD

  • hkey_local_machine \system \currentcontrolset \services \tcpip \parameters \enablepmtudiscovery=0 REG_DWORD

Microsoft Knowledge Base Articles

The following Microsoft Knowledge Base articles will also help you protect your network from malicious attacks:

Microsoft TechNet Resources

You can find numerous, useful resources in Microsoft TechNet that will help you secure your web servers. For example, if you follow the Ten Immutable Laws of Security, you can significantly improve the security of your systems. For more information on network security, please see: https://www.microsoft.com/technet/security/default.mspx.

The Internet Security and Acceleration (ISA) Server provides a multi-layered enterprise firewall that helps protect your network resources. The https://www.microsoft.com/technet/prodtechnol/isa/2000/deploy/isaentin.mspx describes how ISA can help secure your organization's network for the Internet.

Lastly, take a look at the white paper on TCP/IP Implementation. It contains all of the registry keys used for the purpose of securing web servers or preventing an attack.

For any questions or feedback, please write to Microsoft TechNet at https://go.microsoft.com/?linkid=2544905.