Just a thought - strict RPF at all ingress points, in combination with Fair Queueing keyed on something like 24 high-order bits of source IP address in transit routers would render any high-rate flooding attack pretty much harmless. --vadim
Vadim, Vadim Antonov wrote:
Just a thought - strict RPF at all ingress points, in combination with Fair Queueing keyed on something like 24 high-order bits of source IP address in transit routers would render any high-rate flooding attack pretty much harmless.
If you are talking FQ, as the source addresses are usually forged and thus random, don't you want to key on the *destination* address? Or are you only aiming at reflected attacks? Fair Queuing is useful in this manner not only on interconnect with other providers (transit / peering / customers so multihomed to be difficult to RPF) but also perhaps on interfaces connected to customers. Not all attacks are forged source. Attacks with true source addresses from comprimized servers would be mitigated by the fair queuing you describe on the router interface. One minor problem here is that Fair Queuing (as I understand it) only drops packets if the egress interface to which it is applied gets full. So *my* applying fair queuing to all interfaces at an exchange point doesn't help me if X's MAE-East router is squirting and extra 50Mb/s of traffic at me, enough to fill my port, but not X's - this is true also evn if *everyone* at the IXP applies FQ. So alternative is CEF/CAR like behaviour which would limit (not queue) traffic to any particular IP address within one given rate-limit matching clause to a specific rate. It's dead easy to make exceptions to this for specific IPs. I'm sure getting people to deploy this universally will be just as easy as persuading them to deploy ingress filtering universally and turning off directed broadcast universally (cough cough). -- Alex Bligh VP Core Network, Concentric Network Corporation (formerly GX Networks, Xara Networks)
I'm not sure if this is news or not, but looking at http://www.fbi.gov/nipc/trinoo.htm - it seems the NIPC has released binaries, (no source code, the jerks), for tools to detect if a box has trin00, tribal flood net, tfn2k and some other DDoSD's on it. So far they have a sparc solaris, intel solaris, and x86 linux binary for download. While I am shocked to see a government agency writing potentially usefull code so quickly, I am dissappointed they didn't release their source code so it can be ported to say.. FreeBSD? .. AIX .. HP/UX ... and so on... Rodney Caston Southwestern Bell Internet Services
I don't care where it purports to be from, for this kind of code, I will not trust something [to not be a trojan] that I can not compile myself. This policy applies to SSH, SSL, and other security related code. I am sure that I am not the only one with this policy.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Rodney Caston Sent: Thursday, February 10, 2000 8:45 AM To: nanog@merit.edu Subject: FBI / NIPC released a DDoSD detection tool?
I'm not sure if this is news or not, but looking at http://www.fbi.gov/nipc/trinoo.htm - it seems the NIPC has released binaries, (no source code, the jerks), for tools to detect if a box has trin00, tribal flood net, tfn2k and some other DDoSD's on it.
So far they have a sparc solaris, intel solaris, and x86 linux binary for download. While I am shocked to see a government agency writing potentially usefull code so quickly, I am dissappointed they didn't release their source code so it can be ported to say.. FreeBSD? .. AIX .. HP/UX ... and so on...
Rodney Caston Southwestern Bell Internet Services
Especially considering it ended up sucking all of the memory on my machine before dying with a bus error and taking half of the processes with it. Oh, the irony ;-) -rt -- Ryan Tucker <rtucker@netacc.net> Unix Systems Administrator NetAccess, Inc. Phone: +1 716 756-5596 3495 Winton Place, Building E, Suite 265, Rochester NY 14623 www.netacc.net On Thu, 10 Feb 2000, Roeland M.J. Meyer wrote:
I don't care where it purports to be from, for this kind of code, I will not trust something [to not be a trojan] that I can not compile myself. This policy applies to SSH, SSL, and other security related code. I am sure that I am not the only one with this policy.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Rodney Caston Sent: Thursday, February 10, 2000 8:45 AM To: nanog@merit.edu Subject: FBI / NIPC released a DDoSD detection tool?
I'm not sure if this is news or not, but looking at http://www.fbi.gov/nipc/trinoo.htm - it seems the NIPC has released binaries, (no source code, the jerks), for tools to detect if a box has trin00, tribal flood net, tfn2k and some other DDoSD's on it.
So far they have a sparc solaris, intel solaris, and x86 linux binary for download. While I am shocked to see a government agency writing potentially usefull code so quickly, I am dissappointed they didn't release their source code so it can be ported to say.. FreeBSD? .. AIX .. HP/UX ... and so on...
Rodney Caston Southwestern Bell Internet Services
On Thu, 10 Feb 2000, Ryan Tucker wrote:
Especially considering it ended up sucking all of the memory on my machine before dying with a bus error and taking half of the processes with it.
Oh, the irony ;-) -rt
Gawd. I'm more likely to run bins from we-now-own-you.evil.com than from ANY .gov site!
On Thu, 10 Feb 2000, NANOG Mailing List wrote:
Gawd. I'm more likely to run bins from we-now-own-you.evil.com than from ANY .gov site!
With the bare minimum of doing a tripwire update before and after (particulary, in our case, of anything from a mod.uk site) -- Patrick Evans - Sysadmin, bran addict and couch potato pre at pre dot org www.pre.org/pre
'twould appear that the sources are available at Dave Dittrich's place: http://www.washington.edu/People/dad/ See the gag and ddos links. -ls- Patrick Evans <pre@pre.org> wrote:
On Thu, 10 Feb 2000, NANOG Mailing List wrote:
Gawd. I'm more likely to run bins from we-now-own-you.evil.com than from ANY .gov site!
With the bare minimum of doing a tripwire update before and after (particulary, in our case, of anything from a mod.uk site)
-- Patrick Evans - Sysadmin, bran addict and couch potato pre at pre dot org www.pre.org/pre
Roeland M.J. Meyer has declared that:
I don't care where it purports to be from, for this kind of code, I will not trust something [to not be a trojan] that I can not compile myself. This policy applies to SSH, SSL, and other security related code. I am sure that I am not the only one with this policy.
The NIPC admitted that to me. You are not the only one by a long shot. I contacted the NIPC site, and sent email to the nicpc contact asking about source, explaining the above concerns to them. Their response was they were valid concerns, but they basically didnt care. NO SOURCE. "Trust us". Hard to do knowing they are pushing for the legal right to install trojans or backdoors on peoples computers w/o warrant or the persons knowlege or permission - no way I would put anything on running as root on any system I control. Sad state of affairs, but I feel a prudent approach, given the attitude of some agencies these days. So, I responded that when they changed their policy and started regarding the admins expected to rely on this as an ally in the effort to solve these abuse problems, please let me know, we (where I work) would be glad to participate. Until then, however, thanks but no thanks. I will muddle along using other methods. As such I am looking for open-src tools for finding and smoking out these rogue daemons from other sources. Thanks Pat M/HW -- #include <std.disclaimer.h> Pat Myrto (pat at rwing dot ORG) Seattle WA "On a more encouraging note, I have yet to see anything suggesting the Internet is a threat to the mining industry. Our key assets are ore bodies and its hard to see virtual ore bodies taking over." -- Market analist Jack Jones
On Thu, 10 Feb 2000, Pat Myrto wrote:
As such I am looking for open-src tools for finding and smoking out these rogue daemons from other sources.
Saw this in a bulletin from our upstream: "Dave Dittrich's page (which includes a a stacheldraht agent scanner (C source code) and a a trinoo/stacheldraht agent scanner (C source code) - http://www.washington.edu/People/dad/" Haven't built/played yet. Charles
Thanks Pat M/HW
Also check out: http://packetstorm.securify.com/ In addition to detectors, it has what purports to be the stacheldrahtV4 source. -Declan At 14:00 2/10/2000 -0500, Charles Sprickman wrote:
"Dave Dittrich's page (which includes a a stacheldraht agent scanner (C source code) and a a trinoo/stacheldraht agent scanner (C source code) - http://www.washington.edu/People/dad/"
On Thu, 10 Feb 2000, Pat Myrto wrote:
Roeland M.J. Meyer has declared that:
I don't care where it purports to be from, for this kind of code, I will not trust something [to not be a trojan] that I can not compile myself. This policy applies to SSH, SSL, and other security related code. I am sure that I am not the only one with this policy.
The NIPC admitted that to me. You are not the only one by a long shot.
I contacted the NIPC site, and sent email to the nicpc contact asking about source, explaining the above concerns to them. Their response was they were valid concerns, but they basically didnt care. NO SOURCE. "Trust us". [SNIP] Until then, however, thanks but no thanks. I will muddle along using other methods.
As such I am looking for open-src tools for finding and smoking out these rogue daemons from other sources.
Did people not read where I posted links to info and scanners for the known DDoS daemons? I know I'm vocal, and occasionally irrational, but I like to think I have a few good pieces of information to share now and again. http://www.washington.edu/People/dad/, scroll down to Papers / Articles / Reports, and look at the fifth and sixth entries. "gag -- a stacheldraht agent scanner (C source code) by Dave Dittrich, Marcus Ranum, and others. dds -- a trinoo/TFN/stacheldraht agent scanner (C source code) by Dave Dittrich, Marcus Ranum, George Weaver, David Brumley, and others. [In BETA testing.]" These are links to source tarballs. -- Joseph W. Shaw - jshaw@insync.net Computer Security Consultant and Programmer Free UNIX advocate - "I hack, therefore I am."
On Thu, Feb 10, 2000 at 10:44:35AM -0600, Rodney Caston wrote:
I'm not sure if this is news or not, but looking at http://www.fbi.gov/nipc/trinoo.htm - it seems the NIPC has released binaries, (no source code, the jerks), for tools to detect if a box has trin00, tribal flood net, tfn2k and some other DDoSD's on it.
So far they have a sparc solaris, intel solaris, and x86 linux binary for download. While I am shocked to see a government agency writing potentially usefull code so quickly, I am dissappointed they didn't release their source code so it can be ported to say.. FreeBSD? .. AIX .. HP/UX ... and so on...
There is also code available that sends a kill message to the individual nodes attacking you upon reception of the attack for the original versions of trinoo (the non-spoofed or spoofed with the last octet only udp flood version). Unfortunantly I havn't had a chance to look at the src for any of the newer flood programs, if someone would be so kind as to forward me a copy perhaps there are some more easily exploitable ways to use their poorly designed distributed programs against them, or if nothing else at least write a scanner with freely distributable source. -- Richard A. Steenbergen <ras@above.net> http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) MFN / AboveNet Communications Inc - ISX Network Engineer, Vienna VA
participants (13)
-
Alex Bligh -
Charles Sprickman -
Declan McCullagh -
Joe Shaw -
Larry Snyder -
NANOG Mailing List -
Pat Myrto -
Patrick Evans -
Richard Steenbergen -
Rodney Caston -
Roeland M.J. Meyer -
Ryan Tucker -
Vadim Antonov