Suite de mes histoires de Freebox

Le Fri, 29 Dec 2006 15:48:55 +0100, Fabien LE LEZ a écrit :

On Fri, 29 Dec 2006 14:57:54 +0100, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org>:

1) Le filtrage iptables par la machine Linux. La Freebox en mode routeur
NAT, on ne sait pas trop ce qu'elle filtre.

Yep, mais avec la solution de "sansflotusspam", le PC Windows est
physiquement branché sur la freebox. Donc, soit on fait confiance à la
freebox et on n'a pas besoin d'un truc aussi compliqué, soit on ne lui
fait pas confiance et la solution est mauvaise.

Si on veut utiliser une machine Linux pour filtrer et protéger une
machine Windows, il faut AMHA que la passerelle Linux ait deux cartes
réseau, et que les deux sous-réseaux soient physiquement séparés.

C'est bien ce que sansflotusspam suppose : deux cartes réseau sur la
station Linux. C'est, je pense, ce que je vais faire. Mais je vais faire
plus simple que ce qu'il propose en termes de firewall : j'ai trouvé sur
http://www.glatozen.org/freebox.php un script simple qui semble faire ce
que je veux, j'affinerai après, je veux juste mettre mon préservatif
tout de suite ;-)

J'ai vu sur http://www.zebulon.fr/outils/scanports/ que j'avais pas mal de
ports détectables avant cela, maintenant, au moins, ils sont fermés ou
indétectables !

Merci pour tous vos conseils, je vais réfléchir à tout cela.

bye

--

Nicolas FRANCOIS
http://nicolas.francois.free.fr
A TRUE Klingon programmer does NOT comment his code

Pascal Hambourg wrote:

Salut,

Je ne vois pas bien ce que ta solution apporte par rapport à une
config classique (tout en 192.168.0.x, et la freebox en routeur).

1) Le filtrage iptables par la machine Linux. La Freebox en mode routeur
NAT, on ne sait pas trop ce qu'elle filtre.

2) La machine Linux a l'adresse IP publique de la connexion et une
connectivité complète sans NAT.

pour moi solution plus lourde :
un vieux PC (200M) en firewall avec SENTRY dedans avec 2 cartes réseau :
- une sur la Freebox (IP Free)
- l'autre à un hub comme tous les PC

Tout en IP statique (il n'y a que peu de PC branchés)

Pour le réseau les PC sont en 192.168.10.x (routeur compris).
avec comme passerelle l'IP du routeur et les DNS de Free.
Le PC windows dispose de son prpore anti-virus (AVG).

Comme le firewall n'a qu'un CD et une disquette de config, il est mis en
route et éteint suivant les besoins par l'inter M/A.

Quand on veut ajouter un PC pour avoir internet :
- IP libre sur l'interface réseau
- en passerelle l'adresse du routeur
- les DNS de FREE qui vont bien
- et c'est tout.

Cerise sur le gateau : une HP ljIV sur le réseau accessible par tout le
monde via le hub.

Aucun problème.
C Hiebel

la freebox sur la linuxbox en ethernet, eth0 et 192.168.0.1 (static, pas
dhcp, dans ifcfg-eth0),

Pourquoi pas en DHCP ?

en câble droit, gateway 192.168.0.250 (= la gateway
de la freebox, à régler sur le site de free, compte perso)

Pourquoi mettre la Freebox en mode routeur et introduire un étage de NAT
supplémentaire (et inutile AMA) au lieu de donner l'adresse publique à
la machine Linux ?

une carte ethernet (ou le circuit ethernet de la carte mère, généralement un
realtek ou un via-rhine) en eth1 192.168.10.1, un câble droit sur le hub,

la win$box sur le hub en 192.168.10.2, câble ethernet droit.

les deux segments de réseau (192.168.0.0 et 192.168.10.0) , c'est exprès
pour faire faire le routage et les filtres iptables/netfilter par la
linuxbox.

activer les règles suivantes (au minimum) sur la linuxbox :

#!/bin/sh
# Le script commence par effacer les règles de filtrage actuelles
/sbin/iptables -F
/sbin/iptables -t nat -F

# Effacement des chaines existantes
/sbin/iptables -X

Je ne vois pas la définition des politiques par défaut des chaînes.

# on charge les modules NAT
modprobe iptable_nat
modprobe ip_nat_irc
modprobe iptable_filter
modprobe ip_nat_ftp
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ipt_state
modprobe iptable_mangle

Pourquoi précharger des modules comme iptable_nat ou ip_conntrack qui
sont automatiquement chargés par les modules de suivi de connexion et de
NAT et les règles iptables qui en ont besoin ?

modprobe iptables_conntrack_rtsp

Il me semble que c'est plutôt "ip_conntrack_rtsp". Pourquoi ne pas aussi
charger son alter ego iptables_nat_rtsp ? D'autre part, il faut noter
que ces modules ne sont disponibles que si le le patch rtsp-conntrack,
qui n'est pas encore inclus dans les source du noyau standard à ma
connaissance, a été appliqué au noyau.

# on active l'IP-forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# on accepte les paquets relatifs aux connexions déjà ouvertes
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Il manque la même dans la chaîne FORWARD.

# on accepte tout ce qui se passe sur lo
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

# on accepte tout ce qui se passe sur le reseau local 192.168.10.0
/sbin/iptables -A INPUT -s 192.168.10.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -s 192.168.10.0/24 -j ACCEPT
/sbin/iptables -A FORWARD -s 192.168.10.0/24 -j ACCEPT

Ce n'est pas suffisant de se baser uniquement sur l'adresse source : il
faut aussi prendre en compte l'interface d'entrée et/ou de sortie pour
éviter les cas d'usurpation d'adresse IP. Ces règles acceptent un paquet
qui arrive de l'extérieur par eth0 avec une une adresse IP source dans
la plage du LAN. Le LAN, c'est 192.168.10.0/24 *sur eth1*. A la limite,
j'ai tendance à penser que l'interface est plus importante que l'adresse.

# dans la table NAT (-t nat), on ajoute une règle (-A) pour masquer le
POSTROUTING
/sbin/iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -j MASQUERADE

J'ajouterais "-i eth0" à cette règle pour ne prendre en compte que les
paquets établissant une connexion vers l'extérieur. Inutile de masquer
les communications de la machine vers le LAN.

# éventuellement, on autorise les requêtes dhcp
#/sbin/iptables -A INPUT -i eth1 -p udp --sport bootpc --dport bootps -j
ACCEPT

A condition que la machine Linux fasse tourner un serveur DHCP sur son
interface LAN.

#/sbin/iptables -A INPUT -i eth1 -p tcp --sport bootpc --dport bootps -j
ACCEPT

Euh, du DHCP en TCP ?

#/sbin/iptables -A INPUT -i eth1 -p udp --sport bootps --dport bootpc -j
ACCEPT

Pour quoi faire ? Recevoir des réponses d'un serveur DHCP supposerait
que la machine émette des requêtes DHCP sur son interface LAN.

#/sbin/iptables -A INPUT -i eth1 -p tcp --sport bootps --dport bootpc -j
ACCEPT

Euh, du DHCP en TCP (bis) ?

# on autorise les requêtes dns venat de 192.168.10.0
/sbin/iptables -A INPUT -i eth1 -p udp --dport domain -j ACCEPT
/sbin/iptables -A INPUT -i eth1 -p tcp --dport domain -j ACCEPT

Utile seulement si la machine fait tourner un serveur DNS genre bind ou
un relais DNS genre dsnmasq. Mais inutile en fait puisqu'une règle
précédente a déjà accepté les paquets provenant du LAN.

# On DNAT la freebox
/sbin/iptables -t nat -A PREROUTING -i eth0 -s 192.168.0.0/24 -d
212.27.38.253 -j DNAT -d 192.168.0.250

Pourquoi DNATer l'adresse IP Freeplayer en entrée sur l'interface WAN ?
Je ne vois pas comment un paquet valide pourrait déclencher cette règle.

# On autorise udp sur les ports utilisés par freeplayer
/sbin/iptables -A INPUT -p udp -m udp -s 192.168.0.250 --dport 32000:34000
-j ACCEPT

Le module de suivi de connexion RTSP chargé plus haut n'est pas censé
s'occuper de ça automatiquement ?

# On ouvre le port 8080 et le 1234
/sbin/iptables -A INPUT -p tcp -s 192.168.0.1 --dport 8080 -j ACCEPT
/sbin/iptables -A INPUT -o udp -s 192.168.0.1 --dport 8080 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 192.168.0.1 --dport 1234 - ACCEPT
/sbin/iptables -A INPUT -o udp -s 192.168.0.1 --dport 1234 -j ACCEPT

Indépendamment du fait que je n'ai pas la moindre idée des services
associés à ces règles, j'avoue que je ne comprends pas pourquoi accepter
en entrée des paquets dont l'adresse IP source appartient à la machine
elle-même. De tels paquets ne peuvent être valides que s'ils passent par
l'interface de loopback, et des règles plus génériques pour les accepter
sont déjà en place.

# ... ainsi que les réponses
/sbin/iptables -A OUTPUT -p tcp -d 192.168.0.1 --sport 8080 -j ACCEPT
/sbin/iptables -A OUTPUT -p udp -d 192.168.0.1 --sport 8080 -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp -d 192.168.0.1 --sport 1234 -j ACCEPT
/sbin/iptables -A OUTPUT -p udp -d 192.168.0.1 --sport 1234 -j ACCEPT

Inutile voire nuisible. Les réponses sont normalement déjà prises en
charge par des règles ESTABLISHED, et se baser sur le seul port source
pour déterminer qu'un paquet est une réponse est une erreur.

# On ouvre le port 631 pour cups sur le réseau local 192.168.10.0
/sbin/iptables -A INPUT -p tcp -s 192.168.10.0/24 --dport 631 -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp -d 192.168.0.0/24 --sport 631 -j ACCEPT
^^^

Typo probable. Et je réitère mes remarques sur la nécessité de prendre
en compte l'état de suivi de connexion pour reconnaître les paquets de
réponse et la nécessité de spécifier l'interface d'entrée et/ou de
sortie en plus de l'adresse source et/ou destination.

# ON REFUSE TOUT CE QUI VIENDRAIT D'UN LAN PRIVE EN PROVENANCE D'INTERNET
/sbin/iptables -A FORWARD -s 10.0.0.0/8 -i eth0 -j REJECT
/sbin/iptables -A INPUT -s 10.0.0.0/8 -i eth0 -j REJECT
/sbin/iptables -A FORWARD -s 172.16.0.0/12 -i eth0 -j REJECT
/sbin/iptables -A INPUT -s 172.16.0.0/12 -i eth0 -j REJECT
/sbin/iptables -A FORWARD -s 192.168.0.0/16 -i eth0 -j REJECT
/sbin/iptables -A INPUT -s 192.168.0.0/16 -i eth0 -j REJECT

Trop tard en ce qui concerne 192.168.10.0/24, des règles précédentes
l'ont déjà accepté sans vérifier l'interface. ;-)
Et si je ne m'abuse, le réseau entre interfae WAN et Freebox est aussi
en adressage privé, donc ça va bloquer les communications de la machine
vers l'extérieur.
Accessoirement, DROP est préférable à REJECT pour le traitement des
adresses sources invalides. Il ne sert à rien d'envoyer un message
d'erreur ICMP dans ce cas, bien au contraire. C'est comme les bounces en
SMTP en cas d'usurpation de l'adresse d'expéditeur.

# ON REFUSE TOUT CE QUI IRAIT VERS UN LAN PRIVE EN DIRECTION D'INTERNET
/sbin/iptables -A FORWARD -d 10.0.0.0/8 -o eth0 -j DROP
/sbin/iptables -A FORWARD -d 172.16.0.0/12 -o eth0 -j DROP
/sbin/iptables -A FORWARD -d 192.168.10.0/16 -o eth0 -j DROP

Mêmes remarques que précédemment, sauf pour la cible : REJECT est ici
préférable à DROP pour signaler à la source présumée valide que la
destination est injoignable.

[...]

au passage, toutes remarques, observations, suggestions, des contributeurs
du forum sont acceptées avec plaisir.

Serviteur. :-)

Pascal Hambourg wrote:

la freebox sur la linuxbox en ethernet, eth0 et 192.168.0.1 (static, pas
dhcp, dans ifcfg-eth0),

Pourquoi pas en DHCP ?

en câble droit, gateway 192.168.0.250 (= la gateway
de la freebox, à régler sur le site de free, compte perso)

Pourquoi mettre la Freebox en mode routeur et introduire un étage de NAT
supplémentaire (et inutile AMA) au lieu de donner l'adresse publique à
la machine Linux ?

une carte ethernet (ou le circuit ethernet de la carte mère, généralement
un realtek ou un via-rhine) en eth1 192.168.10.1, un câble droit sur le
hub,

la win$box sur le hub en 192.168.10.2, câble ethernet droit.

les deux segments de réseau (192.168.0.0 et 192.168.10.0) , c'est exprès
pour faire faire le routage et les filtres iptables/netfilter par la
linuxbox.

activer les règles suivantes (au minimum) sur la linuxbox :

#!/bin/sh
# Le script commence par effacer les règles de filtrage actuelles
/sbin/iptables -F
/sbin/iptables -t nat -F

# Effacement des chaines existantes
/sbin/iptables -X

Je ne vois pas la définition des politiques par défaut des chaînes.

exact :
# Debut des regles de filtrages
# Mise en place des politiques par defaut
/sbin/iptables -P INPUT DROP
/sbin/iptables -P OUTPUT DROP
/sbin/iptables -P FORWARD DROP

# on charge les modules NAT
modprobe iptable_nat
modprobe ip_nat_irc
modprobe iptable_filter
modprobe ip_nat_ftp
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ipt_state
modprobe iptable_mangle

Pourquoi précharger des modules comme iptable_nat ou ip_conntrack qui
sont automatiquement chargés par les modules de suivi de connexion et de
NAT et les règles iptables qui en ont besoin ?

automatiquement, non, pas forcément, ça dépend des ditribs (j'en ai de très
vieilles sur certaines machines) et de pas mal de paramètres.
comme je recopie le truc d'une install à l'autre, je mets tout au départ et
je commente # "selon affinités".

modprobe iptables_conntrack_rtsp

Il me semble que c'est plutôt "ip_conntrack_rtsp". Pourquoi ne pas aussi
charger son alter ego iptables_nat_rtsp ?

parce que j'ai celui là, et pas l'autre

D'autre part, il faut noter
que ces modules ne sont disponibles que si le le patch rtsp-conntrack,
qui n'est pas encore inclus dans les source du noyau standard à ma
connaissance, a été appliqué au noyau.

ah ? je n'ai rien patché, et pourtant il se charge

# on active l'IP-forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# on accepte les paquets relatifs aux connexions déjà ouvertes
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Il manque la même dans la chaîne FORWARD.

exact, oublié au copié/collé

# on accepte tout ce qui se passe sur lo
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

# on accepte tout ce qui se passe sur le reseau local 192.168.10.0
/sbin/iptables -A INPUT -s 192.168.10.0/24 -j ACCEPT
/sbin/iptables -A OUTPUT -s 192.168.10.0/24 -j ACCEPT
/sbin/iptables -A FORWARD -s 192.168.10.0/24 -j ACCEPT

Ce n'est pas suffisant de se baser uniquement sur l'adresse source : il
faut aussi prendre en compte l'interface d'entrée et/ou de sortie pour
éviter les cas d'usurpation d'adresse IP. Ces règles acceptent un paquet
qui arrive de l'extérieur par eth0 avec une une adresse IP source dans
la plage du LAN. Le LAN, c'est 192.168.10.0/24 *sur eth1*. A la limite,
j'ai tendance à penser que l'interface est plus importante que l'adresse.

ok, compris, j'applique

# dans la table NAT (-t nat), on ajoute une règle (-A) pour masquer le
POSTROUTING
/sbin/iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -j MASQUERADE

J'ajouterais "-i eth0" à cette règle pour ne prendre en compte que les
paquets établissant une connexion vers l'extérieur. Inutile de masquer
les communications de la machine vers le LAN.

ok

# éventuellement, on autorise les requêtes dhcp
#/sbin/iptables -A INPUT -i eth1 -p udp --sport bootpc --dport bootps -j
ACCEPT

A condition que la machine Linux fasse tourner un serveur DHCP sur son
interface LAN.

oui, il y en a un sur une babasse, pour tests.

#/sbin/iptables -A INPUT -i eth1 -p tcp --sport bootpc --dport bootps -j
ACCEPT

Euh, du DHCP en TCP ?

je sais, c'est très bizarre, mais si je commente # cette règle, le portable
sous XP de ma femme ne va que sur Google et nulle part ailleurs.

#/sbin/iptables -A INPUT -i eth1 -p udp --sport bootps --dport bootpc -j
ACCEPT

Pour quoi faire ? Recevoir des réponses d'un serveur DHCP supposerait
que la machine émette des requêtes DHCP sur son interface LAN.

oui, voir plus haut

#/sbin/iptables -A INPUT -i eth1 -p tcp --sport bootps --dport bootpc -j
ACCEPT

Euh, du DHCP en TCP (bis) ?

# on autorise les requêtes dns venat de 192.168.10.0
/sbin/iptables -A INPUT -i eth1 -p udp --dport domain -j ACCEPT
/sbin/iptables -A INPUT -i eth1 -p tcp --dport domain -j ACCEPT

Utile seulement si la machine fait tourner un serveur DNS genre bind ou
un relais DNS genre dsnmasq. Mais inutile en fait puisqu'une règle
précédente a déjà accepté les paquets provenant du LAN.

# On DNAT la freebox
/sbin/iptables -t nat -A PREROUTING -i eth0 -s 192.168.0.0/24 -d
212.27.38.253 -j DNAT -d 192.168.0.250

Pourquoi DNATer l'adresse IP Freeplayer en entrée sur l'interface WAN ?
Je ne vois pas comment un paquet valide pourrait déclencher cette règle.

si on # cette règle, freeplayer ne diffuse plus sur le lan ; j'ignore
totalement comment et pourquoi ; est-ce dû aux autres règles fautives ?

# On autorise udp sur les ports utilisés par freeplayer
/sbin/iptables -A INPUT -p udp -m udp -s 192.168.0.250 --dport
32000:34000 -j ACCEPT

Le module de suivi de connexion RTSP chargé plus haut n'est pas censé
s'occuper de ça automatiquement ?

censé, peut'être, mais sans ça, pas de diffusion freeplayer

# On ouvre le port 8080 et le 1234
/sbin/iptables -A INPUT -p tcp -s 192.168.0.1 --dport 8080 -j ACCEPT
/sbin/iptables -A INPUT -o udp -s 192.168.0.1 --dport 8080 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -s 192.168.0.1 --dport 1234 - ACCEPT
/sbin/iptables -A INPUT -o udp -s 192.168.0.1 --dport 1234 -j ACCEPT

Indépendamment du fait que je n'ai pas la moindre idée des services
associés à ces règles, j'avoue que je ne comprends pas pourquoi accepter
en entrée des paquets dont l'adresse IP source appartient à la machine
elle-même. De tels paquets ne peuvent être valides que s'ils passent par
l'interface de loopback, et des règles plus génériques pour les accepter
sont déjà en place.

ok, on teste

# ... ainsi que les réponses
/sbin/iptables -A OUTPUT -p tcp -d 192.168.0.1 --sport 8080 -j ACCEPT
/sbin/iptables -A OUTPUT -p udp -d 192.168.0.1 --sport 8080 -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp -d 192.168.0.1 --sport 1234 -j ACCEPT
/sbin/iptables -A OUTPUT -p udp -d 192.168.0.1 --sport 1234 -j ACCEPT

Inutile voire nuisible. Les réponses sont normalement déjà prises en
charge par des règles ESTABLISHED, et se baser sur le seul port source
pour déterminer qu'un paquet est une réponse est une erreur.

ok

# On ouvre le port 631 pour cups sur le réseau local 192.168.10.0
/sbin/iptables -A INPUT -p tcp -s 192.168.10.0/24 --dport 631 -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp -d 192.168.0.0/24 --sport 631 -j ACCEPT
^^^

Typo probable. Et je réitère mes remarques sur la nécessité de prendre
en compte l'état de suivi de connexion pour reconnaître les paquets de
réponse et la nécessité de spécifier l'interface d'entrée et/ou de
sortie en plus de l'adresse source et/ou destination.

ok

# ON REFUSE TOUT CE QUI VIENDRAIT D'UN LAN PRIVE EN PROVENANCE D'INTERNET
/sbin/iptables -A FORWARD -s 10.0.0.0/8 -i eth0 -j REJECT
/sbin/iptables -A INPUT -s 10.0.0.0/8 -i eth0 -j REJECT
/sbin/iptables -A FORWARD -s 172.16.0.0/12 -i eth0 -j REJECT
/sbin/iptables -A INPUT -s 172.16.0.0/12 -i eth0 -j REJECT
/sbin/iptables -A FORWARD -s 192.168.0.0/16 -i eth0 -j REJECT
/sbin/iptables -A INPUT -s 192.168.0.0/16 -i eth0 -j REJECT

Trop tard en ce qui concerne 192.168.10.0/24, des règles précédentes
l'ont déjà accepté sans vérifier l'interface. ;-)
Et si je ne m'abuse, le réseau entre interfae WAN et Freebox est aussi
en adressage privé, donc ça va bloquer les communications de la machine
vers l'extérieur.
Accessoirement, DROP est préférable à REJECT pour le traitement des
adresses sources invalides. Il ne sert à rien d'envoyer un message
d'erreur ICMP dans ce cas, bien au contraire. C'est comme les bounces en
SMTP en cas d'usurpation de l'adresse d'expéditeur.

# ON REFUSE TOUT CE QUI IRAIT VERS UN LAN PRIVE EN DIRECTION D'INTERNET
/sbin/iptables -A FORWARD -d 10.0.0.0/8 -o eth0 -j DROP
/sbin/iptables -A FORWARD -d 172.16.0.0/12 -o eth0 -j DROP
/sbin/iptables -A FORWARD -d 192.168.10.0/16 -o eth0 -j DROP

Mêmes remarques que précédemment, sauf pour la cible : REJECT est ici
préférable à DROP pour signaler à la source présumée valide que la
destination est injoignable.

ok

[...]

au passage, toutes remarques, observations, suggestions, des
contributeurs du forum sont acceptées avec plaisir.

Serviteur. :-)

merci de tes excellentes remarques ; en fait, le script est une compilation
bricolée à partir de plusieurs sources et complété (au pif ....) au fur et
à mesure de diverses petites misères.
j'ai mis mes petites explications aux endroits visés.
bien sûr, j'adopte tes corrections.
A+

Pascal Hambourg wrote:

Je ne vois pas bien ce que ta solution apporte par rapport à une
config classique (tout en 192.168.0.x, et la freebox en routeur).

2) La machine Linux a l'adresse IP publique de la connexion et une
connectivité complète sans NAT.

Je retire. Apparemment la solution de sansflotusspam suppose que la
Freebox est en mode routeur, ce dont je ne vois pas l'intérêt.

freeplayer ... si la freebox n'est pas en routeur, la passerelle ne diffuse
pas sur le lan.
mais il y a peut'être quelque chose que je n'ai pas compris dans le
fonctionnement de freeplayer.

Fabien LE LEZ wrote:

On Fri, 29 Dec 2006 14:57:54 +0100, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org>:

1) Le filtrage iptables par la machine Linux. La Freebox en mode routeur
NAT, on ne sait pas trop ce qu'elle filtre.

Yep, mais avec la solution de "sansflotusspam", le PC Windows est
physiquement branché sur la freebox. Donc, soit on fait confiance à la
freebox et on n'a pas besoin d'un truc aussi compliqué, soit on ne lui
fait pas confiance et la solution est mauvaise.

ben, non, justement ; les pc du lan sont sur le hub :

freebox --> eth0 de PClinux -- eth1 de PClinux --> HUB <-- machines du lan

Si on veut utiliser une machine Linux pour filtrer et protéger une
machine Windows, il faut AMHA que la passerelle Linux ait deux cartes
réseau, et que les deux sous-réseaux soient physiquement séparés.

c'est bien ce que je fais (enfin, on essaye)