[HOW-TO] Sécuriser son serveur web

[Gr3ps]

Parce que nous sommes jamais à l’abri d’une quelconque attaque, voici
quelques petites astuces afin d’améliorer la sécurité d’un serveur :


Utilisez de vrais mots de passe

Un bon mot de passe, est un mot de passe respectant un certains nombre de caractéristique que l’on nomme complexité.
Il est important de mixer ces complexités afin que les logiciels type bruteforce/rainbowtables ne puissent décoder ce mot de passe.

Ainsi, un mot de passe de plus de 8 caractères, comprenant à la fois des chiffres, des lettres, et des caractères spéciaux est quasiment inviolable.

Afin de le retenir plus facilement, vous pouvez opter pour une phrase auquel vous changerez certains caractères.

Ex : C3#paSS3#3st#s3cure@

Si le protocole le permet, il est possible d’utiliser des clés partagés (SSH par exemple).


Désactiver l’accès root depuis SSH

De base, un accès SSH autorise l’accès avec le login « root ».

Ce point est critique car le login « root » dispose bien évidemment de tous les droits.

Le moyen le plus simple pour éviter cela, c’est de désactiver l’accès SSH en root, en éditant le fichier /etc/ssh/sshd_config et en remplaçant la ligne :

PermitRootLogin: yes

Par

PermitRootLogin: no

Un redemarrage du service ssh est alors de rigueur :

/etc/init.d/ssh restart

Changer le port SSH par défaut

Par default, le service SSH écoute sur le port 22.
C’est en general le port le plus attaqué par les scanner, car il permet un accès directe à la machine.
Le fait de changer le port d’écoute, et de fermer le port 22 vous évitera donc pas mal de risques.

Toujours dans le même fichier /etc/ssh/sshd_config, changer le numéro de port par défaut (22) par un autre :

Port 12345

Attention toutefois de ne pas utiliser un port déjà pris par un autre service (serveur web sur le 80 ou smtp sur le 25).
Le plus pratique pour ne pas se tromper est de prendre un port superieur à 10000

Un redemarrage du service ssh est alors de rigueur :

/etc/init.d/ssh restart

Blacklister les IP malsaines

Des outils existent permettant de blacklister les ips tentant du forcing sur vos authentifications.

Fail2Ban par exemple fait ca très bien et est très simple à utiliser :

Pour l’installation :

Apt-get install fail2ban

Les fichiers de configuration se trouvent dans le répertoire /etc/fail2ban/

- Fail2ban.conf
Défini la criticité et l’emplacement des logs.

- Jail.conf
Défini les differents services à surveiller, les ips à ignorer, les actions à entreprendre en cas de detection (mailing, log).


Interdire l’execution depuis /tmp

Le repertoire /tmp est par default accessible à tous.
Aussi, si un utilisateur arrive à bypasser vos authentification (ou à uploader via un script corrompu), il aura tout le loisir de déposer et d’executer des fichiers dans ce fameu dossier /tmp.

L’astuce consiste donc à rendre ce dossier non exécutable.
Les fichiers pourront alors y être déposés, supprimés, modifiés, mais en aucun cas exécutés.

Pour cela, un simple ajout de l’attribut « noexec » dans votre fichier /etc/fstab :

/dev/sda3 /tmp ext3 noexec,nosuid 0 2

Attention toutefois, l’outil d’ajout de packet “apt” a parfois besoin d’un accès en exécution dans ce répertoire.
Il convient donc d’agir avec prudence sur cette manipulation.


Vérifier régulièrement la présence de rootkits

Un rootkit (en français : « outil de dissimulation d’activité ») est un type de programme (ou d’ensemble de programmes ou d’objets exécutables) dont le but est d’obtenir et de maintenir un accès frauduleux (ou non autorisé) aux ressources d’une machine , de la manière la plus furtive possible.

(source : http://fr.wikipedia.org/wiki/Rootkit)

L’utilitaire « chkrootkit » permet de détecter un grand nombre de ces indésirables, et ce très simplement en scannant la machine.

Installation :

apt-get install chkrootkit

Utilisation :

chkrootkit

On peut alors créé une tache cron qui lancera la détection automatiquement toutes les nuits et enverra un rapport par email :

0 3 * * * chkrootkit 2>&1 | mail votre@email.com -s « Rapport de chkrootkit »

Restriction des accès via iptables

Une des manières de sécuriser un serveur, est aussi de restreindre son utilisation qu’à un périmètre bien défini.

Ainsi, il n’est peut etre pas utile d’ouvrir l’accès SSH à tous le monde, mais uniquement à son adresse IP
(Idem pour les consoles d’administration de type webmin)

Ex :

Pour une machine d’admin ayant l’ip 192.168.0.2 et le serveur en 192.168.0.1

Chain INPUT (policy ACCEPT 1449K packets, 314M bytes)
pkts bytes target prot opt in out source destination
5 276 ACCEPT tcp — * * 192.168.0.2/32 192.168.0.1/32 tcp dpt:22

Ainsi de suite pour tous les autres services n’ayant pas besoin d’un accès par tous.