NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux - Guide de securite - S�curit� du serveur
Lorsqu'un syst�me est utilis� comme un serveur sur un r�seau public, il devient la cible d'attaques. Il est donc primordial pour l'administrateur syst�me d'endurcir le syst�me et de verrouiller les services.
Avant de vous lancer dans des questions sp�cifiques, vous devriez revoir les conseils g�n�raux suivants pour am�liorer la s�curit� du serveur�:
Garder tous les services � jour pour les prot�ger contre les derniers dangers.
Utiliser des protocoles s�curis�s autant que possible.
Servir un seul type de service r�seau par machine autant que possible.
Contr�ler avec attention tous les serveurs contre toute activit� soup�onneuse.
5.1. S�curisation de services avec les enveloppeurs TCP et xinetd
Les enveloppeurs TCP offrent le contr�le d'acc�s sur divers services. La plupart des services r�seau modernes, tels que SSH, Telnet et FTP, utilisent les enveloppeurs TCP qui montent la garde entre les requ�tes entrantes et le service interrog�.
Les avantages offerts par les enveloppeurs TCP sont augment�s avec l'utilisation de la commande xinetd, un super service offrant plus de possibilit�s en mati�re d'acc�s, de journalisation, de liaison, de redirection et de contr�le de l'utilisation des ressources.
Astuce
Il est bon d'utiliser les r�gles de pare-feu IPTables avec les enveloppeurs TCP et xinetd pour cr�er une redondance au sein des contr�les d'acc�s aux services. Reportez-vous au Chapitre 7 afin d'obtenir davantage d'informations sur l'impl�mentation des pare-feu avec les commandes IPTables.
De plus amples informations sur la configuration des enveloppeurs TCP et de xinetd se trouvent dans le chapitre intitul� Enveloppeurs TCP et xinetd dans le Guide de r�f�rence de Red Hat Enterprise Linux.
Les sous-sections suivantes assument une connaissance de base sur chaque sujet et se concentrent essentiellement sur des options de s�curit� sp�cifiques.
5.1.1. Am�lioration de la s�curit� avec les enveloppeurs TCP
Les enveloppeurs TCP peuvent �tre utilis�s pour bien plus que pour d�nier l'acc�s aux services. Cette section illustre la mani�re de les utiliser pour envoyer des banni�res de connexion, pr�venir des attaques provenant d'h�tes particuliers et am�liorer la fonctionnalit� de journalisation. Pour obtenir une liste compl�te des fonctionnalit�s de l'enveloppeur TCP et du langage de contr�le, veuillez consulter la page de manuel de hosts_options.
5.1.1.1. Enveloppeurs TCP et banni�res de connexion
Lors de la connexion d'un client sur un service, l'envoi d'une banni�re intimidante est un bon moyen pour cacher le syst�me utilis� par le serveur tout en avertissant l'agresseur que l'administrateur syst�me est vigilant. Pour impl�menter une banni�re d'enveloppeurs TCP pour un service, utilisez l'option banner.
Cet exemple impl�mente une banni�re pour vsftpd. Pour commencer, vous devez cr�er un fichier de banni�re. Il peut se trouver n'importe o� sur le syst�me, mais il doit porter le m�me nom que le d�mon. Dans cet exemple, nous appellerons le fichier /etc/banners/vsftpd.
Le contenu du fichier ressemble � l'exemple suivant�:
220-Hello, %c
220-All activity on ftp.example.com is logged.
220-Act up and you will be banned.
Le mot-cl� %c fournit diverses informations sur le client, comme le nom d'utilisateur et le nom d'h�te, ou le nom d'utilisateur et l'adresse IP, pour rendre la connexion encore plus intimidante. Le Guide de r�f�rence de Red Hat Enterprise Linux contient une liste de mots-cl�s disponibles pour les enveloppeurs TCP.
Pour que cette banni�re soit pr�sent�e aux connexions entrantes, ajoutez la ligne suivante dans le fichier /etc/hosts.allow�:
vsftpd : ALL : banners /etc/banners/
5.1.1.2. Enveloppeurs TCP et avertissement d'attaques
Si un h�te ou un r�seau particulier a �t� identifi� en train d'attaquer le serveur, les enveloppeurs TCP peuvent �tre utilis�s pour avertir l'administrateur en cas d'attaques suivantes depuis cet h�te ou ce r�seau gr�ce � la directive spawn.
Dans cet exemple, supposez qu'un craqueur provenant du r�seau 206.182.68.0/24 a �t� arr�t� en essayant d'attaquer le serveur. En ajoutant la ligne suivante dans le fichier /etc/hosts.deny, l'essai de connexion sera refus� et enregistr� dans un fichier sp�cial�:
Le mot-cl� %d fournit le nom du service que l'agresseur a essay� d'attaquer.
Pour autoriser la connexion et l'enregistrer, ajoutez la directive spawn dans le fichier /etc/hosts.allow.
Note
Vu que la directive spawn ex�cute toutes les commandes shell, vous pouvez cr�er un script sp�cial pour pr�venir l'administrateur ou ex�cuter une cha�ne de commandes dans le cas o� un client particulier essaierait de se connecter au serveur.
5.1.1.3. Enveloppeurs TCP et journalisation avanc�e
Si certains types de connexion font l'objet d'un plus grande inqui�tude que d'autres, le niveau de journalisation peut �tre �lev� pour ce service gr�ce � l'option severity.
Dans cet exemple, supposez que toutes les personnes qui essaient de se connecter au port 23 (le port Telnet) sur un serveur FTP sont des craqueurs. Pour d�montrer cela, ajoutez un indicateur emerg dans les fichiers journaux � la place de l'indicateur par d�faut, info, et refusez la connexion.
Dans ce but, ajoutez la ligne suivante dans le fichier /etc/hosts.deny�:
in.telnetd : ALL : severity emerg
Cela utilisera l'option de journalisation authpriv par d�faut, mais augmentera la priorit� de la valeur par d�faut de info � emerg, qui envoie les messages de journalisation directement sur la console.
5.1.2. Am�lioration de la s�curit� avec xinetd
Le super serveur xinetd est un autre outil utile pour contr�ler l'acc�s � ses services subordonn�s. Cette section se limitera � expliquer comment xinetd peut �tre utilis� pour configurer un service pi�ge et contr�ler la quantit� de ressources utilis�e par un service xinetd afin de contrecarrer les attaques par d�ni de service. Pour une liste compl�te des options disponibles, veuillez consulter les pages de manuel pour xinetd et xinetd.conf.
5.1.2.1. Pr�parer un pi�ge
Une caract�ristique importante de xinetd repose dans sa capacit� d'ajouter des h�tes sur une liste no_access globale. Les h�tes sur cette liste sont d�ni�s toute connexion aux services g�r�s par xinetd pour une dur�e de temps sp�cifi�e ou jusqu'� ce que xinetd soit red�marr�. Cela est accompli � l'aide de l'attribut SENSOR. Cette technique est un moyen facile pour bloquer les h�tes qui essaient de scanner les ports du serveur.
La premi�re �tape de la configuration d'un SENSOR est de choisir un service que vous n'utiliserez pas. Dans cet exemple, nous utiliserons Telnet.
Modifiez le fichier /etc/xinetd.d/telnet en changeant la ligne flags en�:
flags = SENSOR
Ajoutez la ligne suivante � l'int�rieur des accolades�:
deny_time = 30
Ce faisant, l'h�te ayant essay� de se connecter au port sera interdit pendant 30 minutes. Il existe d'autres valeurs possibles pour l'attribut deny_time, telles que FOREVER, qui permet de maintenir l'interdiction jusqu'� ce que xinetd soit relanc� et NEVER, qui autorise la connexion et l'enregistre.
Finalement, la derni�re ligne devrait ressembler � ceci�:
disable = no
Alors que l'utilisation de SENSOR est une bonne mani�re de d�tecter et d'arr�ter des connexions venant d'h�tes malintentionn�s, elle a deux inconv�nients�:
Elle ne fonctionne pas contre les cannages sournois.
Un agresseur sachant que vous ex�cutez SENSOR peut organiser une attaque par d�ni de service contre des h�tes sp�cifiques en falsifiant leurs adresses IP et en se connectant au port interdit.
5.1.2.2. Contr�le des ressources de serveur
Une autre caract�ristique importante de xinetd est sa capacit� � surveiller la quantit� de ressources que des services sous son contr�le peuvent utiliser.
Cette fonctionnalit� est possible gr�ce aux directives suivantes�:
cps = <number_of_connections> <wait_period> — Stipule le nombre de connexions autoris�es vers un service par seconde. Cette directive n'accepte que des valeurs enti�res.
instances = <number_of_connections> — Stipule le nombre total de connexions autoris�es vers un service. Cette directive accepte aussi bien une valeur enti�re que la valeur UNLIMITED.
per_source = <number_of_connections> — Stipule le nombre de connexions autoris�es vers un service par chaque h�te. Cette directive accepte aussi bien une valeur enti�re que la valeur UNLIMITED.
rlimit_as = <number[K|M]> — Stipule la quantit� d'espace d'adressage que le service peut occuper en m�moire, et ce, en kilo-octets ou m�ga-octets. Cette directive accepte aussi bien une valeur enti�re que la valeur UNLIMITED.
rlimit_cpu = <number_of_seconds> — Stipule la dur�e en secondes pendant laquelle un service est autoris� � occuper le CPU. Cette directive accepte aussi bien une valeur enti�re que la valeur UNLIMITED.
L'utilisation de ces directives peut permettre d'�viter que tout service xinetd ne submerge le syst�me, entra�nant par l�-m�me un d�ni de service.
