Serveur dédié : ajouter l'authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim photo 1

Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim

dkim-spf-200

Cela fait quelques années maintenant que mon serveur tourne et je trouvais le serveur de mail (postfix) bien fonctionnel plutôt bien jusqu’à ce que je reçoive des messages de la part de Gmail comme quoi les emails envoyés par le site sont considérés comme spam!

Et c’est à ce moment que l’on réalise qu’être bloqué par son fournisseur email, ce n’est pas cool du tout : à chaque fois qu’un nouveau commentaire est publié et que quelqu’un y est abonné, l’erreur se déclenche et le mail part en mail delivery service.

Voici le message type que l’on reçoit de Gmail dans ce cas:

Final-Recipient: rfc822; ***@gmail.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been blocked. Please visit
    https://support.google.com/mail/answer/81126 to review our Bulk Email Senders Guidelines. Code language: JavaScript (javascript)

Lorsque l’on monte un serveur email, rien n’est sécurisé par défaut. Avec tout le spam en circulation, il y a des entêtes à ajouter lors de l’envoi pour que le courrier ne soit pas considéré comme indésirable :

dkim-spf-schema

Il est donc temps de sécuriser un peu notre serveur de mail.

Étape 1 : diagnostics

Sur le serveur dans le terminal, on envoie un mail de test :

mail  check-auth@verifier.port25.comCode language: CSS (css)

Résultat:

==========================================================
Summary of Results
==========================================================
SPF check:          softfail
DomainKeys check:   neutral
DKIM check:         neutral
Sender-ID check:    softfail
SpamAssassin check: ham

Du fail et du neutral, ce n’est pas trop bon! Nous allons commencer par activer SPF et Sender-ID.

Étape 2 : ajouter SPF et Sender-ID à BIND

Nous allons donc ajouter l’authentification SPF (Sender Policy Framework) à notre enregistrement DNS. On édite le fichier de configuration BIND de notre domaine :

nano /etc/bind/skyminds.net.hosts

Et on y ajoute à la fin du fichier :

;SPF
skyminds.net. IN TXT "v=spf1 ip4:IP4SERVEUR mx -all"
skyminds.net. IN SPF "v=spf1 ip4:IP4SERVEUR mx -all"
mail.skyminds.net. IN  TXT  "v=spf1 ip4:IP4SERVEUR a -all"
mail.skyminds.net. IN  SPF  "v=spf1 ip4:IP4SERVEUR a -all"Code language: JavaScript (javascript)

Remplacez IP4SERVEUR par l’IPv4 de votre serveur et skyminds.net par votre nom de domaine. Enregistrez le fichier et relancez BIND :

/etc/init.d/bind9 restart

On renvoie un mail de test :

mail  check-auth@verifier.port25.comCode language: CSS (css)

Nouveau résultat :

==========================================================
Summary of Results
==========================================================
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         neutral
Sender-ID check:    pass
SpamAssassin check: ham

Pas mal, on vient d’activer le SPF et le Sender-ID en 2 minutes !

Étape 3 : installation de l’authentification DKIM

DKIM (DomainKeys Identified Mail) est une norme d’authentification fiable du nom de domaine de l’expéditeur d’un courrier électronique : DKIM fonctionne par signature cryptographique du corps du message et d’une partie de ses en-têtes.

Une signature DKIM vérifie donc l’authenticité du domaine expéditeur et garantit l’intégrité du message. Idéal pour lutter contre le spam.

1. On installe opendkim :

apt-get install opendkim opendkim-toolsCode language: JavaScript (javascript)

Et on édite le fichier de configuration:

nano /etc/opendkim.conf

On supprime tout le contenu de ce fichier et on met :

 # Enable Logging
Syslog yes
SyslogSuccess yes
LogWhy yes

# User mask
UMask 002

# Always oversign From (sign using actual From and a null From to prevent
# malicious signatures header fields (From and/or others) between the signer and the verifier)
OversignHeaders From

# Our KeyTable and SigningTable
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable

# Trusted Hosts
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts /etc/opendkim/TrustedHosts

# Hashing Algorithm
SignatureAlgorithm rsa-sha256

# Auto restart when the failure occurs. CAUTION: This may cause a tight fork loops
AutoRestart Yes
DNSTimeout  5

# Set the user and group to opendkim user
UserID opendkim:opendkim

# Specify the working socket
Socket inet:12345@localhost

Canonicalization relaxed/relaxedCode language: PHP (php)

2. On édite la configuration par défaut d’opendkim:

nano /etc/default/opendkimCode language: JavaScript (javascript)

Avec :

# Command-line options specified here will override the contents of
# /etc/opendkim.conf. See opendkim(8) for a complete list of options.
#DAEMON_OPTS=""
#
# Uncomment to specify an alternate socket
# Note that setting this will override any Socket value in opendkim.conf
#SOCKET="local:/var/run/opendkim/opendkim.sock" # default
#SOCKET="inet:54321" # listen on all interfaces on port 54321
SOCKET="inet:12345@localhost" # listen on loopback on port 12345
#SOCKET="inet:12345@192.0.2.1" # listen on 192.0.2.1 on port 12345Code language: PHP (php)

3. On crée un nouveau répertoire pour notre clé et on assigne les droits à l’utilisateur opendkim, du groupe opendkim:

mkdir -pv /etc/opendkim/skyminds.net/
chown -Rv opendkim:opendkim /etc/opendkim
chmod go-rwx /etc/opendkim/* 

Ensuite, on crée une paire de clés pour chaque domaine :

cd /etc/opendkim/skyminds.net/
opendkim-genkey -r -h rsa-sha256 -d skyminds.net -s mail -b 4096
mv -v mail.private mail
chown opendkim:opendkim *
chmod u=rw,go-rwx * Code language: PHP (php)

Cela nous crée 2 fichiers : un fichier mail (clé privée) et un fichier mail.txt qui contiendra notre clé publique.

4. On ajoute notre clé publique à l’enregistrement DNS du domaine dans BIND:

nano /etc/bind/skyminds.net.hosts

On y copie notre clé publique (/etc/opendkim/skyminds.net/mail.txt) à la fin du fichier :

;DKIM
_domainkey.skyminds.net. IN TXT "t=y; o=-;"
mail._domainkey.skyminds.net. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6YG5lJXmZxgz1eFprQfEV8oqUjYceMNPctuhi/Fo+oE+4oeDwMTDyPJcGCuJMp2XZxL2X3a8/Q9g3StekiHWqPehY7cyrnYZg6ttTCdbJYGAc/t0rVCKut/2baiGw9lcMq5sbUG9YywEEI/rN4Fu0PCU1A6BkqtNAepPhDwVRAQIDAQAB; t=s"; ----- DKIM key mail for skyminds.net
_adsp._domainkey.skyminds.net. IN TXT "dkim=unknown"Code language: JavaScript (javascript)

On enregistre le fichier et on relance BIND :

/etc/init.d/bind9 restart

5. On associe les domaines avec les clés :

nano  /etc/opendkim/KeyTable

La syntaxe du fichier est la suivante :
KeyID Domain:Selector:PathToPrivateKey

Nous ajoutons donc :

skyminds.net skyminds.net:mail:/etc/opendkim/skyminds.net/mailCode language: JavaScript (javascript)

6. On édite ensuite la table des signatures :

nano /etc/opendkim/SigningTable

à laquelle on ajoute :

*@skyminds.net skyminds.netCode language: CSS (css)

7. On définit les domaines considérés comme trusted :

nano /etc/opendkim/TrustedHosts

Avec :

127.0.0.1
localhost
ns.kimsufi.com
skyminds.netCode language: CSS (css)

Il ne faut pas oublier d’ajouter le DNS de votre hébergeur (ns.kimsufi.com chez moi).

8. On applique maintenant les bons droits à nos fichiers :

chown opendkim:opendkim /etc/opendkim/KeyTable
chown opendkim:opendkim /etc/opendkim/SigningTable
chown opendkim:opendkim /etc/opendkim/TrustedHosts 

9. On édite maintenant la configuration Postfix :

nano /etc/postfix/main.cf

Et on rajoute :

# DKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:12345
non_smtpd_milters = $smtpd_miltersCode language: PHP (php)

On redémarre bind, opendkim et postfix pour vérifier que tout va bien :

/etc/init.d/bind9 restart
/etc/init.d/opendkim restart
/etc/init.d/postfix restart

10. On vérifie qu’opendkim est bien lancé sur le serveur :

ps aux | grep dkim
netstat -tanp | grep dkim 

Étape 4 : tests et vérifications

Il faut maintenant attendre que la propagation DNS prenne effet, cela peut prendre quelques heures.

Vous pouvez lancer un test DKIM ici : http://www.brandonchecketts.com/emailtest.php

Vérifiez les erreurs mail dans les logs :

tail -f /var/log/mail.logCode language: JavaScript (javascript)

Envoyez-vous un email via le terminal. Voici ce que vous devriez obtenir :

dkim-spf-signed

Étape 5 : optimiser la vitesse d’envoi

Quelques jours après la réalisation et la mise en place du tutoriel, je me suis aperçu que Gmail grognait toujours à cause de la vitesse à laquelle étaient envoyés les emails, notamment lorsque beaucoup de gens sont abonnés aux commentaires : en cas de nouveau commentaire, une flopée de notifications partent au même moment – ce qui déclenche le message d’erreur chez Gmail.

Pour améliorer cela, on édite à nouveau le fichier de configuration postfix :

nano /etc/postfix/main.cf

Et on y rajoute :

# Matt : NOT TOO FAST COWBOY!
# This means that postfix will up to two concurrent
# connections per receiving domains. The default value is 20.
default_destination_concurrency_limit = 2
# Postfix will add a delay between each message to the same receiving domain.
default_destination_rate_delay = 5s
# Limit the number of recipients of each message.
# If a message had 20 recipients on the same domain, postfix will break it out
default_extra_recipient_limit = 3Code language: PHP (php)

Cela se connecte au maximum avec 2 connexions par domaine, avec un délai de 5 secondes entre chaque message s’ils sont envoyés au même domaine et on envoie par tranche de 3 messages. Un peu alambiqué mais cela semble satisfaire Google.

Voilà, c’est fini. Les messages de votre serveur de mail devraient maintenant être un peu plus acceptés dans les boîtes de réception !

La faille Heartbleed dans OpenSSL : mettez à jour vos serveurs photo

La faille Heartbleed dans OpenSSL : mettez à jour vos serveurs

Heartbleed

heartbleed

Dans la nuit du lundi 7 au mardi 8 avril 2014, une équipe de chercheurs du Codenomicon et le chercheur Neel Mehta de Google Security ont découvert une faille dans la librairie open-source OpenSSL.

OpenSSL est une librairie utilisée pour gérer la couche SSL/TLS de nombreux logiciels (serveurs webs, webmails, VPN, messagerie instantanée…).

La faille, baptisée Heartbleed, est une vulnérabilité sérieuse dans le protocole d’encryption OpenSSL, utilisé pour chiffrer et sécuriser les connexions.

Potentiellement, cette faille permet de dérober des données normalement chiffrées et des clés privées.

Concrètement, cela signifie que toutes les données que nous avons considérées comme sécurisées ne l’étaient pas.

Heartbleed affecte approximativement 66 % des serveurs du monde entier et existe depuis décembre 2011.

En exploitant cette faille, un hacker peut lire 64 KB de la mémoire du système protégé par OpenSSL et ainsi voler les mots de passe, les clés de chiffrement, toutes les données qui transitent entre votre ordinateur et le serveur, et ensuite pouvoir se faire passer de manière transparente pour un service web ou un internaute…

Cela ne laisse aucune trace : un PoC est disponible.

Déterminer la version d’OpenSSL

Toutes les versions d’OpenSSL 1.0.1 à 1.0.1f inclus sont vulnérables. Pour savoir quelle version d’OpenSSL est actuellement installées sur votre système, tapez :

dpkg -s openssl | grep Version

La faille a été introduit dans OpenSSL en décembre 2011 et s’est retrouvé dans la nature avec la sortie d’OpenSSL 1.0.1 le 14 mars 2012.

OpenSSL 1.0.1g, sortie le 7 avril 2014, corrige Heartbleed.

Lire la suite

windows-xp-logo

Windows XP arrive à expiration : sauvegarder l’activation pour une future (ré-)installation

Windows XP expire le 8 avril 2014

windows-xp-logo

Si vous êtes encore sous Windows XP, vous devez savoir que le support de ce système d’exploitation arrivera à son terme le 8 avril 2014.

Après cette date, il ne sera plus possible d’activer l’OS depuis les serveurs de Microsoft donc il va falloir sauvegarder votre activation du système en lieu sûr.

Sauvegarde de l’activation Windows XP

Il vous suffit de :

1. copier le fichier C:\Windows\System32\wpa.dbl en lieu sûr;

2. à la réinstallation suivante de Windows XP, redémarrer en Mode sans échec (F8 au démarrage);

3. renommer le fichier C:\Windows\System32\wpa.dbl créé par la nouvelle activation en wpa.dbl.bak

4. copier enfin le fichier d’activation que vous aviez sauvegardé dans C:\Windows\System32\

Et voilà, vous pourrez réinstaller XP sans passer par les serveurs d’activation de Microsoft.

Windows XP, sorti en 2001, aura eu une durée de vie de 13 ans, ce qui n’est vraiment pas négligeable pour un système d’exploitation.

Il aura été pour moi le Windows de référence avant que je ne passe sur du tout Linux.

vpn-icon

Linux : configurer un VPN avec VPNTunnel

vpn icon

Pour tout un tas de raison, il est temps pour nous de prendre un petit VPN, histoire de d’ajouter une couche de sécurité supplémentaire.

Stéphane nous avait déjà montré comment créer un réseau privé virtuel (VPN) sous Debian Lenny mais je voulais un service externe qui ne sollicitait pas le serveur du site.

J’ai essayé VPNTunnel pour 5 euros pendant un mois et comme le service m’a bien plu, je vous donne le petit tutoriel qui permet de configurer tout cela en moins de 10 minutes, sous Ubuntu.

Installation d’OpenVPN et des fichiers de configuration de VPNTunnel

On installe OpenVPN et ses dépendances :

sudo apt-get install openvpn network-manager-openvpn-gnome resolvconfCode language: JavaScript (javascript)

puis on crée le répertoire /etc/openvpn/keys:

sudo mkdir /etc/openvpn/keys

Sur le site de VPN Tunnel, deux fichiers sont à télécharger : Linux-confs.tar.gz et cert.zip. Dézippez les deux fichiers.

Après avoir tapé :

sudo nautilus

Il vous reste à :

  1. copier tous les fichiers *.conf dans /etc/openvpn/
  2. copier tous les certificats *.cert dans /etc/openvpn/keys

A ce stade, nous sommes presque prêts : il ne nous reste plus qu’à ajouter ces différentes configurations VPN au gestionnaire de connexion de Gnome.

Lire la suite

Serveur dédié : configurer la limite mémoire pour PHP et Suhosin photo

Serveur dédié : configurer la limite mémoire pour PHP et Suhosin

suhosin_logo

Aujourd’hui, je vous livre la solution à un problème auquel vous avez peut-être été confronté lors de la configuration de votre serveur dédié – il s’agit d’une erreur que l’on peut trouver dans les fichiers logs d’Apache :

Dec 12 16:19:26 mail suhosin[22860]: ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker '82.83.84.85', file '/home/skyminds/public_html/wp-admin/admin.php', line 96)Code language: JavaScript (javascript)

Etape 1 : paramétrage de memory_limit dans php.ini

On édite notre fichier php.ini :

nano /etc/php5/apache2/php.ini

On recherche la variable memory_limit et on l’augmente à 256MB :

; Maximum amount of memory a script may consume (128MB)
; http://php.net/manual/en/ini.core.php#ini.memory-limit
memory_limit = 256MCode language: JavaScript (javascript)

Note : vérifiez que vous éditez bien le bon fichier php.ini ! Je me suis aperçu après quelques essais que celui qui correspondait à mon installation était en fait /etc/php5/apache2filter/php.ini.

Lancez un phpinfo();pour être sûr du fichier à éditer.

Lire la suite

Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH photo 1

Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH

Aujourd’hui, nous abordons la sauvegarde des fichiers essentiels du serveur.

Backup Manager permet d’effectuer des sauvegardes quotidiennes du système : il crée des archives dans plusieurs formats de compression (tar, gzip, bzip2, lzma, dar, zip) et peut les exporter vers un serveur FTP.

Dans notre cas, nous allons l’installer et le configurer pour envoyer tout ce qui est important sur notre serveur sur le serveur FTP externe de sauvegarde fourni gratuitement par OVH (100 Go).

Etape 1 : installation de Backup Manager

C’est classique :

apt-get install backup-managerCode language: JavaScript (javascript)

A la fin de l’installation, un assistant se lance et vous permet de configurer des options par défaut. Ou vous pouvez configurer à la main, comme indiqué dans l’étape suivante.

Lire la suite

Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes photo 1

Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes

ssh plugins logo

Sur mon serveur, j’ai fait le choix de ne pas installer de serveur FTP.

Pourquoi ? Et bien tout simplement parce que le protocole FTP n’est pas du tout sécurisé : les mots de passe sont envoyés en clair sur le réseau, il n’y a aucun chiffrement appliqué sur la connexion et il existe 1001 manières d’en forcer l’accès.

Du coup, je me dis que l’on peut très bien s’en passer. Comme il faut bien que je mette des fichiers sur le serveur ou mettre à jour le site, nous allons utiliser SSH qui est un protocole sécurisé.

Lire la suite

Serveur dédié : sécuriser Apache 2 avec ModSecurity photo

Serveur dédié : sécuriser Apache 2 avec ModSecurity

modsecurity

Aujourd’hui, on ajoute une couche de sécurité supplémentaire avec l’installation du module ModSecurity pour Apache.

ModSecurity est un firewall pour les applications web (WAF) pour Apache.

Il permet de se prémunir contre pas mal d’attaques (connues/inconnues, injections SQL, failles XSS…) et permet de surveiller le traffic HTTP en temps réel. Très utile pour un serveur dédié sous Apache!

L’installation est très rapide, cela ne prend que quelques minutes et 3 étapes.

Etape 1 : installation de mod_security

On commence par éditer nos sources de dépôts :

nano /etc/apt/sources.listCode language: PHP (php)

et on ajoute les backports :

deb  squeeze-backports main

On met à jour et on installe mod_security:

apt-get update
apt-get install libapache-mod-securityCode language: JavaScript (javascript)

On active le module :

a2enmod mod-security

Et on relance Apache pour prendre en compte nos changements :

/etc/init.d/apache2 restart

Lire la suite

Serveur dédié : création d'un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d'utilisateurs/domaines virtuels photo 1

Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels

Aujourd’hui, nous voyons comment créer un serveur mail sécurisé et qui tient bien la route. Comme je suis seul utilisateur du serveur, je ne voyais pas trop l’intérêt de créer des comptes utilisateurs sur le serveur juste pour pouvoir bénéficier d’un serveur mail.

J’ai donc opté pour la solution suivante : un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et un serveur Courier (accès POP et IMAP) qui utilisent MySQL (utilisateurs et domaines virtuels) pour la redirection des messages des utilsateurs/domaines.

icon mail server1

Le tutoriel est certainement le plus long de la série, j’estime que cela prend à peu près 50 minutes à compléter (en 15 étapes!). Attention au niveau des copier/coller, une simple erreur peut vous faire perdre pas mal de temps !

Etape 1 : configurer le hostname

Le hostname est le nom du serveur en général. Mon domaine est skyminds.net donc mon serveur s’appelle mail.skyminds.net

Il est également important que ce nom soit présent dans la configuration bind du serveur.

Pour connaitre le nom de votre machine, tapez :

hostname -f

Pour le modifiez, il faut éditer /etc/hostname :

nano /etc/hostname

Remplacez ce qui s’y trouve avec le nom de votre serveur. J’y mets ‘mail.skyminds.net’.

Ensuite, éditez /etc/hosts:

nano /etc/hosts

On ne touche pas à la première ligne mais on ajoute l’adresse IP du serveur suivie de notre nom de machine :

127.0.0.1       localhost.localdomain localhost
xxx.xxx.xxx.xxx  mail.skyminds.netCode language: CSS (css)

Il ne vous reste plus qu’à rebooter le serveur pour que les modifications soient prises en compte :

/sbin/reboot

Vérifiez bien que le nouveau nom a bien changé :

hostname -f

J’obtiens bien :

mail.skyminds.netCode language: CSS (css)

Si vous obtenez une erreur du style “name or service not found”, vérifiez que les enregistrements DNS du serveur sont bien corrects.

Lire la suite

Serveur dédié : sécurisation de la couche TCP/IP photo

Serveur dédié : sécurisation de la couche TCP/IP

icon security firewall

Il est facile de sécuriser la couche TCP/IP du serveur juste en activant quelques directives.

Normalement, le réseau de l’hébergeur est suffisant stable pour que nous puissions désactiver certains fonctions de routage IPv4 et IPv6.

Nous allons donc désactiver les redirections ICMP, nous protéger des attaques SYN FLOOD, du spoofing, du smurfing, désactiver le routage à l’intérieur des paquets et finalement désactiver l’autoconf IPV6.

Ce tutoriel prend à peine 10 minutes.

Configuration du fichier /etc/sysctl.conf

Il existe pas mal d’options dans le fichier sysctl.conf liées à la sécurité. Commençons par éditer le fichier :

nano /etc/sysctl.conf

Lire la suite

Serveur dédié : sécurisation des services avec iptables et fail2ban photo

Serveur dédié : sécurisation des services avec iptables et fail2ban

icon security firewall

Notre serveur est maintenant opérationnel et sert les pages du site. Il faut toutefois penser à le sécuriser un peu contre les attaques les plus communes.

Nous utilisons donc iptables – un firewall qui filtre activement nos ports utilisés et qui bloque les autres – et fail2ban qui scanne vos fichiers logs à la recherche de requêtes étranges pour bloquer les intrus à la porte lorsqu’ils deviennent trop insistants.

Installation et configuration d’iptables

Si ce n’est déjà fait, on installe iptables :

apt-get install iptablesCode language: JavaScript (javascript)

Les règles peuvent porter sur 3 chaînes :

  • INPUT en entrée,
  • FORWARD dans le cas d’un routage réseau,
  • OUPUT en sortie.

et les actions à entreprendre sont ACCEPT (accepter le paquet), DROP (le jeter), QUEUE et RETURN. Les arguments utilisés sont :

  • i : interface d’entrée (input)
  • o : interface de sortie (output)
  • t : table (par défaut filter contenant les chaînes INPUT, FORWARD, OUTPUT)
  • j : règle à appliquer (Jump)
  • A : ajoute la règle à la fin de la chaîne (Append)
  • I : insère la règle au début de la chaîne (Insert)
  • R : remplace une règle dans la chaîne (Replace)
  • D : efface une règle (Delete)
  • F : efface toutes les règles (Flush)
  • X : efface la chaîne
  • P : règle par défaut (Policy)
  • lo : localhost (ou 127.0.0.1, machine locale)

Lire la suite