Reprise du message précédent :
mouais, cruel dilemme?
 
D'un côté grace à conntrack, la plupart des règles utiles ne sont matchées que la première fois à l'ouverture de connexion.
Mais bon en même temps l'ouverture de connexion c'est important.
Et si on considère que le but d'un serveur web, c'est de servir le plus rapidement possible les pages il vaut peut-être mieux mettre l'accent sur les règles utiles.
 
MAIS, je ne peux pas les mettre à la fin, car le paquet invalide risquerait d'être accepté avant par une de mes règles utile.
 
 
EDIT : grillé par l0ky

 
Le traitement n'est pas si lourd pour 1 paquet dans une connexion. La chaine que j'utilise ne contient pas non plus des milliers de règles.

On est d'accord, de toute façon si je les mets à la fin elles ne servent vraiement à rien.
et tu veux pas la faire péter ta chaine?
 
y'a un truc que je capte pas avec les chaines, en gros c'est une sorte de fonction, et donc même si la chaine est définie après les chaines principale, elle est qd même appellée avant (puisque tu l'appelle juste après les règles sur les paquets ESTABLISHED).
 
C'est juste une manière de faire un script plus propre alors?
 
 
 
EDIT : l'interêt c'est que tu peux y faire passer que certains paquets, genre uniquement les paquets en INPUT sur l'interface $INTERNET?

mes scripts sont chez moi
je suis au boulot et je n'ai pas accès à mon Firewall depuis ici. Tu pourras les avoir que dimanche soir si tu es patient jusqu'à la

je suis patient, mais c'est plus maarant d'essayer de les refaire en confrontant nos idées. Le but de ce topic (enfin c'est comme ça que je le vois), c'est de créer un script iptables nickel pour un serveur, et aussi de servir de tuto, car toutes les questions que j'ai posé je dois pas être le seul à me les poser...

Les chaines tu les crées au moment ou tu exécute ton scripts. Il faut voir iptables comme un outils de configuration de netfilter. Lorsque tu crées une chaine via iptables -N toto la chaine est crée tout de suite durant l'exécution de ton script.
 
Ensuite tu lui envois les paquets avec -j

du moins ca permet d'effctuer un traitement que sur des paquets prédéterminer.

ok, en même temps dans mon cas, et vu les règles que j'ai, je vais y faire tout passer (même le traffic du réseau local) sauf les règles OUTPUT et les connexions déjà établies, c'est vraiment interessant niveau perfs?
 
 
 
EDIT : le but étant de faire un truc propre, je vais modifier mon script en ce sens

c'est fait, j'ai crée une chaine CHECK_VALID qui n'est appellée que pour les paquets en INPUT et je l'appelle après les règles sur l'interface loopback, ça me semble cohérent.

mets ta règle -N CHECK_VALID au moment de l'initialisation (au tout début, avant les policy)

ok, mais pourquoi? j'ai vu des scripts où elle était initialisée au moment de l'utilisation, c'est juste pour que ce soit plus lisible?

bah si tu vais un -j CHECK_VALID sans qu'il y ait de chaine CHECK_VALID  dans la table il va pas aimer
au pire tu le mets juste avant le -j CHECK_VALID. Pour moi ca fait partit de l'initialisation de netfilter

tu l'as pas vu mais je l'ai déjà mis, à la ligne 73.
 
J'essaie juste de comprendre si ça a une importance autre que la lisibilité.

tu fais un -j à la ligne 23 et un -N à la ligne 73.
à la ligne 23 ta chaine n'est pas encore créer, il va t'envoyer chier

ok, je change ça et je le mets au début, je vais en profiter pour mettre les règles sur les prétendues connexions du réseau locales dans une chaine aussi...

voilà, c'est fait :
 
- les déclarations sont aux lignes 18 et 19 (après les policy car je trouve ça + logique)
- les appels se font aux lignes 30 à 35 (RESERVED_NET_CHECK est appellée 2 fois ce qui m'a permis de diviser le nombre de lignes dans la chaine par 2)
- les chaines sont définies à la fin

bah alors, y'a plus personne?
 
me dites pas qu'il n'y a pas de connerie qd même
 
Il manque bien quelque chose...

En même temps il y a des gens qui mangent à midi

ah oui c'est vrai, j'avais oublié
 
bon j'vais aller chercher à manger aussi

j'ai ajouté une variante pour le ftp qui n'autorise que le trafic sortant vers un serveur de mises à jours (security.debian.org dans mon exemple).
 
j'ai ajouté des commandes non relatives à iptables à la fin pour activer des protections réseau
 
 
J'ai constaté que sur le guide de sécurisation debian, les règles pour les ouvertures de ports ne contenaient pas -m state --state NEW, pourtant ils utilisent bien la règle suivante en début de script :

 
 
je me demande si ce flag est vraiment nécessaire...

Si tu fais un script au sens script, tu pourrais utiliser les variables et les boucles pour générer les lignes à executer. Par exemple PORT_SERVER="25 80 110 143" ou regarde le contenu de Arno ya des bonnes options qui servent aussi pour les serveurs

 
Sans le flag ca marchera mais bon...

Oui je le ferais si tout les services utilisaient les mêmes règles, mais ce n'est pas le cas.
Regarde bien, les règles pour ssh, http et ftp sont différentes par exemple.
 
En le faisant service par service, je garde le contrôle et si je veux changer quelques chose pour tel port sur telle interface je peux le faire.
 
J'avais regardé le script d'Arno, et c'est pour ça que j'ai décidé de ne pas l'utiliser, pas assez souple...

 
mais bon, c'est pas beau c'est ça?
C'est vrai qu'on ferais moins le lien entre les premières lignes ESTABLISHED et les lignes NEW, dans l'optique d'un truc didactique c'est mieux avec le flag, mais je me demandais simplement si ça marcherait

Ben ça dépend des services mais c'est obligé que quand tu fasses un serveur (cad qq de disponible à tous) les règles soient identiques à la différence des ports.
Après tu peux faire des règles spécifique (ou des modèles de règles spécifique) pour ouvrir un port qu'à une ip ou sous réseau ou if.
Par exemple un serveur http, mail (smtp, pop, imap), ssh, dns tu pourrais faire:
 
PORT_OUVERT="80 25 110 143" et PORT_SPEC_OUVERT="eth1>22 192.168.0.0/24>53"
 
 
Sinon on oublie souvent quelque chose dans la sécurité : ne pas faire écouter ses daemons n'importe où. Par exemple si le serveur ftp doit être local ben on va pas lui faire écouter sur son interface publique mais uniquement sur l'interface LAN. Là du coup ya même pas de risque.

y'a encore moins de risque à ne pas avoir de serveur ftp
 
En tout cas faire en sorte que les serveurs n'écoutent que sur l'interface dont ils ont besoin, je le fais déjà, et c'est ce que j'essaie de transposer dans ce script aussi.

ce n'est pas la question c'est juste un exemple, j'aurais pu dire dns si tu préfères on s'en fou

ya encore moins de risque en débranchant l'alimentation aussi

ce n'était qu'un exemple, d'où le smiley
 
Sans débrancher l'alim, on peut débrancher le cable réseau c'est moins radical

Si tu n'utilise pas la chaine FORWARD, tu peux laisser la regles par defaut (DROP).
 
Tu peux aussi rajouter des regles de log avec ULOG

oui effectivement, je n'utilise pas FORWARD, mais je me demande, dans quel cas l'utiliser?
 
Genre si je dois contrôler le trafic qui rentre sur l'interface locale puis sort sur l'interface internet? Sur un serveur ça ne doit pas être très utile.
 
 
 
En ce qui concerne les logs, comme chacun fait à sa sauce, je ne vais pas les mettre dans ce script.

 
Normalement un serveur ne devrait pas router de trafic.
Normalement le firewall ne devrait pas se trouver sur le serveur.

La chaine FORWARD peut servir a partager la connexion, rediriger certains ports pour des services tournant derriere le firewall. Je ne pense pas que tu ai a t'en servir mais ca peut être necessaire si tu fais ecouter un de tes services sur l'interface local mais que tu veux y acceder aussi par l'interface web (ce n'est qu'un exemple, ca n'a pas d'interet AMHA)

Pourtant c'est plus utile
Au moins LOG

 
Donc ok avec sebchap pour virer les règles FORWARD, je vais par contre laisser echo 0 > /proc/sys/net/ipv4/ip_forward car ça désactive explicitement le forwarding.
 
En ce qui concerne le fait que le firewall soit sur le serveur, l'explication est donnée au premier post, c'est une 2è ligne de défense.

 
 
Non ça c'est la table nat, la chaine forward dans la table filter sert à autoriser ou pas au moment du routage les paquet à transiter.
par exemple iptables -I FORWARD -p tcp --dport 80 -i eth1 -j ACCEPT (et la chaine inverse) pour autoriser les machines de eth1 à envoyer des paquets vers le port 80 à l'extérieur du réseau.

y'a pas un commande magique pour LOGger tous les paquets DROPped?

  je confonds a chaque fois. Decidemment, j'ai bien fais de participer a ce topic, ca va me remettre les idées au clair

tu rajoute en derniere position une commande pour logguer tout ce qui est droppé (à la fin de la chaine OUTPUT et INPUT)
mais regarde du coté de -m limit pour pas que tes log explosent.

on peut logger et dropper dans la même règle? Tout les scripts que j'ai vu nécessitaient 2 règles

Ils n'avaient pas un -m limite par hasard ?