Regle Iptables

guigui69 · Février 20, 2016, 7:27pm

Bonsoir à tous, je vais mettre bientot en place un pare-feu au sein de mon entreprise.

j’ai réalisé ceci en suivant différent tuto trouvé sur internet:
(c’est que le début du script)
Situation:

LAN <==>FW<==>WAN

$lan = eth1
$wan = eth0
$serveur1 = 172.16.0.19
$serveur2 = 172.16.0.252
$wsus = 172.16.0.8

#On vide les regles
iptables -F
iptables -X 

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

#processus locaux sont autorisés a fonctionner entre eux
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

#regle SSH LAN vers FW

iptables -A INPUT -p tcp --dport ssh -i LAN -j ACCEPT
iptables -A OUTPUT -p tcp --sport ssh -o LAN -j ACCEPT

#règle des serveurs (exchange, wsus, pop,antivirus)pour qu'il puisse interroger l'extérieur (récuperer mail, requete dns)

iptables -A FORWARD -p udp --dport 53 -i lan -o wan -s $serveur1 -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -i lan -o wan -s $serveur2 -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports pop,smtp,dns -i lan -o wan -s $serveur1 -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports 80,443 -i lan -o wan -s $wsus -j ACCEPT


#rediriger les le flux du port 80 des utilisateur lan  sur le proxy

iptables -A INPUT -p -i $lan -p tcp --dport 80 -j REDIRECT --to-port 3128

Est-ce commis des erreurs? La règle pour redirige le port 80 vers le port du proxy est-elle bonne?

Merci d’avance pour votre aide

guigui69

fran.b · Février 20, 2016, 7:27pm

Oui, les variables passent de majuscules à minuscules et sont sans «$»
Tu n’autorises aucune règle forward ou presque
La dernière règle n’est pas une règle INPUT mais une règle concernant la table NAT (PREROUTING en l’occurrence). Va voir dans T&Astuces http://forum.debian-fr.org/viewtopic.php?f=8&t=1901&start=1 notamment http://forum.debian-fr.org/viewtopic.php?f=8&t=1901&start=125 (vers la fin) j’ai fait des fonctions permettant d’écrire simplement un parefeu de ce type.

guigui69 · Février 20, 2016, 7:27pm

Merci pour ta réponse, le fait qu’il y a majuscule minuscule sans $, s’était déjà pour me repérer facilement entre lan et wan.

Quand tu dt “tu n’autorise aucune regle en forward ou preque” je n’ai pas compris. peux-tu est plus claire.

Merci

guigui69

fran.b · Février 20, 2016, 7:27pm

[quote]iptables -A FORWARD -p udp --dport 53 -i lan -o wan -s $serveur1 -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -i lan -o wan -s $serveur2 -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports pop,smtp,dns -i lan -o wan -s $serveur1 -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports 80,443 -i lan -o wan -s $wsus -j ACCEPT
[/quote]
Tu n’autorises le relais que dans le sens LAN->WAN sur les ports 53, pop, smtp, http et https (venant d’une seule machine pour le dernier cas), mais de toute façon la réponse (WAN->LAN) ne pourra pas passer.

guigui69 · Février 20, 2016, 7:27pm

D’accord,

Mais ma démarche est-elle la bonne?
LAN (serveur, client) <==>FW<==>WAN
En fait je veut que mes serveurs puisse interroger:

serveur DNS (de notre fai),
récupérer les mail (pop)
envoyer les mail (smtp).

Mes utilisateurs eux passeront par un proxy pour accéder à internet. Et tout le reste doit être bloquer.

$lan = eth1
$wan = eth0
$serveur1 = 172.16.0.19
$serveur2 = 172.16.0.252
$wsus = 172.16.0.8
$fw = 172.16.0.140

# Activation du forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

#Vidage des regles
iptables -F
iptables -X 
iptables -t nat -F
iptables -t nat -X

#Politique de restriction par defaut

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

#FW:
#processus locaux sont autorisés a fonctionner entre eux
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

#De LAN vers FW
#regle SSH $lan vers FW
iptables -A INPUT -p tcp --dport ssh -i $lan -j ACCEPT
iptables -A OUTPUT -p tcp --sport ssh -o $lan -j ACCEPT

#rediriger les le flux web des utilisateur $lan  sur le proxy
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to-destination $fw:3128 

#De LAN vers WAN
#regle des serveurs (exchange, wsus, pop,antivirus)
iptables -A POSTROUTING -t nat -o $wan -j MASQUERADE
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur1 -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur2 -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports pop,smtp,dns -i $lan -o $wan -s $serveur1 -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports 80,443 -i $lan -o $wan -s $wsus -j ACCEPT


#du FW vers WAN
#DNS
iptables -A INPUT -i $wan --protocol udp --source-port 53 -j ACCEPT
iptables -A OUTPUT -o $wan --protocol udp --destination-port 53 -j ACCEPT
iptables -A INPUT -i $wan --protocol tcp --source-port 53 -j ACCEPT
iptables -A OUTPUT -o $wan --protocol tcp --destination-port 53 -j ACCEPT
#web (surf)
iptables -A INPUT -i $wan --protocol tcp --source-port 80 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $wan --protocol tcp --destination-port 80 -m state --state NEW,ESTABLISHED -j ACCEPT

Je regarde pour l’histoire du FORWARD.

Merci d’avance pour tes réponses

guigui69

fran.b · Février 20, 2016, 7:27pm

Bon alors, rapidement, comme tu mets tout à DROP, ça n’est pas simple:

Tu n’autorises pas le retour du proxy vers tes clients, les paquets étant «natés», le retour se fera par la passerelle, je pense que ça serait un truc genre

iptables -A OUTPUT -o $lan --protocol tcp --source-port 80 -j ACCEPT

tu as oublié les ports 443, pop, smtp, etc dans les INPUT et OUTPUT
en fait, tes règles m’ont l’air incomplètes: tu es obligé de prévoir le INPOUT, le FORWARD et le OUTPUT dans les deux sens.
Pour le Web, tu devrais n’autoriser la sortie que pour les paquets venant du proxy.

guigui69 · Février 20, 2016, 7:27pm

[quote=“fran.b”]Bon alors, rapidement, comme tu mets tout à DROP, ça n’est pas simple:

Tu n’autorises pas le retour du proxy vers tes clients, les paquets étant «natés», le retour se fera par la passerelle, je pense que ça serait un truc genre

iptables -A OUTPUT -o $lan --protocol tcp --source-port 80 -j ACCEPT

tu as oublié les ports 443, pop, smtp, etc dans les INPUT et OUTPUT
en fait, tes règles m’ont l’air incomplètes: tu es obligé de prévoir le INPOUT, le FORWARD et le OUTPUT dans les deux sens.
Pour le Web, tu devrais n’autoriser la sortie que pour les paquets venant du proxy.[/quote]

Merci pour ta réponse,

Ce n’ai pas bon de tout mettre a DROP?
#2 Pourquoi j’ai oublié 443, pop, smtp en INPUT OUTPUT? sur la machine linux il n’y a que le proxy et le pare-feu
#3 Le proxy est sur le pare-feu et donc sort sur le port 80.

Merci

guigui69

Concernant les forward

#De LAN vers WAN
#regle des serveurs (exchange, wsus, pop,antivirus)
iptables -A POSTROUTING -t nat -o $wan -j MASQUERADE
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur1 -m state --state NEW,ESTABLISHED,RELATED  -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW,ESTABLISHED,RELATED  -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports pop,smtp,dns -i $lan -o $wan -s $serveur1 -m state --state NEW,ESTABLISHED,RELATED  -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports 80,443 -i $lan -o $wan -s $wsus  -m state --state NEW,ESTABLISHED,RELATED  -j ACCEPT
iptables -A FORWARD -i $wan -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT

Est-ce cela te parait mieux?
CI-dessus j’autorise les serveurs à sortir vers le net et j’autorise le retour seulement connexions déjà établies ou en relation avec des connexions établies. Est-ce correcte?

PascalHambourg · Février 20, 2016, 7:28pm

DROP en politique par défaut c’est très bien pour la sécurité puisque tout ce qui n’est pas autorisé explicitement est interdit.

En dehors des fautes de syntaxe avec les variables de shell, je relève des maladresses.

Un pare-feu en entreprise, c’est du sérieux. Pas comme un pare-feu maison bricolé sur sa connexion internet à la maison. Si je devais en écrire un, je procéderais avec un minimum de méthode, avec au minimum trois étapes.

Je décrirais textuellement mon besoin en terme de communications autorisées. Par exemple :

autoriser les requêtes DNS traversantes de serveur1 vers l’extérieur
autoriser les connexions HTTP sortantes vers l’extérieur
autoriser les connexion entrantes au proxy depuis le LAN
etc.

Ensuite je détaillerais la description ainsi obtenue pour l’exprimer en terme de protocoles, ports et adresses source et/ou destination, interfaces d’entrée et/ou sortie… Par exemple :

autoriser les paquets dans FORWARD entrant par $lan, sortant par $wan, avec l’adresse source de serveur1, le port destination 53 en TCP et UDP
autoriser les paquets dans OUTPUT sortant par $wan, avec le port destination 80 en TCP
autoriser les paquets dans INPUT entrant par $lan, avec le port destination 3128 en TCP

Pour finir, je traduirais la description détaillée en règles iptables.

Nous pondre un script sans dire ce qu’il est censé faire comme dans ton message initial et demander si c’est bon, ça n’a pas grand sens. La réponse ne peut qu’être : ça dépend. S’il fait ce que tu veux qu’il fasse, alors c’est bon. S’il fait autre chose, alors c’est pas bon. Mais comme on ne sait pas ce qu’il est censé faire, on ne peut rien dire de plus.

Autre maladresse : ne pas oublier qu’une “connexion”, c’est des paquets aller et des paquets retour, et si on n’autorise pas les paquets retour ça ne sert pas à grand chose d’autoriser les paquets aller. Pourquoi poser une question si on n’écoute pas la réponse ? Le problème : comment identifier une réponse ? Tu y répondu de la mauvaise façon : avec le port source. Non, le port source ne suffit pas pour identifier une réponse au prétexte qu’on peut avoir envoyé une requête vers le même port en destination. Il est facile de contourner ce genre de règle puisque c’est l’émetteur qui définit le port source des paquets qu’il envoie. iptables offre un service bien plus fiable : le suivi de connexion avec ses états NEW, ESTABLISHED, RELATED, INVALID.

En gros : le premier paquet d’une connexion est classé dans l’état NEW, et tous les suivants sont dans l’état ESTABLISHED, qu’ils soient dans le sens aller ou retour. Les paquets liés à une connexion existante (message d’erreur ICMP ou connexion secondaire) sont classés dans l’état RELATED. Les paquets qui n’appartiennent à aucune connexion sont classés INVALID.

Moralité : si on accepte tout ce qui est dans l’état ESTABLISHED ou RELATED dans les trois chaînes, ensuite il suffit d’accepter ou bloquer les paquets NEW au cas par cas pour décider du sort de la connexion tout entière. Ainsi on n’a notamment plus à s’occuper des paquets retour.

guigui69 · Février 20, 2016, 7:29pm

Merci de m’avoir répondu.

J’avais écrit ce que je voulait faire au niveau de pare-feu sur un morceau de papier. (mais pas indiquer sur le post du forum)

LAN (Serveur, Client) <==> FW (Proxy) <==> Internet.

LAN:

J’autorise le serveur 1 et 2 à traverser le pare-feu pour interroger les DNS (tcp & udp port 53).(1)
J’autorise le serveur 1 à réaliser l’envoie de mail (tcp smtp port 25) et la réception des mail en pop3 (tcp port 110).(2)
Redirection du port 80: pour accéder à internet l’ensemble des postes clients devront passer par le proxy. Je devrait donc réaliser une redirection du port 80 vers le port 8080 (en tcp).(3)
Autorise les retours d INTERNET vers LAN seulement au connexion déjà établis ou connexion secondaire. (4)

iptables -A POSTROUTING -t nat -o $wan -j MASQUERADE
(1)iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur1 -m state --state NEW,ESTABLISHED,RELATED  -j ACCEPT
(1)iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW,ESTABLISHED,RELATED  -j ACCEPT
(2)iptables -A FORWARD -p tcp -m multiport --dports pop,smtp,dns -i $lan -o $wan -s $serveur1 -m state --state NEW,ESTABLISHED,RELATED  -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports 80,443 -i $lan -o $wan -s $wsus  -m state --state NEW,ESTABLISHED,RELATED  -j ACCEPT
(3)iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to-destination $fw:8080
(4)iptables -A FORWARD -i $wan -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT

La gestion des états de connexion n’est-elle pas la bonne?
FW:

J’autorise les processus locaux à fonctionner sur le FW.(A)
J’autorise le LAN à pouvoir se connecter en ssh au pare-feu.(B)
J’autorise le FW à naviguer sur le web ( port 53 en tcp & udp, port 80 en tcp).©
J’autorise le LAN à se connecter au port 8080 du FW.(D)

(A)iptables -A INPUT -i lo -j ACCEPT
(A)iptables -A OUTPUT -o lo -j ACCEPT
(B)iptables -A INPUT -p tcp --dport ssh -i $lan -j ACCEPT
(B)iptables -A OUTPUT -p tcp --sport ssh -o $lan -j ACCEPT
(D)iptables -A INPUT -p tcp --dport 8080 -i $lan -j ACCEPT
(D)iptables -A OUTPUT -p tcp --sport 80 -o $lan -j ACCEPT (pas sur de cette règle)
(C)iptables -A INPUT -i $wan --protocol udp --source-port 53 -j ACCEPT
(C)iptables -A OUTPUT -o $wan --protocol udp --destination-port 53 -j ACCEPT
(C)iptables -A INPUT -i $wan --protocol tcp --source-port 53 -j ACCEPT
(C)iptables -A OUTPUT -o $wan --protocol tcp --destination-port 53 -j ACCEPT
(C)iptables -A INPUT -i $wan --protocol tcp --source-port 80 -m state --state ESTABLISHED -j ACCEPT
(C)iptables -A OUTPUT -o $wan --protocol tcp --destination-port 80 -m state --state NEW,ESTABLISHED -j ACCEPT

Merci de ton aide.

guigui69

PascalHambourg · Février 20, 2016, 7:29pm

Elle est perfectible.
Dans les règles (1) et (2), l’état RELATED est superflu : jamais un paquet d’une communication DNS, SMTP ou POP n’aura cet état.
D’autre part, tu n’as pas de règle acceptant les paquets (notamment les messages d’erreur ICMP) dans l’état RELATED dans le sens LAN vers WAN. J’ajouterai une règle symétrique à (4) :

ce qui permet en outre de simplifier les règles (1) et (2) en supprimant l’état ESTABLISHED puisqu’il est pris en charge par cette nouvelle règle, ne reste plus que l’état NEW. A titre d’optimisation, il est intéressant de placer les deux règles ESTABLISHED,RELATED en début de chaîne car elles concernent la majorité du trafic : pour une communication donnée, le premier paquet est NEW et tout le reste est ESTABLISHED ou RELATED.

Concernant les chaînes INPUT et OUTPUT, seules les règles relatives au port 80 sur le WAN gèrent correctement les états de connexions. Les autres règles ne les gèrent tout simplement pas. Si je prends par exemple la règle suivante :

Cette règle permet à n’importe qui sur le WAN de se connecter à n’importe quel port de ta passerelle du moment qu’il utilise le port source 53. Rappelons que c’est l’émetteur qui décide du port source. Donc cette règle est une faille béante.

Le principe doit être le même en INPUT/OUTPUT qu’en FORWARD :

des règles génériques acceptant les paquets dans l’état ESTABLISHED ou RELATED
des règles acceptant le premier paquet des communications autorisées dans l’état NEW.
Exemple :

# suivi de connexion
iptables -A INPUT -i $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH depuis le LAN
iptables -A INPUT -i $lan -m state --state NEW -p tcp --dport 22 -j ACCEPT
(etc.)
# suivi de connexion
iptables -A OUTPUT -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
# DNS vers le WAN
iptables -A OUTPUT -o $wan -m state --state NEW -p udp --dport 53 -j ACCEPT
(etc.)

PS : j’aurais aussi quelques remarques concernant la cohérence entre les spécifications et les règles, mais on verra ça plus tard.

guigui69 · Février 20, 2016, 7:29pm

Voici les modifications de mon fichier par rapport à tes recommandations:

iptables -A FORWARD -i $wan -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -A FORWARD -i $lan -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT

###
###

iptables -A POSTROUTING -t nat -o $wan -j MASQUERADE
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur1 -m state --state NEW  -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW  -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports pop,smtp,dns -i $lan -o $wan -s $serveur1 -m state --state NEW  -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports 80,443 -i $lan -o $wan -s $wsus  -m state --state NEW  -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to-destination $fw:8080


###
###
iptables -A INPUT -i $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT

###
###
#interface local
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
#SSH du lan vers FW
iptables -A INPUT -p tcp --dport ssh -i $lan -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --sport ssh -o $lan -m state --state NEW -j ACCEPT

#proxy 8080 sur FW
iptables -A INPUT -p tcp --dport 8080 -i $lan -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --sport 80 -o $lan -m state --state NEW -j ACCEPT 
#autoriser le FW interroger DNS
iptables -A OUTPUT -o $wan -p udp -dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o $wan -p tcp -dport 53 -m state --state NEW -j ACCEPT
#Autoriser le web
iptables -A OUTPUT -o $wan -p tcp -dport 80 -m state --state NEW -j ACCEPT

Est la bonne démarche? Aurait-je confondu des règles?

Merci

guigui69

PascalHambourg · Février 20, 2016, 7:30pm

Ça commence à prendre forme, mais les règles avec --sport et l’état NEW sont sans objet et sont des trous de sécurité car elles autorisent les connexions vers n’importe quel port depuis les ports sources spécifiés (port source qui est contrôlé par l’attaquant, je rappelle).

Tu as remplacé REDIRECT par DNAT, pourtant REDIRECT était parfaitement approprié.

Concernant non plus la forme mais le fond, je soupçonne de menues incohérences :

$serveur2 n’a accès qu’au DNS en UDP, pas en TCP ni à aucun autres service. Quel intérêt ?
$wsus a accès direct au web mais pas au DNS, ça peut être génant.

guigui69 · Février 20, 2016, 7:31pm

Merci pour ces réponses.

Oui c’est un oubli concernant les serveurs serveur2 et wsus.

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-destination $fw:8080

iptables -A FORWARD -p tcp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW  -j ACCEPT

iptables -A FORWARD -p tcp -m multiport --dports 80,443 53 -i $lan -o $wan -s $wsus  -m state --state NEW  -j ACCEPT

iptables -A FORWARD -p tcp --dport 53 -i $lan -o $wan -s $wsus -m state --state NEW  -j ACCEPT

citation:
Ça commence à prendre forme, mais les règles avec --sport et l’état NEW sont sans objet et sont des trous de sécurité car elles autorisent les connexions vers n’importe quel port depuis les ports sources spécifiés (port source qui est contrôlé par l’attaquant, je rappelle).

Tu veux dire qu’il faudrait que je précise les port de destination et source? c’est bien ?

Merci pour l’aide que tu m’apporte

guigui69

PascalHambourg · Février 20, 2016, 7:31pm

Mauvaise syntaxe pour REDIRECT -> "--to-ports 8080".

[code]iptables -A FORWARD -p tcp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW  -j ACCEPT[/code]
Bon, maintenant serveur2 peut faire des requêtes DNS en TCP et UDP mais rien d'autre si je ne m'abuse. Quel intérêt ?

[code]iptables -A FORWARD -p tcp -m multiport --dports 80,443 53 -i $lan -o $wan -s $wsus  -m state --state NEW  -j ACCEPT[/code]
Manque une virgule entre 443 et 53.

[code]iptables -A FORWARD -p tcp --dport 53 -i $lan -o $wan -s $wsus -m state --state NEW  -j ACCEPT[/code]
Redondant avec la règle précédente. Je suppose que tu voulais écrire "-p udp" ?

[quote="guigui69"]Tu veux dire qu'il faudrait que je précise les port de destination et source?[/quote]
Non. Je veux dire que les règles avec --sport sont à la fois inutiles et dangereuses, donc il faut les supprimer.

Mauvaise syntaxe pour REDIRECT -> “–to-ports 8080”.

Bon, maintenant serveur2 peut faire des requêtes DNS en TCP et UDP mais rien d’autre si je ne m’abuse. Quel intérêt ?

Manque une virgule entre 443 et 53.

Redondant avec la règle précédente. Je suppose que tu voulais écrire “-p udp” ?

Non. Je veux dire que les règles avec --sport sont à la fois inutiles et dangereuses, donc il faut les supprimer.

fran.b · Février 20, 2016, 7:31pm

[quote=“PascalHambourg”]
Non. Je veux dire que les règles avec --sport sont à la fois inutiles et dangereuses, donc il faut les supprimer.[/quote]
Dans un but de sécurité et comme filtre seul, oui elles sont inutiles, c’est ça que tu veux dire?? (Parce que pour la gestion QoS par exemple, on a du mal à s’en passer…)

PascalHambourg · Février 20, 2016, 7:31pm

Je parle spécifiquement des règles de guigui69 du genre de celle-ci

pas de l’utilisation de --sport en général, qui peut être utile même en filtrage.

guigui69 · Février 20, 2016, 7:31pm

Voici mon code modifier:

iptables -A FORWARD -i $wan -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $lan -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT

###
###

iptables -A POSTROUTING -t nat -o $wan -j MASQUERADE
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur1 -m state --state NEW  -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW  -j ACCEPT
iptables -A FORWARD -p tcp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW  -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports pop,smtp,dns -i $lan -o $wan -s $serveur1 -m state --state NEW  -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-ports 8080


###
###
iptables -A INPUT -i $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT

###
###
#interface local
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
#SSH du lan vers FW
iptables -A INPUT -p tcp --dport ssh -i $lan -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --sport ssh -o $lan -m state --state NEW -j ACCEPT

#proxy 8080 sur FW
iptables -A INPUT -p tcp --dport 8080 -i $lan -m state --state NEW -j ACCEPT


#autoriser le FW interroger DNS
iptables -A OUTPUT -o $wan -p udp -dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o $wan -p tcp -dport 53 -m state --state NEW -j ACCEPT
#Autoriser le web
iptables -A OUTPUT -o $wan -p tcp -dport 80 -m state --state NEW -j ACCEPT

Au niveau des serveurs:

Seul les serveur 1 et 2 sont autorisé à sortir sur internet pour interroger les dns.
Le serveur 1 (messagerie exchange interne) est le seul autorisé a récupérer les mail en pop et envoyer les mails au smtp de notre fai.
Le serveur wsus, n’a enfaite pas besoin d’accès dns (il utilise les dns des serveur 1 et 2) et pour télécharger ces maj ou accéder au web il passera par le proxy (ou je l’autoriserait).

Au niveau pare-feu:

J’autorise le par feu a accéder à internet (80 & 53).
J’applique la règle pour rediriger les le flux sur le port 80 vers le port 8080 (dansguardian)
J’autorise mon lan à rentrer sur le port 8080 du pare-feu.

Tout ces règles sont accepter avec l’etat NEW. Et Pour réaliser le retour se sont les règles suivante:

iptables -A FORWARD -i $wan -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $lan -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT

Qui autorise ou non le retour en se basant unique sur les l’etat de la connxion (etablis ou bien si il y a une autre connexion).

J’espere que les regles que j’ai ecrit correspond a mon analyse juste apres.

Merci pour ton aide.

guigui69

fran.b · Février 20, 2016, 7:31pm

Voilà comment je traduis tes règles:

[quote]iptables -A FORWARD -i $wan -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $lan -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
[/quote]Toutes les connexions établies sont autorisées.

[quote]###

iptables -A POSTROUTING -t nat -o $wan -j MASQUERADE
[/quote]Masquerading sur ce qui sort sur le WAN.

[quote]iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur1 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dports pop,smtp,dns -i $lan -o $wan -s $serveur1 -m state --state NEW -j ACCEPT
[/quote]serveur 1 et 2 peuvent interroger des DNS sur le WAN
De même pour pop, smtp et dns pour serveur1. Attention pas d’«s» à dport, douvble emploi pour dns.

[quote]#
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-ports 8080
[/quote]eth1 = lan donc. Interception des paquets et renvoit sur le port 8080 de la machine (Squid transparent je présume)

[quote]###

iptables -A INPUT -i $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT

#interface local
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
[/quote]règles minimales usuelles
Puis ça concerne la machine elle même.

[quote]#SSH du lan vers FW
iptables -A INPUT -p tcp --dport ssh -i $lan -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --sport ssh -o $lan -m state --state NEW -j ACCEPT
[/quote]Elle peut être gérée du LAN par ssh

[quote]#proxy 8080 sur FW
iptables -A INPUT -p tcp --dport 8080 -i $lan -m state --state NEW -j ACCEPT
[/quote]elle héberge un proxy pouvant être utilisée du LAN

[quote]#autoriser le FW interroger DNS
iptables -A OUTPUT -o $wan -p udp -dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o $wan -p tcp -dport 53 -m state --state NEW -j ACCEPT
[/quote]elle peut interroger les DNS

[quote]#Autoriser le web
iptables -A OUTPUT -o $wan -p tcp -dport 80 -m state --state NEW -j ACCEPT
[/quote]et le Web

[quote]#
iptables -A FORWARD -i $wan -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $lan -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
[/quote]Vu plus haut donc, une fois les connexions initiées suivant les règles plus haut, les paquets peuvent traverser FW.

[quote]#
iptables -A INPUT -i $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
[/quote]Idem pour INPUT et OUTPUT.
Note: serveur2 ne peut qu’interroger les DNS plus les droits communs à tous, pas de https pour qui que ce soit.

guigui69 · Février 20, 2016, 7:31pm

D’accord,

le porte 8080 est pour dansguardian qui lui envoie après a squid.
Je vais rajouter une règle pour l’https.
Est-ce que cela te parait bien? Sécurisé?

Merci

guigui69

fran.b · Février 20, 2016, 7:31pm

Oui, penses au mises à jour de squid (si tu utilises des listes venant de l’extérieur) mais sur l’usage des machines, c’est toi qui vois.