To report a botnet PRIVATELY please email: [EMAIL PROTECTED] ---------- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jonathan Yarden wrote: > To report a botnet PRIVATELY please email: [EMAIL PROTECTED] > ---------- >>> http://www.infiltrated.net/?p=29 > > Although this seems to be yet another conspiracy theorist hard at work, > there are some interesting issues raised. Not the least of which is why is > it that network equipment manufacturers are still doing static rule-based > access control when clearly a distributed approach could be easily done? > After all, what is an RBL but a DNS-based distributed access list? > Carrier grade routers are designed to route (or switch in the case of MPLS) packets at line-rate. When you start applying ACLs, the performance hit is not trivial - especially when you've got interfaces doing 1-Mpps+ under *normal* load. It is for this reason that most high-tier providers (read: those with clue) typically use divert routing to ship traffic that needs "special attention" via a dedicated mitigation path where it is dropped or scrubbed. There are products out there that can do wire-speed scrubbing but *THEY ARE NOT ROUTERS* but rather purpose-built devices. The Arbor TMS is one such device. I'm sure that "sil" is going to pipe up and say, "Well, if they can do this, why aren't they doing it and if they are doing it, why are they charging the CUSTOMER to clean up THEIR mess?!" Go look and see how much a TMS costs. Now, consider a "medium" sided provider with a backbone that covers about 25 states. How many TMS devices does that provider need to deploy? How much extra capacity does that provider need to deploy on their network to be able to divert traffic to the "closest" TMS? Who is it that these devices are being deployed to protect? I'll answer the last question. They're deployed to protect the CUSTOMER. If the customer wants to enjoy the benefits of having their inbound 900Mb/s @ 800Kpps attack mitigated by the provider so the customer can still surf via their fractional DS1, the customer needs to pony up some money because the provider still has to carry that 900Mb/s of traffic to the scrubbing devices. It would be far easier for me to simply null-route the victim (customer) IP address and redistribute that blackhole via an RFC1998 implementation to all of my peers to keep the attack traffic off of my network completely. That takes the customer out though and they don't want that. I wasn't the one who went out and started talking smack on IRC and invited Joe Botherder to "take his best shot" at me. It was my misguided customer. This notion that it is the responsibility of the providers to protect their customers is analogous to the two of us walking into a bar and you thinking that just because I'm a Marine that you can go pick the biggest, baddest mofo in the bar and pick a fight with him and it will be my job to fight him *for you*... I hate to tell you but, if that happend, I would drive you to the hospital and tell the triage nurse, "My buddy wrote a check with his mouth that his body couldn't cash. He's all yours now." If you got blood on the interior of my car in the process, I'd make you pay for it. > Granted, while I don't work for a transit carrier and manage a mere OC-3 > worth of data to a few thousand end-users, it would be nice to have an > IP-granular "kill-switch" system that I could use to signal an upstream > router to stop sending data from a network or ASN because it's causing me > problems. I can do it already at the host level with a system I fudged > together, but the data still comes into my network before I can drop it. > It exists. It's been around for quite some time. uRPF + RFC1998 And a newer concept: http://tools.ietf.org/id/draft-marques-idr-flow-spec-04.txt ~john -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFG9Ct9+16lRpJszIgRAnNgAJwNClG9GR+v/5fi5teq1FuN3tnLdACggb6g kS1aFK1hQlA3XJHnZKvBhZw= =Itto -----END PGP SIGNATURE----- _______________________________________________ To report a botnet PRIVATELY please email: [EMAIL PROTECTED] All list and server information are public and available to law enforcement upon request. http://www.whitestar.linuxbox.org/mailman/listinfo/botnets
