AFFICHER CET ARTICLE EN MODE PLEINE PAGE
Sommaire
3) Limitation des services actifs
4) Sécurisation du système de fichiers
7) Configuration sécurisée de la pile TCP/IP
Il n’existe aucun système d’exploitation qui ne présente son lot de vulnérabilités. Du fait de la croissance rapide des accès au haut débit et du nombre de connexions internet permanente la sécurité informatique est devenu primordiale. Cependant, par nature, l’accès réseau et la sécurité des ordinateurs vont à l’encontre l’un de l’autre. Les réseaux favorisent les accès aux systèmes informatiques, alors que la sécurité a pour rôle de restreindre l’accès à ces systèmes. Voyons dans cette article quelques points de base pour un bon départ dans la sécurisation de votre système.
Le meilleur moment pour sécuriser un système linux c’est dès le début. Installer un système minimal opérationnel. Aucun service superflu, ne doit être installé et démarré. Ce qui n’est pas le cas lors d’une installation par défaut de la plupart des distributions Linux. Après l’installation il est indispensable d’effectuer une mise à jour du système et des logiciels, tout comme tout au long de l‘utilisation du système d’exploitation. Pour les applications réseau (DNS, Mail, web ….) il est fortement recommandé d’utiliser les distributions originales plutôt que les paquetages fournis dans la distribution linux (pour une plus grande réactivité). Les mises à jour ne doivent pas être négligé, la sécurité en dépend et un retard dans l’application d’un correctif est très souvent à l’origine de la compromission de nombreux systèmes. Pour commencer informez vous sur la sécurité informatique :
Le site de votre distribution :
- http://65.54.172.250/cgi-bin/www.securityfocus.com
- http://www.security-corporation.com/
- http://www.linuxsecurity.com/
3) Limitation des services actifs
Pour augmenter la sécurité du système, est réduire les vulnérabilités potentielles. Après installation, même minimal d’un système linux il y a plusieurs processus inutiles.
- identification des processus exécutés par défaut après l’installation : ps –edf
- identification des ports réseau utilisés : netstat –atup
- identification des services actifs : chkconfig --list
- désactivation au redémarrage du système : chkconfig --level 0123456 nom_du_service off
- suppression du service de la table de configuration : chkconfig --del nom_du_service
- arrêt immédiat du service : service nom_du_service stop
Liste non exhaustive de services :
- apmd
: nécessaire uniquement pour les ordinateurs portables.
- xntpd : Network time protocol.
- portmap : nécessaire si vous utilisez
un service rpc, comme NIS ou NFS.
- sound : configuration des sons.
- netfs : c'est le client nfs, utilisé pour
mounter des filesystems depuis un serveur nfs.
- rstatd , rusersd, rwhod, rwalld : ne pas exécuter
tous les services car ils fournissent trop d'informations aux utilisateurs à
distance.
- bootparamd : Utilisé par les clients sans
lecteur de disquette (vulnérable).
- squid : serveur proxy.
- yppasswdd : nécessaire si vous êtes
un serveur NIS (extrêmement vulnérable).
- ypserv : nécessaire si vous êtes
un serveur NIS (extrêmement vulnérable).
- dhcpd : démarre le daemon du serveur dhcp.
- atd : utilisé pour le service at, similaire
à cron, mais n'est pas nécessaire.
- pcmcia : parle de lui-même.
- snmpd : daemon SNMP, peut donner à des
utilisateurs distants des informations détaillées sur votre système.
- named : serveur DNS.
- routed : RIP, n'exécutez cela que si vous
en avez vraiment besoin.
- lpd : services d'impression.
- mars-nwe : fichier Netware et serveur d'impression.
- nfs : Utilisé pour le serveur NFS, lancez
le que si vous en avez absolument besoin.
- amd : daemon AutoMount, sert à mounter
les filesystems distants.
- gated : sert à lancer d'autres protocoles
de routage comme OSPF.
- sendmail : Vous pourrez toujours envoyer/recevoir
des emails par Netscape (ou autre) sans lui.
- httpd : serveur web Apache.
- ypbind : nécessaire si vous êtes
un client NIS.
- xfs : xfont server (indispensable si vous êtes
sous X).
- innd : serveur de news.
- arpwatch : off par défaut. Rapport d'activité
de datagrammes IP via mail.
- kudzu : détection des periphériques.
A réactiver à l'occasion.
- anacron : reprise de jobs de la crontab après
un crash.
- crond : si vous ne savez pas ce qu'est une crontab,
désactivez-le.
- rawdevices : partitions spécifique sous
ORACLE ou autre SGBD.
- random : améliore la génération
aléatoire de nombres (peut être utile pour les joueurs).
- rhnd : redhat network.
- linuxconf : on peut utiliser linuxconf sans ce
daemon (peut être est-ce utile pour l'administration à distance
?).
- nfslock : si vous n'êtes pas sur un serveur
NFS, désactivez-le.
- usb : parle de lui-même.
- gpm : fournit des fonctions pour le support de
la souris en mode texte (utile pour midnight commander en particulier).
Il est recommandé d’éliminer tout démon du fichier /etc/inetd.conf dont vous n’avez pas besoin absolument.
4) Sécurisation du système de fichiers
Détections des fichiers dotés de droits trop permissifs
- fichiers en écriture pour tous : # find / -type f –perm –o+w –ls
- fichiers en écriture pour le groupe : # find / -type f –perm –g+w –ls
- répertoires en écriture pour tous : # find / -type d –perm –o+w –ls
- répertoires en écriture pour le groupe : # find / -type d –perm –g+w –ls
Le droit sticky bit (droit t) doit être attribué a tous les répertoires communs, pour permettre aux utilisateurs décrire dans le répertoire mais seul le propriétaire d’un fichier pourra le modifier et le supprimer.
- chmod 1000 fichier ou dossier
Recherche des fichiers .rhosts
Ce fichier s’il existe, autorise l’accès sans mot de passe à votre compte pour des utilisateurs locaux ou distants listés dans ce fichier. Cette option ne devrait être utilisée que par des utilisateurs expérimentés. Pour découvrir tous les fichiers .rhosts sur votre système utilisez la commande suivante en changeant /home par le répertoire accueillant les répertoires des différents utilisateurs :
- find /home –name .rhosts –print
Droits suid et sgid
Certains programmes ont besoin de droits privilégiés pour être exécutés, pour cela on peut leur attribuer suid (Set User ID) ou sgid (Set Group ID). Donc le programme sera exécuté avec les privilèges du propriétaire pour suid ou du groupe pour sgid . Il est impératif de contrôler l’utilisation de ces droits, il faut limiter au maximum l’utilisation du droit suid lorsque le fichier appartient à un compte privilégié comme le compte root. Seuls quelques programmes devraient en être dotés.
- Recherche des fichiers dotés du droit suid : # find / -perm -4000 –type f –ls
- Recherche des fichiers dotés du droit sgid : # find / -perm -2000 –type f –ls
Pour interdire l’utilisation des programmes dotés de l’attribut suid, positionnez l’option nosuid au montage d’un système de fichiers. Le montage du système de fichiers avec l’option nosuid permet de contrer ce genre d’initiative. Le contenu de /etc/fstab doit être modifié en conséquence au lieu de default, il faut mettre nosuid pour les partitions sur lesquels peuvent écrire des utilisateurs autres que root.
Sudo
Un simple utilisateur n’a pas beaucoup de pouvoir sur un système linux, ce privilège étant réservé au compte root. Toutefois, l’administrateur (root) lui-même travaille le plus souvent sous un autre compte, principalement pour des raisons de sécurité. A la longue il peut être pénible de devoir utiliser le compte root pour effectuer des opérations brèves. Le programme sudo permet de s’affranchir de cette contrainte. Elle permet aussi de donner plus de pouvoir a un utilisateur, de plus comme sudo permet de logguer tous les évènements, on sait qui a fait quoi et quand. Toute la configuration se fait par le fichier /etc/sudoers. L’édition de /etc/sudoers se fait par : visudo
Voici les paramètres qui nous intéressent :
- User alias specification : permet de définir des alias pour les utilisateurs auquel sudova donner des droits particuliers. Vous pouvez définir des groupes : User_Alias Arenhack=Draven,Sps6m3n,CLAD. Lorsque vous donnerez des droits à ArenHack ce sont Draven, Sps6m3n et CLAD qui en bénéficieront.
- Cmnd alias specification : permet de définir des alias pour les commandes que vont pouvoir exécuter les utilisateurs. Cmnd_Alias NET =/bin/ping, /usr/bin/traceroute, /usr/bin/nmap. La commande NET autorise le ping, traceroute et nmap.
- User privilège specification : permet de donner les droits à un utilisateur. Vous remarquerez que par défaut une ligne est déjà présente, elle concerne root qui a tous les droits. Mettons en application nos exemples précédents : Arenhack ALL=(ALL) NET, les membres du groupe Arenhack. Le premier ALL, n’est pas très important sauf si l’on exporte son fichier sudoers, il s’agit de la machine sur laquelle les droits de la ligne sont valables. Le second ALL représente l’utilisateur dont on prend les droits (on peut mettre Benja donc ont disposera de ses droits en plus de nos propres droits, on pourra tout détruire dans son /home). NET regroupe les commandes définis plus haut. Pour conclure grâce à cette configuration les utilisateurs Draven, Sps6m3n et CLAD pourront utiliser ping, traceroute et nmap. Pour effectuer des opérations sans passer root: Sps6m3n ALL=(ALL) NOPASSWD :ALL, désormais Sps6m3n pour passer root devra taper sudo puis Entrée, sans lui demander de mot de passe. Lorsqu’on veut exécuter une commande ponctuelle en tant que root il suffit de faire précéder la commande en question par sudo.
Mot de passe
La plupart des Unix utilisent un algorithme de cryptage à sens unique, appelé DES (Data Encryption Standard) pour crypter les mots de passe. Pour une plus grande sécurité utilisez le fichier de mots de passe shadow (/etc/shadow et non le fichier /etc/passwd), qui n’est accessible que par root (dans la plupart des distributions récentes il suffit de rentrer pwconv pour activer les mots de passe shadow). DES n’est pas réversible, il n’existe aucun moyen connu de retrouver directement le mot de passe en clair à partir de la version chiffrée. Le seul moyen de découvrir le mot de passe en clair est de le brute forcer. Utilisez l’avantage des perceurs de mots de passe pour identifier les faiblesses des votres (John the ripper, Crack...). Changez de mots de passe fréquemment (tous les 3 mois), pour le constituer utilisez en alternance des lettres, chiffres, caractères spéciaux, alterner majuscules et minuscules, veillez à ce que votre mot de passe n'est pas de signification et bien sûr veillez à ce qu’il soit d’une taille respectable (minimum plus de 10 caractères).
Compte root
Le répertoire /root ne doit être accessible en écriture et en lecture que par root lui-même. Le masque de protection pour la création des fichiers ne doit permettre qu’à l’administrateur de modifier ses propres fichiers (umask 022 ou mieux 077). N’utilisez jamais les r-commandes (rlogin, rsh…) en tant que root. Elles n’utilisent pas d’authentification par mot de passe mais un mécanisme de sécurité basé sur des machines et des utilisateurs de confiance. Pour cela il faut des bases de données qui définissent les machines et utilisateurs de confiance qui sont /etc/hosts.equiv et .rhosts. Des r-commandes mal configurées peuvent permettre des accès à votre ordinateur par tous. N’employez les r-commandes que si vous êtes un utilisateur expérimenté.
Il faut interdire les connexions telnet pour le compte root, car les connexions telnet transmettent en clair sur le réseau à la vue des regards indiscrets. Pour cela éditez le fichier /etc/securetty, indiquer seulement tty1, tty2 dans ce fichier, restreignant ainsi les accès root à des accès locaux. Ceci oblige les utilisateurs à se logger avec leur propre identité, et de passer en root avec la commande su. ttyp1, ttyp2, ttyp3…. sont des pseudo-terminaux , permettant au root d’établir des connexions telnet à distances. De toutes évidences préférezSSH à Telnet.
Limiter les accès FTP
Tout compte présent dans le fichier /etc/ftpusers, ne pourra faire d'appel ftp sur le système. Placez y le compte root qui ne devrait pas accéder au compte ftp. Par contre tout compte ayant besoin d’un accès ftp ne doit pas figurer dans le fichier /etc/ftpusers. Pour protéger vos communications ftp faites appel au cryptage SSL (Secure Socket Layer) qui a été conçu pour les applications de commerce en ligne. SSL peut être employée pour des applications telles que telnet, ftp, HTTP.
Blocage des comptes inutiles
A l’installation du système de nombreux comptes sont créés. Seul le compte administrateur root est un compte de connexion, peu sont à conserver. Enlever la plupart des comptes systèmes présent par défaut dans /etc/passwd. Linux fournit ces comptes pour différents services systèmes dont vous pouvez ne pas avoir besoin. Si tel est le cas enlevez-les. Nombres de vos comptes facilitent l’accès à votre système.
Contrôle d'accès avec Wrapper
Pas besoin de télécharger où d’installer le logiciel tcpd, il est partit intégrante de la distribution linux. Il se base sur 2 fichiers : /etc/hosts.allow et /etc/hosts.deny pour contrôler les accès. Les accès accordés par hosts.allow ne peuvent être remis en question par hosts.deny. Voici le format des 2 fichiers :
Liste des services : liste des machines [ : commande-interpréteur ] |
Ex : ftpd, telnetd : Draven.org //qui accorde un accès ftp et telnet à toutes les machines du domaine Draven
- ALL : LOCAL //désigne tous les services pour toutes les machines locales, c'est-à-dire sans point dans le nom
- ALL : LOCAL, Draven.org //pareil qu’avant mais toute l’extension de nom de domaine Draven.org est aussi acceptable
- ALL : ALL //Pas besoin d’expliquer ici, seuls les services démarrés par inetd, et seulement ceux dont les entrées dans inetd.conf ont été éditées pour exécuter tcpd, sont concernés
- ALL : Draven.org EXCEPT public.Draven.org //autorise un accès à toutes les machines du domaines Draven.org sauf a public.Draven.org
Variables de tcpd utilisées dans les commandes interpréteur :
VARIABLE |
VALEUR |
%a | L’adresse IP du client |
%A | L’adresse IP du serveur |
%c | Toutes les informations disponibles sur le client, nom de l’utilisateur inclus |
%d | Le nom du démon qui fournit le service réseau |
%h | Le nom de machine du client. Si le nom de la machine est indisponible, l’adresse IP est utilisée |
%H | Le nom de machine du serveur |
%n | Le nom de machine du client. Si le nom de la machine est indisponible, le mot-clé UNKNOWN est utilisé. Si suite à une recherche dans le DNS, le nom de la machine cliente et l’adresse IP ne correspondent pas, le mot-clé PARANOID est utilisé |
%N | Le nom de machine du serveur |
%P | Le numéro de processus (PID) du démon qui fournit le service réseau |
%s | Toutes les informations disponibles sur le serveur, nom de l’utilisateur inclus s’il est accessible |
%u | Le nom de l’utilisateur du client ou le mot-clé UNKNOWN si le nom de l’utilisateur est indisponible |
%% | Le caractère pourcent (%) |
La commande pour l’interpréteur permet de rassembler plus d’information sur les intrus ou pour informer immédiatement l’administrateur système.
Ex : ALL : ALL : (safe_finger –l @%h | /usr/sbin/mail –s %d - %h root) &
Signifie que tous les systèmes à qui un accès n’est pas accordé explicitement dans le fichier hosts.allow ne peuvent accéder à aucun service. Après écriture dans le journal de la tentative d’accès, tcpd transmet à l’interpréteur de commande safe_finger pour qu’elle s’exécute ce qui permet de retrouver l’agresseur. Le résultat est envoyé par mail au compte root. L’esperluette (&) à la fin de la ligne produit l’exécution de la commande en arrière plan.
Contrôle d'accès avec xinetd
Le démon xinetd apporte des possibilités similaires à celle de wrapper. Il gère les contrôles d’accès définis dans les fichiers /etc/hosts.allow et /etc/hosts.deny. xinetd fournit sa propre journalisation et des contrôles d’accès qui lui sont spécifiques.
Le démon xinetd fournit 2 paramètres de journalisation : log_on_sucess et log_on_failure qui permettent de personnaliser les entrées du journal standard lorsqu’une connexion réussie ou échoue. Voici les options de journalisation acceptées :
USERID : Place dans le journal l’identifiant utilisateur de l’utilisateur distant. S’applique aux 2 paramètres.
HOST : Place dans le journal l’adresse de la machine distante. S’applique aux 2 paramètres.
PID : Place dans le journal l’identifiant du processus du serveur invoqué pour prendre en charge la connexion. S’applique uniquement à log_on_success.
DURATION : Place dans le journal la durée pendant laquelle le serveur s’occupant de cette connexion a fonctionné. Uniquement pour log_on_success.
EXIT : Place dans le journal l’état de fin du serveur lorsque la connexion se termine. Uniquement pour log_on_success.
ATTEMPT : Place dans le journal les tentatives de connexion infructueuses. Uniquement pour pour log_on_failure.
RECORD : Place dans le journal les informations de connexion reçues depuis le serveur distant. Uniquement pour log_on_failure.
Le démon xinetd offre aussi 3 paramètres pour le contrôle d’accès :
only_from
: identifie les machines qui ont la permission de se connecter au service. Les
machines peuvent être données par :
# adresse numérique 172.80.12.50 pour une machine spécifique.
172.80.0.0 pour toutes les machines avec une adresse commençant par 172.80.
Où 0.0.0.0 pour toutes les adresses.
# un étendue d’adresse. 172.80.12.{5,6,12,25} désigne 4
machines différentes : 172.80.12.5, 172.80.12.6, 172.80.12.12, 172.80.12.25.
# un nom de réseau. Celui-ci doit être présent dans
/etc/networks.
# un nom canonique de machine. L’adresse IP fournie par le système
distant doit être résolu de manière inverse en ce nom de
machine.
# Un nom de domaine. Le nom de machine renvoyé par la recherche inversée
doit faire partie du domaine en question.
# une adresse IP associés à une adresse de masque. Ex : 172.16.12.128/25
correspondra aux adresses comprises entre 172.16.12.128 et 172.16.12.255.
no_access : définit les machines qui n’ont pas accès au service. Les machines précisées avec les mêmes méthodes que celles de l’attribut only_from.
access_times : spécifie les moments de la journée où un service est disponible. Si, ni only_from, ni no_accessne sont indiqués, l’accès est accordé à tout le monde.
Le chiffrement est une technique pour restreindre l’accès aux données. Le chiffrement code les données sous une forme qui ne peut être lue que par les systèmes qui possèdent la « clé » du mécanisme d’encodage. Utilisons GPG (GNU Privacy Guard) :
Création d'une clé
gpg --gen-key //la génération initiale des clés ne doit être effectué qu’une fois
GPG affiche "Your selection ?" Sélectionnez 1, qui est le choix par défaut.
Ensuite il demande la longueur de la clé (What keysize do you want ?) la valeur par défaut est 1024 bits, qui est bien assez long.
GPG demande votre nom, adresse électronique et en option un commentaire. Qui lui permettra d’identifier vos clés dans la base de données des clés. Il demande aussi une "passphrase" pour vous identifier lorsque vous accédez à votre clé secrète.
Processus de chiffrement
L'outil gpg se sert de 2 bases de données de clés : une pour les clés secrètes (secring.gpg) et une pour les clés publiques (pubring.gpg). Les clés publiques et privéees sont à la fois utilisées lors du chiffrage et du déchiffrage.
gpg
--recipient paul@Draven.org --encrypt test.txt |
La base de données pubring.gpg peut contenir plusieurs clés publiques. Le paramètre recipient (destinataire) identifie la clé publique à utiliser. GPG crée un fichier codé qui possède le même nom avec l’ajout de l’extension .gpg. Après vérification que le fichier chiffré existe, le fichier en clair doit être supprimé. Il est inutile de chiffrer un fichier si le fichier déchiffré existe encore, exposé aux yeux de tous.
Processus de déchiffrement
gpg
--output test.txt --decrypt test.txt.gpg |
Output indique ou écrire le fichier chiffré, ici test.txt.gpg vous demandera votre passphrase avant de déchiffrer.
7) Configuration sécurisée de la pile TCP/IP
Ignorez certains messages ICMP
ICMP redirect indique à une machine ou un routeur le chemin le plus court pour joindre une destination donnée. Pour éviter les attaques de types MIM (Man In the Middle attack) il faut ignorer ICMP redirect. Pour cela ajouter les lignes suivantes au fichier /etc/sysctl.conf après l’installation du système.
#ignore
les messages ICMP redirect net.ipv4.conf.all.accept_redirects = 0 |
Des paquets ICMP echo request envoyés par le message ping peuvent dans certains cas, être utilisés pour scanner un réseau ou provoquer un déni de service. Pour désactiver la prise en compte de ces requêtes. Il faut modifier le fichier de configuration /etc/sysctl.conf.
#Ignore
les messages ICMP echo request net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_echo_ignore_all = 1 |
Pour garder une trace d’une machine avec une adresse source falsifiée ou non routable. Il est utile de garder une trace de ces paquets.
#
logs des paquets martiens |
Protection contre l’IP spoofing, le paramètre rp_filter permet d’éviter dans une certaine mesure les attaques par IP spoofing. Son activation est obligatoire sur une machine linux qui fait office de routeur.
#
Détection spoofing net.ipv4.conf.all..rp_filter = 1 |
Pour vous protéger des attaques de type SYN flood, le paramètre tcp_syncookies permet de s’en protéger.
#
Activation de tcp_syncookies net.ipv4.tcp_syncookies = 1 |
Un pare-feu est un composant essentiel de la sécurité d’un système informatique. Ce dernier fournit un contrôle d’accès strict entre votre système et le monde extérieur. Le pare-feu est un point de convergence à travers lequel doit passer tout le trafic pour permettre de le surveiller et de le contrôler plus aisément. De la même façon qu’il restreint l’accès depuis le monde extérieur vers votre système, il limite aussi l’accès de votre système vers le monde extérieur. Seuls les services vitaux véritablement indispensables pour communiquer avec les systèmes externes doivent être offerts par le pare-feu. Voyons quelques commandes de bases de l’outil iptables fourni avec plusieurs systèmes unix.
Filtrage du trafic
Le noyau linux classe le trafic de pare-feu en 3 groupes et applique des règles de filtrage différentes à chaque catégorie de trafic :
INPUT : le trafic entrant à destination
d’un processus sur le système local est testé par les règles
de filtrage INPUT avant d’être accepté
OUTPUT : le trafic émis qui est initié
depuis le système local est soumis aux règles de filtrage OUTPUT
avant envoi.
FORWARD : le trafic d’un système externe à destination
d’un autre système externe est analysé par les règles
de filtrage FORWARD.
Les règles INPUT et OUTPUT sont utilisées lorsque le système exerce les fonctions de machine. Les règles FORWARD sont employées lorsque le système joue le rôle de routeur.
Définitions des règles de filtrage
Le noyau linux conserve une liste de règles pour chacune de ces catégories. Les listes de règles sont entretenues par la commande iptables, voici les options :
OPTION |
FONCTION |
-A | Ajoute des règles à la fin d’un ensemble de règles |
-D | Supprime des règles d’un ensemble de règles |
-E | Renomme un ensemble de règles |
-F | Efface toutes les règles d’un ensemble de règles |
-I | Insère une règle à un endroit précis dans un ensemble de règles |
-L | Liste toutes les règles d’un ensemble de règles |
-N | Crée un ensemble de règles utilisateur avec le nom spécifié |
-P | Définit la politique par défaut d’une chaîne |
-R | Remplace une règle dans une chaîne |
-X | Supprime l’ensemble des règles utilisateur indiqué |
-Z | Remet à zéro tous les compteurs de paquets et d’octets |
Les règles du pare-feu sont constituées du filtre avec lequel les paquets sont identifiés et de l’action à appliquer lorsqu’un paquet est reconnu par le filtre :
ACCEPT : laisse passer le paquet à
travers le pare-feu
DROP : détruit le paquet
QUEUE : transmet le paquet à l’espace utilisateur pour traitement
RETURN : dans un ensemble de règles utilisateur, indique de
revenir à l’ensemble de règles appelant. Dans un des 3 ensembles
de règles du noyau, spécifie de quitter la chaîne et d’employer
la politique par défaut pour celle-ci.
La commande iptables construit des filtres qui réalisent l’identification en se basant sur le protocole utilisé, l’adresse source ou destination ou l’interface réseau employée pour le paquet, grâce à un éventail de paramètres en ligne de commande. Les paramètres élémentaires d’iptables pour construire des filtres sont :
-p protocole
: définit le protocole auquel cette règle s’applique. protocole
peut être une valeur numérique quelconque du fichier /etc/protocols
ou un de ces mot-clés : tcp, udp, ou icmp.
-s adresse[/masque] : définit
l’adresse source des paquets à laquelle la règle s’applique.
adresse peut être un nom de machine, un nom de réseau ou une adresse
IP.
--sport [port[ :port]] : définit
le port source des paquets auquel la règle s’applique. port peut
être un nom ou un numéro du fichier /etc/services. Un intervalle
de ports peut être spécifié en se servant du format port:port.
Si aucune valeur de port particulière n’est donnée, tous
les ports sont pris en compte.
-d adresse[/masque] : définit l’adresse
de destination des paquets à laquelle la règle s’applique.
adresse peut être un nom de machine, un nom de réseau ou une adresse
IP.
--dport [port[ :port]] : définit le port
de destination auquel la règle s’applique. Tout le trafic destiné
à un port particulier est filtré. Le port est spécifié
en utilisant les mêmes règles que celles employées pour
la définition des valeurs de la source du paquet.
--icmp-type type : définit
le type ICMP auquel la règle s’applique. type peut être n’importe
quel nom ou numéro de type de message ICMP valide.
-i nom : définit le nom
de l’interface réseau d’entrée auquel la règle
s’applique. Seuls les paquets reçus sur cette interface sont concernés
par la règle. Spécifiez un nom partiel d’interface en le
terminant par un + (par exemple, eth+ reconnaît toutes les interfaces
Ethernet qui commence par eth).
-o nom : définit le nom
de l’interface réseau de sortie auquel la règle s’applique.
Seuls les paquets envoyés via cette interface sont concernés par
la règle. Spécifiez un nom partiel d’interface en le terminant
par un + (par exemple, eth+ reconnaît toutes les interfaces Ethernet qui
commencent par eth).
-f : indique que la règle
se rapporte uniquement au second morceau et aux suivants des paquet fragmentés.
Exemple :
iptable
–F INPUT iptables –F FORWARD ipatbles –A INPUT –i eth1 –j DROP iptables –A FORWARD –i eth1 –s 172.16.0.0/16 –j DROP iptables –A FORWARD –o eth1 –d 172.16.0.0/16 –j DROP iptables –A FORWARD –d 172.16.12.1 25 –j ACCEPT iptables –A FORWARD –d 172.16.12.6 80 –j ACCEPT iptables –A FORWARD –j DROP |
Les 2 premières lignes effacent les ensembles de règles sur lesquels il va y avoir des modifications. La troisième ligne détruit tous les paquets du réseau externe à destination d’un processus s’exécutant localement sur le routeur linux. Les lignes 4 et 5 détruisent les paquets qui sont routés vers le monde extérieur et qui contiennent une adresse interne. Lignes 6 et 7, elles acceptent les paquets si la destination et le port désignent un des serveurs spécifiques autorisés. Ainsi le port 25 est le port SMTP et 172.16.12.1 est le serveur de courrier électronique, et le port 80 correspond au port HTTP et 172.16.12.6 est l’adresse du serveur web. La dernière ligne rejette tout autre trafic. Voici quelques exemples qui illustrent la puissance des fonctionnalités de filtrage de linux. Certes pour construire un véritable pare-feu, il faut en faire plus, mais ceci n’est qu’une petite introduction, alors à vos claviers...
L’OS parfait n’existera jamais tout comme la sécurité informatique ne sera jamais infaillible, car ils sont tous 2 élaborés, mis en place et utiliser par l’Homme. Le bon sens est l’outil le plus approprié qui puisse être utilisé pour établir votre politique de sécurité. Les systèmes et les mécanismes de sécurité complexes sont impressionnants et ils sont nécessaires, cependant il est inutile d’investir de l’argent et du temps dans un système évolué si les contrôles élémentaires ont été oubliés. Peu importe ce que vous faites, vous aurez des problèmes. Acceptez cela et préparez-vous y. Une authentification utilisateur correcte, une surveillance système efficace et une administration système compétente sont la base d’une bonne sécurité. Des outils sont disponibles pour vous aider dans ces tâches : SSH, OPIE, Tripwire, OpenSSL, iptables, TCP wrappers, le chiffrement et les pare-feu….Ce rassemblement de connaissances est comme son nom l’indique la base d’une bonne sécurité donc nullement une solution miracle à vos problèmes présent ou futur juste une ligne de conduite recommandable, qui permettront de vous guider dans vos recherches pour approfondir ces multiples points.
Références : "Sécuriser un réseau
linux de Bernard Boutherin et Benoît Delaunay" (Eyrolles)
___________"TCP/IP administration de réseau
de Craig Hunt" (O’Reilly)
Remerciements : SpS6m3N (Arenhack
Team) pour les défis qu’ils me donnent, le soutient et la confiance
qu’il m’apporte.
_______________Deepfear et vRz (DHS-Team) pour
leurs soutient et conseils.
BY DRAVEN
Copyright © 2004 ARENHACK - DHS