Personal computing discussed
Moderators: renee, Steel, notfred
Anovoca wrote:So, I understand the principle behind what a DDOS attack is, shove enough garbage data requests at an online service's door and legitimate traffic can't find its way in. Its not too different from the old Ping of death, only these attacks use multiple systems and more beefy hardware to achieve the same effect against modern networking technology. My main question that I can't find information on is, what part of the online service's network is getting bottle-necked. Is it the firewall, the ISP's trunk or routing equipment leading into the facility, the login server/database, internal routing equipment?
Anovoca wrote:So, I understand the principle behind what a DDOS attack is, shove enough garbage data requests at an online service's door and legitimate traffic can't find its way in. It
Anovoca wrote:Its not too different from the old Ping of death
Anovoca wrote:only these attacks use multiple systems and more beefy hardware to achieve the same effect against modern networking technology.
Anovoca wrote:My main question that I can't find information on is, what part of the online service's network is getting bottle-necked. Is it the firewall, the ISP's trunk or routing equipment leading into the facility, the login server/database, internal routing equipment?
It is possible to directly attack the ISP's trunk and routing equipment (overflowing the CAM table, for instance), but with the type of equipment they use, it's harder to successfully pull off before they "blackhole" you.
Anovoca wrote:It is possible to directly attack the ISP's trunk and routing equipment (overflowing the CAM table, for instance), but with the type of equipment they use, it's harder to successfully pull off before they "blackhole" you.
I suppose there really isn't a point to doing this either since if you disrupt the communication link in a way that already authenticated users must reestablish a connection, then the surge of legit traffic attempting to re-validate at once will overwhelm the ISP trunk for you.
I guess I was trying to understand why it is so difficult to prevent. I would think that any login service that uses a local client to cache credentials could require some form of dynamically generated yet manually inputted token to even begin the handshake process. It wouldn't prevent things completely but it would require the attacker to manually intervene in the process and if successful in bringing down the network, they would have to do it again.
Anovoca wrote:True, i was more thinking in terms of authentication and connection servers being attacked. Specifically SPN, XBN, and blizzard that were being attacked this weekend. If the network is guarded by a firewall that only accepts traffic initiated via the local client launchpad, I would think they could filter the traffic using the services already in place. But my understanding of network protocols are a bit rusty so I am probably looking at this at a wrong angle.
Hz so good wrote:It is possible to directly attack the ISP's trunk and routing equipment (overflowing the CAM table, for instance), but with the type of equipment they use, it's harder to successfully pull off before they "blackhole" you.
Hz so good wrote:ISP trunks are a LOT fatter than you'd realize. I used to install aggregators in COs, and even the small ones had 100gbps backplanes. The giant switches they use can easily eclipse that speed, especially if they distribute CAM and routing table entries to secondary/tertiary cabinets. Those can accomodate terabit speeds. And that's not counting IDS/IPS systems, nor DPI used to spot, mark, and drop traffic like that.
Hz so good wrote:You can't really token-ize the TCP handshake, since that's how the protocol works by design. Even just viewing a webpage involves that handshake. That's one of the mechanisms it uses to guarantee packet delivery. If you tried to force every machine that wanted to connect to your resource to wait for a token, for it's turn to "talk", it would slow things down to a crawl anyway.
Hz so good wrote:There's a reason Token Ring fell out of favor.
Hz so good wrote:Ideally, mitigating a DDOS would involve determining the sources, then dropping their traffic as close as possible to their point of entry to the internet.
Hz so good wrote:That, or just blackhole the IP block the attack is coming from.
Anovoca wrote:If the network is guarded by a firewall that only accepts traffic initiated via the local client launchpad
Hz so good wrote:Their best bet is to have mechanisms in place to spot and drop attacks in real-time, and block them as close to the source as possible.
Anovoca wrote:I guess I was trying to understand why it is so difficult to prevent. I would think that any login service that uses a local client to cache credentials could require some form of dynamically generated yet manually inputted token to even begin the handshake process. It wouldn't prevent things completely but it would require the attacker to manually intervene in the process and if successful in bringing down the network, they would have to do it again.
Glorious wrote:...
Hz so good wrote:Yeah I totally munged that up. I blame the cold medicine I'm on.
Captain Ned wrote:Hz so good wrote:Yeah I totally munged that up. I blame the cold medicine I'm on.
Don't diss a good NyQuil buzz.