SMTP Authentication (Sophos as smtp relay to internal Exchange server)

The Bee said:

Right now is possible to send emails using SMTP port (25) from one or our domain's user accounts to any another of our domain's user accounts without authentication. Which is, of course to me, a very big security vulnerability. (I tested it with telnet from outside of our networks... like if I were an attacker).

Please read my post about SPF! This is one possible way that you can use!

https://en.wikipedia.org/wiki/Sender_Policy_Framework

Regards

mod

Most mail servers will accept mail on port 25. How else would I be able to send mail to one of your users?

Telneting to a mail server and entering a valid user with data etc and a mail from will result in the mail server accepting the mail (either from your domain user or a complete stranger)

Are you getting this mixed up with an open relay?

Hi @all,

please remember, OP is an Exchange admin!

Louis-M said:

But it's no big shock to be able to telnet to a mail server and send an email to a valid recipient.

If my only emailaddress is test@example.com and example.com is hosted on my exchange, and I'm in the Internal network of my utm,  mail from: test@example.com  -> rcpt-to:  community@sophos.com will work.

But if I choose to use mail from: mod42@example.com -> rcpt-to:  community@sophos.com , that will wirk too and that could be for Exchange Admins a big shock, because they expect that I can only send emails from my only emailaddress test@example.com but not form mod42@example.com.

I think/guess thats the issue what the OP mean with SMTP Authentication.

Otherwise it's like Louis-M and BAlfson said:

If you want to try to prevent that someone from the internet uses your emiladomain example.com as a senderaddress, please use SPF / DIKM.

If you need guideance for configuring SMTP Proxy , please use the link from BAlfson's post.

Greetings

There is still a bit of a mix up going on here. Let's forget about the UTM for a minute and deal purely with exchange. From the internet, people can telnet to the exchange server, add a valid recipient, data and a message from.

Exchange will accept that because if it didn't, how would you receive email for that recipient. We are mixing up receiving email and being able to send email from the exchange server here. Now depending on the way the exchange server is setup, it may try TLS first, a reverse lookup etc but in general, it will accept mail for a valid user. If the user doesn't exist, it will not accept the mail returning "invalid recipient". This will be the receive connector working here.

On the inside of the exchange server network, if the user can send mail from a client without authentication, there's a good change the exchange has a send connector based on IP authentication and the inside subnet is included. That's worth checking out as only certain hosts required should be allowed that.

Now, if you have a user outside who can connect to the exchange server, send email to a recipient outside of the organization without authentication, you have a problem. That is what is known as an open relay and it won't take long for others to find it. You may even find yourself quickly blacklisted if that is the case.

This post is getting mixed up between receive and send connectors, authentication and relaying regardless of SPF, DKIM & DMARC etc.

Hi Louis-M,

in fact the situation is different. My issue is that I'm able to send emails from internet as a sender of my domain (without authentication) to any recipient email address (valid or not) to any of my domains.

Let's say that my domains are example.com, anotherexample.com athirdexample.com that resolves to the UTM's Public IP address (UTM acting as SMTP relay to our internal Exchange server):

an "attacker" (me, in this case), can telnet to the SMTP server of example.com:25 and send emails as sender: me@example.com,  to any email address on example.com and/or anotherexample.com and/or athirdexample.com,

And I can do that using a valid/existing and/or invalid/non-existing SENDER and/or RECEIVER for any of those domains.

(That's why SPF won't do it here, because SPF well tell other servers who is authoritative to send emails on behalf of "example.com", but being that, in fact, "example.com" is the one used to send emails from... SPF, AFAIU,  is not relevant in this case.

That's also why external SMTP servers are not involved in this issue, because they will try to reach my SMTP servers with emails with a sender other than any of my domains. )

I guess I haven't explained this properly before, maybe is a bit more clear now?

thanks!

I feel your pain. What you are referring to is spoofed sender address, and there's really not much you can do about it with UTM. SPF helps, as message from a sender using you domain originating from and IP that is not explicitly allowed to send messages on behalf of your domain should get quarantined. Of course, this depends on how you configure your protection for it to work. DKIM also helps, as a spoofed message would not be signed and therefore the spam score would rise. You could try to blacklist *@ example.com, *@anotherexample.com and *@athirdexample.com (domains as per you example) but this would be only half useful, since as already proven by BAlfson an attacker could still spoof sender addresses since blacklisting would only match MAIL FROM information and not anything past DATA. DMARC could also be a solution but is also not implemented on Sophos UTM.

IMHO, your best bet right now is SPF and DKIM.

EDIT: Reading a little more, and it appears even SPF won't cut it as well, as it will also only be checked before DATA. We do need Sophos UTM to add the functionality to scan messages even after DATA in order to stop spoofed messages. You could vote for BAlfson's idea and hope for the best, but I don't see any major changes being integrated into UTM as of now, with SFOS receiving the most attention and all.

Regards,

Giovani

Ok, anybody should be able to send mail (either from a client or telnet) to your internal authorised receive domains.

What shouldn't happen is they can send to a non existent user. If that is happening, you must have a "catch all" configured otherwise the mail server would bounce the mail for an invalid recipient. Likewise, they shouldn't be able to send to a non existent receive domain on your server either.

But as I've stated, if you have user1@example.com, I would expect you mail server to accept a mail TO user1@example.com FROM joe@bloggs.com via telnet.

Louis, as far as I understand, Bee's worry is that anyone can connect to the UTM and post a message to user1@example.com (an internal user) using user1@example.com as the FROM address. If this message passes basic antispam checks it will reach users mailboxes as a message sent from himself, or worse, as a message sent from the CFO, for example, which is actually a sender spoofing. Sophos UTM only checks the recipient for its existence and has no mechanism to prevent outside clients to spoof the sender address, not entirely. This is actually something that happens a lot, unfortunately. Other antispam products, including Sophos Email Appliance, are able to check the message in P2 (after DATA) so you can block external messages that comes with senders from protected domains. Unfortunately UTM is only able to check this information against P1 (before DATA), so a message can be accepted with a bogus MAIL FROM, pass initial protection and blocking, and have its FROM modified later on in P2, thus deceiving the recipient. This is quite inconvenient and it's largely used for phishing attacks. Am I in the right track here, Bee?

Regards,

Giovani

Hi Giovani,

you are right.

That's why SPF won't do it here, because the attacker will be using the authoritative SMTP server for the domain example.com, which is my UTM, to send emails using telnet:

telnet example.com 25

From: existing_user@example.com 

To: bigboss@example.com

or 

To: bigboss@anotherexample.com

and that applies to any existing and non-existing accounts. As well as inter-domains' accounts. 

Please remember that: an attacker can currently send emails using my SMTP server on port 25, with a FROM email address of any account on my domains and with a TO email address of any account on my domains. And that applies to non-existing email addresses.

This has nothing to do with any domain to which my UTM is non-authoritative for.

That's why I was hoping to have any kind of SMTP Authentication for sending emails FROM any account of any of my domains. In that way if an attacker wants to send emails using my UTM:25, FROM an account on any of my domains TO another account on any of my domains, a user/pass (or whatever other form of authentication/authorization) should be required.

 Regards.

"That's why SPF won't do it here, because the attacker will be using the authoritative SMTP server for the domain example.com, which is my UTM, to send emails using telnet:"

Not really. When receiving a message UTM is relaying messages, not originating them, so UTM's antispam would check the originating IP address against the SPF record of the domain supplied in MAIL FROM. With SPF you could block this type of spoofing, but you don't see much of this kind of spoofing anymore, exactly because of SPF. 

The problem is that UTM does not do any checks AFTER P1, so an attacker could use a valid external domain with valid SPF and RDNS record in MAIL FROM, pass SPF checks and then change the FROM address in P2. Attackers do that by using hijacked mail servers and unfortunately there are many, many vulnerable mail servers out there that are being used for spoofing. That's where the real problem lives. With a sound SPF record you can stop someone from using your domain in P1 (MAIL FROM), but you can do nothing if they change the FROM address in P2 (FROM after DATA). 

What you want to achieve, which is authentication BEFORE relaying for a protected domain just does not exist. Sophos UTM is not the authoritative destination, so it HAS to accept any messages for the domains it is protecting. There's no way UTM would ask for authentication before accepting a message for a known domain. This would break relaying altogether. The problem is that UTM currently lacks the ability to stop an attacker from spoofing the sender address after DATA. So as long as the message originates from a valid mail server with its own domain, SPF and rDNS records, there's nothing you can do to stop spoofing from happening after DATA. Do note that this is a VERY specific spoofing and the issue you are originally referring to CAN be stopped with the right SPF record.

And just to make things clear: you are under zero risk of someone using your UTM to relay messages to the outside world. That kind of relaying would be explicitly blocked, as only your Exchange server should be allowed to relay messages through UTM to the outside world.

I truly hope I was able to make myself clear. English is not my native language, so please forgive me if I'm unable to express myself as I would like to.

Regards,

Giovani

Got agree with Giomoda there. Forget about the UTM for the moment and concentrate on exchange. You need to look at your send connectors and make sure that only authenticated users can use it. Specifically the send connector on port 25 which probably has a 0.0.0.0 to allow all ip's to use it.

The only hosts that should be able to use an IP based send connector should be other servers that can't use authentication. That way, you avoid simple spam programs that somebody could introduce on you LAN. All other submissions should be authenticated inside and outside. Once that is sorted, bring the UTM into play and only allow the exchange server/s to use the smtp proxy and then use the exotic stuff like SPF, DKIM & DMARC.

But if you have an open relay, I'm suprised you ain't blacklisted already as it doesn't take them long to find you.

Hi Giovani,

thanks again for your reply!

giomoda said:

"That's why SPF won't do it here, because the attacker will be using the authoritative SMTP server for the domain example.com, which is my UTM, to send emails using telnet:"

Not really. When receiving a message UTM is relaying messages, not originating them, so UTM's antispam would check the originating IP address against the SPF record of the domain supplied in MAIL FROM. With SPF you could block this type of spoofing, but you don't see much of this kind of spoofing anymore, exactly because of SPF. 

But if I telnet to the UTM, the UTM is the one sending the email, there's NO other server involved.

On all my tests, the only servers involved are the UTM and the exchange. (Well, unless my computer is considered an email server, which I'm not 100 % sure on that...)

I already have a TXT record for some of our domains like:

example.com TXT record: "v=spf1 ip4:my_UTM_public_ip a:another_allowed_domain.com -all"

That will tell the SMTP servers that the only servers allowed to send emails on behalf of "example.com" are my_UTM_public_ip and another_allowed_domain.com

About:

giomoda said:

What you want to achieve, which is authentication BEFORE relaying for a protected domain just does not exist. Sophos UTM is not the authoritative destination, so it HAS to accept any messages for the domains it is protecting. There's no way UTM would ask for authentication before accepting a message for a known domain.

Remember that what I want to achieve is that when I send an email from: example@example.com (my domain), the Sophos will not allow me to do it UNLESS I'm authenticated or I come from my internal Exchange.

This is not about destination but about sender/source. 

From my point of view, when I use telnet (in fact I use curl, but doesn't matter...) and I enter the field "FROM:", the UTM should see that the email belongs to a domain which he is "authoritative" for, and reject/abort the email. 

About the DATA, yes, I saw that behavior on my tests, but for now, is not that important to me... although is still important.

Regards.

Hi Giovani,

thanks again for your reply!

giomoda said:

"That's why SPF won't do it here, because the attacker will be using the authoritative SMTP server for the domain example.com, which is my UTM, to send emails using telnet:"

Not really. When receiving a message UTM is relaying messages, not originating them, so UTM's antispam would check the originating IP address against the SPF record of the domain supplied in MAIL FROM. With SPF you could block this type of spoofing, but you don't see much of this kind of spoofing anymore, exactly because of SPF. 

But if I telnet to the UTM, the UTM is the one sending the email, there's NO other server involved.

On all my tests, the only servers involved are the UTM and the exchange. (Well, unless my computer is considered an email server, which I'm not 100 % sure on that...)

I already have a TXT record for some of our domains like:

example.com TXT record: "v=spf1 ip4:my_UTM_public_ip a:another_allowed_domain.com -all"

That will tell the SMTP servers that the only servers allowed to send emails on behalf of "example.com" are my_UTM_public_ip and another_allowed_domain.com

About:

giomoda said:

What you want to achieve, which is authentication BEFORE relaying for a protected domain just does not exist. Sophos UTM is not the authoritative destination, so it HAS to accept any messages for the domains it is protecting. There's no way UTM would ask for authentication before accepting a message for a known domain.

Remember that what I want to achieve is that when I send an email from: example@example.com (my domain), the Sophos will not allow me to do it UNLESS I'm authenticated or I come from my internal Exchange.

This is not about destination but about sender/source. 

From my point of view, when I use telnet (in fact I use curl, but doesn't matter...) and I enter the field "FROM:", the UTM should see that the email belongs to a domain which he is "authoritative" for, and reject/abort the email. 

About the DATA, yes, I saw that behavior on my tests, but for now, is not that important to me... although is still important.

Regards.

"On all my tests, the only servers involved are the UTM and the exchange. (Well, unless my computer is considered an email server, which I'm not 100 % sure on that...)"

Since mail is originating from your computer, is this case it IS considered a mail server. The information UTM will use to check SPF is your computer's IP and the information you provide at P1 (MAIL FROM). 

Your SPF record seems sound. How are you conducting your tests? Are you connecting to the UTM from the internal network or from an external address? Do you have any exceptions in your UTM configuration that could cause SPF checks to be skipped in your testing? If you could provide us with some lines from your SMTP Proxy logs from when you are condcuting your testing we might be able to help you further. 

"Remember that what I want to achieve is that when I send an email from: example@example.com (my domain), the Sophos will not allow me to do it UNLESS I'm authenticated or I come from my internal Exchange."

I get that, and in a perfect world that would maybe exist. But with the email messaging protocol as is this is just not feasible and you will not find such a feature on any antispam product. What you need to consider is that Sophos is not in any way authoritative for your domain, so it has no way of forcing such authentication, even if selectively. As a matter of fact, even your Exchange server would have to accept an external message with a spoofed FROM address. It's the filter's job to detect and block such messages AFTER accepted and it's just how it works on every platform I have ever worked with.

As I mentioned earlier, if your SPF is not stopping spoofed messages for whatever reason, what you CAN do is create a regular expression or a blacklist at Sophos UTM blocking everything using @example.com (plus any other protected domains) as a sender address from going thought the filter. Do consider that you would need to create exceptions for your Exchange server and any other external service that might use your domain as a sender address, as those would be blocked by this configuration as well. That would allow you to block anyone spoofing your address in P1, like you are doing. BUT, if the FROM address is changed in P2, that would be ineffective, as the filter is only able to check P1 for expressions and blacklisting. But that's another story and actually not the issue your are facing, so let's fix your original issue first. 

Let's see some logs to start with, shall we?

Regards,

Giovani

Hi Giovani,

I think I have just identified the issue ( I was about the create a new thread about it).

The Sophos is not checking any additional DNS records, because I have a "Network definition" for "example.com" that points to our Internal IP address, hence, I assume, the Sophos won't check for any TXT record on "example.com"... because he thinks is authoritative for that domain?

This "host" definitions are related to Web servers, which, as I wrote before,  point to the Internal IP addresses. The issue is that I need those entries, so VPN users  can reach the internal IP address instead of the public one, for those hosts.

Do I really need to remove the "host" definitions for those domains, so the Sophos will query external DNS servers?

regards

it seems I need to do that, tested it with one domain, and now SPF checks are working...

thanks all for your help!!

Hi all

If you use the logic of "Authenticated Users" and read about it , it should be easy

If checked, users in the list can use UTM as smarthost directly, no need for exchange.

If not checked, UTM will not allow emails from users but only from mail-servers

Hey Bee.

I just tested, and if you have a top level domain mapped to an IP address it will in fact disrupt DNS queries. So you do need to disable them ir order to have correct DNS resolution. A more elegant solution might be a local DNS server to which you can point those VPN clients to.

 Example:

Regards,

Giovani

Hi Giovani,

the problem is that for internal users I need a different IP assignment than for VPN users, I will just remove the "example.com" domain and leave "www.example.com", that will do it (and tell VPN users to hard code their host file..)

Regards