Lorsque 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.
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.
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.
Lors de l'envoi de connexions client vers un service, 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/ |
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 que 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.
![]() | 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. |
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.
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.
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 par 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.
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 = <nombre_de_connexions> <période_d_attente> — Stipule le nombre de connexions autorisées vers un service par seconde. Cette directive n'accepte que des valeurs entières.
instances = <nombre_de_connexions> — 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 = <nombre_de_connexions> — 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 = <nombre[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 = <nombre_de_secondes> — 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.
Précédent | Sommaire | Suivant |
Outils de communication à sécurité avancée | Niveau supérieur | Sécurisation de portmap |