Avec le script comme il est, pour réinitialiser le parefeu :
/etc/init.d/mon_parefeu clean
Ok, mais est-ce que les trois commandes auraient l’effet de détruire toutes les modifications ? Comme avant les manipulations, en fait.
oui aux lancement des scripts de démarrage près
update-rc.d -f parefeu remove
Bonsoir,
Je me retrouve également avec :
update-rc.d: warning: mon_parefeu start runlevel arguments (S) do not match LSB Default-Start values (2 3 4 5)
update-rc.d: warning: mon_parefeu stop runlevel arguments (0 6) do not match LSB Default-Stop values (0 1 6)
ds le script j’ai ajouter :
[code]### BEGIN INIT INFO
Provides: iptables
Required-Start:
Should-Start:
Required-Stop:
Should-Stop:
Default-Start: 2 3 4 5
Default-Stop: 0 1 6
Short-description: iptables
Description: Firewall
END INIT INFO[/code]
Même problème , 
sur STABLE avec Kernel : 2.3.32
digression-installation-parefeu-iptables-pour-les-nuls-t26303-300.html#p319850
Mais
Ah ? Peux-tu expliquer en quoi c’est inutile ?
Pour moi afin d’assurer une protection optimale les règles iptables doivent être mises en place avant l’activation du réseau qui a lieu en runlevel S.[/quote]
Je n’avais pas vu, le mode single est en général un mode de maintenance où aucun service n’est actif. C’est pour cela que je trouve cela inutile. Par contre ton argument se tient, il suffit de mettre l’activation avant le lancement de networking.
Puis rajout: merdouille, je n’avais pas vu que cette activation avait lieu en S (09) d’où ton S (08). Dans ce cas c’est cohérent, je n’avais pas pensé à cette précaution.
Conclusion, il faut ignorer les «warnings»…
PS: Ricardo, je ne crois pas que j’avais écrit stupide.
hello
euh j’arrive après la guèrre mai il manque un tuto pour un serveur pour les noob (me ? 
)
bien qu’un admin devrai savoir le faire, je pense que en fournir un de base serai bien.
d’autre par des commentaire pourquoi on ne filtre pas les sortie ?
j’avoue que sa me chiffonne ,
car on supose que rien ne devrai rentrer. donc ne rien toucher.
cepandant on peux très bien installer quelque chose qui possède des dépandances ,(la paquet A qui va installer apache… hum oui bon imaginon hein…)
rien ne va bloquer la sortie … et un port 80 ouvert … welcome the world?
on peux aussi filtrer les paquet par utilisateur ,chose que je me suis amuser a faire, cepandant certin paquet bien que sa ne soie pas root qui est propriétaire de l’application est reconnu comme utilisateur root.
c’est donc pas possible de filtrer quelque chose avec cela. (et c est vachment dur a mintenir a chaque utilisateur créée ou suprimer il fau tmodifier le par feux donc déconseiller hormis pour s’amuser…)
vala bon tout avis est bien venu , mai taper pas trop fort 
La sortie, je vois pas ce qu’il y a de chiffonnant là-dedans :
Si tu as peur de quelque chose qui sortirai de ton serveur, c’est qu’il est mal protégé en amont et qu’il transmet des paquets suites à une requêtes entrantes 
Donc le : "rien n’entre sans permission et tous peut sortir et bien sur ce point de vue 
"
Salut,
J’ai un peu travaillé sur les règles proposées, et pour ma part je vais appliquer les règles suivantes (c’est sur une passerelle)
Ne pas accepter toutes les connexion qui viennent du LAN…
Donc je ne met pas cette ligne: iptables -A INPUT -i ethx -j ACCEPT
Et je remplace ceci:
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
Par cela:
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
En fait je bloque tout, et précise à chaque fois quelle interface/port est autorisée ou pas
Ça donnerait pour un serveur Web ceci (autorisation sur LAN et WAN)
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT
Il faut avoir une confiance aveugle dans son LAN pour laisser tout ouvert, non ?
[quote=“lol”]Salut,
J’ai un peu travaillé sur les règles proposées, et pour ma part je vais appliquer les règles suivantes (c’est sur une passerelle)
Ne pas accepter toutes les connexion qui viennent du LAN…
Donc je ne met pas cette ligne: iptables -A INPUT -i ethx -j ACCEPT
Et je remplace ceci:
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
Par cela:
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
En fait je bloque tout, et précise à chaque fois quelle interface/port est autorisée ou pas
Ça donnerait pour un serveur Web ceci (autorisation sur LAN et WAN)
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT
Il faut avoir une confiance aveugle dans son LAN pour laisser tout ouvert, non ?[/quote]
je trouve le faite de devoir mettre l’interface une mauvaise idée car, si on ajoute ou si desactive/active une carte reseau dans e bios (quand il y a pas plusieur interface …) le nom de l’interface pourait changer et du coup plus rien n’est correct. c’est aussi valable quand une mise jours du systeme ce fait ,parfois l’interface change.
sa reste rare, mai sur un serveur il devien inacessible si cela ce produis.
ceci dit tes explication son interessante 
Salut,
[quote=“panthere”]je trouve le faite de devoir mettre l’interface une mauvaise idée car, si on ajoute ou si desactive/active une carte reseau dans e bios (quand il y a pas plusieur interface …) le nom de l’interface pourait changer et du coup plus rien n’est correct. c’est aussi valable quand une mise jours du systeme ce fait ,parfois l’interface change.
sa reste rare, mai sur un serveur il devien inacessible si cela ce produis.
ceci dit tes explication son interessante [/quote]
C’est juste, merci d’avoir pris la peine de regarder.
Ceci dit il faut bien trouver une façon de se protéger et de distinguer clairement les réseaux.
Dans mon cas le LAN n’est pas parfaitement sain, il est ouvert. Ce n’est pas aussi pourri qu’Internet, mais bon…
Maintenant, sur une stable, un serveur, les changements sont quand même rares. Mais je vais en tenir compte.
Merci
Ça dépend des besoins.
Pour une machine avec une seule interface, ou dont les communications peuvent passer indifféremment par n’importe quelle interface, il n’est pas forcément pertinent de filtrer par interface.
En revanche ça l’est pour un routeur ou un serveur qui donne accès à des services différents sur chaque interface.
Salut,
C’est le cas. Merci de cette précision.
J’ai un routeur/pare-feu/portail captif/proxy filtrant à mettre en place.
Je m’y prend à l’avance: je ne suis pas très à l’aise avec iptables et Xen…
Ça commence tout juste à prendre forme.
Pour iptables, je souhaite effectivement séparer l’accès aux services en fonction des interfaces, des réseaux et éventuellement pour certains services (ssh par exemple) des ip.
Il existe une façon simple de “débuger” iptables ?
iptables -L -v et iptables -t nat -L -v t’indiquent le nombre de fois qu’une règle a été appliquée. iptables-save t’infique les règles telles qu’elles sont réellement, c’est finalement ce qui est le plus parlant.
Salut,
Merci pour les deux premières commandes, c’est pratique.
iptables-saves c’est bien, mais encore faut-il être capable de déchifrer en un coup d’oeil l’ensemble des règles.
Je décroche quand ça devient un peu complexe… Un peu comme au échecs: facile d’anticiper deux trois coups, au delà…
[quote=“lol”]Salut,
Merci pour les deux premières commandes, c’est pratique.
iptables-saves c’est bien, mais encore faut-il être capable de déchifrer en un coup d’oeil l’ensemble des règles.
Je décroche quand ça devient un peu complexe… Un peu comme au échecs: facile d’anticiper deux trois coups, au delà… [/quote]
si tu pratique le marquage de paquet oui sa devien complexe, mai c est rare de s’en servir (du moins pour moi et mes serveur)
Vu que je passe plus que par des script j’utilise un bout de code:
if [ "$*" = "stat" ] ;then
#echo "==================== table filter ==================="
#tc -s -d filter ls dev eth0
#echo "==================== Les class ==================="
#tc -s -d class ls dev eth0
#echo "==================== La table mangle ==============="
#iptables -t mangle -L marcage-paquet-en-sortie -v -x 2> /dev/null
echo "==================== Iptables ==================="
iptables -L -n -v -x --line-numbers
exit
fiévidement vu que c est par interface c est pénible il faut l’adapter, par exemple si on a du wifi le nom change facilment
le lien don je me ser depuis la version 1.2.0:
linux-france.org/prj/inetdoc … -tutorial/
amuse toi bien ,je joue avec quand je sai pas trop quoi faire
Salut,
Ça c’est sympa!
“Malheureusement” oui, je joue avec le marquage… C’est plus amusant! 
C’est pour un portail captif…
$IPT -t mangle -A PREROUTING -i $NTINT -j CONNMARK --restore-mark
$IPT -t mangle -A PREROUTING -p TCP -i $NTINT -d $IP_PRIVATE -j ACCEPT
$IPT -t mangle -A PREROUTING -p TCP -i $NTINT -m state --state NEW -j QUEUE
$IPT -t nat -A PREROUTING -p TCP -i $NTINT -j CONNMARK --save-mark
$IPT -t nat -A PREROUTING -p TCP -i $NTINT -m mark --mark 0xFFFFFFFF -j ACCEPT
$IPT -t nat -A PREROUTING -p TCP --dport 80 -i $NTINT -m mark --mark 0 -j DNAT --to-destination $IP_PRIVATE:8080
Merci beaucoup pour le bout de code et le lien!
il y a un module qui demande pas mal de relfexion et qui est buguer:
linux-france.org/prj/inetdoc … ownermatch
il faut savoir que seul:
[!] --uid-owner username
[!] --uid-owner userid[-userid]
!] --gid-owner groupname
marche actuelment mai, je te laisse trouver le bug 
suplementaire c’est juste pour le fun si j’ai rien dit a ce jours c’est simplement
qu’il est pas grave:)
Salut,
Je me demandais… Est-il mieux d’utiliser le script proposé ici, ou plutôt ceci dans le fichier /etc/network/interfaces:
Quels sont les avantages d’utiliser le script plutôt que de lancer iptables au moment du démarrage du réseau avec iptables-restore ?
Si j’ai bien compris, le script démarre juste avant que les interfaces ne soient “levées”. C’est mieux ?
est-ce que ta restauration est bien à jour ?
Oui,
Quand j’ajoute ou enlève une règle, hop:
Je me posais juste la question de l’utilité du script…