Audit iptables

[pyridoxine]

Bonsoir à tous.

j’espère que vous allez bien en cette période.

Je souhaite partager avec vous, ma configuration iptable disposée sur mon serveur.
Et j’aimerai, si possible, avoir votre aide pour savoir si elle est cohérente ou non.

Effectivement, je trouve quelque chose de bizarre. Même avec la sortie en DROP, et même sans le port smtp ouvert, mon petit client mail (ssmtp) arrive à envoyer un mail…

Du coup, je m’interroge sur ma configuration, la voici :

#!/bin/sh
 
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 DROP
 
iptables -A INPUT -m pkttype --pkt-type broadcast -j DROP
iptables -A INPUT -p tcp --tcp-flags FIN,URG,PSH FIN,URG,PSH -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
 
iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state ! --state INVALID -j ACCEPT
 
iptables -I INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
 
 
iptables -A INPUT -p tcp --destination-port 32 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 32 -m state --state ESTABLISHED -j ACCEPT
 
 
#VPN
 
iptables -t nat -A PREROUTING -d x1/32 -j DNAT --to-destination 10.8.0.3
iptables -t nat -A POSTROUTING -s 10.8.0.3/32 ! -d 10.8.0.0/30 -j SNAT --to-source x1
 
iptables -t nat -A PREROUTING -d x2/32 -j DNAT --to-destination 10.8.0.5
iptables -t nat -A POSTROUTING -s 10.8.0.5/32 ! -d 10.8.0.0/30 -j SNAT --to-source x2
 
iptables -t nat -A POSTROUTING -s 10.8.0.0/30 ! -d 10.8.0.0/30 -j SNAT --to-source x
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens3 -j MASQUERADE
 
iptables -A FORWARD -i ens3 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o ens3 -j ACCEPT
 
iptables -A INPUT -i ens3 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o ens3 -p udp --dport 1194 -j ACCEPT
 
 
iptables -A INPUT -i tun0 -p tcp --destination-port 53 -j ACCEPT
iptables -A OUTPUT -o tun0 -p tcp --destination-port 53 -j ACCEPT
 
iptables -A INPUT -i tun0 -p udp --destination-port 53 -j ACCEPT
iptables -A OUTPUT -o tun0 -p udp --destination-port 53 -j ACCEPT
 
 
iptables -A INPUT -i tun0 -p tcp --destination-port 80 -j ACCEPT
iptables -A OUTPUT -o tun0 -p tcp --destination-port 80 -j ACCEPT
 
 
iptables -A INPUT -i tun0 -p tcp --destination-port 9091 -j ACCEPT
iptables -A OUTPUT -o tun0 -p tcp --destination-port 9091 -j ACCEPT
 
iptables -A INPUT -p tcp --dport 51413 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 51413 -j ACCEPT
 
iptables -A INPUT -p tcp --destination-port 81 -j ACCEPT
iptables -A OUTPUT -p tcp --destination-port 81 -j ACCEPT

Merci

[PascalHambourg]

@pyridoxine

Je souhaite partager avec vous, ma configuration iptable disposée sur mon serveur.
Et j’aimerai, si possible, avoir votre aide pour savoir si elle est cohérente ou non.

1. Cette machine est manifestement plus qu’un simple serveur, elle a des fonctions de routeur pour un VPN.

2. Il est difficile de juger la pertinence du jeu de règles d’un routeur sans connaître la topologie du réseau et l’expression des besoins : qui doit accéder à quels services/ports sur quoi, raisons des règles NAT…

On peut quand même signaler les incohérences suivantes :

3. Cette règle :

   iptables -A OUTPUT -m state ! --state INVALID -j ACCEPT
   

   rend superflues toutes les règles du type :

   iptables -A OUTPUT -p tcp --sport 32 -m state --state ESTABLISHED -j ACCEPT
   iptables -A OUTPUT -o ens3 -p udp --dport 1194 -j ACCEPT
   iptables -A OUTPUT -p tcp --dport 51413 -j ACCEPT
   

4. Le regroupement de règles comme

   iptables -A INPUT -i tun0 -p tcp --destination-port 53 -j ACCEPT
   iptables -A OUTPUT -o tun0 -p tcp --destination-port 53 -j ACCEPT
   

   pourrait laisser supposer qu’elles sont liées. Or ce n’est pas vrai. la première concerne les connexions entrantes (requêtes DNS reçues) et la seconde les connexions sortantes (requêtes DNS émises), qui sont indépendantes (je ne parle pas de paquets mais de connexions).

5. Ça manque de commentaires explicatifs.

@pyridoxine

Même avec la sortie en DROP, et même sans le port smtp ouvert, mon petit client mail (ssmtp) arrive à envoyer un mail

6. Ssmtp n’est pas un client mail, c’est un MTA (mail transport agent).

7. Les règles suivantes du script autorisent n’importe quelle connexion sortante depuis la machine ou à travers elle :

   iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
   iptables -A OUTPUT -m state ! --state INVALID -j ACCEPT
   
   iptables -A FORWARD -i ens3 -o tun0 -j ACCEPT
   iptables -A FORWARD -i tun0 -o ens3 -j ACCEPT

[pyridoxine]

Merci de votre réponse PascalHambourg !

Je vais essayer de faire de mon mieux pour expliquer.

Sur mon serveur, j’ai effectivement openvpn, afin de pouvoir disposer d’un petit vpn maison lorsque j’en ai le besoin.
Nous sommes deux à l’utiliser, un ami principalement via son pc, et moi, avec mon pc et mon smartphone.
Pour bien scinder le tout, il y a donc 2 ip failover qui sont destinés à mon ami, et mon smartphone, et l’ip même du vps que je m’attribue personnellement avec mon pc.

D’ou ceci :

iptables -t nat -A PREROUTING -d ipfailover1/32 -j DNAT --to-destination 10.8.0.3
iptables -t nat -A POSTROUTING -s 10.8.0.3/32 ! -d 10.8.0.0/30 -j SNAT --to-source ipfailover1
 
iptables -t nat -A PREROUTING -d ipfailover2/32 -j DNAT --to-destination 10.8.0.5
iptables -t nat -A POSTROUTING -s 10.8.0.5/32 ! -d 10.8.0.0/30 -j SNAT --to-source ipfailover2
 
iptables -t nat -A POSTROUTING -s 10.8.0.0/30 ! -d 10.8.0.0/30 -j SNAT --to-source ipduvps
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens3 -j MASQUERADE

Je dispose également d’un pihole sur ce serveur, permettant de filtrer les requêtes dns. il agit uniquement sur l’interface tun0.

J’ai également transmission-daemon dont le port 51413 lui est destiné ainsi que le 9091

De ce fait, je souhaite un serveur avec une politique stricte, je laisse entrer ce que je veux, et sortir ce que je veux.
Mais avec openvpn, ce n’est pas si simple concernant l’output… A la base je le laisse ouvert, car sinon, j’ai toujours des problèmes. Mais là j’ai envie de pousser un peu plus (a savoir si c’est réellement interessant de bloquer l’output… )

Concernant Ssmtp, je ne savais pas ! Mais j’ai dit une bêtise, effectivement, aucun besoin d’avoir un port 587 d’ouvert sur son serveur pour se connecter sur un serveur distant sur ce fameux port 587… Bref.

J’ajouterai enfin, que je ne veux pas que le server soit accessible depuis l’exterieur.
Par exemple on remarque que j’ai ouvert le port 80, 81, uniquement pour l’interface du vpn, de sorte que personne puisse y accéder sans être connecté au vpn.

Exception pour transmission-daemon, ou je le laisse communiquer via sont port 51413, car de toute façon, il n’y a rien à afficher derrière. Au contraire du pannel (via le 9091) que je laisse accessible uniquement via le vpn.

je vous remercie !

[PascalHambourg]

J’oubliais une remarque :

iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEP
iptables -I INPUT -i lo -j ACCEPT

Insérer une règle en début de chaîne avec -I c’est très bien pour modifier le jeu de règles en place, mais il me semble que ça n’a pas sa place dans un script d’initialisation linéaire. Le risque de confusion sur l’ordre effectif résultant est élevé. Ici c’est la seconde qui se retrouvera en premier. Si ces règles doivent être en début de chaîne (ce qui reste à prouver), il suffit de les mettre avant les autres règles de la même chaîne dans le script.

@pyridoxine

Pour bien scinder le tout, il y a donc 2 ip failover qui sont destinés à mon ami, et mon smartphone, et l’ip même du vps que je m’attribue personnellement avec mon pc.

D’accord, ça justifie les règles DNAT+SNAT.
Mais pourquoi le /30 ?
Le /32 est superflu et alourdit la notation.
Et pourquoi n’avoir pas attribué directement les deux adresses IP publiques « failover » aux clients VPN correspondants au lieu de faire du NAT ?

@pyridoxine

Je dispose également d’un pihole

Connais pas.
Le serveur émet et reçoit des requêtes DNS sur l’interface tun ?

@pyridoxine

J’ai également transmission-daemon dont le port 51413 lui est destiné ainsi que le 9091

Il utilise ces deux ports à la fois en entrée et en sortie ?

@pyridoxine

Mais avec openvpn, ce n’est pas si simple concernant l’output

C’est très simple au contraire : tu identifies et autorises uniquement les flux dont tu as besoin. Et tu peux ajouter des règles LOG en fin de chaque chaîne de filtrage pour identifier le trafic qui serait bloqué à tort.

@pyridoxine

a savoir si c’est réellement interessant de bloquer l’output

A toi de décider. Est-ce que tu contrôles vraiment tout ce qui sort de tes machines ?

@pyridoxine

J’ajouterai enfin, que je ne veux pas que le server soit accessible depuis l’exterieur.
Par exemple on remarque que j’ai ouvert le port 80, 81, uniquement pour l’interface du vpn

Le port 81 est accessible par toutes les interfaces :

iptables -A INPUT -p tcp --destination-port 81 -j ACCEPT

@pyridoxine

je le laisse communiquer via sont port 51413, car de toute façon, il n’y a rien à afficher derrière.

Je ne vois pas le rapport avec le fait qu’il y a ait quelque chose à afficher ou pas.

Et le port 32, il sert à quoi ?

[pyridoxine]

Effectivement, je m’en suis rendu compte, je vais remplacer -I par -A.

Concernant les règles nat, j’ai suivi bêtement ce tutoriel et ça marche, mais je me suis posé la question quand même, j’ai essayé de changer, et ça ne fonctionnait plus alors je suis resté sur cette configuration…

Utiliser une IP failover avec OpenVPN | Tech Area

Concernant Pi-Hole, il sert de serveur DNS pour l’interface Tun0 oui !

Pour Transmission-daemon, oui, du moins je pense, mais ça me parait normal du fait qu’il télécharge et envoie via ce port.

Pour les règles LOG, tu penses à :
iptables -A OUTPUT -j LOG ?

Pour le port 81, effectivement, et c’est normal pas de soucis !

Quand je disais qu’il n’y a rien à afficher, c’est à dire qu’il n’y a pas de panel d’administration derrière

Enfin, le port 32, est mon port ssh !

Merci !

[PascalHambourg]

@pyridoxine

Concernant les règles nat, j’ai suivi bêtement ce tutoriel et ça marche, mais je me suis posé la question quand même, j’ai essayé de changer

Changer pourquoi ?

@pyridoxine

Concernant Pi-Hole, il sert de serveur DNS pour l’interface Tun0 oui !

Donc il n’a pas besoin d’envoyer de requêtes DNS sur l’interface tun. Les règles OUTPUT --dport 53 sont sans objet.

@pyridoxine

Pour Transmission-daemon, oui, du moins je pense, mais ça me parait normal du fait qu’il télécharge et envoie via ce port.

La direction des données n’a strictement aucune importance. Ce qui compte, c’est qu’est-ce qui établit la connexion à quoi :

• se connecte-t-il à ce port sur d’autres machines (règle OUTPUT) ?
• d’autres machines se connectent-elles à lui sur ce port (règle INPUT) ?

@pyridoxine

iptables -A OUTPUT -j LOG ?

La même chose à la fin des 3 chaînes, avec un préfixe différent pour les distinguer dans les logs (même si on peut le faire en examinant IN= et OUT=, c’est moins visuel).

[pyridoxine]

Changer pourquoi ?

Je me posais la question de pourquoi /32 pourquoi /30, ou encore pourquoi /24
Du coup, je me suis dis, pourquoi pas essayer d’harmoniser

Donc il n’a pas besoin d’envoyer de requêtes DNS sur l’interface tun. Les règles OUTPUT --dport 53 sont sans objet.

Exacte je supprime.

La direction des données n’a strictement aucune importance. Ce qui compte, c’est qu’est-ce qui établit la connexion à quoi :

• se connecte-t-il à ce port sur d’autres machines (règle OUTPUT) ? : Non pas forcément.
• d’autres machines se connectent-elles à lui sur ce port (règle INPUT) ? Oui !

Après, si laisser ouvert en sortie ne pose pas de problème de sécurité, je n’y vois pas d’inconvénient à le laisser ouvert et ne pas me prendre la tête.

Merci

[PascalHambourg]

@pyridoxine

Je me posais la question de pourquoi /32 pourquoi /30, ou encore pourquoi /24

Très bonne question. Par contre,

@pyridoxine

Du coup, je me suis dis, pourquoi pas essayer d’harmoniser

Qu’est-ce que ça veut dire, « harmoniser » ? Mettre la même valeur partout ? Il n’est pas question de ça mais de mettre les bonnes valeurs.
On commence par virer les /32 qui ne servent à rien : /32, ça représente une adresse unique, donc autant mettre seulement l’adresse, c’est plus court.
A priori 10.8.0.0/24 est le préfixe affecté au VPN, donc on garde.
Reste à justifier 10.8.0.0/30 qui représente les 4 adresses 10.8.0.0 à 10.8.0.3. Qu’est-ce qu’elles ont de particulier ?

@pyridoxine

si laisser ouvert en sortie ne pose pas de problème de sécurité

Ça peut poser problème en cas d’activité anormale du serveur ou des clients VPN, notamment suite à une compromission : envoi de spam, scan de ports, attaque d’autres machines…

[pyridoxine]

@PascalHambourg

On commence par virer les /32 qui ne servent à rien : /32, ça représente une adresse unique, donc autant mettre seulement l’adresse, c’est plus court.

Je le fais de ce pas !

@PascalHambourg

Reste à justifier 10.8.0.0/30 qui représente les 4 adresses 10.8.0.0 à 10.8.0.3. Qu’est-ce qu’elles ont de particulier ?

J’ai attribué à deux client une adresse ip local qui leur son dédié :
L’ip 10.8.0.3 correspond à un pc, et la 10.8.0.5 un téléphone.
Pour des raisons de clairvoyance.

@PascalHambourg

Ça peut poser problème en cas d’activité anormale du serveur ou des clients VPN, notamment suite à une compromission : envoi de spam, scan de ports, attaque d’autres machines…

D’accord, mais nous pouvons aussi admettre que si le serveur à un comportement anormale, c’est que finalement on est entré, a partir de là, je pense qu’il n’y aura pas de soucis pour l’attaquant de laisser sortir ce qu’il veut
Par contre, effectivement c’est plus subtile via les clients vpn ! Mais bon, j’estime le risque assez faible, sachant que les clés privées ont une passephrase, et qu’il faudrait avoir accès à nos ordinateurs & smartphone, les stockants

Finalement, je pense laisser l’OUTPUT ouvert tout de même…

[PascalHambourg]

Le tutoriel semble considérer que le préfixe du VPN est 10.8.0.0/30. Ça ne peut pas être ton cas puisque un des clients utilise 10.8.0.5 qui est en dehors cette plage. Quels plage/masque as-tu définis dans la configuration d’openVPN ?

D’autre part le tutoriel ne mentionne pas la règle MASQUERADE qui ferait double emploi avec la règle SNAT précédente si le préfixe de cette dernière était correct.

@pyridoxine

si le serveur à un comportement anormale, c’est que finalement on est entré, a partir de là, je pense qu’il n’y aura pas de soucis pour l’attaquant de laisser sortir ce qu’il veut

Non, l’attaquant n’a pas forcément réussi à acquérir les privilèges root nécessaires à la modification des règles iptables, mais pas nécessaires pour lancer des attaques sur le réseau.

[pyridoxine]

@PascalHambourg

Quels plage/masque as-tu définis dans la configuration d’openVPN ?

Est-ce ceci ? :

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
      inet 10.8.0.1  netmask 255.255.255.0  destination 10.8.0.1

@PascalHambourg

D’autre part le tutoriel ne mentionne pas la règle MASQUERADE

Oui, c’est une règle que j’avais par défaut pour que le vpn fonctionne.
Si on doit faire abstraction des règles nat etc, la configuration pour que openvpn fonctionne est la suivante :

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens3 -j MASQUERADE
iptables -A INPUT -i tun0 -j ACCEPT
iptables -A FORWARD -i ens3 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o ens3 -j ACCEPT
iptables -A INPUT -i ens3 -p udp --dport 1194 -j ACCEPT

D’ailleurs, je n’ai pas pris soin d’appliquer :

iptables -A INPUT -i tun0 -j ACCEPT

Est-ce que ça poserait un souci de laisser tout entrer sur tun0, sachant que tout est fermé à l’exception de ce que je souhaite laisser ouvert sur mon interface par défaut ens3 (disposant de l’ip de base) ens3:1 (ipfailover 1) et ens3:2 (ipfailover 2) ?
Car à la base mon idée est de ne rien laisser ouvert en public, comme le serveur web sur le port 80, et d’y accéder que en local, et donc openvpn est là entre autre pour ça aussi…

@PascalHambourg

Non, l’attaquant n’a pas forcément réussi à acquérir les privilèges root nécessaires à la modification des règles iptables, mais pas nécessaires pour lancer des attaques sur le réseau.

Pas faux !

[PascalHambourg]

@pyridoxine

Est-ce ceci ?

Ça fera l’affaire. 255.255.255.0 = /24.

@pyridoxine

Oui, c’est une règle que j’avais par défaut pour que le vpn fonctionne

Cette règle ne sert à rien pour le VPN. Elle ne sert que pour que les clients puissent accéder à internet via le VPN.

@pyridoxine

Est-ce que ça poserait un souci de laisser tout entrer sur tun0, sachant que tout est fermé à l’exception de ce que je souhaite laisser ouvert sur mon interface par défaut ens3

Ce que tu filtres sur une interface n’a aucun rapport avec ce que tu filtres sur une autre interface.
On en revient à l’expression du besoin. D’abord, on définit clairement ce qu’on veut. Ensuite seulement on écrit des règles pour l’appliquer.

[pyridoxine]

@PascalHambourg

Ce que tu filtres sur une interface n’a aucun rapport avec ce que tu filtres sur une autre interface.
On en revient à l’expression du besoin. D’abord, on définit clairement ce qu’on veut. Ensuite seulement on écrit des règles pour l’appliquer.

De base, avoir openvpn sur mon vps, afin de pouvoir naviguer sur internet au travers de ce dernier (et donc de ne pas exposer mon ip personnelle), de plus, y avoir installé pihole sur le vps, filtrant les requêtes dns qui passent par le vpn, me permet de naviguer en bloquant pub et trackers.

Egalement, je souhaite avoir un serveur web qui soit accessible uniquement si on se connecte au travers du vpn.
C’est le cas du port 80, derrière j’ai entre autre le panel de pihole, et je ne veux pas laisser le panel en libre accès.

Après il y a transmission-daemon, pour télécharger mes distributions linux en torrent.

Jusque là, la configuration fonctionne plutôt correctement…
Quand je me connecte via mon vpn, je peux naviguer sur internet sans soucis, accéder à mon serveur web (dont je ne peux pas y avoir accès sans connexion vpn, sauf sur le port 81), et mettre à télécharger mes distributions (dont le panel n’est pas accès au publique)

Pour l’apparition des règles nat, c’est à cause du fait qu’a plusieurs devices utilisant la même ip du vps, j’avais des soucis avec google entre autre.
Donc j’ai acheté 2 ip failover pour les attribuer à 2 devices différents.

Voilà

[PascalHambourg]

Bien, maintenant il faut traduire tout ça en flux réseau : source, destination, protocole, port…

@pyridoxine

à cause du fait qu’a plusieurs devices utilisant la même ip du vps, j’avais des soucis avec google entre autre.

Quel genre de soucis ? Les box internet font du NAT avec une seule adresse IP publique pour tous les postes qui sont derrière, je n’ai jamais entendu parler de problème avec Google.

[pyridoxine]

@PascalHambourg

Quel genre de soucis ? Les box internet font du NAT avec une seule adresse IP publique pour tous les postes qui sont derrière, je n’ai jamais entendu parler de problème avec Google.

Celui-ci : https://support.google.com/websearch/answer/86640?hl=fr

@PascalHambourg

Bien, maintenant il faut traduire tout ça en flux réseau : source, destination, protocole, port…

Je te propose de te soumettre un peu plus tard une version simplifiée de mon iptables, et d’annoter pour dire ce que je comprends !

Et voilà @PascalHambourg :

#!/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

#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

#Redirection du traffic de 10.8.0.3 vers l'ip fail over 1
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 ! -d 10.8.0.0/24 -j SNAT --to-source ipfailover1

#Redirection du traffic de 10.8.0.5 vers l'ip fail over 2
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 ! -d 10.8.0.0/24 -j SNAT --to-source ipfailover2

#Redirection du traffic des autres clients vers l'ip de base du vps
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source ipvps

#Permettre aux clients vpn de naviguer sur internet. 
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens3 -j MASQUERADE

#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

# OU BIEN : 

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

#ET  alors : 

#DNS

iptables -A INPUT -i tun0 -p tcp --destination-port 53 -j ACCEPT
iptables -A INPUT -i tun0 -p udp --destination-port 53 -j ACCEPT

#Web
#Panel uniquement accessible via vpn
iptables -A INPUT -i tun0 -p tcp --destination-port 80 -j ACCEPT

iptables -A INPUT -i tun0 -p tcp --destination-port 443 -j ACCEPT

iptables -A INPUT -p tcp --destination-port 81 -j ACCEPT


####												####

#Transmission-daemon
#Panel uniquement accessible via vpn
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

[PascalHambourg]

1. Il manque la politique par défaut de la chaîne OUTPUT.

2. Les deux dernières règles de nat POSTROUTING font double emploi.
   A mon avis, la règle MASQUERADE est superflue. Pire : elle pourrait affecter n’importe laquelle des 3 adresses IP publiques à une connexion sortante.
   Note : au lieu de spécifier le préfixe de destination ! -d 10.8.0.0/24, tu pourrais spécifier l’interface de sortie -o ens3.

3. Les commentaires « redirection du trafic » sont incorrects. Dans les deux premiers cas il ne s’agit pas de redirection mais d’un mapping bidirectionnel pour les flux entrants et sortants. Dans le troisième, il s’agit d’un mapping unidirectionnel pour les flux sortants.

4. Le commentaire "#Ne pas laisser le traffic entrer sur l’interface tun0 sans restriction. " avant une règle commentée me laisse perplexe.

5. Les commentaires « # DNS » et « # Web » sont trop vagues.

6. Il manque un commentaire pour la règle du port 81. Par ailleurs celle-ci devrait être placée avant les règles concernées par « # OU BIEN » car elle ne fait pas partie de l’alternative.

7. Les règles pour transmission-daemon ont disparu. Finalement il n’a plus besoin d’accepter des connexions entrantes ? Je croyais que le principe du P2P était d’être à la fois client et serveur.

[pyridoxine]

J’ai essayé de faire au mieux, mais je suis certain que je ne vais pas pouvoir naviguer correctement via mon vpn dans la configuration ou je bloque l’output. Et je n’arrive pour le moment pas à faire fonctionner les logs d’iptables avec LOG.

#!/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 DROP


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


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


#Port SSH
iptables -A INPUT -p tcp --destination-port 32 -j ACCEPT
iptables -A OUTPUT -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
iptables -A OUTPUT -o ens3 -p udp --dport 1194 -j ACCEPT


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


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

#Transmission-daemon
iptables -A INPUT -p tcp --dport 51413 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 51413 -j ACCEPT
iptables -A INPUT -p udp --dport 51413 -j ACCEPT
iptables -A OUTPUT -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 DROP


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


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


#Port SSH
iptables -A INPUT -p tcp --destination-port 32 -j ACCEPT
iptables -A OUTPUT -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
iptables -A OUTPUT -o 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
iptables -A OUTPUT -o tun0 -p tcp --destination-port 80 -j ACCEPT

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


#Transmission-daemon
#Panel uniquement accessible via vpn
iptables -A INPUT -i tun0 -p tcp --destination-port 9091 -j ACCEPT
iptables -A OUTPUT -o tun0 -p tcp --destination-port 9091 -j ACCEPT


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

[PascalHambourg]

@pyridoxine

je suis certain que je ne vais pas pouvoir naviguer correctement via mon vpn dans la configuration ou je bloque l’output.

Je n’ai pas parlé de bloquer quoi que ce soit mais de définir la politique par défaut d’OUTPUT (à ACCEPT ou DROP) car on ne sait pas dans quel état elle se trouve. C’est comme le vidage des chaînes avec -F, on ne sait pas ce qu’elles contiennent donc on vide tout.

[pyridoxine]

@PascalHambourg

Je n’ai pas parlé de bloquer quoi que ce soit mais de définir la politique par défaut d’OUTPUT (à ACCEPT ou DROP) car on ne sait pas dans quel état elle se trouve. C’est comme le vidage des chaînes avec -F, on ne sait pas ce qu’elles contiennent donc on vide tout.

Ah oui je vois…
Je n’ai rien précisé car je sais qu’avec le « flush » en début de script, l’input / forward /output, se remettent en ACCEPT

[PascalHambourg]

@pyridoxine

Je n’ai rien précisé car je sais qu’avec le « flush » en début de script, l’input / forward /output, se remettent en ACCEPT

Non, -F ne modifie pas la politique par défaut. C’est d’ailleurs pour cela qu’on doit définir la politique par défaut AVANT d’effacer les règles.