Re: Effective ways to deal with DDoS attacks?
On Sun, 5 May 2002, Christopher L. Morrow wrote: like with single homed customers. The only time when those sets of prefixes is NOT the same is for a backup connection. But if a connection Not always the case, customer behaviour can not be accurately modeled. I was hoping someone else might mention this, BUT what about the case of customers providing transit for outbound but not inbound traffic for their customers? We have many, many cases of customers that are 'default routing' for their customers that get inbound traffic down alternate customers or peers or wherever... Is there a compelling reason you should allow this? If yes, you can't use uRPF and you have to install an acl to do sanity checking on the customer's source addresses. If no, they'll have to announce those routes to you. If they set the no export community they still won't get any inbound traffic to speak of. uRPF seems like a not so good solution for these instances :( especially since some of these are our worst abusers :( Well if these are your worst abusers, it seems to me uRPF is exactly what those customers need. ;-)
Re: Effective ways to deal with DDoS attacks?
At 03:34 AM 5/05/2002 +, Christopher L. Morrow wrote: I was hoping someone else might mention this, BUT what about the case of customers providing transit for outbound but not inbound traffic for their customers? two methods: [1] if your customer has their own AS, have them route the (valid) networks to you with the no-export bgp attribute set. [2] if they're not BGP connected, then surely you have some idea of what subnet(s) they're sending traffic out from? (i hope so). if so, then you'd have static-routes for those subnets pointing at their interface. you don't necessarily have to include those static-routes in announcements to your peers. both of [1] [2] may mean that more traffic may 'prefer' the link from you to the customer. (probably doubly so given you're uunet and the amount of transit that goes thru you). in that case, perhaps using the no-advertise community so that the route stays 'local' to a router (or local to a city) will prove sufficient. cheers, lincoln.
Re: anybody else been spammed by no-ip.com yet?
On Sat, 4 May 2002, Forrest W. Christian wrote: Anyone who thinks that government can pass a law and this will go away is hopelessly naieve. The spammers will go overseas. Besides, if you look The spammers already use non-US machines in various ways to disguise their (still predominately) US origin. been reported to the razor. rbldns lists are effective only against the worst offenders, as the rest don't get reported until it is too late. and so on. Hrm, I'm thinking that the focus is slightly off (ie, rejection doesn't have to occur solely at the message delivery stage); assuming that you had custom software, you could conceiveably get a real time feed of spam/open relays/other criteria and periodically check your mail that-you-have-received-but-not-yet-read against any new updates to further get rid of more spam. If you've got a few million subscribers who would be further annoyed at spam/your abuse desk in receiving spam, this would possibly be productive. I think the only other methods I can think of are best described as some sort of web of trust type method. These are essentially whitelist systems. In order to send me mail you have to *do* something. How long before mailing list exploders are forced to only accept pgp-signed/encrypted mail from its subscribers, and re-pgp-sign/encrypt it when sending to subscribers ? --==-- Bruce.
Re: anybody else been spammed by no-ip.com yet?
The only way to catch and stop spammers is with horsepower and proactive mail policies. Sendmail is capable of being configured in a rigid manner and filters put in place, the problem is that most system hacks are not capable enough to manage the overhead of enforcing a filtration rule on each piece of mail because of the complexity. What's needed is a turn-key solution really. Non of us want to have to play with email gateways and reception agents if we don't have to (well ok, so its only most of us...). For instance, we got a boatload of bad email last week locally at one of the local SF Bay Area University's I do work with, and our entire email gateway was shutdown dealing with actively filtering 3000 emails that had a contaminated attachment. The problem with email filters is that they are not smart. The cant tell you when they see 5 pieces of email that all have a bad return or source address/name and that have a contaminated attachment, that all came from the same place that they should create and manage their own little blacklist file... I also suggest that running sendmail on a single host is a mistake or any mail system for that matter. I have ours setup on a reception agent system which timestamps and logs all the email into a queue. The queue has a stand-alone engine that qualifies each piece of email and checks any attachments for evilness. Each stage also sends a response to the sender acknowledging receipt if Receipts are requested and the whole system works pretty well. The whole system cost less than 15K to put in place and is essentially 5 different computers all of which happen to be implemented on a SBC we have so the entire system fits into a single PCI based computer's footprint. If anyone is interested in the exact setup - email me offlist and we can continue this conversation. Todd Glassey, CTO ServerWerks Inc. http://www.serverwerks.cc - Original Message - From: [EMAIL PROTECTED] To: Forrest W. Christian [EMAIL PROTECTED] Cc: Eric A. Hall [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, May 04, 2002 4:33 PM Subject: Re: anybody else been spammed by no-ip.com yet? On Sat, 4 May 2002, Forrest W. Christian wrote: We're trying to discourage bulk emailers, not individuals. Then the way to do this is to make the cost of sending mass mail more expensive than sending only a few here and there. In short, we need a way to prevent the use of the $19.95 throw-away account that is used to send the vast majority of spam. Let's face it, only the biggest of the hardcore spammers are willing to pay out for dedicated lines. How about something along the lines of dial accounts having their outgoing SMTP connections rate limited to, oh, let's say 100 per day, and limiting the maximum number of recipients on any given email to some low number, say 5? A customer reaches the limit, the account auto-rejects all email for 24 hours. Someone bitches? Let them buy full rate dedicated services, with the first month, last month, and a security deposit up front before service is established. -- Yours, J.A. Terranson [EMAIL PROTECTED] If Governments really want us to behave like civilized human beings, they should give serious consideration towards setting a better example: Ruling by force, rather than consensus; the unrestrained application of unjust laws (which the victim-populations were never allowed input on in the first place); the State policy of justice only for the rich and elected; the intentional abuse and occassionally destruction of entire populations merely to distract an already apathetic and numb electorate... This type of demogoguery must surely wipe out the fascist United States as surely as it wiped out the fascist Union of Soviet Socialist Republics. The views expressed here are mine, and NOT those of my employers, associates, or others. Besides, if it *were* the opinion of all of those people, I doubt there would be a problem to bitch about in the first place...
Re: anybody else been spammed by no-ip.com yet?
There will be a day when folks will need to pay to transit email (Paul Vixie, 1998). Still working on that better mouse trap? well, other than that i wish i could charge _you_ for the spam i get that's due to the several MAILTO:[EMAIL PROTECTED]'s on your www.dotcomeon.com site, no. it's not my mouse of choice.
Re: Per message costs of email (was: Re: anybody else been spammed by no-ip.com yet?)
In a message written on Sat, May 04, 2002 at 04:36:40PM -0400, Scott A Crosby wrote: So far, other than Jared Mauch [EMAIL PROTECTED]'s calculation where he neither confirmed nor disputed $.02/email, I've yet to see *one* quantified per-message price bandied about.. It doesn't matter. I will suggest that as long as the cost of e-mail advertisements is cheaper than the cost of snail mail advertisements you will get more e-mail advertisements than snail mail ones. Even at $0.18/message (or whatever the bulk rate is these days), plus the cost of paper, printers, machines/people to stuff envelops I still get 2-3 unwanted physical ads in my snail mail box every day. Even if spammers had to pay $0.05, $0.02, $0.0002, or whatever the cost is determined to be you will get spam. Lots of spam. In fact, if the spammers did have to pay it would eliminate the 'theft of resources' argument, and I bet spam would triple as more business consider it a legal and ethical way of doing business. Sadly, I don't see the virtual world working any better than the real world. The only real difference at the moment is the type of products being sold. In the end there will be a mechanism to make spam legal. It may be micro-payments, it may be something else; but business will find a way to do it. Then your spam will change from Viagra and Live Girls to Get your Capitol 1 No Hassel Card and Publishers Clearinghouse wants to award you $1 Million! Maybe that wouldn't be so bad, the spam would be less offensive. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
RE: Effective ways to deal with DDoS attacks?
Be mindful that uRPF Strict Mode was created to help scale BCP 38 filtering. If you have 1000 lease line customers and can use uRFP Strict Mode on 80% of those customers, that is 80% fewer BCP38 ACLs that you need to manage. For the other 20% you have uRFP + BGP tweaks or plain old ACLs. But as Chris inferred, that 20% where you cannot use simple uRPF is also the 20% most difficult customers. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Iljitsch van Beijnum Sent: Sunday, May 05, 2002 12:44 AM To: Christopher L. Morrow Cc: [EMAIL PROTECTED] Subject: Re: Effective ways to deal with DDoS attacks? On Sun, 5 May 2002, Christopher L. Morrow wrote: like with single homed customers. The only time when those sets of prefixes is NOT the same is for a backup connection. But if a connection Not always the case, customer behaviour can not be accurately modeled. I was hoping someone else might mention this, BUT what about the case of customers providing transit for outbound but not inbound traffic for their customers? We have many, many cases of customers that are 'default routing' for their customers that get inbound traffic down alternate customers or peers or wherever... Is there a compelling reason you should allow this? If yes, you can't use uRPF and you have to install an acl to do sanity checking on the customer's source addresses. If no, they'll have to announce those routes to you. If they set the no export community they still won't get any inbound traffic to speak of. uRPF seems like a not so good solution for these instances :( especially since some of these are our worst abusers :( Well if these are your worst abusers, it seems to me uRPF is exactly what those customers need. ;-)
Re: uRPF Loose Check Mode vs. ACL
On Sun, May 05, 2002 at 11:55:21AM -0700, Livio Ricciulli wrote: In particular, I am interested in the ability of eliminating specific routes from the FIB under uRPF Loose Check Mode to effectively filter specific source addresses that are flooding. As I understand the concept, eliminating an address from the FIB such as x.y.0.0/24 would have the equivalent effect of installing a network-wide ACL rule: deny ip x.y.0.0/24 any Not quite. First, lets be specific by what you mean by remove from the FIB, as there are a number of different methods you could use. You could simply block it from the RIB when generating the FIB, you could go back after FIB generation and try to make it unresolved, or you could change the nexthop to discard. If you're trying to replicate traditional firewall behavior (filter no matter what) you would have to do it post FIB generation, but if you are trying to replicate normal routing behavior (ex: a null route) you would have to do it during FIB generation, so that you can potentially have more specific routes which escape the filter. Secondly, when you remove something from your FIB, you also block destination routing as well as source. The reason why I ask is that we would like to keep control of these two important aspects of the traffic to avoid filtering out too much and therefore possibly affecting legitimate traffic. Think of the case where a flood targets one of multiple downstream customers and the spoofed addresses correspond to a popular address range (such as Yahoo). Doing a deny ip x.y.0.0/24 any would effectively shut down Yahoo's traffic for all downstream customers thus amplifying the attacker's effect. It sounds like what you are looking for has nothing to do with the RPF or the FIB, but rather simply manual source address filtering. However, if the reason you're interested in RPF is because you want to source match filtering more efficiently, you may be interested in the data structure. Rather then walking a straight access-list rule set doing a comparison for every rule, you can make a Filtering Information Base mtrie for source address rules. This is the entire point of standard access-lists, and more recently compiled access-lists. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: uRPF Loose Check Mode vs. ACL
Richard A Steenbergen wrote: On Sun, May 05, 2002 at 11:55:21AM -0700, Livio Ricciulli wrote: In particular, I am interested in the ability of eliminating specific routes from the FIB under uRPF Loose Check Mode to effectively filter specific source addresses that are flooding. As I understand the concept, eliminating an address from the FIB such as x.y.0.0/24 would have the equivalent effect of installing a network-wide ACL rule: deny ip x.y.0.0/24 any Not quite. First, lets be specific by what you mean by remove from the FIB, as there are a number of different methods you could use. You could simply block it from the RIB when generating the FIB, you could go back after FIB generation and try to make it unresolved, or you could change the nexthop to discard. If you're trying to replicate traditional firewall behavior (filter no matter what) you would have to do it post FIB generation, but if you are trying to replicate normal routing behavior (ex: a null route) you would have to do it during FIB generation, so that you can potentially have more specific routes which escape the filter. escaping the filter with more specific routes would be absolutely necessary. Secondly, when you remove something from your FIB, you also block destination routing as well as source. Good point; so in ACL equivalent language you are saying that taking out a FIB entry in uRPF Loose Check Mode is equivalent to a network-wide insertion of: deny ip x.y.0.0/24 any (from the uRPF Loose Check Mode) deny ip any x.y.0.0/24 (from the absence of a route) (modulo the more specific routes to escape the filter which could be expressed as prepended permits in the ACL equivalent world) The reason why I ask is that we would like to keep control of these two important aspects of the traffic to avoid filtering out too much and therefore possibly affecting legitimate traffic. Think of the case where a flood targets one of multiple downstream customers and the spoofed addresses correspond to a popular address range (such as Yahoo). Doing a deny ip x.y.0.0/24 any would effectively shut down Yahoo's traffic for all downstream customers thus amplifying the attacker's effect. It sounds like what you are looking for has nothing to do with the RPF or the FIB, but rather simply manual source address filtering. Well, I am investigating if it is possible today to use uRPF Loose Check Mode to achieve network-wide source/destination address filtering functionality (it seems not from what you write). I immagine that it would be useful to use route advertisements to enforce network-wide access control policies. These policies, however, to be generally interesting for DDoS would have to be at least as expressive as deny|permit proto source destination (hence my questions). Livio.
Re: e-postage yet again, was anybody else been spammed by no-ip.com yet?
On Sun, 05 May 2002 18:15:15 EDT, Nathan J. Mehl [EMAIL PROTECTED] said: people that this had happened to? I'd file a class-action liability suit against Microsoft for selling a defective product that lost my clients thousands of dollars. I suspect I'd have a good chance of winning, too. EULA. Computer software is unique in that not only are the producers not held liable for defects, but quite often manage to avoid any of the usual suitability for purpose requirements - there is a presumption that (for instance) a toaster is supposed to be able to actually toast a piece of bread - and that therefore any toaster that is unable to do so is inherently defective *and it's the vendor's problem to make it right*, whether via replacement, repair, or refund. Quite often, vendors of software manage to disclaim even the requirement that a word processor be able to process text, etc.
Re: e-postage yet again, was anybody else been spammed by no-ip.com yet?
In the immortal words of [EMAIL PROTECTED] ([EMAIL PROTECTED]): On Sun, 05 May 2002 18:15:15 EDT, Nathan J. Mehl [EMAIL PROTECTED] said: people that this had happened to? I'd file a class-action liability suit against Microsoft for selling a defective product that lost my clients thousands of dollars. I suspect I'd have a good chance of winning, too. EULA. Absent the passage of an SPCCA-esque Federal law, the enforceability of EULAs in the face of actual, quantifiable financial damage is untested at best, farcical at worst. This is, of course, entirely non-operational in content, so I'd like to take this moment to remind the list of the presence of: [EMAIL PROTECTED] Send email to [EMAIL PROTECTED] to be added to the list. Only you can prevent endless non-operational digressions on [EMAIL PROTECTED]! -n -[EMAIL PROTECTED] I used to think that the brain was the most wonderful organ in my body. Then I realized who was telling me this. (--Emo Phillips) http://blank.org/memory/-
Re: IP renumbering timeframe
Well how am I supposed to arrange a payment on a Sunday afternoon? As well I'd say I've already paid them more than enough to use their IPs - I never brought up a BGP session with them and never passed a single packet to them. I'm surprised to hear that such extortion techniques are considered acceptable. somehow, i suspect that we're hearing only one side of a, quite likely messy and unhappy, story. and i doubt it all happened on a sunny sunday afternoon. randy
Re: IP renumbering timeframe
Well how am I supposed to arrange a payment on a Sunday afternoon? As well I'd say I've already paid them more than enough to use their IPs - I never brought up a BGP session with them and never passed a single packet to them. I'm surprised to hear that such extortion techniques are considered acceptable. somehow, i suspect that we're hearing only one side of a, quite likely messy and unhappy, story. and i doubt it all happened on a sunny sunday afternoon. That's why I can't believe Cogent actually did this. 14:46 eastern, May 2 my Cogent rep Scott Elrod emailed me indicating there would be no resolution to the dispute, and to contact him should I wish to have Cogent service in the future. Since then we received *NO* contact from Cogent. I first heard that Cogent was expecting an immediate renumbering from the /22 was when I got an email from Peer1 (as I was watching Montreal beat Carolina). -Ralph
