Digression Installation parefeu (iptables & ip6tables) "pour les nuls"

Support Debian
#361

Re,

J’ai ma réponse… :wink:

#362

Si tu mets la commande iptables-restore dans une option pre-up au lieu de post-up, les règles iptables seront mises en place avant le démarrage de l’interface. Un défaut éventuel, c’est que la mise en place des règles iptables par ce moyen reste tributaire de l’activation d’une interface particulière.

#363

Salut,

J’ai rajouté ça à mon script, histoire d’avoir un aperçu de l’ensemble des tables.

... status) # Liste des tables echo echo "---------- TABLE 'FILTER' ----------" echo /sbin/iptables -t filter -L -v echo echo "---------- TABLE 'NAT' -----------" echo /sbin/iptables -t nat -L -v echo echo "---------- TABLE 'MANGLE' ----------" echo /sbin/iptables -t mangle -L -v echo ;; ... echo "Usage: $0 {start|stop|restart|clean|status}" ...

#364

iptables-save ne suffit pas ?

#365

S’il te suffit tant mieux… :wink:

Là tu as d’un coup:

Essaye tu verras la différence.

#366

Justement, iptables-save sans argument affiche d’un coup toutes les règles de toutes les tables, dans un format détaillé à la fois plus compact et plus lisible AMA car plus proche de la syntaxe de création des règles.

Accessoirement, ton bout de script a deux défauts supplémentaires par rapport à iptables-save :

  • il manque la table ‘raw’,
  • si une table n’est pas chargée car pas utilisée, ‘iptables -t -L’ force inutilement son chargement ; tu peux l’éviter en testant sa présence dans /proc/net/ip_tables_names (ou plus malin, en faisant une boucle sur le contenu de ce fichier). A noter que c’est aussi un défaut des scripts de réinitialisation “aveugles” qui peuvent avoir le même effet.
#367

[quote=“PascalHambourg”]Justement, iptables-save sans argument affiche d’un coup toutes les règles de toutes les tables, dans un format détaillé à la fois plus compact et plus lisible AMA car plus proche de la syntaxe de création des règles.

Accessoirement, ton bout de script a deux deux défauts supplémentaires par rapport à iptables-save :

  • il manque la table ‘raw’,
  • si une table n’est pas chargée car pas utilisée, ‘iptables -t -L’ force inutilement son chargement ; tu peux l’éviter en testant sa présence dans /proc/net/ip_tables_names (ou plus malin, en faisant une boucle sur le contenu de ce fichier). A noter que c’est aussi un défaut des scripts de réinitialisation “aveugles” qui peuvent avoir le même effet.[/quote]

    J’ai rajouté la table RAW, merci du rappel.
    J’aime bien avoir des détails sur le trafic qui passe par chaque règle:

    Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 3445 302K fail2ban-ssh ...

#368

iptables-save peut aussi afficher les compteurs avec l’option -c.

#369

Je capitule… :laughing:

#370

:laughing: :laughing: :laughing:
Pour une fois que j’ai “bon”
tiens, j’en rajoute une couche :
:dance: :dance: :dance:

#371

Moi pas :violence-fencing: :laughing:
le default d’iptables save, c’est le numéro de la ligne :slightly_smiling: plus facile pour ce reperer dans un script . de plus tu as des commentaire avec l’heur et la date …

# Completed on Fri Jun 10 18:49:33 2011
# Generated by iptables-save v1.4.5 on Fri Jun 10 18:49:33 2011

ce qui peux etre pénible si on veux filtrer avec grep sure certin caractère :stuck_out_tongue: .
[size=85](on est vendredi :smiley: )[/size]

par contre pour ce qui est de la table raw ,je vien d’apprendre quelque chose :023

#372

Les lignes de commentaire, ça se filtre facilement.

#373

Salut,
J’essaye de “loguer” les paquets qui passent par mes règles iptables, et je n’arrive à pas grand chose…

J’ai tout d’abord séparé les logs iptables de kern pour les mettres dans iptables.log (rsyslog). C’est plus clair.

Par contre je ne logue que les paquets sur les ports 137 et 138… C’est pas terrible.

Voici un extrait de mon iptables-save

# Generated by iptables-save v1.4.8 on Mon Jun 13 17:26:06 2011 *filter :INPUT DROP [17:1438] :FORWARD DROP [0:0] :OUTPUT ACCEPT [2928:544236] :fail2ban-ssh - [0:0] :log_table - [0:0] ... Ensemble des règles (ACCEPT) ... -A log_table -j LOG --log-prefix "iptables: " --log-level 6 COMMIT

Je ne comprend pas comment faire pour tout loguer (Accept, Drop et Forward)
Merci de vos conseils.

#374

Re,
Est-ce que la solution ne serait pas de créer une table pour chaque "règle"
Du genre:

iptables -N LOGACCEPT > /dev/null 2> /dev/null iptables -F LOGACCEPT iptables -A LOGACCEPT -j LOG --log-prefix "ACCEPT " iptables -A LOGACCEPT -j ACCEPT

Puis

Je ne sais pas si c’est bon…
Et je coince pour le FORWARD et le DROP…

#375

moi je fait:

1 les police a drop
2, les regle qui von bien
3 je log tout avec ulog ,comme sa sa va pas dans les fichier systeme

iptables -A INPUT  -j  ULOG --ulog-prefix="Entree "

voila simple , si t’a trop d’entrée tu peux limiter avec le module -m limit, c est même préférable pour eviter de saturer le serveur.
seulement pafois sa déconne ,probablement parce que la règle est pas bonne.

		#iptables -A INPUT -m limit --limit-burst 4 --limit 4/hour -j  ULOG --ulog-prefix="Entree "
		#iptables -A OUTPUT -m limit --limit-burst 1 --limit 1/hour -j  ULOG --ulog-prefix="Sortie "
		#iptables -A FORWARD -m limit --limit-burst 1 --limit 1/hour -j  ULOG --ulog-prefix="Forward "

si tes règle son bien faite tu devrai avoir peux d’entrée dans les log :slightly_smiling:

#376

Une chaîne définie par l’utilisateur, pas une table.
En fait une pour chaque cible terminale que tu utilises :
ACCEPT -> logaccept
DROP -> logdrop
REJECT -> logreject
REJECT --reject-with tcp-reset -> logrejectrst
etc.

Les chaînes définies par l’utilisateur peuvent être appelées depuis n’importe quelle chaîne de la table à laquelle elles appartiennent, donc aussi bien une des chaînes de base INPUT, OUTPUT, FORWARD ou une chaîne définie par l’utilisateur. Il faut bien sûr terminer les chaînes de base par une règle appelant une chaîne logxxx, sinon les paquets atteignant la fin de la chaîne seront traités par la politique par défaut sans être loggés.

Par contre, tout logger n’est pas forcément utile, sauf pour faire des tests. C’est un coup à se faire inonder de logs…

#377

[quote=“PascalHambourg”]Par contre, tout logger n’est pas forcément utile, sauf pour faire des tests. C’est un coup à se faire inonder de logs…[/quote]J’ai vu c’est plusieurs Mo à la minute…

[quote=“PascalHambourg”]Une chaîne définie par l’utilisateur, pas une table.[/quote]Oui une chaine, pardon.

Je “crois” avoir à peu près saisi. Ça donnerais:[code]
:LOGFWD - [0:0]
:LOGIN - [0:0]
:LOGOUT - [0:0]
…
-A INPUT -i lo -j LOGOUT
-A INPUT -m state --state RELATED,ESTABLISHED -j LOGOUT
-A INPUT -s 10.9.8.254/32 -p udp -m udp --dport 1812:1814 -j LOGOUT
…
-A LOGFWD -j LOG --log-prefix "FORWARD --REJECT "
-A LOGFWD -j DROP
-A FORWARD -j LOGFWD

-A LOGIN -j LOG --log-prefix "INPUT --REJECT "
-A LOGIN -j DROP
-A INPUT -j LOGIN

-A LOGOUT -j LOG --log-prefix "OUTPUT --ACCEPT "
-A LOGOUT -j ACCEPT
[/code]

Est-ce qu’avec les deux dernières lignes je ne fais pas double emploi avec les règles au dessus ? (pour freeradius pas exemple)
Je crois que ma règle “LOGOUT” est ok, mais pour les autres (forward et input) je nage dans le brouillard… iptables ne peut pas savoir que c’est du forward ou du input…

C’est à des fin de test évidemment.
Mes règles iptables (sans mes essais de logs) semblent fonctionner, mais comment vérifier… J’ai du mal à trouver l’outil qui va bien.

Purée je souffre… :017 :005

@Panthère: Je regarderais ULOG quand je “maîtriserais” un peu mieux iptables…

#378

Je ne comprends pas la logique de nommage et d’utilisation de ces chaînes.
Pourquoi appeler LOGOUT une chaîne appelée depuis la chaîne INPUT ?
Pourquoi appeler d’une part LOGOUT une chaîne qui ACCEPTe et d’autre part LOGIN et LOGFWD des chaînes qui DROPpent ?
Pourquoi mettre REJECT dans le préfixe alors que la cible est DROP ?

AMA la première chose à faire avant de pondre des règles, c’est de définir ce que tu veux logger dans le préfixe : la chaîne de base d’origine (ce n’est pas indispensable, on peut la déduire des informations in= et out=), la cible appliquée ?

#379

[quote=“PascalHambourg”]
Par contre, tout logger n’est pas forcément utile, sauf pour faire des tests. C’est un coup à se faire inonder de logs…[/quote]

moi sa ne me derange pas vraiment puisque je met -m limit --limit-burst 1 --limit 1/hour mai evidament on peux affiner avec un port et/ou une ip.
et puis si sa vien a faire ramer la machine il suffi de suprimer la règle .

Lol ulog ce charge juste de mettre les entrée ailleur c’est donc plus simple , si si :wink:

#380

Bonjour,
Effectivement ce n’était pas clair mon affaire… Aussi brumeux que dans mon esprit.
La nuit m’a permis d’y voir plus clair.

:LOGIN - [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [812:365500] ... -A INPUT -i lo -j LOGIN -A INPUT -m state --state RELATED,ESTABLISHED -j LOGIN -A INPUT -s 10.9.8.254/32 -p udp -m udp --dport 1812:1814 -j LOGIN ... -A LOGIN -m limit --limit 1/min --limit-burst 4 -j LOG --log-prefix "RULE 1: --ACCEPT " -A LOGIN -j ACCEPT -A FORWARD -j LOG --log-prefix "RULE 2: --FORWARD " -A OUTPUT -m limit --limit 1/min -j LOG --log-prefix "RULE 3: --OUTPUT "

J’ai un dernier doute…
Les paquets entrants qui ne passent pas par la règle “LOGIN” ils sont quand même acceptés dans ma configuration ?
Il faut que j’ajoute un -A INPUT -j DROP après ?

Merci panthère pour le -m limit :023
Au moins j’ai le temps d’arrêter les logs si ça prend de l’ampleur…