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?

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 Louis-M

I don't have an open relay... except when the Sender is any account of  any of my domains... AND the recipient is any account of any of my domains... the rest are blocked.

I'll look at you mentioned before (as well as Bob's answer), about the connectors, but still, I'm not sure if that will fix the issue, because the Sophos will still be allowed to send emails... and I think the Sophos' originating them...

Regards.

It sounds like your environment is behaving the way that you configured it.

Sending Mail

This is how things work for every mail system that I have configured, including Exchange

• If your mail server requires authentication, the authenticated user can only send under his own name.   This is used for real people, like you and me, running Outlook or Webmail.  It is also used for automated applications that have been configured to log onto the mail server with authentication.
• If your mail server does not require authentication, the connected entity (usually an automated application) can send using any email address that is valid for the hosted email domain(s).
• To prevent abuse of unauthenticated connections, the mail server is (or should be) configured to allow unauthenticated connections from specific IP addresses only.   Everyone else has to authenticate.  In exchange, you apply the IP address filtering on the receive connector.
• For domains not hosted locally, the mail is forwarded based on MX or other outbound routing rules, as appropriate.

Receiving mail

• Mail is accepted from anything that can connect to the mail server, pass its spam checks, and is addressed to a valid account on a hosted email domain.   Mail is not forwarded elsewhere unless the receiving account (or for Exchange, a Transport Rule) causes it to be forwarded.
• If a received message is forwarded externally, "SRS" coding can be used to permit the forwarding server to "take responsibility" for the message, so that it will pass SPF checks at the receiving system.   I do not believe Exchange does this.

Complications

• SPF checks are based on the internal "authenticated-as" (a.k.a. "envelope-from") information (matched to the sending system IP address).   This field is the remote server's assertion about what user authenticated to it before the message was delivered.   In the case of a non-delivery report, the authenticated-as information is empty, because the NDR was generated automatically.
  
  
• The "authenticated-as" information need not have anything to do with the "FROM" information seen by the recipient.   In fact, the vast majority of legitimate email is promotional material sent by third parties, such as ConstantContact.   For this third-party mail, the two are frequently different.  You have to look at the internal message headers to see the "authenticated-as" information.
  
  
• Both the "Authenticated-As" information and the "From" information can be fraudulent.   This is a necessary side effect of allowing third-party mailing services.
  
  
• UTM, and the EXIM mail system underneath it, do not seem to have any capability to filter on the "FROM" information seen by the user.   This limitation, coupled with the limitations of SPF, can lead to the impression that UTM lets anyone send anything on behalf of your domain.   The only known workaround is to have a DMARC policy that says EVERY message from my domain will have a valid DKIM signature.

Hope this helps.  I am not sure what problem you think UTM introduces into your environment.

CORRECTION:

If SMTP Authentication is disabled for an IP, then the server accepts mail for any destination, not just locally hosted ones.   Both user and domain portions of the sender email address could be invalid, because no verification is performed.   This makes the system a relay.   Any "authenticated-as" information in the incoming data stream will be forwarded when the message is forwarded.

This leaves these possible configurations:

• Incoming to a locally-hosted domain:   Message accepted from any source, with or without authentication, subject to whatever spam filtering rules are enforced by the receiving system.
• Incoming to any domain, with SMTP authentication completed:   Message accepted for delivery using the authenticated user's email address
• incoming to a non-hosted domain, without SMTP authentication, and without an exemption from SMTP authentication:   Message rejected.
• Incoming to a non-hosted domain, without SMTP authentication, and WITH an exemption from SMTP authentication:   Message accepted for delivery (relay mode)

 Typical relay configurations:

• Inbound spam filter:   Accepts messages for configured domains only, applies filtering rules, delivers only to configured mail servers for configured mail domains.
• Outbound spam filter:   Accepts messages from internal mail servers only, delivers anywhere.
• Open Relay (Always Inappropriate):   Applies SMTP Authentication Exemption to inappropriate sending systems, such as any/all internet addresses.

UTM configuration

• Inbound SPAM filter:  UTM accepts messages for the configured incoming mail domains, without authentication, for delivery to the configured host systems.
• Outbound SPAM filter:   UTM accepts messages from systems in the "Host-based relay" list, without authentication, for delivery anywhere.
• Open Relay:  Only happens if you include Internet addresses (e.g. ANY) in the Host-Based Relay list.   This would be foolish.
• Mail Server Mode:   Enable the box for "Allow authenticated relaying", configure authorized users and groups using local user objects, configure an email address on each local user object.   (Not recommended.   Mail should be submitted to a normal mail system.)
• Incoming Relay:   If UTM is not your perimeter SPAM filter, you must configure it to look past your other SPAM filters.   This is configured on the "upstream host list".   (Some spam filters call this the "trusted senders list".)   It tells the UTM filter (a) the upstream host will add a correct routing header, and will correctly forward the header information that it receives; and (b) the UTM SPAM filter should look past the upstream host in the Received-From list for purposes of evaluating SPF, sender block list, and similar criteria. 

Thank you DouglasFoster for the feedback!.

After doing more tests and re-reading previous replies, I think I'm starting to see what is happening... 

Maybe I should abandon this thread a create a new one called "SPF checks not working or how does UTM check TXT records"...

Because I think now that the issue lies with the SPF records (for the domains that have SPF records, I have another that do NOT have SPF records and I'm not sure how I'll fix those, besides adding a SPF record...)

As I mentioned before, I have a TXT record:

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

and in the example.com profile the:

BATV/RDNS/HELO/SPF/Greylisting

with check marks on "USE BATV" and "Perform SPF check"

and no exceptions

But emails get through anyway. 

When I run a dig query, like:

dig example.com TXT +short

I don't see anything, but if I run:

dig @8.8.8.8 example.com TXT +short

I do see my TXT (SPF) record...

Thank you DouglasFoster for the feedback!.

After doing more tests and re-reading previous replies, I think I'm starting to see what is happening... 

Maybe I should abandon this thread a create a new one called "SPF checks not working or how does UTM check TXT records"...

Because I think now that the issue lies with the SPF records (for the domains that have SPF records, I have another that do NOT have SPF records and I'm not sure how I'll fix those, besides adding a SPF record...)

As I mentioned before, I have a TXT record:

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

and in the example.com profile the:

BATV/RDNS/HELO/SPF/Greylisting

with check marks on "USE BATV" and "Perform SPF check"

and no exceptions

But emails get through anyway. 

When I run a dig query, like:

dig example.com TXT +short

I don't see anything, but if I run:

dig @8.8.8.8 example.com TXT +short

I do see my TXT (SPF) record...