Re: [Asrg] article: port 25 blocking

Larry Seltzer wrote:

> > Right--there's no point in blocking port 25 if you just open up another 
> > port to plain unauthenticated SMTP....
>
> Don't get me wrong, this was just a crazy off-the-top-of-my-head idea and I
> can certainly believe I'm wrong, but this reasoning doesn't persuade me.
> There's no reason to believe that there would be a few common ports. 
>
> Let's say I want to let my team of users access the mail server from their
> ISP accounts. I set up SMTP on (pull number out of ass) TCP 48207. I have to
> set this up on all their clients (and open it up on any firewalls between
> us), so for practical purposes it can't be too many of them.
>  
Let's start with why this proposal won't work.

Basically, it's security through obscurity. And in this case, the 
obscurity will only last until the first port scan. There are only 65535 
ports in total; there are plenty of tools out there which will scan them 
all in a couple of minutes; adding code to go back to each open port and 
check for an SMTP server is a trivial addition.
Like every cable modem user, I already get port scanned regularly by 
malware. As soon as any significant number of SMTP servers start using 
random unadvertised ports for unauthenticated SMTP, the port scanning 
0wn3d machines already out there will find out what those ports are. The 
spammers will simply add the port number to each address on the lists of 
open relays they already exchange with each other.
Remember, they don't care if the port scan sets off alarm bells and gets 
the scanning machine's owner into trouble, because they're using 
botnets. In fact, good luck even detecting a port scan when it's coming 
from 10,000 different IP addresses over the course of a month.
So all you'll have done is slowed the spammers for maybe a few weeks or 
a few months, depending on how long your scheme takes to become popular 
and how long it takes them to take their existing port scan code and use 
it to scan your server. Then you'll be back to square one, except you'll 
have the added support burden of having to explain to grandma what a 
port number is, and why it's different for her account than it is for 
the account of her friend that helped her set up the computer, and what 
she should do to use her e-mail client that doesn't allow arbitrary 
random port numbers to be entered.
> Assuming the ISP hasn't blocked that port as well (ISP's don't generally
> block arbitrary ports) it should solve the problem of getting through the
> port 25 block.
The *problem* is spam. Blocking port 25 was supposed to be a *solution*. 
Instead, it causes a problem, and doesn't stop or slow spam for any 
significant period of time.
> A new worm could be written to monitor all communications looking for SMTP on 
> non-standard ports, but this is a lot
> of work when there is still low-hanging fruit out there.
>  
It's also a lot of work when you can just port scan the server, or use 
the list of server:port combinations you obtained from your spamware 
supplier.
So, it won't work. Now for some additional reasons why it's a bad idea.

First off, plenty of places only allow connections on known ports. The 
company I work for has a hard enough time getting clients to allow VPN 
connections, let alone SMTP on port 13281. There's a reason why IPSec is 
gradually disappearing and being replaced by SSL-based VPN.
Secondly, while it's common for software to implement SMTP 
authentication, it's uncommon for it to allow the user to set whatever 
random port number he likes. My phone won't allow that, for instance.
Third issue: one of the reasons we have ports in the first place is so 
that you don't get someone's FTP data session coming in on the port your 
SMTP server is connected to. There's a finite set of ports available, 
and if you start using random *necessarily undocumented* ports for your 
servers, the chance of a client talking protocol X hitting a server 
talking protocol Y increases. Better hope the client checks the server 
is talking the right protocol, and doesn't dumbly retry, or your mail 
server logs are going to fill up pretty quickly.
For problem four, let's imagine you're in charge of security for a big 
ISP. You have hundreds of corporate customers, so you'd like to be 
pro-active and watch out for intrusion attempts and have the system warn 
you. Well, now you have the problem of distinguishing between 1,000 
incoming legitimate SMTP connections on random ports caused by company 
employees sending mail via company servers, and a port scan from a 
botnet. The only way you'll be able to do it will be to do traffic 
analysis on every single incoming TCP/IP connection. That might make 
Cisco happy, because they'll be able to sell a ton of new routers, but 
it probably won't make anyone else happy.
Except that ironically, this exact same traffic pattern (incoming TCP 
connections on random ports eventually talking SMTP) is exactly what 
you'll be wanting to catch when it comes from botnets, because then 
it'll be spammers probing your customers for SMTP servers on random 
ports, rather than your customers connecting to their SMTP servers on 
random ports. So even traffic analysis won't help too much, because the 
new normal traffic pattern looks exactly like a botnet port scan.
Problem five is that another use for well-known ports is rate limiting, 
or to look at it from the other side, quality of service. Suppose you're 
in charge of networking for a major corporation. You'd probably like to 
be able to allocate a fixed minimum amount of bandwidth to SMTP, so that 
your employees can still send and receive e-mail no matter how many 
inconsiderate clods are downloading Linux ISOs via FTP. Except that now 
SMTP might be on any random port, so that's going to be more difficult 
than it used to be.
In fact, you don't even need to be a big company to have that issue--my 
home router has QoS features so I can make sure e-mail goes out even if 
the spouse or kids are uploading or downloading movies. Or at least, it 
does so long as the services I want to ensure have bandwidth, are on 
known ports...
Problem six is that it encourages spammers to generate more traffic and 
penetrate more systems. Even if we assume it does slow them for a few 
months, it's trivially defeatable if they do lots and lots of port 
scans, so guess what they're gonna be doing next year? I for one would 
rather not incent mass port scanning by botnets.
I'm sure the above isn't an exhaustive list of problems either. So, why 
not do the simpler thing that also happens to be more effective and less 
disruptive, and put authentication on your SMTP server?
I'm not saying that port 25 blocking is worthless; it's probably a 
reasonable idea under specific circumstances. That is, if a big ISP 
detects a suspicious number of outgoing SMTP connections from one of 
their customers to random machines on the Internet, it's probably worth 
blocking port 25 for that customer until the customer can explain what 
they're doing. It's probably better still (and simpler) to rate-limit 
SMTP, though.
Because of port scanning, blanket blocking of port 25 everywhere isn't 
*sufficient* as a solution to the spam problem. And since you can do 
authentication on SMTP on port 25, I think it's pretty clear that it 
isn't *necessary* either. So, we have something which is neither 
necessary nor sufficient to solve the spam problem, which causes all the 
headaches listed above. I think that qualifies it as a bad idea.
Since all the technical talk about ports and protocols is boring, I'll 
end with an analogy any random person should be able to appreciate: If 
you find that people are walking through your front door and stealing 
from your house, you can probably stop them for a little while, or at 
least slow them down, by bricking up the front door and leaving the back 
door open instead. But you know, it's not going to stop them for long, 
it's going to be a pain in the ass for you, and the real solution is to 
put a lock on the door.

mathew

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg