[HS] Help pour débuter avec iptables

Le
giggzounet
Bonjour,

suite à des problèmes avec la surcouche firewall apportée par
firestarter, je me décide à m'intéresser à iptables. Mais je suis un peu
perdu. Et la doc d'iptables est plus que conséquente. donc j'ai besoin
d'aide pour débuter. J'ai tenté ma chance sur la list de
netfiltermais bon pas eu de réponsealors je me tourne vers vous.

j'ai un cluster. les noeuds n'ont pas accès au net. Donc je monte un
parefeu sur le master node. Naturellement le master doit accepter tout
ce que vient des noeuds. Et j'aimerais que tout ce que vienne de
l'extérieur soit filtré à part qqs services comme ssh et http.

pour l'instant j'ai ça:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:Firewall-1-INPUT - [0:0]
-A INPUT -j Firewall-1-INPUT
-A FORWARD -j Firewall-1-INPUT
#
#
-A INPUT -j Firewall-1-INPUT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set
--name SSH --rsource -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60
--hitcount 4 --rttl --name SSH --rsource -j LOG --log-prefix
"SSH_brute_force "
-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60
--hitcount 4 --rttl --name SSH --rsource -j DROP
#
#
-A Firewall-1-INPUT -i lo -j ACCEPT
#
# begin: allowed networks
# Intern Network
-A Firewall-1-INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT
-A Firewall-1-INPUT -s 192.168.100.0/255.255.255.0 -j ACCEPT
-A Firewall-1-INPUT -s 192.168.200.0/255.255.255.0 -j ACCEPT
#
-A Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A Firewall-1-INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A Firewall-1-INPUT -p esp -j ACCEPT
-A Firewall-1-INPUT -p ah -j ACCEPT
-A Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT
-A Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
-A Firewall-1-INPUT -j LOG
-A Firewall-1-INPUT -j DROP
COMMIT



Est ce qu'on peut faire mieux ? ou alors plus simple? bref si vous avez
des idéesje suis preneur.



UNe autre question:
si je mets ces règles pour iptables. Qu'en est il pour ip6tables ? dois
je mettre les mêmes rêgles ?

Merci d'avance,
BOnne journée
Guillaume

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/i6ckvh$51v$1@dough.gmane.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
moi-meme
Le #22557651
Le Fri, 10 Sep 2010 09:00:02 +0200, giggzounet a écrit :

suite à des problèmes avec la surcouche firewall apportée par
firestarter, je me décide à m'intéresser à iptables. Mais je suis un peu
perdu. Et la doc d'iptables est plus que conséquente. donc j'ai besoin
d'aide pour débuter. J'ai tenté ma chance sur la list de
netfilter...mais bon pas eu de réponse...alors je me tourne vers vous.



c'est vieux mais ça m'a bien dépanné pour comprendre
http://olivieraj.free.fr/fr/linux/information/firewall/

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/4c8a27fd$0$23401$
Pascal Hambourg
Le #22557711
Salut,

giggzounet a écrit :

suite à des problèmes avec la surcouche firewall apportée par
firestarter, je me décide à m'intéresser à iptables.



Bravo !

J'ai tenté ma chance sur la list de
netfilter...mais bon pas eu de réponse...



J'ai vu "cluster" dans le sujet alors j'ai passé en me disant "houla,
j'y connais rien et ça doit être compliqué".

j'ai un cluster. les noeuds n'ont pas accès au net. Donc je monte un
parefeu sur le master node. Naturellement le master doit accepter tout
ce que vient des noeuds. Et j'aimerais que tout ce que vienne de
l'extérieur soit filtré à part qqs services comme ssh et http.



Le master se comporte comme un genre de load balancer ? Il fonctionne
plutôt comme un routeur, ou un reverse proxy, ou selon un autre mécanisme ?

pour l'instant j'ai ça:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:Firewall-1-INPUT - [0:0]
-A INPUT -j Firewall-1-INPUT
-A FORWARD -j Firewall-1-INPUT



C'est pas la peine de virer la surcouche si c'est pour faire pareil...

#
#
-A INPUT -j Firewall-1-INPUT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set
--name SSH --rsource -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60
--hitcount 4 --rttl --name SSH --rsource -j LOG --log-prefix
"SSH_brute_force "
-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60
--hitcount 4 --rttl --name SSH --rsource -j DROP



Mon conseil : quand on débute, commencer par des choses simples et
basiques : suivi de connexion, filtrage des flux par interface d'entrée
et/ou de sortie, protocole et port. Pour les trucs subtils à base de
"recent" (susceptible de provoquer un auto-DoS si mal maîtrisé), on
verra plus tard.

<couic le reste>
Est ce qu'on peut faire mieux ? ou alors plus simple? bref si vous avez
des idées...je suis preneur.



Ben en fait, c'est difficile à dire car je vois pas trop le rapport avec
le "cahier des charges" mentionné plus haut. Faut dire qu'il est
tellement vague...

UNe autre question:
si je mets ces règles pour iptables. Qu'en est il pour ip6tables ?



C'est indépendant. ip6tables n'est utile que si la machine a une
connectivité IPv6.

dois je mettre les mêmes rêgles ?



Tu ne pourras pas forcément : les adresses et les types ICMP sont
spécifiques à chacun des deux protocole.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
giggzounet
Le #22557801
Le 10/09/2010 15:39, Pascal Hambourg a écrit :
Salut,

giggzounet a écrit :

suite à des problèmes avec la surcouche firewall apportée par
firestarter, je me décide à m'intéresser à iptables.



Bravo !




merci. mais j'ai un de ces mal de tête maintenant!!!

J'ai tenté ma chance sur la list de
netfilter...mais bon pas eu de réponse...



J'ai vu "cluster" dans le sujet alors j'ai passé en me disant "houla,
j'y connais rien et ça doit être compliqué".

j'ai un cluster. les noeuds n'ont pas accès au net. Donc je monte un
parefeu sur le master node. Naturellement le master doit accepter tout
ce que vient des noeuds. Et j'aimerais que tout ce que vienne de
l'extérieur soit filtré à part qqs services comme ssh et http.



Le master se comporte comme un genre de load balancer ? Il fonctionne
plutôt comme un routeur, ou un reverse proxy, ou selon un autre mécanisme ?




le master se charge de distribuer les jobs sur les noeuds. C'est via le
master que tout le monde se connecte. En gros j'ai 5 interfaces:

lo locahost
eth0 interface ethernet vers les noeuds
eth0:2 interface de controle/monitoring des noeuds (ipmi)
ib0 interface infiniband vers les noeuds
eth1 interface ethernet vers l'extérieur.

En gros je voudrais qu'en interne il n'y ait aucun filtrage (donc tout
passe sur lo,ib0,eth0,eth0:2 dans tous les sens). par contre que tout en
entrée de eth1 soit bloqué sauf le port 22 (pour commencer). en sortie
sur eth1 je peux laissé ouvert.

pour l'instant j'ai ça:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:Firewall-1-INPUT - [0:0]
-A INPUT -j Firewall-1-INPUT
-A FORWARD -j Firewall-1-INPUT



C'est pas la peine de virer la surcouche si c'est pour faire pareil...

#
#
-A INPUT -j Firewall-1-INPUT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set
--name SSH --rsource -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60
--hitcount 4 --rttl --name SSH --rsource -j LOG --log-prefix
"SSH_brute_force "
-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 60
--hitcount 4 --rttl --name SSH --rsource -j DROP



Mon conseil : quand on débute, commencer par des choses simples et
basiques : suivi de connexion, filtrage des flux par interface d'entrée
et/ou de sortie, protocole et port. Pour les trucs subtils à base de
"recent" (susceptible de provoquer un auto-DoS si mal maîtrisé), on
verra plus tard.





ben pour l'instant ça a l'air de marcher. en gros si je me connecte
normal ça va. par contre si je lance un nmap par exemple il gueule.

<couic le reste>
Est ce qu'on peut faire mieux ? ou alors plus simple? bref si vous avez
des idées...je suis preneur.



Ben en fait, c'est difficile à dire car je vois pas trop le rapport avec
le "cahier des charges" mentionné plus haut. Faut dire qu'il est
tellement vague...





cf plus haut.


UNe autre question:
si je mets ces règles pour iptables. Qu'en est il pour ip6tables ?



C'est indépendant. ip6tables n'est utile que si la machine a une
connectivité IPv6.




ok. bon je suis sur le réseau interne d'une uni...alors je suppose que oui.

dois je mettre les mêmes rêgles ?



Tu ne pourras pas forcément : les adresses et les types ICMP sont
spécifiques à chacun des deux protocole.




oui ça j'ai vu. et j'ai modifié.


Merci.

pour l'instant j'ai ça; qu'en pensez vous (résultat de mon mal de tête...) ?

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:Firewall-1-INPUT - [0:0]
#
## SSH (test brute force)
-A INPUT -i eth1 -p tcp -m tcp --dport 22 -m state --state NEW -m recent
--set --name SSH --rsource -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 22 -m recent --update --seconds
60 --hitcount 4 --rttl --name SSH --rsource -j LOG --log-prefix
"SSH_brute_force "
-A INPUT -i eth1 -p tcp -m tcp --dport 22 -m recent --update --seconds
60 --hitcount 4 --rttl --name SSH --rsource -j DROP
#
# IP DROP SPOOF
-A INPUT -i eth1 -s 10.0.0.0/8 -j DROP
-A INPUT -i eth1 -s 172.16.0.0/12 -j DROP
-A INPUT -i eth1 -s 192.168.0.0/16 -j DROP
-A INPUT -i eth1 -s 240.0.0.0/5 -j DROP
# IP DROP MULTICAST
-A INPUT -i eth1 -s 224.0.0.0/4 -j DROP
-A INPUT -i eth1 -s 169.254.0.0/16 -j DROP
# IP DROP LOOPBACK
-A INPUT -i eth1 -d 127.0.0.0/8 -j DROP
# IP DROP
-A INPUT -i eth1 -s 0.0.0.0/8 -j DROP
-A INPUT -i eth1 -s 240.0.0.0/4 -j DROP
-A INPUT -i eth1 -s 255.255.255.255/32 -j DROP
-A INPUT -i eth1 -s 168.254.0.0/16 -j DROP
-A INPUT -i eth1 -s 248.0.0.0/5 -j DROP
#
##
-A INPUT -j Firewall-1-INPUT
-A FORWARD -j Firewall-1-INPUT
#
## Allow all traffic on localhost
-A Firewall-1-INPUT -i lo -j ACCEPT
#
# begin: allowed networks
#
## Allow all traffic from the nodes
-A Firewall-1-INPUT -i eth0 -s 192.168.0.0/255.255.255.0 -j ACCEPT
-A Firewall-1-INPUT -i ib0 -s 192.168.100.0/255.255.255.0 -j ACCEPT
-A Firewall-1-INPUT -s 192.168.200.0/255.255.255.0 -j ACCEPT
# end: allowed networks
#
## Allow icmp
-A Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
## Allow IPsec (ESP port 50 and AH port 51)
-A Firewall-1-INPUT -p esp -j ACCEPT
-A Firewall-1-INPUT -p ah -j ACCEPT
## Allow mdns (avahi)
#-A Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT
## Allow PRINTER port 631
#-A Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
#-A Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
## Allow WWW http port 80 for PFS IP
-A Firewall-1-INPUT -s 139.11.215.0/255.255.128.0 -p tcp -m state
--state NEW -m tcp --dport 80 -j ACCEPT
## Allow previously established connections
-A Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
## Allow SSH
-A Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
## Do not log smb/windows sharing packets - too much logging
-A Firewall-1-INPUT -p tcp -i eth1 --dport 137:139 -j REJECT
-A Firewall-1-INPUT -p udp -i eth1 --dport 137:139 -j REJECT
## Packets are DROPPED
-A Firewall-1-INPUT -j DROP
COMMIT

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/i6decb$jpd$
Pascal Hambourg
Le #22558481
giggzounet a écrit :
Le 10/09/2010 15:39, Pascal Hambourg a écrit :

giggzounet a écrit :

j'ai un cluster. les noeuds n'ont pas accès au net. Donc je monte un
parefeu sur le master node. Naturellement le master doit accepter tout
ce que vient des noeuds. Et j'aimerais que tout ce que vienne de
l'extérieur soit filtré à part qqs services comme ssh et http.



Le master se comporte comme un genre de load balancer ? Il fonctionne
plutôt comme un routeur, ou un reverse proxy, ou selon un autre mécanisme ?



le master se charge de distribuer les jobs sur les noeuds. C'est via le
master que tout le monde se connecte.



"Via", ça reste vague. Ça peut être via routage et redirection de ports,
ou via un programme. Je suppose que c'est via un programme, donc le
master ne fonctionne pas en routeur et dans ce cas il n'est pas censé y
avoir de trafic dans la chaîne FORWARD.

En gros j'ai 5 interfaces:

lo locahost
eth0 interface ethernet vers les noeuds
eth0:2 interface de controle/monitoring des noeuds (ipmi)



eth0:2 n'est pas une interface mais un alias IP, une façon obsolète
d'affecter une adresse IP supplémentaire à l'interface eth0.

ib0 interface infiniband vers les noeuds
eth1 interface ethernet vers l'extérieur.

En gros je voudrais qu'en interne il n'y ait aucun filtrage (donc tout
passe sur lo,ib0,eth0,eth0:2 dans tous les sens). par contre que tout en
entrée de eth1 soit bloqué sauf le port 22 (pour commencer). en sortie
sur eth1 je peux laissé ouvert.



Ça, c'est facile. Ton jeu de règles va déjà plus loin.

ben pour l'instant ça a l'air de marcher. en gros si je me connecte
normal ça va. par contre si je lance un nmap par exemple il gueule.



C'est important qu'il gueule ?

pour l'instant j'ai ça; qu'en pensez vous (résultat de mon mal de tête...) ?

*filter
:INPUT ACCEPT [0:0]



La politique par défaut devrait être DROP.

:FORWARD ACCEPT [0:0]



Même chose, si la machine n'est pas routeur rien ne doit traverser cette
chaîne.

:OUTPUT ACCEPT [0:0]
:Firewall-1-INPUT - [0:0]



Cette chaîne est inutile, tout ce qu'elle contient peut être mis dans INPUT.

## SSH (test brute force)



Ces règles devraient arriver après les règles anti-spoof.

# IP DROP SPOOF
-A INPUT -i eth1 -s 10.0.0.0/8 -j DROP
-A INPUT -i eth1 -s 172.16.0.0/12 -j DROP
-A INPUT -i eth1 -s 192.168.0.0/16 -j DROP



Je suppose que tu sais ce que tu fais et que personne n'est censé
communiquer avec ta machine par cette interface depuis ces adresses.

-A INPUT -i eth1 -s 240.0.0.0/5 -j DROP



Pourquoi /5 et pas /4 ?

# IP DROP MULTICAST
-A INPUT -i eth1 -s 224.0.0.0/4 -j DROP



Pas absolument nécessaire, la plage multicast est invalide en tant que
source donc ces paquets sont de toute façon écartés par la pile IP du noyau.

-A INPUT -i eth1 -s 169.254.0.0/16 -j DROP



Ce n'est pas du multicast, c'est la plage link-local IPv4.

# IP DROP LOOPBACK
-A INPUT -i eth1 -d 127.0.0.0/8 -j DROP



Pas absolument nécessaire, la plage de loopback est invalide en tant que
source ou destination à l'extérieur de la machine donc ces paquets sont
de toute façon écartés par la pile IP du noyau.
Accessoirement tu n'as pas mis de règle pour bloquer la plage de
loopback en source.

-A INPUT -i eth1 -s 240.0.0.0/4 -j DROP



Ah, voilà la bonne longueur de préfixe.

-A INPUT -i eth1 -s 255.255.255.255/32 -j DROP



Déjà inclus dans le préfixe précédent.

-A INPUT -i eth1 -s 168.254.0.0/16 -j DROP



Pourquoi, tu as quelque chose contre les écoles publiques du comté de
Hillsborough en Floride ?

-A INPUT -i eth1 -s 248.0.0.0/5 -j DROP



Déjà inclus dans 240.0.0.0/4.

-A INPUT -j Firewall-1-INPUT



Comme déjà dit, autant mettre les règles directement dans INPUT.

-A FORWARD -j Firewall-1-INPUT



Comme déjà dit, aucun paquet ne traverse cette chaîne si la machine
n'est pas routeur.

## Allow all traffic from the nodes
-A Firewall-1-INPUT -i eth0 -s 192.168.0.0/255.255.255.0 -j ACCEPT
-A Firewall-1-INPUT -i ib0 -s 192.168.100.0/255.255.255.0 -j ACCEPT
-A Firewall-1-INPUT -s 192.168.200.0/255.255.255.0 -j ACCEPT



Toujours vérifier l'interface d'entrée.
Note : spécifier la longueur de préfixe plutôt que le masque est AMA
plus lisible.

## Allow icmp
-A Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT



Bof. Le ping (echo-request), c'est suffisant.

## Allow IPsec (ESP port 50 and AH port 51)



Protocoles 50 et 51, pas ports.

-A Firewall-1-INPUT -p esp -j ACCEPT
-A Firewall-1-INPUT -p ah -j ACCEPT



C'est utile ?

## Allow previously established connections
-A Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT



Cette règle devrait se trouver en début de chaîne car c'est elle qui
traite normalement le plus de paquets.

## Allow SSH
-A Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT



Déjà traité plus haut avec le bazar "recent", non ?

## Do not log smb/windows sharing packets - too much logging
-A Firewall-1-INPUT -p tcp -i eth1 --dport 137:139 -j REJECT
-A Firewall-1-INPUT -p udp -i eth1 --dport 137:139 -j REJECT
## Packets are DROPPED
-A Firewall-1-INPUT -j DROP



Pas logique. Le commentaire dit "do not log", mais il n'y a pas de règle
LOG de toute façon. Et pourquoi REJECT sur les paquets Netbios mais pas
les autres ?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
steve
Le #22558611
Pascal,

J'adore te lire, merci pour ce bon début de wiknd !


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
giggz
Le #22558681
Le 10/09/2010 20:11, Pascal Hambourg a écrit :
giggzounet a écrit :
Le 10/09/2010 15:39, Pascal Hambourg a écrit :

giggzounet a écrit :

j'ai un cluster. les noeuds n'ont pas accès au net. Donc je monte un
parefeu sur le master node. Naturellement le master doit accepter tout
ce que vient des noeuds. Et j'aimerais que tout ce que vienne de
l'extérieur soit filtré à part qqs services comme ssh et http.



Le master se comporte comme un genre de load balancer ? Il fonctionne
plutôt comme un routeur, ou un reverse proxy, ou selon un autre mécanisme ?



le master se charge de distribuer les jobs sur les noeuds. C'est via le
master que tout le monde se connecte.



"Via", ça reste vague. Ça peut être via routage et redirection de ports,
ou via un programme. Je suppose que c'est via un programme, donc le
master ne fonctionne pas en routeur et dans ce cas il n'est pas censé y
avoir de trafic dans la chaîne FORWARD.




disons que normalement il n'agit pas en routeur. mais si les noeuds ont
besoin d'internet j'active temporairement l'ip forwarding.

En gros j'ai 5 interfaces:

lo locahost
eth0 interface ethernet vers les noeuds
eth0:2 interface de controle/monitoring des noeuds (ipmi)



eth0:2 n'est pas une interface mais un alias IP, une façon obsolète
d'affecter une adresse IP supplémentaire à l'interface eth0.




oui. d'ailleurs je suppose que je ne peux pas faire:
-A Firewall-1-INPUT -i eth0:2 -s 192.168.200.0/255.255.255.0 -j ACCEPT non ?

ib0 interface infiniband vers les noeuds
eth1 interface ethernet vers l'extérieur.

En gros je voudrais qu'en interne il n'y ait aucun filtrage (donc tout
passe sur lo,ib0,eth0,eth0:2 dans tous les sens). par contre que tout en
entrée de eth1 soit bloqué sauf le port 22 (pour commencer). en sortie
sur eth1 je peux laissé ouvert.



Ça, c'est facile. Ton jeu de règles va déjà plus loin.




ok. donc c'est correct.

ben pour l'instant ça a l'air de marcher. en gros si je me connecte
normal ça va. par contre si je lance un nmap par exemple il gueule.



C'est important qu'il gueule ?




ben non :)

pour l'instant j'ai ça; qu'en pensez vous (résultat de mon mal de tête...) ?

*filter
:INPUT ACCEPT [0:0]



La politique par défaut devrait être DROP.




alors là ya un truc que je ne pige pas:
si c'est à DROP tout ce qui rentre va être droppé non ? Dans quel ordre
iptables lit il les règles ? pourquoi si :INPUT est à DROP j'arrive tout
de même à avoir une connection ssh avec l'autre règle ?

:FORWARD ACCEPT [0:0]



Même chose, si la machine n'est pas routeur rien ne doit traverser cette
chaîne.




ok. sauf si j'active temporairement l'ip forwarding, non ?

:OUTPUT ACCEPT [0:0]
:Firewall-1-INPUT - [0:0]



Cette chaîne est inutile, tout ce qu'elle contient peut être mis dans INPUT.




mais via cette chaine je traite INPUT et FORWARD en même temps, non ?

## SSH (test brute force)



Ces règles devraient arriver après les règles anti-spoof.




ok. je corrige

# IP DROP SPOOF
-A INPUT -i eth1 -s 10.0.0.0/8 -j DROP
-A INPUT -i eth1 -s 172.16.0.0/12 -j DROP
-A INPUT -i eth1 -s 192.168.0.0/16 -j DROP



Je suppose que tu sais ce que tu fais et que personne n'est censé
communiquer avec ta machine par cette interface depuis ces adresses.




oui. c'est voulu.

-A INPUT -i eth1 -s 240.0.0.0/5 -j DROP



Pourquoi /5 et pas /4 ?




aucune idée...le mal de tête :D

# IP DROP MULTICAST
-A INPUT -i eth1 -s 224.0.0.0/4 -j DROP



Pas absolument nécessaire, la plage multicast est invalide en tant que
source donc ces paquets sont de toute façon écartés par la pile IP du noyau.




ok. donc à virer.

-A INPUT -i eth1 -s 169.254.0.0/16 -j DROP



Ce n'est pas du multicast, c'est la plage link-local IPv4.




ok.

# IP DROP LOOPBACK
-A INPUT -i eth1 -d 127.0.0.0/8 -j DROP



Pas absolument nécessaire, la plage de loopback est invalide en tant que
source ou destination à l'extérieur de la machine donc ces paquets sont
de toute façon écartés par la pile IP du noyau.
Accessoirement tu n'as pas mis de règle pour bloquer la plage de
loopback en source.




ok.

-A INPUT -i eth1 -s 240.0.0.0/4 -j DROP



Ah, voilà la bonne longueur de préfixe.

-A INPUT -i eth1 -s 255.255.255.255/32 -j DROP



Déjà inclus dans le préfixe précédent.




donc à virer ?

-A INPUT -i eth1 -s 168.254.0.0/16 -j DROP



Pourquoi, tu as quelque chose contre les écoles publiques du comté de
Hillsborough en Floride ?




ben je les aime po :p

-A INPUT -i eth1 -s 248.0.0.0/5 -j DROP



Déjà inclus dans 240.0.0.0/4.




ok. donc je vire.

-A INPUT -j Firewall-1-INPUT



Comme déjà dit, autant mettre les règles directement dans INPUT.

-A FORWARD -j Firewall-1-INPUT



Comme déjà dit, aucun paquet ne traverse cette chaîne si la machine
n'est pas routeur.

## Allow all traffic from the nodes
-A Firewall-1-INPUT -i eth0 -s 192.168.0.0/255.255.255.0 -j ACCEPT
-A Firewall-1-INPUT -i ib0 -s 192.168.100.0/255.255.255.0 -j ACCEPT
-A Firewall-1-INPUT -s 192.168.200.0/255.255.255.0 -j ACCEPT



Toujours vérifier l'interface d'entrée.
Note : spécifier la longueur de préfixe plutôt que le masque est AMA
plus lisible.




ok. mais qu'est ce que je met qd c'est un alias ? dans mon cas eth0:2,
je met eth0 ?

## Allow icmp
-A Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT



Bof. Le ping (echo-request), c'est suffisant.

## Allow IPsec (ESP port 50 and AH port 51)



Protocoles 50 et 51, pas ports.

-A Firewall-1-INPUT -p esp -j ACCEPT
-A Firewall-1-INPUT -p ah -j ACCEPT



C'est utile ?




non :)

## Allow previously established connections
-A Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT



Cette règle devrait se trouver en début de chaîne car c'est elle qui
traite normalement le plus de paquets.




tu veux dire que je dois mettre ça tout en haut ? mais après les DROP ?

## Allow SSH
-A Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT



Déjà traité plus haut avec le bazar "recent", non ?




vi. ça c'est un "reste"

## Do not log smb/windows sharing packets - too much logging
-A Firewall-1-INPUT -p tcp -i eth1 --dport 137:139 -j REJECT
-A Firewall-1-INPUT -p udp -i eth1 --dport 137:139 -j REJECT
## Packets are DROPPED
-A Firewall-1-INPUT -j DROP



Pas logique. Le commentaire dit "do not log", mais il n'y a pas de règle
LOG de toute façon. Et pourquoi REJECT sur les paquets Netbios mais pas
les autres ?




c'est encore un reste. j'ai tenté de logguer mais il y a tellement de
tentative...que je me suis retrouvé avec un fichier message de 10 mo en
30 minutes...donc encore un reste.


est ce que tu vois des règles utiles à rajouter ?


Merci pour le temps consacré,
Guillaume

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/i6e47h$n2h$
Serge Cavailles
Le #22558951
Bonjour,

Je me permets d'intervenir, j'adore me faire reprendre par Pascal. ;)

Le Friday 10 September 2010 22:25:20 giggz, vous avez écrit :
>>
>> *filter
>>
>> :INPUT ACCEPT [0:0]
>
> La politique par défaut devrait être DROP.

alors là ya un truc que je ne pige pas:
si c'est à DROP tout ce qui rentre va être droppé non ?



La politique par _defaut_ s'applique en fin de chaîne aux paquets restant s
(comprendre qui n'auront pas été acceptés par une règle).


Dans quel ordre iptables lit il les règles ?



Dans l'ordre ou elles apparaissent dans les tables.
Chaque ajout (-A) à lieu à la suite des règles existantes, d'où la remarque de
Pascal (plus loin dans le même message) de placer les règles concernant les
paquets ESTABLISHED/RELATED en début de table, pour éviter que ces paqu ets ne
doivent tout d'abord passer par les autres règles.

>> ## Allow previously established connections
>> -A Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> Cette règle devrait se trouver en début de chaîne car c'est elle qui
> traite normalement le plus de paquets.




Plus globalement, une politique de DROP par défaut me paraît beaucoup p lus
sûre; si on oublie d'ouvrir un port ça se remarque généralement ass ez
rapidement, ce qui n'est pas forcément le cas de ceux que l'on oublie de
fermer. De plus AMA c'est plus facile à lire et à comprendre, on n'a qu e des
règles ACCEPT au lieu d'un mélange de règles ACCEPT (pour récupér er les
paquets sans traverser toute la chaîne) et de règles DROP dans le cas d 'une
politique par défaut en ACCEPT.


mes 2cts.
--
Serge

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
giggz
Le #22559461
Le 11/09/2010 00:21, Serge Cavailles a écrit :
Bonjour,

Je me permets d'intervenir, j'adore me faire reprendre par Pascal. ;)

Le Friday 10 September 2010 22:25:20 giggz, vous avez écrit :

*filter

:INPUT ACCEPT [0:0]



La politique par défaut devrait être DROP.



alors là ya un truc que je ne pige pas:
si c'est à DROP tout ce qui rentre va être droppé non ?



La politique par _defaut_ s'applique en fin de chaîne aux paquets restants
(comprendre qui n'auront pas été acceptés par une règle).




ah ok. j'avais pas saisi. Donc si je comprends bien, en mettant
:INPUT DROP au début je n'ai plus besoin d'avoir:
-A INPUT -j DROP juste avant le commit, non ?


Dans quel ordre iptables lit il les règles ?



Dans l'ordre ou elles apparaissent dans les tables.
Chaque ajout (-A) à lieu à la suite des règles existantes, d'où la remarque de
Pascal (plus loin dans le même message) de placer les règles concernant les
paquets ESTABLISHED/RELATED en début de table, pour éviter que ces paquets ne
doivent tout d'abord passer par les autres règles.




ok. je saisis.
Faut il mieux mettre la règle pour lo et RELATED,ESTABLISHED avant ou
après "anti-spoofing" ?

## Allow previously established connections
-A Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT



Cette règle devrait se trouver en début de chaîne car c'est elle qui
traite normalement le plus de paquets.






Plus globalement, une politique de DROP par défaut me paraît beaucoup plus
sûre; si on oublie d'ouvrir un port ça se remarque généralement assez
rapidement, ce qui n'est pas forcément le cas de ceux que l'on oublie de
fermer. De plus AMA c'est plus facile à lire et à comprendre, on n'a que des
règles ACCEPT au lieu d'un mélange de règles ACCEPT (pour récupérer les
paquets sans traverser toute la chaîne) et de règles DROP dans le cas d'une
politique par défaut en ACCEPT.




ok . merci de tes explications. BOn en combinant vos 2 réponses. J'ai
pour l'instant:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
#
## Allow all traffic on localhost
-A INPUT -i lo -j ACCEPT
#
## Allow previously established connections
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
#
# IP DROP SPOOF
-A INPUT -i eth1 -s 10.0.0.0/8 -j DROP
-A INPUT -i eth1 -s 172.16.0.0/12 -j DROP
-A INPUT -i eth1 -s 192.168.0.0/16 -j DROP
-A INPUT -i eth1 -s 240.0.0.0/4 -j DROP
# IP DROP link-local
-A INPUT -i eth1 -s 169.254.0.0/16 -j DROP
# IP DROP
-A INPUT -i eth1 -s 0.0.0.0/8 -j DROP
-A INPUT -i eth1 -s 240.0.0.0/4 -j DROP
-A INPUT -i eth1 -s 168.254.0.0/16 -j DROP
#
# begin: allowed networks
#
## Allow all traffic from the nodes
-A INPUT -i eth0 -s 192.168.0.0/24 -j ACCEPT
-A INPUT -i ib0 -s 192.168.100.0/24 -j ACCEPT
-A INPUT -s 192.168.200.0/24 -j ACCEPT
# end: allowed networks
#
## SSH + test brute force
-A INPUT -i eth1 -p tcp -m tcp --dport 22 -m state --state NEW -m recent
--set --name SSH --rsource -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 22 -m recent --update --seconds
60 --hitcount 4 --rttl --name SSH --rsource -j LOG --log-prefix
"SSH_brute_force "
-A INPUT -i eth1 -p tcp -m tcp --dport 22 -m recent --update --seconds
60 --hitcount 4 --rttl --name SSH --rsource -j DROP
#
## Allow icmp echo-request
-A INPUT -i eth1 -p icmp -m icmp --icmp-type 8 -j ACCEPT
#
## Allow WWW http port 80 for PFS IP
-A INPUT -i eth1 -s 139.11.215.0/17 -p tcp -m state --state NEW -m tcp
--dport 80 -j ACCEPT
## Packets are DROPPED
-A INPUT -j DROP
COMMIT



Donc les points qui restent obscurent pour le moment ce sont:
- peut on mettre -A INPUT -eth0 -s 192.168.200.0/24 -j ACCEPT ? ou alors
-A INPUT -eth0:2 -s 192.168.200.0/24 -j ACCEPT ?

- la ligne -A INPUT -j DROP est elle nécessaire ? si j'ai bien compris
la réponse de Serge, je suppose que je peux la supprimer.

- les règles de spoof doivent être en premier ou alors lo et
related/established ?


- si je veux permettre à mes noeuds d'avoir internet, il suffit que je
fasse :
iptables -t nat -A POSTROUTING --out-interface eth1 -j MASQUERADE -s
192.168.0.0/16
sysctl -w net.ipv4.ip_forward=1
non ?

Merci de votre aide! je commence à entrevoir la chose...
Guillaume

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/i6fbpn$8ad$
Pascal Hambourg
Le #22559551
giggz a écrit :
Le 11/09/2010 00:21, Serge Cavailles a écrit :

La politique par _defaut_ s'applique en fin de chaîne aux paquets restants
(comprendre qui n'auront pas été acceptés par une règle).





Pas seulement acceptés. La politique par défaut est appliquée aux
paquets qui atteignent la fin de la chaîne sans avoir rencontré de cible
dite "terminale" : DROP, ACCEPT, REJECT, DNAT, SNAT, MASQUERADE...

ah ok. j'avais pas saisi. Donc si je comprends bien, en mettant
:INPUT DROP au début je n'ai plus besoin d'avoir:
-A INPUT -j DROP juste avant le commit, non ?



En effet.

Faut il mieux mettre la règle pour lo et RELATED,ESTABLISHED avant ou
après "anti-spoofing" ?



Pour lo, tu peux la mettre avant sauf si tu soupçonnes ta machine de
faire du spoofing lorsqu'elle se cause à elle-même (ce qui traduirait de
graves troubles de la personnalité).

Pour RELATED,ESTABLISHED, en toute rigueur il faudrait la mettre après.
En effet le suivi de connexion ne tient pas compte de l'interface
d'arrivée des paquets (après tout, le routage sur internet est
asymétrique par nature et une machine multihomée peut recevoir un paquet
légitime par n'importe quelle interface). On pourrait imaginer une
situation où la machine communique avec une machine A sur l'interface
interne, et une machine B extérieure profite de la connexion établie
pour injecter des paquets par l'interface externe en se faisant passer
pour A. Mais cette situation a autant sinon plus de chances de se
produire si la machine usurpée et la machine usurpatrice sont du même
côté, et là le filtrage anti-spoofing n'y peut rien.

ok . merci de tes explications. BOn en combinant vos 2 réponses. J'ai
pour l'instant:


[...]
-A INPUT -i eth1 -s 240.0.0.0/4 -j DROP


[...]
-A INPUT -i eth1 -s 240.0.0.0/4 -j DROP



Doublon.

Donc les points qui restent obscurent pour le moment ce sont:
- peut on mettre -A INPUT -eth0 -s 192.168.200.0/24 -j ACCEPT ?



Plutôt -i eth0.

ou alors -A INPUT -eth0:2 -s 192.168.200.0/24 -j ACCEPT ?



Encore moins, eth0:2 n'est pas une interface.

- la ligne -A INPUT -j DROP est elle nécessaire ? si j'ai bien compris
la réponse de Serge, je suppose que je peux la supprimer.



En effet, puisque la politique par défaut de la chaîne est DROP.

- si je veux permettre à mes noeuds d'avoir internet, il suffit que je
fasse :
iptables -t nat -A POSTROUTING --out-interface eth1 -j MASQUERADE -s
192.168.0.0/16
sysctl -w net.ipv4.ip_forward=1
non ?



Il faudra aussi des règles dans FORWARD pour accepter les connexions
routées arrivant par eth0 puisque la politique par défaut est DROP.

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m state --state NEW -j ACCEPT

A précéder par des règles anti-spoofing sur eth1 si tu y tiens. Elles
peuvent être factorisées dans une chaîne utilisateur appelée depuis
INPUT et FORWARD.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Pascal Hambourg
Le #22559651
giggz a écrit :
Le 10/09/2010 20:11, Pascal Hambourg a écrit :

eth0:2 n'est pas une interface mais un alias IP, une façon obsolète
d'affecter une adresse IP supplémentaire à l'interface eth0.



oui. d'ailleurs je suppose que je ne peux pas faire:
-A Firewall-1-INPUT -i eth0:2 -s 192.168.200.0/255.255.255.0 -j ACCEPT non ?



Tu peux, même si iptables affiche un avertissement. Mais ça ne fera pas
ce que tu attends. Cette règle n'accrochera jamais aucun paquet puisque
l'interface eth0:2 n'existe pas.

:Firewall-1-INPUT - [0:0]


Cette chaîne est inutile, tout ce qu'elle contient peut être mis dans INPUT.



mais via cette chaine je traite INPUT et FORWARD en même temps, non ?



Justement, il y a de forte chances que les besoins de filtrage dans
INPUT et FORWARD soient très différents. Seules les règles communes sont
susceptibles d'être factorisées dans une chaîne utilisateur.

-A INPUT -i eth1 -s 240.0.0.0/4 -j DROP


Ah, voilà la bonne longueur de préfixe.

-A INPUT -i eth1 -s 255.255.255.255/32 -j DROP


Déjà inclus dans le préfixe précédent.



donc à virer ?



Oui, cette règle n'accrochera aucun paquet puisque tous les paquets
qu'elle pourrait accrocher auront déjà été bloqués par la règle
précédente plus large.

-A INPUT -i eth1 -s 168.254.0.0/16 -j DROP


Pourquoi, tu as quelque chose contre les écoles publiques du comté de
Hillsborough en Floride ?



ben je les aime po :p



C'est toi qui vois.

ok. mais qu'est ce que je met qd c'est un alias ? dans mon cas eth0:2,
je met eth0 ?



Oui. iptables ne connaît que les interfaces et les adresses, pas les alias.

c'est encore un reste. j'ai tenté de logguer mais il y a tellement de
tentative...que je me suis retrouvé avec un fichier message de 10 mo en
30 minutes...donc encore un reste.



Trop de log tue le log...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme