Re: Sender authentication zombies (was Re: Time to check the rate limits on your mail servers)
On 02/05/05, Douglas Otis [EMAIL PROTECTED] wrote: On Sat, 2005-02-05 at 19:10, J.D. Falk wrote: On 02/05/05, Douglas Otis [EMAIL PROTECTED] wrote: DK or IIM makes it clear who is administering the server and this authentication permits reputation assessment. Add an account identifier, and the problem is nailed. Ah, so you're saying that only the reputation of individual e-mail addresses is worth paying attention to? How do you expect that to scale to billions of messages per day? Without authenticating an identity, it must not be used in a reputation assessment. Currently this is commonly done by using the remote IP address authenticated through the action of transport. In the name space there are two options, the HELO and a validated signature. DK and IIM are attempting to allow the signature solution to scale. Heh, you don't need to convince me that DomainKeys is a good idea. I just don't see how you're jumping from the issue of end-user authentication (which is not free from zombies, as others have explained already) to domain-level reputation. Where's the link? If you're talking about adding user-level signatures to something like DomainKeys (which we already have in s/mime), how do you propose to scale that to interact with the reputation determination for billions of messages per day? -- J.D. Falk uncertainty is only a virtue [EMAIL PROTECTED]when you don't know the answer yet
Re: Sender authentication zombies (was Re: Time to check the rate limits on your mail servers)
On Sun, 2005-02-06 at 09:41, J.D. Falk wrote: On 02/05/05, Douglas Otis [EMAIL PROTECTED] wrote: Without authenticating an identity, it must not be used in a reputation assessment. Currently this is commonly done by using the remote IP address authenticated through the action of transport. In the name space there are two options, the HELO and a validated signature. DK and IIM are attempting to allow the signature solution to scale. Heh, you don't need to convince me that DomainKeys is a good idea. I just don't see how you're jumping from the issue of end-user authentication (which is not free from zombies, as others have explained already) to domain-level reputation. Where's the link? If you're talking about adding user-level signatures to something like DomainKeys (which we already have in s/mime), how do you propose to scale that to interact with the reputation determination for billions of messages per day? Take something like the DomainKey, and add an opaque identifier to the signature, derived from a user authentication process. This could be from an access server or a verification that resolves a dynamic address assignment to a persistent identifier. DomainKeys can scale. Adding an optional opaque persistent identifier will also scale, as this information is already collected. The reason for adding this identifier is two fold. One, it can be used to guard against replay attacks. Two, to assist in identifying compromised systems. Blocking by the provider scales; the identifier makes it easier to locate the problem via abuse reports. The signature ensurers that the provider can accurately attribute abuse. In addition, the provider should want to include the identifiers to protect their reputation in the face of a replay attack, which they can not block otherwise. By convention, the provider can publish their own identifier blackhole-listing just to address the replay attack, whereas known compromised systems should be blocked outright. The signature protects the provider from possible blocking and blackhole-listing errors, as the users will not believe they were the cause of their own problem. -Doug
Re: Time to check the rate limits on your mail servers
You should know all your users email addresses. You have got to be kidding. Not kidding. I have a mail system that handles mail for the example.com domain. I use SMTP AUTH as the only means to relay through the server. My expectation from my customers is that they will utilize this mail service for their [EMAIL PROTECTED] communications. This means the mail server has knowledge of all 'mail from' addresses my users are allowed to use. Who says that Joe ISP has to provide an open SMTP relay to all customers on his IP space? Let's face it, it doesn't work! Even with throttling some SPAM will make it thorough and tha mail server will be black listed and unable to deliver mail to many destinations in no time. It's only a matter of time before owned PCs aquire the 'intelligence' to utilize SMTP AUTH to relay mail. So to clarify my position, my SMTP server handles mail for my users and noone else. My users are identified by their email address(es) on my mail server. Therefore, I can enforce that may mailserver reject relayed mail that does not have a 'mail from' address that corresponds to one of the valid email addresses for an authenticated users. I am addressing the dilemma with the average home user. If you own a bunch of domains you're in a whole different class. Make arrangement with your ISP to handle your mail, run your own mail server or buy hosting with email accounts. Point is, if you own a bunch of domains you're not the average home user that floods the world with crap without their knowledge. Adi
Sender authentication zombies (was Re: Time to check the rate limits on your mail servers)
On 02/04/05, Douglas Otis [EMAIL PROTECTED] wrote: Attempting to detect spam trickled through thousands of compromised systems sent through the ISP's mail servers, SPF does nothing, Nor is it purported to. Domain-based authentication schemes are intended to handle an entirely different problem. and could actually damage the reputation of those domains that authorize the provider for their mailbox domain using SPF. These records can be read by the spammers and then exploited. Repairing this reputation could be next to impossible. You touch on some basic realities here: 1. spam coming out of your network will affect your reputation. 2. spam coming out of your own mail machines will affect your reputation even more immediately. Neither are affected by any of the domain authentication schemes currently in play (SPF, SenderID, DomainKeys, etc.) The spam itself may include forgeries, but that's a different issue. -- J.D. Falk uncertainty is only a virtue [EMAIL PROTECTED]when you don't know the answer yet
Re: Time to check the rate limits on your mail servers
TV Date: Fri, 4 Feb 2005 09:53:07 -0500 (EST) TV From: Todd Vierling TV The only way to be sure is via cryptographic signature. Barring that level False. You imply that a crypto signature is a perfect guarantee, and that nothing else can provide equal assurance. TV of immediate traceability, SPF provides a very useful data point to that TV end (as its *only* purpose is curbing forgery). SPF says mail from this domain should only come from these MXes. It doesn't stop someone from forging a random @domain.tld address from an SPF-blessed Everquick MX. Now, let's say it's known that Everquick MXes authenticate users and only allow whitelisted From: email addresses. Step 1: SPF [or similar/better] confirms that the MX is allowed to send email on behalf of the claimed sender address. Discard message if it comes from a bogus MX. Step 2: The MX confirms that the user was authorized to use the claimed sender address. The message would never have been transmitted had the user not authenticated with the trusted MX. Please explain how the trust chain does not verify the sending user. Malware will steal username/password is not a valid answer, as the same can apply equally to crypto keys. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Time to check the rate limits on your mail servers
That, on the other hand, gets you into trouble with rather stupid Spam filters, that only accept mails from a server, if that server is also MX for the senders domain. Yes, this is stupid, but that does not change the fact, that these setups are out there. No, they're not. Large ISPs, starting with AOL and Yahoo, separated their inbound and outbound mail servers years ago. Anyone who still uses mail from MX for filtering doesn't really care if he gets mail or not. Note that this is a different issue from separating your public inbound MX servers from your user-only submit servers. I've done that, too, and haven't had any problems other than educating the occasional too-clever user who thinks my setup instructions must be wrong, substitutes the MX server for the SUBMIT server, and then complains that it doesn't work. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor I shook hands with Senators Dole and Inouye, said Tom, disarmingly.
Re: Sender authentication zombies (was Re: Time to check the rate limits on your mail servers)
On Sat, 5 Feb 2005, J.D. Falk wrote: DK or IIM makes it clear who is administering the server and this authentication permits reputation assessment. Add an account identifier, and the problem is nailed. Ah, so you're saying that only the reputation of individual e-mail addresses is worth paying attention to? How do you expect that to scale to billions of messages per day? Isn't that called S/MIME and PGP? It hasn't scaled yet. I've received two S/MIME messages in my life, and a few more PGP messages. A problem is if the computer has been compromised, its likely the authentication information stored on the computer has also been compromised or will be when the user starts typing any missing information. Very few consumer-grade computers have advanced security devices installed. As I keep saying, a secure computer rarely DDOSes, spams or sends viruses. And when they do, its much easier to whack the owner. So how do we keep computers secure and fix the insecure ones?
Re: Sender authentication zombies (was Re: Time to check the rate limits on your mail servers)
On Sat, 2005-02-05 at 19:10, J.D. Falk wrote: On 02/05/05, Douglas Otis [EMAIL PROTECTED] wrote: DK or IIM makes it clear who is administering the server and this authentication permits reputation assessment. Add an account identifier, and the problem is nailed. Ah, so you're saying that only the reputation of individual e-mail addresses is worth paying attention to? How do you expect that to scale to billions of messages per day? Without authenticating an identity, it must not be used in a reputation assessment. Currently this is commonly done by using the remote IP address authenticated through the action of transport. In the name space there are two options, the HELO and a validated signature. DK and IIM are attempting to allow the signature solution to scale. -Doug
Re: Time to check the rate limits on your mail servers
On Thu, 3 Feb 2005, Edward B. Dreger wrote: JJ auth is sufficient to make email traceable to your own customers. End users also would appreciate the ability to _know_ a message is not forged. The only way to be sure is via cryptographic signature. Barring that level of immediate traceability, SPF provides a very useful data point to that end (as its *only* purpose is curbing forgery). -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Time to check the rate limits on your mail servers
On Thu, 3 Feb 2005, Michael Loftis wrote: --On Thursday, February 03, 2005 11:42 + [EMAIL PROTECTED] wrote: Do you let your customers send an unlimited number of emails per day? Per hour? Per minute? If so, then why? Because there are *NO* packages available that offer limiting. Free or commercial. I disagree. On a per IP basis, sendmail now offers ClientRate, number of connections allowed within a 60 second sliding window from a given IP and ClientConn, number of active connections allowed from an IP at any time Used in conjunction with Jochen Bern's bm patch available from http://www.informatik.uni-trier.de/~bern/sendmail/ which limits the number of mail commands given in a single connection, you can rate limit your users fairly well. We have used these limits for ~6 months now and have only had to whitelist 3 sites from the Client limits. You could probably adjust the window size for the ClientRate and then limit the number of smtp commands per connection to achieve like an hourly limit of some sort. sam
RE: Time to check the rate limits on your mail servers
On Thu, 3 Feb 2005, Joel Perez wrote: I keep reading these articles and reports about this botnet and that botnet problem and how many user's pc's are infected. The only thing I don't see is a way to remove these bots! http://www.sun.com/software/javadesktopsystem/features.xml http://www.apple.com/macosx/ matto [EMAIL PROTECTED]darwin The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Re: Time to check the rate limits on your mail servers
On Fri, 2005-02-04 at 09:53 -0500, Todd Vierling wrote: On Thu, 3 Feb 2005, Edward B. Dreger wrote: JJ auth is sufficient to make email traceable to your own customers. End users also would appreciate the ability to _know_ a message is not forged. The only way to be sure is via cryptographic signature. Barring that level of immediate traceability, SPF provides a very useful data point to that end (as its *only* purpose is curbing forgery). Attempting to detect spam trickled through thousands of compromised systems sent through the ISP's mail servers, SPF does nothing, and could actually damage the reputation of those domains that authorize the provider for their mailbox domain using SPF. These records can be read by the spammers and then exploited. Repairing this reputation could be next to impossible. With respect to forgery, authorization is not authentication. There is no consensus which mailbox-domain is checked, SPF (MAILFROM or HELO), Classic (MAILFROM or Other and HELO), or Sender-ID (PRA), so it is uncertain which mailbox-domain may have been checked for authorization, if any. False assurances could be worse than no assurances. White-listing for forwarded accounts or mailing lists to allow an SPF rule-set bypass means there is no certainty a check was ever made. -Doug
Re: Time to check the rate limits on your mail servers
On Thu, 3 Feb 2005 11:42:55 +, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://news.com.com/Zombie+trick+expected+to+send+spam+sky-high/2100-7349_3-5560664.html?tag=cd.top that botnets are now routing their mail traffic through the local ISP's mail servers rather than trying their own port 25 connections. Now? We (and AOL, and some other large networks) have been seeing this thing go on since over a year. Do you let your customers send an unlimited number of emails per day? Per hour? Per minute? If so, then why? Doing that - especially now when this article has hit the popular press and there's going to be lots more people doing the same thing - is going to be equivalent of hanging out a block my email sign. One additional thing that I think wasnt mentioned in the article - Make sure your MXs (inbound servers) are separate from your outbound machines, and that the MX servers dont relay email for your dynamic IP netblock. Some other trojans do stuff like getting the ppp domain name / rDNS name of the assigned IP etc and then nslookup -q=mx domain.com, then set itself up so that all its payloads get delivered out of the domain's MX servers -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Time to check the rate limits on your mail servers
Hi! http://news.com.com/Zombie+trick+expected+to+send+spam+sky-high/2100-7349_3-5560664.html?tag=cd.top that botnets are now routing their mail traffic through the local ISP's mail servers rather than trying their own port 25 connections. Now? We (and AOL, and some other large networks) have been seeing this thing go on since over a year. Indeed, we also see this a long time now. Most of them specific spamruns towards the bigger players... (AOL alike). Do you let your customers send an unlimited number of emails per day? Per hour? Per minute? If so, then why? One additional thing that I think wasnt mentioned in the article - Make sure your MXs (inbound servers) are separate from your outbound machines, and that the MX servers dont relay email for your dynamic IP netblock. Some other trojans do stuff like getting the ppp domain name / rDNS name of the assigned IP etc and then nslookup -q=mx domain.com, then set itself up so that all its payloads get delivered out of the domain's MX servers So the next article would say 'lets now all seperate MX and SMTP servers' still a LOT of large players combining those two. Giving troyans doing the above scenario a open door. Bye, Raymond.
Re: Time to check the rate limits on your mail servers
On Thu, 3 Feb 2005, Suresh Ramasubramanian wrote: On Thu, 3 Feb 2005 11:42:55 +, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://news.com.com/Zombie+trick+expected+to+send+spam+sky-high/2100-7349_3-5560664.html?tag=cd.top that botnets are now routing their mail traffic through the local ISP's mail servers rather than trying their own port 25 connections. Now? We (and AOL, and some other large networks) have been seeing this thing go on since over a year. Do you let your customers send an unlimited number of emails per day? Per hour? Per minute? If so, then why? Doing that - especially now when this article has hit the popular press and there's going to be lots more people doing the same thing - is going to be equivalent of hanging out a block my email sign. I just implemented a patch to tcpserver which allows me to limit the number of simultaneous SMTP connections from any one IP, but have not yet looked into daily/hourly limits. I know Comcast has started limiting residential customers to 50-100 emails per day, and that customers with legitimate reasons for using more than that are starting to complain. One additional thing that I think wasnt mentioned in the article - Make sure your MXs (inbound servers) are separate from your outbound machines, and that the MX servers dont relay email for your dynamic IP netblock. Some other trojans do stuff like getting the ppp domain name / rDNS name of the assigned IP etc and then nslookup -q=mx domain.com, then set itself up so that all its payloads get delivered out of the domain's MX servers Easier said than done, especially if you're a small ISP that's been doing POP before SMTP and changing this requires that every customer's settings be changed. Is there any info on how this zombie is spread? ie, email worms, direct port attacks, etc. If the former, there's hope of nipping it in the bud with anti-virus filtering. James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: Time to check the rate limits on your mail servers
On Thu, Feb 03, 2005 at 11:42:55AM +, [EMAIL PROTECTED] wrote: CNET reports http://news.com.com/Zombie+trick+expected+to+send+spam+sky-high/2100-7349_3-5560664.html?tag=cd.top that botnets are now routing their mail traffic through the local ISP's mail servers rather than trying their own port 25 connections. There is one mistatement in this article, though: the author says: This means the junk mail appears to come from the ISP [...] If it's coming from their servers (or their network), it IS coming from the ISP, and they bear full responsibility for making it stop. ---Rsk
Re: Time to check the rate limits on your mail servers
On Feb 3, 2005, at 9:30 AM, [EMAIL PROTECTED] wrote: One additional thing that I think wasnt mentioned in the article - Make sure your MXs (inbound servers) are separate from your outbound machines, and that the MX servers dont relay email for your dynamic IP netblock. Some other trojans do stuff like getting the ppp domain name / rDNS name of the assigned IP etc and then nslookup -q=mx domain.com, then set itself up so that all its payloads get delivered out of the domain's MX servers Easier said than done, especially if you're a small ISP that's been doing POP before SMTP and changing this requires that every customer's settings be changed. IMHO, if you are a small ISP and limit the # of e-mails per user per day, even to something like 1K, you probably don't have to separate the MX SMTP servers. But that's me, others might still think you were being irresponsible. Is there any info on how this zombie is spread? ie, email worms, direct port attacks, etc. If the former, there's hope of nipping it in the bud with anti-virus filtering. All of the above. -- TTFN, patrick
Re: Time to check the rate limits on your mail servers
Do you let your customers send an unlimited number of emails per day? Per hour? Per minute? If so, then why? Doing that - especially now when this article has hit the popular press and there's going to be lots more people doing the same thing - is going to be equivalent of hanging out a block my email sign. I don't understand your comment. This is an arms race. The spammers and botnet builders are attempting to make their bots use the exact same email transmission channels as your customers' email clients. They are getting better at doing this as time goes on. I think we are at the point where the technical expertise of the botnet builders is greater than the technical expertise of most people working in email operations. We cannot win this battle by continuing to attempt to trump their technical abilities. However, if we shift the battleground to a location where network operators have the upper hand, we can do better. And that's why I suggest that people should start looking at email volume controls. The vast majority of individual users only send a small number of emails over a given time period whether you measure that time period in minutes, hours or days. SPAM is a form of DDoS against the Internet's email architecture. Rate limiting has proven to be an effective way of mitigating DDoS because it strikes at the very core of the DoS methodology. Why not deploy this strategy against email? Please note that I am not suggesting that this is a way to solve the SPAM problem. First of all, I do not agree that there is a SPAM problem. The fundamental problem is that the Internet email architecture is flawed. SPAM is merely a symptom of those flaws. If we fix the architecture, then nobody will care about SPAM. As you can see, two separate problems are becoming intertwingled here. In the past we had viruses, DDoS, botnets, SPAM, phishing. But now, all of these things are merging and evolving together. And secondly, I'm only pointing out that there are reasons for people to start thinking about rate limiting email on their networks. I'm suggesting that people should be asking questions. I don't think it is wise to run out and slap rate limits on mail infrastructure without thinking through the implications. --Michael Dillon
Re: Time to check the rate limits on your mail servers
[EMAIL PROTECTED] wrote: CNET reports http://news.com.com/Zombie+trick+expected+to+send+spam+sky-high/2100-7349_3-5560664.html?tag=cd.top that botnets are now routing their mail traffic through the local ISP's mail servers rather than trying their own port 25 connections. Both on ASRG and here on NANOG, many of us said many times, and most of the times people called me crazy; 1. Block port 25 for dynamic ranges - that will kill the current strain of worms. 2. It won't solve spam, and neither will SPF or anything else of the sort, as when you have 100K zombies, you don't need to act a server, you can use the real credentials for the user, and even if limited to a 1000 messages, that times 100K drones is... The issue is numbers, and how to reduce them, not stop the tide. Currently there is a discussion of this on Spam-Research [1], quite interesting. Gadi. 1 - Spam-Research archives: https://linuxbox.org/cgi-bin/mailman/listinfo/spam
Re: Time to check the rate limits on your mail servers
[EMAIL PROTECTED] wrote: On Thu, 3 Feb 2005, Suresh Ramasubramanian wrote: snip Easier said than done, especially if you're a small ISP that's been doing POP before SMTP and changing this requires that every customer's settings be changed. drac http://mail.cc.umanitoba.ca/drac/ supports seperate pop/smtp servers. Which is not neccessarily what is being recommended by having seperate in-mx-smtp and out-smtp. Is there any info on how this zombie is spread? ie, email worms, direct port attacks, etc. If the former, there's hope of nipping it in the bud with anti-virus filtering. James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: Time to check the rate limits on your mail servers
Hi! Now, once 100K zombies can send *only* 1000 spam messages a day instead of 10K or even 500K, it makes a difference, but it is no solution. I am happy to see people are starting to move this way, and I personally believe that although this is happening (just go and hear what Carl from AOL says on Spam-R that they have been seeing since 2003), this is all a POC. We have not yet begun seeing the action. This is no POC, we have seen this happen many many times. Perhaps some drone networks are a little 'behind' but in general, they are perfectly able to do this. Even with some static lists for some large ISPs mailservers they can perfectly initiate it large scale. And yes, it does limit, but with the number of bots we see controlled on the few botnets we monitored the impact will still be hudge. Should I once again be stoned, or will others see it my way now that the tide is starting to turn? Its not turning, its happening. Bye, Raymond.
Re: Time to check the rate limits on your mail servers
If a pro cannot clean it out safely, then i cannot imagine our typical homeuser would be able to... and with some luck he installs a firewall and antivirus next time, after reinstalling his system for the 4th or 5th time. You may want to check out some AT (Anti-Trojan) software such as The Cleaner and BOclean. Gadi.
Re: Time to check the rate limits on your mail servers
Hi! If a pro cannot clean it out safely, then i cannot imagine our typical homeuser would be able to... and with some luck he installs a firewall and antivirus next time, after reinstalling his system for the 4th or 5th time. You may want to check out some AT (Anti-Trojan) software such as The Cleaner and BOclean. You will never be sure you have picked up all, only the known ones. For a compromised system, unless running tripwire or something, reinstall! Its a nice start, but it also tell people i am safe, and they dont know for sure. Seeing our abuse department getting tickets over and over about the same customers its a fact that they just simple are not able to clean it out easilly. Then its better to instert foot (CD) and start all over. Bye, Raymond
Re: Time to check the rate limits on your mail servers
You will never be sure you have picked up all, only the known ones. For a compromised system, unless running tripwire or something, reinstall! You can never be sure, that's why it's a backdoor/Trojan horse. Its a nice start, but it also tell people i am safe, and they dont know Yes, it is. AV products have not taken Trojan horses seriously for years, and called them garbage samples. Now they start to change that due to almost any sample out there being also a Trojan horse, but not drastically enough for sure. Seeing our abuse department getting tickets over and over about the same customers its a fact that they just simple are not able to clean it out easilly. Then its better to instert foot (CD) and start all over. Then using AT programs is a good start. A clean slate is always better, but your grandma won't agree. Gadi.
Re: Time to check the rate limits on your mail servers
Now, once 100K zombies can send *only* 1000 spam messages a day instead of 10K or even 500K, it makes a difference, but it is no solution. I'd like to see rate limits set much lower than that. Perhaps one message per day to begin with. After the message is sent, send the customer a reminder about the limit and tell them how to get to a web page to increase the limit. The web page would only accept an incremental increase. For instance, if your limit is one, you can bump it up to five per day and that is all. Then, if you exceed the new limit, you once again have the opportunity to bump it up by five more. Most people won't need more than 10 or 15 per day limits. People who need more can call their customer representative and order the volume mail add-on product. They will have to agree to a contract that allows you, the operator, to completely block their net access without notice if it appears that a bot/virus may have infected their systems. I'm sure if you discuss this kind of stuff with your product development and product marketing people, they will come up with more interesting variations. One message per day is not too low. There are people who never use email. They just browse the web and use IM. Why should you, the operator, allow those customers to inject huge numbers of email systems into the Internet as botnet drones? 1000 a day is way too high, IMHO. --Michael Dillon
Re: Time to check the rate limits on your mail servers
This is no POC, we have seen this happen many many times. Perhaps some Wrong, and I will tell you why in a second. drone networks are a little 'behind' but in general, they are perfectly able to do this. Even with some static lists for some large ISPs mailservers they can perfectly initiate it large scale. And yes, it does limit, but with the number of bots we see controlled on the few botnets we monitored the impact will still be hudge. You have been seeing them try it, yes. But why should they use it when they can send 10,000,000,000 spam messages out with no trouble? The answer is because they will soon have to. As much as some are capable of it, most are not yet there. They will be soon. This is the first evolutionary step I can see that we pushed the spammers into doing, according to our wishes. It may be a bigger attack on your servers, but it's nothing in comparison to spam messages out there where every available host sends the spam out. Why SPF won't work? Why it is all useless (SPF, etc.) is because there are 100K and more drone armies out there, but don't kid yourselves - you ain't seen nothing yet. Should I once again be stoned, or will others see it my way now that the tide is starting to turn? Its not turning, its happening. You will know when it's happening. That will be when every spammer will be at the corner and will have to move to this way of working. Just because you see a POC and some people are either more adavanced or bored to do it, and spam is a massive thing so you feel it, doesn't mean it's a trend. Gadi.
Re: Time to check the rate limits on your mail servers
- Original Message - From: Gadi Evron [EMAIL PROTECTED] Allow me to elaborate; and forget about this article, why limited ourselves? Once big ISP's started blocking port 25/outbound for dynamic ranges, and it finally begun hitting the news, we once again caused the spammers to under-go evolution. In this particular case, they figured they'd have to find better ways to send spam out, because eventually, they will be out of working toys. Hello I am a bit concerned that blocking any port at all preventing abuse of the affected service will make the abusers go through other services instead. Port 139/445 is already blocked by several isps due to excessive abuse or I believe they call it 'a security measurement'. Even port 23 has been blocked (inbound and outbound) by atleast 1 large isp I am aware of. When that mssql worm was lurking around isps were also blocking that port. I hope I'm not the only one seeing a pattern here. Really, blocking ports makes no sense to me in the long run. You are destroying the service, and even if you block all ports there are several ways to spam anyway. You would probably reply now saying that yeah but you get rid of 99% of the spammers that way. That is only partly true. As time goes on all spammers will adopt to your isps new security policy and if you still don't see the pattern I am talking about now there is nothing more I can say. I don't have the solution to all of this, but I sure know how to see what is not the solution. Teach people how to write Hello world better perhaps. Joergen Hovland Joergen Hovland ENK
Re: Time to check the rate limits on your mail servers
I know that I'm in the middle of trying to figure this out with the mail server software that is used where I work but if limits are going to be put into place per email box of say 1,000 messages per day and a total daily sending limit of say 200 megabytes, I feel there also needs to be methods in place for the end-user (customer) to be able to view where they stand in relationship to their quota. Yes this becomes more of something for the help desk side of a provider but as operations, I have to support the help desk in being able to give the user information when they call about the limits David - Original Message - From: Gadi Evron [EMAIL PROTECTED] To: Raymond Dijkxhoorn [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; nanog@merit.edu Sent: Thursday, February 03, 2005 10:14 AM Subject: Re: Time to check the rate limits on your mail servers Did you actially read the article? This was about drones sending out via its ISP mailserver. Blocking outbound 25 doesnt help a bit here. In general sure, good ide, and also start using submission for example. But in this contect its silly. No, it is relevant or I wouldn't have mentioned it. Allow me to elaborate; and forget about this article, why limited ourselves? Once big ISP's started blocking port 25/outbound for dynamic ranges, and it finally begun hitting the news, we once again caused the spammers to under-go evolution. In this particular case, they figured they'd have to find better ways to send spam out, because eventually, they will be out of working toys. Using the user's own mail server, whether by.. erm.. just utilizing it if that is possible, sniffing the SMTP credentials or stealing them from a file/registry, maybe even using Outlook to send is all that's about to happen. heck, I don't see how SMTP auth would help, either. They have local access to the machine. Now, once 100K zombies can send *only* 1000 spam messages a day instead of 10K or even 500K, it makes a difference, but it is no solution. I am happy to see people are starting to move this way, and I personally believe that although this is happening (just go and hear what Carl from AOL says on Spam-R that they have been seeing since 2003), this is all a POC. We have not yet begun seeing the action. Should I once again be stoned, or will others see it my way now that the tide is starting to turn? Gadi.
Re: Time to check the rate limits on your mail servers
Hello I am a bit concerned that blocking any port at all preventing abuse of the affected service will make the abusers go through other services instead. Port 139/445 is already blocked by several isps due to excessive abuse or I believe they call it 'a security measurement'. Even port 23 has been blocked (inbound and outbound) by atleast 1 large isp I am aware of. When that mssql worm was lurking around isps were also blocking that port. I hope I'm not the only one seeing a pattern here. Really, blocking ports makes no sense to me in the long run. You are destroying the service, and even if you block all ports there are several ways to spam anyway. You would probably reply now saying that yeah but you get rid of 99% of the spammers that way. That is only partly true. As time goes on all spammers will adopt to your isps new security policy and if you still don't see the pattern I am talking about now there is nothing more I can say. I don't have the solution to all of this, but I sure know how to see what is not the solution. Teach people how to write Hello world better perhaps. I quite agree, blocking ports is not the best answer, as it is a self-inflicted-DDoS. Still, please tell me, how is not blocking un-used or un-necessary ports a bad thing? It is a defensive measure much like you'd add barricades before an attack. The Internet is a war zone, but I don't have to tell the NANOG community that. Thing is, blocking port 25 won't cause spam to stop, there are no FUSSP solution. Yet, we all recognize that SMTP is far from perfect. And indeed, as others here are more qualified than me, by far, to tell you, most development in anti-spam technology only helped short-term, and caused the bad guys to evolve. Well, why is blocking port 25 different? See for yourself. They now evolved, and are using user-credentials and ISP-servers. This evolution means that their capabilities are severely decreased, at least potentially. This is the best next thing after dark Irish stout and ketchup. It means ISP's will have to re-think their strategies, just like AOL did. It also means it's once small step to victory for us. We are a long way from it, and please - not everybody blocks port 25 so current-day worms are more than efficient still. It is nice to see fore thinking and long-term planning with the bad guys, where all we can do is disagree. Gadi.
Re: Time to check the rate limits on your mail servers
On Thu, 03 Feb 2005 16:07:10 +0100, Raymond Dijkxhoorn said: The only thing I don't see is a way to remove these bots! Not everyone knows how to even look at their machines for signs of these bots. Heck, I know most of my guys here don't even know how these bots work. For a compromised system, insert CD, reinstall! BZZT! But thank you for playing. Don't *RE*-install. If you got whacked by a bot on Monday, and re-install Sunday's configuration of software on Tuesday, all that means is that Wednesday you'll get re-whacked. Lather, rinse, repeat. Install *SOMETHING ELSE*. Something less vulnerable to all this manure. (I'll mention the *other* alternative, replacing/upgrading the user, mostly for completeness and so we can all have a good chuckle) pgpLVSBP3QLeD.pgp Description: PGP signature
Re: Time to check the rate limits on your mail servers
On Thu, 03 Feb 2005 17:54:28 +0200, Gadi Evron [EMAIL PROTECTED] wrote: Still, please tell me, how is not blocking un-used or un-necessary ports a bad thing? It is a defensive measure much like you'd add barricades before an attack. Agreed. And depending on your service, there are different ports worth blocking. For residential users, I can't see a reason to not block something like Netbios. And blocking port 25 effectively prevents zombies from spamming. Unfortunately, it also blocks legitimate users from being able to use SMTP AUTH on a remote server.. They now evolved, and are using user-credentials and ISP-servers. This evolution means that their capabilities are severely decreased, at least potentially. Has this been confirmed? Does this new worm, in fact, use SMTP AUTH where necessary? Will it also check the port that the user's computer is set to send mail on? So, for instance, if SMTP AUTH is required, and the mail submission port is being used rather than standard port 25, will the worm detect all this? The nice part about SMTP AUTH, though, is that there is at least a direct link to the user sending the spam. This means, of course, that ISP's will need to police their users a little better.. :) It means ISP's will have to re-think their strategies, just like AOL did. It also means it's once small step to victory for us. We are a long way from it, and please - not everybody blocks port 25 so current-day worms are more than efficient still. So I guess users will have to stop clicking that Save Password button... That is, until the worm records the keystrokes when the password is entered... *sigh* Gadi. -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Time to check the rate limits on your mail servers
On Thu, 3 Feb 2005, Raymond Dijkxhoorn wrote: One additional thing that I think wasnt mentioned in the article - Make sure your MXs (inbound servers) are separate from your outbound machines, and that the MX servers dont relay email for your dynamic IP netblock. Some other trojans do stuff like getting the ppp domain name That, on the other hand, gets you into trouble with rather stupid Spam filters, that only accept mails from a server, if that server is also MX for the senders domain. Yes, this is stupid, but that does not change the fact, that these setups are out there. Start using authenticated SMTP for this. Until the next bot implemented co-opts the pop3 client, or simply hacks the password from the pop3 client (how strong is that encryption?). James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: Time to check the rate limits on your mail servers
On Thu, 03 Feb 2005 12:16:41 EST, Jason Frisvold said: Agreed. And depending on your service, there are different ports worth blocking. For residential users, I can't see a reason to not block something like Netbios. And blocking port 25 effectively prevents zombies from spamming. Unfortunately, it also blocks legitimate users from being able to use SMTP AUTH on a remote server.. There's a *reason* why RFC2476 specifies port 587 pgpGfzZdCd46O.pgp Description: PGP signature
Re: Time to check the rate limits on your mail servers
On Thu, Feb 03, 2005 at 05:29:15PM +0200, Gadi Evron wrote: You will never be sure you have picked up all, only the known ones. For a compromised system, unless running tripwire or something, reinstall! You can never be sure, that's why it's a backdoor/Trojan horse. Its a nice start, but it also tell people i am safe, and they dont know Yes, it is. AV products have not taken Trojan horses seriously for years, and called them garbage samples. Now they start to change that due to almost any sample out there being also a Trojan horse, but not drastically enough for sure. Seeing our abuse department getting tickets over and over about the same customers its a fact that they just simple are not able to clean it out easilly. Then its better to instert foot (CD) and start all over. Then using AT programs is a good start. A clean slate is always better, but your grandma won't agree. Unfortunately, starting over in some operating systems means re-installing EVERYTHING, and since applications tend to get installed over time, the installation media for each and every app may not be available. Backups are not very useful, because just placing the executables and the work product/data files in the right place will not work in some Windows systems if the proper registry entries are not there. Also, if you reinstall in the wrong order you can wind up in DLL hell. Gadi. -- -=[L]=-
Re: Time to check the rate limits on your mail servers
On 02/03/05, [EMAIL PROTECTED] wrote: Is there any info on how this zombie is spread? ie, email worms, direct port attacks, etc. If the former, there's hope of nipping it in the bud with anti-virus filtering. Yeah, that's been working really well for us so far. /sarcasm -- J.D. Falk uncertainty is only a virtue [EMAIL PROTECTED]when you don't know the answer yet
Re: Time to check the rate limits on your mail servers
on Thu, Feb 03, 2005 at 04:07:10PM +0100, Raymond Dijkxhoorn wrote: The only thing I don't see is a way to remove these bots! Not everyone knows how to even look at their machines for signs of these bots. Heck, I know most of my guys here don't even know how these bots work. For a compromised system, insert CD, reinstall! ...which simply reinstalls the old vulnerabilities that made the machine suspectible to compromise in the first place. If you can't patch up from the buggy baseline in time, reinstalling from original media is often the worst thing you can do, if the machine is still connected to the network. And if the machine is NOT connected to the network, it is often not possible to get the security updates downloaded that patch the vulnerabilities. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: Time to check the rate limits on your mail servers
GE Date: Thu, 03 Feb 2005 17:14:40 +0200 GE From: Gadi Evron GE heck, I don't see how SMTP auth would help, either. They have local GE access to the machine. User joe6pack is pumping out 100k messages/day. That can't possibly be valid; let's disable his -- and only his -- SMTP access. He can't spam directly via SMTP/25 connections, so we're good there. User joe6pack's mail volume is two sigma above normal. Good thing our outbound mail spam scanning is much more stringent under these conditions. User joe6pack doesn't know which of 50 machines behind his SOHO's NAT box sent the spam. Luckily, the username helps us/him track down the infected box. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Time to check the rate limits on your mail servers
GE Date: Thu, 03 Feb 2005 17:54:28 +0200 GE From: Gadi Evron GE They now evolved, and are using user-credentials and ISP-servers. This GE evolution means that their capabilities are severely decreased, at least GE potentially. This means that it's 1998 again. Direct-to-MX spam was an evolution when user accounts began getting nuked for spamming. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Time to check the rate limits on your mail servers
: I'd like to see rate limits set much lower than that. Perhaps one : message per day to begin with. After the message is sent, send the : customer a reminder about the limit and tell them how to get to a web : page to increase the limit. The web page would only accept an : incremental increase. For This is a great way to attract and keep customers. I also like the other's suggestions that cause their customers a lot of hassle and pain. As some folks have said before, I encourage my competition to do this. : services instead. Port 139/445 is already blocked by several isps due : to excessive abuse or I believe they call it 'a security measurement'. NetBIOS was never meant to be a WAN protocol. For your customers that need this so they can share files, it's a dangerous thing because folks with that level of expertise wouldn't know how to protect their personal data. There is no need to let NetBIOS ports be open to the world. : atleast 1 large isp I am aware of. When that mssql worm was lurking : around isps were also blocking that port. I hope I'm not the only one You want your MySQL database open to the world??? What's you IP address? Never mind, I could find it anyway... 8-) : seeing a pattern here. Really, blocking ports makes no sense to me in : the long run. Again, some protocols were never meant to be available to the world, so there is a need to block some things. Some should be restricted to the local LAN, some should be restricted to your network, or some part of it, and some open to the world. scott
Re: Time to check the rate limits on your mail servers
On Thu, 03 Feb 2005 12:26:55 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Thu, 03 Feb 2005 12:16:41 EST, Jason Frisvold said: Agreed. And depending on your service, there are different ports worth blocking. For residential users, I can't see a reason to not block something like Netbios. And blocking port 25 effectively prevents zombies from spamming. Unfortunately, it also blocks legitimate users from being able to use SMTP AUTH on a remote server.. There's a *reason* why RFC2476 specifies port 587 I assume you're referring to the ability to block port 25 if 587 is used for submission. This is great in theory, but if this were the case, then the Trojan authors would merely alter their Trojan to use port 587. Unfortunately, I don't think there's an easy answer to the spam problem. Sure, we can educate and block. But at the end of the day, the spammers will just find another way to worm those messages into the network. Some of these guys are making boatloads of money, and I hardly think they're willing to throw in the towel if they hit a bump in the road... On the flipside, those of us working as admins and trying to stop the flow of spam are making next to nothing.. *sigh* -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Time to check the rate limits on your mail servers
On Thu, Feb 03, 2005 at 12:26:55PM -0500, [EMAIL PROTECTED] wrote: On Thu, 03 Feb 2005 12:16:41 EST, Jason Frisvold said: Agreed. And depending on your service, there are different ports worth blocking. For residential users, I can't see a reason to not block something like Netbios. And blocking port 25 effectively prevents zombies from spamming. Unfortunately, it also blocks legitimate users from being able to use SMTP AUTH on a remote server.. There's a *reason* why RFC2476 specifies port 587 IIRC the starting point of this thread was, that Spammers now learned to use the smarthost of the clients. When they are using that, why is it more difficult for them to send their junk on port 587 instead of port 25? As soon as the spammers on a big scale learn to use the same traffic path the mailclients do, instead looking up MXes themselves, this switching ports and blocking 25 that is proposed, will cause a lot of work without any benefit. Same goes for SPF, BTW. Only thing that puzzles me is, why it took spammers so long to go in this direction. Nils
Re: Time to check the rate limits on your mail servers
--On Thursday, February 03, 2005 11:42 + [EMAIL PROTECTED] wrote: Do you let your customers send an unlimited number of emails per day? Per hour? Per minute? If so, then why? Because there are *NO* packages available that offer limiting. Free or commercial.
Re: Time to check the rate limits on your mail servers
Nils Ketelsen wrote: Only thing that puzzles me is, why it took spammers so long to go in this direction. It didn't. It took the media long to notice. Pete
Re: Time to check the rate limits on your mail servers
- Original Message - From: Jason Frisvold [EMAIL PROTECTED] On Thu, 03 Feb 2005 17:54:28 +0200, Gadi Evron [EMAIL PROTECTED] wrote: Still, please tell me, how is not blocking un-used or un-necessary ports a bad thing? It is a defensive measure much like you'd add barricades before an attack. Agreed. And depending on your service, there are different ports worth blocking. For residential users, I can't see a reason to not block something like Netbios. And blocking port 25 effectively prevents zombies from spamming. Unfortunately, it also blocks legitimate users from being able to use SMTP AUTH on a remote server.. I still can't really agree. How do you know a port is un-used or un-necessary? Because IANA has assigned port 25 as SMTP? Because only crackers use netbios outside their lan? You can't really inspect your network for a month to determine what ports are being used legit either since this changes over time and the list of ports would be noisy due to virus' etc. And why should you block that particular port when there are no difference between port numbers technically speaking? The only valid reason would be because the other party is also using that port and blocking that particular port will prevent that particular traffic unless somebody changed the portnumber - which will happen if you start blocking specific ports because it might just annoy certain people too much. This is why all the socket enabled software we develop always use port 80 or 443 to be able to get through firewalls. We simply don't want to spend the extra time helping and telling the customer to enable this and that port on their firewall. So in 20 years when every single program is using the same port because you are blocking all the other ports - how can you tell the difference? Packet inspection! But no not always, not when you are using SSL etc. Oh okay, then lets disable that then since you can't identify those packets and because we don't care about the collateral damage it gives anyway? To a solution I would consider okay: Since port 25 is mostly known as belonging to SMTP I would rather transparently proxy all outbound 25 connections from customers to our outbound SMTP server instead of blocking the port directly. If the proxy was unable to detect that this was a legit SMTP connection, it will redirect to the original target instead. Now, what will happen is that your companies SMTP server will catch every single bot/worm spamming through SMTP. Here is when the rate-limit and outbound spam/virusfilters should kick in. If you were sending more than 10 infected e-mails or you are actually spamming (yourself or not), disable the customers internet connectivity and redirect port 80 requests to an information page telling the customer you are infected, click here to download antivirus etc... and click here when you think you have removed the virus/stopped spamming to regain full connectivity. Virus' could automaticly detect this so you shouldn't make it too easy to regain internet access. This would help your customer finding out if their equipment is infected instead of being unaware of it (since you block port 25 instead). If the customers laptop was infected and he/she frequently moves to other isps (wlan etc) not blocking that port, it could be harder to find out for both parties. They now evolved, and are using user-credentials and ISP-servers. This evolution means that their capabilities are severely decreased, at least potentially. Has this been confirmed? Does this new worm, in fact, use SMTP AUTH where necessary? Will it also check the port that the user's computer is set to send mail on? So, for instance, if SMTP AUTH is required, and the mail submission port is being used rather than standard port 25, will the worm detect all this? The nice part about SMTP AUTH, though, is that there is at least a direct link to the user sending the spam. This means, of course, that ISP's will need to police their users a little better.. :) It means ISP's will have to re-think their strategies, just like AOL did. It also means it's once small step to victory for us. We are a long way from it, and please - not everybody blocks port 25 so current-day worms are more than efficient still. So I guess users will have to stop clicking that Save Password button... That is, until the worm records the keystrokes when the password is entered... *sigh* Gadi. -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] Joergen Hovland Joergen Hovland ENK
Re: Time to check the rate limits on your mail servers
Nils Ketelsen wrote: Only thing that puzzles me is, why it took spammers so long to go in this direction. Nils I am still confused why people think this is new behavior. The sky is not falling (regardles of how many stories CNET publishes claiming it is), nor should this really be relevant to how I operate my network. This is purely a systems administration issue to tackle, which I believe is beyond the scope of this list. I do find it amazing that we cannot go more than a month without raising some spam-related thread and beating it to death. Andy
Re: Time to check the rate limits on your mail servers
On Thu, 3 Feb 2005, Jason Frisvold wrote: prevents zombies from spamming. Unfortunately, it also blocks legitimate users from being able to use SMTP AUTH on a remote server.. There's a *reason* why RFC2476 specifies port 587 I assume you're referring to the ability to block port 25 if 587 is used for submission. This is great in theory, but if this were the case, then the Trojan authors would merely alter their Trojan to use port 587. If they authenticate. Modulo a stupidity built-in to Sendmail (that Claus Assman ignorantly thinks is a non-issue[*]), port 587 is not supposed to be used for endpoint MTA delivery. It's a mail SUBMISSION port, which is supposed to mean that J. Random Client isn't supposed to use it for delivery purposes. === [*] As of now, Sendmail doesn't require one of SMTP AUTH auth by default on the MSA port; it treats 25 and 587 identically (so that things like IP-based relay auth work without need for SMTP AUTH). I sent a m4-only change to the Sendmail maintainers implementing a way to make 587 allow only relay-authorized clients to send anything at all by default -- whther IP-based relay auth, or SMTP AUTH, or any other method built in to the relay-check code path. It was shot down by Claus because he simply doesn't understand the issue and doesn't think identical 25 and 587 ports is a threat. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Time to check the rate limits on your mail servers
Michael Loftis wrote: Because there are *NO* packages available that offer limiting. Free or commercial. Strange. Our mail servers have had this ability for over a year. The hard part is getting tens of thousands of legacy ISP customers to switch to SMTP auth without drowning the support center in calls. -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: http://www.inoc.net/~dev/ Key fingerprint = 1E02 DABE F989 BC03 3DF5 0E93 8D02 9D0B CB1A A7B0 Supercomputer: Turns CPU-bound problem into I/O-bound problem. - Ken Batcher
Re: Time to check the rate limits on your mail servers
Once upon a time, Robert Blayzor [EMAIL PROTECTED] said: Michael Loftis wrote: Because there are *NO* packages available that offer limiting. Free or commercial. Strange. Our mail servers have had this ability for over a year. The hard part is getting tens of thousands of legacy ISP customers to switch to SMTP auth without drowning the support center in calls. What does that have to do with SMTP rate limiting? -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Time to check the rate limits on your mail servers
Chris Adams wrote: What does that have to do with SMTP rate limiting? A lot since the original question was: Do you let your customers send an unlimited number of emails per day? Per hour? Per minute? If so, then why? and an answer was: Because there are *NO* packages available that offer limiting. Free or commercial. So I corrected it, software is available that allows you limit/tarpit SMTP connections as well as limit a number of messages a user can send in a given time period. -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: http://www.inoc.net/~dev/ Key fingerprint = 1E02 DABE F989 BC03 3DF5 0E93 8D02 9D0B CB1A A7B0 Please excuse me, I have to circuit an AC line through my head to get this database working.
RE: Time to check the rate limits on your mail servers
How come it is always about controlling the symptoms and not the illness? The vast majority of these spam drones are compromised WINDOWS machines. If the operating system and dominant email applications so easily allows the users' machines to be taken over by a third party, then there is something wrong with the operating system and the mail applications. It occurs to me that the solution is not to limit the range of destruction, but to defuse the bomb. Perhaps the focus for a solution should move up the model to layer 7. - Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 03, 2005 8:47 AM To: nanog@merit.edu Subject: Re: Time to check the rate limits on your mail servers Do you let your customers send an unlimited number of emails per day? Per hour? Per minute? If so, then why? Doing that - especially now when this article has hit the popular press and there's going to be lots more people doing the same thing - is going to be equivalent of hanging out a block my email sign. I don't understand your comment. This is an arms race. The spammers and botnet builders are attempting to make their bots use the exact same email transmission channels as your customers' email clients. They are getting better at doing this as time goes on. I think we are at the point where the technical expertise of the botnet builders is greater than the technical expertise of most people working in email operations. ...
Re: Time to check the rate limits on your mail servers
Miller, Mark wrote: How come it is always about controlling the symptoms and not the illness? The illness is the user. That is uncontrollable.
Re: Time to check the rate limits on your mail servers
On 02/03/05, Miller, Mark [EMAIL PROTECTED] wrote: How come it is always about controlling the symptoms and not the illness? The vast majority of these spam drones are compromised WINDOWS machines. If the operating system and dominant email applications so easily allows the users' machines to be taken over by a third party, then there is something wrong with the operating system and the mail applications. It occurs to me that the solution is not to limit the range of destruction, but to defuse the bomb. Perhaps the focus for a solution should move up the model to layer 7. Upgrading and/or replacing the OS for every Windows user on the planet is an educational issue. Keeping the network viable while you figure out how to do that is an operational issue. -- J.D. Falk uncertainty is only a virtue [EMAIL PROTECTED]when you don't know the answer yet
Re: Time to check the rate limits on your mail servers
Michael Loftis [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Do you let your customers send an unlimited number of emails per day? Per hour? Per minute? If so, then why? Because there are *NO* packages available that offer limiting. Free or commercial. My exim.conf calls you a liar. -- Madam, there's no such thing as a tough child - if you parboil them first for seven hours, they always come out tender. - W.C. Fields
Re: Time to check the rate limits on your mail servers
On Thu, Feb 03, 2005 at 09:21:19PM +0200, Petri Helenius wrote: Nils Ketelsen wrote: Only thing that puzzles me is, why it took spammers so long to go in this direction. It didn't. It took the media long to notice. Pete's correct. And there's another reason: spammers have long since demonstrated that they will adapt when necessary. Now that some ISPs have FINALLY, more than two years after they were warned that they needed block port 25 inbound/outbound ASAP on as much of their address space as possible in order to put a sock in this, done something...the spammers may have judged that it's become necessary. And please note: this is far, FAR from the last thing that they have in their bag of tricks. ---Rsk
Re: Time to check the rate limits on your mail servers
Creating an invincible mail client, still only addresses the symptom, and not the disease. I would contend that any attempts made to harden a mail client, will, (and have always been..), be countered with a new exploit, a new method of exploiting the system. The only way to really control spam, is to make it unprofitable, both for the hosting providers, and websites that use this as a form of mass marketing. If say, a 'top 100 domains' (or 10,000, if need be..), list of offending websites were assembled, continually updated, and used universally to null route the websites paying for these services, (and in some cases, entire blocks owned by unscrupulous service providers hosting these websites, in the case that are continually proffering these services to offending parties..), it would soon become the case that if you use spam to mass market your product, you risk losing your access to a portion of the internet. Of course, there are many lists of this kind, but what is lacking, is the willingness to launch a coordinated effort, or agreement on a proven and effective criteria for identifying how this could/should be regulated. I have heard the argument that we are not in the business of determining what should be permitted on the internet, and for the most part I would tend to agree, but I view this as a technical and not an ethical issue, and when seen in that context, the solutions seem obvious. Control spam? Attack it at the source, -follow the money- and make those that would profit from the abuse of the system accountable by denying them services. John - Original Message - From: Miller, Mark [EMAIL PROTECTED] To: nanog@merit.edu Sent: Thursday, February 03, 2005 3:37 PM Subject: RE: Time to check the rate limits on your mail servers How come it is always about controlling the symptoms and not the illness? The vast majority of these spam drones are compromised WINDOWS machines. If the operating system and dominant email applications so easily allows the users' machines to be taken over by a third party, then there is something wrong with the operating system and the mail applications. It occurs to me that the solution is not to limit the range of destruction, but to defuse the bomb. Perhaps the focus for a solution should move up the model to layer 7. - Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 03, 2005 8:47 AM To: nanog@merit.edu Subject: Re: Time to check the rate limits on your mail servers Do you let your customers send an unlimited number of emails per day? Per hour? Per minute? If so, then why? Doing that - especially now when this article has hit the popular press and there's going to be lots more people doing the same thing - is going to be equivalent of hanging out a block my email sign. I don't understand your comment. This is an arms race. The spammers and botnet builders are attempting to make their bots use the exact same email transmission channels as your customers' email clients. They are getting better at doing this as time goes on. I think we are at the point where the technical expertise of the botnet builders is greater than the technical expertise of most people working in email operations. ...
Re: Time to check the rate limits on your mail servers
We've been doing this on postfix for some time now. Michael Loftis wrote: --On Thursday, February 03, 2005 11:42 + [EMAIL PROTECTED] wrote: Do you let your customers send an unlimited number of emails per day? Per hour? Per minute? If so, then why? Because there are *NO* packages available that offer limiting. Free or commercial.
RE: Time to check the rate limits on your mail servers
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of J.D. Falk Sent: Thursday, February 03, 2005 4:35 PM To: nanog@merit.edu Subject: Re: Time to check the rate limits on your mail servers On 02/03/05, Miller, Mark [EMAIL PROTECTED] wrote: How come it is always about controlling the symptoms and not the illness? The vast majority of these spam drones are compromised WINDOWS machines. If the operating system and dominant email applications so easily allows the users' machines to be taken over by a third party, then there is something wrong with the operating system and the mail applications. It occurs to me that the solution is not to limit the range of destruction, but to defuse the bomb. Perhaps the focus for a solution should move up the model to layer 7. Upgrading and/or replacing the OS for every Windows user on the planet is an educational issue. Keeping the network viable while you figure out how to do that is an operational issue. ..or a cost issue. Most of these users are people who have decided not to spend the $40 to defend their machine at home. -M
Re: Time to check the rate limits on your mail servers
On 02/03/05, Hannigan, Martin [EMAIL PROTECTED] wrote: Upgrading and/or replacing the OS for every Windows user on the planet is an educational issue. Keeping the network viable while you figure out how to do that is an operational issue. ..or a cost issue. Most of these users are people who have decided not to spend the $40 to defend their machine at home. So you educate them as to why it would be a good idea to keep their computer secure. But in the meantime, their machine is spewing garbage -- which, as many have said, is the operational issue at hand. -- J.D. Falk uncertainty is only a virtue [EMAIL PROTECTED]when you don't know the answer yet
Re: Time to check the rate limits on your mail servers
Peter Corlett [EMAIL PROTECTED] wrote: [...] My exim.conf calls you a liar. Since I've had a few private emails about my rude and abrupt comment (although not complaining about it, which is encouraging :), I'd better explain further, just in case there were people who are curious but not curious enough to email me. Exim4 contains support for executing SQL statements in, for example, PostgreSQL. The original intent was probably so that you can do a SELECT on a PostgreSQL database for performing expansions instead of the more traditional flat files and DBMs/CDBs. However, you can also do an INSERT or UPDATE, which now allows you to maintain state between SMTP transactions. So, to perform rate-limiting, you would create a couple of ACLs: a) A deny ACL that blocks/defers mail submission if a SELECT indicates that the user has exceeded their quota. b) A warn ACL (effectively a no-op as far as access control is concerned) that does an INSERT or UPDATE to increment the user's counter. To identify a user in exim.conf, you can use, for example, their IP address, authenticated username, or some other information available from the SMTP transaction. You can either have a cron job reset the usage counters, or craft your SQL statements so that old counters are ignored. If done right, you would even get counts of daily mail volume for each individual customer in a handy SQL-queriable database for free. -- The only source of knowledge is experience. - Albert Einstein
Re: Time to check the rate limits on your mail servers
How come it is always about controlling the symptoms and not the illness? The illness is the user. That is uncontrollable. A product that doesn't work as advertised has much to do with it as well. Adi
Re: Time to check the rate limits on your mail servers
How about using SMTP AUTH and verifying the envelope MAIL FROM to match the actual user authenticating? This will make SPAM traceable and hopefully ultimately users aware that their PC is sending junk. Adi
Re: Time to check the rate limits on your mail servers
On Thu, 3 Feb 2005, Adi Linden wrote: How about using SMTP AUTH and verifying the envelope MAIL FROM to match the actual user authenticating? that doesn't work if you have more than one email address. This will make SPAM traceable and hopefully ultimately users aware that their PC is sending junk. auth is sufficient to make email traceable to your own customers. Adi -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: Time to check the rate limits on your mail servers
How about using SMTP AUTH and verifying the envelope MAIL FROM to match the actual user authenticating? that doesn't work if you have more than one email address. Wouldn't address resolution take care of that if properly configured? Some implementations allow you to specify what email addresses the user is allowed to send from, that's something that needs to be managed carefully. -GSH
Re: Time to check the rate limits on your mail servers
JJ Date: Thu, 3 Feb 2005 15:41:34 -0800 (PST) JJ From: Joel Jaeggli JJ How about using SMTP AUTH and verifying the envelope MAIL FROM to match JJ the actual user authenticating? JJ JJ that doesn't work if you have more than one email address. The words overreaching and fallacious come to mind. JJ auth is sufficient to make email traceable to your own customers. End users also would appreciate the ability to _know_ a message is not forged. Alas, I doubt much has changed since last October's BCP38 discussions, so perhaps I should not hold my breath. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Time to check the rate limits on your mail servers
On Thu, 2005-02-03 at 14:55 -0800, J.D. Falk wrote: On 02/03/05, Hannigan, Martin [EMAIL PROTECTED] wrote: ..or a cost issue. Most of these users are people who have decided not to spend the $40 to defend their machine at home. So you educate them as to why it would be a good idea to keep their computer secure. But in the meantime, their machine is spewing garbage -- which, as many have said, is the operational issue at hand. Solutions through diligent use of add-on products is not 100%. Many users spend $40 and diligently apply prophylactics, but still are compromised. Reinstalling over an existing installation does not ensure removal. Either way, this returns the OS to a vulnerable state, while costing several frustrating hours. Using a CD-ROM OS/App suite, such as Knoppix, sounds promising for this headache. It should be difficult to corrupt an OS or application when on Read-Only media. :) The number of zombies ensures rate limiting will not be effective either. Providers keeping their house in order in the face of this new strategy may be assisted by domain signed mail. This could serve to block compromised accounts with help from the provider themselves. Rejections from a third party will tell their clients they need a disinfectant. http://mipassoc.org/mass/ The wack-a-mole game needs a more agile mallet. -Doug
Re: Time to check the rate limits on your mail servers
On Thu, 3 Feb 2005 09:30:58 -0500 (EST), [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I just implemented a patch to tcpserver which allows me to limit the number of simultaneous SMTP connections from any one IP, but have not yet looked into daily/hourly limits. I know Comcast has started limiting residential customers to 50-100 emails per day, and that customers with legitimate reasons for using more than that are starting to complain. See http://spamthrottle.qmail.ca/ for a qmail rate-limiting solution. Setting a limit on the maximum number of messages/minute that will be accepted (and enforcing the limit by tarpitting, by slowing down the server response) seems to be less likely to annoy customers than setting a hard daily quota. One additional thing that I think wasnt mentioned in the article - Make sure your MXs (inbound servers) are separate from your outbound machines, and that the MX servers dont relay email for your dynamic IP netblock. Some other trojans do stuff like getting the ppp domain name / rDNS name of the assigned IP etc and then nslookup -q=mx domain.com, then set itself up so that all its payloads get delivered out of the domain's MX servers. This is a very good suggestion. I also ran into a trojan which would take the target domain name and try to guess mail servers willing to accept mail for the domain by prepending names like mx and smtp and mail1. I ended up renaming mail1 to a more obscure name after noticing that 80% of the blocked worm traffic for a given week was coming in via that one path. At Date: Thu, 3 Feb 2005 09:54:00 -0500 Nils Ketelsen writes: That, on the other hand, gets you into trouble with rather stupid Spam filters, that only accept mails from a server, if that server is also MX for the senders domain. Yes, this is stupid, but that does not change the fact, that these setups are out there. I've set up the outbound and inbound mail servers for many sites, including a Fortune 500 enterprise sending many thousands of messages each day, and have never run into a problem with outbound mail being refused because the outbound mail servers are not listed as an MX for the sender's domain. Not only are the outbound servers not listed in the MX record for the sending domain, but much of the outbound email shows a 'from' address which is a completely different domain than the domain of the server's DNS entry. I don't doubt that there might be sites blocking email based on this criteria, but such a policy is not only shortsighted, but also exceedingly rare. Kevin
Re: Time to check the rate limits on your mail servers
How about using SMTP AUTH and verifying the envelope MAIL FROM to match the actual user authenticating? This will make SPAM traceable and hopefully ultimately users aware that their PC is sending junk. Ouch .. Then spammers may start using a From: matching the SMTP auth user, and effectively joe-jobbing the user.. Ick.. And that would be marvelous! At the very least it would give the user an incentive to clean up his PC. Alternately the email account could be revoked. Adi
Re: Time to check the rate limits on your mail servers
How about using SMTP AUTH and verifying the envelope MAIL FROM to match the actual user authenticating? that doesn't work if you have more than one email address. You should know all your users email addresses. It shouldn't be too difficult to match the 'mail from' address with the user account. The only caveat would be that [EMAIL PROTECTED] would actually have to use the hotmail smtp server to send mail. This will make SPAM traceable and hopefully ultimately users aware that their PC is sending junk. auth is sufficient to make email traceable to your own customers. And how is that? There isn't necessarily anything in an email indicating that it originated from an SMTP AUTH authenticated user. While a header could be added, it isn't a mandatory thing. Adi
Re: Time to check the rate limits on your mail servers
* [EMAIL PROTECTED] (Adi Linden) [Fri 04 Feb 2005, 03:17 CET]: You should know all your users email addresses. You have got to be kidding. -- Niels. -- The idle mind is the devil's playground
Re: Time to check the rate limits on your mail servers
JF Date: Thu, 3 Feb 2005 20:37:29 -0500 JF From: Jason Frisvold JF Ouch .. Then spammers may start using a From: matching the SMTP auth JF user, and effectively joe-jobbing the user.. Ick.. Exactly. The user then loses mail sending ability, but other services remain functional. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
