Il n’y a pas de paquetage .deb sur netfilter.org mais seulement les sources, je me demande comment tu as pu installer iptables avec dpkg (et si c’était le cas dpkg et apt le verraient). Ne l’aurais-tu pas compilé et installé manuellement avec make && make install comme le soupçonne lorelei ?
en effet j’avais oublié ce passage … J’ai bien compilé iptables ( je pensais l’avoir installé avec son .deb mais si il n’y a que les sources, ca doit être ca)…
Malheureusement le “make uninstall” n’est pas pris en charge … et j’ai supprimé mon dossier iptables ( adieu le install_manifest.txt ) …
je réinstall pour le destinstall ensuite ^^?
Oooh joie de l’informatique ^^
Si nettoyage manuel, pour info il y a longtemps j’avais compilé iptables qui s’était installé de mémoire dans /usr/local :
/usr/local/sbin pour les commandes iptables, ip6tables (vérifier avec which iptables)…
/usr/local/lib/iptables pour les bibliothèques partagées lib_*.so
peut-être aussi les pages de manuel, docs…
Merci beaucoup …
J’ai supprimé tout ce qu’il y avait en relation avec iptables ( il reste le système d’autocompletion pour iptables-restore mais je ne sais pas ou il est)
En esperant que ca suffira … Merci a vous deux
Pour être honnête Pascal, loin de moi cette idée.
Il me semblais simplement relever une certaine incohérence dans le fait d’avoir pour OS Debian Squeeze (Stable) avec des priorités fixés à 500. …?
install/dé-install … je m’abstiendrais.
D’où ma curiosité mal saine, il va s’en dire …
Suis encore bien trop jeune (pour un ADA, AMHA) pour compiler …
C’est pourtant la priorité par défaut sans fichier preferences. 
Qu’entendais-tu alors par “iptables n’est-il pas installé nativement ?” ?
@ syam,
J’avais oublié ceci, 
le temps s’écoule inexorablement, beaucoup trop à mon goût … sans preferences.
@ PascalHambourg,
Je suis arrivé sous Debian Lenny 5.0 (de mémoire), en aucun cas depuis, je n’ai eu à installer le paquet iptables (créer un minimum de règles … oui !), y compris sur mon dédié ovh (relativement récent).
D’où ma remarque … iptables n’est-il pas installé nativement ? … non ?
Tu veux dire installé par défaut avec le système de base ?
Probablement, car il a la priorité “important”.
Plus exactement, oui !
A mon sens, nativement=defaut.
N’en n’était il pas de même pour iptchain ?
- edit *
Que d’eaux sous les ponts, depuis ta dernière installation Debian … 
A vrai dire, je ne me suis jamais intéressé au système des préférences pour apt … J’ai deux 3-4 repositories donc je ne sais pas si c’est nécessaire …
Pour ce qui est de l’installation par défaut ,j’ai en effet du l’installer avec mon kernel … et j’ai du rencontrer l’erreur que j’ai toujours ( malgré l’utilisation d’aptitude)… je recréerais un poste si je n’arrive pas a le résoudre …
A propos de ton noyau que tu as compilé, tu as bien activé les options nécessaires pour netfilter/iptables ?
Oui… et ça, j’en suis certain vu que j’ai encore les sources et la configuration que j’ai utilisé pour compiler… je suis pas le seul à avoir ce problème … c’est assez embêtant
Que contient le fichier /proc/net/ip_tables_names (s’il existe) ?
Que rapporte la commande /sbin/modinfo avec les modules ip_tables et iptable_nat ?
cat /proc/net/ip_tables_names
filter
/sbin/modinfo ip_tables
filename: /lib/modules/3.1.5-20111215/kernel/net/ipv4/netfilter/ip_tables.ko
description: IPv4 packet filter
author: Netfilter Core Team <coreteam@netfilter.org>
license: GPL
depends: x_tables
vermagic: 3.1.5-20111215 SMP mod_unload modversions
/sbin/modinfo iptable_nat
ERROR: modinfo: could not find module iptable_nat
zsh: exit 1 /sbin/modinfo iptable_nat
Je suis en train de me dire que j’ai pas du tout cocher dans les paramètres avancées d’iptables…
hello
certaine version d’iptables son incompatible avec certaine version du kernel…et c’est si mes souvenir en relation avec la libc*
la seul la doc de netfilter peut aider.
Ceci dit, si tu ne comptes pas faire de NAT, tu n’as pas besoin de la table nat, et donc de commandes qui y font appel.
C’est vrai que je peux me limiter aux commandes filter ^^ …
Que pensez vous de ce script :
(J’ai volontairement modifié les ports 42 pour ssh et 20-41 pour ftp)
EDIT: je viens de le lancer sur mon serveur … ca me coupe tout(ssh et http mort) alors que sur mon serveur de test tout passe … je ne comprend pas vraiment là
[code]#!/bin/sh
BEGIN INIT INFO
Provides: Firewall
Required-Start: $local_fs $remote_fs $syslog $network
Required-Stop: $local_fs $remote_fs $syslog $network
Default-Start: 2 3 4 5
Default-Stop: 0 1 6
Short-Description: Initialisation du Firewall
Description: Lance l intitialisation du Firewall
END INIT INFO
portsentry -audp
portsentry -atcp
On vide toutes les r.gles avant d’appliquer les nouvelles.
iptables -F
iptables -X
iptables -Z
On r.initialise les tables.
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT
iptables -t filter -P INPUT ACCEPT
Bloque tout le trafic
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
on se prot.ge des scan de port
iptables -t filter -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
Protection SYN flood
iptables -t filter -A INPUT -p tcp --syn -m limit --limit 5/s -j ACCEPT
iptables -t filter -A INPUT -p udp -m limit --limit 10/s -j ACCEPT
Protection ping flood
iptables -t filter -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -t filter -A INPUT -p icmp --icmp-type echo-reply -m limit --limit 1/s -j ACCEPT
Protection ping flood
iptables -t filter -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -t filter -A INPUT -p icmp --icmp-type echo-reply -m limit --limit 1/s -j ACCEPT
Ping
iptables -t filter -A OUTPUT -p ICMP -j ACCEPT
iptables -t filter -A INPUT -p ICMP -j ACCEPT
Autorise les connexions d.j. .tablies et localhost
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
SSH
iptables -t filter -A INPUT -p tcp --dport 42 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 42 -j ACCEPT
DNS
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
#FTP
iptables -t filter -A OUTPUT -p tcp --dport 41 -j ACCEPT
Serveur Web
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
whois
iptables -t filter -A OUTPUT -p udp --dport 43 -j ACCEPT
NTP (horloge du serveur)
iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT
[/code]
J’ai pas tout regardé en détail mais à première vue il y a des choses qui ne me plaisent pas. Commentaire détaillé à venir.
Ce script a un en-tête LSB de script d’init mais n’en a pas la structure (cf. /etc/init.d/skeleton) : il ne tient pas compte de l’action start|stop|reload… passée en paramètre et effectue les même actions dans tous les cas.
Inutile de régler les politiques par défaut à ACCEPT pour les régler à DROP immédiatement après.
Les diverses règles de “protection” sont mal placées ou mal écrites : elles acceptent des paquets entrants sans autre considération de protocole, port… court-circuitant les règles ultérieures autorisant seulement certains protocoles et ports. Il faut soit bloquer les paquets au-delà de la limite, soit appliquer les règles de ports etc. au trafic en-deça de la limite, ce qui revient au même.
Les règles de suivi de connexion (ESTABLISHED,RELATED) devraient se trouver en début de chaîne. Celles relatives à l’interface de loopback aussi, à moins qu’on veuille filtrer le trafic entre processus locaux.
Il y a un doublon des règles de “protection ping flood”. D’autre part la règle limitant les ICMP echo-reply n’a pas grand intérêt. Les réponses au ping unicast sont dans l’état ESTABLISHED. Donc cette règle ne sert que pour les réponses au ping broadcast (qui ne devraient pas être nombreuses puisque désactivées par défaut sur les OS récents y compris Linux).
La paire de règles sous le commentaire “Ping” porte bien mal son nom : elle autorise sans limite les paquets ICMP de n’importe quel type et pas seulement le ping (types echo-request et echo-reply), et rend totalement inutiles les limitations des règles précédentes.
Le protocole DNS peut utiliser le port 53 en TCP aussi et pas seulement en UDP.
Le protocole FTP n’utilise pas que le port de commande (21 par défaut, ici 41). Le module de suivi de connexion FTP nf_conntrack_ftp permet de reconnaître les connexions de données à la volée. Mais si on utilise un port non standard pour la connexion de commande, alors il faut spécifier ce port au module lors de son chargement, car par défaut il ne surveille que le port 21.
Les règles sous le commentaire “Serveur web” sont en sortie, donc autorisent les connexions sortantes. Pour un serveur il faudrait plutôt autoriser les connexions entrantes.