Renforcer la sécurité de son serveur

Nous voilà sur la dernière ligne droite de notre série d’articles consacrée à la mise en place d’un cloud personnel. Nous avons installé à peu près tout ce dont on peut avoir besoin, mais à part un script de pare-feu relativement restrictif et une protection anti-spam et anti-virus pour le serveur mail, il reste encore quelques petites choses à faire pour sécuriser notre serveur.

Avant toute chose, contrairement à ce que beaucoup de gens recommandent comme bonne pratique, je ne vais pas aborder la question du changement de port pour améliorer la sécurité de notre serveur. Je pense en effet qu’un simple nmap sur l’hôte à tester suffit pour déterminer quels sont les ports ouverts sur une machine, et ce n’est pas en déplaçant ce port que le “pirate” va jeter l’éponge. Si quelqu’un est vraiment déterminé à récupérer de votre serveur des données auxquelles il n’a pas le droit d’accéder, il y parviendra.

Je mise donc sur une approche différente qu’on va tout de suite mettre en place, et qui repose sur fail2ban. Pour mémoire, fail2ban analyse les tentatives de connexion à votre serveur, et blacklist toute IP qui tentera d’accéder à votre serveur sans succès, selon un certain nombre de règles (qui peuvent être bien velues à configurer…).

fail2ban

Installons l’application :

apt-get install fail2ban
/etc/init.d/fail2ban stop

On configure ensuite l’application :

mv /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf-orig
nano /etc/fail2ban/jail.conf

Le nombre d’applications nécessitant une connexion réseau pour fonctionner est relativement limité sur notre serveur, ce qui va simplifier la configuration de fail2ban, d’autant que la plupart des filtres existe déjà.

Voici un fichier jail.conf de référence, correspondant à notre serveur :

[DEFAULT]
ignoreip = 127.0.0.1 xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy
bantime = 600
maxretry = 3
backend = polling
destemail = contact@exemple.fr
banaction = iptables-multiport
mta = sendmail
protocol = tcp

action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]

action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
              %(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s]

action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
               %(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s]

# Choose default action.  To change, just override value of 'action' with the
# interpolation to the chosen action shortcut (e.g.  action_mw, action_mwl, etc) in jail.local
# globally (section [DEFAULT]) or per specific section
action = %(action_)s

[ssh]
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

[ssh-ddos]
enabled = false
port    = ssh
filter  = sshd-ddos
logpath  = /var/log/auth.log
maxretry = 6

[pam-generic]
enabled = true
filter  = pam-generic
port = all
banaction = iptables-allports
port     = anyport
logpath  = /var/log/auth.log
maxretry = 6

[apache]
enabled = true
port    = http,https
filter  = apache-auth
logpath = /var/www/*/*/log/error.log
maxretry = 6

[apache-multiport]
enabled   = true
port      = http,https
filter    = apache-auth
logpath   = /var/www/*/*/log/error.log
maxretry  = 6

[apache-noscript]
enabled = true
port    = http,https
filter  = apache-noscript
logpath = /var/www/*/*/log/error.log
maxretry = 6

[apache-overflows]
enabled = true
port    = http,https
filter  = apache-overflows
logpath = /var/www/*/*/log/error.log
maxretry = 2

[postfix]
enabled  = true
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/mail.log

[sasl]
enabled  = true
port     = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter   = sasl
logpath  = /var/log/mail.log

[named-refused-tcp]
enabled  = true
port     = domain,953
protocol = tcp
filter   = named-refused
logpath  = /var/log/named/security.log

Si vous activez le monitoring pour bind, vous devez activer la journalisation :

nano /etc/bind/named.conf.options

logging {
     channel security_file {
         file "/var/log/named/security.log" versions 3 size 30m;
         severity dynamic;
         print-time yes;
     };
     category security {
         security_file;
     };
};

/etc/init.d/bind9 restart

Vous devriez être relativement tranquille avec ce fichier de configuration.

Notice : N’oubliez surtout pas de renseigner correctement votre (vos) adresse(s) IP en début de fichier !

Démarrez ensuite le service :

/etc/init.d/fail2ban start

Désormais, si quelqu’un n’entre pas dans les clous, son adresse IP sera bloquée directement au niveau d’iptables, pour une durée déterminée spécifiée en début de fichier de configuration.

Un firewall “modulaire”

On va un peu compléter notre script de pare-feu pour vous permettre de spécifier vous-même une liste d’adresses IP à bannir.

nano /scripts/firewall

Ajoutez tout à la fin du fichier :

if [ -f "/scripts/firewall.hosts" ]
then
    for ip in `cat /scripts/firewall.hosts`; do
        ${IPT} -A INPUT -s $ip -j DROP
    done
fi

Créez ensuite le fichier en question :

touch /scripts/firewall.hosts

Vous pouvez maintenant remplir ce fichier avec les adresses IP que vous souhaitez bloquer (une par ligne).

N’oubliez pas de relancer le script une fois vos modifications terminées :

/scripts/firewall

Accès via certificats clients

Si vous le souhaitez, vous pouvez limiter l’accès à certains de vos sites Internet à certains clients disposant d’un certificat délivré par vous-même.

Notice : Évitez cette restriction sur l’accès webdav : les clients webdav peuvent ne pas gérer les certificats clients.

Il suffit de modifier le fichier de configuration de l’hôte virtuel que vous voulez “protéger”, en rajoutant les lignes suivantes :

<Location />
    SSLCACertificateFile /scripts/certificate_authority/ca.crt
    SSLVerifyClient require
    SSLVerifyDepth 4
</Location>

Vous créez ensuite un certificat classique :

/scripts/certificate_authority/make_request apache-client sous-domaine.exemple.fr
/scripts/certificate_authority/sign_request apache-client sous-domaine.exemple.fr
chown -R www-data:www-data /scripts/certificate_authority/apache-client

Notice : Dans ce cas, ne créez pas de certificat sans mot de passe.

Il faut ensuite exporter le certificat créé et signé dans un format compatible :

openssl pkcs12 -export -clcerts -in /scripts/certificate_authority/apache-client/sous-domaine.exemple.fr.crt -inkey /scripts/certificate_authority/apache-client/sous-domaine.exemple.fr.key -out /scripts/certificate_authority/apache-client/sous-domaine.exemple.fr.p12

Transmettez ce certificat et son mot de passe au client qui doit accéder au site, client qui devra l’importer dans son navigateur. Utilisez de préférence SSH pour effectuer ce transfert

Échanger autour de ce texte

Si vous souhaitez réagir publiquement, un fil dédié vous attend.

Ouvrir le fil de discussion

fail2ban

Un firewall “modulaire”

Accès via certificats clients

Échanger autour de ce texte

Taxonomies