Effectivement
Effectivement je me trompe ou effectivement tu ne sais pas comment ça marche ?
1 J'aime
Bon, en fait, seul tes “exceptionnels” ont vraiment besoin d’aller sur le net complétement, mais les “normaux”, eux, finalement, ils n’ont besoin que de pouvoir surfer un peu en http/https, aller faire des recherches sur google et quelques sites ?
C’est ça ?
Ce qu’ils ont au travers du squid leur suffit ?
Dans ce cas, avec la config (transparente ou pas c’est toi qui vois ce qui marche), tu ne configures le masquerade sur ton routeur >que pour les “exceptionnels”.
La, les “normaux” auraient accés uniquement au web http que tu veux dans le squid, sans contournement possible, alors que les “exceptionnels” auront un fonctionnement full normal.
C’est ça qu’il te faudrait ?
@PascalHambourg Effectivement, tu as raison, avant cette fois, je n’ai jamais touché à iptables. Je découvre au fur et à mesure avec ce cas.
@mattotop
T’as plus ou moins cerné la problématique, en réalité même sans contournement, il est possible de faire 2 groupes, les “normaux” avec restriction streaming et réseaux sociaux, et les “exceptionnels” accès à tout le web. Avec les règles ACL de squid, on définit des plages IP de chaque groupe. Et les deux groupes passent par le proxy.
Là où réside le problème, c’est que certaines applications comme filezilla, la console (pour utiliser le git), certains sites qui utilisent des ports spéciaux, font que même le groupe “exceptionnels” ne peut pas les utiliser. D’où l’intérêt du contournement.
Actuellement; sans restriction, je n’arrive pas à accéder à un serveur FTP distant via Filezilla, même en configurant le proxy dessus. Étrangement, en mode transparent, Filezilla marche impeccablement. Il y a une règle sur les 3 que j’ai inséré, pour le mode transparent, qui a ouvert les ports ftp/sftp.
Tu veux utiliser le proxy en mode transparent ou pas ? En mode normal (proxy explicite), il n’y a aucune interaction entre la fonction proxy et la fonction routeur NAT, c’est donc relativement simple à mettre en place avec les exceptions. En mode transparent en revanche, il y a des interactions entre la fonction proxy et la fonction routeur NAT donc c’est plus compliqué à mettre en place. Et comme tu l’as constaté, un proxy transparent ne fonctionne pas avec HTTPS sans bidouillage lourd et sale (le proxy fait de l’usurpation de certificat et le client est trafiqué pour ne pas s’en offusquer).
@PascalHambourg Effectivement, vu qu’il faut créer un faux certificat et l’installer sur les navigateurs de chaque machine, j’ai laissé tomber cette idée, ça me fait du boulot alors que je voulais réduire la corvée de la config proxy au départ.
Alors proxy transparent, on oublie.
Actuellement, j’ai remis le serveur en proxy explicite, il ne me reste plus qu’à savoir comment créer un contournement pour les adresses exceptionnelles et j’aurais réglé ce cas.
Pour la fonction routeur NAT :
# activation du routage IP (peut aussi être fait dans /etc/sysctl{,.d/*}.conf
systctl net.ipv4.ip_forward=1
iptables -P FORWARD DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# exception
iptables -A FORWARD -i enp1s0 -o enp4s0 -s 192.168.0.x -m state --state NEW -j ACCEPT
# NAT source
iptables -t nat -A POSTROUTING -o enp4s0 -s 192.168.0.0/24 -j SNAT --to 192.168.1.3
Et rien d’autre, donc virer toutes les règles existantes avant.
1 J'aime
@PascalHambourg merci pour ce code; je dois tout de même comprendre ce qu’il fait.
Le routage est déjà activé.
En suite, je vois qu’il faut changer la police de sécurité et bloquer toutes les redirections; excepté ceci:
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
et je ne sais pas ce qu’elle fait.
Ensuite, en ajoute l’exception, on accepte les paquets, qui sont expédiés par l’adresse définie après -s (qui veut dire source), et qui vont de la carte enp1s0, qui se trouve être coté local vers la carte enp4s0, celle coté modem. ça veut dire, données sortantes, vers internet. En revanche, j’ignore pourquoi il y a le mot “FORWARD”.
Ensuite, le “NAT source”, une règle qui intervient après routage, il me semble, et je ne comprends pas le reste.
JE ne veux pas faire mon rabat-joie, mais je me souviens, que sur l’ancienne machine, le script shell que j’utilisais pour ajouter et supprimer les IP exceptionnelles (et je rappelle que ce n’est pas mi qui l’ai créé), il y avait au début, iptables … etc. je me souviens d’un -s suivi d’une suite d’adresses IP séparées par des virgules; et le tout en une seule ligne. Il n’y avait pas pas la partie “NAT source”.
Il n’est pas question de redirections. La chaîne FORWARD voit passer les paquets qui traversent la machine d’une interface à une autre lorsque la machine fonctionne en routeur. Cela n 'a strictement rien à voir avec le “port forwarding” traduit par “redirection de port”.
La chaîne qui t’intrigue accepte les paquets appartenant ou liés aux connexions dont le paquet initial a déjà accepté. Les règles d’exceptions ont pour but d’accepter ce paquet initial dans les cas prévus.
Le NAT source remplace l’adresse IP source d’origine par l’adresse IP spécifiée, qui est celle de l’interface de sortie, afin que le routeur suivant, s’il ne connaît pas le sous-réseau des postes, sache où renvoyer les réponses. S’il a une route pour ce sous-réseau, la règle SNAT n’est pas nécessaire.
Je comprends mieux; et en effet j’avais compris “forwarding”.
Je teste ça demain. Merci.
Bonjour, ça marche bien. Mais ça reste différent de l’ancienne machine car les adresses exceptionnelles étaient ajoutées sur la table nat.
J’ai aussi réussi à faire fonctionner filezilla, j’ai ajouté le port 22 à l’acl SSL_ports et au Safe_ports, acl ftp proto FTP, http_access allow ftp, puis configuré le proxy sur filezilla.
Merci à vous tous.
Avec des règles de ce genre ?
iptables -t nat -A POSTROUTING -s 192.168.0.x -j MASQUERADE
La table nat ne sert pas à faire du filtrage, il est plus propre de gérer les autorisations/blocages dans la table filter comme je l’ai proposé.
La règle SNAT/MASQUERADE (NAT source) ci-dessus ne bloque pas les paquets émis depuis d’autres adresses, elle les laisse sortir sans changer leur adresse source, à laquelle le routeur suivant (ici modem-routeur VDSL) ne pourra pas répondre s’il n’ a pas de route correspondante. C’est cette absence de routage retour qui empêche les communications vers l’extérieur. Mais si le routeur a une route de retour pour le sous-réseau 192.168.0.0/24, alors le système d’exception par NAT source est inopérant puisque toutes les communications passent. Le filtrage dans la chaîne FORWARD de la table filter, en revanche, fonctionne dans tous les cas.
@PascalHambourg Bonjour, oui des règles de ce genre. Alors peut être qu’il y avait une configuration de routage retour dont j’ignorais l’existence.
J’ai un autre petit souci que j’ai constaté hier. Actuellement, tout marche bien:
1- Le proxy est en mode explicite
2- Les règles de restrictions squid fonctionnent
3- Filezilla se connecte aux serveurs FTP distant
4- Je n’ai toujours pas ajouté d’IP exceptionnelles, car il n’y a pas de raison pour le moment. Et j’aimerais que ça reste comme ça.
J’en conclue que les règles de routage ne sont pas nécessaires; mais je les ai laissé et sauvegardé dans un fichier avec la commande iptables-save, au cas où.
Alors voilà le souci, en temps normal, je ne peux pas ping un NDD derrière le proxy, j’ai activé ufw pour voir si ça changeait quelque chose
ufw enable
je refais un ping, ça ne marchait toujours pas, je désactive ufw pensant qu’il n’était pas en cause
ufw disable
je refais un ping, surprise, ça marche, le ping marche derrière le proxy. Je n’arrive pas à comprendre en quoi le fait d’activer et de désactiver ufw juste après sans rien faire entre les deux commandes, fait que la commande ping marche derrière le proxy.
Par la même occasion, le enable/disable, me créer une très longue liste de chaines et de tables dans iptables, alors qu’avant, il ne le faisait pas.
S’il y avait une configuration de routage retour toutes les communications pourraient passer en direct sans règles NAT d’exception. L’efficacité des règles d’exception de type NAT repose sur l’absence de routage retour, en cela il est peu fiable. En plus il laisse fuir des paquets vers l’extérieur. L’efficacité des règles d’exception par filtrage dans FORWARD est indépendant de la présence ou de l’absence du routage retour, en cela il est plus fiable.
Quelles règles de routage ? iptables ne fait pas de routage.
La règle iptables SNAT/MASQUERADE est nécessaire pour cela. Et si tu ne veux pas que toutes les communications directes passent, il faut ajouter les autres règles FORWARD et une règle pour autoriser le ping sortant :
iptables -A FORWARD -i enp1s0 -o enp4s0 -p icmp --icmp-type echo-request -j ACCEPT
Compare la sortie de la commande iptables-save avant et après.
Il ne faut surtout pas combiner ufw (ou une autre surcouche d’iptables) avec tes propres règles iptables. Utilise soit l’un, soit l’autre. Si ce que tu veux faire est trop compliqué à mettre en place avec ufw, utilise iptables.
@PascalHambourg
iptables gère le pare-feu, mais cette commande
iptables -t nat -A POSTROUTING -o enp4s0 -s 192.168.0.0/24 -j SNAT --to 192.168.1.3
créé une route de retour pour les paquets, elle donne le chemin à emprunter; cette action s’appelle bien routage?
La comparaison avec iptables-save donne ceci:
1- avec reboot de la machine, pour annuler tout ce que ufw a fait, iptables-save n’affiche que les règles NAT/MASQUERADE et SNAT que tu m’avais donné plus haut, pour ajouter les IP exceptionnelles et les tables nat et filter (de mémoire) avec leur chaines, INPUT, OUTPUT, FORWARD etc.
2- après enable/disable du ufw, iptables-save retourne de nouvelles tables avec ses chaines; que lui même a créé, car ces tables son nommées de la sorte: ufw-forward-xxxxx (toujours de mémoire)
Je crois que oui, on parle bien de routage des paquets au travers du noyau dans la doc iptables, mais iptables altère les paquets, elle ne les route pas vraiment (sauf pour cette terminologie au sein du noyau peut être) et l’action que tu décris ici est une redirection.
Le routage c’est le mot utilisé pour le processus de décision de l’endroit ou on envoie un paquet.
1 J'aime
Non, pas du tout. Cette règle ne fait que modifier l’adresse source des paquets, elle n’intervient pas directement sur le routage. Là où elle intervient, c’est que le routeur amont sait router la nouvelle adresse et pourra faire suivre les paquets de réponse qu’il aura éventuellement reçus de l’extérieur alors qu’il ne sait pas router l’adresse originale.
Sans la règle supplémentaire que j’ai indiquée un peu plus haut pour autoriser le ping, ce jeu de règles bloque le ping provenant des adresses ne bénéficiant pas d’une exception.
Ben oui, et il faut regarder ce qui autorise le ping dans ce fatras. Je suppose qu’il y a du SNAT/MASQUERADE dans la table nat et du ACCEPT partout dans la table filter ?
@PascalHambourg Très bien, le modem sait router, on lui indique juste l’adresses de destination pour le retour, à savoir le 192.168.1.3.
La dernière règle que t’as posté, autorise les paquets ICMP, c’est bien ça? et pour tout le monde. ça ne constitue pas une faille exploitable? L’intérêt que la console puisse se connecter à internet, c’est pour que les développeurs puissent utiliser git, car avant ils ne pouvaient pas télécharger les branches derrière le proxy.
À l’heure qu’il est, je suis à la maison, je ne peux pas vérifier, mais oui, de mémoire il y avait beaucoup d’ACCPET.
Non, seulement les paquets ICMP de type “echo request” comme ceux émis par la commande ping et qu’on appelle familièrement “ping”. Il existe d’autres types de paquets ICMP.
A noter que les paquets de réponse au ping (ICMP type “echo reply”) sont acceptés par la règle déjà présente contenant “ESTABLISHED”.
Oui. Tu peux la restreindre à des adresses sources particulières avec -s, comme les exceptions.
Si, bien sûr. Comme tout canal de communication cela peut être exploité. Mais les failles affectant le ping sont devenues rares. Un poste du réseau local pourrait détourner le ping comme support pour un VPN par exemple. Ceci dit on peut déjà le faire avec HTTP ou HTTPS même à travers un proxy. Une machine extérieure malveillante pourrait aussi flooder l’initiateur d’un ping dont elle est la cible (mais c’est pareil avec un serveur web malveillant).
Je ne vois pas en quoi l’autorisation du ping va aider cela.
Je ne vois pas en quoi l’autorisation du ping va aider cela.
Après tes explications, moi non plus je ne vois pas. En fait, l’année dernière, un développeur qui avait l’habitude d’utiliser git ne parvenait pas à se connecter à un serveur (je ne sais pas lequel) pour télécharger les branches d’une application etc. mais après avoir ajouté son IP aux exceptions, il y étais arrivé. J’en ai conclue; que le proxy squid bloquait les connexions à travers la console win.
Cette semaine, en mettant la main à la pâte sur la nouvelle machine (en réalité j’ai tout fait seul), et lorsque je ne pouvais pas ping une adresse web, je me suis rappelé l’histoire de git, et je me suis dit, faussement apparemment, que si j’arrivais à faire en sorte que le ping marche, et bien les commandes git pourraient marcher, et je n’aurais pas à ajouter l’IP de l’utilisateur dans les exceptions.