OPNsense Forum
Archive => 18.1 Legacy Series => Topic started by: dcol on February 05, 2018, 12:10:30 am
-
I have one complaint about email notifications, and it is most likely a FreeBSD issue.
The authentication method used is PLAIN which violates security protocols. Most email servers do not accept this method on purpose and the ones that do advise against using it.
How do I go about making a request to change this authentication method. I am not even sure which module handles that. Or at least an option to offer more modern methods. Kind of silly that a security device would leave an open door like that.
Thanks
-
I'm confused, do you mean in System -> Settings -> notifications?
-
Yes, and there the authentication method used for email is AUTH PLAIN.
Monit alerts do not use AUTH PLAIN, which is good
-
You can enable STARTTLS etc.. at least in my settings I see them.
-
But the email server still needs to allow AUTH PLAIN to accept the messages. That is the issue. OPNsense may send encrypted with STARTTLS, but the server has to be left vulnerable by allowing AUTH PLAIN for all incoming SMTP.
-
I think that's https://github.com/opnsense/core/issues/1983
I'll hopefully fix this week... even though it'll be a fix that won't be needed once Monit is integrated but since that is still almost 6 months away it's not totally in vain.
I'll add a CFT here when the code is available or someone beats me to it. ;)
Cheers,
Franco
-
AUTH PLAIN is perfectly ok in case of a TLS connection.
LOGIN is also not secure over an unencrypted connection so there are not many options left, any server supports. From the list of authentication variants supported by Thunderbird, only kerberos, NTLM and OAUTH2 are left.
This is the reason why the best protection is an email server, that supports STARTTLS connections. There is only one valid alternative that may work: The postfix plugin. In that case, OPNsense could send mails by itself and does not depend on an external mail server but in that case, the SPF record must match and the postfix plugin is not preinstalled and therefore not available on all appliances.
-
Maybe ok for OPNsense, but you still have to leave an email server wide open to accept the message. OPNsense is not my concern because STARTTLS can be used. But any other mis-configured client may expose themselves.
I love monit. Good idea to integrate it. Installed the plug-in and tested the heck out of it this past weekend and it does what I wanted. Also, monit does not use AUTH PLAIN, which is good.
-
I guess I'm confused, if you're worried about misconfigured clients trying to send outbound on port 25, why not just explicitly block outbound port 25 traffic?
-
Clients are not local and can use an unknown IP. Authenticated traffic can relay. If I close port 25, then no email will be accepted. Outbound for an external authenticated user is inbound traffic to me. I cannot restrict inbound port 25, but users sending mail must authenticate, but if I allow AUTH PLAIN, then a mis-configured client is vulnerable.
What would actually solve this issue, which looks like it is being addressed, is to send notifications via port 465 over SSL. But that is not currently working. Then I could set my email server to never allow authentication over port 25 for sending email. That way a client could never configure their SMTP outbound for port 25. Which is actually the way it was set until I had to allow it for this one OPNsense feature.
I guess another work around would be to open up some obscure SMTP port and use that. Then allow only local traffic to that port in the firewall.
-
465 has been deprecated for a long time... Really should configure clients to use Port 587 (submission) with STARTTLS...
-
Right now I use 465 with SSL which is the standard port for SMTP SSL. Is there a reason I haven't heard why SSL is being depreciated?
-
Probably best to reference this article with the links to the source info than me trying to haphazardly explain it hehe
https://en.wikipedia.org/wiki/SMTPS
-
I will start using 587, but need to maintain 465 for compatibility reasons. But will maintain SSL over STARTTLS.
I have opened an internal port for the OPNsense email notifications. That seems to work nicely.
-
Quite a bit of incorrect information floating around in this thread.
PLAIN auth is fine with SSL/STARTTLS and does not require that the server be left wide open. Servers can force requirement of either SSL or STARTTLS and reject unsecure connections.
Currently OPNsense email notifications SSL and STARTTLS is broken. Neither are secure.
https://github.com/opnsense/core/issues/1983
In general STARTTLS is unsecure for clients that merely request but do not require connection upgrade.
https://en.wikipedia.org/wiki/Opportunistic_TLS#Weaknesses_and_mitigations
It's not difficult to do. But it requires diligent attention to some details.
-
Slightly OT: I use a raspberry pi configured as a fake email server (only for receiving status emails from firewalls and NAS etc). Access from remote via VPN. Don't want my status emails with sensitive info to be floating through this interweb thing... ;-)
-
I use a VPS hosted POSTFIX configured to only accept secure connections. Either SSL/TLS or required STARTTLS connection upgrade. Plus my router email notifications client configured to require STARTTLS connection upgrade.
In short. Own email server and secure connection required.
-
I agree with everything NOYB said, I just got bogged down with two different issues.
The reason that the AUTH PLAIN was an issue is because I could not use SSL or STARTTLS because it doesn't work in OPNsense, which meant I needed to allow non encrypted authentication to make it work. But there is always a different approach and I used an obscure local port that does not require STARTTLS or SSL and that works fine until the issue is resolved.