Comcast Thinks About Stopping Zombies
LehiNephi writes "Comcast has finally admitted that its users are responsible for a large amount of spam, and they are thinking about how to stop it. Apparently they haven't been turning a blind eye to the problem after all. The simple, blanket approach of blocking all traffic on port 25 would have too many side effects, particularly for users running their own mail servers. However, they can block that port on individual cable modems-a sort of surgical strike. As far as I'm concerned, the sooner they implement this, the better!"
Had a user come into our help channel last night, unable to send email through his account with us since that morning (yesterday Sun 05/23) and I confirmed the server was working fine so I had him telnet to port 25 - no luck, had him telnet to port 25 on the server I use for email - no dice, had him use port 2525 - SMTP connection opened up fine.
He was using comcast for his cable modem. Said it just started that day.
We accept incoming smtp on port 2525 also since my OWN isp at home blocks port 25 (knology) so I have ot use 2525 to send email through my company email server myself.
--- www.f-theocean.com
There's a real easy way to tell the difference between a zombie and somebody running a home mail server...
The zombie will be sending an insane number of e-mails to an insane number of users constantly. No home mail server should be used to run a listserve with anything more than a hundred people or so. Therefore, bursts of port 25 are okay, camping on port 25 is a sign of trouble.
Is there an easy way to tell if your own computer is a zombie spambot?
As a mail admin stop the shit yourself.
:-)
Ban - client.comcast.net, and client2.comcast.net
Since the spammers can't forge the reverse DNS on the IP you can trust your blocking Comcast's dynamic ranges. Their business customers are not on any of the IP's that reverse to client.comcast.net or client1.comcast.net, and residential customers in the blocked dynamic ranges can relay mail to you through comcast's mail servers like they are supposed to.
There is absolutely no reason in this day and age of spam to run a legit mail server off of a dynamic IP address.
Incoming mail servers are arguable, though not allowed in Comcast's EULA, but outgoing- I can't think of a single good reason why a user needs to run their own outgoing mail server and not relay through the Comcast server.
Yes, the Comcast tech support people are complete morons, I'm a Comcast subscriber myself. I hate them too, but I can't think of a good reason to allow outbound port 25 mail. One could possibly make an argument about authenticated SMTP relays with silliness like POP before relay, but IMHO such systems are broken (and I've used them- I should know). It's better to use SASL and encrypt the whole thing.
When Comcast starts monitoring indivudal users though- I do get more than a little concerned.
DSLExtreme out here in California blocks port 25 natively across the board.
they have a registration webserver you can use to whitelist your account/address for such purposes, and monitor port 25 to make sure that you're not all about the open relay after being opened up.
why can't comcast do the same? doesn't seem that difficult to me.
better yet, why can't people patch their damn servers. if you're running an open relay, i say you're fair game. not to mention violating the draconian ToS of a massive media conglomerate. no thanks.
rawr.
It doesn't even have to be that difficult. Just block port 25 by default. If someone calls up and asks for it to be enabled, do it free of charge, no questions asked. Now everyone who wants to run a mailserver can do so painlessly, but the average joe zombie wouldn't be able to spread spam because port 25 would be off for him by default. I bet this would stop 90%+ of all the nasty zombie spam.
...they're concerned about having adverse effects on people running mail servers???? I could have sworn we weren't allowed to run any type of server (HTTPd, IRCd, anything) through their connections. My friend runs a HTTP server through his, but I've never run one through mine for more than a day at a time, being the good customer I am.
It always seemed to me that if they didn't want people hosting servers, they'd block the ports from the beginning. Don't get me wrong though, I'm glad to see they're finally cracking down on spam, and I'm glad they're not going to just block port 25. Maybe Comcast isn't as horrible as everyone says they are.
My friend tried to run a mail server off of his comcast connection awhile back. He could recieve mail fine, but anytime he tried to send mail it would fail. I always assumed 25 was off anyway.
Etiquette is etiquette. He kills his mother but he can't wear grey trousers.
We in the anti-spam community have been yelling this for a while. Since early 2004, most spam is sent through unwitting zombies (compromised Windows hosts) that are remotely controlled spam bots. This is not just an open relay issue. These hosts are hacked in an automated fashion and loaded with spamming software.
Now obviously, there's a lot an ISP can do about this and it doesn't have to be as drastic as blocking port 25 outright. Users which generate suspicious amounts of TCP port 25 traffic could be reassigned IP addresses from a probation-class pool. That is, hosts within that netblock might not be allowed to make port 25 connections, or might be advertised to the world as block-on-sight.
Yeap. This is the only way to stem the traffic. People can still run their own mail servers, but all outbound connections should go though the ISP. Afterall, it is not like it is a privacy issue (they can sniff the packets anyway, so bypassing their SMTP server does not help you!)
If they're bouncing off zombies, ostensibly the zombie server is a virus or trojan or whatever, which means it could be written to utilize whichever port whoever codes the thing wants.
Just like squid proxying, why not redirect port 25 transparently to a Comcast mail proxy. This proxy could queue mail and essentially throttle outgoing mail or reject if spam is detected.
I have two primary requirements for an ISP. (1) must not block any ports for any reason. (2) must provide at least one static IP.
AOL blocks game ports, so they can charge you $5 more per month for opening the ports. They were one of the first to change the role of ISP from utility to controlled collector of optimal revenue. I have for at least 5 years told everyone to get rid of AOL. Unfortunately, today, people have come to accept the idea that it's ok for an ISP to block ports.
As for the zombies, the ISPs should try:
Open Standards Portal
"... Comcast's network engineers would like to be more aggressive. But the marketing department shot down a ban on port 25 because of its circa $58 million price tag--so high partially because some subscribers would have to be told how to reconfigure their mail programs to point at Comcast's servers, and each phone call to the help desk costs $9."
It's interesting how such a simple technical change can wind up costing so much money. It's amazing how such small, seemingly innocent details add up to be monstrous problems!
This is really a dumb idea because you can send mail on any port you want. The packets don't even need to be assembled until they reach their destination. The only solution is to certify mail servers. Any server caught sending spam is responsible on the certified network.
I've seen some different approaches to block mail.
The one my ISP (a University) use it to black any incoming tcp connection with dst port 25. This stops spammers to use any badly configure mail server from beeing used as a relay. I can still use any mail server i want to send mails though, i can even run one of my own. What i can't do is handle incoming emails for my own domain. They also monitors how much mail is sent, and if your computer seems to send out "too much" mails, you'll get an email from the sysadmins asking you to explain what's up.
The other approach I've seen used by xDSL providers here is to block any outgoing connections to dst port 25. This way you could run you own mail server for you domain, but you must relay all sent email through the ISP's smtp server.
I think both solutions offers some protection against spammers, without putting to mych restrions on the users. Not sure which one is most effectiv e though, if any.
This sucks for people with a laptop who frequently plug in to different networks (starbucks, airports, etc). Having to change what mail server I point to every time I plug in my computer is really painful.
A landmine system would be relatively easy to implement - you set up a few hundred landmines and block any customer IP who sends a spam to a landmine. It's similar to honeypots, although you treat the accounts like mines where even a single email will get an address temporarily blacklisted. Once blacklisted, you can shut off port 25 for that IP, disconnect their session for 30 minutes, or do whatever you want. The Streamlined Blackhole List server could be used to create a landmine database with a spread of 1 to instantly identify new hosts.
Even better: Make a simple web-interface where you setup your like using, requireing you to type in your customer number or whatever. They might already have some online-service that can be used. Of course include one of these anti-automatic-gifs that most free webservices use.
Cheers
Actually, their reps have said during calls that mail servers are not officially supported, but that they willingly turn a blind eye.
Given that they are the only broadband I can get and I do run a mail server for any host of reasons; the targeted approach would be the only acceptable method.
The ISP I work for (name withheld to protect the proactive) has what I consider to be a good policy for handling bots. I think it is good because I came up with it myself. Any host that we get a complaint about is portscanned (all ports are scanned). The output from nmap is then fed into amap for application fingerprinting and mothra to grab banners. We then suspend the customer's internet access until they clean up the computer. On the whole port 25 thing, ever day we find systems that are running SMTP servers on bizarre, very high ports.
"Who's going to believe a talking head?" - Herbert West
Even if Comcast goes forth with this, it's just a drop in the bucket. Maintaining an open database of websites known to propogate spam, then blacklisting them would do more.
Of course, that'd require *real* work and verification, as those sites move all the time. Still, it's possible.
The point is, this is lipstick on a pig. No amount of port blocking is going to stop dumbass users from being turned into zombies, short of pulling the plug or blocking their access to a database of known-to-be-harmful sites.
Here's an idea: how about disabling it like they are considering, and then putting them on a probationary term? They'd be able to continue with Comcast, but their traffic would have to be filtered through the blacklist for, say three months?
I know it's not popular to talk about censoring sites, but it's wasteful in terms of productivity and economics to have to clean up after these zombies all the time. Perhaps the "denial of service" should be applied to those infected, say after two incidents?
Just thoughts. I applaud Comcast for thinking about it, but can't help but shake my head as to the likely effectiveness.
Given the gigantic expansion of broadband, I'm surprised that cable / dsl modems don't just do NAT and other firewalling techniques by default. It certainly seems like something the industry should push. Sure, today it's spam everyone's worried about, but when WindowsProcessX on port whatever is compromised next Comcast will have to start all over again blocking ports, unless the hardware each user had prevented this. As an added bonus, your "technical" users could configure things to their hearts' content too.
To provide services (such as incoming SMTP, SSH, etc.), one can rent a co-located box (or a User Mode Linux virtual colo) offsite, drive an outbound encrypted tunnel to that, and pass packets through the outbound connected pipe for all the ports and services blocked by Comcast. Linux servers can stay completely within the TOS. Dynamic IP addresses can change with no changes to the DNS tables. The best part of this is that if Comcast ever gets fiesty and NATs their users, there will be no interruption of service. Since you can choose whatever ports you want, an outbound tunnel will always work. At the user level, you can still use the web, download files, etc. without using bandwidth at the colo.
I am currently setting this up now with a local UML colo service, www.pdxcolo.net. $20/month, which is admittedly not free as in beer, but the cost is less painful than the enormous amount of Comcast zombie spam. And the colo can be shared, so real cheapskates can reduce the colo cost further.
I am glad Comcast is finally removing their heads from their posteriors about this. Maybe with some oxygen to their brains, they can make even more smart decisions. :-)
Keith Lofstrom server-sky.com
Comcast actually did something I agree with. I'm stunned.
Surgical strikes are a good idea--they stop the damn zombies without screwing over everyone else. Tho I think only blocking port 25 for zombies isn't going far enough.
IMO, Comcast should block the MAC addresses of spyware/virus infected zombies and send letters to these people, telling them that they'll only be unblocked if they can present proof that the virii/spyware are off their computers and that they've taken measures to ensure that it never happens again.
I support the Center for Consumer Freedom
I would dearly love it if Comcast (nee any and every ISP) offered a spesific /dev/null address that I could use with icmp-redirect like clarity.
When I see a bunch of bogus packets slam into my box that have no reason to exist, I would like to be able to automagically do the IP equivalent of call blocking.
Sending an ICMP-REDIRECT-like message out in response to a bogus packet should be snuffled up by the ISP equipment and taken as a "call block" request against a particular peer address.
So if I rig up my firewall to icmp-redirect to some magic address (say 0.0.0.0, which is never legal in a redirect), the upstream router should process it as, say, a 24 hour ban of packets from that address to my address.
Were such a thing to become common, the ISP could forward that ban on to the next upstream peer and so on until the "well behaved" router closest to the miscreant would be keeping the wastage off of the backbones entirely.
Since it is a poit-to-point ban it would be rather effective without letting malicious third parties do too much damage unless they could get common-segment with one of the parties.
Talk about killing a DDOS at the diverse roots.
Anyway, it would need a little refinement to keep the haxors next door from pretending to be me and cutting all of the sites they sniff me using, you know, check mac addresses or require me to use an activation squib from my firewall from time to time....
But it should be easy and safe enough once the nearest "Real" router got the do-not-call packet.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
What I would love to see somebody come out with is a provider-side web configurable firewall.
:)
While I am a student at utexas.edu, I must speak up about https://firewall.tamu.edu/. Apparently the resnet team in College Station filters the heck out of their residents' hosts, but allows them to open their boxes up interactively on the fly without having to call tech support. This is all based on what I have gleaned from the TAMU CIT online writeups, so of course dont quote me on it. While I do not have access, maybe some kind A&M soul will offer forth what is contained inside?
Hooray for BSD and Snort inline! Apparently TAMU also doing some really cool IDS work and dynamically switching ACOs to non-routable VLANs and providing fixes via a web interface for compromised hosts. I heard about RIT doing something similar with their homebrewed ActiveX-based development during last July/August during the big RPC craze. I wish more universitys would implement similar solutions.
Section 9's cool too. It says that you waive the right to sue them in a real court, but instead will have a hearing before a "neutral arbitrator".
You can get the right to sue in court back, or alternatively force them to waive the right to sue YOU in court. See battle of the forms for more info.
The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
My father had BellSouth DSL, and they've started blocking Port 25 for outgoing mail. This means that he couldn't send mail through the third-party mail server that he's been using for years. I don't want to have to change his settings (and he doesn't want to give people a new address) every time he has to change ISPs, so he pays a bit of money to use NetIdentity.com for his mail.
Since BellSouth wouldn't use some sort of reasonable measure of WHO was abusing the service instead of treating everyone as a spammer, we switched him to another DSL carrier. I think it's unreasonable to expect everyone to have to use ONLY the mail server of the ISP.
BTW, BellSouth said they WOULD open Port 25 if my father would pay double the money for a "business-class" DSL account, which shows me that it's more of a marketing distinction on their part than a distinction with a truly technical justification.
All they nned to do is to restrict SMTP outbound connections to their own mailservers. Forcing traffic through their won machines will qucik;ly point out who the abusers are, and they can likewise filter for viruses and worms preventing propogation.
I work for an ISP that did exactly this. Suprisingly enough, there were little complaints, short of people who don't check their email and weren't aware of it until they can't send email.
Otherwise, it's been a great help to make sure that our email servers don't get blacklisted by AOL or other big companies because of traffic coming from our networks.
So far, it's been a positive experience.
I'm trying to convince the powers that be to redirect outbound SMTP from all but our business customers and our own server farms to our local SMTP servers. That way we'd force all our normal customers into a mandatory Smarthost configuration. The only problem I've found while trying to get this going is a problem with redirection on Ciscos. It's been a few weeks since I stumbled across it. It's something about the redirected packet using the wrong source IP when dumped onto the wire facing the target of the redirection. Something like that. With a simple Linux firewall this wouldn't be a problem. I vote for redirection personally. Still this adversely affects users using SMTP authentication.
I am a Comcast customer, and I'd hate to have all
my connections proxied or blocked, but I don't see
the harm in making people like myself call a phone
number to supply a list of ports to unblock/unproxy.
Them: "How may we help you?"
Me: "Please unblock TCP port 25, both ways"
Them: "OK"
After all, why should millions of people have tens
of thousands of unneeded ports available for abuse?
Ah, but why should an ISP care about impact to services it doesn't permit on its network anyways (at least for residential non-business users)? Soon every ISP will block 25/TCP outbound for residential users and spammers will have to find another way. They will, but at least it will put a crimp in their efforts.
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'
Optus (Australia) has a very good system.
Blanket block of all outgoing port 25 traffic. If you want your port 25 enabled, you go to a specific section of the Optus website, enter your login/pass and click "I Accept" on an agreement type thing, and click "Unblock my port 25".
Done. Techies who want their own mail dealies get them, and people who get infected and deployed as spambots go nowhere.
--
The last digit of pi is four.
Not true, I have run my domain mail server for several years ( since '98 ), and before switching from DSL to Cable ( Comcast ) , I asked if they had a problem with me running my own SMTP/POP3/Web servers over their connection, and they said no. Not only that, I have it in writing, so they'd better not try and renig on our agreement.
I can't afford a sig!
The problem is that there are too many zombies. With MyDoom I immediately saw a jump in SPAMs I get. I get a couple messages an hour on one account.
Comcast itself could transparently proxy all web access to a server that outputs that information.
I think it is a good idea.
Furtermore, I think that Internet providers should implement a standard method for reporting infected PC's by IP address and timestamp. They can forward this message to their customer.
Why not just transparently redirect port 25 the ISPs MTA? Just like a transparent Squid Proxy. That's what I do here at work. As long as the MTA is configured to relay for that IP range there shouldn't be any problem. Yes, the mail headers will have an extra hop; but that hop can scan for mass mailings, viruses or whatever. That way it is controllable in one central location.