Securing port 25 for Telnet
After quite a lot of Googling, it left me even more confused, as a lot of contradicting info is out there.
Problem: Anyone can connect to telnet port 25 and abuse internal mails (Relay access is not authorised) As an example if the server is hosting mails for xyz.tld:
Anyone could send email from jane@xyz.tld to joe@xyz.tld without any authentication.
How do I prevent, secure this? Is it possible to force authentication on port 25, and if yes what is the impact of this?
-
Email to locally hosted domains are always accepted without authentication. That is how internet email works. Port 25 is the port that email comes in to your users on and it comes from all external sources. All those servervices do not have authentication data. Its the only way your users can get emails. You have to reply on spam tools like spamassassin and your exim config to assist in separating the crap out. 0 -
This is where SPF and DKIM are SUPPOSE to help. SPF and DKIM are called Email Authenticators because the process is SUPPOSE to provide a system to verify that a system that sent a message is really SUPPOSE to be sending that message. As you can see, there a lot of suppose to's in this. Trouble is, the adoption of strictly verifying these authentication methods at the receiving end (not just your server or cPanel servers, but ANY mail server) is very poor. That and the fact that people still want to hold onto ancient and archaic methods of distributing mail means that there is still a significant email population that does not want this verification to be very strict. 0 -
My concern is more linked to the fact that anyone can Telnet on 25 and pretend to be someone else and send internal mails. i.e.: telnet mail.anydomain.com 25 EHLO [xxx.xxx.xxx.xxx] mail from: rcpt to: data from: Big Boss CEO to: Accounts Department subject: Please pay the below Lorem ispum dolor sit amet... .
So default cPanel: Mail is internal and is not relayed: no auth needed and the mail will be delivered. No DKIM or SPF in play here as they are normally not applied to internal.0 -
Yep! That's the way SMTP works. Every SMTP server is going to be "vulnerable" to this. Those sextortion emails everyone is getting... the ones that say "Hey look, I'm sending this from your email address"... it works on this same principle. I can send an email from any [plain]@cpanel.net[/plain] email address to anyone. There's nothing to stop me from doing that. Hopefully (fingers crossed) the recipient that I sent that message to would have Email Authentication checks in place enough to show that I didn't really connect from a [plain]cpanel.net[/plain] mail server when sending that message and either reject it or flag it as spam. The only way to govern that the envelope-sender is really who they say they are (or at least as close as possible) is with Email Authentication. But I've already expressed that soapbox in the reply above. Keep in mind - Email Authentication - here is referring to SPF, DKIM, (and I suppose DMARC). Not SMTP Authentication - which is where you have to present a valid username and password to relay out mail through the server. Email Authentication is meant to verify the authenticity of the email sender - that they are who they say they are. SMTP Authentication is meant to allow relaying of outgoing mail. These are two completely different things. 0 -
@SPaReK, Thank you for the comprehensive reply. Relaying on my server is not allowed, so one domain sending to another one even hosted on the same server is not an issue using this method. When using @cpanel.net example above I could a mail for anyone to anyone within that domain. The mails will be considered as a local delivery thus not going thru spamassassin, or SPF, DKIM checks before accepting the message for delivery. Perhaps a very noob reaction, but I find this absolutely puzzling. 0 -
Hello @divemasterza, You can find discussion of this topic on the following thread: Thank you. 0
Please sign in to leave a comment.
Comments
7 comments