New Method to Stop DDoS Attacks

This is taken directly from the slashdot website. I thought it was very interesting.

Quote:

---

Pushback against DDOS Attacks
Posted by CmdrTaco on Sunday October 27, @08:49AM
from the build-a-better-*******-trap dept.
Huusker writes "Steven Bellovin and others at ATT Research Labs and ICIR have come up with mechanism to stop DDOS attacks. The idea is called Pushback . When the routers get flooded they consult a Unix daemon (/etc/pushbackd) to determine if they are being DDOS'ed. The routers propagate the quench packets back to the sources. The policy and propagation are separate, allowing hardware vendors to concentrate on the quench protocol while the white hats invent ever more clever DDOS detection filters for /etc/pushbackd. The authors of the paper have an initial implementation on FreeBSD."

---

I would not normally take an article from a different page, but I thought this one should be posted. I searched the forums and didn't see this one yet.

Interesting, but it will probably only work for well known attacks. What will happen when the targets of the attacks will specifically be the systems anti-DDOS?

that's just end up being a battle of Bandwidth....the end result is that the Anti-DDOS won't work.....the system will simply be out-numberd....A DDOS is meant to slow down and time-out a server or network...if that server or network then start's working overtime to push-back the information...it'll just cause even more problem's.......

There was something like this posted some time agoe...although that was about a system where the false data was simple discarded...I can't remember the exact detail's but it was a better alternative than this.....I would get you the link....but I'm too lazy.

- Noia

Didn't think about that...

Maybe create a "rule" in advance to handle said attacks to anti-DDOS preventative measures?

Have to think about it more... That could get kinda messy.

It seems like in this DDoS they are simply trying to stop the actual server or services from lagging/crashing, but like Noia said there is also the issue of Bandwith being used up in a DDoS attack, eventually(depending on who has the bigger pipe) your pipe will get full and that program wont be any good.

I highly doubt any program or mauever could stop DoS/DDoS attacks point blank. Simple as that.

I have to agree with Noia that seems to make the most sense, just drop the packets. That will leave more upstream available to send packets for legit. services, right?

I have to agree with Noia that seems to make the most sense, just drop the packets. That will leave more upstream available to send packets for legit. services, right?

Actually, it's quite possible to make ACL's under Cisco IOS 12.x to do all of this. Between bandwidth scaling, throttling, and source-quench options, it's actually already possible to knock out most of the DOS schemes out there. Of course, actually DOING this is another matter. :(

Although the new PUSHBACK scheme seems to be a bit of a better option than what's out there now, I think it is still more an IMPLEMENTATION problem than a TECHNOLOGY one. A lot of network security / network administrator types just see their role as uptime, rather than providing insurance - after all, uptime you can take to management and point at it - it's tangeable. The insurance given by good, solid security measures doesn't EVER become apparent if it's effective. And it's hard to justify this to some PHB-types.

~N~

Actually, it's quite possible to make ACL's under Cisco IOS 12.x to do all of this. Between bandwidth scaling, throttling, and source-quench options, it's actually already possible to knock out most of the DOS schemes out there. Of course, actually DOING this is another matter. :(

Although the new PUSHBACK scheme seems to be a bit of a better option than what's out there now, I think it is still more an IMPLEMENTATION problem than a TECHNOLOGY one. A lot of network security / network administrator types just see their role as uptime, rather than providing insurance - after all, uptime you can take to management and point at it - it's tangeable. The insurance given by good, solid security measures doesn't EVER become apparent if it's effective. And it's hard to justify this to some PHB-types.

~N~

I actually disagree with the comment that DDoS attacks can't be stopped. What needs to happen is there needs to be another protocol speced out by the IETF that all routers would need to adhere to. And that protocol would check a signature file, or policy rule, and send a message to the gateway that is sending the offending packets, and that gateway in turn would act out the consequences for the policy, i.e. shutting off all communications from the offending host, or limiting it in such a way that it could no longer access the target until the attack was over. This, of course, would require an upgrade for the routers, cause they would need more processing power to check the packets fast enough to not make a giant slow down. This is sort of a distributed IDS tree, and doesn't necessarily have to be limited to DDoS attacks, this could also be implemented for all sorts of malicious traffic.

Just a thought...

Regards,
Wizeman

EDIT: Also, just to let everyone know, anything that sends some sort of throttle or quench request to the offending host can be ignored if the host happens to be using a non-compliant TCP/IP stack, or if it is modified in some other fashion to ignore the requests. This is why I believe the focal point for preventing attacks of any sort should be the nearest gateway to the offender, that is not under the offender's direct control.

I actually disagree with the comment that DDoS attacks can't be stopped. What needs to happen is there needs to be another protocol speced out by the IETF that all routers would need to adhere to. And that protocol would check a signature file, or policy rule, and send a message to the gateway that is sending the offending packets, and that gateway in turn would act out the consequences for the policy, i.e. shutting off all communications from the offending host, or limiting it in such a way that it could no longer access the target until the attack was over. This, of course, would require an upgrade for the routers, cause they would need more processing power to check the packets fast enough to not make a giant slow down. This is sort of a distributed IDS tree, and doesn't necessarily have to be limited to DDoS attacks, this could also be implemented for all sorts of malicious traffic.

Just a thought...

Regards,
Wizeman

EDIT: Also, just to let everyone know, anything that sends some sort of throttle or quench request to the offending host can be ignored if the host happens to be using a non-compliant TCP/IP stack, or if it is modified in some other fashion to ignore the requests. This is why I believe the focal point for preventing attacks of any sort should be the nearest gateway to the offender, that is not under the offender's direct control.

One method that I recently learned about for defending against DDOS attacks is the concept of SYN cookies. Apparently, it's been incorporated in the linux kernel for quite some time, but it's not turned on by default because there are some who argue that the concept is in violation of the TCP/IP RFC's. Here's a website for you to read if you're interested in learning more like I was...

http://cr.yp.to/syncookies.html

One method that I recently learned about for defending against DDOS attacks is the concept of SYN cookies. Apparently, it's been incorporated in the linux kernel for quite some time, but it's not turned on by default because there are some who argue that the concept is in violation of the TCP/IP RFC's. Here's a website for you to read if you're interested in learning more like I was...

http://cr.yp.to/syncookies.html

Quote:

---

Originally posted here by NeoAcid5000
I highly doubt any program or mauever could stop DoS/DDoS attacks point blank. Simple as that.

---

Really? I do it every day. Its as simple as 1 2 3.

1. Packet Capture/Mirror
2. Determine Source.
3. Block source at backbone/router level.

Of course there is alot in between that. Hmmmm..... maybe I should write a tutorial about it....
I think I will.

Quote:

---

Originally posted here by NeoAcid5000
I highly doubt any program or mauever could stop DoS/DDoS attacks point blank. Simple as that.

---

Really? I do it every day. Its as simple as 1 2 3.

1. Packet Capture/Mirror
2. Determine Source.
3. Block source at backbone/router level.

Of course there is alot in between that. Hmmmm..... maybe I should write a tutorial about it....
I think I will.

"Actually, it's quite possible to make ACL's under Cisco IOS 12.x to do all of this. Between bandwidth scaling, throttling, and source-quench options, it's actually already possible to knock out most of the DOS schemes out there. Of course, actually DOING this is another matter." - nietzsche

nietzsche would you explain this to me, would these ACL features be under standard, extended..etc. Or both maybe. Ive not gotten that far with ACLs yet, that explains my lack of knowledge.

Actually Dr has it right, DDos depends upon networks and connects thing is now days even a dot edu seperates students from staff and faculity and most ISP more now monitor the bandwidth both ways. Good signature of a DDos is the leg or IP range they are on because most target dot edu, mil or gov systems, shutting off progressive legs of a sub net is not hard with the firewalls we have now, ban UUNET you bet, think I'd blink an eye if I was hit by to many packets from AT&T IP range nope. One does what one must to keep people productive and working. Yes this will work after all your system or backbone is blocked enough from bad traffic then it will hurt profits and well telecomm is not a hot area right now they all jumped on and did not know they also offered bandwidth to the bad guys. Fact is the network traffic now days is monitored beyond what I even ever thought it would be 10 years ago.