Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux - Guide de securite - S�curit� du serveur

Chapitre 5. 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.

TuyauAstuce
 

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�:

 ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert

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.

NoteNote
 

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 infoemerg, 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.

 
 
  Published under the terms of the GNU General Public License Design by Interspire