Why do we need it?
With the ubiquitous nature of mobile devices in the hands of non-technical users, they are at risk of them compromising their log in credentials at at poorly implemented or old technology hotspots. This translates into a problem for the hosting company when their credentials get into the hands of the spammers, the server gets blacklisted, and everyone else on the server are holding hosting company responsible for the service interruption. Moreover, every time such an event occurs, it requires hours of time to determine if the problem is due to a bad form on their site or by compromised credentials, and responding as necessary to the data center and spam lists to return the server to full usability.
The cert strategy:
1. Use the server’s snake oil cert.
2. Buy a low cost cert from a CA
I went with number number two. However, I encourage the user to use their own domain as usual in their E-mail clients, and then against the warning, install the cert. The advantage is you can move their domain to a different server, and the users won’t have to change their E-mail client settings. They would simply need to accept the certificate again. If they were to use the name of the server’s cert, if you move them to another server, every device in the company would need to have their E-mail clients edited to reflect the new E-mail server. Where the problem comes in some software will only allow the cert to work for a day, or until you reboot. Then they have to re-accept. Instead of getting annoyed every day, they can edit the mail server in their E-mail client to reflect the name of the CA server cert.
The changes:
Secure Web Mail (http)
Credit goes to zEitEr for this one. Add near the bottom of the /etc/httpd/conf/extra/httpd-includes.conf the following:
################################################################################
# Mod_Rewrite
################################################################################
<location /phpMyAdmin>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
<location /webmail>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
<location /squirrelmail>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
<location /roundcube>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
<location /atmail>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</location>
– Restart Apache
Secure Dovecot (POP3 & IMAP)
– ssh in as root
– cd /etc/dovecot
– cp dovecot.conf dovecot.conf.ssl
– Edit /etc/dovecot.conf.ssl
– Change:
disable_plaintext_auth = no
to
## Begin Change disable_plaintext_auth = yes ## End Change
– mv dovecot.conf dovecot.conf.orig
– cp dovecot.conf.ssl dovecot.conf
– Restart dovecot
Secure Exim (SMTP)
This example is based off SpamBlocker.exim.conf.2.1.1-release 05-Jun-2007. Open /etc/exim.conf and find the following block of code:
# to block certain well known exploits, Deny for local domains if
# local parts begin with a dot or contain @ % ! / |
deny domains = +local_domains
local_parts = ^[.] : ^.*[@%!/|]
and place this directly below it:
# Change Begin
# Prevents unencrypted mail submission.
accept encrypted = *
drop message = Your connection must be encrypted.
log_message = Connection from
[$sender_host_address]($authenticated_id) was
not encrypted.
# Change End
The code that should show directly below this is:
# to restrict port 587 to authenticated users only
# see also daemon_smtp_ports above
accept hosts = +auth_relay_hosts
condition = ${if eq {$interface_port}{587} {yes}{no}}
endpass
message = relay not permitted, authentication required
authenticated = *
– Restart Exim
Other:
The # Change Begin and # Change End comments simply highlight your changes for when it becomes advantageous to move to a newer version of the configs. If you find any errors or omissions, let me know, and I’ll correct them.
