38 RETVAL=1
39 ;;
40 esac
41 exit $RETVAL
Bhen ça bloque toujours a la ligne 40 !
Pourtant c’est le même sur le tuto :
Quelqu’un a une idée ??
Edit=
La sortie d’erreur est la suivante:
root@Sid-1:~# /etc/init.d/mon-parefeu stop
/etc/init.d/mon-parefeu: 40: /bin/iptables-save: not found
C’est lié a ces lignes du script : ???
10 /bin/[b]iptables-save >[/b] /etc/config_parefeu
11 RETVAL=$?
12 ;;
13 'clean')Chez moi (et sur le tuto), c’est
mon_parefeu
et non
mon-parefeu
‘_’ à la place de '-'
c’est ptet ça qui coince ?
non ricardo, sinon, ça n’arriverait pas à la ligne 40 du fichier, s’il n’existait pas 
Clem_ufo: le paquet iptables est il installé sur ta machine ?
Bonsoir à tous
iptables est bien installé:
apt-cache policy iptables
iptables:
Installé : 1.4.6-2
Candidat : 1.4.6-2
Table de version :
*** 1.4.6-2 0
500 http://ftp.fr.debian.org sid/main Packages
500 http://ftp.fr.debian.org testing/main Packages
100 /var/lib/dpkg/status
J’ai mv mon-parefeu en mon_parefeu : sans changements.
Par contre pour un /etc/init.d/mon_parefeu start : il n’ y a aucun problèmes.
C’est au déchargement que ça coince
tilt !! Un locate me dit que je n’ai pas de /bin/iptables mais un /sbin/iptables
Je fait la modif et je vois si ça s’arrange.
EDIT:
Bon voila :
10 /bin/iptables-save > /etc/config_parefeu
11 RETVAL=$?
12 ;;
13 'clean')
devient:
10 /sbin/iptables-save > /etc/config_parefeu
11 RETVAL=$?
12 ;;
13 'clean')
Et plus de messages d’erreurs !! 
Un grand merci a vous 
[Re-Edit : HS : Je suis une andouille ( de Vire ( de là)) = Pas foutu de recopier un script
]
L’important, c’est que tu y sois arrivé.
Les recopies, c’est souvent le piège.
C’est pour ça que je préfère le copié/collé, quand on est sûr que c’est bon au départ 
Bon dimanche !
salut Ricardo,
j’ai adopté ton script de firewal basé sur iptables depuis quelques temps. Et, ça je t’en remercie grandement !
Et là je le modifie pour LSB.
Je te soumet les champs lsb ajoutés :
#!/bin/sh
Te semblent-ils corrects ?
Il y a une discussion ici : viewtopic.php?f=3&t=26319 sur le runlevel S, mais après
update-rc.d firewall remove
update-rc.d firewall defaults
ça renvoit une erreur et un désaccord !! (je ne l’ai pas notée, mais je peux la reproduire, si besoin !!!)
J’attends de te lire.
H.
J’avoue mon incompétence concernant LSB et, plutôt que de dire des conneries, je préfère que d’autres te répondent.
j’ai modifié le script, et ça fonctionne pour moi. En tout cas, je n’ai plus d’erreurs.
Juste une remarque, avec la configuration proposée dans le tuto, ce site détecte les ports fermés :
zebulon.fr/outils/scanports/ … curite.php
Comment les masquer, pour avoir une protection plus poussée?
Une autre question, comment puis-je voir les logs du firewall, ou tout simplement être averti si quelque chose de louche se produit?
[quote=“thuban”]
Une autre question, comment puis-je voir les logs du firewall, ou tout simplement être averti si quelque chose de louche se produit?[/quote]
essaie avec cette ligne en plus
-A INPUT -j LOG
elle m’avait été indiquée par Pascal Hambourg, qui ne vient plus souvent, malheureusement 
Pas mal ton lien :
La liste des "masqués est bien plus longue, évidemment.
Merci pour les logs!
Je ne trouve rien pour les ports visibles. C’est ennuyeux. 
Bonjour à tous et bonsoir thuban 
Je viens de rentrer : iptables -A INPUT -j LOG
et je voudrais savoir ou est ce fichier, je suis allé dans var/log et j’ai rien vu pour le reperer. 
C’est bien là le problème de LOG (je trouve), c’est qu’il loggue les paquets au milieu des autres infos dans le syslog, qui se retrouve vite noyé de ce genre d’info pour peu que nos règles soient un peu sévères…
Prérequis : les chaînes par défauts INPUT, OUTPUT et FORWARD de la table “filter” sont à DROP (sinon les règles de log en fin de script ne veulent plus dire la même chose)
Il y a une autre solution pour logguer simplement les paquets droppés dans un fichier dédié, qui consiste en la chose suivante :
Installer le paquet ulogd (apt-get install ulogd)
une fois installé, modifier le fichier de configuration /etc/ulogd.conf comme suit (plus explicite, mais facultatif):
remplacer dans la section [LOGEMU] :
file="/var/log/ulog/syslogemu.log"
par
file="/var/log/ulog/iptables"Redémarrer le service ulogd (en root : service ulogd restart)
rajouter dans son script iptables A LA FIN :
iptables -A INPUT -j ULOG --ulog-prefix '[IPTABLES DROP IN] : '
iptables -A OUTPUT -j ULOG --ulog-prefix '[IPTABLES DROP OUT] : '
iptables -A FORWARD -j ULOG --ulog-prefix '[IPTABLES DROP FWD] : 'Les logs seront alors rassemblés dans un fichier dédié /var/log/ulog/iptables, facilement reconnaissables avec leur préfixe entre crochets, et ne pollueront plus le fichier syslog.
Pour avoir une vue temps réel des logs en question (ca peut servir, pour débugguer par exemple…), il suffit d’ouvrir un terminal et taper :
tail -f /var/log/ulog/iptablesC’est la solution que j’ai adopté pour ma machine.
ça c’est chouette! j’hésitais à désactiver le LOG, car il remplissait mes tty, pas facile de faire grand chose quand quelque chose écrit par dessus en même temps 
.
Autre question : À quand ce tutoriel sur le wiki?
Bonsoir dric64
Tu en penses quoi, j’ai enlevé la régle 9 de LOG, et en suite j’ai installé ce que tu montres.
dans les régles j’ai inclu ça : " comme dans le tuto que tu présentes c’est bien ?
Et avec ta commande tail -f /var/log/ulog/iptables je vois tout en direct.
Il y a t-il un systeme pour vider les logs iptables ? ça à l’air de se remplir vite.
Merci
[quote]debian:/home/kei# iptables-save
*filter
:INPUT DROP [2:154]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [882:137780]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT
-A INPUT -j ULOG --ulog-prefix "[IPTABLES DROP IN] : "
-A FORWARD -j ULOG --ulog-prefix "[IPTABLES DROP FWD] : "
-A OUTPUT -j ULOG --ulog-prefix "[IPTABLES DROP OUT] : "
COMMIT
*nat
REROUTING ACCEPT [0:0]
OSTROUTING ACCEPT [124:7668]
:OUTPUT ACCEPT [124:7668]
COMMIT
*mangle
REROUTING ACCEPT [851:731384]
:INPUT ACCEPT [851:731384]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [882:137780]
OSTROUTING ACCEPT [884:137934]
COMMIT
*raw
REROUTING ACCEPT [851:731384]
:OUTPUT ACCEPT [882:137780]
COMMIT
[/quote]
[quote=“thuban”]ça c’est chouette! j’hésitais à désactiver le LOG, car il remplissait mes tty, pas facile de faire grand chose quand quelque chose écrit par dessus en même temps .
Autre question : À quand ce tutoriel sur le wiki?[/quote]
Il me semble qu’il y est.
[quote=“kim”]Bonsoir dric64
Tu en penses quoi, j’ai enlevé la régle 9 de LOG, et en suite j’ai installé ce que tu montres.
dans les régles j’ai inclu ça : " comme dans le tuto que tu présentes c’est bien ?
Et avec ta commande tail -f /var/log/ulog/iptables je vois tout en direct.
Il y a t-il un systeme pour vider les logs iptables ? ça à l’air de se remplir vite.
Merci
[quote]debian:/home/kei# iptables-save
*filter
:INPUT DROP [2:154]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [882:137780]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT
-A INPUT -j ULOG --ulog-prefix "[IPTABLES DROP IN] : "
-A FORWARD -j ULOG --ulog-prefix "[IPTABLES DROP FWD] : "
-A OUTPUT -j ULOG --ulog-prefix "[IPTABLES DROP OUT] : "
COMMIT
*nat
REROUTING ACCEPT [0:0]
OSTROUTING ACCEPT [124:7668]
:OUTPUT ACCEPT [124:7668]
COMMIT
*mangle
REROUTING ACCEPT [851:731384]
:INPUT ACCEPT [851:731384]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [882:137780]
OSTROUTING ACCEPT [884:137934]
COMMIT
*raw
REROUTING ACCEPT [851:731384]
:OUTPUT ACCEPT [882:137780]
COMMIT
[/quote][/quote]
J’ai édité mon post car il pouvait porter à confusion. Toujours sauf erreur de ma part, en réalité, les lignes :
-A INPUT -j ULOG
-A FORWARD -j ULOG
-A OUTPUT -j ULOG
Placées en fin de script, vont loguer les paquets qui n’ont matchés avec aucune des règles précédentes, autrement dit, qui vont subir la politique par défaut de la chaine en question. Par conséquent, si la politique par défaut d’une chaîne est DROP, alors on loguera bien les paquets rejetés. En revanche, si la politique par défaut est ACCEPT, alors on loguera les paquets qui sont été acceptés. Il faut donc adapter le suffixe afin qu’il corresponde bien à ce que l’on va réellement loguer.
Dans ton cas, kim, c’est pas bon :
Sur la chaîne OUTPUT ta politique par défaut est ACCEPT
:OUTPUT ACCEPT [882:137780]Tu ne peux donc pas avoir
-A OUTPUT -j ULOG --ulog-prefix "[IPTABLES DROP OUT] : "
Le préfixe est incohérent avec ce que tu logues en réalité.
Un pare feu, c’est :
Soit on rejette tout ce qui n’est pas explicitement autorisé :
Politique par défaut = DROP
On créé des règles d’exceptions qui ont le status ACCEPT
Soit on accepte tout ce qui n’est pas explicitement interdit :
Politique par défaut = ACCEPT
On créé des règles d’exceptions qui ont le status DROP
Tu es dans le premier cas pour ta politique du trafic entrant, mais tu es dans le second cas pour le trafic sortant : si tu voulais loguer les paquets rejetés il faudrait donc déjà créer des cas de rejets, or tu n’en a aucun. Donc inutile de loguer tes paquets rejetés en sortie, puisque le cas ne se présentera jamais.
Je remplace ça
Par ça ?
Parce que figure toi que quand j’ai installé le parefeu du site,je ne connaissais rien aux régles,je l’ai installé sans pouvoir comprendre se que ça voulait dire.
Cette nuit j’ai regardé pas mal de tutos pour décrypter le sens de ces lignes
Maintenant je comprend un peu mieux comment fonctionne un parefeu et partant que je dois mettre ces trois lignes à la fin du script, il est normale que je mette INPUT,en esperant ne pas me tromper dans mon résonnement.
Non. 
Le préfixe c’est juste une étiquette que tu rajoutes dans chaque ligne de log pour identifier plus clairement chacune d’elles, et du premier coup d’oeil savoir si elles concernent un paquet rejeté ou accepté, en entrée ou en sortie par exemple dans notre cas. Il est complètement facultatif, et je dirais que plutôt que mettre un préfixe faux, si on n’est pas trop sur, il vaut mieux ne rien mettre… Il faut donc l’adapter à ce que fait vraiment notre ligne de log.
Pour que ca soit cohérent avec TES règles, il faudrait remplacer :
-A OUTPUT -j ULOG --ulog-prefix "[IPTABLES DROP OUT] : "
par
-A OUTPUT -j ULOG --ulog-prefix "[IPTABLES ACCEPT OUT] : "
Car la politique par défaut de la chaîne OUTPUT est ACCEPT.
Si tu remplaces par :
-A INPUT -j ULOG --ulog-prefix "[IPTABLES DROP OUT] : "
C’est pas bon, ca voudrait dire que tu “étiquettes” les paquets qui sont en réalité des paquets rejetés en entrée comme étant des paquets rejetés en sortie. C’est faux, et quand tu lirais tes logs, tu serais induit en erreur.