Régles iptables

Support Debian
#1

Bonjour,

Je connais un peu iptables, mais je ne suis pas un expert.

Je souhaiterai mettre en place un règle simple.

Mon serveur (debian) est derrière une livebox, je fais du NAT (ou plutôt du PAT) des ports des 500 et 4500 en UDP vers l’ip du serveur debian (pour pouvoir monter mon VPN IPSEC). Il faut donc du routage (net.ipv4.ip_forward = 1)

Il héberge d’autres services (web/smtp/…). Je souhaiterai simplement autoriser les accès aux ports 500/4500 UDP depuis l’ip du site distant et bloquer ces deux ports pour toutes les autres IP, et laisser les autres ports ouvert pour tout le monde (en l’occurrence le LAN).

Comment procéder ?
Ce que je connais c’est : on bloque tout et on ouvre ce dont on a besoin. Mais pas là …

Merci.

#2

Hello,

dans ce que tu cherches à faire, il y a peut-être un début de solution avec une règle iptables représentée par le point d’exclamation (!). Pour tes ports 500 et 4500 à ne laisser en accès que par l’IP du site distant comme tu le demandes, on peut imaginer une règle Iptables comportant ce point d’exclamation. Cette règle se terminerait par un DROP et serait précédée par ce point d’exclamation devant l’adresse IP source de ton site distant :

(où 85.158.25.31 serait l’adresse IP de ton site distant) Ce qui ferait comprendre à Iptables que toutes les adresses IP qui ne seraient pas 85.158.25.31 (et voulant se connecter aux ports 500 et 4500) serait DROPées.

Je ne suis pas spécialiste non plus, et ma ligne d’exemple de règles Iptables est sûrement fausse et/ou incomplète(il faudra sûrement l’affiner en précisant par exemple l’interface réseau sur laquelle tu veux que ça se passe), etc… Mais je voulais juste te faire connaître l’existence de cette fonction amenée par ce point d’exclamation. Je me suis basé sur ces deux pages :

frozentux.net/iptables-tuto … TRACKMATCH
frozentux.net/iptables-tuto … c2105.html

Configuration proxy transparent Squid3
#3

Ces pages ne sont pas à jour : la syntaxe actuelle en vigueur depuis pas mal de temps déjà stipule que le ! d’inversion soit placé avant l’option (! -s) et non entre l’option et la valeur. A part cela, la règle me semble correcte, dans l’hypothèse ou tout le reste est à ACCEPT.

La redirection de port de la box modifie l’adresse destination et non le port, donc pour moi c’est du NAT.

Sur la box (forcément, c’est un routeur), mais pas sur le serveur, sauf si ce dernier joue le rôle de routeur entre le réseau local et le site distant.

“Tout le monde” et “le LAN”, ce n’est pas la même chose. En l’absence de filtrage c’est “tout le monde” (y compris le site distant via le VPN) et pas seulement “le LAN”.

#4

[quote=“PascalHambourg”]Ces pages ne sont pas à jour : la syntaxe actuelle en vigueur depuis pas mal de temps déjà stipule que le ! d’inversion soit placé avant l’option (! -s) et non entre l’option et la valeur. A part cela, la règle me semble correcte, dans l’hypothèse ou tout le reste est à ACCEPT.
[/quote]

J’ai réctifié le placement du point d’exclamation dans mon message précédent merci. Sinon je pensais que la règle que j’ai donné faisait office d’exception, et allait quand même fonctionner, ême en ayant la Policy de INPUT en DROP. Mais non, tu as raison, j’ai essayé et rien n’y fait, il faut un INPUT en ACCEPT pour qu’elle fonctionne, c’est dommage. J’ai néanmoins une question : peut-on faire ceci :

Ensuite :

Et à ce moment là dans la nouvelle chaîne UDPSERVER que l’on vient de créer, faire en sorte que la demande du premier message de tof soit applicable ? Mais alors il faudrait faire quoi comme règle dans UDPSERVER concernant les ports 500 et 4500 en UDP venant de l’IP de son serveur distant ?

Et est-ce que c’est faisable ?

#5

Coool pour les régles iptables!!
Je testerai tout ça quand j’aurai trouvé d’où vient le problème de mon VPN, il ne monte plus alors que rien n’a changé …

La nat c’est une translation d’adresse ip1 => ip2 donc tout les ports de l’ip 1 vers tout les ports de l’ip2 (network address translation), le pat c’est la translation d’un seul port.
La fonction NAT dans un routeur de service intégré (ISR) traduit une adresse IP source interne en adresse IP globale. En réalité la fonction DMZ des box font en réalité du NAT.

ben oui justement la box ne fait de VPN et encore moins d’IPSEC, donc le serveur debian via racoon/ipsec me sert de routeur pour atteindre le réseau distant.

#6

Je ne vois pas le message que j’avais écrit en réponse à SylvainMuller, j’ai dû oublier de le valider avant de me déconnecter…

Une règle DROP fait office d’exception par rapport à une politique ACCEPT ou une autre règle ACCEPT. Une règle DROP avec une politique DROP n’a aucun effet, de même qu’une règle ACCEPT avec une politique ACCEPT. On utilise généralement les combinaisons suivantes :

  • politique DROP et règles ACCEPT (bloque tout sauf ce qui est explicitement autorisé)
  • politique ACCEPT et règles DROP (accepte tout sauf ce qui est explicitement interdit).

Pour être indépendant de la politique par défaut, il faut combiner deux règles : une pour accepter les paquets IPSec provenant de 192.0.2.5 (adresse officiellement réservée aux exemples), et une pour bloquer tous les autres paquets IPSec :

iptables -A INPUT -p udp -m multiport --destination-port 500,4500 -s 192.0.2.5 -j ACCEPT iptables -A INPUT -p udp -m multiport --destination-port 500,4500 -j DROP

Les chaînes utilisateur sont rarement indispensables. Elles servent principalement à “factoriser” les conditions, grouper les règles et éviter les répétitions. Comme des sous-programmes.
Dans ton exemple, tous les paquets envoyés dans la chaîne doivent être bloqués, donc elle ne contiendrait qu’une simple règle DROP :

Aucun intérêt, autant faire le DROP directement comme dans ta règle originelle au lieu d’envoyer dans une chaîne.

On pourrait en revanche définir une chaîne utilisateur pour factoriser les conditions communes aux deux règles que j’ai écrites plus haut (dont j’ai modifié l’ordre des conditions pour faire ressortir les points communs) :

iptables -N IPSEC iptables -A INPUT -p udp -m multiport --destination-port 500,4500 -j IPSEC iptables -A IPSEC -s 192.0.2.5 -j ACCEPT iptables -A IPSEC -j DROP

Oui.

Non. Tu confonds l’opération et sa portée. Une règle de NAT peut être sélective selon l’adresse, le port, le protocole… des paquets auxquels elle s’applique. La caractéristique commune est qu’on modifie l’adresse source et/ou destination.

Similairement, le PAT modifie le port source et/ou destination. La combinaison des deux est le NPAT où on modifie à la fois adresse et port.

Mais cela n’a strictement aucun rapport avec la redirection des ports IPSec de la box et aucune pertinence dans le cadre du présent sujet, à savoir les flux UDP du port 500 et 4500. Le “donc” était de trop.

#7

Encore une fois je ne comprends pas l’intérêt de chipoter en public sur un forum à propos de terme technique qui n’ont pas de rapport direct avec la question.
De plus j’ai vérifié la différence entre nat et pat et je pense avoir raison vu les sources (université, cisco, …). et je ne débatterai pas plus la dessus.

Pour le routage du serveur c’était une indication quand à l’utilisation de ce dernier et des rélge à mettre (ou pas) en place.

En tout cas les infos de l’iptable … y a bon !!

#8

L’intérêt, c’est que tout le monde se comprenne en parlant de la même chose dans les mêmes termes. Cisco dit comme moi : PAT = modification du port. Si tu ne veux pas chipoter, utilise le terme NAT de façon générique, cela désigne tous les types de NAT/PAT.

#9

Merci du message, je peux le comprendre difficilement, du coup je ne suis pas sûr de l’avoir compris (j’ai vraiment du mal), je reprends les étapes ci-dessous pour expliquer la logique que j’ai comprise, pourras-tu confirmer si elles sont exactes PascalHambourg stp ?

Dans la problèmatique de tof (et en prenant pour exemple d’adresse IP correspondant à son serveur distant l’adresse : 192.0.2.5), nous n’avons donc qu’à faire les étapes suivantes et ça fonctionnera svp ??

Créer une nouvelle chaîne nommée comme on veut, ici se sera “IPSEC” :

Inclure dans notre chaîne INPUT déjà existente ceci :

Ensuite indiquer dans notre nouvelle chaîne que l’on accepte les connexions depuis le serveur distant de tof comme ceci :

Et ne pas oublier de mettre cette règle à la fin des règles de la chaîne IPSEC(ici nous n’en avons qu’une), pour interdire toute les autres IP possible :

Et voilà, ça va marcher comme ça stp ?

#10

Oui, sauf erreur de ma part. Tu as bien compris la logique.

#11

Tu as de sacrées connaissances, je n’aurais jamais pu la trouver. Avoir l’idée “d’hameçonner” les demandes du serveurs avec la règle des ports qu’il utilise pour la disposer dans Input je trouve ça énorme (enfin la façon dont d’hameçonner), et puis les rediriger vers la chaîne IPSEC j’avais un peu compris, mais je n’aurai pas pensé non plus à la simplicité de la règle que tu as donné pour mettre dans IPSEC pour autoriser le serveur, et celle de fin de règle de la chaîne IPSEC pour DROPer le reste non plus. @ toute

#12

Oui ça semble marcher!!!
C’est cool.
Mais il va falloir tester ça … avec une autre ip public … la ça va pas être facile :slightly_smiling:

#13

Tu l’as compris, on est là en cas de besoin. Ça nous fait même plaisir :049

#14

Modifie temporairement l’adresse autorisée et vérifie que la machine distante ne peut plus se connecter.

#15

Je traduis selon ce que j’ai compris, car ces deux derniers messages peuvent ne pas être clairs pour les lecteurs néophites intéressés par cette solution finale et ses tests finaux, je m’en excuse d’avance auprès de vous deux, vous êtes spécialistes ça se sent, et vous n’avez donc pas eu besoin de traduction, sincères excuses.

[quote=“tof”]Oui ça semble marcher!!!
C’est cool.[/quote]

Donc à ce niveau de la conversation, quand tof nous dit “Oui ça semble marcher!!!” On peut le traduire par un "Oui je viens de tester vos règles Iptables avec la vraie adresse IP du serveur distant dont il est question dans mon premier message. Et ça marche ! Cool ! (si je me trompe, il faut le dire tof stp). Ensuite tof tu nous dis :

Par autre “IP publique qui ne va pas être facile”, tu sous-entendais que tu aurais aimé tester d’un autre endroit que chez toi (par exemple depuis quelqu’un de la famille), afin que depuis l’adresse IP de la BOX de ce membre de la famille, tu puisses voir si on peut transgresser les règles Iptables que tu as établies comme fonctionnant bien donc dans ton message précédent. (là aussi si je me trompe dis-le stp).

Ce à quoi PascalHambourg a dit :

Ce qui voulait dire que tu n’avais qu’à changer temporairement la vraie adresse IP de ton serveur distant dans la règle Iptables de la chaîne IPSEC, par par exemple une au hasard (pour ce test de quelques minutes tu ne risquais pas grand chose, car si cela se trouvait, l’adresse IP hasardeuse que tu aurais défini n’était pas encore allouée à quelqu’un sur le net), de ce fait, Iptables connaissant maintenant une autre adresse IP à autoriser, il n’allait bien sûr plus autoriser ton serveur distant ! @ ce moment là, le test de PascalHambourg prend tout son sens et est lumineux, car si tu te mettais à tester maintenant avec la vraie adresse IP du serveur distant, Iptables ne t’en laissait du coup, plus l’accès du tout ! Tu viens de lui interdire pour ce test ! (mais là aussi il faudra dire si j’ai bien tout compris svp ?)

C’est très difficile pour les gens qui seraient intéressés de comprendre ce topic si on ne développe pas un peu nos réponses, et leur logique, voilà je tenais à m’excuser vraiment d’une quelconque gène, à bientôt :slightly_smiling:

#16

Alors oui j’ai mi en place les règles et le vpn fonctionne donc … le serveur distant (avec son ip public) est connecté.

Pour faire le test oui, je le voyais comme ça, faire des testes depuis une autre ip (publique ou privée). Mais comme c’est de l’udp pas de telnet … va falloir monter une machine de test …

Mais changer l’ip est aussi une bonne solution…

#17

[quote=“tof”]
Mais changer l’ip est aussi une bonne solution…[/quote]

C’est à dire qu’en fait cette solution remplace le test depuis une autre IP, parce que Iptables verra la vraie adresse IP de ton serveur distant, comme l’adresse IP “d’une box de la famille”, en gros comme non-autorisée par les règles Iptables actuelles (je parle de tes règles de tests va sans dire), c’est pour ça que je disais lumineux tout à l’heure pfff !

Dis nous si ça marche, tiens nous au courant aussi si tu as voulu tester depuis une “vraie autre IP”, à toute !

(moi ça m’intéresse en tous cas si t’as pas compris!)

#18

Je viens de faire les tests et ça fonctionne (donc ça bloque ce qui n’est pas autorisé) :

  • vpn OK
  • coupure de racoon
  • flush des règles iptables (iptables -F ; iptables ; X)
  • application de la nouvelles règle (avec une mauvaise ip) : iptables -N IPSEC ; iptables -A INPUT -p udp -m multiport --destination-port 500,4500 -j IPSEC ; iptables -A IPSEC -s 1.2.3.4 -j ACCEPT ; iptables -A IPSEC -j DROP
  • relance de racoon
  • pas de vpn monté (rien dans les logs, et les deux réseaux ne parlent pas)
  • arrêt de racoon
  • flush des règles
  • applications des bonne règles iptables -N IPSEC ; iptables -A INPUT -p udp -m multiport --destination-port 500,4500 -j IPSEC ; iptables -A IPSEC -s ma_vrai_ip_public -j ACCEPT ; iptables -A IPSEC -j DROP
  • relance de racoon
  • le vpn est op (logs qui causent et traffic réseau ok).

Donc c’est ok

#19

C’est ce type de retour qui me fait plaisir, content d’avoir pu aider.

@ toute :049

#20

A la différence de telnet, netcat (nc), donc il existe plusieurs variantes plus ou moins équivalentes, permet de communiquer en TCP ou en UDP.