1. There are three generally agreed-upon planes, not two - control, management, and data.
2. The described methodology isn't novel. Observing the effects of attacks is something attackers do routinely, as is attack selectivity in order to garner maximum impact. This goes back a couple of decades with regards to DDoS attacks in particular.
3. Routers will continue to forward and process priority 6/7 traffic - i.e., control-plane traffic like BGP - whilst dropping enough data-plane traffic to ensure sufficient link bandwidth & RP/LC CPU overhead to keep routing sessions up and process routing updates. This undercuts the central thesis of the paper.
4. Re-marking all priority 6/7 traffic at the edge is a best current practice (BCP) for network operators; this prevents attackers from sending floods of priority 6/7 traffic in order to force punts.
5. iACLs and GTSM, two more BCPs, protect BGP sessions against direct attack via SYN-flooding, et. al.
6. Control-plane policing (CoPP) is yet another BCP which indirectly limits the number of updates/sec via rate-limiting control-plane traffic exchanged between routers.
So, the assertions of novelty in the paper aren't really justified, nor are all the assumptions and assertions regarding the way routers work and the way they handle control-plane traffic. Also, standard BCPs to protect control-plane traffic aren't taken into account. Nor are routine defensive BCPs discussed and taken into account.
Finally, there are other mechanisms which are considerably more effective in disrupting control-plane communication due to high RP CPU which aren't touched upon in the paper, nor are they cited in references. Though there are defenses against those attack mechanisms, as well, they aren't as well-known.
It's generally a good idea for researchers to consult with members of the global operational security (opsec) community while looking for topics and methodologies which are truly unique. This saves a lot of time and effort in duplicating existing work and going down paths which don't lead to truly novel research and results.
It's also a good idea for researchers investigating routing resilience to launch real attacks (in a lab environment) on real routers, rather than just theorizing and simulating, in order to gain an understanding of how they actually behave under attack, and how the various BCPs and other defensive mechanisms come into play.
This.pdf presentation may be of interest, as well.
You're right that the article doesn't delve into the technical specifics - but the report the article is describing, available via this link provides more details.
The essence of the issue is that DDoS attacks are attacks against capacity and/or state. Even the largest firewalls commercially available or that one can build have limited state-table sizes.
Placing stateful firewalls in front of client access networks makes sense - when your Web browser requests the TCP/IP stack on your client device to set up a three-way TCP handshake with example.com, there's an outgoing SYN request which traverses the stateful firewall, and the stateful firewall makes a note of this in its state table. When the SYN-ACK response comes back from the example.com server, the stateful firewall checks to see if there's a corresponding outbound request and that the incoming response conforms with the firewall policies - if the answers to both questions is 'yes', then the firewall passes the server response packets. If the answer to either question is 'no', the stateful firewall drops the inappropriate server response.
When we're talking about Web servers, DNS servers, et. al., however, basically every incoming request is unsolicited - therefore, there is no state to inspect. This is why it makes zero sense to put a stateful firewall in front of servers.
Instead, the server OS and apps (Apache, BIND, sendmail, whatever) should be hardened, tcpwrappers should be deployed on the server to provide onboard stateless policy filtering, and stateless Access Control Lists (ACLs) should be implemented on your hardware-based routers and/or layer-3 switches in order to enforce network access policy - e.g., allow TCP/80 and TCP/443 for a standard SSL-enabled Web server, allow UDP/53 and TCP/53 for a DNS server, etc., and then disallow anything else from the outside.
Here's a.pdf presentation from a recent NANOG conference which makes the same point.
When stateful firewalls are used to enforce these polices which ought to be enforced by stateless ACLs per the above, the state-table limitations of even the largest firewalls form a significant DDoS chokepoint. Attackers can craft well-formed attack traffic which will conform to the firewall rules, but which will 'crowd out' legitimate requests from users, and which in many cases causes an error condition on the stateful firewall which causes it to stop forwarding packets altogether. This leads to a DoS of the firewall itself and all the servers behind it.
I've seen this over and over and over again, even with very large firewalls. It's far easier to DoS the largest firewall in existence than it is to DoS well-tuned, hardened server TCP/IP stacks.
Servers should be protected from DDoS attacks via source-based remotely-triggered blackholes (S/RTBH), flowspec, and/or intelligent DDoS mitigation systems (IDMS) specifically designed for this application.
Load-balancers are also a DDoS state vector, but in many environments are a necessary evil. When they must be used (note that there are many ways to achieve clustering/load-balancing without making use of single-point load-balancers), they must be protected by the same stateless ACLs in terms of enforcing network access policy, and must furthermore be protected from DDoS by S/RTBH, flowspec, and/or IDMS.
'Application-layer firewalls', with their 'protocol inspectors', and so-called 'IPSes' are even worse. They carry even more state, and the protocol inspectors offer a broadened attack surface for exploitation and device compromise (you can find numerous examples of publicly-acknowledge buffer overflows, etc. which comprise security vulnerabilities in the inspectors of both commercial and open-source firewalls and 'IPSes'). Consequently, they fall over during even a moderate DDoS attack even more qui
Yes, but the thing is, *we know how to do all that*, we've done it before. Far better and easier and cheaper, IMHO, than this Ares nonsense with SRBs ready to kill the crew during launch.
Hell, we could take the Saturn Vs lying on the ground (3-4) of them, the unflown CMs and LMs lying around, and refurbish them, for starters!
What's maddening is that nobody involved in this debate seems to realize that:
1. We solved resonance and pogoing issues in the 1960s vis-a-vis the Saturn V stack.
2. We can simply dust off the Apollo 18-20 J-series mission plans and the Apollo X/ALSS/AES/LESA studies, and execute them.
3. All we need to actually get back to the Moon is a Saturn V stack updated with newer materials and automation technologies.
4. SRBs are insanely dangerous due to their non-throttalability, and should not be man-rated beyond the poorly-designed Shuttle stack.
We knew all this *more than 40 years ago* (we ignored the SRB issue back then, which led directly to Challenger); how can these people be so ignorant?!
Here's a link to just a few of the studies which were done of follow-on missions. Here are links to Apollo X, ALSS, AES, and LESA.
Stephen Baxter's Voyage is an interesting alternate history based upon some of these mission plans (although he's way too hard on the Germans, IMHO).
The bottom line - if NASA want to go back to the Moon (far better to offer a $20B X-Prize for the first organization to put 30 men on the Moon for a year and a day, and return them safely to Earth), all they have to do is to start building modernized Saturn Vs, Apollo CMs, SMs, & LMs.
Doesn't use signatures, doesn't produce false positives. Combine anomaly-detection technology with an information source like NetFlow, and you have a scalable and flexible detection system.
>It makes wearing a tinfoil hat look like locking your front door when you go out for the day.
For your information I wear my tinfoil had and lock my door and wash my hands when I go out for the day - although I try to go out as little as possible, it must be noted.
the idiots at Apple, completely unheedful and unmindful of prior art and experience - this is especially true of security-related matters - are going about slowly ensuring that OS/X will end up just as full of security holes and vulnerabilities as Windows.
This is sad; I love my PowerBook, I love OS/X, I'm a *NIX switcher (i.e., not an Apple person, but a *NIX person who switched from Linux to the Mac in order to get the benefits of FreeBSD along with all the goodness of Apple's hardware and multimedia capabilities, not to mention Office).
Someone needs to whack Jobs over the head and get him to focus his people on security, or the Mac will end up being as full of malware as Windows, solely because Apple programmers are doing stupid things which undermine the solid security foundation of FreeBSD which OS/X was built upon, but which can be bypassed by doing stupid things with the GUI/APIs layered atop it.
I support funding for fusion research, solar power satellites, and research to get us onto a hydrogen-based economy. I want us to get away from fossil-fuels.
I disagree. Greenland used to be green, and then became cold and icy, prior to the invention of the internal combustion engine and the emisison of 'greenhouse gasses' by human-constructed factories and such.
Or, what if human beings are making a difference, and we're really staving off an ice age.
Or what if global warming is happening, and whether or not we have anything to do with it, we'd see increased crop-yields and all the benefits thereof for the needy and starving of the world?
We don't have enough data, and the scientists are too busy with political posturing and grubbing for grant-money to sit down and do actual science. And when you look at the economic impact of something like the Kyoto Treaty, it becomes apparent that we need to be damned sure, one way or another, before we start making huge policy change which might well prove iatrogenic.
We're talking potentially about the future of the species - we need to get this right. We also need to get into space and start colonizing so that all our eggs aren't in one basket, we need to invest in fusion research and solar-power satellites, and all sorts of things, instead of making pronouncements without a truly scientific basis for doing so.
There's no actual consensus on 'global warming' is in fact happening, and if it is, whether or not human activity has anything to do with it. Remember, 25 years ago these same folks were howling about 'global cooling', that should tell you something.
Insteead, there seems to be largely a grab for grant money and political power, as opposed to real science - this article for an example of the phenomenon.
We just don't know, and instead of concentrating on actual science, political agendas and feeding at the public trough have become the priorities. This is far too important an issue to rush to judgment on, IMHO.
They ought to have out-of-band (OOB )serial-console access to their servers via a terminal server for any number of reasons, including this one; if they'd implemented OOB console access, they could've sshed into the terminal server, gotten onto the consoles of the servers in question, and used ifconfig to fix the duplex issue.
Why they don't seem to grasp this is beyond me . . . anyone running a public-facing, high-volume service should have OOB access to all servers, routers, switches, firewalls, etc. . . . it's just common sense.
Slashdot Mirror
Or a recent iPad in a waterproof case?
They're waterproof enough for what you describe.
What's the application, anyways?
-----
1. There are three generally agreed-upon planes, not two - control, management, and data.
2. The described methodology isn't novel. Observing the effects of attacks is something attackers do routinely, as is attack selectivity in order to garner maximum impact. This goes back a couple of decades with regards to DDoS attacks in particular.
3. Routers will continue to forward and process priority 6/7 traffic - i.e., control-plane traffic like BGP - whilst dropping enough data-plane traffic to ensure sufficient link bandwidth & RP/LC CPU overhead to keep routing sessions up and process routing updates. This undercuts the central thesis of the paper.
4. Re-marking all priority 6/7 traffic at the edge is a best current practice (BCP) for network operators; this prevents attackers from sending floods of priority 6/7 traffic in order to force punts.
5. iACLs and GTSM, two more BCPs, protect BGP sessions against direct attack via SYN-flooding, et. al.
6. Control-plane policing (CoPP) is yet another BCP which indirectly limits the number of updates/sec via rate-limiting control-plane traffic exchanged between routers.
So, the assertions of novelty in the paper aren't really justified, nor are all the assumptions and assertions regarding the way routers work and the way they handle control-plane traffic. Also, standard BCPs to protect control-plane traffic aren't taken into account. Nor are routine defensive BCPs discussed and taken into account.
Finally, there are other mechanisms which are considerably more effective in disrupting control-plane communication due to high RP CPU which aren't touched upon in the paper, nor are they cited in references. Though there are defenses against those attack mechanisms, as well, they aren't as well-known.
It's generally a good idea for researchers to consult with members of the global operational security (opsec) community while looking for topics and methodologies which are truly unique. This saves a lot of time and effort in duplicating existing work and going down paths which don't lead to truly novel research and results.
It's also a good idea for researchers investigating routing resilience to launch real attacks (in a lab environment) on real routers, rather than just theorizing and simulating, in order to gain an understanding of how they actually behave under attack, and how the various BCPs and other defensive mechanisms come into play.
This .pdf presentation may be of interest, as well.
You're right that the article doesn't delve into the technical specifics - but the report the article is describing, available via this link provides more details.
The essence of the issue is that DDoS attacks are attacks against capacity and/or state. Even the largest firewalls commercially available or that one can build have limited state-table sizes.
Placing stateful firewalls in front of client access networks makes sense - when your Web browser requests the TCP/IP stack on your client device to set up a three-way TCP handshake with example.com, there's an outgoing SYN request which traverses the stateful firewall, and the stateful firewall makes a note of this in its state table. When the SYN-ACK response comes back from the example.com server, the stateful firewall checks to see if there's a corresponding outbound request and that the incoming response conforms with the firewall policies - if the answers to both questions is 'yes', then the firewall passes the server response packets. If the answer to either question is 'no', the stateful firewall drops the inappropriate server response.
When we're talking about Web servers, DNS servers, et. al., however, basically every incoming request is unsolicited - therefore, there is no state to inspect. This is why it makes zero sense to put a stateful firewall in front of servers.
Instead, the server OS and apps (Apache, BIND, sendmail, whatever) should be hardened, tcpwrappers should be deployed on the server to provide onboard stateless policy filtering, and stateless Access Control Lists (ACLs) should be implemented on your hardware-based routers and/or layer-3 switches in order to enforce network access policy - e.g., allow TCP/80 and TCP/443 for a standard SSL-enabled Web server, allow UDP/53 and TCP/53 for a DNS server, etc., and then disallow anything else from the outside.
Here's a .pdf presentation from a recent NANOG conference which makes the same point.
When stateful firewalls are used to enforce these polices which ought to be enforced by stateless ACLs per the above, the state-table limitations of even the largest firewalls form a significant DDoS chokepoint. Attackers can craft well-formed attack traffic which will conform to the firewall rules, but which will 'crowd out' legitimate requests from users, and which in many cases causes an error condition on the stateful firewall which causes it to stop forwarding packets altogether. This leads to a DoS of the firewall itself and all the servers behind it.
I've seen this over and over and over again, even with very large firewalls. It's far easier to DoS the largest firewall in existence than it is to DoS well-tuned, hardened server TCP/IP stacks.
Servers should be protected from DDoS attacks via source-based remotely-triggered blackholes (S/RTBH), flowspec, and/or intelligent DDoS mitigation systems (IDMS) specifically designed for this application.
Load-balancers are also a DDoS state vector, but in many environments are a necessary evil. When they must be used (note that there are many ways to achieve clustering/load-balancing without making use of single-point load-balancers), they must be protected by the same stateless ACLs in terms of enforcing network access policy, and must furthermore be protected from DDoS by S/RTBH, flowspec, and/or IDMS.
'Application-layer firewalls', with their 'protocol inspectors', and so-called 'IPSes' are even worse. They carry even more state, and the protocol inspectors offer a broadened attack surface for exploitation and device compromise (you can find numerous examples of publicly-acknowledge buffer overflows, etc. which comprise security vulnerabilities in the inspectors of both commercial and open-source firewalls and 'IPSes'). Consequently, they fall over during even a moderate DDoS attack even more qui
Next thing you know, he'll be posting about the lulz on 4chan & his Facebook page. ;>
> Guess why Ron Paul ran for the Republicans? Because he knew that as a third party/independent he wouldn't even get on the ballets
You have to admit, the thought of Ron Paul en pointe in tights is a pretty powerful argument for censorship, in and of itself.
Yes, but the thing is, *we know how to do all that*, we've done it before. Far better and easier and cheaper, IMHO, than this Ares nonsense with SRBs ready to kill the crew during launch.
Hell, we could take the Saturn Vs lying on the ground (3-4) of them, the unflown CMs and LMs lying around, and refurbish them, for starters!
What's maddening is that nobody involved in this debate seems to realize that:
1. We solved resonance and pogoing issues in the 1960s vis-a-vis the Saturn V stack.
2. We can simply dust off the Apollo 18-20 J-series mission plans and the Apollo X/ALSS/AES/LESA studies, and execute them.
3. All we need to actually get back to the Moon is a Saturn V stack updated with newer materials and automation technologies.
4. SRBs are insanely dangerous due to their non-throttalability, and should not be man-rated beyond the poorly-designed Shuttle stack.
We knew all this *more than 40 years ago* (we ignored the SRB issue back then, which led directly to Challenger); how can these people be so ignorant?!
Here's a link to just a few of the studies which were done of follow-on missions. Here are links to Apollo X, ALSS, AES, and LESA.
Stephen Baxter's Voyage is an interesting alternate history based upon some of these mission plans (although he's way too hard on the Germans, IMHO).
The bottom line - if NASA want to go back to the Moon (far better to offer a $20B X-Prize for the first organization to put 30 men on the Moon for a year and a day, and return them safely to Earth), all they have to do is to start building modernized Saturn Vs, Apollo CMs, SMs, & LMs.
That way, I can have fun buying rounds at the bar whilst railing against my stupid managers, even stupid users, etc.
according to SANS.
Check it out.
It'd be worth it just to never see another post from such an arrogant, pompus ass.
Check here.
Doesn't use signatures, doesn't produce false positives. Combine anomaly-detection technology with an information source like NetFlow, and you have a scalable and flexible detection system.
for automated publish/subscribe models because it's an actual standard.
What's wrong with electrified nipple-clamps?!
>It makes wearing a tinfoil hat look like locking your front door when you go out for the day.
For your information I wear my tinfoil had and lock my door and wash my hands when I go out for the day - although I try to go out as little as possible, it must be noted.
Am I alone in this?
Here's what the MOL might've looked like . . .
Start here.
the idiots at Apple, completely unheedful and unmindful of prior art and experience - this is especially true of security-related matters - are going about slowly ensuring that OS/X will end up just as full of security holes and vulnerabilities as Windows.
This is sad; I love my PowerBook, I love OS/X, I'm a *NIX switcher (i.e., not an Apple person, but a *NIX person who switched from Linux to the Mac in order to get the benefits of FreeBSD along with all the goodness of Apple's hardware and multimedia capabilities, not to mention Office).
Someone needs to whack Jobs over the head and get him to focus his people on security, or the Mac will end up being as full of malware as Windows, solely because Apple programmers are doing stupid things which undermine the solid security foundation of FreeBSD which OS/X was built upon, but which can be bypassed by doing stupid things with the GUI/APIs layered atop it.
The Boston U solution.
And the UConn approach.
I support funding for fusion research, solar power satellites, and research to get us onto a hydrogen-based economy. I want us to get away from fossil-fuels.
I disagree. Greenland used to be green, and then became cold and icy, prior to the invention of the internal combustion engine and the emisison of 'greenhouse gasses' by human-constructed factories and such.
Or, what if human beings are making a difference, and we're really staving off an ice age.
Or what if global warming is happening, and whether or not we have anything to do with it, we'd see increased crop-yields and all the benefits thereof for the needy and starving of the world?
We don't have enough data, and the scientists are too busy with political posturing and grubbing for grant-money to sit down and do actual science. And when you look at the economic impact of something like the Kyoto Treaty, it becomes apparent that we need to be damned sure, one way or another, before we start making huge policy change which might well prove iatrogenic.
We're talking potentially about the future of the species - we need to get this right. We also need to get into space and start colonizing so that all our eggs aren't in one basket, we need to invest in fusion research and solar-power satellites, and all sorts of things, instead of making pronouncements without a truly scientific basis for doing so.
There's no actual consensus on 'global warming' is in fact happening, and if it is, whether or not human activity has anything to do with it. Remember, 25 years ago these same folks were howling about 'global cooling', that should tell you something.
Insteead, there seems to be largely a grab for grant money and political power, as opposed to real science - this article for an example of the phenomenon.
We just don't know, and instead of concentrating on actual science, political agendas and feeding at the public trough have become the priorities. This is far too important an issue to rush to judgment on, IMHO.
More details here.
They ought to have out-of-band (OOB )serial-console access to their servers via a terminal server for any number of reasons, including this one; if they'd implemented OOB console access, they could've sshed into the terminal server, gotten onto the consoles of the servers in question, and used ifconfig to fix the duplex issue.
Why they don't seem to grasp this is beyond me . . . anyone running a public-facing, high-volume service should have OOB access to all servers, routers, switches, firewalls, etc. . . . it's just common sense.