Understanding and Preventing DDoS Attacks
January 9, 2004
By Steven J. Vaughan-Nichols
It was in early 2000 that most people became aware of the dangers of distributed denial of service (DDoS) attacks when a series of them knocked such popular Web sites as Yahoo, CNN, and Amazon off the air. More recently, a pair of DDoS attacks nailed The SCO Group's Web site, which many people thought had to be a hoax, since surely any company today could stop a simple DDoS SYN attack. Wrong.
It's been almost four years since they first appeared, but DDoS attacks are still difficult to block. Indeed, if they're made with enough resources, some DDoS attacks – including SYN (named for TCP synchronization) attacks – can be impossible to stop.
No server, no matter how well it's protected, can be expected to stand up to an attack made by thousands of machines. Indeed, [url=\"http://www.arbornetworks.com/\"]Arbor Networks[/url], a leading anti-DDoS company, reports DDoS zombie armies of up to 50,000 systems. Fortunately, major DDoS attacks are difficult to launch; unfortunately, minor DDoS attacks are easy to create.
In part, that's because there are so many types of DDoS attacks that can be launched. For example, last January, the Slammer worm targeted SQL Server 2000, but an indirect effect as infected SQL Server installations tried to spread Slammer was to cause DDoS attacks on network resources, as every bit of bandwidth was consumed by the worm.
Thus, a key to thinking about DDoS is that it's not so much a kind of attack as it is an effect of many different kinds of network attacks. In other words, a DDoS may result from malignant code attacking the TCP/IP protocol or by assaulting server resources, or it could be as simple as too many users demanding too much bandwidth at one time.
Typically, though, when we're talking about DDoS attacks, we mean attacks on your TCP/IP protocol. There are three types of such attacks: the ones that target holes in a particular TCP/IP stack; those that target native TCP/IP weaknesses; and the boring, but effective, brute force attacks. For added trouble, brute force also works well with the first two methods.
The Ping of Death is a typical TCP/IP implementation attack. In this assault, the DDoS attacker creates an IP packet that exceeds the IP standard's maximum 65,536 byte size. When this fat packet arrives, it crashes systems that are using a vulnerable TCP/IP stack. No modern operating system or stack is vulnerable to the simple Ping of Death, but it was a long-standing problem with Unix systems.
The Teardrop, though, is an old attack still seen today that relies on poor TCP/IP implementation. It works by interfering with how stacks reassemble IP packet fragments. The trick here is that as IP packets are sometimes broken up into smaller chunks, each fragment still has the original IP packet's header as well as a field that tells the TCP/IP stack what bytes it contains. When it works right, this information is used to put the packet back together again.
What happens with Teardrop, though, is that your stack is buried with IP fragments that have overlapping fields. When your stack tries to reassemble them, it can't do it, and if it doesn't know to toss these trash packet fragments out, it can quickly fail. Most systems know how to deal with Teardrop now, and a firewall can block Teardrop packets at the expense of a bit more latency on network connections, since this makes it disregard all broken packets. Of course, if you throw a ton of Teardrop busted packets at a system, it can still crash.
Original SYN
And, then, there's SYN, to which there really isn't a perfect cure. In a SYN Flood, the attack works by overwhelming the protocol handshake that has to happen between two Internet-aware applications when they start a work session. The first program sends out a TCP SYN (synchronization) packet, which is followed by a TCP SYN-ACK acknowledgment packet from the receiving application. Then, the first program replies with an ACK (acknowledgment). Once this has been done, the applications are ready to work with each other.
A SYN attack simply buries its target by swamping it with TCP SYN packets. Each SYN packet demands a SYN-ACK response and causes the server to wait for the proper ACK in reply. Of course, the attacker never gives the ACK, or, more commonly, it uses a bad IP address so there's no chance of an ACK returning. This quickly hogties a server as it tries to send out SYN-ACKs while waiting for ACKs.
When the SYN-ACK queues fill up, the server can no longer take any incoming SYNs, and that's the end of that server until the attack is cleared up. The Land attack makes SYN one-step nastier by using SYN packets with spoofed IP addresses from your own network.
There are many ways to reduce your chances of getting SYNed, including setting your firewall to block all incoming packets from bad external IP addresses like 10.0.0.0 to 10.255.255.255, 127.0.0.0 to 127.255.255.255, 172.16.0.0 to 172.31.255.255, and 192.168.0.0 to 192.168.255.255, as well as all internal addresses. But, as SCO discovered, if you throw enough SYN packets at a site, any site can still be SYNed off the net.
Brute Force Attacks
Common brute force attacks include the Smurf attack and the User Datagram Protocol (UDP) flood. When you're Smurfed, Internet Control Message Protocol (ICMP) echo request packets, a particular type of ping packet, overwhelm your router. Making matters worse, each packet's destination IP address is spoofed to be your local broadcast address. You're probably already getting the picture. Once your router also gets into the act of broadcasting ICMP packets, it won't be long before your internal network is frozen.
A UDP flood works by someone spoofing a call from one of your system's UDP chargen programs. This test program generates semi-random characters for received packets with another of your network's UDP echo service. Once these characters start being reflected, your bandwidth quickly vaporizes.
Fortunately, for these two anyway, you can usually block them. With Smurfing, just setting your router to ignore broadcast addressing and setting your firewall to ignore ICMP requests should be all you need.
To dam up UDP floods, just block all non-service UDP services requests for your network. Programs that need UDP will still work. Unless, of course, the sheer volume of the attack mauls your Internet connection.
That's where the DDoS attack programs such as Tribe Force Network (TFN), Trin00, Trinity, and Stacheldraht come in. These programs are used to set DDoS attack agents in unprotected systems. Once enough of them have been set up in naïve users' PCs, the DDoS controller sets them off by remote control, burying target sites from hundreds or even thousands of machines.
Unfortunately, as more and more users add broadband connections without the least idea of how to handle Internet security, these kinds of attacks will only become more common.
Deflecting DDoS Attacks
So what can you do as an administrator about DDoS threats? For starters, all the usual security basics can help. You know the drill: make sure you have a firewall set up that aggressively keeps everything out except legal traffic, keep your anti-viral software up to date lest your computers become a home for DDoS agents like TFN, and keep your network software up to date with current security patches. This won't stop all DDoS attacks, but it will stop some of them like Smurfing.
You should also keep yourself current on the latest DDoS developments. The best site for this is the University of Washington hosted Distributed Denial of Service (DDoS) Attacks/tools [url=\"http://staff.washington.edu/dittrich/misc/ddos\"]site[/url].
There is no silver bullet for DDoS attacks. Several companies, such as Arbor Networks, [url=\"http://www.mazunetworks.com/\"]Mazu Networks[/url], and [url=\"http://www.netzentry.com/\"]netZentry[/url] offer programs and services that can help you manage DDoS assaults.
Essentially, these corporate approaches consist of intense real-time monitoring of your network looking for telltale signs of incoming DDoS attacks. These give you a chance to harden your network or even switch to another ISP provider in an attempt to dodge a DDoS attack. For example, [url=\"http://www.riverhead.com/\"]Riverhead[/url] actually diverts DDoS attacks to its own servers and filters out the good traffic, which it then passes along to your site.
You may not think you need these services, since in a worse case scenario you're still going to get knocked off the net. But not every attack will be a massive one with thousands of attackers. For most attacks, these services can definitely help.
And, let's face it, today almost all businesses need to be on the net 24-7. With DDoS attacks on the rise according to [url=\"http://www.cert.org/\"]CERT[/url], you'd be wise to at least familiarize yourself with DDoS prevention services. After all, it's not only your network in danger, it's your business.
[url=\"http://networking.earthweb.com/netsecur/article.php/10952_3297581_1\"]Source[/url]
DDoS Attacks~For Future Reference
Moderators: Moderator, Global Moderator
DDoS Attacks~For Future Reference
[color=\"#41211C\"]It takes years to build up trust and only seconds to destroy it
[/color]
DDoS Attacks~For Future Reference
Building a Blueprint for Network Security
December 17, 2003
By Paul Rubens
Ever gone out and then spent the evening wondering whether you remembered to lock all the doors back at home?
If you’re responsible for a corporate network, you’ve probably had a similar feeling — is my network secure, or have I forgotten something that could leave my organization wide open to attack from the first hacker to probe my network for vulnerabilities?
It’s an important question, and one worth spending some time considering. How can you be sure you’ve done everything reasonable to secure your network?
If you’ve just assumed responsibility for a network and time is of the essence, the first thing to do is check the existing patch management policy. According to research from Gartner Group, around 30% of damage to networks stems from organizational failure to implement patches in a timely fashion. If you find unpatched systems, get them in order as quickly as possible.
The same research found that 65% of intrusions stem from misconfigured systems, with only 5% coming from problems that were not previously known. To go back to the house analogy, 95% of security problems are caused by casual walk-in burglars who find you don’t bother to shut all the windows and doors when you go out, while only 5% come from more devious and determined thieves.
At this stage you may want to examine the configuration of every device on your network. But if you’re really keen to get moving, then it’s probably wise to hire some penetration testers to check if there are any serious vulnerabilities in your network that are likely to be found by would-be intruders.
It’s also useful to test the security of your network from the inside — there are a wide range of statistics available that indicate a high proportion of network attacks come from employees. This can be achieved by giving penetration testers a realistic amount of inside knowledge and network access, and then discovering what kind of trouble they can get into.
An Overall Security Architecture
OK, so far these have all been stopgap measures, but what’s really needed (in fact required — but more on that later) is an overall security architecture rather than a series of ad-hoc measures. “A high-level security architecture is a set of guiding principals, an orderly arrangement of security components,” says Mark Bouchard, a senior program director at Stamford CT-based Meta Group.
A security architecture should define roles, responsibilities, and a policy framework all the way down to the finest detail in a hierarchy. And the buck must stop with a Head of Information Security, who takes ownership of – and responsibility for – the architecture.
A corporate security architecture will probably include a business process catalogue and a domain structure that divides the organization into manageable – and meaningful – portions with different security requirements. Clearly, valuable R&D data has a different value — and as a result needs a different level of protection — than customer contact details, so these would be in different domains.
Other domains could include an executive domain and a typical user domain. Using a series of tools, models, and templates, appropriate security measures should be defined right down to the level of firewalls and passwords.
The purpose of this division by domains is quite simple — it’s all about risk management. It’s not worth spending $100 on a fence to protect a $10 horse — in other words, the security measures you take should be proportionate to the value of the information you’re protecting.
The purpose of the architecture is to use this process of risk management and codify it into a set of rules with which you can engage business users, who are understandably more interested in doing their jobs than in protecting your company’s assets.
Ultimately, a security architecture is a blueprint for all your security efforts. “Without one to guide you, investments in security will be tactical, reactive. Instead of fixing things, you will probably fix one thing and introduce new vulnerabilities at the same time,” says Bouchard.
There’s one further point in favor of ensuring you have an effective security architecture in place — it’s obligatory. Regulatory and fiduciary responsibilities demand that you take security seriously and address it thoroughly, and the Federal Trade Commission says you need to have a plan. Your security architecture is this plan.
Devising a Security Architecture
So what’s the best way to come up with a security architecture? The most important question to consider is how much to rely on staff from within your company and how much to rely on outside consultants. Security, as we have seen, is all about risk management, and this entails sorting out what is mission critical, what is valuable, and what is merely important.
It’s clear that staff from within an organization are in the best position to understand how the business works and how the underlying processes affect each other, but it’s also important to understand that outside consultants may be more objective and are likely to have a greater specialist knowledge of security than existing IT resources. So while internal resources need to be involved at every level to ensure that the key components are being protected, consultants can be the best option for ensuring that the knowledge of risks and how to respond to them is up to date.
The U.S. Department of Defense-funded CERT (Computer Emergency Response Team) coordination center recommends the use of a methodology called OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation), a risk-based strategic assessment and planning technique for security.
“OCTAVE is self-directed. A small team of people from the operational (or business) units and the IT department work together to address the security needs of the organization. The team draws on the knowledge of many employees to define the current state of security, identify risks to critical assets, and set a security strategy,” says CERT.
Self-direction of the security audit is key, believes Ted Wilke, CEO of Pittsburgh PA-based information security consultancy DMZ2. “Often companies get outsiders to take an audit and then don’t implement the results, as they just don’t buy into it,” he says. “If internal people carry out the audit, then it’s much more likely to get to the real issues, and it’s far more likely that the results will be implemented.”
A Culture of Security
This points to the cultural aspect of security — too often users find security measures simply as impediments to their work, annoyances that are circumvented whenever possible. It’s only when a culture of security is instilled into an organization — so that every employee is aware of security measures and why they have been put in place — that security can be effective. “If you get employees involved, there is a far higher chance of succeeding in improving security, and getting employees to keep other employees in line,” Wilke says.
Outside consultants can certainly add value to a security exercise, but their greatest value comes only after it’s clearly understood what needs protecting and once all employees have been involved. “The types of attacks that companies are experiencing is changing constantly, and most companies can’t cope themselves, so it simply makes sense to get outside help,” says Mike Arnavutian, head of security strategy at BT Global Services.
“A security consultant like us can manage security for a company, removing risk and taking liability — and would charge on that basis.” It’s not only expertise that consultants can bring: security specialists can often offer considerable benefits of economies of scale. “If you look at the cost of monitoring and managing a system, it’s often cheaper for outside experts to do it for you,” he says.
Outside companies can also help by providing alternate facilities for use in a disaster, which may often be necessary from a risk management point of view, but which can also be prohibitively expensive to equip and have standing idle.
When is it safe to say “enough is enough,” and relax in the knowledge that the network is secure and all prudent measures have been put in place? Sadly, the answer is “never.”
Security is a process, not a task, and it needs to be reviewed critically and regularly. New threats appear all the time, and measures that are satisfactory one day may be woefully inadequate the next. The only way to be sure that you are doing enough is by understanding that when it comes to security, nothing is ever enough for long.
[url=\"http://networking.earthweb.com/netsecur/article.php/10952_3290411_1\"]source[/url]
December 17, 2003
By Paul Rubens
Ever gone out and then spent the evening wondering whether you remembered to lock all the doors back at home?
If you’re responsible for a corporate network, you’ve probably had a similar feeling — is my network secure, or have I forgotten something that could leave my organization wide open to attack from the first hacker to probe my network for vulnerabilities?
It’s an important question, and one worth spending some time considering. How can you be sure you’ve done everything reasonable to secure your network?
If you’ve just assumed responsibility for a network and time is of the essence, the first thing to do is check the existing patch management policy. According to research from Gartner Group, around 30% of damage to networks stems from organizational failure to implement patches in a timely fashion. If you find unpatched systems, get them in order as quickly as possible.
The same research found that 65% of intrusions stem from misconfigured systems, with only 5% coming from problems that were not previously known. To go back to the house analogy, 95% of security problems are caused by casual walk-in burglars who find you don’t bother to shut all the windows and doors when you go out, while only 5% come from more devious and determined thieves.
At this stage you may want to examine the configuration of every device on your network. But if you’re really keen to get moving, then it’s probably wise to hire some penetration testers to check if there are any serious vulnerabilities in your network that are likely to be found by would-be intruders.
It’s also useful to test the security of your network from the inside — there are a wide range of statistics available that indicate a high proportion of network attacks come from employees. This can be achieved by giving penetration testers a realistic amount of inside knowledge and network access, and then discovering what kind of trouble they can get into.
An Overall Security Architecture
OK, so far these have all been stopgap measures, but what’s really needed (in fact required — but more on that later) is an overall security architecture rather than a series of ad-hoc measures. “A high-level security architecture is a set of guiding principals, an orderly arrangement of security components,” says Mark Bouchard, a senior program director at Stamford CT-based Meta Group.
A security architecture should define roles, responsibilities, and a policy framework all the way down to the finest detail in a hierarchy. And the buck must stop with a Head of Information Security, who takes ownership of – and responsibility for – the architecture.
A corporate security architecture will probably include a business process catalogue and a domain structure that divides the organization into manageable – and meaningful – portions with different security requirements. Clearly, valuable R&D data has a different value — and as a result needs a different level of protection — than customer contact details, so these would be in different domains.
Other domains could include an executive domain and a typical user domain. Using a series of tools, models, and templates, appropriate security measures should be defined right down to the level of firewalls and passwords.
The purpose of this division by domains is quite simple — it’s all about risk management. It’s not worth spending $100 on a fence to protect a $10 horse — in other words, the security measures you take should be proportionate to the value of the information you’re protecting.
The purpose of the architecture is to use this process of risk management and codify it into a set of rules with which you can engage business users, who are understandably more interested in doing their jobs than in protecting your company’s assets.
Ultimately, a security architecture is a blueprint for all your security efforts. “Without one to guide you, investments in security will be tactical, reactive. Instead of fixing things, you will probably fix one thing and introduce new vulnerabilities at the same time,” says Bouchard.
There’s one further point in favor of ensuring you have an effective security architecture in place — it’s obligatory. Regulatory and fiduciary responsibilities demand that you take security seriously and address it thoroughly, and the Federal Trade Commission says you need to have a plan. Your security architecture is this plan.
Devising a Security Architecture
So what’s the best way to come up with a security architecture? The most important question to consider is how much to rely on staff from within your company and how much to rely on outside consultants. Security, as we have seen, is all about risk management, and this entails sorting out what is mission critical, what is valuable, and what is merely important.
It’s clear that staff from within an organization are in the best position to understand how the business works and how the underlying processes affect each other, but it’s also important to understand that outside consultants may be more objective and are likely to have a greater specialist knowledge of security than existing IT resources. So while internal resources need to be involved at every level to ensure that the key components are being protected, consultants can be the best option for ensuring that the knowledge of risks and how to respond to them is up to date.
The U.S. Department of Defense-funded CERT (Computer Emergency Response Team) coordination center recommends the use of a methodology called OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation), a risk-based strategic assessment and planning technique for security.
“OCTAVE is self-directed. A small team of people from the operational (or business) units and the IT department work together to address the security needs of the organization. The team draws on the knowledge of many employees to define the current state of security, identify risks to critical assets, and set a security strategy,” says CERT.
Self-direction of the security audit is key, believes Ted Wilke, CEO of Pittsburgh PA-based information security consultancy DMZ2. “Often companies get outsiders to take an audit and then don’t implement the results, as they just don’t buy into it,” he says. “If internal people carry out the audit, then it’s much more likely to get to the real issues, and it’s far more likely that the results will be implemented.”
A Culture of Security
This points to the cultural aspect of security — too often users find security measures simply as impediments to their work, annoyances that are circumvented whenever possible. It’s only when a culture of security is instilled into an organization — so that every employee is aware of security measures and why they have been put in place — that security can be effective. “If you get employees involved, there is a far higher chance of succeeding in improving security, and getting employees to keep other employees in line,” Wilke says.
Outside consultants can certainly add value to a security exercise, but their greatest value comes only after it’s clearly understood what needs protecting and once all employees have been involved. “The types of attacks that companies are experiencing is changing constantly, and most companies can’t cope themselves, so it simply makes sense to get outside help,” says Mike Arnavutian, head of security strategy at BT Global Services.
“A security consultant like us can manage security for a company, removing risk and taking liability — and would charge on that basis.” It’s not only expertise that consultants can bring: security specialists can often offer considerable benefits of economies of scale. “If you look at the cost of monitoring and managing a system, it’s often cheaper for outside experts to do it for you,” he says.
Outside companies can also help by providing alternate facilities for use in a disaster, which may often be necessary from a risk management point of view, but which can also be prohibitively expensive to equip and have standing idle.
When is it safe to say “enough is enough,” and relax in the knowledge that the network is secure and all prudent measures have been put in place? Sadly, the answer is “never.”
Security is a process, not a task, and it needs to be reviewed critically and regularly. New threats appear all the time, and measures that are satisfactory one day may be woefully inadequate the next. The only way to be sure that you are doing enough is by understanding that when it comes to security, nothing is ever enough for long.
[url=\"http://networking.earthweb.com/netsecur/article.php/10952_3290411_1\"]source[/url]
[color=\"#41211C\"]It takes years to build up trust and only seconds to destroy it
[/color]
DDoS Attacks~For Future Reference
Fending Off a Vicious Attack
November 21, 2003
By Phil Hollows
Third shift at the Network Operations center is a quiet time, well suited for the engineer types who understand and speak the language of machines.
Let's take a look at what could easily happen on any given 'third shift' at any company, in any industry, around the country.
Traffic in the wee hours of the morning is sparse, and the night thus far has passed uneventfully. Administrators joke with each other and share the usual gripes about work. Tonight's concern focuses on a new software vulnerability found in an email program used by the company's worldwide offices. This means that in the near future the technicians will have to exhaustively test and set another code patch into the system. But for now, all is well and the skeleton IT crew feels fairly safe.
And for good reason.
The company has invested heavily in IT security. The latest firewalls and intrusion detection systems are keeping the network's perimeter secure, and IT managers will discuss new threats and the email patch roll-out during Monday's staff meeting. A good plan will have to be developed to tackle that task. Merely applying an untested patch to the critical email servers is a risk the IT staff can't afford. They know because they've been burnt too many times before.
Normally, these concerns would pass as the shift grinds on, but tonight the issue with the messaging servers gnaws at them.
The firewalls were programmed to let all email traffic through and that leaves a wide gap in their defenses. Email is essential to the company's business and attacking it could, in theory, reach every server in the company.
Just as the IT crew is mulling over the email problem while working on their nightly duties, a hacker somewhere in Eastern Europe hits 'Enter' and releases a new worm into the wild. The mass-mailing worm spreads quickly, doubling the number of infected machines every 10 seconds. Unlike Slammer, a worm that simply replicated itself, this worm's payload is much more devastating.
A simple yet elegant piece of code, the multi-threaded worm is able to execute multiple tasks in parallel — a devastating double threat that first looks for targets to infect while, at the same time, examining stored messages on infected machines. This second threat could identify external email addresses and forward all stored messages from the infected server to anyone and everyone.
Nothing is safe.
Sensitive intellectual property could be made public and mailed to competitors; product plans, account information, and customer interactions could be exposed; and state and federal disclosure and securities and privacy statues could be violated. All of the company's information is fair game. It could be culled and mailed anywhere with abandon
It only takes a few minutes before alerts start to ring out on Operations consoles. Servers across the network suddenly stop responding, and then blank out completely. Grabbing on to multiple infected outside email servers with address books referencing the company, infected data packets stream in.
Once inside, the worm's first thread starts looking for other machines on the network to infect. The internal targets are easy prey. While the company had invested heavily in perimeter defenses, the internal soft center was left wide open. Production servers, test servers — all are rapidly compromised.
The second thread rifles through the company's stored messages. It is late at night so emails that users hadn't yet accessed had been piling up. All sensitive information inside those messages will soon find itself out in public by first light.
The guys in Operations stand by helplessly while the worm burrows through their network. As CPU and disk usage in each of the mail servers maxes out, the worm prepares for its finale. After compromising each server and sending all its data out onto the Internet, a self-destruct command within the worm activates, deleting all stored information and mutilating each infected machine as thoroughly as if it had been hit by a grenade.
Protect Yourself
While the attack just described is hypothetical, it could easily be real — all too real. The Slammer virus, for instance, could have been much worse with just a little extra code added to it. It was, relatively speaking, a benign beast. We may not be so lucky next time.
Attacks that exploit common technologies, such as web and email servers, won't be stopped by firewalls. How can a company react to this class of attack?
Monitor, monitor, and monitor. If Operations only finds out about an attack when an email server crashes, it's too late. Use real-time monitoring tools to analyze data from IDS (intrusion detection systems) and firewalls in real-time to give the best warning of a new attack.
Secondly, protect your core assets. Consider modifying processes based on the potential threat posed by a vulnerability, and make sure that core machines are always at the highest practical level of protection. That way the potential damage inflicted by an attack that gets through (and there always will be some attacks that get through) is greatly reduced.
Also remember to isolate infected systems. If the infected system is the Internet instead of an internal server, figure out when to cut the cord to prevent further damage to the organization.
And don't throw out your firewall. It can be useful. It's simply not the be all and end all of a secured network. Enable operators to shut down outbound or internal traffic on common ports if that's what it takes.
Another thing to think about is correlating and suppressing alarms. When a massive worm like the one described in the story above appears, the operations team could get swamped with thousands of similar alerts. Real-time correlation and security event management systems will link and escalate similar events, creating a few 'master' alerts. This reduces information overload during crises and clearly identifies the root cause of the attacks. Any organization with more than five to 10 firewalls and IDS should consider a security event correlation solution.
[url=\"http://networking.earthweb.com/netsecur/article.php/3112281\"]source[/url]
November 21, 2003
By Phil Hollows
Third shift at the Network Operations center is a quiet time, well suited for the engineer types who understand and speak the language of machines.
Let's take a look at what could easily happen on any given 'third shift' at any company, in any industry, around the country.
Traffic in the wee hours of the morning is sparse, and the night thus far has passed uneventfully. Administrators joke with each other and share the usual gripes about work. Tonight's concern focuses on a new software vulnerability found in an email program used by the company's worldwide offices. This means that in the near future the technicians will have to exhaustively test and set another code patch into the system. But for now, all is well and the skeleton IT crew feels fairly safe.
And for good reason.
The company has invested heavily in IT security. The latest firewalls and intrusion detection systems are keeping the network's perimeter secure, and IT managers will discuss new threats and the email patch roll-out during Monday's staff meeting. A good plan will have to be developed to tackle that task. Merely applying an untested patch to the critical email servers is a risk the IT staff can't afford. They know because they've been burnt too many times before.
Normally, these concerns would pass as the shift grinds on, but tonight the issue with the messaging servers gnaws at them.
The firewalls were programmed to let all email traffic through and that leaves a wide gap in their defenses. Email is essential to the company's business and attacking it could, in theory, reach every server in the company.
Just as the IT crew is mulling over the email problem while working on their nightly duties, a hacker somewhere in Eastern Europe hits 'Enter' and releases a new worm into the wild. The mass-mailing worm spreads quickly, doubling the number of infected machines every 10 seconds. Unlike Slammer, a worm that simply replicated itself, this worm's payload is much more devastating.
A simple yet elegant piece of code, the multi-threaded worm is able to execute multiple tasks in parallel — a devastating double threat that first looks for targets to infect while, at the same time, examining stored messages on infected machines. This second threat could identify external email addresses and forward all stored messages from the infected server to anyone and everyone.
Nothing is safe.
Sensitive intellectual property could be made public and mailed to competitors; product plans, account information, and customer interactions could be exposed; and state and federal disclosure and securities and privacy statues could be violated. All of the company's information is fair game. It could be culled and mailed anywhere with abandon
It only takes a few minutes before alerts start to ring out on Operations consoles. Servers across the network suddenly stop responding, and then blank out completely. Grabbing on to multiple infected outside email servers with address books referencing the company, infected data packets stream in.
Once inside, the worm's first thread starts looking for other machines on the network to infect. The internal targets are easy prey. While the company had invested heavily in perimeter defenses, the internal soft center was left wide open. Production servers, test servers — all are rapidly compromised.
The second thread rifles through the company's stored messages. It is late at night so emails that users hadn't yet accessed had been piling up. All sensitive information inside those messages will soon find itself out in public by first light.
The guys in Operations stand by helplessly while the worm burrows through their network. As CPU and disk usage in each of the mail servers maxes out, the worm prepares for its finale. After compromising each server and sending all its data out onto the Internet, a self-destruct command within the worm activates, deleting all stored information and mutilating each infected machine as thoroughly as if it had been hit by a grenade.
Protect Yourself
While the attack just described is hypothetical, it could easily be real — all too real. The Slammer virus, for instance, could have been much worse with just a little extra code added to it. It was, relatively speaking, a benign beast. We may not be so lucky next time.
Attacks that exploit common technologies, such as web and email servers, won't be stopped by firewalls. How can a company react to this class of attack?
Monitor, monitor, and monitor. If Operations only finds out about an attack when an email server crashes, it's too late. Use real-time monitoring tools to analyze data from IDS (intrusion detection systems) and firewalls in real-time to give the best warning of a new attack.
Secondly, protect your core assets. Consider modifying processes based on the potential threat posed by a vulnerability, and make sure that core machines are always at the highest practical level of protection. That way the potential damage inflicted by an attack that gets through (and there always will be some attacks that get through) is greatly reduced.
Also remember to isolate infected systems. If the infected system is the Internet instead of an internal server, figure out when to cut the cord to prevent further damage to the organization.
And don't throw out your firewall. It can be useful. It's simply not the be all and end all of a secured network. Enable operators to shut down outbound or internal traffic on common ports if that's what it takes.
Another thing to think about is correlating and suppressing alarms. When a massive worm like the one described in the story above appears, the operations team could get swamped with thousands of similar alerts. Real-time correlation and security event management systems will link and escalate similar events, creating a few 'master' alerts. This reduces information overload during crises and clearly identifies the root cause of the attacks. Any organization with more than five to 10 firewalls and IDS should consider a security event correlation solution.
[url=\"http://networking.earthweb.com/netsecur/article.php/3112281\"]source[/url]
[color=\"#41211C\"]It takes years to build up trust and only seconds to destroy it
[/color]
DDoS Attacks~For Future Reference
Loads more articles & references:
[url=\"http://networking.earthweb.com/netsecur/\"]http://networking.earthweb.com/netsecur/[/url]
[url=\"http://networking.earthweb.com/netsecur/\"]http://networking.earthweb.com/netsecur/[/url]
[color=\"#41211C\"]It takes years to build up trust and only seconds to destroy it
[/color]
DDoS Attacks~For Future Reference
Distribute This Denial of Service Checklist
August 9, 2004
By Paul Rubens
A distributed denial of service (DDoS) attack on your corporate Web site can be a terrifying thing. First traffic levels start rising, then your network gets clogged. Before long your servers stop coping, and within a few minutes your customers find your Web site is unreachable. As far as the Internet is concerned, your company has ceased to exist.
The important thing to realize about DDoS attacks is that they aren't going to go away, and there's no way of preventing them. They have been around for a very long time, and they are getting easier to carry out. That's because there are increasing numbers of poorly secured home PCs with always-on Internet connections just waiting to be discovered and taken over by hackers. These compromised PCs are incorporated into attack networks, where they remain dormant until a short burst of command and control traffic activates them and turns them into crazed attack zombies, firing off data at a target host until -- the hacker hopes -- it disappears under a deluge of unwanted packets.
As a responsible network administrator, it's prudent to assume that if it hasn't faced one yet it's only a matter of time before your organization faces a DDoS attack. This could be orchestrated by some mindless teenaged cretin, or, as a number of gambling sites have discovered, by more sinister underworld blackmailers. Whoever it happens to be, the important question is what can you do to mitigate the damage it could cause?
Getting to Know Your Net
"As with any disaster, the key to surviving a DDoS attack is planning ahead," says Allen Householder, Internet security analyst at US-CERT, a partnership between the Department of Homeland Security and the public and private sectors established to protect the nation's Internet infrastructure.
An important first step is to familiarize yourself with your typical inbound traffic profile, Householder advises. "The more you know about what your normal traffic looks like the better the position you are in to spot when its profile changes," he says. "Most DDoS attacks start as sharp spikes in traffic, but if you can't tell the difference between a flash crowd of legitimate visitors and the start of a DDoS attack you are already in trouble." There are plenty of network tools on the market which enable you to look at traffic flows and protocols, and if you can see the traffic going across your network you can analyze it and see if it changes.
Bandwidth is also worth considering. The principal of a DDoS attack is that your entire system becomes overwhelmed by too much traffic, and the smaller the pipe into your organization the easier it will be to overwhelm it. "Having excess capacity is always a good thing," says Householder. "But we have witnessed attacks that have taken down the largest portals, so you are never going to have enough capacity to handle all circumstances."
And having a monstrous amount of bandwidth available is only any use if your servers can handle the requests fired at them. It's wise to over-provision to cope with peaks in expected demand, and you may design your infrastructure to cope with traffic which is, say, 50 or 100 per cent higher than normal levels. But during a DDoS attack traffic may jump to a thousand times the normal levels, and who can afford to have a thousand times the resources normally required held in reserve in case of a DDoS attack? Even then, there would be no guarantee that would be enough.
The Managed Hosting Option
It's possible to make the case that Web sites stand the best chance of surviving a DDoS attack if the servers are sited in a large managed hosting facility. That's because there's likely to be very large amounts of bandwidth, servers and other network infrastructure available -- far more than is required for your site alone. During an attack it would be far easier to commit some of these resources to supporting your Web presence.
"A DDoS attack overwhelms your network infrastructure, and the smaller that is, the easier it is to overwhelm it, says Paul Froutan, VP of Engineering at San Antonio, Texas-based managed hosting company Rackspace. "At our facilities we have gigs of connectivity and big switches, so we are less likely to be overwhelmed," he says.
Of course big bandwidth means that instead of overwhelming your network connection, a DDoS attack just overwhelms the next weak link: your servers. Hosting companies like Rackspace also use -- and share the cost of -- DDoS mitigation devices such as Cisco Guard. These spot traffic anomalies to help detect DDoS attacks, and then divert traffic destined to a site under attack, enabling it to be filtered so that legitimate traffic is passed through while attack traffic is rejected. In practice up to 90 percent of unwanted traffic can be stopped using mitigation devices, Froutan says, giving your Web presence a good chance of remaining visible to most, if not all, Internet users. Of course there is nothing to stop your organization from buying its own mitigation device, but clearly there are economies of scale to be had when a hosting facility owns and manages one for all its customers together. Engineers at a hosting facility are also likely to face DDoS attacks more regularly than those at a single organization, so the speed of response is likely to be quicker.
Grin and Bear It? Or Step Out of the Way?
There are other measures that can be taken to mitigate the effect of an attack, and some of these are very simple. You could rate limit your router to prevent your Web server being overwhelmed -- some legitimate traffic would get through, which is better than no traffic at all. You could simply take your Web server offline for the duration of the attack, although some would argue that by doing this you are effectively doing the DDoS attacker's work for him, by ensuring the attack successfully makes your server unreachable.
And there are steps you can take if you are well enough prepared. For example, you can seek help from your upstream provider -- but only if you know who to contact and how to contact them.
So which of these measures should you take to mitigate the damage a DDoS attack could cause? Each organization is different, and it's really up to you to run your own cost-benefit analysis before deciding. One thing is for sure though: Ignoring the very real threat of DDoS attack is likely to cost your organization dearly, both in monetary terms and in the reputation you have with your customers.
[url=\"http://networking.earthweb.com/netsecur/article.php/3392361\"]source[/url]
August 9, 2004
By Paul Rubens
A distributed denial of service (DDoS) attack on your corporate Web site can be a terrifying thing. First traffic levels start rising, then your network gets clogged. Before long your servers stop coping, and within a few minutes your customers find your Web site is unreachable. As far as the Internet is concerned, your company has ceased to exist.
The important thing to realize about DDoS attacks is that they aren't going to go away, and there's no way of preventing them. They have been around for a very long time, and they are getting easier to carry out. That's because there are increasing numbers of poorly secured home PCs with always-on Internet connections just waiting to be discovered and taken over by hackers. These compromised PCs are incorporated into attack networks, where they remain dormant until a short burst of command and control traffic activates them and turns them into crazed attack zombies, firing off data at a target host until -- the hacker hopes -- it disappears under a deluge of unwanted packets.
As a responsible network administrator, it's prudent to assume that if it hasn't faced one yet it's only a matter of time before your organization faces a DDoS attack. This could be orchestrated by some mindless teenaged cretin, or, as a number of gambling sites have discovered, by more sinister underworld blackmailers. Whoever it happens to be, the important question is what can you do to mitigate the damage it could cause?
Getting to Know Your Net
"As with any disaster, the key to surviving a DDoS attack is planning ahead," says Allen Householder, Internet security analyst at US-CERT, a partnership between the Department of Homeland Security and the public and private sectors established to protect the nation's Internet infrastructure.
An important first step is to familiarize yourself with your typical inbound traffic profile, Householder advises. "The more you know about what your normal traffic looks like the better the position you are in to spot when its profile changes," he says. "Most DDoS attacks start as sharp spikes in traffic, but if you can't tell the difference between a flash crowd of legitimate visitors and the start of a DDoS attack you are already in trouble." There are plenty of network tools on the market which enable you to look at traffic flows and protocols, and if you can see the traffic going across your network you can analyze it and see if it changes.
Bandwidth is also worth considering. The principal of a DDoS attack is that your entire system becomes overwhelmed by too much traffic, and the smaller the pipe into your organization the easier it will be to overwhelm it. "Having excess capacity is always a good thing," says Householder. "But we have witnessed attacks that have taken down the largest portals, so you are never going to have enough capacity to handle all circumstances."
And having a monstrous amount of bandwidth available is only any use if your servers can handle the requests fired at them. It's wise to over-provision to cope with peaks in expected demand, and you may design your infrastructure to cope with traffic which is, say, 50 or 100 per cent higher than normal levels. But during a DDoS attack traffic may jump to a thousand times the normal levels, and who can afford to have a thousand times the resources normally required held in reserve in case of a DDoS attack? Even then, there would be no guarantee that would be enough.
The Managed Hosting Option
It's possible to make the case that Web sites stand the best chance of surviving a DDoS attack if the servers are sited in a large managed hosting facility. That's because there's likely to be very large amounts of bandwidth, servers and other network infrastructure available -- far more than is required for your site alone. During an attack it would be far easier to commit some of these resources to supporting your Web presence.
"A DDoS attack overwhelms your network infrastructure, and the smaller that is, the easier it is to overwhelm it, says Paul Froutan, VP of Engineering at San Antonio, Texas-based managed hosting company Rackspace. "At our facilities we have gigs of connectivity and big switches, so we are less likely to be overwhelmed," he says.
Of course big bandwidth means that instead of overwhelming your network connection, a DDoS attack just overwhelms the next weak link: your servers. Hosting companies like Rackspace also use -- and share the cost of -- DDoS mitigation devices such as Cisco Guard. These spot traffic anomalies to help detect DDoS attacks, and then divert traffic destined to a site under attack, enabling it to be filtered so that legitimate traffic is passed through while attack traffic is rejected. In practice up to 90 percent of unwanted traffic can be stopped using mitigation devices, Froutan says, giving your Web presence a good chance of remaining visible to most, if not all, Internet users. Of course there is nothing to stop your organization from buying its own mitigation device, but clearly there are economies of scale to be had when a hosting facility owns and manages one for all its customers together. Engineers at a hosting facility are also likely to face DDoS attacks more regularly than those at a single organization, so the speed of response is likely to be quicker.
Grin and Bear It? Or Step Out of the Way?
There are other measures that can be taken to mitigate the effect of an attack, and some of these are very simple. You could rate limit your router to prevent your Web server being overwhelmed -- some legitimate traffic would get through, which is better than no traffic at all. You could simply take your Web server offline for the duration of the attack, although some would argue that by doing this you are effectively doing the DDoS attacker's work for him, by ensuring the attack successfully makes your server unreachable.
And there are steps you can take if you are well enough prepared. For example, you can seek help from your upstream provider -- but only if you know who to contact and how to contact them.
So which of these measures should you take to mitigate the damage a DDoS attack could cause? Each organization is different, and it's really up to you to run your own cost-benefit analysis before deciding. One thing is for sure though: Ignoring the very real threat of DDoS attack is likely to cost your organization dearly, both in monetary terms and in the reputation you have with your customers.
[url=\"http://networking.earthweb.com/netsecur/article.php/3392361\"]source[/url]
[color=\"#41211C\"]It takes years to build up trust and only seconds to destroy it
[/color]
-
mobil1_oils
- Hero Member
- Posts: 1873
- Joined: Sun May 09, 2004 6:42 am
DDoS Attacks~For Future Reference
[b][color=\"gray\"][font=\"tahoma\"]A current list of bogon IP's to block.
0.0.0.0/8
1.0.0.0/8
2.0.0.0/8
5.0.0.0/8
7.0.0.0/8
10.0.0.0/8
23.0.0.0/8
27.0.0.0/8
31.0.0.0/8
36.0.0.0/8
37.0.0.0/8
39.0.0.0/8
41.0.0.0/8
42.0.0.0/8
49.0.0.0/8
50.0.0.0/8
73.0.0.0/8
74.0.0.0/8
75.0.0.0/8
76.0.0.0/8
77.0.0.0/8
78.0.0.0/8
79.0.0.0/8
89.0.0.0/8
90.0.0.0/8
91.0.0.0/8
92.0.0.0/8
93.0.0.0/8
94.0.0.0/8
95.0.0.0/8
96.0.0.0/8
97.0.0.0/8
98.0.0.0/8
99.0.0.0/8
100.0.0.0/8
101.0.0.0/8
102.0.0.0/8
103.0.0.0/8
104.0.0.0/8
105.0.0.0/8
106.0.0.0/8
107.0.0.0/8
108.0.0.0/8
109.0.0.0/8
110.0.0.0/8
111.0.0.0/8
112.0.0.0/8
113.0.0.0/8
114.0.0.0/8
115.0.0.0/8
116.0.0.0/8
117.0.0.0/8
118.0.0.0/8
119.0.0.0/8
120.0.0.0/8
121.0.0.0/8
122.0.0.0/8
123.0.0.0/8
124.0.0.0/8
125.0.0.0/8
126.0.0.0/8
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
173.0.0.0/8
174.0.0.0/8
175.0.0.0/8
176.0.0.0/8
177.0.0.0/8
178.0.0.0/8
179.0.0.0/8
180.0.0.0/8
181.0.0.0/8
182.0.0.0/8
183.0.0.0/8
184.0.0.0/8
185.0.0.0/8
186.0.0.0/8
187.0.0.0/8
189.0.0.0/8
190.0.0.0/8
192.0.2.0/24
192.168.0.0/16
197.0.0.0/8
198.18.0.0/15
223.0.0.0/8
224.0.0.0/3
[s]Sauce[/s] [url=\"http://www.cymru.com/Documents/bogon-bn-nonagg.txt\"]Source[/url][/color][/font][/b]
0.0.0.0/8
1.0.0.0/8
2.0.0.0/8
5.0.0.0/8
7.0.0.0/8
10.0.0.0/8
23.0.0.0/8
27.0.0.0/8
31.0.0.0/8
36.0.0.0/8
37.0.0.0/8
39.0.0.0/8
41.0.0.0/8
42.0.0.0/8
49.0.0.0/8
50.0.0.0/8
73.0.0.0/8
74.0.0.0/8
75.0.0.0/8
76.0.0.0/8
77.0.0.0/8
78.0.0.0/8
79.0.0.0/8
89.0.0.0/8
90.0.0.0/8
91.0.0.0/8
92.0.0.0/8
93.0.0.0/8
94.0.0.0/8
95.0.0.0/8
96.0.0.0/8
97.0.0.0/8
98.0.0.0/8
99.0.0.0/8
100.0.0.0/8
101.0.0.0/8
102.0.0.0/8
103.0.0.0/8
104.0.0.0/8
105.0.0.0/8
106.0.0.0/8
107.0.0.0/8
108.0.0.0/8
109.0.0.0/8
110.0.0.0/8
111.0.0.0/8
112.0.0.0/8
113.0.0.0/8
114.0.0.0/8
115.0.0.0/8
116.0.0.0/8
117.0.0.0/8
118.0.0.0/8
119.0.0.0/8
120.0.0.0/8
121.0.0.0/8
122.0.0.0/8
123.0.0.0/8
124.0.0.0/8
125.0.0.0/8
126.0.0.0/8
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
173.0.0.0/8
174.0.0.0/8
175.0.0.0/8
176.0.0.0/8
177.0.0.0/8
178.0.0.0/8
179.0.0.0/8
180.0.0.0/8
181.0.0.0/8
182.0.0.0/8
183.0.0.0/8
184.0.0.0/8
185.0.0.0/8
186.0.0.0/8
187.0.0.0/8
189.0.0.0/8
190.0.0.0/8
192.0.2.0/24
192.168.0.0/16
197.0.0.0/8
198.18.0.0/15
223.0.0.0/8
224.0.0.0/3
[s]Sauce[/s] [url=\"http://www.cymru.com/Documents/bogon-bn-nonagg.txt\"]Source[/url][/color][/font][/b]