Configuration iptables et OpenVPN

Frodomo · Le 06/10/2016, à 18:50

Bonjour à tous,

Voilà j'ai configuré OpenVPN sur mon petit raspberry pi.
Tout fonctionne à merveille sauf quand je veux configurer iptables.
J'utilise le script suivant :

#!/bin/bash

iptables -F

#Deny all other coms
iptables -P FORWARD DROP
iptables -P INPUT DROP

#Allow all coms from private network
iptables -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT

#Allow coms for openVPN
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0 -o eth0 -j MASQUERADE
iptables -A INPUT -p udp --dport 1194 -j ACCEPT

#Accept packets belonging to established and related connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT

#Accept coms for localhost
iptables -A INPUT -i lo -j ACCEPT

#Accept all coms out
iptables -P OUTPUT ACCEPT

Et là dès que j'applique, je n'ai plus accès au web depuis mon client OpenVPN et mon PC qui est sur mon réseau local ne peut plus se connecter en SSH.
L'ajout de la règle suivante permet de résoudre le dernier problème mais j'aurais aimé pouvoir n'y accéder que depuis le réseau local.

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

Si quelqu'un aurait une idée pour résoudre le problème de web et de SSH je lui serais très reconnaissant

Merci à vous !

lynn · Le 06/10/2016, à 19:08

Bonjour,

Un sujet qui me rappelle quelque chose... Peut-être une piste par ici..?!

Frodomo · Le 06/10/2016, à 19:21

Bonjour Lynn !

Merci pour ta réponse.

Si j'ai bien suivi le post vers lequel tu m'as orienté, le problème était un problème de routage ?

Là j'ai vraiment l'impression que ça vient de la config d'iptables. Car avant d'appliquer le script, tout fonctionne bien.

Alex Ample · Le 07/10/2016, à 11:51

La règle SSH port 22, il faut la placer avant la ligne INPUT DROP;

Dernière modification par Alex Ample (Le 07/10/2016, à 11:52)

pires57 · Le 07/10/2016, à 16:27

La règle SSH port 22, il faut la placer avant la ligne INPUT DROP;

certainement pas ...
@frodomo: pourrais tu fournir une sorte de schéma rapide de ton réseau histoire de vérifier ?

Frodomo · Le 08/10/2016, à 14:51

Salut,

merci pour vos réponses.

Je sais pas trop quoi te donner comme information.
J'ai mon raspberry avec l'adresse ip 192.168.1.99 que j'essaie d'accéder depuis mon PC portable avec l'adresse IP 192.168.1.92

PS: le problème du web est résolu, il manquait le masque de sous réseau à la ligne iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Dernière modification par Frodomo (Le 08/10/2016, à 15:02)

Alex Ample · Le 08/10/2016, à 15:39

Essaye de placer une règle iptables -I INPUT ? -i lo -j ACCEPT
( -I et pas -A ), en mettant le bon chiffre à la place du ? pour modifier l’ordre des règles, et voir ce qui marche, la règle placée au dessus est celle qui fait autorité.

Essaye aussi de bouger la règle SSH de la même façon.

Un bricolage parfois conseillé est d’abord de faire la règle à problème puis d’installer le script ensuite, le tien ne semble pas très académique, il aurait mieux valu que tu acceptes tout ( input output forward ), puis faire tes règles pour les flux autorisés, et enfin bloquer le reste.

Gufw tu connais ?...

Dernière modification par Alex Ample (Le 08/10/2016, à 15:44)

Frodomo · Le 08/10/2016, à 16:39

Je suis un peu perdu sur l'ordre dans lequel doivent-etre appliqués les règles.
Les règles par défaut puis les règles spécifiques ensuite ou l'inverse ?

Alex Ample · Le 08/10/2016, à 18:20

Frodomo a écrit :

Je suis un peu perdu sur l'ordre dans lequel doivent-etre appliqués les règles.
Les règles par défaut puis les règles spécifiques ensuite ou l'inverse ?

Si tu installes des politiques avec -P, tu vas avoir par exemple INPUT DROP, si tu ajoutes tes règles INPUT ou OUTPUT avec -A, elles vont s’ajouter à celles ci, elles vont autoriser ou bloquer, le reste du trafic INPUT ou OUTPUT restant interdit grâce à la politique -P définie, le danger c’est de faire des règles qui se contredisent ou s’annulent, du fait de leur syntaxe ou de leur rang mal placé.

Une autre méthode comme dit plus haut est d’avoir une politique INPUT ACCEPT ( ou FORWARD ou OUTPUT ), d’ajouter ses propres règles INPUT avec -A, puis de bloquer tout le reste toujours avec -A, comme la règle placée le plus haut a la main, elles seront acceptées jusqu’aux dernières qui bloqueront le reste.

Dernière modification par Alex Ample (Le 08/10/2016, à 18:33)

pires57 · Le 08/10/2016, à 19:08

Si tu installes des politiques avec -P, tu vas avoir par exemple INPUT DROP, si tu ajoutes tes règles INPUT ou OUTPUT avec -A, elles vont s’ajouter à celles ci, elles vont autoriser ou bloquer, le reste du trafic INPUT ou OUTPUT restant interdit grâce à la politique -P définie, le danger c’est de faire des règles qui se contredisent ou s’annulent, du fait de leur syntaxe ou de leur rang mal placé.
Une autre méthode comme dit plus haut est d’avoir une politique INPUT ACCEPT ( ou FORWARD ou OUTPUT ), d’ajouter ses propres règles INPUT avec -A, puis de bloquer tout le reste toujours avec -A, comme la règle placée le plus haut a la main, elles seront acceptées jusqu’aux dernières qui bloqueront le reste.

Les règles ne bloqueront que ce qui est défini, tu parles de Input / Output mais si je spécifie la table Mangle elle ne bloquera aucune des deux tables que tu cites ...
Le paramètre -P te permet de définir une politique, ce sera le comportement par défaut de ton firewall. Dans ton cas, tu as opté pour une politique DROP par défaut donc la suite du processus reviens à ouvrir les ports qui te seront nécessaire.
L'option -A (append) te permet effectivement de d'ajouter à la fin d'une chaîne une nouvelle règle, en revanche je ne conseille pas d'opter pour une méthode de type ACCEPT puis DROP à la dernière ligne parce que ce genre de configuration est sujette aux embrouilles.
Je m'explique :
J'exécute tout un tas de règles puis je termine par mon drop. Super, mon serveur fonctionne, mes règles sont OK mais 3 mois plus tard j'installe un nouveau service nécessitant un nouveau port (45500 par exemple), que ce passera t'il si j’exécute une commande iptables avec l'option -A afin d'autoriser ce port? Et bien il ne se passera rien du tout parce qu'une fois la règle de DROP avec l'option -A atteinte le paquet sera rejetté purement et simplement.
Alors bien sur il existe un moyen de rajouter des règles en sautant ce problème (option -I) mais c'est franchement moins pratique que de définir une policy de drop et d'ouvrir ce qui doit l'être.

Pour ton SSH, tu devra donc ajouter une règle pour l'ouvrir :

iptables -A INPUT -p tcp -i ethX --dport ssh -j ACCEPT

Si tu souhaite le restreindre pour un seul réseau / adresse il te faudra utiliser l'option "-s" et si tu souhaite également restreindre l'interface (cas d'un serveur avec plusieurs cartes réseau ) l'option "-i")

Frodomo · Le 09/10/2016, à 16:24

Super merci pour cette réponse c'est largement plus clair maintenant.
Mais du coup j'ai déjà la règle suivante de précisée :

iptables -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT

qui est la toute première règle, donc je pense pas qu'il y ai de soucis à ce niveau.

pires57 · Le 09/10/2016, à 18:13

Que renvois

iptables -L

Alex Ample · Le 10/10/2016, à 07:23

Scanne tes ports avec Nmap dans le réseau local, si le 22 apparaît fermé, c'est que le service n'est pas démarré.

" iptables -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT "
Ta plage " 192.168.0.0/255.255.255.0 " est impossible à scanner, essaye plus simple, " 192.168.1.0/24 " pour commencer.

Dernière modification par Alex Ample (Le 10/10/2016, à 10:40)

pires57 · Le 10/10/2016, à 09:44

Scanne tes ports avec Nmap dans le réseau local, si le 22 apparaît fermé, c'est que le service n'est pas démarré.
Ta plage " 192.168.0.0/255.255.255.0 " est impossible à scanner, essaye plus simple, " 192.168.1.0/24 " pour commencer.

Quel intérêt de scanner une adresse réseau?
il faut scanner l'adresse IP du serveur (raspberry pi) mais rien ne te dit que le serveur n'est pas protégé contre ce type de scan (Portsentry par exemple).
Je ne vois pas vraiment l'intérêt de faire un scan de port alors que le serveur est sous la main ...
Que renvois

ssh -V

et

netstat -tlnpu |grep ssh

robindesbois · Le 10/10/2016, à 11:44

pires57 a écrit :

Que renvois
ssh -V
et
netstat -tlnpu |grep ssh

Hello, juste pour dire que je mets les lettres autrement pour créer un moyen mnémotechnique pour cette ligne netstat (sans la fonctione grep ssh pour moi chaque jour) :

Pour voir les services (serveur), je me plains (je dépose une plainte au serveur car je n'ai plus de bière) :

# netstat -plunt

Et pour voir les connexions établies (une fois que j'ai ma pinte de bière, la connexion est établie), je fais :

# netstat -punt

Voilà.

Frodomo · Le 10/10/2016, à 19:09

Le service ssh est actif puisque j'y accède avant d'appliquer les règles iptables

pires57 · Le 10/10/2016, à 19:24

Je te demande des infos précise que tu ne donne pas. Je ne vois pas comment je vais pouvoir t'aider. . dans ton premier poste tu parle de ssh dopenvpn ... A l'heure actuel je ne sais toujours pas a quoi ressemble ton réseau, qui a quel IP ... Tu ne donne aucune info ! Je te demande le retour d'une commande iptables que tu ne renvois pas. Comment veut tu que je t'aide? Je suis pas un magicien. Hein je ne vois pas ta config exacte dans une boule de cristal !

Frodomo · Le 10/10/2016, à 19:57

désolé

le retour de la première commande est le suivant :

OpenSSH_6.7p1 Raspbian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016

et netstat:

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      612/sshd        
tcp6       0      0 :::22                   :::*                    LISTEN      612/sshd

pires57 · Le 10/10/2016, à 20:27

Et

iptables -L

Alex Ample · Le 10/10/2016, à 20:47

Frodomo a écrit :

Le service ssh est actif puisque j'y accède avant d'appliquer les règles iptables

" tcp 0 0 0.0.0.0:22 0.0.0.0:* "

Il n'est pas actif sur une IP locale précise ( 0 0.0.0.0 ) mais à disposition, si tu scannais avec Nmap on verrait clairement l'état du port 22, netstat c'est du bricolage.

Dernière modification par Alex Ample (Le 10/10/2016, à 20:47)

Frodomo · Le 10/10/2016, à 20:56

iptables -L retourne ceci:

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  192.168.0.0/24       anywhere            
ACCEPT     udp  --  anywhere             anywhere             udp dpt:openvpn
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  10.8.0.0/24          anywhere            
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere

pires57 · Le 10/10/2016, à 22:48

@alex le retour est plus que précis. Netstat te dis clairement que le port 22 est en écoute sur 0.0.0.0 qui est une adresse réseau représentant internet. C'est toi le bricoleur, nmap est un outils de pentesting alors que netstat est un outils système... mais bien sur à condition de comprendre ses retours, ce qui n'est visiblement pas ton cas.
@frodomo: je regarde les retours de tes commandes demain matin.
Ps: peut tu renvoyer les adresses ip de ton serveur et du poste avec lequel tu veut te connecter en ssh.
La commande a taper est

ifconfig -a

Dernière modification par pires57 (Le 10/10/2016, à 23:21)

Alex Ample · Le 11/10/2016, à 06:34

Frodomo a écrit :

iptables -L retourne ceci:

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  192.168.0.0/24       anywhere            
ACCEPT     udp  --  anywhere             anywhere             udp dpt:openvpn
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  10.8.0.0/24          anywhere            
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere

Frodomo, un port ouvert en écoute apparaît sur netstat comme ceci :

TCP 192.168.1.14:139 0.0.0.0:0 LISTENING 4

Une adresse locale 0.0.0.0 ça veut dire en gros « pour tous ceux que ça intéresse ».

Si tu avais utilisé Nmap on aurait pu savoir si le port est ouvert, fermé, ou filtré, et faire des corrections sans chercher dans les limbes, tu devrais refaire ton iptables, nettoie comme ceci et redémarre :

sudo iptables -F
sudo iptables -X

Dans ce topic tu as des infos pour faire quelque chose de correct.

Remarque : Iptables n’a aucune valeur particulière, le pare feu c’est Netfilter, ensuite avec Ubuntu 16.04 / systemd, si tu as réussi à l’installer préviens nous.

Tu devrais utiliser Gufw, tu n’aurais aucun ennui.

Dernière modification par Alex Ample (Le 11/10/2016, à 07:07)

pires57 · Le 11/10/2016, à 10:10

Je pense que ton soucis viens d'OpenVPN.
Les requêtes vers ton serveur ne semble pas venir de la plage d'adresse que tu as fourni (192.168.0.0/24).
Pour vérifier il va falloir être plus permissif et restreindre par la suite.
Rajoute cette règle à ton script iptables :

iptables -A INPUT -p tcp --dport ssh -s 10.8.0.0/24,192.168.0.0/24 -j ACCEPT

elle va ouvrir ssh pour tout le range 10.8.0.0/24 et 192.168.0.0/24 dit moi si cela fonctionne.
Au niveau de ton script iptables, tu peut également incorporer la commande fourni par Alex_ample :

iptables -X

juste en dessous de

iptables -F

PS : GUFW est une interface graphique à UFW, le serveur étant un raspberry Pi je suppose qu'il n'a pas installé d'interface graphique mais pourrais éventuellement utiliser UFW.

Dernière modification par pires57 (Le 11/10/2016, à 11:50)

Frodomo · Le 11/10/2016, à 19:37

La ligne suivante n'apporte aucune amélioration.

iptables -A INPUT -p tcp --dport ssh -s 10.8.0.0/24,192.168.0.0/24 -j ACCEPT

pour ce qui est du résultat des ipconfig les voici:
serveur

eth0      Link encap:Ethernet  HWaddr b8:27:eb:d0:e6:be  
          inet addr:192.168.1.99  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::b420:b868:de01:8ac5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:94 errors:0 dropped:0 overruns:0 frame:0
          TX packets:108 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:7704 (7.5 KiB)  TX bytes:12938 (12.6 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:200 errors:0 dropped:0 overruns:0 frame:0
          TX packets:200 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:16656 (16.2 KiB)  TX bytes:16656 (16.2 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

client

Carte Ethernet Ethernet :

   Suffixe DNS propre à la connexion. . . : lan
   Description. . . . . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Adresse physique . . . . . . . . . . . : DC-4A-3E-F3-7A-42
   DHCP activé. . . . . . . . . . . . . . : Oui
   Configuration automatique activée. . . : Oui
   Adresse IPv6 de liaison locale. . . . .: fe80::9923:cd41:b300:d774%5(préféré)
   Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.92(préféré)
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Bail obtenu. . . . . . . . . . . . . . : jeudi 6 octobre 2016 21:45:04
   Bail expirant. . . . . . . . . . . . . : mercredi 12 octobre 2016 18:35:59
   Passerelle par défaut. . . . . . . . . : 192.168.1.254
   Serveur DHCP . . . . . . . . . . . . . : 192.168.1.254
   IAID DHCPv6 . . . . . . . . . . . : 64768574
   DUID de client DHCPv6. . . . . . . . : 00-01-00-01-1E-39-CE-77-DC-4A-3E-F3-7A-42
   Serveurs DNS. . .  . . . . . . . . . . : 2001:4860:4860::8888
                                       2001:4860:4860::8844
                                       8.8.8.8
                                       8.8.4.4
   NetBIOS sur Tcpip. . . . . . . . . . . : Activé

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 06/10/2016, à 18:50

Configuration iptables et OpenVPN

#2 Le 06/10/2016, à 19:08

Re : Configuration iptables et OpenVPN

#3 Le 06/10/2016, à 19:21

Re : Configuration iptables et OpenVPN

#4 Le 07/10/2016, à 11:51

Re : Configuration iptables et OpenVPN

#5 Le 07/10/2016, à 16:27

Re : Configuration iptables et OpenVPN

#6 Le 08/10/2016, à 14:51

Re : Configuration iptables et OpenVPN

#7 Le 08/10/2016, à 15:39

Re : Configuration iptables et OpenVPN

#8 Le 08/10/2016, à 16:39

Re : Configuration iptables et OpenVPN

#9 Le 08/10/2016, à 18:20

Re : Configuration iptables et OpenVPN

#10 Le 08/10/2016, à 19:08

Re : Configuration iptables et OpenVPN

#11 Le 09/10/2016, à 16:24

Re : Configuration iptables et OpenVPN

#12 Le 09/10/2016, à 18:13

Re : Configuration iptables et OpenVPN

#13 Le 10/10/2016, à 07:23

Re : Configuration iptables et OpenVPN

#14 Le 10/10/2016, à 09:44

Re : Configuration iptables et OpenVPN

#15 Le 10/10/2016, à 11:44

Re : Configuration iptables et OpenVPN

#16 Le 10/10/2016, à 19:09

Re : Configuration iptables et OpenVPN

#17 Le 10/10/2016, à 19:24

Re : Configuration iptables et OpenVPN

#18 Le 10/10/2016, à 19:57

Re : Configuration iptables et OpenVPN

#19 Le 10/10/2016, à 20:27

Re : Configuration iptables et OpenVPN

#20 Le 10/10/2016, à 20:47

Re : Configuration iptables et OpenVPN

#21 Le 10/10/2016, à 20:56

Re : Configuration iptables et OpenVPN

#22 Le 10/10/2016, à 22:48

Re : Configuration iptables et OpenVPN

#23 Le 11/10/2016, à 06:34

Re : Configuration iptables et OpenVPN

#24 Le 11/10/2016, à 10:10

Re : Configuration iptables et OpenVPN

#25 Le 11/10/2016, à 19:37

Re : Configuration iptables et OpenVPN

Pied de page des forums