Iptables : serveur et proxy
Lynow
-
avion-f16 Messages postés 19252 Date d'inscription Statut Contributeur Dernière intervention -
avion-f16 Messages postés 19252 Date d'inscription Statut Contributeur Dernière intervention -
Bonjour,
Je suis en train de configurer iptables pour mon serveur Cortex (outil CTI), qui travaille avec Opensearch pour collecter ses données.
Pour bien comprendre la chose :
J'ai un conteneur sous Debian, dans lequel j'ai installé l'outil Cortex. Pour configurer une connexion SSL, j'ai dû installer sur ce même conteneur un proxy inverse, via le serveur nginx. Ces deux services (cortex et nginx) sont exécutés par un utilisateur non-root, j'ai donc choisis deux nouveaux ports d'écoutes pour nginx : 8080 et 8443.
Cependant, pour faire plus propre côté client, j'ai fais une redirection de port via iptables :
Afin que l'utilisateur puisse se connecter sur http (rediriger sur https) et https.
Ensuite, j'ai ajouté différentes règles de pare-feu.
Voici mon iptables actuelles :
J'ai donc ajouter DROP all pour supprimer toutes les connexions.
Ensuite, j'autorise la connexion du client en http, https. J'ouvre également les ports 8080 et 8443 pour le proxy.
J'ai retiré le port 9000 car il ne sert plus, grâce au proxy.
Cortex stocke ses données sur Opensearch, il faut donc ajouter une règle par rapport à cela pour qu'il puisse communiquer, un OUTPUT à destination de l'adresse IP Opensearch ?
Cela ne fonctionne pas pour l'instant, je pense que c'est dû à la règle pour Opensearch, sinon je ne sais pas ...
Je suis en train de configurer iptables pour mon serveur Cortex (outil CTI), qui travaille avec Opensearch pour collecter ses données.
Pour bien comprendre la chose :
J'ai un conteneur sous Debian, dans lequel j'ai installé l'outil Cortex. Pour configurer une connexion SSL, j'ai dû installer sur ce même conteneur un proxy inverse, via le serveur nginx. Ces deux services (cortex et nginx) sont exécutés par un utilisateur non-root, j'ai donc choisis deux nouveaux ports d'écoutes pour nginx : 8080 et 8443.
Cependant, pour faire plus propre côté client, j'ai fais une redirection de port via iptables :
Chain PREROUTING (policy ACCEPT) target prot opt source destination REDIRECT tcp -- anywhere anywhere tcp dpt:http redir ports 8080 REDIRECT tcp -- anywhere anywhere tcp dpt:https redir ports 8443 Chain INPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination REDIRECT tcp -- anywhere anywhere tcp dpt:8443 redir ports 443
Afin que l'utilisateur puisse se connecter sur http (rediriger sur https) et https.
Ensuite, j'ai ajouté différentes règles de pare-feu.
Voici mon iptables actuelles :
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
44 3872 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
3733 477K DROP all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9000
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8443
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 4231 packets, 281K bytes)
pkts bytes target prot opt in out source destination
J'ai donc ajouter DROP all pour supprimer toutes les connexions.
Ensuite, j'autorise la connexion du client en http, https. J'ouvre également les ports 8080 et 8443 pour le proxy.
J'ai retiré le port 9000 car il ne sert plus, grâce au proxy.
Cortex stocke ses données sur Opensearch, il faut donc ajouter une règle par rapport à cela pour qu'il puisse communiquer, un OUTPUT à destination de l'adresse IP Opensearch ?
Cela ne fonctionne pas pour l'instant, je pense que c'est dû à la règle pour Opensearch, sinon je ne sais pas ...
Configuration: Linux Debian 10
2 réponses
Ok, mon erreur, je crois, est que la commande
J'ai ensuite ajouté un OUTPUT pour Opensearch, cela fonctionne.
sudo iptables -A INPUT -j DROPbloque tout, même les règles enregistrées qui sont définies après cette commande ... (si quelqu'un peut me confirmer la chose). J'ai donc juste modifier la police avec les commandes :
sudo iptables -P INPUT DROP sudo iptables -P FORWARD DROP sudo iptables -P OUTPUT DROP
J'ai ensuite ajouté un OUTPUT pour Opensearch, cela fonctionne.
Bonjour,
Je ne vois pas pourquoi tu crées des règles de redirection côté client.
Il suffit juste de faire une redirection 80 -> 8080 et 443 -> 8443 côté serveur et les clients pourront ainsi accéder à Nginx via les ports standards malgré que Nginx écoute d'autres ports. C'est exactement à cela que servent les redirections.
Voir ici :
https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#REDIRECTTARGET
(je te conseille de garde ce tuto très pratique parmi tes marques pages)
Le deuxième problème, c'est que tu places une règle ACCEPT en-dessous d'une règle DROP qui aurait déjà capturé les paquets visés par ta règle ACCEPT. L'ordre des règles a son importance.
Le 3e problème, je ne sais pas si c'est volontaire ou pas, mais tu bloques le trafic entrant sur des ports différents de ceux spécifiés. Si tu tentes d'accéder depuis le serveur vers du HTTP ou HTTPS externes (pour télécharger des mises à jour par exemple), ton trafic sortant sera à destination des ports 80/443, mais le port source sera aléatoire. La réponse sera donc destinée à ce port aléatoire, et non aux ports 80/443. C'est pour cela qu'il est aussi nécessaire d'autoriser en INPUT les paquets relatifs à une connexion déjà établie (RELATED, ESTABLISHED).
Voir ici :
https://www.digitalocean.com/community/tutorials/iptables-essentials-common-firewall-rules-and-commands#allowing-established-and-related-incoming-connections
Je ne vois pas pourquoi tu crées des règles de redirection côté client.
Il suffit juste de faire une redirection 80 -> 8080 et 443 -> 8443 côté serveur et les clients pourront ainsi accéder à Nginx via les ports standards malgré que Nginx écoute d'autres ports. C'est exactement à cela que servent les redirections.
Voir ici :
https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#REDIRECTTARGET
(je te conseille de garde ce tuto très pratique parmi tes marques pages)
Le deuxième problème, c'est que tu places une règle ACCEPT en-dessous d'une règle DROP qui aurait déjà capturé les paquets visés par ta règle ACCEPT. L'ordre des règles a son importance.
Le 3e problème, je ne sais pas si c'est volontaire ou pas, mais tu bloques le trafic entrant sur des ports différents de ceux spécifiés. Si tu tentes d'accéder depuis le serveur vers du HTTP ou HTTPS externes (pour télécharger des mises à jour par exemple), ton trafic sortant sera à destination des ports 80/443, mais le port source sera aléatoire. La réponse sera donc destinée à ce port aléatoire, et non aux ports 80/443. C'est pour cela qu'il est aussi nécessaire d'autoriser en INPUT les paquets relatifs à une connexion déjà établie (RELATED, ESTABLISHED).
Voir ici :
https://www.digitalocean.com/community/tutorials/iptables-essentials-common-firewall-rules-and-commands#allowing-established-and-related-incoming-connections
Merci encore pour ton aide.
Il y a une chose que je ne comprends pas. Lorsque je veux envoyer des données à un serveur, à partir d'un serveur. Par exemple, prenons le serveur Cortex qui veut envoyer des données à Opensearch.
Pour moi, il suffisait d'autoriser le OUTPUT vers l'adresse IP du serveur. Mais, cela ne fonctionne pas, je dois ajouter OUTPUT -j ACCEPT pour tout accepter. A noter que j'ai ajouté la connexion déjà établie ...
Il y a une chose que je ne comprends pas. Lorsque je veux envoyer des données à un serveur, à partir d'un serveur. Par exemple, prenons le serveur Cortex qui veut envoyer des données à Opensearch.
Pour moi, il suffisait d'autoriser le OUTPUT vers l'adresse IP du serveur. Mais, cela ne fonctionne pas, je dois ajouter OUTPUT -j ACCEPT pour tout accepter. A noter que j'ai ajouté la connexion déjà établie ...
