Le Forum Non Officiel de la DEDIBOX
Vous n'êtes pas identifié.
Je vous met un site tres bien fait avec une bonne explication du fonctionnement d'iptables, le programme qui gere les regles de filtrage et de routage du noyeau sous linux.
http://christian.caleca.free.fr/netfilter/iptables.htm
une autre page tres bien faite
http://lea-linux.org/cached/index/Resea … ables.html
voilà.
je suis à votre disposition si vous avez des questions ![]()
Dernière modification par mobyfab (2006-05-04 15:17:35)
Hors ligne
Merci beaucoup. Etant plutôt du genre nioubi, je sens que j'aurais rapidement une envie irrépressible de poser des questions. Enfin dès que ma Dedibox sera opérationnelle ![]()
Ciao,
LoneCat
Hors ligne
Tout en rappelant que si vous activez l'IPtables avec rejet des paquets (iptables -P INPUT DROP) avant d'avoir paramétré les ouvertures, vous perdrez définitivement accès à votre serveur donc attention..

Hors ligne
Définitivement ? On peut quand même réinstaller le serveur non ? ou utiliser la console d'urgence ?
Hors ligne
un petit reboot et tout ira bien...
à moins que vous ayez définit les regles avec webmin, qui recharche le firewall au boot...
Hors ligne
Suite à une petite erreur de configuration dans mes iptables, je me retrouve sans possibilité d'accès à ma dedibox.
Y aurait-il moyen qu'un technicien la redémarre sans firewall, que je puisse reprendre la main pour régler le problème ?
Merci
Hors ligne
J'ai réussi à régler le problème grâce au mode rescue...
Béni soit le mode rescue ! ![]()
Dernière modification par openhoat (2006-05-06 15:36:42)
Hors ligne
à mon avis c'est possible de demander à un technicien mais faut pas etre préssé...
sinon pour les firewall, il faut TOUJOURS s'assurer de ne pas scier la branche sur laquelle on est !
en metant par exemple une regle qui autorise tous les access par votre ip ![]()
le minimum avant de passer les polices en DROP :
- autoriser tout trafic au provenance et en destination de votre ip (regles dans INPUT et OUTPUT)
- autoriser le port 22 en tcp (SSH)
- autoriser le port 10000 en tcp (webmin)
- on peu aussi autoriser les requetes icmp, pour le monitoring automatique par ping
Hors ligne
Tout à fait, j'ai beau le savoir, et être habitué à administrer des serveurs Linux, je suis tombé dans le panneau...
Shame on me :s
Hors ligne
Puis n'appliquer les règles que pendant un certain temps tant que c'est pas validé.
Hors ligne
Calimero a écrit:
Puis n'appliquer les règles que pendant un certain temps tant que c'est pas validé.
oui bien sur, à chaque fois il faut verifier que tout fonctionne comme on le souhaite avant de rajouter des regles...
ça parait évident mais il faut le préciser ![]()
Hors ligne
Hors ligne
Bonsoir à tous ![]()
J'avoue etre un peu depassé par les iptables... j'ai parcouru les differentes docs mais j'ai du mal à savoir par où commencer...
Y-a-t'il un b-a-ba ?? ou quelques conseils pour commencer ?
comment savoir quel est l'etat des iptables sur mon serveur ? que faut-il proteger d'urgence ? les ports 10000 et 22 sont-ils proteges en standard ou faut-il s'en occuper ?
bref je suis un peu paumé... des questions simples peut-etre, mais bon... c'est pas tres clair pour moi ![]()
Hors ligne
Rien n'est protégé en standard.
Personnellement quand j'arrive sur un serveur je suis toujours ça :
# vi /etc/init.d/firewall
#!/bin/bash echo Setting firewall rules... # # config de base # # vidage iptables -t filter -F iptables -t filter -X # avant tout : autoriser SSH iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT # ne pas casser les connexions etablies iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # interdire toute connexion entrante iptables -t filter -P INPUT DROP iptables -t filter -P FORWARD DROP # interdire toute connexion sortante iptables -t filter -P OUTPUT DROP # autoriser les requetes DNS, FTP, HTTP (pour les mises a jour) iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT # autoriser loopback iptables -t filter -A INPUT -i lo -j ACCEPT iptables -t filter -A OUTPUT -o lo -j ACCEPT # Refuser ping iptables -t filter -A INPUT -p icmp -j DROP # # gestion des connexions entrantes autorisées # # iptables -t filter -A INPUT -p <tcp|udp> --dport <port> -j ACCEPT # http, https iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT # ftp iptables -t filter -A INPUT -p tcp --dport 20 -j ACCEPT iptables -t filter -A INPUT -p tcp --dport 21 -j ACCEPT
# chmod +x /etc/init.d/firewall
# update-rc.d firewall start 01 2 .
Ensuite je paufine mon /etc/init.d/firewall, et je le lance
le plus important c'est d'avoir autorisé le SSH entrant et les connexions déjà établies, afin d'être sûr de ne pas perdre le contrôle du serveur.
Le script sera relancé à chaque reboot du serveur, histoire de ne pas predre ces règles en cas de reboot intempestif (hard reboot du à une coupure électrique, ou une maintenance du staff, par exemple).
Dernière modification par naholyr (2006-05-16 00:36:14)
Hors ligne
super ! merci pour ta reponse claire et... hyper rapide ![]()
j'ai cree le fichier firewall avec ton code et suivi tes indications. no problem.
maintenant j'ai plus qu'à decortiquer tout çà pour bien comprendre ! mais dans l'ensemble ca donne des bases assez claires.
mais d'abord... gros dodo !!! ![]()
Hors ligne
Attention, j'ai édité mon message précédent il y avait 2 erreurs dans le script :
- la chaine INPUT,OUTPUT est invalide (j'avais tapé ça de tête, erreur...)
- plus grave : la règle sur l'état ESTABLISHED,RELATED doit être ajoutée pour OUTPUT. En effet puisque je bloque les connexions sortantes, dans le cas de SSH (par exemple) le client envoie une requête sur le port 22 au serveur, elle est réceptionnée, mais le serveur ne peut pas répondre (puisque l'OUTPUT est bloqué par défaut) et la connexion n'est jamais établie. Cette règle permet d'autoriser le serveur à répondre à toute requête qui a été initialisée par le client (et donc autorisée en INPUT).
Donc gare à ne pas appliquer ce script sans l'avoir testé sur un serveur à la maison (de l'intérêt de l'entrainement).
Dernière modification par naholyr (2006-05-16 00:40:31)
Hors ligne
salut Naholyr,
J'ai fait les modifs merci ![]()
Mais la becane est toujours visible avec un ping.
D'un autre coté je pouvais toujours me connecter et intervenir sur le serveur en ssh avant ton edit sur le code... de meme pour le port 10000 : il n'est pas ouvert et pourtant je me connecte sur webmin sans pb..
j'ai raté une etape ou quoi ??? j'ai besoin de rebooter la becane pour que le script soit actif ??? il me semble qu'il ne fait pas son boulot... ![]()
Hors ligne
iptables -L pour lister les règles, histoire de voir si tout ce qui doit être en place... est bien en place.
Hors ligne
j'obtiens çà :
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
... ca me semble un peu leger... je replonge dans les docs !
Hors ligne
C'est qu'il y a 0 règles, là. On peut effectivement considéré que c'est léger. ![]()
Hors ligne
pourtant j'ai appliqué à la lettre les definitions de naholyr... le fait d'enregistrer le fichier firewall suffit ? ne faut-il pas déclarer ce fichier iptables quelques part pour que le serveur le prenne en compte ?
bon avant de poser plus de questions je prendre le temps de bien me documenter... mes suppositions ne vont pas m'amener à grand chose !
Hors ligne
Lien intéressant: IpTables par l'exemple sur Lea-Linux.
Ciao,
LoneCat
Hors ligne
dfuzion a écrit:
pourtant j'ai appliqué à la lettre les definitions de naholyr... le fait d'enregistrer le fichier firewall suffit ? ne faut-il pas déclarer ce fichier iptables quelques part pour que le serveur le prenne en compte ?
bon avant de poser plus de questions je prendre le temps de bien me documenter... mes suppositions ne vont pas m'amener à grand chose !
Comme on le voit, le fichier proposé par naholyr est un script shell.
Une fois créé (avec soin !) il faut le rendre exécutable:
$ chmod 700 monscript.sh
puis l'exécuter pour que les règles soient appliquées (c'est à dire que la commande iptables soit appelée pour chaque règle)
$ ./monscript.sh
Dans un premier temps, je ne le mettrais pas dans init.d/rcX.d, pour que justement il ne s'applique pas au démarrage. Comme ca, si tu te rates, tu vas dans ta console dedibox et tu lances un reboot de ta machine et hop plus de règles de filtrage.
Attention au copier/coller entre le forum et un fichier via putty/SSH. Tu risques d'avoir des retours à la ligne mal placés, etc...
C'est pour cà que je commenterais les lignes suivantes (ou je mettrais ACCEPT à la place de DROP) dans le fichier pour les premiers lancements du script:
iptables -t filter -P INPUT DROP iptables -t filter -P FORWARD DROP # interdire toute connexion sortante iptables -t filter -P OUTPUT DROP
Ca supprime le filtrage (vu qu'on accepte tous les paquets du coup), mais ca permet de voir si toutes les règles sont bien en place et qu'on n'a pas d'erreur de syntaxe dans le fichier. Ca permet d'inspecter avec iptables -L la gueule des règles pour voir si ca semble OK.
Une fois que c'est bon, on décommente ces lignes pour remettre le filtrage par défaut puis on réapplique les règles à la main en relançant le script. Si tout beigne, on peut alors les rajouter au boot.
Hors ligne
Le script est prévu pour se lancer au reboot de la machine oui, donc si tu ne rebootes pas il faut le lancer une première fois manuellement :
# /etc/init.d/firewall
Par contre moi je teste toujours un script sur un serveur virtuel (vmware) chez moi avant de l'appliquer en production, j'ai une peur panique du "je perds le contrôle de ma machine bêtement parce que j'ai mis une règle qu'il fallait pas".
Dans cet ordre d'idée, il vaut mieux d'ailleurs lancer le script, voir si on a toujours la main sur la machine, et enfin faire l'appel à update-rc.d. Si jamais on perd la main on lance un reboot soft et on recommence. Si on a mis le script en démarrage on est bon pour le mode rescue ![]()
Hors ligne