Audit iptables

Tags: #<Tag:0x00007f63f37a3010>

Mea coulpa, je raconte n’importe quoi :joy:
Effectivement !

Dans un troisième cas alors :

#!/bin/sh

echo "Flushing iptables rules..."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT


#Laisser les connexions établies ouvertes. 
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

#Autoriser le loopback
iptables -A INPUT -i lo -j ACCEPT

#Port SSH
iptables -A INPUT -p tcp --destination-port 32 -j ACCEPT

iptables -t nat -A PREROUTING -d ipfailover1 -j DNAT --to-destination 10.8.0.3
iptables -t nat -A POSTROUTING -s 10.8.0.3 ! -o tun0 -j SNAT --to-source ipfailover1

iptables -t nat -A PREROUTING -d ipfailover2 -j DNAT --to-destination 10.8.0.5
iptables -t nat -A POSTROUTING -s 10.8.0.5 ! -o tun0 -j SNAT --to-source ipfailover2

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 ! -o tun0 -j SNAT --to-source ipvps

#Permettre de laisser passer le traffic de ens3 vers tun0
iptables -A FORWARD -i ens3 -o tun0 -j ACCEPT

#Permettre de laisser passer le traffic de tun0 vers ens3
iptables -A FORWARD -i tun0 -o ens3 -j ACCEPT

#Pour permettre aux clients du vpn d'établir une connexion au serveur.
iptables -A INPUT -i ens3 -p udp --dport 1194 -j ACCEPT

#laisser le traffic entrer  sur l'interface tun0 sans restriction. 
iptables -A INPUT -i tun0 -j ACCEPT

#serveur web publique
iptables -A INPUT -p tcp --destination-port 81 -j ACCEPT

#Transmission-daemon
iptables -A INPUT -p tcp --dport 51413 -j ACCEPT
iptables -A INPUT -p udp --dport 51413 -j ACCEPT

ou :

#!/bin/sh

echo "Flushing iptables rules..."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT


#Laisser les connexions établies ouvertes. 
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

#Autoriser le loopback
iptables -A INPUT -i lo -j ACCEPT

#Port SSH
iptables -A INPUT -p tcp --destination-port 32 -j ACCEPT

iptables -t nat -A PREROUTING -d ipfailover1 -j DNAT --to-destination 10.8.0.3
iptables -t nat -A POSTROUTING -s 10.8.0.3 ! -o tun0 -j SNAT --to-source ipfailover1

iptables -t nat -A PREROUTING -d ipfailover2 -j DNAT --to-destination 10.8.0.5
iptables -t nat -A POSTROUTING -s 10.8.0.5 ! -o tun0 -j SNAT --to-source ipfailover2

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 ! -o tun0 -j SNAT --to-source ipvps

#Permettre de laisser passer le traffic de ens3 vers tun0
iptables -A FORWARD -i ens3 -o tun0 -j ACCEPT

#Permettre de laisser passer le traffic de tun0 vers ens3
iptables -A FORWARD -i tun0 -o ens3 -j ACCEPT

#Pour permettre aux clients du vpn d'établir une connexion au serveur.
iptables -A INPUT -i ens3 -p udp --dport 1194 -j ACCEPT

#Permettre la résolution de noms de domaines pour pihole
iptables -A INPUT -i tun0 -p tcp --destination-port 53 -j ACCEPT
iptables -A INPUT -i tun0 -p udp --destination-port 53 -j ACCEPT

#Accès serveur web privé
iptables -A INPUT -i tun0 -p tcp --destination-port 80 -j ACCEPT

#Serveur web publique
iptables -A INPUT -p tcp --destination-port 81 -j ACCEPT

#Transmission-daemon
#Panel 
iptables -A INPUT -i tun0 -p tcp --destination-port 9091 -j ACCEPT

iptables -A INPUT -p tcp --dport 51413 -j ACCEPT
iptables -A INPUT -p udp --dport 51413 -j ACCEPT

Il y a une erreur dans les règles POSTROUTING.

1 J'aime

–>

iptables -t nat -A PREROUTING -d ipfailover1 -j DNAT --to-destination 10.8.0.3
iptables -t nat -A POSTROUTING -s 10.8.0.3 -o tun0 -j SNAT --to-source ipfailover1 

iptables -t nat -A PREROUTING -d ipfailover2 -j DNAT --to-destination 10.8.0.5 
iptables -t nat -A POSTROUTING -s 10.8.0.5 -o tun0 -j SNAT --to-source ipfailover2

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun0 -j SNAT --to-source ipvps

Je pense que c’est ça.

En effet.

1 J'aime

Du coup, plus d’incohérences à tes yeux ? :face_with_monocle:

Si c’est le cas, je te remercie, dès que je peux, je vais tester les configurations !

Oui, il faut tester. En cas de problème, ajouter des règles LOG pour voir ce qui est bloqué.

1 J'aime

je ne risque pas de me bloquer en appliquant le script ?
car j’ai un doute concernant l’emplacement de :

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

je la verrai avant :

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Ça ne devrait pas faire une grosse différence. Si un paquet TCP est bloqué transitoirement, il sera retransmis un peu plus tard. Par contre il faut bien l’exécuter en tant que script, et pas ligne par ligne dans le shell.

De toute façon tu as bien une console de dépannage pour reprendre la main si nécessaire ?

1 J'aime

oui sans problème !

Petite question :

#Permettre de laisser passer le traffic de ens3 vers tun0
iptables -A FORWARD -i ens3 -o tun0 -j ACCEPT

#Permettre de laisser passer le traffic de tun0 vers ens3
iptables -A FORWARD -i tun0 -o ens3 -j ACCEPT

Pourquoi ne pas le faire également pour ens3:1 et ens3:2 qui sont les interfaces pour les ipfailover ?

Surtout pas : ens3:1 et ens3:2 ne sont pas de vraies interfaces, ce sont des « alias IP », des étiquettes qui servaient à ajouter des adresses IPv4 supplémentaire à l’interface ens3. Les règles iptables ne les voient pas, elles ne voient que la véritable interface ens3.

Je n’avais pas pris la peine de le signaler après avoir parcouru le tutoriel, mais cette technique est obsolète, maintenant on peut directement affecter plusieurs adresses à une même interface.

2 J'aime

Aurais-tu un tuto permettant de faire quelque chose au goût du jour ?

Je ne suis pas très « tuto ». Si les interfaces réseau sont configurées dans /etc/network/interfaces, il suffit d’ajouter une strophe « iface » pour chaque adresse.

iface ens3 inet static
address x.x.x.x/32

D’autre part, je me demande dans quelle mesure il est nécessaire d’ajouter les adresses « failover » à l’interface. La seule raison, ce serait si les routeurs connectés au réseau du serveur envoient des requêtes ARP pour résoudre les adresses.

Je ne sais pas comment les adresses « failover » sont gérées par l’hébergeur de ton serveur, ni si le routage d’un adresse « failover » est direct (requête ARP pour l’adresse failover) ou indirect (requête ARP pour l’adresse principale du serveur). Tu peux faire une capture du trafic ARP sur ens3 tout en générant du trafic sur une adresse failover pour voir.

tcpdump -nti ens3 arp

Dans le second cas, pas besoin de les ajouter.

je reviendrai sur ce sujet un peu plus tard !
Personnellement, j’ai commandé 2 ips failover sur mon vps (chez ovh).
Ensuite, pour les faires fonctionner j’ai ajouter les lignes correspondantes dans mon fichier /etc/network/interfaces :

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens4
iface ens4 inet dhcp


auto ens3:1
iface ens3:1 inet static
address ipfailover1
netmask 255.255.255.255

auto ens3:2
iface ens3:2 inet static
address ipfailover2
netmask 255.255.255.255

là, j’ai essayé cette configuration :

#!/bin/sh

echo "Flushing iptables rules..."
sleep 1
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT


#Laisser les connexions établies ouvertes
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

#Autoriser le loopback
iptables -A INPUT -i lo -j ACCEPT

#Port SSH
iptables -A INPUT -p tcp --destination-port 32 -j ACCEPT

iptables -t nat -A PREROUTING -d ipfo1 -j DNAT --to-destination 10.8.0.3
iptables -t nat -A POSTROUTING -s 10.8.0.3 -o tun0 -j SNAT --to-source fo1

iptables -t nat -A PREROUTING -d ipfo2 -j DNAT --to-destination 10.8.0.5
iptables -t nat -A POSTROUTING -s 10.8.0.5 -o tun0 -j SNAT --to-source ipfo2

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun0 -j SNAT --to-source ipvps

#Permettre de laisser passer le traffic de ens3 vers tun0
iptables -A FORWARD -i ens3 -o tun0 -j ACCEPT

#Permettre de laisser passer le traffic de tun0 vers ens3
iptables -A FORWARD -i tun0 -o ens3 -j ACCEPT

#Pour permettre aux clients du vpn d'établir une connexion au serveur.
iptables -A INPUT -i ens3 -p udp --dport 1194 -j ACCEPT

#laisser le traffic entrer  sur l'interface tun0 sans restriction. 
iptables -A INPUT -i tun0 -j ACCEPT

#serveur web publique
iptables -A INPUT -p tcp --destination-port 81 -j ACCEPT

#Transmission-daemon
iptables -A INPUT -p tcp --dport 51413 -j ACCEPT
iptables -A INPUT -p udp --dport 51413 -j ACCEPT

Malheureusement, mes clients openvpn n’ont pas internet :confused:

L’interface de sortie des règles SNAT n’est pas bonne, ça m’avait échappé.

1 J'aime

Je viens de rectifier tun0 > ens3 ; et ça fonctionne !

Peux-tu m’en dire un peu plus concernant les ips failovers, si on pouvait faire autrement / plus simplement ?

Egalement, c’est surement une question bête, mais lorsque je test si un port est ouvert ou fermé, est-qu’il faut un programme qui écoute, tourne, derrière un ce port pour qu’il soit considéré comme open ou bien, il s’affichera comme fermé ?

D’abord il faut vérifier s’il y a des requêtes ARP pour les adresses IP failover.
Si oui, alors tu peux remplacer les strophes ens3:X dans /etc/network/interfaces par ce que j’ai proposé.
Si non, tu peux carrément les supprimer.

Lorsqu’aucun processus n’écoute sur un port, le port est dit fermé et renvoie immédiatement une information disant qu’il est fermé. Tes règles DROP bloquent silencieusement les demandes de connexion, donc le port est dit filtré et non fermé et ne renvoie aucune information sur son état. Le programme client part en time-out.
Pour simuler un port fermé avec iptables, il faut utiliser la cible REJECT au lieu de DROP.

1 J'aime

Merci pour l’explication !

J’ai ceci (12.13.502.14 étant l’ip du vps) :

tcpdump -nti ens3 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
ARP, Request who-has ipfailover1 tell 12.13.500.1, length 28
ARP, Reply ipfailover1 is-at fa:16:3e:9f:58:eb, length 28
ARP, Request who-has 12.13.502.14 tell 12.13.500.1, length 28
ARP, Reply 12.13.502.14 is-at fa:16:3e:9f:58:eb, length 28
ARP, Request who-has ipfailover2 tell 12.13.500.1, length 28
ARP, Reply ipfailover2 is-at fa:16:3e:9f:58:eb, length 28
ARP, Request who-has 12.13.502.14 tell 12.13.500.1, length 28
ARP, Reply 12.13.502.14 is-at fa:16:3e:9f:58:eb, length 28
ARP, Request who-has ipfailover1 tell 12.13.500.1, length 28
ARP, Reply ipfailover1 is-at fa:16:3e:9f:58:eb, length 28
ARP, Request who-has ipfailover2 tell 12.13.500.1, length 28
ARP, Reply ipfailover2 is-at fa:16:3e:9f:58:eb, length 28
ARP, Request who-has 12.13.502.14 tell 12.13.500.1, length 28
ARP, Reply 12.13.502.14 is-at fa:16:3e:9f:58:eb, length 28
ARP, Request who-has ipfailover1 tell 12.13.500.1, length 28
ARP, Reply ipfailover1 is-at fa:16:3e:9f:58:eb, length 28
ARP, Request who-has ipfailover2 tell 12.13.500.1, length 28
ARP, Reply ipfailover2 is-at fa:16:3e:9f:58:eb, length 28
ARP, Request who-has 12.13.502.14 tell 12.13.500.1, length 28
ARP, Reply 12.13.502.14 is-at fa:16:3e:9f:58:eb, length 28
ARP, Request who-has ipfailover1 tell 12.13.500.1, length 28
ARP, Reply ipfailover1 is-at fa:16:3e:9f:58:eb, length 28
^C
22 packets captured
26 packets received by filter
0 packets dropped by kernel

Par contre, je viens de m’apercevoir que cette règle ou non :

iptables -A INPUT -i tun0 -j ACCEPT

Les clients vpn ont accès librement au web, c’est normal ?

Il y a bien des requêtes ARP pour les adresses failover, donc il faut garder ces adresses sur l’interface ethernet, ou bien faire du proxy ARP pour elles mais ce n’est pas plus simple, et ce serait utile seulement pour pouvoir les affecter directement à des clients VPN sans faire du NAT.

Tu veux dire à internet ou aux services web du serveur ?
Pour l’accès à internet c’est normal, le trafic passe par la chaîne FORWARD et non INPUT (sauf les requêtes DNS si les clients utilisent le serveur comme serveur DNS).
Pour avoir accès aux services web du serveur, il faut soit cette règle soit des règles pour les différents ports.

1 J'aime

un avantage à affecter directement les ips aux clients sans faire du NAT ?

Ils ont accès à internet et aux services web du serveur.

Ah je comprends mieux !
Par contre, oui, accès à internet, mais pas au serveur web sur les port 80 et 81 ni même à mon panel de transmission !
Par contre, la résolution DNS fonctionnait quand même !
Mais lorsque dans le fichier de configuration d’openvpn je mettais comme adresse DNS 10.8.0.1, pour que Pi hole puisse faire office de « filtre DNS » effectivement là ça ne fonctionnait plus. Je t’ai peut être perdu sur cette phrase, car bon on sort du cadre…

Si l’idée me vient de vouloir faire l’inverse. Que les clients vpn puisse accéder au serveur mais uniquement pour utiliser les services « localement » sans pouvoir utiliser le vpn pour aller sur internet.
Je commente l’une de ces commandes :

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens3 -j SNAT --to-source ipvps
iptables -A FORWARD -i ens3 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o ens3 -j ACCEPT

?
J’ai testé ça fonctionne, mais c’est peut être du bricolage dont je suis adepte :joy:

Egalement, je n’arrive pas à comprendre comment est-ce que tun0 peut communiquer librement avec internet, sachant que l’interface ens3 est bloqué en input, il n’y a que le port 32, 81, 1194, 9091, 51413 d’ouvert… Je ne sais pas pourquoi, dans ma tête ce n’est pas normal que ça fonctionne.
tun0 d’un point de vue extérieur n’est pas visible ? Il y a uniquement ens3 en liaison avec l’extérieur ? Ce que je veux dire, c’est que si on souhaite accéder à tun0 depuis l’extérieur, on passe forcément pas ens3 ?

Fournir une véritable connectivité IP de bout en bout en évitant les inconvénients du NAT. Le NAT ne fonctionne pas avec certains flux, notamment ceux qui ne se comportent pas comme des « connexions » (quadruplet adresse+port source et destination), ou qui transmettent des informations de couche réseau dans les couches supérieures (exemple : FTP, SIP).

Le plus propre est de désactiver les deux règles ACCEPT dans FORWARD. Le NAT ne devrait pas être utilisé pour faire du filtrage, ce n’est pas fiable.

Les paquets transmis d’une interface à l’autre ne transitent pas par la chaîne INPUT, seulement par la chaîne FORWARD. La chaîne INPUT ne traite que les paquets destinés à la machine elle-même.

1 J'aime