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.
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.
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.
suite à des problèmes avec la surcouche firewall apportée par
firestarter, je me décide à m'intéresser à iptables.
J'ai tenté ma chance sur la list de
netfilter...mais bon pas eu de réponse...
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
Est ce qu'on peut faire mieux ? ou alors plus simple? bref si vous avez
des idées...je 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 ?
suite à des problèmes avec la surcouche firewall apportée par
firestarter, je me décide à m'intéresser à iptables.
J'ai tenté ma chance sur la list de
netfilter...mais bon pas eu de réponse...
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
Est ce qu'on peut faire mieux ? ou alors plus simple? bref si vous avez
des idées...je 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 ?
suite à des problèmes avec la surcouche firewall apportée par
firestarter, je me décide à m'intéresser à iptables.
J'ai tenté ma chance sur la list de
netfilter...mais bon pas eu de réponse...
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
Est ce qu'on peut faire mieux ? ou alors plus simple? bref si vous avez
des idées...je 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 ?
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.
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.
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.
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.
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.
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.
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)
# 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
-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 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
## 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 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
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.
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.
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.
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)
# 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
-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 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
## 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 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
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.
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.
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.
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)
# 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
-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 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
## 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 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
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 ?
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 ?
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 ?
>>
>> *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 ?
>> ## 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.
>>
>> *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 ?
>> ## 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.
>>
>> *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 ?
>> ## 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.
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).
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.
## 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.
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).
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.
## 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.
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).
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.
## 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.
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).
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 ?
Faut il mieux mettre la règle pour lo et RELATED,ESTABLISHED avant ou
après "anti-spoofing" ?
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
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.
- 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 ?
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).
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 ?
Faut il mieux mettre la règle pour lo et RELATED,ESTABLISHED avant ou
après "anti-spoofing" ?
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
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.
- 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 ?
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).
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 ?
Faut il mieux mettre la règle pour lo et RELATED,ESTABLISHED avant ou
après "anti-spoofing" ?
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
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.
- 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 ?
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 ?
: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 ?
-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
ok. mais qu'est ce que je met qd c'est un alias ? dans mon cas eth0:2,
je met eth0 ?
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.
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 ?
: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 ?
-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
ok. mais qu'est ce que je met qd c'est un alias ? dans mon cas eth0:2,
je met eth0 ?
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.
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 ?
: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 ?
-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
ok. mais qu'est ce que je met qd c'est un alias ? dans mon cas eth0:2,
je met eth0 ?
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.