iptables sans conntrack

jejeman · Le 15/12/2015, à 17:37

Bonjour,
Je viens de prendre un serveur "dédié" chez godaddy avec ubuntu 14.04
Mais en fait il n'est pas si dédié que ça puisque à part CPU, ram et disk, le reste est virtualisé et du coup je n'ai pas accès aux modules du kernel.
Je suis en train de configurer iptables pour sécuriser le serveur et je voudrais notamment accepter les connection dont l'état est established
Or pour cela, il a besoin d'avoir le module conntrack activé sur le kernel et j'ai l'impression que ce n'est pas le cas.
Comment configurer proprement iptables sans conntrack ?
Merci de votre aide.

pires57 · Le 15/12/2015, à 18:18

Conntrack peut être utilisé sur n'importe quel machine linux, VM compris.
Une VM incorpore le système complet, je ne vois donc pas ou es le problème

robindesbois · Le 16/12/2015, à 00:23

Salut, tu peux utiliser -m state --state à la place de -m conntrack --ctstate dans tes règles, ça dépanne très bien en attendant, à plus.

bruno · Le 16/12/2015, à 10:55

Bonjour,

D'abord je ne te comprends pas ton histoire de serveur. C'est un serveur dédié ou un serveur privé virtuel (VPS) ?
Dans un cas comme dans l'autre tu as un système d'exploitation complet et autonome.

Tu dis que tu n'as pas accès aux modules du noyau. C'est effectivement possible car de nombreux hébergeurs installent les distributions Linux avec un noyau monolithique (c'est à dire, compilé sans la prise en charge des modules) « maison » et non le noyau fournit par la distribution.

robindesbois · Le 16/12/2015, à 11:22

Cela dit c'est vrai qu'il faut que le module conntrack soit activé pour que tes règles qui contiennent "conntrack" passent, ça c'est sûr, mais comme dit au dessus, "state" fait très bien le travail aussi, et pas besoin de module d'activé pour lui, tcho !

mazarini · Le 16/12/2015, à 11:26

Il me semble que certaines solution de virtualisation démarre les vm avec le noyau de l’hôte. Ca doit être le cas de xen lorsque l'on ne choisit pas le démarrage via pygrub en mode para-virtualisation. Je ne connais pas les autres solutions de virtualisation mais j'ai déjà eu des problèmes avec un vps OVH et un vps gandi il y a quelques années.
Un indice serait de vérifier la présence d'un noyau dans /boot et de /boot/grub/menu.lst.

jejeman · Le 17/12/2015, à 12:53

Bonjour et merci à tous pour vos réponses.
Alors il s'agit d'un serveur dédié (dedicated server), mais ils proposent aussi des serveurs virtuel (virtual private server).
Après échange avec le support, c'est eux qui gère l'image de la distrib qu'ils mettent et donc tu ne peux pas gérer les modules chargés par le kernel.
Dans mon cas, je voudrai sécuriser l'accès avec iptables :
- autoriser le traffic sortant
- autoriser le traffic HTTP entrant
- autoriser que mon PC en SSH

Voici ce que me donne iptables au départ :

~$ sudo iptables -nvL --line-number
Chain INPUT (policy ACCEPT 19884 packets, 2062K bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 4951 packets, 530K bytes)
num   pkts bytes target     prot opt in     out     source               destination

Je veux autoriser les connexions entrantes déjà établies et ça bloque avec state

~$ sudo iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables: No chain/target/match by that name.

Alors que ça, ça passe :

~$ sudo iptables -A INPUT -p tcp -s xxx.xxx.xxx.xxx --dport 22 -j ACCEPT

Sur ce site http://www.inetdoc.net/guides/iptables- … gging.html ils disent que ça bloque si le module n'est pas chargé dans le noyau
Et comme j'ai pas accès au noyau, je me posais la question...
Mais peut-être que je suis dans le faux...
Merci de votre aide.

robindesbois · Le 17/12/2015, à 14:56

Donner des portions de règles ne va pas nous aider Jejeman, il faut que tu nous donnes tes règles complètes, sinon on ne peut pas te trouver les erreurs. Comme ça, je ne peux rien te dire par exemple (là c'est comme si tu me montrais les phares d'une voiture mise ne vente sur le bon coin, en me disant : "Alors tu l'achètes, elle est en super état (state...)"), c'est pas possible. @ plus...

bruno · Le 17/12/2015, à 15:16

Comme je le disais tu as probablement un noyau monolithique fournit par ton hébergeur. Pour voir la version du noyau :

uname -a

En principe rien ne t'empêche d'installer un autre noyau.

Concernant iptables, il faudrait effectivement expliquer pourquoi et comment tu veux configurer ton pare-feu. Sachant que dans 99% des cas c'est totalement inutile sur un serveur isolé (Il y a déjà de nombreuses discussion sur le forum à ce sujet…)

jejeman · Le 17/12/2015, à 16:38

Alors voilà les infos noyau :

~$ uname -a
Linux sxxx-xx-xxx-xxx.secureserver.net 3.13.0-042stab111.11 #1 SMP Tue Sep 1 18:19:12 MSK 2015 x86_64 x86_64 x86_64 GNU/Linux

Pour robindesbois, c'est un serveur web essentiellement que je veux mettre en place. Donc au niveau des règles autoriser mon PC a accèder en SSH, ouvrir les ports 80 et 443 pour le web pour tout le monde, ouvrir le port 3306 pour mon PC pour mysql et bloquer tout le reste. J'ai déjà un autre serveur qui fait globalement la même chose et dont voici les règles que j'ai mis en place.

Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      266  195K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
2      611 64140 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
3        0     0 ACCEPT     tcp  --  *      *       XX.XX.XX.XXX         0.0.0.0/0           tcp dpt:22 flags:0x17/0x02
4        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:2121
6        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:40000:40100
7       51  2652 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 flags:0x17/0x02
8        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443
9        1    60 ACCEPT     tcp  --  *      *       XX.XX.XX.XXX         0.0.0.0/0           tcp dpt:3306
10       2   168 ACCEPT     icmp --  *      *       XX.XX.XX.XXX         0.0.0.0/0
11      17  2932 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `Reject INPUT packets '
12      17  2932 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      940  578K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW,RELATED,ESTABLISHED
2        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `Reject OUTPUT INVALID packets'

Mon problème est que lorsque je veux ajouter ma règle #2 ça ne marche pas :

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

robindesbois · Le 17/12/2015, à 17:00

Ça ne va pas pour moi, il faut transmettre tes règles de "confection" de règles iptables, pas tes règles finales suivant la commande :

# iptables -t filter -L --line-numbers -vn

Merci.

Dernière modification par robindesbois (Le 17/12/2015, à 17:01)

jejeman · Le 17/12/2015, à 18:27

Pour robindesbois, je commence avec une table de règle vide :

$ sudo iptables -t filter -L --line-numbers -vn
Chain INPUT (policy ACCEPT 15 packets, 1130 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 7 packets, 956 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Ensuite je veux créer la première règle pour autoriser le loopback et donc j'écris :

$ sudo iptables -A INPUT -j ACCEPT -i lo

Je vérifie, pas de souci, la règle est créée :

$ sudo iptables -t filter -L --line-numbers -vn
Chain INPUT (policy ACCEPT 9 packets, 660 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 5 packets, 692 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Ensuite je veux écrire la deuxième règle pour autoriser le trafic entrant d'une connexion déjà établie :

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

Et là ça pêche...
Merci.

robindesbois · Le 17/12/2015, à 19:39

Non ce que je voulais dire c'est que dans ton message numéro #10 au dessus, tu as tout un tas de règles dans INPUT, FORWARD, OUTPUT, mais elles sont tirées des résultats de la ligne de commande :

$ sudo iptables -nvL --line-number

Moi ce qu'il me faut ce sont les lignes de commandes iptables qui te permettent d'avoir ces résultats dans INPUT, FORWARD, OUTPUT (avec la commande) :

$ sudo iptables -nvL --line-number

Et non pas les résultats de la commande ci-dessus. Merci...

Dernière modification par robindesbois (Le 17/12/2015, à 19:41)

bruno · Le 18/12/2015, à 08:26

Quel est le résultat de :

grep 'CONFIG_NETFILTER_XT_MATCH_STATE' /boot/config*

jejeman · Le 18/12/2015, à 11:28

Pour bruno, le répertoire /boot/ est vide

Pour robindesbois les règles que je montrais dans le #10 sont issues de règles que j'avais écrites pour un autre serveur et j'aurai voulu mettre en place les mêmes règles pour ce nouveau serveur.
Voici les règles que j'avais utilisé à l'époque

sudo iptables -A INPUT -j ACCEPT -i lo
sudo iptables -A INPUT -j ACCEPT -m state --state RELATED,ESTABLISHED 
sudo iptables -A INPUT -p tcp -s XX.XX.XX.XXX --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 2121 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s XX.XX.XX.XXX --dport 3306 -j ACCEPT
sudo iptables -A INPUT -p icmp -s XX.XX.XX.XXX -j ACCEPT
sudo iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable

sudo iptables -A OUTPUT -j ACCEPT -m state --state NEW,RELATED,ESTABLISHED

Mais dès que j'utilise le paramètre "state" la règle ne fonctionne pas

Pour info, j'ai installé un ubuntu 14.04 sur mon PC en vbox, j'ai essayé de recréer mes règles, le parametre "state" ne pose pas de soucis
Il y a donc un problème avec cette version de ubuntu...

Dernière modification par jejeman (Le 18/12/2015, à 11:28)

mazarini · Le 18/12/2015, à 11:52

jejeman a écrit :

Pour bruno, le répertoire /boot/ est vide
...

Ca ressemble plus à du vps que du vrai dédié. Est ce que ca correspond à cette offre : https://fr.godaddy.com/pro/dedicated-server ?
Le VPS est très bien, mais ce n'est pas toujours aussi libre.

Je te conseille de regarde du coté d'OVH (soyoustart) ou d'Online qui sont les 2 hébergeurs bon marché.

Edit : bon marché mais pas de mauvaise qualité, tu peux éventuellement regarder Kimsufi (OVH) avec souvent plus de stock et service minimal.

Dernière modification par mazarini (Le 18/12/2015, à 11:55)

bruno · Le 18/12/2015, à 11:56

Un /boot vide, tu es sûr ? Ce que tu décris ressemble beaucoup plus à un serveur virtualisé qu'à un serveur dédié…

Si tu as ce message d'erreur avec « state » alors que tes lignes de commandes sont correctes c'est forcément que le noyau ne le gère pas.
Je ne peux que te conseiller de voir cela avec le support de Godaddy.

EDIT: grillé par Mazzarini Je plussoie sur le choix de l'hébergeur.

Dernière modification par bruno (Le 18/12/2015, à 11:58)

robindesbois · Le 18/12/2015, à 11:56

jejeman a écrit :

Pour bruno, le répertoire /boot/ est vide
Pour robindesbois les règles que je montrais dans le #10 sont issues de règles que j'avais écrites pour un autre serveur et j'aurai voulu mettre en place les mêmes règles pour ce nouveau serveur.
Voici les règles que j'avais utilisé à l'époque
sudo iptables -A INPUT -j ACCEPT -i lo
sudo iptables -A INPUT -j ACCEPT -m state --state RELATED,ESTABLISHED 
sudo iptables -A INPUT -p tcp -s XX.XX.XX.XXX --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 2121 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s XX.XX.XX.XXX --dport 3306 -j ACCEPT
sudo iptables -A INPUT -p icmp -s XX.XX.XX.XXX -j ACCEPT
sudo iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable

sudo iptables -A OUTPUT -j ACCEPT -m state --state NEW,RELATED,ESTABLISHED 
Mais dès que j'utilise le paramètre "state" la règle ne fonctionne pas
Pour info, j'ai installé un ubuntu 14.04 sur mon PC en vbox, j'ai essayé de recréer mes règles, le parametre "state" ne pose pas de soucis
Il y a donc un problème avec cette version de ubuntu...

Oui c'est normal, la règle est mal-formée, le "-j ACCEPT" est toujours à mettre en fin de chaque règle Iptables, ce qui donne :

sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Pour rappel celle que tu essaies de faire est celle-ci :

sudo iptables -A INPUT -j ACCEPT -m state --state RELATED,ESTABLISHED

Ce n'était donc pas une construction de règle conforme pour Iptables, il la rejette tout simplement. Si ça ne marche toujours pas repasse aucun soucis.

Dernière modification par robindesbois (Le 18/12/2015, à 11:58)

bruno · Le 18/12/2015, à 12:03

@robindesbois : À ma connaissance cet ordre n'a pas d'importance. Si tu as une référence prouvant le contraire ce serait intéressant de la lire.

robindesbois · Le 18/12/2015, à 12:06

Par contre tu peux "activer" le "Statefull" à tes autres règles (la fonction "suivi des paquets", rendant ainsi Iptables comme parefeu à "états"(Statefull) , c'est plus "sécuritaire" quoi) :

J'ai revu tes autres règles, les "-j REJECT" et autres règles qui suivent le "-j" sont toujours à mettre en fin de règles de chaque ligne d'iptables, sinon il ne les accepte pas, à plus :

 
 
sudo iptables -A INPUT -p tcp -s XX.XX.XX.XXX --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 2121 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -s XX.XX.XX.XXX --dport 3306 -j ACCEPT
sudo iptables -A INPUT -p icmp -s XX.XX.XX.XXX -j ACCEPT
sudo iptables -A INPUT --reject-with icmp-port-unreachable -j REJECT
sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -i lo -j ACCEPT

sudo iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Dernière modification par robindesbois (Le 18/12/2015, à 12:08)

robindesbois · Le 18/12/2015, à 12:07

bruno a écrit :

@robindesbois : À ma connaissance cet ordre n'a pas d'importance. Si tu as une référence prouvant le contraire ce serait intéressant de la lire.

Oui, mode d'emploi d'Iptables avec l'option --state sur le site officiel de Netfilter. L'ordre des règles est aussi important...(voir mes règles rectifiées au dessus.)

Dernière modification par robindesbois (Le 18/12/2015, à 12:09)

robindesbois · Le 18/12/2015, à 12:20

Pour le statefull, option très utile d'iptables, (quand activée avec l'option "-m state --state"), ça pourrait donner ce type de règles au finales (mais là Jejeman, il faudra que tu réfléchissent avant de mettre NEW ou de l'enlever, moi je te donne ce que j'ai compris de tes règles, donc j'ai mis du NEW là où je pense qu'il le faut, mais à toi de l'ajouter ou de l'enlever selon tes besoin) :

sudo iptables -A INPUT -p tcp -m state --state NEW,RELATED,ESTABLISHED -s XX.XX.XX.XXX --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp -m state --state RELATED,ESTABLISHED --dport 2121 -j ACCEPT
sudo iptables -A INPUT -p tcp -m state --state RELATED,ESTABLISHED --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp -m state --state RELATED,ESTABLISHED --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -m state --state NEW,RELATED,ESTABLISHED -s XX.XX.XX.XXX --dport 3306 -j ACCEPT
sudo iptables -A INPUT -p icmp -m state --state NEW,RELATED,ESTABLISHED -s XX.XX.XX.XXX -j ACCEPT
sudo iptables -A INPUT --reject-with icmp-port-unreachable -j REJECT
sudo iptables -A INPUT -i lo -j ACCEPT

sudo iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -o lo -j ACCEPT

Edit : j'ai viré la règle là de tes lignes, elle ne me semble pas utile du tout, et surtout pas logique, cette ligne là ne sert à rien pour moi :

sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Parce que toutes les lignes que je viens te donner au dessus comporte déjà l'option "-m state --state", Iptables a une logique d'utilisation, il faut s'y référer, à plus.

edit 2 : tu n'avais pas non plus autorisé l'interface lo en OUTPUT, je l'ai rajouté.

Dernière modification par robindesbois (Le 18/12/2015, à 12:28)

jejeman · Le 18/12/2015, à 12:31

Pour @mazarani en effet, c'est bien l'offre dont tu parles... Donc ça ressemble plus à du serveur virtuel que du dédié....
Pour @robindesbois, j'ai essayé, le -j ACCEPT à la fin ou non c'est pas mieux ! Et iptables sans pouvoir gérer du "state" ça va pas être facile...
Merci pour les conseil d'hébergeur, mais j'ai une contrainte, il faut qu'il soit aux USA...
Du coup je vais contacter godaddy je crois...
Merci à tous.

robindesbois · Le 18/12/2015, à 13:16

Quel sont tes règles finales avec tout ce qu'on t'a donné Jejeman ? les règles complètes stp, en masquant toujours tes adresses IP y'a pas de soucis Qu'elles sont tes interfaces réseaux sur cette machine ? eth0 ? tun0 ? etc... Si c'est iptables qui bloque on peut te résoudre ça très vite en fait. La ligne là ne doit pas faire partie de tes règles au final je te le rappelle, car si tu l'as met, c'est normal que ça ne marche pas, c'est la logique d'Iptables quoi... il ne faut pas mettre ça à la fin :

sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Car selon la logique du logiciel Iptables, ça annule toutes tes règles du dessus... Donc effectivement, ça ne va pas marcher si tu l'as met Et c'est pour ça que ça ne marche pas depuis le début que tu essaies de la mettre, Iptables ne fonctionne pas avec ta logique, mais avec la sienne, ce n'est pas grave, quand on débute on se trompe, du coup on est là pour t'apprendre, repasse, y'a pas de soucis.

Dernière modification par robindesbois (Le 18/12/2015, à 13:19)

jejeman · Le 18/12/2015, à 13:37

T'inquietes pas @robindesbois, je pense que le problème n'est pas sur iptables mais sur le serveur.
J'ai repris les règles dans l'ordre que tu donnes dans ton post #20 et ca bloque sur le reject et sur le state

$ sudo iptables -A INPUT --reject-with icmp-port-unreachable -j REJECT
iptables v1.4.21: unknown option "--reject-with"
Try `iptables -h' or 'iptables --help' for more information.
$ sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables: No chain/target/match by that name.

Alors que ça marche très bien sur un ubuntu 14.04 en mode virtualbox...

On peut installer un autre noyau ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 15/12/2015, à 17:37

iptables sans conntrack

#2 Le 15/12/2015, à 18:18

Re : iptables sans conntrack

#3 Le 16/12/2015, à 00:23

Re : iptables sans conntrack

#4 Le 16/12/2015, à 10:55

Re : iptables sans conntrack

#5 Le 16/12/2015, à 11:22

Re : iptables sans conntrack

#6 Le 16/12/2015, à 11:26

Re : iptables sans conntrack

#7 Le 17/12/2015, à 12:53

Re : iptables sans conntrack

#8 Le 17/12/2015, à 14:56

Re : iptables sans conntrack

#9 Le 17/12/2015, à 15:16

Re : iptables sans conntrack

#10 Le 17/12/2015, à 16:38

Re : iptables sans conntrack

#11 Le 17/12/2015, à 17:00

Re : iptables sans conntrack

#12 Le 17/12/2015, à 18:27

Re : iptables sans conntrack

#13 Le 17/12/2015, à 19:39

Re : iptables sans conntrack

#14 Le 18/12/2015, à 08:26

Re : iptables sans conntrack

#15 Le 18/12/2015, à 11:28

Re : iptables sans conntrack

#16 Le 18/12/2015, à 11:52

Re : iptables sans conntrack

#17 Le 18/12/2015, à 11:56

Re : iptables sans conntrack

#18 Le 18/12/2015, à 11:56

Re : iptables sans conntrack

#19 Le 18/12/2015, à 12:03

Re : iptables sans conntrack

#20 Le 18/12/2015, à 12:06

Re : iptables sans conntrack

#21 Le 18/12/2015, à 12:07

Re : iptables sans conntrack

#22 Le 18/12/2015, à 12:20

Re : iptables sans conntrack

#23 Le 18/12/2015, à 12:31

Re : iptables sans conntrack

#24 Le 18/12/2015, à 13:16

Re : iptables sans conntrack

#25 Le 18/12/2015, à 13:37

Re : iptables sans conntrack

Pied de page des forums