Disabling SSLv3 in Postfix

Dark Knight Poodle
Some rights reserved by greg westfall.

The POODLE attack was made public late 2014 and as most vendors have taken action to solve possible issues related to POODLE. The time definitely has come to close SSLv3 in all parts of public facing infrastructure. By default Postfix still only disallows SSLv2 and hopefully this will change in the form of stricter default behaviour in Postfix or distributions/vendors that stop shipping SSLv3 libraries.

For now you can set with the postconf command restrictions which protocols shouldn’t be used by Postfix.

$ sudo postconf -e smtpd_tls_mandatory_protocols=\!SSLv2,\!SSLv3
$ sudo postconf -e smtpd_tls_protocols=\!SSLv2,\!SSLv3
$ sudo postconf -e smtp_tls_mandatory_protocols=\!SSLv2,\!SSLv3
$ sudo postconf -e smtp_tls_protocols=\!SSLv2,\!SSLv3

As this is a change to /etc/postfix/main.cf Postfix can be reloaded to reread the configuration, but it may be smarter to just restart Postfix to make it effective for all connection from the moment Postfix restarts.

$ sudo systemctl restart postfix.service

All encrypted sessions Postfix allows will require TLSv1+. The next step will be to disable the RC4 cipher suite, but will do that in another posting.

Postfix en aangepaste syslog meldingen

Vanwege een voorgaande posting over port 465 een mea culpa van mijn kant. Een lange tijd geleden heb ik blijkbaar over een optie van Postfix gekeken, maar recentelijk werd ik door een posting op de postfix mailinglist toh getriggerd. Met behulp van de optie syslog_name kan een aanpassingen worden gedaan.

De volgende standaard entry staat in /etc/postfix/master.cf en is om submission van mail te ondersteunen.

submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_etrn_restrictions=reject
-o smtpd_client_restrictions=permit_sasl_authenticated,reject

Door het toevoegen van de optie syslog_name valt nu te zien wie mail injecteert via de submission poort ipv de standaard mail poort.

submission inet n - n - - smtpd
-o syslog_name=postfix-submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_etrn_restrictions=reject
-o smtpd_client_restrictions=permit_sasl_authenticated,reject

Vanaf dit moment worden entries in oa /var/log/mail.log aangemaakt met de prefix postfix-submission en dat maakt het herleiden van sommige fouten wel gemakkelijker.

Vaarwel, port 465

Hoewel de weg al in 1998 was ingezet met RFC2476 om mail te kunnen injecteren via een aparte poort, maar helaas kwam in 1999 ook RFC2487. Deze laatste RFC ging over SMTP over SSL, maar heeft nooit echt een vlucht genomen gelukkig. Sommige mensen zien het wel als een alternatief voor de mail submission oplossing en andere zien het als oplossing om SMTP over SSL te versturen.

Gelukkig heeft TLS sindsdien een vlucht genomen en kan tegenwoordig TLS worden gebruikt voor zowel SMTP-verbindingen als voor Submission-verbindingen. Door de splitsing van server-to-server verkeer over poort 25 en client-to-server verkeer over poort 587 is er een verduidelijking gekomen in de soorten verkeer. TLS afdwingen op client-to-server verkeer is een mogelijkheid geworden en worden username/password combinaties afgeschermd. Het nut van SMTP over SSL is dus verdwenen, maar hoe faseer je het uit?

Je kan gewoon uitzetten in Postfix door het bestand master.cf aan te passen, zodat de regels voor smtps niet meer actief zijn. Simpeler is het gelukkig niet, maar de kans bestaat dat sommige verbindingen ineens stoppen met werken. Helaas is het in logfiles niet te herleiden of er verbindingen over poort 465 lopen ipv poort 25 of 587.

Op platformen zoals Linux, BSD en Solaris zijn packetfilters beschikbaar en kan met behulp van een paar simpele regels toch informatie worden verkregen. Zoals de onderstaande regel voor Netfilter.

iptables -A INPUT_ETH0 -d 192.0.2.1 -p tcp \
--sport 1024:65535 --dport 465 \
-j LOG --log-level DEBUG --log-prefix "SERVICE MONITORING: "

Voor elke verbinding naar de server zal melding worden gemaakt door de kernel naar syslog en deze zijn hierna terug te lezen in bv /var/log/syslog. Door deze opstelling een paar maanden te volgen kan je bepalen of er echt geen verbindingen meer zijn.