Re: Weird distributed spam attack
2) uses an attack algorithm to distribute the load so you only see any given source IP every other day Yep. My list of attacking IP's was several thousand deep before I gave up. Back when I used to analyze dialup spammers (well over a year ago) I felt that a large part of the spam problem could be traced back to just a handful of very prolific abusers. Some were professionals, with 4 to 8 phone lines at home, others seemed to be mixing their home and work phone access. One(?) person laundered all his calls through 800-number accessible switchboards (hotels and resorts). I still think pursuing just these heavy hitters could pay off big for everyone. For a short time at least. If you want to try some simple analysis on your own: - once you have a spammer's userid and caller ID, pull every record for that userid and caller ID. This will give you several new userids and phone numbers. Pull all of those too, and keep repeating until nothing new pops out. Search all of your logs, for as far back as possible. Watch out for mixed case and trailing spaces. - every few iterations, use a round of reverse number lookups at anywho.com, and the address and name lookups at infospace.com to expand your phone numbers. - if any of the numbers trace back to businesses, knock off (wild card) the last one or two digits of the phone numbers and search again. - Google any distinctive (personal?) userids. (obNanog: I doubt many other groups' members have access to the needed records)
Re: Weird distributed spam attack
On Wed, Nov 20, 2002 at 09:40:50AM -0800, Joe St Sauver wrote: In addition to thousands of open relays, which are bad enough in their own right, there are also thousands of open proxy servers which a growing number of spammers have been using to launch spam runs lately. I suspect that's what you're seeing. I agree--that's a strong possibility. This week, I released a tool to test open proxies. http://www.unicom.com/sw/pxytest [I will also say that it would really be great if mail-abuse.org would add an open proxy listing project to complement their RSS, DUL, and other initiatives.] I believe RBL will list open proxies. Another good resource is the Blitzed Open Proxy Monitor (BOPM) http://www.blitzed.org/bopm/. -- Chip Rosenthal * [EMAIL PROTECTED] * http://www.unicom.com/ Lawsuit Update: I Win, Domain Hijackers Lose * http://save.unicom.com/
Re: Weird distributed spam attack
Unless, I missed the posts about this,.. I just (and still am experiencing) a distributed spam attack. We get these almost continually Yep... same here. it is incredibly depressing to look at the logs. Backup-only MX here see upwards of 10K messages on bad days, mostly attacks of that type. yep same here... before we ducked for cover (see below) I could grep 800 megs of just REJECTED out of our maillog file (two per day). Very depressing. To make it even more depressing we were only getting harvested on about two dozen of the several thousand domains we run MX for. Some of the domains chosen for the attack are ridiculous (are 4 valid addresses really worth that effort?). Well, they don't know that until the dictionary the domain do they? Sigh. I have come to the conclusion that distributed dictionary attacks will eventually get the goods. Sure you can reject by pattern match on ainet.us for this case, but that's not going to help when someone with a large network of spambots sets up a job that: 1) uses completely random from addresses, subject lines and message content Correct. That is exactly what we have seen. 2) uses an attack algorithm to distribute the load so you only see any given source IP every other day Yep. My list of attacking IP's was several thousand deep before I gave up. I suspect that this type of attack is currently ongoing, underneath the obvious noise of the cruder tools. yes. We started seeing it (moderate volume) in July of this year. By August it was equal to regular client traffic. By early-October is was kneecapping our mailservers. Managing the ignore list started to become a full-time job, so we surrendered and started using an external blocking service. (see below) Before that we tried filtering at the router(s) and maintaining ignore lists on the servers, but it broke all sorts of things you *want* to have happen with secondary mail servers, especially the ones we have off-site. The only solution I see for the service provider is to recommend their subscribers choose long, complicated usernames not likely to be found in a dictionary. That doesn't do *anything* to stop the attack, it just hides the user from being harvested (easily.) It managed to find a couple of my weird addresses though, so while you can run, you can't hide forever. If anyone has better thoughts as to defense for the above scenario, I would love to hear it. We have been offering Postini http://www.postini.com spam virus filtering to our clients since May. They offer a service that detects, and blocks/ignores the originating harvest spambots. They call it ActiveEMS... we tried it on our own domain (one of the first targeted) and we saw it drop like a rock. So we made it mandatory for our clients now... they can opt-out of the filtering, but we still hide our mailservers behind theirs, even if our client opts out. That way, the client's *domain* stays protected, but they can read all the spams their hearts desire. It *still* does some wonky stuff with secondaries, so I might have to buy (grumble) their services as secondary MX spooling. I used to believe that running a catchall alias was an effective deterrent until the b*st*rds started sending complete spams and not just RCPT TO. In fact, in this scenario the catch-all is like pouring gasoline on the fire without some giant water tank on the roof to... oh, wait... wrong thread. Sorry. The only clients we haven't moved to Postini are those with catch-all addresses. Those break under Postini... well, they don't really break accept the bank, as clients get charged per-address. We are spreading clues as much as we can to discourage catch-alls. I hope to have all but the completely entrenched converted by year-end. Then we just have to wait until they get harvested... then they'll change their mind. We have one client, who owns close to 50 domains... all with a catch-all going to his *one* address. He went from getting maybe 30 spams a week to several hundred a day... just because a single domain was harvested by these attacks. The only alternative I see is a blacklist populated by some type of distributed detection system... if enough of us under attack contributed 550 unknown user logs, there should be an easily definable threshold for human error. Interesting alternative... the hard part is making it work. How does it face the spambots, but still not refuse actual legit mail traffic coming into your primary MX? What is the threshold where it recognizes an attack from the normal traffic and start feeding the BS to the Bots? I have about 4 gigs of 550 logs to contribute. Mike -- With all the spam I get, maybe mlewinski isn't such a bad idea for username after all. heh. Totally OT, but a nice bonus with Postini was re-acquainting myself with somebody I knew from a Network Manager's user group (ANMA) I was in back in the early 90's. The salesdroid
RE: Weird distributed spam attack
We just recently started using GatewayDefender's Business service. So far, I've only received about 1 or 2 spam a day -- down from nearly 40-60. Not bad in my estimation. (http://www.gatewaydefender.com) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of chuck goolsbee Sent: Wednesday, November 20, 2002 4:16 AM To: [EMAIL PROTECTED] Subject: Re: Weird distributed spam attack Unless, I missed the posts about this,.. I just (and still am experiencing) a distributed spam attack. We get these almost continually Yep... same here. it is incredibly depressing to look at the logs. Backup-only MX here see upwards of 10K messages on bad days, mostly attacks of that type. yep same here... before we ducked for cover (see below) I could grep 800 megs of just REJECTED out of our maillog file (two per day). Very depressing. To make it even more depressing we were only getting harvested on about two dozen of the several thousand domains we run MX for. Some of the domains chosen for the attack are ridiculous (are 4 valid addresses really worth that effort?). Well, they don't know that until the dictionary the domain do they? Sigh. I have come to the conclusion that distributed dictionary attacks will eventually get the goods. Sure you can reject by pattern match on ainet.us for this case, but that's not going to help when someone with a large network of spambots sets up a job that: 1) uses completely random from addresses, subject lines and message content Correct. That is exactly what we have seen. 2) uses an attack algorithm to distribute the load so you only see any given source IP every other day Yep. My list of attacking IP's was several thousand deep before I gave up. I suspect that this type of attack is currently ongoing, underneath the obvious noise of the cruder tools. yes. We started seeing it (moderate volume) in July of this year. By August it was equal to regular client traffic. By early-October is was kneecapping our mailservers. Managing the ignore list started to become a full-time job, so we surrendered and started using an external blocking service. (see below) Before that we tried filtering at the router(s) and maintaining ignore lists on the servers, but it broke all sorts of things you *want* to have happen with secondary mail servers, especially the ones we have off-site. The only solution I see for the service provider is to recommend their subscribers choose long, complicated usernames not likely to be found in a dictionary. That doesn't do *anything* to stop the attack, it just hides the user from being harvested (easily.) It managed to find a couple of my weird addresses though, so while you can run, you can't hide forever. If anyone has better thoughts as to defense for the above scenario, I would love to hear it. We have been offering Postini http://www.postini.com spam virus filtering to our clients since May. They offer a service that detects, and blocks/ignores the originating harvest spambots. They call it ActiveEMS... we tried it on our own domain (one of the first targeted) and we saw it drop like a rock. So we made it mandatory for our clients now... they can opt-out of the filtering, but we still hide our mailservers behind theirs, even if our client opts out. That way, the client's *domain* stays protected, but they can read all the spams their hearts desire. It *still* does some wonky stuff with secondaries, so I might have to buy (grumble) their services as secondary MX spooling. I used to believe that running a catchall alias was an effective deterrent until the b*st*rds started sending complete spams and not just RCPT TO. In fact, in this scenario the catch-all is like pouring gasoline on the fire without some giant water tank on the roof to... oh, wait... wrong thread. Sorry. The only clients we haven't moved to Postini are those with catch-all addresses. Those break under Postini... well, they don't really break accept the bank, as clients get charged per-address. We are spreading clues as much as we can to discourage catch-alls. I hope to have all but the completely entrenched converted by year-end. Then we just have to wait until they get harvested... then they'll change their mind. We have one client, who owns close to 50 domains... all with a catch-all going to his *one* address. He went from getting maybe 30 spams a week to several hundred a day... just because a single domain was harvested by these attacks. The only alternative I see is a blacklist populated by some type of distributed detection system... if enough of us under attack contributed 550 unknown user logs, there should be an easily definable threshold for human error. Interesting alternative... the hard part is making it work. How does it face the spambots, but still not refuse actual legit mail traffic coming into your primary MX? What is the threshold where it recognizes an attack from the normal traffic and start
Re: Weird distributed spam attack
It *still* does some wonky stuff with secondaries, so I might have to buy (grumble) their services as secondary MX spooling. We have started distribiting the list of valid addresses to secondary MX servers to reduce the store and forward load of dictionary attacks on those servers. Using a fast response RBL helps, but whitelisting is a chore. (http://openrbl.org pick one) I used to believe that running a catchall alias was an effective deterrent until the b*st*rds started sending complete spams and not just RCPT TO. We have never run catchall, but I am thinking about funneling LUser into pattern matching (spamassassin, or similar) and then used to build a time limited local ipfw or ipfirewall table. We have enough horsepower to filter at the routers, but prefer to let the routers route, and let the MX boxes filter. In fact, in this scenario the catch-all is like pouring gasoline on the fire without some giant water tank on the roof to... oh, wait... wrong thread. Sorry. We tried water cooling, but it quit working when they patched the roof. ;-} -bryan bradsby Texas State Government Net NOC: 512-475-2432 877-472-4848 -- The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in. We're computer professionals. We cause accidents. -- Nathaniel Borenstein co-author of MIME.
Re: Weird distributed spam attack
Hi, #Here is the kicker. I check where these are coming from, they #are from all over the place. I check for IP address spoofing... #not happening. No IP options or TCP options. # #This came from like about 300 different networks, and yes #I don't accept source routing (IP Options). In addition to thousands of open relays, which are bad enough in their own right, there are also thousands of open proxy servers which a growing number of spammers have been using to launch spam runs lately. I suspect that's what you're seeing. You can see some of the open proxy servers that we've seen traffic from at http://darkwing.uoregon.edu/~joe/open-proxies-used-to-send-spam.html If you aren't blocking traffic from open proxy servers via a dns blacklist, I predict that you will definitely see increasingly aggressive spam attacks coming in from diverse locations (although the more you look at the problem, the easier it becomes to identify the handful of carriers who are open proxy-tolerant). [I will also say that it would really be great if mail-abuse.org would add an open proxy listing project to complement their RSS, DUL, and other initiatives.] Regards, Joe
Re: Weird distributed spam attack
--On Wednesday, November 20, 2002 9:40 AM -0800 Joe St Sauver [EMAIL PROTECTED] wrote: [I will also say that it would really be great if mail-abuse.org would add an open proxy listing project to complement their RSS, DUL, and other initiatives.] They go on the RBL - largely due to the existance of AS, in a manner similar to the way listings happen on the RSS. If we have spam via an open proxy and it tests open, it gets listed. I've got some contract coding work (sh, perl, some C) related to this available if any of you folks in the Bay Area have some spare cycles. (We're also hiring full time for some other positions - feel free to ping me). -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Margie Arbon Mail Abuse Prevention System, LLC [EMAIL PROTECTED] http://mail-abuse.org
Re: Weird distributed spam attack
On 11/20/2002 at 12:40 PM, [EMAIL PROTECTED] wrote: In addition to thousands of open relays, which are bad enough in their own right, there are also thousands of open proxy servers which a growing number of spammers have been using to launch spam runs lately. I suspect that's what you're seeing. Almost all SMTP dictionary-crack attacks are done through open proxies, otherwise it's a delivery attack carrying actual spam. Some ISPs seem to have problems understanding the concept that log evidence showing 200 unknown users being probed is in-your-face evidence of illegal trespass and accessing another host/network without authorization. Indeed, the SMTP-cracking malware that Elcomsoft (Advanced Maillist Verifier Pro) pumps out, specifically uses rotating proxies to do its illegal work. Talk about a company not worth defending, even if it's against the DMCA. Dimitry should find himself a more ethical employer, even if Adobe was wrong on this to begin with. If you aren't blocking traffic from open proxy servers via a dns blacklist, I predict that you will definitely see increasingly aggressive spam attacks coming in from diverse locations (although the more you look at the problem, the easier it becomes to identify the handful of carriers who are open proxy-tolerant). If you don't use at least several DNSBL's, you are already DEAD from dictionary attacks, I'd say. I have personally observed an attack against a DS3-connected server from a single source IP, ratcheting through 2400 RCPT TO: checks in just 2-3 seconds. Yes, they are not trying to hide very well, they are trying to crack through your mail server at maximum speeds, with 10-25 probes per connection. There is a demonstration patch for Sendmail to slow down the SMTP dialogue (at the expense of keeping the process in memory too long, and long after the attacking host disconnects) at http://www.spamshield.org/sendmail8.9.0b5-rcpt-patch.txt Do not use this in production, unless you really know what you are doing and are tongue-in-cheek with Sendmail and its source: it has several deficiencies that are obvious to a good observer (and tester) and that may impede or render it useless to most. I wonder if Eric ever reconsidered by suggestion (from 4-5 years ago) to optionally drop processing arguments for a given SMTP dialogue if the client host disconnects the TCP connection prematurely [while not in pipeline mode, but the latter was not part of the argument]. This is very much Sendmail-specific, so you may ignore this. [I will also say that it would really be great if mail-abuse.org would add an open proxy listing project to complement their RSS, DUL, and other initiatives.] What we really want is a DNSBL that lists SMTP dictionary-crack attacks in real-time. The overlap of the mechanics required for running this with other DNSBL's are obvious: Unfortunately I could only spare some expertise, but not a whole lot of time or expenses to set something like that up (and merge it into an existing DNSBL such as Osirusoft's as far as day-to-day ops is concerned). Without touting my horn, SS2.0 will succesfully defend a given (OS)Sendmail (Un*x) against SMTP dictionary-cracking, distributed or not, but other significant reasons are holding up its release right now, in case you were going to ask. bye,Kai
