[Iptables] Besoin d'aide à sa configuration

Support Debian
#1

Bonjour,

en voulant jouer avec iptables, et je ne suis pas très doué dans ce domaine, j’ai rendu mon serveur dédié kimsufi inaccessible. J’ai chrooté depuis le mode rescue et iptables -L me donne:

[quote]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[/quote]

Petite question: Si je comprend bien, tout ce qui rentre (INPUT), se fait redirigé vers un service sur mon serveur (FORWARD) ou sort (OUTPUT) est accepté sans chercher à comprendre.

Pourtant, ce qui fait que mon serveur est inaccessible (selon moi) via via SSH était que j’utilisais un port différent et que je n’ai pas su rediriger le 22 sur le port que j’avais choisit. Or je ne vois pas de règles supplémentaire dans mes tables (quote plus haut, désolé si je me trompe de terme je ne suis pas encore bien habitué à iptables).

Je rappel que je suis bien dans le chroot lorsque je tape la commande.

Avez-vous une idée?

Koshicalement

#2

Salut,
oui, tout st accepté: INPUT, OUTPUT et FORWARD.

Quand tu dis avoir joué avec iptables, c’est avec un script, ou juste avec des lignes de commandes ?
Si c’est le second cas, c’est normal que ce soit perdu.

Au minimum, il faut un iptables-saves quand tu as terminé de définir tes règles, puis au redémarrage du système un iptables-restore, sinon, iptables reprend à zéro: les règles sont vides…

#3

Non. La chaîne FORWARD ne voit passer que les paquets reçus et retransmis vers une autre destination, lorsque la machine fonctionne en routeur (rien à voir avec une redirection). Les paquets reçus et redirigés vers des services locaux passent dans la chaîne INPUT, comme tous les autres paquets reçus destinés aux processus locaux. Si ton serveur ne fait pas routeur (VPN routé par exemple), alors tu n’as pas besoin de t’occuper de la chaîne FORWARD, elle ne voit aucun trafic.

C’est confus. Qu’entends-tu exactement par rediriger ?

Les chaînes sont vides parce que ton serveur est dans le mode rescue. Tu as seulement monté et éventuellement chrooté la partition racine, cela n’a pas exécuté les scripts de démarrage normal. Recherche ton fichier de règles iptables et/ou ton fichier de configuration de sshd et corrige-les.

#4

Après avoir constaté que sur mon système je n’avais pas /etc/sysconfig où semble se trouver le fichier de config d’iptables, j’ai trouvé sur le wiki de debian à propos d’iptables mon bonheur je pense.

Je créer en gros le fichier et je l’actives, je vérifie que ça fait bien ce que je veux et je redémarre le système.

Et c’est là que j’ai besoin de vos conseils:

_ Si je comprend bien FORWARD ne sert que lorsqu’on utilise sa machine comme routeur. J’envisageai un de ses quatre d’utiliser ce dédié comme VPN, donc je finirai bien par y toucher à un moment ou à un autre. Mais pour l’instant, est-ce sûr d’autoriser le FORWARD? Je sais que par principe il faut interdire ou désactiver ce qui ne sert pas.

_ Je dois déterminer quels sont les services qui vont tourner et accepter l’INPUT et l’OUTPUT pour tout ces services pour qu’ils fonctionnent bien.

Je pense qu’en faisant un petit peu attention et en lisant bien la doc du wiki de Debian je devrais m’en sortir.

De plus j’ai vu l’option flush (-F) qui permettra sûrement de purger la config pour repartir sur une base saine.

Et j’avais tenté de configuré via des commandes mes modifications et je crois bien avoir utilisé la commande pour les sauver.

D’autres suggestions?

Merci pour vos réponses !

#5

Si tu as fait des modifs, redonne-nous
NON PAS
iptables -L
MAIS
iptables-save

#6

Salut,

Salut,
Tu as peut-être sauvegardé, mais si tu ne “restore” pas au démarrage, ça ne sert à rien… D’où l’utilité d’un script.

#7

Debian n’utilise pas /etc/sysconfig, c’est spécifique à d’autres distributions (souvent dérivées de RedHat). Iptables n’est pas un service ni un démon, il n’a pas de fichier de configuration. Par contre les gestionnaires de règles iptables (“pare-feux”) comme shorewall, ufw, iptables-persistent… ont des fichiers de configuration spécifiques à chacun. Il peut aussi y avoir un simple script de création du jeu de règles iptables, mais toi seul sais ce que tu as installé.

Est-ce la même machine que celle de la discussion sur mumble, qui semblait utiliser ufw comme générateur de règles iptables ? Si oui et si tu veux gérer toi-même les règles iptables, il faut d’abord désinstaller ou désactiver ufw. Qu’as-tu modifié pour rendre ton serveur inaccessible ?

FORWARD : Tu peux lui définir une politique par défaut à DROP et la laisser vide, même si aucun paquet ne peut passer dans cette chaîne tant que net.ipv4.ip_forward (routage IP) n’est pas activé.

Commande flush (-F) : si tu appliques le wiki Debian, tu n’en as pas besoin car iptables-restore écrase le jeu de règles précédent. Ce n’est utile que si on injecte les règles une par une avec des commandes iptables dans un script shell, avec -X pour supprimer ensuite les chaînes définies par l’utilisateur. A faire pour chaque table.

#8

Bonjour,

Je fais un script qui réinitialise les règles et crée les nouvelles règles. A chaque fois je lance le script et je vérifie que je peux toujours me connecter au serveur. En cas de problème un reboot du serveur et les règles sont annulées.
Lorsque le script est au point, je fais en sorte que les règles soient activées au démarrage. J’utilise pour ca le fichier interfaces en mettant “up /sbin/iptables-restore < /etc/firewall/ip4tables.conf” pour l’interfaces eth0 (/etc/firewall/ip4tables.conf est créer par iptables-save).

Pour la mise au point, j’avais ajouter en fin du script :

iptables -t filter -A INPUT -j LOG --log-prefix "IPTables : input : " iptables -t filter -A FORWARD -j LOG --log-prefix "IPTables : forward : " iptables -t filter -A OUTPUT -j LOG --log-prefix "IPTables : output : "
pour voir les flux bloqués et ajouter des règles si nécessaire.

#9

Okay je comprend mieux. En fait iptables c’est une série d’instruction qu’on doit envoyer à chaque démarrage de la machine (d’où le script, dans /etc/init.d/ je présume).

@PascalHambourg oui c’est la même machine pour mon serveur mumble (le problème découle même directement de là :smiley:).

Comme je ne connais pas bien iptables et que j’aimerai combler cette lacune il serait intéressant que je me sépare d’ufw pour gérer à la mano iptables, ça me fera pas de mal je pense.

@mazarini comme je fais aussi du bash je vais m’amuser à essayer de scripter quelque chose aussi alors, ce qui est intéressant et évitera que mon serveur soit inaccessible est que je pourrai vérifier que tout marche comme je le souhaite?

Par exemple au démarrage du script les règles sont lancés, puis un test (?) est effectué pour vérifier que ce que je désire est toujours accessible, sinon le serveur redémarre sans que ce script soit pris en compte afin de le dépanner?

Merci pour vos réponses, Koshicalement

#10

[quote=“koshie”]Okay je comprend mieux. En fait iptables c’est une série d’instruction qu’on doit envoyer à chaque démarrage de la machine (d’où le script, dans /etc/init.d/ je présume).

@PascalHambourg oui c’est la même machine pour mon serveur mumble (le problème découle même directement de là :smiley:).

Comme je ne connais pas bien iptables et que j’aimerai combler cette lacune il serait intéressant que je me sépare d’ufw pour gérer à la mano iptables, ça me fera pas de mal je pense.

@mazarini comme je fais aussi du bash je vais m’amuser à essayer de scripter quelque chose aussi alors, ce qui est intéressant et évitera que mon serveur soit inaccessible est que je pourrai vérifier que tout marche comme je le souhaite?

Par exemple au démarrage du script les règles sont lancés, puis un test (?) est effectué pour vérifier que ce que je désire est toujours accessible, sinon le serveur redémarre sans que ce script soit pris en compte afin de le dépanner?

Merci pour vos réponses, Koshicalement[/quote]

Tu présumes bien.

Si tu veux t’instruire sur Iptables, fais une recherche double :
par mot clef : iptables
par auteur : PascalHambourg
le tout dans la section "support Debian"
Tu en as … 32 pages :005
Pascal est le Maître incontesté et, je crois, incontestable en matière de “Ipatbles”.

Mais méfie-toi de lui, il est “méchant” et snob :laughing:

#11

Bonjour,

Je me suis servi de ce lien pour mes bases iptables : alsacreations.com/tuto/lire/ … ables.html (j’ai suivi tout le tuto en fait lorsque j’ai configuré mon premier serveur)

Par contre, j’ai préféré lié l’activation des règles à l’activation de l’interface eth0 qui communique avec l’extérieur plutôt qu’utiliser un script de /etc/init.d. A priori, le firewall est actif en même temps que l’interface et ca doit être mieux.

Il y a fail2ban qui utilise aussi iptables. Ton script de mise au point va supprimer les règles de fail2ban. Il faut donc penser à les rétablir à l’occasion (restart de fail2ban) et ne pas sauver les règles en même temps que celle de fail2ban.

#12

Bonsoir,

J’ai essayé le lien de Mazarini, et lorsque j’ai fais un iptables-save j’ai eu:

[code]# Generated by iptables-save v1.4.14 on Sun Apr 28 21:36:30 2013
*raw
:PREROUTING ACCEPT [21144]
:OUTPUT ACCEPT [20939:3164056]
COMMIT

Completed on Sun Apr 28 21:36:30 2013

Generated by iptables-save v1.4.14 on Sun Apr 28 21:36:30 2013

*nat
:PREROUTING ACCEPT [51:7589]
:INPUT ACCEPT [37:3341]
:OUTPUT ACCEPT [125:9067]
:POSTROUTING ACCEPT [125:9067]
COMMIT

Completed on Sun Apr 28 21:36:30 2013

Generated by iptables-save v1.4.14 on Sun Apr 28 21:36:30 2013

*mangle
:PREROUTING ACCEPT [21144]
:INPUT ACCEPT [21130]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [20941:3164560]
:POSTROUTING ACCEPT [20941:3164560]
COMMIT

Completed on Sun Apr 28 21:36:30 2013

Generated by iptables-save v1.4.14 on Sun Apr 28 21:36:30 2013

*filter
:INPUT ACCEPT [21130]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [20944:3165148]
COMMIT
[/code]

Et désormais j’ai ssh configuré sur le port 22.

Mais mon serveur redémarre toujours en RESCUE… Une idée?

Koshicalement

#13

Entre balises de code plutôt que de citation, ce serait mieux. Toutes les tables sont chargées et toutes les chaînes sont vides et ouvertes. Il faut un tutoriel pour en arriver là ?

[quote=“koshie”]Mais mon serveur redémarre toujours en RESCUE… Une idée?
[/quote]
Ce n’est pas toi qui décides de redémarrer en mode rescue sur l’interface de gestion ?

#14

Salut,

Si mon serveur démarre en mode RESCUE c’est parce qu’en le hard-rebootant depuis OVH manager, il est détecté que mon serveur n’est plus accessible après le boot et donc OVH le reboot en mode RESCUE et m’envoit de quoi me connecter par e-mail.

J’en conclus donc que ce n’est pas encore une configuration correcte. Sinon je ne recevrais pas d’e-mail à propos du RESCUE.

pix.toile-libre.org/?img=1367236930.png

–

Si c’est pour souligner “que je fais de la merde”, c’était franchement pas la peine, si j’ai mal compris excuse-moi :slightly_smiling:.

Y’a t’il quelque chose dans mon output qui vous fasse penser que mon serveur serait innaccessible? Voici le /etc/init.d/firewall :

[quote]#!/bin/sh

BEGIN INIT INFO

Provides: firewall

Required-Start: mountkernfs ifupdown $local_fs

X-Start-Before: networking

Default-Start: 2 3 4 5

Required-Stop:

Default-Stop: 0 1 6

Short-Description: Configure the iptables firewall.

Description: Configure the iptables firewall.

END INIT INFO

Vider les tables actuelles

iptables -t filter -F

Vider les règles personnelles

iptables -t filter -X

Interdire toute connexion entrante et sortante

iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

—

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

Autoriser loopback

iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

ICMP (Ping)

iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT

—

SSH In

iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT

SSH Out

iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT

DNS In/Out

iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT

NTP Out

iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT

HTTP + HTTPS Out

iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT

Mumble

iptables -I INPUT -p tcp --dport 64738 -j ACCEPT
iptables -I INPUT -p udp --dport 64738 -j ACCEPT
[/quote]

#15

Salut,
Juste pour être certain (désolé), tu es sur d’être sur hd dans le netboot ?

Edit, je dis ça parce que je ne crois pas que mon serveur sera rebooté par OVH s’il est inaccessible (manquerait plus que ça… :mrgreen: ). Et d’ailleurs, ça peut boucler sans fin une histoire comme ça… Donc ça m’étonne vraiment.

#16

Je vais me renseigner sur le site d’OVH, mais voici le genre de mail que je reçois:

[quote]Bonjour,

Votre serveur a redémarré en mode ‘Rescue’ ; cela signifie qu’un
Linux/BSD est lancé sur votre serveur via le réseau. Il ne s’agit pas
du système qui est normalement installé sur votre serveur, aucune
de vos partitions n’est d’ailleurs montée.

Une interface web est disponible pour vous permettre d’effectuer un
diagnostique de votre serveur (disque dur, raid, ram, CPU) et de
parcourir l’arborescence de votre système de fichiers:
XXXXXXXXXXX:XX

  • nom d’utilisateur : root
  • mot de passe : *****

Vous pouvez également vous connecter en SSH à votre serveur (XXXXXXXXXX)
avec les paramètres suivants:

  • user : root
  • mot de passe : *****

Vous pouvez dès à présent effectuer les opérations de maintenance
nécessaires au rétablissement de votre serveur, à titre d’exemple,
vous pouvez:

  • vérifier et mettre à jour vos fichiers de configuration réseau,
  • vérifier et éventuellement désactiver votre firewall,
  • vérifier et mettre à jour votre LILO (ou bien configurer un autre
    boot via le réseau : guides.ovh.com/KernelNetboot/
  • procéder à la vérification manuelle de votre système de fichiers,
  • effectuer une sauvegarde ou une restauration de données,
  • etc.

Si vous pensez avoir identifié l’origine du problème et souhaitez
redémarrer votre serveur normalement, vous devez configurer le
’netboot’ de votre serveur sur le disque dur ou sur un noyau OVH:
guides.ovh.com/KernelNetboot/ puis rebooter votre serveur
en SOFT (évitez de rebooter via le manager).

Vous trouverez des informations complémentaires dans notre guide:
guides.ovh.com/ModeRescue/

Cordialement,

Support Client OVH
Support Technique : 08.99.49.87.65 (1,349 Euro/appel + 0,337 Euro/min)
Support Commercial : 08.20.69.87.65 (Numéro Indigo 0,118 Euro/min)
Fax : 03.20.20.09.58
E-mail : support@ovh.com
Du lundi au vendredi : 8h00 - 20h00
Le samedi : 9h00 - 17h00
[/quote]

De plus le mode “hard reboot” semble être un simple reboot physique (alimentation) de la machine, rien de plus.

Voici ce que j’ai au niveau du boot sur l’OVH Manager: pix.toile-libre.org/upload/origi … 244500.png

#17

koshie, je me suis permis de cacher l’IP qui était en clair, par des ‘XXX’.
Sinon, tu risques de voir pas mal de tentatives de connexion sur fail2ban.
Toutefois, si tu tiens à les replacer, tu es libre bien sûr.

#18

J’avais par principe de le faire avant, mais parfois sur certains logs les infos «sensibles» sont trop nombreuses et je faisais tellement de découpage que je finissais par cacher des infos… Mais pour le mail j’aurai pu le faire oui. Mais en cherchant sur le forum on retrouve l’IP assez facilement.

Merci :slightly_smiling:.

#19

Source: guides.ovh.com/ModeRescue

Bon, j’aurai pu rebooter mon serveur dix fois que ça n’aurait rien changé. Donc si je comprend bien le rescue se lance quand mon serveur est innacessible mais il faut manuellement relancer son serveur en mode “hd”.

Au passage: Je ne suis plus en rescue!

Merci à tous !

#20

Salut,
Je ne crois vraiment pas qu’il y ait de mode automatique de reboot (je n’ai rien vu de tel dans le manager). Si ça existe, montre moi l’option. Moi ça me ferais vraiment chi** qu’il re-démarrent ma machine sans me demander mon avis.
Et d’ailleurs, il m’est arrivé d’avoir des règles iptables empêchant ovh de scruter et “pinguer” la machine, il ne s’est rien passé (pas de reboot).

Tu as modifié le boot (netboot au lieu de hd) et tu as “oublié” de remettre sur hd; A chaque demande de reboot, tu t’es retrouvé en netboot…