Crash iptable

Creaprog · Le 23/01/2014, à 20:29

Bonsoir,

J'ai un VPS sous debian 7, et je souhaite configuré iptables mais je constate un problème !

#!/bin/sh

# Réinitialise les règles
iptables -t filter -F
iptables -t filter -X
echo 'Reinitialisation des regles'

# Bloque tout le trafic
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
echo 'Bloquage du trafic'

# 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
echo 'Autorisation des connexions deja etablies et localhost'

# ICMP (Ping)
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
echo 'Autorisation ICMP'

# SSH
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT
echo 'Autorisation SSH'

#HTTP
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
echo 'Autorisation HTTP'

J'exécute :

/etc/init.d/firewall
Reinitialisation des regles

Ensuite tous les ports se ferme. Plus aucun moyen de se connecter.

Dernière modification par Creaprog (Le 24/01/2014, à 18:58)

tiramiseb · Le 24/01/2014, à 21:27

Salut,

Tout d'abord, une question : pourquoi bricoler un script avec iptables alors que tu peux utiliser ufw ?

Ensuite, à ta place j'essaierais d'abord de ne pas bloquer les paquets sortants, le problème vient peut-être de là.
Par ailleurs, pourquoi autorises-tu les paquets sortants avec les ports de destination 22 et 80 ?

Zakhar · Le 24/01/2014, à 22:02

tiramiseb a écrit :

Salut,
Tout d'abord, une question : pourquoi bricoler un script avec iptables alors que tu peux utiliser ufw ?

Si je tente une réponse à sa place, moi j'aime bien éviter d'installer des trucs dont je vais me servir 2 fois alors que la ligne de commande suffit. On n'est pas sur Windaube non ?

tiramiseb a écrit :

Par ailleurs, pourquoi autorises-tu les paquets sortants avec les ports de destination 22 et 80 ?

Je me pose la même question !
Pour le port 80 :

Creaprog a écrit :

#HTTP
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT

... on pourrait imaginer qu'il a installé un proxy HTTP qui nécessiterait ça, mais pour le 22 je sèche.

tiramiseb · Le 24/01/2014, à 22:36

Zakhar a écrit :

tiramiseb a écrit :
Salut,
Tout d'abord, une question : pourquoi bricoler un script avec iptables alors que tu peux utiliser ufw ?
Si je tente une réponse à sa place, moi j'aime bien éviter d'installer des trucs dont je vais me servir 2 fois alors que la ligne de commande suffit. On n'est pas sur Windows non ?

Ufw, s'en servir deux fois ? Une fois installé et activé, on s'en sert à chaque fois qu'on veut changer une règle de pare-feu. Il est également utilisé systématiquement à chaque démarrage du système.

Avec un script bricolé à la main, on fait quelque chose de basique et on doit gérer intelligemment les différentes règles, ne pas se planter, etc. Je sais de quoi je parle, je faisais ça il y a 10 ans, quand il n'y avait pas d'autre solution
Avec Ufw, des règles par défaut assez sympa sont mises en place et la gestion des ouvertures de ports est très simplifiée.
Si on a vraiment besoin d'un pare-feu de serveur (c'est-à-dire pas un pare-feu de réseau), il n'y a aucune raison de ne pas l'utiliser.

Zakhar a écrit :

tiramiseb a écrit :
Par ailleurs, pourquoi autorises-tu les paquets sortants avec les ports de destination 22 et 80 ?
Je me pose la même question !

En réalité j'ai un début de réponse dans ma tête : il confond port source et port destination.

...
Et puis déjà qu'un pare-feu pour les paquets entrants, sur une machine bien installée, ça ne sert à rien... Alors pour les paquets sortants, vraiment je ne vois pas l'intérêt de se faire chier avec ça (sauf cas très particuliers)...

Zakhar · Le 24/01/2014, à 23:23

tiramiseb a écrit :

En réalité j'ai un début de réponse dans ma tête : il confond port source et port destination.

Oui c'est ce que j'imagine aussi.

Pour le reste, je ne suis pas admin de serveur (sauf de ma Syno, mais ça compte pas !).
Donc pour le peu de règles dont j'ai besoin, sur un PC protégé par une box en routeur, le script me suffit.

... mais il est vrai que là on nous parle de serveur.

P.S.: en plus maintenant il va falloir apprendre nftables (je suis en train de lire !)... si ça se trouve UFW va être adapté pour les utiliser (je ne pas du mode compatibilité iptables bien sûr)

Dernière modification par Zakhar (Le 24/01/2014, à 23:43)

tiramiseb · Le 25/01/2014, à 10:02

Donc pour le peu de règles dont j'ai besoin, sur un PC protégé par une box en routeur, le script me suffit.

Sur un PC protégé par une box en routeur, un pare-feu est totalement inutile.

Et quand on en veut tout de même un, ufw reste plus simple à utiliser qu'un script bricolé à la main

Creaprog · Le 25/01/2014, à 11:50

J'utilise le port 22 pour le ssh sinon je ne vais pas pouvoir me connecter. Mon serveur est pas en localhost.

Je n'est pas utiliser Ufw pour la bonne raison que je ne connaissais pas jusqu’à aujourd'hui XD.

Zakhar · Le 25/01/2014, à 13:34

tiramiseb a écrit :

Donc pour le peu de règles dont j'ai besoin, sur un PC protégé par une box en routeur, le script me suffit.
Sur un PC protégé par une box en routeur, un pare-feu est totalement inutile.

Oui et non... ça dépend en fait !

Avec une Freebox, tu es susceptible d'utiliser la FreeWifi (même sur un Desktop qui ne bouge pas !). Dans ce cas tu n'es plus en "mode routeur", et par précaution :

iptables -A INPUT -i wlan+ -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i wlan+ -j DROP

Pas de quoi fouetter un chat !

Creaprog a écrit :

J'utilise le port 22 pour le ssh sinon je ne vais pas pouvoir me connecter. Mon serveur est pas en localhost.
Je n'est pas utiliser Ufw pour la bonne raison que je ne connaissais pas jusqu’à aujourd'hui XD.

OK, mais c'est ce qu'on essayait de te dire plus haut.

Tu as besoin d'autoriser le 22 entrant puisque c'est un serveur, mais le 22 sortant ne te sert à rien... à moins que tu ne veuilles faire du rebond ssh à partir de ce serveur !

Dernière modification par Zakhar (Le 25/01/2014, à 13:38)

Creaprog · Le 25/01/2014, à 13:40

Il faut bien communiquer ?

Quand je communique il faut bien parler et avoir une réponse. Si j'autorise que l'entrée, comment je peux avoir les messages d'erreur ?

Mon serveur ne se trouve pas chez moi, mais dans un datacenter.

Dernière modification par Creaprog (Le 25/01/2014, à 13:43)

tiramiseb · Le 25/01/2014, à 14:08

Creaprog a écrit :

Il faut bien communiquer ?
Quand je communique il faut bien parler et avoir une réponse. Si j'autorise que l'entrée, comment je peux avoir les messages d'erreur ?

Oui mais attention, tu confonds port source et port destination.

Mettons que C est le client et S est le serveur.
C se connecte au port 22 sur S (port destination = 22). Il utilise alors un port source aléatoire (par exemple et totalement au hasard, 12842).
S répond alors à C, avec comme port source le port 22 et comme port destination le port 12842 (ou n'importe quel port aléatoire selon ce qu'a choisi C).

Là, tu autorises les flux entrants avec le port destination 22 et les flux sortants avec le port destination 22 : le flux sortant avec le port destination 22 est inutile.

Pour les réponses, tu autorises normalement déjà les connexions "ESTABLISHED" (connexions déjà établies, donc les réponses directes) et les connexions "RELATED" (qui ont un lien avec une connexion déjà établie).

Creaprog · Le 25/01/2014, à 17:08

Je ne comprend pas, le serveur communique comment ?
Il faut bien un truc qui sort l'autre et qui rentre.

C = client
S = Serveur

C => S via le port 22 Entrant
C <=S via le port 22 Sortant
http://fr.openclassrooms.com/informatiq … e-firewall

Sinon :

#!/bin/sh

# Réinitialise les règles
iptables -t filter -F
iptables -t filter -X
echo 'Reinitialisation des regles'

# Bloque tout le trafic
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
echo 'Bloquage du trafic'

# 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
echo 'Autorisation des connexions deja etablies et localhost'

# ICMP (Ping)
iptables -t filter -A INPUT -p icmp -j ACCEPT
echo 'Autorisation ICMP'

# SSH
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
echo 'Autorisation SSH'

#HTTP
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
echo 'Autorisation HTTP'

Toujours le même problème.

Dernière modification par Creaprog (Le 25/01/2014, à 17:39)

tiramiseb · Le 25/01/2014, à 18:02

C => S via le port 22 Entrant
C <=S via le port 22 Sortant

Toi tu ne parles que d'un seul port, là.

Ce qu'il se passe, c'est ça :

C => S, port source aléatoire, port destination 22
S => C, port source 22, port destination idem au-dessus

Toi pour les paquets sortants, tu as mis l'option "--dport 22" (port de destination 22), ce qui n'est pas correct : la destination n'est pas 22, c'est le fameux port aléatoire.
Tu pourrais le remplacer par "--sport 22" (port source 22), mais c'est inutile car tu as les règles "RELATED,ESTABLISHED".

Toujours le même problème.

Ben oui, je ne disais pas que ça résoudrait ton problème, je disais que ce que tu avais mis c'est inutile.

Par contre, ce que j'ai écrit (en #2), c'est : « à ta place j'essaierais d'abord de ne pas bloquer les paquets sortants ».
C'est-à-dire mettre la "policy" en OUTPUT à ACCEPT et non à DROP :

iptables -t filter -P OUTPUT ACCEPT

Tu as essayé ça ?

Autre truc que tu peux essayer : mettre toutes les policies en "ACCEPT" (au lieu de DROP, dans les lignes qui contiennent le "-P") ; oui ça ne bloquera rien, mais tu pourras voir s'il n'y a pas un problème lors de l'exécution des commandes qui suivent. Il sera toujours temps de changer les policies...

----------

Note en passant que "-t filter" n'est pas nécessaire car "filter" est la table par défaut.

----------

Par ailleurs, je viens de survoler le tutoriel que tu as donné en lien, il est truffé d'erreurs, je te déconseille de t'y fier.

Je note notamment les énormités suivantes :
- le placement d'un script lambda (sans gestion des arguments "start", "stop" ni "restart") dans /etc/init.d ;
- le "--dport" en entrant et en sortant (ce dont on vient de parler) ;
- la phrase suivante : « Vous pourriez me dire qu’il suffirait de n’écrire qu’une seule fois la ligne sans préciser l’argument -A... mais suivant notre politique de précision, ce serait une erreur car il existe d’autres valeurs que INPUT et OUTPUT pour lesquelles nous ne voulons pas permettre le trafic » => eh bien non, ce serait une erreur car ça ne marcherait pas, il FAUT dire à iptables dans quelle chaîne mettre une règle (INPUT, OUTPUT...) et il FAUT dire où la mettre (-I = au début, -A = à la fin).
Je n'ai pas + approfondi, ces horreurs me suffisent pour être convaincu qu'il faut te dire de chercher de l'aide ailleurs. On dirait que c'est écrit par un débutant qui n'a même pas testé ni réfléchi sur ce qu'il a écrit...

En dehors de la lecture de ce mauvais tutoriel, as-tu lu d'autres documents ? Notamment la documentation officielle d'iptables ou au moins sa page de manuel ?

tiramiseb · Le 25/01/2014, à 18:10

Pour info, l'équivalent avec ufw :

1/ tu ne fais pas de script, tout se gère tout seul
2/ tu exécutes la commande suivante pour définir l'autorisation sur le port 22 :

ufw allow 22/tcp

... ou alors :

ufw allow OpenSSH

3/ tu exécutes la commande suivante pour activer le pare-feu :

ufw enable

4/ rien d'autre, nada, c'est fini, le pare-feu est en place

Tu pourras en lire plus à ce propos dans l'article que j'ai écrit dans Linux Pratique numéro 73 il y a un peu plus d'un an (http://boutique.ed-diamond.com/linux-pr … -lp73.html) ou alors simplement sur la page idoine de la doc : http://doc.ubuntu-fr.org/ufw.

Dernière modification par tiramiseb (Le 25/01/2014, à 18:11)

Creaprog · Le 25/01/2014, à 21:04

Merci cela semble marcher sauf que j'ai ceci :

iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.

ufw se configure tous seul ? Comment ça se fait ?

tiramiseb · Le 25/01/2014, à 21:38

Creaprog a écrit :

Merci cela semble marcher sauf que j'ai ceci :
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.

Il faut voir quelles lignes retournent ces erreurs. Exécute le fichier de la manière suivante :

sh -x /etc/init.d/firewall

(avec sudo devant si tu utilises sudo)

Creaprog a écrit :

ufw se configure tous seul ? Comment ça se fait ?

Qu'appelles-tu "se configurer tout seul" ?

ufw est un logiciel de gestion de pare-feu, une surcouche d'iptables. Il est constitué de :
- un ensemble de règles par défaut (blocage par défaut des flux entrants, etc)
- une commande (« ufw ») qui enregistre les règles que tu lui soumets et qui les applique immédiatement
- un script de démarrage qui rétablit les règles que tu as configurées au démarrage de la machine

Creaprog · Le 26/01/2014, à 10:10

sh -x /etc/init.d/firewall
+ iptables -t filter -F
+ iptables -t filter -X
+ iptables -t filter -p INPUT DROP
iptables v1.4.14: unknown protocol "input" specified
Try `iptables -h' or 'iptables --help' for more information.
+ iptables -t filter -p FORWARD DROP
iptables v1.4.14: unknown protocol "forward" specified
Try `iptables -h' or 'iptables --help' for more information.
+ iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables: No chain/target/match by that name.
+ iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables: No chain/target/match by that name.

Après le reste marche correctement. Merci effectivement on voit les erreurs . Mais comment les résoudre ?

Dernière modification par Creaprog (Le 26/01/2014, à 12:10)

tiramiseb · Le 26/01/2014, à 15:45

Creaprog a écrit :

+ iptables -t filter -p INPUT DROP
iptables v1.4.14: unknown protocol "input" specified
Try `iptables -h' or 'iptables --help' for more information.
+ iptables -t filter -p FORWARD DROP
iptables v1.4.14: unknown protocol "forward" specified
Try `iptables -h' or 'iptables --help' for more information.

Le "P" doit être en majuscule et non en minuscule.

Par ailleurs j'avais suggéré de remplacer "DROP" par "ACCEPT" le temps de ce test, pour que tu ne te fasses pas jeter... tu as transformé le "-P" en "-p" ?

Creaprog a écrit :

+ iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables: No chain/target/match by that name.
+ iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables: No chain/target/match by that name.

Alors là, je suis perplexe. Ces commandes sont bonnes.

As-tu un noyau Debian par défaut ou un noyau spécial ?
Que donnent ces commandes ?

uname -a
lsmod | grep conntrack
ls /proc/net/*conntrack*
grep CONNTRACK /boot/config-$(uname -r)

Zakhar · Le 26/01/2014, à 18:19

tiramiseb a écrit :

Creaprog a écrit :

+ iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables: No chain/target/match by that name.
+ iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables: No chain/target/match by that name.

Alors là, je suis perplexe. Ces commandes sont bonnes.

Si ça peut aider, la dernière fois que j'ai fait ça sur une Fedora, il a râlé très fort en me disant que j'étais un dinosaure parce que -m state est "deprecated" et qu'il faut maintenant utiliser conntrack.

C'était Fedora 18. Alors effectivement, si ça se trouve sur les dernières Fedora ça ne marche plus du tout -m state !

(J'imagine que c'est pour ça que tu lui fais faire des grep sur conntrack !)

Dernière modification par Zakhar (Le 26/01/2014, à 18:21)

tiramiseb · Le 26/01/2014, à 18:23

Zakhar a écrit :

[...] si ça se trouve sur les dernières Fedora [...]

Oui menfin là on parle de Debian hein...

Pour info j'ai testé les commandes sur mon serveur sous Debian et elles fonctionnent bien.

Creaprog · Le 26/01/2014, à 18:39

root@creaserv:~# uname -a
Linux creaserv 2.6.32-23-pve #1 SMP Tue Aug 6 07:04:06 CEST 2013 i686 GNU/Linux
root@creaserv:~# lsmod | grep conntrack
root@creaserv:~# ls /proc/net/*conntrack*
/proc/net/nf_conntrack  /proc/net/nf_conntrack_expect
root@creaserv:~# grep CONNTRACK /boot/config-$(uname -r)
grep: /boot/config-2.6.32-23-pve: No such file or directory

Pourquoi remplacer DROP par ACCEPT ?

Dernière modification par Creaprog (Le 26/01/2014, à 18:40)

tiramiseb · Le 26/01/2014, à 18:50

Pourquoi remplacer DROP par ACCEPT ?

Pour ne pas te faire jeter lorsque tu exécutes le script, afin de pouvoir visualiser les erreurs comme tu l'as fait là.

root@creaserv:~# uname -a
Linux creaserv 2.6.32-23-pve #1 SMP Tue Aug 6 07:04:06 CEST 2013 i686 GNU/Linux

Ok, donc ton VPS est géré par Proxmox. (suffixe "pve") C'est donc soit une machine virtualisée avec KVM, soit une machine OpenVZ. Il est possible que le module conntrack, nécessaire pour ces règles, ne soit pas disponible avec le noyau que te propose ton hébergeur.

Qui est cet hébergeur ?

Creaprog · Le 26/01/2014, à 19:12

Secu-web, il utilise Openvz.

Dernière modification par Creaprog (Le 26/01/2014, à 19:41)

tiramiseb · Le 26/01/2014, à 20:29

Ok, ils n'ont en effet peut-être pas activé toutes les options qui vont bien pour te permettre de faire du filtrage...

Tu peux probablement contacter le support pour leur dire que tu n'as pas le module ip_conntrack dans ton noyau et que tu coup tu ne peux pas activer le pare-feu comme tu le souhaites...

Voir là pour la manière d'activer ce module (à faire par l'hébergeur sur leur hôte, bien que je doute qu'ils changent leur politique de sécurité pour un seul client) : http://www.readymakers.com/blog/how-to- … container/

Dernière modification par tiramiseb (Le 26/01/2014, à 22:41)

Creaprog · Le 26/01/2014, à 22:34

Je ne comprend pas comment Openvz et Proxmox puisse perturber le fonctionnement de iptables ?

tiramiseb · Le 26/01/2014, à 22:52

Bah le pare-feu (*) fait partie du noyau : si le noyau auquel on te donne accès n'inclut pas la fonctionnalité dont tu as besoin, eh bien tu n'aura pas accès à cette fonctionnalité...

(*) : pour être exact, le pare-feu de Linux s'appelle Netfilter, iptables étant "simplement" la commande permettant de le gérer.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 23/01/2014, à 20:29

Crash iptable

#2 Le 24/01/2014, à 21:27

Re : Crash iptable

#3 Le 24/01/2014, à 22:02

Re : Crash iptable

#4 Le 24/01/2014, à 22:36

Re : Crash iptable

#5 Le 24/01/2014, à 23:23

Re : Crash iptable

#6 Le 25/01/2014, à 10:02

Re : Crash iptable

#7 Le 25/01/2014, à 11:50

Re : Crash iptable

#8 Le 25/01/2014, à 13:34

Re : Crash iptable

#9 Le 25/01/2014, à 13:40

Re : Crash iptable

#10 Le 25/01/2014, à 14:08

Re : Crash iptable

#11 Le 25/01/2014, à 17:08

Re : Crash iptable

#12 Le 25/01/2014, à 18:02

Re : Crash iptable

#13 Le 25/01/2014, à 18:10

Re : Crash iptable

#14 Le 25/01/2014, à 21:04

Re : Crash iptable

#15 Le 25/01/2014, à 21:38

Re : Crash iptable

#16 Le 26/01/2014, à 10:10

Re : Crash iptable

#17 Le 26/01/2014, à 15:45

Re : Crash iptable

#18 Le 26/01/2014, à 18:19

Re : Crash iptable

#19 Le 26/01/2014, à 18:23

Re : Crash iptable

#20 Le 26/01/2014, à 18:39

Re : Crash iptable

#21 Le 26/01/2014, à 18:50

Re : Crash iptable

#22 Le 26/01/2014, à 19:12

Re : Crash iptable

#23 Le 26/01/2014, à 20:29

Re : Crash iptable

#24 Le 26/01/2014, à 22:34

Re : Crash iptable

#25 Le 26/01/2014, à 22:52

Re : Crash iptable

Pied de page des forums