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.
