sentimancho.'>

Sécuriser son serveur

La sécurité est une activité, ce n’est pas un résultat.

On peut s’occuper de sécurité mais on ne pourra jamais l’atteindre complètement. L’aspect sécuritaire sur un site web couvre deux aspects. Il y a tout d’abord l’interface web qui est présentée au public, et qui peut comporter des failles de programmation (sql injection, mauvaise sécurisation de la zone administrateur, …), et ensuite le serveur lui même, qui peut comporter des failles de sécurité (système d’exploitation, droits d’utilisateurs, …).

Cet article couvrira uniquement les aspects “serveur”. Je traiterai peut être les aspects logiciels dans un autre article. Il sera question d’un serveur Apache avec php et mysql installés tournant sous linux.

Sécurité d'un serveur

Il faut considérer la sécurité comme un oignon, pour sécuriser un système on le fera par couches successives. Pour sécuriser le serveur on considérera les deux couches suivantes (qui se sépareront en sous couches lorsque l’on voudra sécuriser encore mieux le système) : l’aspect réseau, et l’aspect système de fichiers.

A lire :

http://www.soyo123.com/HardeningLinux

http://www.freesoftwaremagazine.com/articles/hardening_linux

Le Réseau :

On va tenter de sécuriser les logiciels qui servent d’interface entre le serveur et le web.

Ecoute des ports :

La première chose à faire est d’écouter les ports de son serveur. Pour cela deux outils : netstat et nmap.

$ netstat -l -n -p -t -u -w

-l pour écouter (listenning)

-n pour voir des informations sur l’IP

-p sert à recueillir des informations sur le processus qui utilise le port

-t, -u, -w pour les connections TCP, Udp, et Raw

$ nmap -sS 127.0.0.1
Starting Nmap 4.20 ( http://insecure.org ) at 2008-04-26 19:52 CEST
 Interesting ports on localhost.localdomain (127.0.0.1):
 Not shown: 1689 closed ports
 PORT STATE SERVICE
 22/tcp open ssh
 25/tcp open smtp
 80/tcp open http
 143/tcp open imap
 631/tcp open ipp
 3306/tcp open mysql
 8000/tcp open http-alt
 8080/tcp open http-proxy

Sert à recueillir des informations sur les ports ouverts par les processus du serveur.



Configuration du pare-feu :

(A lire : guide OVH)

Iptables est un pare-feu élémentaire qui nous servira à protéger l’accès à notre serveur. Iptables est configuré par un ensemble de règles qui vont définir les comportements à suivre pour les instructions entrantes, sortantes et transmises. Pour afficher les règles en cours :

$ iptables --list

Nous allons les effacer, afin de reprendre au début la configuration :

$ iptables -F

Pour donner une structure globale du paramétrage du pare-feu serait le suivant :

  1. Permettre les connexions sortantes initiées par le serveur
  2. Autoriser les connexion entrantes en ssh sur le port 22 (obligatoire sinon vous ne pourrez plus accéder à votre serveur à distance)
  3. Autoriser les connexion entrantes en http sur le port 80
  4. Autoriser le https sur le port 443
  5. Autoriser les requêtes internes
  6. Bloquer toutes les connexions ssh sortantes
  7. Bloquer tout le reste

Ce qui donne :

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
iptables -A INPUT -s 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 22 -j DROP
iptables -A INPUT -j REJECT
iptables -A FORWARD -j DROP

Enfin, je sauve ces règles que je pourrai restaurer :

iptables-save > /root/firewall
iptables-restore -c /root/firewall

NB : pour mon serveur, j’ai rajouté les requêtes entrantes sur les ports qui m’intéressent


ATTENTION : il est possible de restaurer le pare feu au démarrage de la machine. Or si celui-ci a été mal réglé (accès au ssh impossible par exemple ), il vous sera impossible d’accéder à votre serveur. Si jamais vous avez vérifier que toutes les requêtes aboutissaient, le lancement automatique se fera dans le dossier : /etc/init.d (voir articles dédié plus tard).

NOTE : Chez OVH il est important de mettre le rejet des input en REJECT. En effet,à la différence de DROP, les paquets sont traités lors d’un REJECT, et l’envoyeur reçoit un message d’erreur. Les services de OVH se basant sur un ping régulier des serveurs qu’ils hébergent, si vous placez un DROP à cet endroit, OVH pensera que votre machine s’est débranché du réseau, et la fera rebooter sans vous demander votre avis.



Sécuriser SSH :

Changer le port de connexion : fichier de configuration : /etc/ssh/sshd_config.

Remplacer la ligne :

# What ports, IPs and protocols we listen for
Port 22

par

# What ports, IPs and protocols we listen for
Port 2200


IMPORTANT : n’oubliez pas de rajouter le nouveau port en lecture sur iptables, et de retirer l’ancien :

 & iptables -A INPUT -p tcp -m tcp --dport 2200 -j ACCEPT
$ iptables -D INPUT "numéro de la règle concernant le port 22"

Redémarrez ensuite le processus :

$ /etc/init.d/ssh restart

Les fichiers de configuration :

Si votre système n’est pas encore envahi (le mieux étant donc de réaliser les étapes de sécurisation avant la mise en ligne du serveur si possible), il est intéressant de vérifier que vos fichiers de configuration restent inchangés dans le temps. Si cela n’est pas le cas, il s’agit sûrement d’un intrus qui a modifié les fichiers de base de votre système.

Il existe plusieurs Intrusion Detection System (IDS). Leur rôle est d’enregistrer dans une base de données des informations concernant les répertoires que vous aurez sélectionnés (configuration et autre), afin de vérifier rapidement si ces fichiers ont subi une modification depuis la création de la base de données. De manière grossière, ce type de logiciel vérifie la date de création et la taille des différents fichiers contenus dans les répertoire cibles afin de vérifier la concordance.

On utilisera ici le logiciel fcheck.

Installer le (compilation / apt-get install) et vérifier que la configuration indique bien :

# Directories that will be monitored
# if there is a trailing / it will be recursive

Directory = /etc/
Directory = /bin/
Directory = /sbin/
Directory = /lib/
Directory = /usr/bin/
Directory = /usr/sbin/
Directory = /usr/lib/
TimeZone = PST8PDT # For Pacific Standard

# Database of file signatures

DataBase = /usr/local/fcheck/sol.dbf
Logger = /usr/bin/logger -t fcheck

# Utility to determin file type
FileTyper = /bin/file

# What to use to create signatures Database of
# file signatures

$Signature = /usr/bin/md5sum#
DataBase = /usr/local/fcheck/sol.dbf
Logger = /usr/bin/logger -tfcheck

# Utility to determin file type

FileTyper = /bin/file


A présent, il faut initialiser la base de données pour qu’elle possède ses signatures à jour :

$ fcheck -cadsx

Pour les arguments : c = Create, a=All, d=monitor, s=créer les Signatures, x= eXtended permissions monitoring

A suivre…

Posts similaires

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">