On Thu, 3 Feb 2005, Suresh Ramasubramanian wrote:

On Thu, 3 Feb 2005 11:42:55 +0000, Michael.Dillon@radianz.com <Michael.Dillon@radianz.com> wrote: http://news.com.com/Zombie+trick+expected+to+send+spam+sky-high/2100-7349_3-...

...

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 up@3.am http://3.am =========================================================================

up@3.am 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 up@3.am http://3.am =========================================================================

On Thu, 3 Feb 2005 09:30:58 -0500 (EST), up@3.am <up@3.am> 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

On Thu, Feb 03, 2005 at 05:42:07PM +0530, Suresh Ramasubramanian 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. Nils

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 up@3.am http://3.am =========================================================================

Hi!

...

CNET reports http://news.com.com/Zombie+trick+expected+to+send+spam+sky-high/2100-7349_3-... 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...

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. Bye, Raymond.

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.

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

----- Original Message ----- From: "Gadi Evron" <ge@linuxbox.org>

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

On Thu, 03 Feb 2005 17:54:28 +0200, Gadi Evron <ge@linuxbox.org> 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 XenoPhage0@gmail.com

On Thu, 03 Feb 2005 12:26:55 -0500, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> 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 XenoPhage0@gmail.com

On Thu, Feb 03, 2005 at 12:26:55PM -0500, Valdis.Kletnieks@vt.edu 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

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

----- Original Message ----- From: "Jason Frisvold" <xenophage0@gmail.com>

On Thu, 03 Feb 2005 17:54:28 +0200, Gadi Evron <ge@linuxbox.org> 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 XenoPhage0@gmail.com

Joergen Hovland Joergen Hovland ENK

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" <ge@linuxbox.org> To: "Raymond Dijkxhoorn" <raymond@prolocation.net> Cc: <Michael.Dillon@radianz.com>; <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.

Once upon a time, Robert Blayzor <rblayzor@inoc.net> 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 <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

Michael Loftis <mloftis@wgops.com> wrote:

Michael.Dillon@radianz.com 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

We've been doing this on postfix for some time now. Michael Loftis wrote:

--On Thursday, February 03, 2005 11:42 +0000 Michael.Dillon@radianz.com 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.