Vérrouiller avec le pare-feu iptables de Arno

par (Copyright C) S. Keeling      keeling CHEZ spots POINT ab POINT ca

traduit par (Copyright C) Philippe FRATTINO      philippe CHEZ frattino POINT com

relecture

Vérrouiller avec le pare-feu iptables de Arno

Sommaire

Ceci décrit mon expérience sur le passage d'un scripts pour pare-feu iptables fait "maison" vers ⁱⁱ to "Arno's iptables-firewall" (AIF)^v, de Arno van Amersfoort (arnova CHEZ xs4all POINT nl). AIF donne un pare-feu robuste basé sur iptables, même dans les mains d'un débutant au niveau de iptables. Entre la lecture la documentation et la mise en place, il faut compter une petite heure.

Inconvénients

AIF est décrit dans le README de Arno sous le titre "Arno's iptables firewall - Single- & multi-homed firewall script with DSL/ADSL support". Il est sous (C) Copyright 2001-2005 par Arno van Amersfoort. C'est un logiciel libre, sous la licence GNU General Public Licence.

Si vous éte décidé a l'utiliser, je vous conseille fortement de LIRE LA FAQ sur le site web de Arno, encore plus si vous vous abonnez à la liste de discussion pour avoir un support. Arno previent que toute demande sera méticuleusement ignorée tant que vous ne serez pas informé par la lecture de la FAQ.

Etant entendu que nous sommes au Vingtième Siècle:

JE NE VOUS CONSEILLE PAS DE LE FAIRE! SI VOUS PASSEZ OUTRE ET QUE QUELQUE CHOSE
S'EN TROUVE CASSÉ, ATTENDEZ-VOUS A RAMASSER DES MORCEAUX. JE DECLINE,
EXPRESSEMENT ET VIGOUREUSEMENT, TOUTES RESPONSABILITÉS CONCERNANT TOUS LES
RÉSULTATS NÉGATIFS QUE VOUS OU QUICONQUE PUISSIEZ ENDURER. CE QUI SUIT EST
ÉCRIT SEULEMENT POUR SE DIVERTIR! DITES A VOTRE MÈRE CE QUE VOUS FAITES AVANT
DE LE FAIRE.

[p'tain d'avocats (non, ce n'est pas une coquille)... Excusez le coup de geule.]

Quand j'ai commencé a écrire ceci, je travaillais avec la version 1.8.2, qui semble être agée de plus d'un an. Comme suggéré par Arno, j'ai mis à jour vers la dernière version 1.8.3-RC3 (du 9 avril 2005) depuis. Donc, si j'ai oublié quoique ce soit en mettant à jour ceci, vous m'en verrez navré. Certains listings d'exemples ont pu être mis de côté, mais j'ai essayé de couvrir les points importants de cette ultime version.

Vous trouverez quelques commentaires de Arno sur mon article original, ci-dessous:

Merci pour cet article. Je l'apprécie beaucoup.
Puis-je vous suggerer de jetter un oeil à la dernière version stable 1.8.3RC3
(à la place de la 1.8.2a qui est agée de plus d'une année? Elle a beaucoup (je
dis bien BEAUCOUP) d'améliorations comme:

Fichiers README et de configuration formaté à 80 caractères (une de vos
tracasseries).
La présentation du fichier de configuration s'en trouvent d'ailleur bien
améliorés.
Support de la DMZ (pour protéger les réseaux WiFi).
Interfaces externes multiples (vers internet).
NAT multiroutes (pour faire de l'équilibrage de charge des connexions
internet).
Filtrage sur adresses MAC.
Support complet de proxy transparent.
Le "execute bit" n'est plus dans le fichier de configuration d'ailleur.
;-)
...et...
version 1.8.4-stable, avec encore plus d'améliorations, bientôt disponible.

Un gars sympa, cet Arno. Au début j'ai (mal fait de) corriger l'usage de "DRDOS" en "DDoS" (ou "Distributed Denial of Service" ("Deni de Service Distribué"^xi)), et c'était une erreur. Il faut donc maintenant parler de "Distributed Reflection Denial Of Service", ("Deni de Service de Reflection Distribuée"), dont je n'avait jamais entendu parlé avant. Je suis depuis averti. Pour moi, le fait d'avoir une fichier de configuration formaté en 80 caractères et une amélioration terrible.

Grand merci à l'équipe de LG pour son aide et sa patience qui a permit d'écrire cet article, de même que pour Arno van Amersfoort pour avoir rendu cela possible.

Preface

Voici ma situation (qu'il n'est pas nécessaire d'imiter):

• Ma station personnelle (pc portable) tourne sous Debian "stable"^ix.
• La plupart de mes connexions passe par une ligne commutée vers mon FAI.
• Je me connecte vers d'autre machine localement en Ethernet (par un hub quatre port ou un câble croisé).
• Je suis pour désactiver le pare-feu quand aucune interface n'est connectée. De la même manière, je ne vois pas l'avantage d'activer le pare-feu au démarrage de la machine lorsqu'il n'y à pas d'interfaces de connectées. Je préfère que mon pare-feu démarre en même temps que pppd ou lorsque ethN est connectée, lorsqu'ils sont déconnectés, le pare-feu doit se désactiver.
• J'utilise localement quelques services qui le sont habituellement par des black hats:
  • identd: fauxidentⁱⁱⁱ procure juste ce qu'il faut d'information identd-ish pour rassurer le serveur CVS sur lequel je me connecte.
  • MaraDNS iv: un serveur DNS seulement pour du cache.
  • ssh: pour les connexions locales avec les autres machines, j'active et autorise le serveur sshd avec acceptation d'autentification.
  • e-mail: Relevé par fetchmail et envoyé par Exim.
  • chrony: un demon NTP qui se connecte sur [012].pool.ntp.org pour synchroniser l'horloge du système.

Avant, j'utilisais un ensemble de commandes "maison" pour vérrouiller simplement et sans autre forme de procès toutes tentative de connexion en "brute force". Toutes connexions que le pare-feu ne détectait pas comme en ESTABLISHED ou RELATED IP établies par moi, étaient simplement loguées et écartées.

Dans l'ensemble c'est pas compliqué a faire, mais, avec le temps, ça le devient. Comment laisser entrer la réponse du serveur NTP? J'ai battaillé avec ça pendant des mois. Sur Google, il y à beaucoup d'exemples contradictoires, (certains fonctionnant, d'autres non), ça me rendait furieux. J'étais toujours à la recherche d'une alternative. Je voulais quelque chose un peu comme se que j'avais déjà, mais en plus solide, plus sensible, plus réactif et plus malin que moi concernant le réseau.

Pendant des années, j'ai essayé d'appliquer d'autre suggestions, mais cela semblait toujours bancale. Je ne veux pas dépendre d'un clicodrome pour la configuration. Si je savais déjà tous ce qu'il est utile de savoir sur les réseaux et le TCP/IP, cela m'aiderait, mais je n'en suis pas là. D'un autre côté, je ne fais pas ce qu'il faut pour ça. Je voudrais quelque chose avec peu de d'éléments qui auraient chacun leurs dossiers, dont ont peux compter sur le fait qu'ils n'en sortent pas. Je ne veut pas que quelque chose soit en panne un beau matin parce que quelqu'un a changé une obscure librairie dont je n'ai jamais entendu parlé^vi.

Le "dimanche 9 janvier 2005 à 12h18 et 45s MST" (NdT: Mountain Standard Time - UTC-7), j'ai découvert "Arno's iptables-firewall" (AIF). Depuis lors, j'ai pris du temps pour le faire fonctionner et le tester, et je suis heureux de dire qu'il me semble avoir trouvé exactement ce que je recherchais. Le système de Arno est destiné à supporter des configurations bien plus compliquées que la mienne, et de loin (par exemple, il supporte NAT et VPN), mais il sait se mettre à la hauteur de mes besoins. Il sagit d'une interface externe (connectée à Internet) et d'une interface interne (LAN). La dernière version peut géré des interfaces externes multiples.

Installation

Ce n'est pas difficile. Selon attention portée aux détails, vous devriez faire l'installation en une demie-heure. Il faut compter une heure en prenant en compte un peu de lecture.

Allez sur la page de téléchargement, récupérez l'archive en tgz qui doit peser 54ko environs. Déplacez-vous dans un répertoire sûr, créez-y un dossier, placez y l'archive et décompressez-la:

 cd mkdir ~/dwn cd ~/dwn tar xzf
/chemin/vers/arno-iptables-firewall-1.8.3-rc3.tgz 

Ceci créer un répertoire ~/dwn/arno-iptables-firewall-1.8.3-RC3:

total 276
drwxrwxr-x    2 keeling  keeling      4096 Apr  9 06:20 ./
drwxr-xr-x   27 keeling  keeling      4096 Apr 18 10:50 ../
-rw-r--r--    1 keeling  keeling     20063 Apr  9 06:20 CHANGELOG
-rwxr-xr-x    1 keeling  keeling     13580 Apr  9 06:20 fwfilter*
-rw-r--r--    1 keeling  keeling     18010 Apr  9 06:20 gpl_license.txt
-rw-rw-r--    1 keeling  keeling      1467 Apr  9 06:20 iana-reserved-nets.txt
-rw-rw-r--    1 keeling  keeling     31674 Apr  9 06:20 iptables-firewall.conf
-rw-r--r--    1 keeling  keeling     29755 Apr  9 06:20 iptables-firewall.conf.example
-rwxr-xr-x    1 keeling  keeling    112070 Apr  9 06:20 rc.iptables*
-rw-r--r--    1 keeling  keeling     16887 Apr  9 06:20 README
-rw-r--r--    1 keeling  keeling      2318 Apr  9 06:20 syslog.conf.Debian
-rw-r--r--    1 keeling  keeling      1202 Apr  9 06:20 syslog.conf.RedHat

Tous les fichiers sont en texte ASCII. Maintenant, lisons le fichier README. Il commence en précisant qu'il s'agit d'un logiciel libre, sous licence GNU/GPL. Il continue en expliquant la destination des différents fichiers. Ce que j'attendais le plus de cette nouvelle version, c'était le formatage des lignes en quatre-vingt caractères de la plupart des fichiers. En effet un fichier avec des lignes de cent caractères de long se révèle être difficiles à lire dans un terminal comme xterm (en quatre-vingt caratères par défaut) ou en console. Mais ce n'est plus un problème. On en trouve encore comme des souvenirs dans le sript du pare-feu, par exemple.

Après la descriptions des fichiers se trouve une liste "d'informations (de sécurité) IMPORTANTES". Ensuite, une section "Démarrage rapide" sur QUOI METTRE DANS LE FICHIER DE CONFIGURATION, et quelques informations qui vous servirons à reconstruire votre noyau s'il ne supporte pas iptables (:-O vraiment?!? je n'ai jamais vu de distribution avec un noyau pré-compilé qui ne supporte pas iptables, ou alors si vous procédez avec votre propre noyau... Il faudra que je relise ça un petit peu).

L'ancienne version refuse simplement de fonctionner si vous utilisez un noyau 2.2.x et ipchains. La dernière version detecte un noyau 2.2.x et ipchains et elle n'en tient pas compte (je ne l'ai jamais testé).

D'habitude, le fichier README donne les instructions d'installation que vous êtes cencé suivre , mais peut-être sont-elles noyées dans un autre chapitre. J'ai noté qu'il y en a aussi au début du script lui-même. Je vous invite a faire selon votre bon sens, donc au mieux pour votre système. C'est juste un ensemble de scripts et de fichiers de configuration. Comment cela peut-il être difficile? :-)

D'un autre côté...

Ce que je fais - Configuration

En tant que root:

$ cp rc.iptables /etc/init.d
$ vi /etc/init.d/rc.iptables

Quelques nouvelles lignes dans le fichier, vous allez voir CONFIG_FILE. Changer cela comme ceci:

CONFIG_FILE=/etc/firewall/iptables-firewall.conf

Puis rendez-le exécutable (Arno suggère de le faire en 700, c'est à vous de voir):

$ chmod 744 /etc/init.d/rc.iptables

Si nécessaire:

$ chown root:root /etc/init.d/rc.iptables

On créer un dossier pour le ou les fichiers de configuration:

$ mkdir /etc/firewall
$ chmod 755 /etc/firewall
$ cp iptables-firewall.conf /etc/firewall
$ chmod 600/etc/firewall/iptables-firewall.conf
$ vi /etc/firewall/iptables-firewall.conf

Selon vos besoins, vous pouvez maintenant créer iptables-blocked-hosts, iptables-custom-rules et iptables-mac-addresses (assurez-vous seulement qu'ils soient bien mentionnés au bas du fichier de configuration). J'ai remarqué que dans le fichier de configuration de la dernière version ceci est commenté. Il leur faut au minimum une ligne vide, alors éditez-les avec Vi, puis faite un retour chariot, sauvegardez et sortez.

Retournons au début du fichier iptables-firewall.conf, pour y mettre quelque chose d'important qui va dire a AIF comment il devra faire les choses pour votre système. Vous devriez consulter les archives de la liste de diffusion pour voir s'il y à des explications sur la manière de faire cela correctement, parce que c'est une partie un peu difficile. La FAQ renseigne sur certaines syntaxes qu'il vaut mienx connaitre. Je vais dans le sens des suggestions d'Arno avec le moins de changements possible. Il y à beaucoup de commentaires sur quelle chose fait quoi et quand vous pourriez vouloir les utiliser.

D'accord, c'est un peu vague. Désolé, mais ce passage est le coeur de ce que vous devez apprendre sur iptables pour que AIF fonctionne comme vous l'avez décidé. Que voulez-vous faire, et qu'avez-vous qui doit fonctionner avec quoi? DSL/ADSL? Connexion en ppp? WiFi depuis un modem routeur? Quel port doit rester ouvert aux crackers? Savez-vous ce que vous faite avec iptables, ou êtes-vous un amateur comme moi?

Vous allez lui dire qu'elle est votre interface externe:

EXT_IF="ppp+" 

INT_IF="eth0" 

je m'occupe de ma carte réseau avec ceci:

INTERNAL_NET="192.168.1.0/24" 

Une chose mentionnée dans la FAQ est que "127.0.0.1" (l'interface loopback) ne doit pas être mentionnée nulle part. "Ah, donc j'imagine que je n'ai rien a faire pour le cache du serveur de noms? Hein..." Eh bien, le Man de MaraDNS a quelque paragraphes là-dessus dans ses pages. Plus tard.

De même, vous trouverez ma commande chmod cité plus haut un peu sèche. Je ne trouve pas d'interêt à tous vérouiller, donc les groupes et les autres ne peuvent pas le lire. C'est ce que suggère Arno. Vous l'arrangez comme bon vous semble. Pour moi, si un fichier de configuration ne contient pas d'informations sensibles, c'est un peu stupide de mettre owner:group en lecture seule.

Ce que je fais - Mise en oeuvre

Une fois le problème du fichier de configuration réglé, pouvez avoir besoin de comprendre comment AIF sera démarré. Si vous voulez qu'il le soit au démarrage de la machine, vous devrez ajouter un lien dans un script du dossier /etc/rcN.d . Arno décrit comment le faire au début du script du pare-feu. Cela peut-être fait à la main, mais beaucoup de distributions possèdes des sortes d'outils qui s'occupent de ces liens.

Pour ma part, je veux qu'il soit contrôler par l'initialisation de l'interface, ce qui va bien avec le système /etc/ppp/ip-up.d/ de Debian. Chaque script de ce répertoire sera exécuté lorsque que l'interface est activée et mise en ligne. Il y à aussi /etc/ppp/ip-down.d/ qui fonctionne en sens inverse.

Maintenant, regardons dans /etc/network. Comme pour ppp, on y trouve aussi (parmis d'autres) un dossier if-up.d "-ish".

J'ai créé un script /etc/ppp/ip-up.d/00iptables_firewall. Il a besoin de deux lignes seulement: le "shebang", et une ligne d'appel à rc.iptables:

#!/bin/sh /etc/init.d/rc.iptables start 

Un chmod 744 /etc/ppp/ip-up.d/00iptables_firewall". De même, il faut un script dans /etc/ppp/ip-down.d qui désactivera le pare-feu lorsque l'interface sera désactivée:

#!/bin/sh
# if [ ! "$(/sbin/ifconfig | /bin/grep eth0)" ]; then
/etc/init.d/rc.iptables stop
# fi

Notez que deux lignes sont commentées. Au début je faisais des contrôles de bonne santé d'abord: si, par chance, les interfaces ppp0 et ethn étaient actives et connectées en même temps, se serait un peu bête de désactiver le pare-feu si une seule interface était désactivée. Mais maintenant que j'y repense, c'est peut-être inutile, Je réflechis encore là-dessus.

Vérifiez que ce fichier aussi soit exécutable.

Une des dernières choses qu'il vous faudra faire, sera de travailler sur /etc/syslog.conf pour dire à syslogd d'envoyer les messages du pare-feu vers /var/log/firewall. Dans la dernière version, c'est en option. Arno a été assez gentil pour mettre des exemples de syslog.conf sur lequels vous pouvez vous baser. J'ai juste fais ceci: chercher le premier terme de "kern.*" et le modifier en "kern.!=debug", puis ajouter une ligne qui fait correspondre kern.=debug à /var/log/firewall. J'obtient:

auth,authpriv.*                 /var/log/auth.log *.*;auth,authpriv.none
-/var/log/syslog #cron.*                         /var/log/cron.log daemon.*
-/var/log/daemon.log kern.!=debug                    -/var/log/kern.log lpr.*
-/var/log/lpr.log mail.*                          -/var/log/mail.log user.*
-/var/log/user.log uucp.*                          /var/log/uucp.log

   # logging for iptables
   kern.=debug                     -/var/log/firewall 

Une fois /etc/syslog.conf modifié, vous devez créer un fichier de log (seulement s'il n'existe pas déjà):

$ touch /var/log/firewall 

Il faut recharger syslogd pour lui faire re-lire son fichier de configuration:

$ kill -hup $(pidof syslogd) 

Si vous n'avez pas "pidof", vous devez trouver le pid de syslogd et le mettre ici. "ps fax | grep syslogd" donne ceci:

(0) keeling /home/keeling_ ps fax | grep syslogd
  242 ?        s      0:00 /sbin/syslogd
30307 pts/2    s      0:00          |       \_ grep syslogd

vous devez mettre "kill -hup 242"

Si vous avez terminé avec le train train du syslog.conf assurez-vous que "firewall_log=/var/log/firewall" et "loglevel=debug" sont bien présents dans le fichier /etc/firewall/iptables-firewall.conf. Heuresement que nous avons logrotate sur notre système, sinon le ficher grossirai sans fin et remplirai notre système de fichiers.

Voici "/etc/logrotate.d/firewall":

/var/log/firewall { rotate 7 daily compress notifempty
create 0640 root adm delaycompress create }

Nous voilà prêt, je vous conseille, pour les quelques premières fois, d'exécuter /etc/init.d/rc.iptables manuellement ("chmod 644 /etc/ppp/ip-up.d/00iptables_firewall" d'abord, d'activer la connexion, puis de lancer "/etc/init.d/rc.iptables start"). Il renvoie quelques messages décrivant ce qu'il fait, en les lisant vous pourrez savoir ce qui ce passe (voir l'exemple ci-dessous) et si c'est ce que vous attendiez. C'est aussi l'occasion de savoir s'il y à des erreurs dans le fichiers de configuration. "iptables -nl | less" montre les règles du pare-feu. "tail -f /var/log/firewall" montre les effets des ces règles.

Si vous pensez qu'en utilisant AIF ça ne change rien a ce que vous faisiez avant, Arno y à pensé a rendu quelques exceptions possibles. Prenez vos règles iptables que vous utilisiez avant te mettez les dans iptables- custom-rules. Bien sûr, soyer prudent car cela pourrait compromettre ce que AIF tente de faire pour vous en bien. Cependant, si vous le faisiez auparavant, vous n'êtes probablement pas plus mal lotis maintenant que vous ne l'étiez.

lorsque j'utilise une ancienne version, j'ai ceci dans mon /etc/firewall/iptables-custom-rules pour que chrony/ntp fonctionne.

# le man iptables dit que faire resoudre les noms par un dns distant est une trés
# mauvaise idée. soupir.
# 
iptables -t filter -i input -s 0.pool.ntp.org -m tcp -p tcp --dport 123 -j accept
iptables -t filter -i input -s 1.pool.ntp.org -m tcp -p tcp --dport 123 -j accept
iptables -t filter -i input -s 2.pool.ntp.org -m tcp -p tcp --dport 123 -j accept

Cependant, avec la nouvelle version, j'ai commenté ça et mis "host_open_tcp" à la place dans le fichier de configuration:

host_open_tcp="0.pool.ntp.org>123 1.pool.ntp.org>123 2.pool.ntp.org>123"

AIF En Action

Regardons ce qu'il fait. Voici un exemple d'une sortie standart de rc.iptables:

Arno's IPTABLES Firewall Script v1.8.3-RC3
   ---------------------------------------------------------------
   Sanity checks passed...OK
   Detected IPTABLES module... Loading additional IPTABLES modules:
   All IPTABLES modules loaded!
   Setting default secure policies.
   
   External (internet) interface(s) (EXT_IF)   : ppp+
   ---------------------------------------------------------------
   Configuring /proc/.... settings
   Enabling anti-spoof with rp_filter.
   Disabling the logging of martians.
   Disabling the acception of ICMP-redirect messages.
   Setting the max. amount of simultaneous connections to 4096 (default).
   Enabling reduction of the DoS'ing ability.
   Disabling ECN (Explicit Congestion Notification).
   Using loglevel debug for syslogd.
   Flushing rules in the filter table.

   Setting up firewall rules
   -------------------------
   Accepting packets from the local loopback device.
   Enabling setting the maximum packet size via MSS.
   Enabling mangling TOS.
   Logging of INVALID packets enabled.
   Reading custom IPTABLES rules from /etc/firewall/iptables-custom-rules
   Logging of ICMP flooding enabled.
   Setting up INPUT policy for internal interface(s) eth0
   Logging of stealth scans (nmap probes etc.) enabled.
   Logging of packets with bad TCP-flags enabled.
   Logging of fragmented packets enabled.
   Logging of access from reserved addresses enabled.
   Setting up anti-spoof rules.
   Logging of DHCP broadcasts disabled.
   Logging of probable "lost connections" disabled.
   Logging of explicitly blocked hosts enabled.
   Logging of denied local output connections enabled.
   Logging of denied LAN (forward) output connections enabled.
   Packets will NOT be checked for private source addresses.
   Denying the whole world to send ICMP-requests(ping).
   Logging of dropped ICMP-request(ping) packets enabled.
   Logging of dropped other ICMP packets enabled.
   Logging of possible stealth scans enabled.
   Logging of (other) connection attempts to PRIVILEGED TCP ports enabled.
   Logging of (other) connection attempts to PRIVILEGED UDP ports enabled.
   Logging of (other) connection attempts to UNPRIVILEGED TCP ports enabled.
   Logging of (other) connection attempts to UNPRIVILEGED UDP ports enabled.
   Logging of other IP protocols (non TCP/UDP/ICMP) connection attempts enabled.
   Setting up FORWARD policy for internal interface(s) eth0:
    Allowing all TCP ports
    Allowing all UDP ports
    Allowing all IP protocols
   Security is ENFORCED for the external interface(s) in the FORWARD chain.
   (Re)loading list of BLOCKED hosts (blackhole) from /etc/firewall/iptables-blocked-hosts

   Apr 18 14:47:12 All firewall rules applied.

Wahoo! vous devriez voir la sortie de "iptables -nl"! Il y à des choses dont j'ai entendu parler mais que vaguement. Jettez un coup d'oeil dans le script rc.iptables lui même pour voir tout ce qu'il fait, d'abord le "contrôles de bonne santé", puis il active (modprobes) tous les modules nécessaires, (de nouveau, dont j'ai entendu parler mais que vaguement). Arno fait tous en choses pas claires:

echo ${some_integer} > /proc/sys/net/blah/blah

Je n'ai jamais réussi a prendre ou a trouver le temps pour approffondir mes connaissances ce ce point. Au final, cela défini les différentes règles du pare-feu.

Une des choses claire de ceci est, au lieu de un peu fade:

one of the neat things about this is, instead of the fairly bland:

Mar 16 07:24:38 localhost kernel: in=ppp0 out= mac= \
 src=xxx.xxx.xx.xx dst=xxx.xxx.xxx.xx len=48 tos=0x00 \
 prec=0x00 ttl=102 id=59091 df proto=tcp spt=3946 dpt=6348 \
 window=64240 res=0x00 syn urgp=0 

Voilà ce que je vois:

Apr  6 12:41:06 localhost kernel: connection attempt (unpriv): \
 in=ppp0 out= mac= src=xx.xxx.xxx.xxx dst=xxx.xxx.xxx.xx len=48 \
 tos=0x00 prec=0x00 ttl=109 id=28712 df proto=tcp spt=4194 dpt=15118 \
 window=65535 res=0x00 syn urgp=0 

Ce qui est trés propre. Cela dit bien ce que ça veux dire. "unpriv" veux dire que le port de destination (dpt) est supérieur à 1024 (voir /etc/services).

Autre chose interessante:

 apr 18 20:22:42 localhost kernel: possible drdos tcp attempt: \
 in=ppp0 out= mac= src=xxx.xxx.xxx.xxx dst=xxx.xxx.xxx.xx \
 len=576 tos=0x00 prec=0x00 ttl=63 id=48819 df proto=tcp spt=110 \
 dpt=4345 window=5840 res=0x00 ack urgp=0

cela vient sur pop3/tcp ("grep 110 /etc/services") qui cherche un port que je n'ai pas (4345).

Parmis tant d'autre chose que AIF apporte, Arno y à mis "fwfilter", un script shell avec lequel on peut "travailler" le contenu du fichier de journalisation. J'utilise actuellement quelque chose d'autre qui se nomme fwlogwatch^viii, mais j'ai décidé de l'essayer quand même. Dans le script, Arno donne des instructions pour s'en servir. J'ai créé un petit script dans /etc/cron.daily/fwfilter:

#! /bin/sh
   #
   #  /etc/cron.daily/fwfilter - arno's iptables-firewall activity monitoring
   #  script.
   # 

   fwfilter=/chemin/vers/fwfilter fwlog=/var/log/firewall day="$(/bin/date '+%b %e' --date=yesterday)"
   
   if [ -f "${fwfilter}" -a -f "${fwlog}" ]; then /bin/grep "${day}" ${fwlog} | ${fwfilter} fi 

Quand le système exécute ses procesus de cron journaliers, il aspire dans le fichier de journalisation du pare-feu les entrées d'hier, les fait traiter par le script fwfilter de Arno, et le résultat est envoyé par e-amil à root. Cela donne quelque chose de joli et précis. Les types d'entrées sont classées en couleurs. Le programme Mutt montre les séquence d'échapemment ANSI en couleur grace à "set allow_ansi=yes", mais vous devriez vraiment le voir dans rxvt ou xterm par exemple.

Dénouement

Je pense que c'est un succés. je n'ai rien perdu autre qu'un peu de temps. Tout ce que je pouvais faire avant, je le fais toujours maintenant. Je trouve dans les entrées des fichiers de journalisation, des évènements plus ésotériques, dont je n'étais pas au courant avant. C'est ce genre de choses qu'on attend.

J'ai même eu la chanche de pouvoir le mettre sur l'ordinateur d'un ami. Il fonctionne très bien, sans entraver les communications habituelles entre deux ordinateurs et fut facile a mettre en place. Je n'ai rien d'autre que des éloges pour AIF et de loin. C'est simplement ce que je voulais débusquer depuis longtemps.

Le système de Arno est facile à utiliser, peut sans doute s'adapter à toutes les situations, et cela même par un débutant en pare-feu. Si vous savez lire vous pouvez tirer partie du pare-feu de Arno.

Si vous l'avez essayé et antant apprécié que moi, allez voir le fichier README et faite un don à une ou plusieurs oeuvres de charités qui y sont mentionnées.

Vas-y Arno. Bravo. Merci beaucoup!

[i]    Oui, je sais exactement quand j'ai découvert AIF.
       J'ai un petit script perl qui sauvegardait, horodatait, et formatait en html
       tous mes copié/collé que je faisais pendant que je surfais sur le web. (ici).

[ii]   Mon script de mise en place de mes vieilles règles
       "maison" est ici.

[iii]  L'URL officiel pour fauxident est:
       http://www.alcyone.com/software/fauxident/
       son auteur est Erik Max Francis http://www.alcyone.com/max/

[iv]   MaraDNS est de Sam Trenholme http://www.samiam.org

[v]    Le pare-feu iptables de Arno: http://rocky.molphys.leidenuniv.nl/
       sur Freshmeat: http://freshmeat.net/projects/iptables-firewall/?topic_id=151
       La liste de distribution de Arno: 
       https://lists.btito.net/mailman/listinfo/firewall

[vi]   Cela m'est arrivé avec XCDRoast. Tout-à-coup, je n'ai plus
       pu faire de sauvegardes. C'et pourquoi je fais mes archives avec afio, avec
       mkisofs je les met en images ISO et avec cdrecord pour les graver sur un CD.

[viii] fwlogwatch est de Boris Wesslowski , rus-cert http://cert.uni-stuttgart.de

[ix]    Debian "stable", du moment (woody), avec un noyau version 2.2.x.
        iptables requiert la version 2.4 ou plus, et l'ancienne version du
        pare-feu de Arno aussi. D'ailleur la dernière version semble l'assumer.

[x]     AIF pense en terme d'interface externe (internet) et interface interne 
        (votre lan). AIF ne s'occupe que de l'externe. Pour l'interface interne, il ne fait que de
        s'assurer que tout y passe. Donc, tester si eth0 est connectée avant avant de désactiver
        le pare-feu est une belle erreur. J'ai depuis désactiver ce test de vérification.

[xi]    Bien sûr, tout le monde sait que "dr-dos" veut dire 
        "digital research disk operating system" (de Gary Kildall), n'est-ce pas?

En 1990, après près d'un décénie de travux avec des données sismiques (comme opérateur au début, puis comme technicien en géophysique), je me suis mis sur les genoux pour mon premier ordinateur personnel et j'ai commencer à apprendre à programmer en C tout seul. Après deux mois, j'ai trouver cela motivant pour une belle carrière en perspective, j'ai donc pris des cours de programmation. Je suis diplomé dans la moyenne.