Bonjour,
J’ai une passerelle chez moi avec squid+dansguardian.
Iptables redirige les requêtes vers le serveur avec deux règles :
iptables -t nat -A PREROUTING -i br0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -i br0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080Et donc ?
Oui, j’ai été interrompu !
Et bien lorsque j’applique ces règles, les connexions skype, snapchat et autres ne passent plus.
Y-a-t-il d’autres ports à rediriger pour ces services ?
Est-ce Squid qui bloque ??
J’ai trouvé çà :
Pour que Skype puisse fonctionner correctement, les ports suivants doivent être ouverts dans votre pare-feu :
443/TCP
3478-3481/UDP
49152-65535/UDP + TCP
Donc
iptables -t nat -A PREROUTING -i br0 -p udp -m udp --dport 3478-3481 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -i br0 -p tcp -m tcp --dport 49152-65535 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -i br0 -p udp -m udp --dport 49152-65535 -j REDIRECT --to-ports 8080Squid est un proxy HTTP. Je doute que ce qui passe sur ces ports en TCP soit du HTTP.
En revanche je n’ai aucun doute sur le fait que les flux UDP ne sont pas du HTTP et ne peuvent être traités par un proxy HTTP.
En bref : marchera pas.
si je relis la doc :
Donc cette règle devrait suffir ?
iptables -A INPUT -p tcp -m tcp --dport 49152-65535 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 49152-65535 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 3478-3481 -j ACCEPT
Si les règles sont bonnes (?!?) dois-je spécifier une interface (br0) ?
Sur la passerelle ? Sûrement pas, elle n’est pas la destinataire de ces flux.
INPUT = paquets destinés à la machine.
Je tourne en rond. Je ne comprends pas ou plutôt c’est nébuleux.
Quand tu dis ‘à la machine’, tu veux dire les paquets destinés au système de fichier qui se trouve sur la machine ?
Exemple : depuis mon serveur-debian, un apt-get update passe par le port 80. Si je ferme tout (iptables -P output DROP), je devrais ensuite ré-ouvrir ce port uniquement pour la machine et les mises à jour ?
iptables -A OUTPUT -o eth0 -p tcp --dport 80 -s 192.168.1.10 -j ACCEPT
L’adresse de la machine est 192.168.1.10 ?
L’adresse de la passerelle est celle du pont ? 172.16.10.1 ?
root@serveur-debian:~# host 192.168.1.10
10.1.168.192.in-addr.arpa domain name pointer pc2.home.
root@serveur-debian:~# hostname
serveur-debian
host serveur-debian
Host serveur-debian not found: 3(NXDOMAIN)
J’ai du mal !!! Mais à force de relire je crois que je commence à entrevoir ce qui se passe.
http://g.urroz.online.fr/doc/ch02s02.html
Si on suit ce schéma (plus facile pour moi que d’autres), les machines du reseau local ne sont pas concernées par les règles des chaines INPUT et OUTPUT de la table filter puisqu’elles sont dans le reseau 2 (LAN).Par contre je peux mettre des règles les concernant dans la chaine FORWARD de la table Filter.
Donc si je veux permettre l’écoute sur le port UDP d’une des machines du LAN, je dois renseigner cette chaine :
iptables -I FORWARD -p udp -m udp --dports 3478-3481 -d 172.16.10.0/28 -j ACCEPT
La décision de routage (juste après le cercle rose Nat prerouting) correspond-elle au pont br0 (redirection des paquets en fonction de leur destinataire) ?
C’est pour la même machine que dans ton autre sujet ?
Oui. Je souhaite tout fermer et filtrer ce qui arrive surtout.
Cette règle laisse transiter les paquets UDP reçus par le routeur et destinés aux ports et adresses du LAN spécifiés. Cela n’a pas grand-chose à voir avec le fait de permettre l’écoute sur un port UDP de la machine de destination. L’écoute est une chose, la réception effective de paquets en est une autre.
Par contre, je ne suis pas certain que cette règle soit utile pour laisser passer le trafic de Skype. Je pense qu’il faut plutôt accepter les paquets transitant du LAN vers l’extérieur (et les paquets de réponse dans l’autre sens avec l’état ESTABLISHED, mais je suppose que tu as déjà des règles pour cela).
Oui, c’est exactement ce que je veux. Je pourrais même spécifier uniquement les adresses des 2 smartphones utilisés dans la maison et qui sont les seuls à utiliser ces ports.
Dans le message situé un petit peu plus haut, j’ai joint un schéma. Je l’ai adapté à mon cas en mettant la livebox à la place de ‘décision de routage 1’ et mon serveur-debian à la place de ‘décision de routage 2’. Est-ce bien cela ?
Pour faire plus simple, je te joins mon schéma du reseau. Je ne suis pas trop satisfait. Mais faut bien avancer !
J’ai oublié de joindre le schéma !
Je ne comprends pas la différence. Pour moi un port c’est une porte. Elle est ouverte ou fermée. Ouverte, les paquets passent et arrivent à la machine qui les a demandés. Car au début il y a une requête sortante je suppose et un retour qui se fait par les ports spécifiés, non ?
Oui, lorsque je suis tombé sur un article parlant de çà, je me suis dit que s’était pas mal.
Il faut que j’ajoute çà dans mes règles : ‘-m state --state RELATED,ESTABLISHED’
Le problème est que je n’ai pas forcément la liste des ports utilisés par tous ces services.
Il faudrait que je récupère les ports utilisés par ces services lorsqu’ils sont actifs sur mon reseau. Quel outil peut faire çà sous debian ?
Non, mes tables sont vides. Pour le moment.
iptables -I FORWARD -m state --state RELATED,ESTABLISHED -p udp --dports 3478-3481 -s 172.16.10.0/28 -j ACCEPT
Cette règle laisse sortir les paquets venant du LAN vers l’extérieur et n’accepte en retour que ceux qui ont été envoyés par la machine par les ports udp 3478 à 3481.
Il faudra ensuite des règles (quelques unes je pense) pour laisser entrer sur le LAN l’essentiel : port 80, 443, ssh, ftp, …) ; à ce propos, il y a une liste quelque part des ports les plus fréquents utilisés ?
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -i br0 -o eth0 -sport 80 -s 172.16.10.0/28 -J ACCEPT
Mais est-ce ce dont tu as besoin ?
L’écriture de règles iptables nécessite de connaître les caractéristiques des flux à filtrer. Dans toute communication TCP ou UDP, il y a deux ports : un côté client, et un côté serveur. Le port côté client est généralement aléatoire, et le port côté serveur est généralement fixe et connu à l’avance, ce qui permet d’écrire les règles.
Dans un paquet envoyé par le client au serveur, l’adresse et le port source (-s, --sport) sont ceux du client et l’adresse et le port destination (-d, --dport) sont ceux du serveur. Réciproquement, dans un paquet envoyé par le serveur au client, l’adresse et le port source sont ceux du serveur et l’adresse et le port destination sont ceux du client.
Ce schéma est obsolète car il manque beaucoup de nouvelles chaînes. Par exemple la table mangle comporte 5 chaînes, mentionnées dans le texte de la page en dessous alors que le schéma n’en montre que deux. Il y a aussi une erreur : la décision de (re)routage en sortie est mal placée. Elle ne traite que les paquets sortant des chaînes OUTPUT, et non ceux sortant des chaînes FORWARD. Et il manque la décision de routage initiale en sortie avant les chaînes OUTPUT.
Dans tes modifications, la mention “livebox décision de routage” en entrée est inappropriée : la décision de routage de la livebox est interne à la livebox et n’a rien à faire dans ce schéma qui décrit un fonctionnement interne à ta passerelle.
La signification des mentions d’adresses IP autour de la décision de routage d’entrée n’est pas claire. Celle du dessous laisse entrendre que seuls les paquets destinés à l’adresse 172.16.10.1 sont envoyés dans la chaîne INPUT puis aux processus locaux (couches supérieures de la pile TCP/IP). Or cet aiguillage vers INPUT s’applique à toutes les adresses locales à la machine, c’est-à-dire configurées sur une de ses interfaces, donc 192.168.1.10 et toute la plage de loopback 127.0.0.0/8.
Pour finir, la mention des réseaux et leurs plages d’adresses à l’entrée et à la sortie du schéma est inappropriée car ce schéma, je le répète, décrit un fonctionnement interne et s’applique quels que soient l’interface et le réseau d’entrée et/ou de sortie.
L’ennui avec les termes “ouvert” et “fermé” est qu’ils peuvent désigner plusieurs notions distinctes et prêtent à confusion.
Un port est juste un numéro utilisé pour le multiplexage des communications. Quand un processus local écoute sur un port, cela signifie juste qu’un paquet reçu par la machine avec ce numéro de port destination est transmis au processus par la pile IP. Cela n’affecte en rien le cheminement du paquet dans netfilter.
Quels paquets ? Ceux qui ont ce port source, ou ce port destination ? Ceux qui sont émis, reçus ou retransmis ?
Si j’autorise les paquets reçus ayant ce port destination mais pas ceux qui sont retransmis, tu considères que le port est ouvert ou fermé ?
Comme je l’ai écrit, la définition de ces termes est floue et j’évite de les employer.
Quant à “la machine qui les a demandé”, on ne peut pas toujours le savoir. L’envoi d’un paquet est à l’initiative de la source, pas du destinataire. On peut juste considérer qu’un paquet est susceptible de correspondre à ce que pourrait attendre une machine en fonction de divers critères.
Sortante pour qui ? Un paquet de requête est sortant pour la machine source, mais entrant pour la machine destinataire. Et “traversant” pour les routeurs intermédiaires.
Il faut bien distinguer le cheminement d’un paquet de ses caractéristiques intrinsèques (adresses et ports source et destination…). Qu’il sorte de la machine source, traverse un routeur ou entre dans la machine destinataire, c’est toujours le même paquet.
En TCP, lorsqu’un serveur qui écoute sur le port X reçoit une demande de connexion depuis un port source Y, il répond en envoyant un paquet avec le port source X vers le port Y. En UDP, il n’y a pas de connexion donc le serveur peut très bien répondre avec un autre port source que X. Mais pour simplifier le traitement par les pare-feu à état comme iptables, il est d’usage courant d’utiliser le même port de façon similaire à TCP.
Non, pas forcément.
Quels services ?
Cette règle n’accepte rien en retour. Elle n’accepte que des paquets routés en provenance des adresses du LAN et appartenant ou liés à une connexion existante. Autant dire que seule elle ne fait rien puisqu’elle n’accepte pas les paquets dans l’état NEW qui créent de nouvelles connexions. Pour accepter les paquets d’une connexion dans les deux sens, il faut généralement au moins deux règles, une pour chaque sens.
Pour quoi faire ? Il y a des serveurs web, FTP… sur ton LAN qui doivent être accessibles de l’extérieur ?
Tu peux trouver une liste de protocoles connus et leurs ports dans le fichier /etc/services.
Un bon début serait de pouvoir scanner, écouter,… les communications entrantes et sortantes des smartphones pour savoir quels ports et quels protocoles ils utilisent. Ya moyen de faire çà ?
Il y a deux raisons au moins à cela :
1/ Si je ferme tout, je dois ouvrir. Et donc je dois savoir quoi ouvrir pour ne pas bloquer l’utilisation des smartphones;
2/ Je ne peux sécuriser le reseau que si je sais quoi sécuriser.
Bien sûr, par une capture de trafic avec tcpdump ou un de ses semblables sur l’interface wifi.
un tcpdump sur l’adresse ip du smartphone suffit ? Faut peut-être spécifier quelque chose, non ?
# tcpdump wlan0 172.16.10.3
-n pour ne pas résoudre les adresses en noms
-i devant le nom de l’interface
"host" devant l’adresse IP
tcpdump -n -i wlan0 host 172.16.10.3
Attention, ça risque d’être bavard.
Ya moyen de filtrer le contenu pour ne récupérer que les protocoles udp puis tcp avec la commande ‘grep’ vers un fichier.txt ?
tcpdump -n -i wlan0 host 172.16.10.3 | grep 'qquechse' > /home/toto69/tcdumpUDP.txt