Protections
[ Accueil ] [ Attaques ] [ Etude de cas ] [ Contrôles possibles ] [ Protections ] [ Les Firewalls ] [ Client Windows ]
Savoir ce qui est installé
La première règle est bien entendu de savoir exactement quels sont les services installés sur sa machine et de n'y laisser que ce qui est strictement nécessaire. Cette méthode, surtout dans le cas d'un réseau local connecté à l'Internet par une passerelle est toutefois assez pénalisante. On peut souhaiter disposer de quelques services sur l'hôte qui sert de passerelle.
Bien entendu, la solution la plus sûre consiste à installer une passerelle qui ne fera que son travail de passerelle et de firewall et d'installer par ailleurs sur le réseau privé un serveur pour les divers services souhaités. Ca augmente tout de même le nombre de machines et la facture EDF. Ca ne résoudra pas non plus certains problèmes pour les entreprises qui souhaitent accéder à certaines de leurs ressources depuis l'extérieur, mais le cas de figure dépasse largement le propos de cet exposé.
Construire une barrière
Etat des lieux
Une solution de protection consiste à interdire l'accès aux ports inutiles côté Internet. Sur Linux Mandrake 7.x (plus généralement avec un noyau 2.2.x bien compilé), ceci peut se faire avec IPChains. Les noyaux 2.4.x, bien que supportant IPChains, gagneront à exploiter plutôt IPTables, nettement plus évolué.
Pour fixer les esprits, donnons un exemple.
Soit une machine Linux servant de passerelle sur l'Internet. Comme on aime bien jouer avec les diverses applications fournies, on y a installé:
- SAMBA, pour communiquer avec le réseau Microsoft.
- APACHE, pour tester ses pages web sur un serveur classique de l'Internet
- WU-FTPD, serveur FTP pour pouvoir charger ses pages HTML avec les outils de FrontPage.
- BIND, pour avoir son propre DNS,
- POSTFIX, pour avoir son propre serveur SMTP,
- VNC SERVER pour ouvrir des sessions X depuis les postes Microsoft du réseau privé.
- Et j'en passe...
Et comme on ne veut pas s'embêter, la règle par défaut sur INPUT est ACCEPT.
Croyez-vous que ce soit prudent? Pas du tout bien entendu. Sur une machine exposée à l'Internet, moins on installe de serveurs, mieux ça vaut. Examinons ce que verrait un pirate qui ferait un "scan" de cette machine avec l'un des meilleurs outils dans le genre: nmap (inclus dans les distributions Mandrake ).
Démonstration :
 |
De quoi vraiment donner envie de s'y intéresser de plus près!
Bon, ça suffit comme ça pour l'instant. Exploitons un peu le sujet... |
Telnet, c'est intéressant:
Welcome to gateway2.maison.mrs Linux Mandrake release 7.1 (helium) Kernel 2.2.16-9mdk on an i586 login:
Voilà, une Mandrake 7.1 avec un kernel 2.2.16-9 et la machine s'appelle gateway2.maison.mrs. Ca c'est intéressant. Allons faire un tour sur le DNS du monsieur...
E:\>nslookup Serveur par défaut : <peu importe> Address: <peu importe> > server 62.161.100.113 Serveur par défaut : ca-ol-marseille-5-113.abo.wanadoo.fr Address: 62.161.100.113 > set q=any > ls maison.mrs [ca-ol-marseille-5-113.abo.wanadoo.fr] maison.mrs. NS server = gateway2.maison.mrs gateway2 A 192.168.0.253 remi A 192.168.0.12 michele A 192.168.0.2 chris A 192.168.0.10 gateway1 NS server = 192.168.0.250 daniel A 192.168.0.11 gateway2 NS server = 192.168.0.253
Et hop! On sait tout du réseau de ce monsieur :-) (Même, si vous avez bien suivi, que ce monsieur dispose sans doute d'une seconde machine du même genre qui s'appelle gateway1)
Il faut dire que c'est quand même très mal, de laisser libre le transfert de zone sur un DNS. Mais j'ai trouvé cette gravissime lacune sur des sites très "officiels".
Reprenons le scénario, mais avec BIND correctement configuré. Ca donne ceci:
E:\>nslookup Serveur par défaut : gateway1.maison.mrs Address: 192.168.0.250 > server 62.161.100.113 Serveur par défaut : ca-ol-marseille-5-113.abo.wanadoo.fr Address: 62.161.100.113 > set q=any > ls maison.mrs. ls: connect: No error *** Impossible de fournir la liste du domaine maison.mrs.: Unspecified error > pchris.maison.mrs Serveur : ca-ol-marseille-5-113.abo.wanadoo.fr Address: 62.161.100.113 *** ca-ol-marseille-5-113.abo.wanadoo.fr ne parvient pas à trouver pchris.maison.mrs : No response from server
C'est déjà mieux, au moins le DNS ne répond plus aux requêtes venant de l'Internet. Comment il faut faire? Dans /etc/named.conf, il faut utiliser les directives "allow-transfert", "allow-query" et même "listen-on" (cf. la doc. de BIND)
Cet exemple est juste donné pour bien montrer que la sécurité passe d'abord par une configuration correcte des serveurs installés...
Mais continuons l'investigation. Voyons le serveur FTP, un petit coup de telnet sur le port 21:
220 gateway2.maison.mrs FTP server (Version wu-2.6.0(1) Wed Jun 28 23:51:34 EDT2000) ready.
Oui, c'est bien un wu-ftp, version 2.6.0. Faudra voir ce qu'il y a comme "exploits" là dessus. On va s'arrêter là, mais il y a pas mal d'investigations à faire sur un serveur FTP
Allez, encore un telnet sur le port 25
220 gateway2.maison.mrs ESMTP Postfix (Postfix-19991231) (Linux-Mandrake)
C'est bien Postfix. (Là aussi, il y aurait encore beaucoup à faire).
Convaincu? en très peu de temps, le pirate accumule une quantité intéressante d'informations sur votre équipement, autant d'informations qu'il pourra exploiter pour essayer de "casser" votre matériel.
Comme l'objectif de cet exposé n'est pas de faire un cours sur l'intrusion (encore que ce soit le meilleur moyen pour apprendre à mettre en place des parades), on va s'arrêter là.
La situation exposée est d'autant plus absurde, qu'avec IPTables, on peut déjà compliquer passablement le travail du pirate.
Que les utilisateurs de Windows n'abandonnent pas la lecture de ce qui suit. La démonstration se fait avec IPtables, mais le principe reste vrai quel que soit l'OS. Nous verrons plus loin les solutions proposées aux utilisateurs de produits Microsoft.
Construction de barrières
Disons d'abord ce que l'on veut faire en français. D'abord une simple passerelle avec masquage d'adresses du réseau privé :
- En entrée, on accepte tout par défaut (comme c'était dans l'exemple précédent),
- en sortie, on laisse tout passer aussi,
- au travers de la passerelle (le routage entre le Net et le réseau privé), on n'accepte rien, mais on va faire du masquage d'adresse pour tout ce qui vient du réseau privé et va vers le Net,
Ensuite, pour tout ce qui vient du Net, nous bloquerons en UDP comme en TCP les ports :
- 21 tcp, qui est le port de commande FTP,
- 23 tcp, qui est le port Telnet,
- 25 tcp, qui est le port SMTP,
- 110 tcp, qui est le port POP3,
- 111 tcp/udp qui est le port des "Remote Procedure Call",
- 135 à 139 tcp/udp, des ports utilisés par NetBIOS,
- 143 tcp, le port IMAP,
- 6000 à 6009 tcp, les ports utilisés pour le serveur graphique.
iptables -P INPUT ACCEPT iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # Le MASQUERADE... iptables -t nat -A POSTROUTING -s 192.168.0.0/255.255.255.0 -o ppp0 -j MASQUERADE # et les interdictions : iptables -A INPUT -p tcp --dport 21 -i ppp0 -j REJECT iptables -A INPUT -p tcp --dport 23 -i ppp0 -j REJECT iptables -A INPUT -p tcp --dport 25 -i ppp0 -j REJECT iptables -A INPUT -p tcp --dport 110 -i ppp0 -j REJECT iptables -A INPUT -p tcp --dport 111 -i ppp0 -j REJECT iptables -A INPUT -p udp --dport 111 -i ppp0 -j REJECT iptables -A INPUT -p tcp --dport 135:139 -i ppp0 -j REJECT iptables -A INPUT -p udp --dport 135:139 -i ppp0 -j REJECT iptables -A INPUT -p tcp --dport 143 -i ppp0 -j REJECT iptables -A INPUT -p tcp --dport 6000:6009 -i ppp0 -j REJECT
Traduit en français, ça veut dire que l'on jette (REJECT) les paquets qui viennent de n'importe où pour aller n'importe où, s'ils ont le malheur de rentrer par ppp0 sur les ports 21, 23, 25, 110, 111, 139, 143 et de 6000 à 6009. C'est bien ce que nous voulions. Refaisons un scan:
Starting nmap V. 2.30BETA17 by fyodor@insecure.org ( www.insecure.org/nmap/ ) Interesting ports on ca-ol-marseille-5-113.abo.wanadoo.fr (62.161.100.113): (Ports scanned but not shown below are in state: filtered) Port State Service Owner 1/tcp unfiltered tcpmux 2/tcp unfiltered compressnet 3/tcp unfiltered compressnet ... 80/tcp open http nobody ... 113/tcp open auth nobody ... 515/tcp open printer root ... ... 3306/tcp open mysql mysql ...
TCP Sequence Prediction: Class=random positive increments
Difficulty=4917615 (Good luck!)
Remote operating system guess: Linux 2.1.122 - 2.2.14
Nmap run completed -- 1 IP address (1 host up) scanned in 220 seconds
nmap ne s'y trompe pas, il constate qu'il y a des règles de filtrage sur cette machine et essaye de trouver les ports non filtrés. Il va en trouver beaucoup, mais ça ne veut pas dire qu'ils sont ouverts. Ceux qu'il trouve ouverts sont ceux que l'on n'a pas filtrés.
Il est clair que l'on a déjà limité les problèmes. Mais on pourrait encore faire beaucoup mieux . L'objectif ici n'était que de montrer comment l'on peut établir des règles de filtrage de paquets, mais d'expliquer comment un port peut être bloqué par un firewall.
Dans la pratique, il sera probablement plus judicieux de tout interdire, puis de n'ouvrir que ce qui est nécessaire. Voyez à ce propos le chapitre sur Netfilter.
Conclusion
Ce type de protection passive offre déjà un bon niveau de sécurité, si l'on a convenablement analysé la configuration de sa machine et placé les bonnes règles. Il y aurait encore à faire sur cette machine, car si l'on a à peu près filtré les ports TCP, qui sont les plus dangereux parce qu'ils permettent un mode connecté, on n'a encore rien fait ni sur UDP, ni sur ICMP. Ces deux protocoles peuvent cependant créer des nuisances parce qu'ils peuvent être utilisés pour bloquer la machine.
Notez qu'il existe un site qui permet de construire des règles IPChains en fonction de critères de protection que l'on choisit dans des tables
http://www.linux-firewall-tools.com/linux/firewall/index.html
Cependant, il est intéressant de placer en plus quelques systèmes qui vont épier le trafic et prévenir, voire réagir, en cas d'activité suspecte avec les "loggers" et les firewalls actifs.
IPtables sait déjà "logger" les événements qui satisfont aux critères des chaînes, mais il est peut-être plus intéressant d'utiliser des outils spécifiques.
Les miradors du Net
La plupart des attaques commencent par un scan des ports ouverts sur la cible. Des outils particuliers permettent de détecter ce scan, d'en identifier la source par son adresse IP et certains permettent même de monter un firewall "sur mesure" pour bloquer l'intrus. Le scanner n'aura même pas le temps de finir son travail et aura l'impression que la cible a disparu.
Les "loggers"
J'en ai plus ou moins testé trois sous Linux, il en existe beaucoup d'autres, chacun dispose, à mon sens, d'avantages et d'inconvénients. Les trois fonctionnent sur Mandrake 7.1 et 7.2 et se trouvent au format RPM.
IPTRAF
Il ne figure plus dans la distribution 9.1, mais se trouve toujours au format rpm pour mandrake dans les contributions.
 |
C'est peut-être le plus "convivial" mais pas forcément le plus paramétrable. Il fonctionne bien en mode texte mais présente quelques bugs d'affichage dans une console sous X, suivant la taille de la fenêtre. |
| Les "anciens" de MS DOS retrouveront avec nostalgie les menus arborescents en mode caractère... |  |
| Ici, il est possible de choisir les protocoles à tracer. Malheureusement, s'il est possible de définir des filtres personnalisés pour UDP, l'option n'existe pas pour les autres protocoles.
|
Il est également possible de choisir l'interface que l'on souhaite tracer
|
Voici un exemple de trace. Si les connexions TCP sont affichées de manière très lisible, il n'en va malheureusement pas de même pour les autres protocoles
IPPL
Celui-ci fonctionne de manière différente. Son but principal étant d'enregistrer la trace dans des fichiers, bien qu'il soit possible de diriger ses traces sur une console. Lui aussi, se trouve encore dans les contributions à la version 9.1 de Mandrake.
Sa configuration se fait par le fichier /etc/ippl.conf, je n'ai malheureusement pas trouvé le moyen de limiter son activité à l'interface choisie autrement qu'en donnant son adresse IP, ce qui n'est guère pratique lorsque l'on dispose d'une adresse dynamique.
IPLOG
Assez similaire à IPPL, celui-ci permet d'indiquer l'interface à logger par son nom (eth0 par exemple). Lui aussi se configure par un fichier /etc/iplog.rules. Il est toujours distribué dans la version 9.1
Une simple manip.
- iplog est démarré :
iplog -L -i eth0
(-L pour diriger le flux dans la console)
- Le fichier iplog.rules ne contient que la ligne:
ignore udp from * sport 53
Ma machine ayant un DNS installé, les réponses des serveurs DNS sur le port 53 sont fréquentes, inutile de les tracer.
Où la paranoïa nous guette...
Tout va à peu près bien. Pour faire un test, je lance un "tracert" depuis ma station de travail :
Détermination de l'itinéraire vers www.eme-enseignement.fr [194.79.150.15] avec un maximum de 30 sauts : 1 <10 ms <10 ms 10 ms gateway2.maison.mrs [192.168.0.253] 2 20 ms 20 ms 20 ms ca-ol-marseille-1-1.abo.wanadoo.fr [62.161.96.1] 3 20 ms 20 ms 30 ms LS-ATM6-0-0-300.Marseille.raei.francetelecom.net[194.250.158.89] 4 20 ms 30 ms 30 ms POS-6-0-0.NCMAR201.Marseille.raei.francetelecom.net [194.51.171.37] 5 20 ms 30 ms 30 ms P0-2.nrlyo101.Lyon.francetelecom.net [193.252.101.74] 6 30 ms 31 ms 30 ms P2-1.ntaub101.Aubervilliers.francetelecom.net [193.251.126.206] 7 30 ms 40 ms 50 ms 193.251.126.154 8 30 ms 40 ms 40 ms P0-0.BAGBB2.Bagnolet.opentransit.net [193.251.128.142] 9 30 ms 40 ms 40 ms P1-0.BOUBB2.Paris.opentransit.net [193.251.128.58] 10 30 ms 30 ms 40 ms P0-0.BOUBB1.Paris.opentransit.net [193.251.128.233] 11 40 ms 30 ms 40 ms frpar602-tb-p0-3.ebone.net [195.158.226.213] 12 30 ms 40 ms 30 ms frpar601-tb-p0-1.ebone.net [195.158.226.197] 13 30 ms 30 ms 40 ms frpar205-tc-p9-0.ebone.net [195.158.228.157] 14 40 ms 40 ms 30 ms 195.158.228.162 15 40 ms 40 ms 40 ms ext-mixt.internext.fr [195.5.253.2] 16 140 ms 150 ms 180 ms ext-nice.paris-nice.internext.fr [194.79.128.78] 17 150 ms 180 ms 130 ms world.monaco.net [194.79.150.1] 18 130 ms 100 ms 170 ms snoopy.monaco.net [194.79.150.15] Itinéraire déterminé.
IPLOG se met alors à remplir la console...
Les "time exceeded (ICMP_ECHO)", c'est parfaitement normal, c'est le fonctionnement de la commande "traceroute" qui veut ça. Comparez la réponse du "tracert" sur mon poste avec les logs ICMP.
Mais il y a des choses plus délicates à expliquer...
- Ce qui concerne 195.158.228.162 par exemple: udp dp=137, sp=61004 ça ressemble à du NetBIOS (dp=137) qui passe le masquage d'adresses (port 61004). Mais cette adresse n'a pas de nom. Elle appartient à "ebone-backbone 4" dixit "sam spade", outil d'investigation bien connu dans le monde Windows.
Je ne sais pas expliquer cette trace.
- UDP datagram from atlas.campus.univ-poitiers.fr:123, ça, je sais. Je ne vous avais pas dit que ma machine Linux est à l'heure atomique grâce à xntpd. atlas.campus.univ-poitiers.fr est un serveur NTP (Network Time Protocol)
- UDP datagram from ns0.mrs.ftci.oleane.com:67, je sais aussi. C'est notre cher serveur DHCP/DNS. Le bail a été renouvelé.
- ICMP yoda.iae.univ-poitiers.fr:123 unreachable , c'est intéressant, parce que comme ça, je constate que l'un des serveurs NTP que j'essaye d'utiliser ne répond pas.
Snort
C'est probablement le plus puissant, avec TCPdump. Pas testés ici, ils sont nettement plus délicats à manipuler, mais ce sont les meilleurs.
Conclusions
Un outil de log comme iplog est un bon moyen pour contrôler le trafic. Il ne sait cependant tracer que ce qu'il lui est demandé (ce que vous lui demandez) et uniquement ce qu'il lui est demandé. Ca veut dire deux choses importantes:
- Il tracera des événements qui n'en valent peut-être pas la peine. Si vous lui demandez de tracer tout trafic sur une interface, il le fera. Les logs de la journée risqueront peut-être de peser plusieurs Mo et seront inexploitables, autrement que par des filtres qu'il vous faudra écrire.
- Il ne tracera peut-être pas des événements qu'il aurait été important de ne pas rater.
Vous apprendrez certainement beaucoup de choses en passant du temps à essayer de maîtriser ce genre d'outils
Les Coupe feux actifs
Un coupe feu actif, en plus de surveiller les connexions entrantes est capable de détecter une activité réputée frauduleuse et y parer de manière dynamique. Il existe sous Linux au moins une application de ce type: "Portsentry"
Portsentry, le pompier du Net
Portsentry est capable de détecter un "scan" de ports TCP et UDP. La détection peut déclencher plusieurs types de parades:
- Un simple "log" via syslogd. Dans ce cas, Portsentry agit comme un simple "loggeur", un peu léger toutefois, puisqu'il ne sait pas traiter les activités ICMP.
- Une inscription du scanner dans "hosts.deny", pour qu'il soit pris en compte par le "TCP Wrapper"
- L'ajout d'une règle dans la chaîne "input" d'IPtables pour bloquer l'intrus.
- La modification de la route par défaut dans un "black hole" de manière à ce qu'une éventuelle réponse à l'intrus soit dirigée vers nulle part.
- Le déclenchement d'une commande externe pouvant être, par exemple, la désactivation pure et simple de l'interface réseau.
Bien entendu, ces parades sont configurables.
Juste un exemple
- Dans le rôle de l'intrus: 213.56.228.199. Une machine Linux équipée du scanner "nmap".
- Dans le rôle du défenseur, une autre machine Linux, équipée de portsentry. La configuration est à peu de choses près celle qui est donnée par défaut dans le paquetage rpm pour Mandrake. En cas de détection de scan, portsentry va réagir de la manière suivante:
- Inscription de l'intrus dans /etc/hosts.deny"
- Ecriture d' une règle de blocage dans IPChains (fonctionne aussi avec IPTables).
Avant l'attaque
Voyons un peu l'allure de la chaîne INPUT (IPtables):
Chain INPUT (policy ACCEPT) target prot opt source destination REJECT tcp -- anywhere anywhere tcp dpt:telnet reject-with icmp-port-unreachable REJECT tcp -- anywhere anywhere tcp dpt:smtp reject-with icmp-port-unreachable
Les protections sont très simplistes, seuls telnet et smtp sont filtrés.
Portsentry est démarré avec la commande "portsentry -atcp" (Entamer ici une étude détaillée de portsentry nous mènerait trop loin.).
Le démarrage de portsentry ajoute ces lignes au fichier /var/log/messages:
adminalert: Psionic PortSentry is starting. adminalert: Advanced mode will monitor first 1023 ports adminalert: Advanced mode will manually exclude port: 113 adminalert: Advanced mode will manually exclude port: 139 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 21 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 23 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 25 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 53 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 80 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 110 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 111 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 113 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 139 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 143 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 515 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 820 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 901 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 113 adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 139 adminalert: PortSentry is now active and listening.
L'attaque a lieu...
Le scan est démarré avec nmap sur l'hôte "pirate". Portsentry s'en rend compte et effectue les opérations suivantes:
- Les lignes qui suivent sont ajoutées au journal /var/log/messages
attackalert: SYN/Normal scan from host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 to TCP port:52
attackalert: Host 213.56.228.199 has been blocked via wrappers with string: "ALL: 213.56.228.199"
attackalert: Host 213.56.228.199 has been blocked via dropped route
using command: "/sbin/ipchains -I input -s 213.56.228.199 -j DENY"
attackalert: SYN/Normal scan from host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 to TCP port:175
attackalert: Host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 is already blocked Ignoring
attackalert: SYN/Normal scan from host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 to TCP port:32
attackalert: Host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 is already blocked Ignoring
attackalert: SYN/Normal scan from host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 to TCP port:621
attackalert: Host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 is already blocked Ignoring
attackalert: SYN/Normal scan from host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 to TCP port:312
attackalert: Host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 is already blocked Ignoring
- La règle suivante est ajoutée dans la chaîne INPUT d'IPChains:
Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- 213.56.228.199 anywhere *** L'attaquant est bloqué sur tous les ports, sur tous les protocoles, *** quelle que soit la destination REJECT tcp -- anywhere anywhere tcp dpt:telnet reject-with icmp-port-unreachable REJECT tcp -- anywhere anywhere tcp dpt:smtp reject-with icmp-port-unreachable
-
Le fichier /etc/hosts.deny est modifié de la manière suivante:
# # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # The portmap line is redundant, but it is left to remind you that # the new secure portmap uses hosts.deny and hosts.allow. In particular # you should know that NFS uses portmap! #ALL: 213.56.228.199
Bilan
L'attaquant n'aura même pas le temps de finir son scan. il aura l'impression que la cible n'existe plus, tout simplement.
N'est-ce pas joli? Attention toutefois, si la modification de /etc/hosts.deny n'est pas volatile (écriture dans le fichier), il n'en va pas de même pour IPChains. Sans précautions particulières, si la machine est arrêtée, la règle sera perdue. Il existe cependant une parade grâce, par exemple, à la possibilité d'exécuter une commande externe en cas de détection d'attaque. Il suffit de sauvegarder la règle INPUT pour pouvoir la recharger au prochain démarrage. Ceci dit, les attaques venant le plus souvent d'adresses dynamiques, il n'est pas forcément nécessaire de rendre la règle définitive. Par ailleurs, si l'on agit sur IPChains, il n'est pas nécessaire de conserver l'option de modification de /etc/hosts.deny.
Notez tout de même que nous n'avons pas couvert les risques émanant:
- D'un scan UDP.
C'est généralement moins dangereux, mais pas à négliger tout de même. Portsentry peut également être démarré pour surveiller les ports UDP, mais le fonctionnement est plus délicat et peut provoquer des réactions parasites. - D'une attaque ICMP
Portsentry ne sait rien faire contre ça. Il ne vous reste de ce côté qu'à écrire des règles correctes. - D'une attaque sans qu'il y ait de scan préalable
Portsentry n'est donc hélas pas un outil miraculeux, il n'en existe d'ailleurs pas.
Malheureusement, cet outil ne semble plus être fourni avec Mandrake 9.1