Apple iOS 8.4 and SMTP with SSL/TLS issues

July 7th, 2015

After updating my iPad to iOS 8.4, I was no longer capable of sending emails. Some research on the net learned me that more people experienced similar problems when using secure SMTP with use of SSL/TLS. It turned out that Apple made some effort in hardening the OS, when it comes to SSL and TLS communication. Here you can read that after updating an iPhone, iPad, iPod touch, or Mac device, it can no longer communicate with servers or webpages that are setup with weaker Diffie-Hellman encryption.

The same article suggests to make use of Diffie-Hellman keys with a group size of 2048 bits or greater. So instead of waiting for another bugfix from Apple, I had to reconfigure my SMTP server which is running Sendmail.

Generate a Strong, Unique Diffie Hellman Group

Like Apple suggests I generated a new Diffie-Hellman parameter file in the same directory where my certificates for Sendmail are stored.

-bash-3.2# cd /etc/pki/tls/certs/
-bash-3.2# openssl dhparam -out dhparams.pem 2048
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
........+.......................................................................
................................................+...............................
................................................................................
-bash-3.2#

Alter the Sendmail configuration

Now I needed to alter the Sendmail configuration so it will be using this newly generated Diffie-Hellman parameter file. I also added some extra security restrictions to avoid using weak ciphers or vulnerable SSL implementations. The following lines need to be added to the /etc/mail/sendmail.mc file

LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
O DHParameters=/etc/pki/tls/certs/dhparams.pem

Generate sendmail.cf and restart Sendmail

Now the sendmail.cf configuration file needs to be generated and Sendmail has to be restarted.

-bash-3.2# cd /etc/mail
-bash-3.2# m4 sendmail.mc > sendmail.cf
-bash-3.2# service sendmail restart
Shutting down sm-client:                                   [  OK  ]
Shutting down sendmail:                                    [  OK  ]
Starting sendmail:                                         [  OK  ]
Starting sm-client:                                        [  OK  ]
-bash-3.2#

After these changes I was able to send emails from my iPad again :-)

UPC modem en remote logging via syslog – Deel 2

November 30th, 2014

Ongeveer anderhalf jaar geleden scheef ik deze post over het activeren van syslog op het Technicolor 7200 modem dat UPC mij in bruikleen heeft gegeven. Inmiddels heb ik mijn server thuis voorzien van RHEL 7. RHEL 7 maakt gebruik van rsyslog. Deze syslog server blijkt qua funtionaliteit veel uitgebreider te zijn dan syslogd (die in iedergeval nog de default syslog server op RHEL 5 was). Zo is het niet langer nodig om via iptables de syslog messages die het UPC modem via UDP/512 naar de syslog server stuurt te redirecten naar UDP/514, want rsyslog kan je op elke gewenste poort laten luisteren.

Je kunt bijvoorbeeld het configuratiebestand /etc/rsyslog.d/upc-modem.conf aanmaken met de volgende inhoud (vervang het ip adres door het ip adres van je eigen UPC modem):

$ModLoad imudp
$UDPServerRun 512
 
:fromhost-ip, isequal, "192.168.178.2" /var/log/upc-modem.log
& ~

Daarna herstart je rsyslog om deze configuratie wijziging door te voeren.

# systemctl restart rsyslog

Dus niet alleen worden de syslog messages netjes op poort UDP/512 ontvangen, maar worden deze tevens opgeslagen in een eigen logbestand. Het is verstandig om dit logbestand op te nemen in logrotate. Hiermee voorkom je dat de log parititie vol loopt. Ik heb ‘m zelf voor het gemak toegevoegd aan /etc/logrotate.d/syslog.

Call Home met SSH en STUNNEL

November 30th, 2014

Vanochtend werd ik snotterig wakker met een beetje pijn in mijn keel. Mogelijk heb ik ergens een virusje opgelopen of kou gevat. Gelukkig hoef ik vandaag nergens naar toe en besluit voor de zekerheid maar even binnen te blijven. Hopelijk gaat het morgen weer beter en waait dit over. Dit zijn voor mij van die momentjes dat je even lekker kunt ‘klooien’ op de computer. Zo ben ik vandaag wezen spelen met docker en heb wat gelezen over de verschillen tussen puppet, chef en zookeeper.

Via een van mijn connecties op LinkedIn kwam ik terecht bij Redsocks. Kennelijk heeft Redsocks de oplossing als het gaat om bescherming tegen de gevaren van malware. Ik heb zo’n beetje de hele site doorgebladerd, maar ben niet veel wijzer geworden wat dat mooie rode apparaat precies doet. Dat mooie rode apparaat lijkt trouwens veel op een Dell PowerEdge. Bij mijn vorige werkgever hadden we deze ook, alleen daar werden ze roze gespoten. Wat dat betreft lijkt die rode wel veel beter dan die roze 😉

Anyway, wat betreft beveiliging maak ik me eigenlijk meer zorgen over de zogenaamde ‘Call Home’ functionaliteit die veel leveranciers van soft- en hardware tegenwoordig standaard meeleveren. Vroeger noemde we dat backdoors, maar nu behoort het tot de standaard support omgeving. Toegegeven, het scheelt wel een hoop werk. Het uitdelen van VPN accounts of het inregelen van IPsec site-to-site VPN verbindingen is niet langer nodig, maar als organisatie dreig je wel de controle over je netwerktoegang kwijt te raken. Want hoe controleer je welke gegevens er precies richting je leverancier gaan? En stellen zij de dezelfde eisen aan beveiliging die binnen jouw organisatie gelden?

Naast deze ‘betrouwbare’ leveranciers zijn er ook nog eindgebruikers die de reguliere methode om van thuis het bedrijfsnetwerk te kunnen benaderen maar lastig vinden. Waar sommige zich wenden tot diensten als ‘LogMeIn’, ‘TeamViewer’ en ‘GoToMyPC’, doen anderen weer handige dingen met SSH en STUNNEL. Dat laatste vind ik dan zelf weer een interessante methode; Niet om zelf te gebruiken (natuurlijk), maar om te zien hoe dat precies werkt. Dat heb ik vandaag ook maar even uitgezocht en opgeschreven.

Zoals je kunt zien is het niet heel lastig om dit werkend te krijgen. Het is echter wel lastig voor organisaties om dit soort (meestal) verboden constructies op te sporen. Zeker omdat je met deze methode de SSH verbinding tunnelt over een SSL verbinding op de standaard HTTPS poort. Ik vond dit trouwens een goede beschrijving om een dergelijke verbinding te realiseren. Deze beschrijving is echter wel zonder gebruik van STUNNEL.

Zo, dat was het weer voor vandaag. Ik ga nog even wat dropjes eten voor mijn zere keel :-)