Problème avec Iptable et un paquet
Fermé
DoctorAngry
Messages postés
159
Date d'inscription
samedi 16 mars 2019
Statut
Membre
Dernière intervention
9 mars 2022
-
Modifié le 28 oct. 2021 à 20:05
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 3 nov. 2021 à 17:58
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 3 nov. 2021 à 17:58
A voir également:
- Problème avec Iptable et un paquet
- Trame paquet segment datagramme - Forum Réseau
- Ce paquet windows installer rencontre un problème stormshield ✓ - Forum Windows
- Os x n'a pas pu être installé sur l'ordinateur aucun paquet n'a pu etre installé - Forum MacOS
- Impossible de trouver le paquet ✓ - Forum Linux / Unix
- Patron paquet de cigarette - Forum Réseaux sociaux
3 réponses
avion-f16
Messages postés
19246
Date d'inscription
dimanche 17 février 2008
Statut
Contributeur
Dernière intervention
21 avril 2024
4 497
Modifié le 29 oct. 2021 à 02:45
Modifié le 29 oct. 2021 à 02:45
Bonjour,
Tout allait bien... jusqu'à la première connexion sortante, en HTTP.
Faut voir dans quel sens tu as ouvert ces ports, ce que tu as bloqué, si tu as autorisé/bloqué les paquets sortants, si tu as autorisé les réponses dans le sens inverse, ...
Nous ne sommes pas devins, merci de donner plus de détails (c'est-à-dire tes règles iptables).
Il n'est pas clair si tu veux autoriser les connexions pour un serveur HTTP(S) et FTP installé sur ton propre système, ou si tu veux filtrer les connexions sortantes de manière à autoriser uniquement le surf (HTTP/HTTPS) et le FTP vers d'autres serveurs.
Si c'est le second cas, tu te trompes... Un utilisateur peut utiliser le fait que tu autorises les ports 21/80/443 comme destination pour se connecter à un serveur quelconque (SSH, VPN, ...) qu'il aura mis sur le port 443 par exemple. Le port n'impose pas le protocole. Et puisque tu autorises les connexions sur le port 443, donc du TLS, l'utilisateur pourrait se connecter à un VPN de type TLS sur le port 443 et contourner tes restrictions. Même si tu fais de la DPI, tu verras du trafic TLS mais sans pouvoir dire si c'est du HTTP via TLS (HTTPS) ou autre-chose.
Je suspecte que tu as bloqué toutes les connexions entrantes, et autorisé les connexions entrantes à destination des ports 21/80/443 en pensant que cela permettrait aussi la communication avec des serveurs distants sur ces ports. C'est faux. Si tu inities une connexion depuis ton système vers un serveur distant sur le port 80, le port source des paquets sortants (ton ordinateur -> serveur distant) sera attribué aléatoirement (mais restera le même durant la communication). Or, c'est ce port source aléatoire qui deviendra le port de destination pour la réponse. C'est grâce à cela qu'il est possible de télécharger simultanément deux fichiers en HTTPS, parce que les deux flux se font à destination de deux ports différents de ton ordinateur (sans oublier qu'il y a sûrement un NAT entre les deux).
Cela signifie que la règle autorisant les INPUT sur le port de destination 80 est sans effet pour accepter les réponses d'une connexion vers un autre serveur sur le port 80. Il faut ajouter un règle pour autoriser les INPUT avec un port source 80, ou bien autoriser les INPUT avec état RELATED / ESTABLISHED.
Voir cette discussion :
https://superuser.com/questions/460621/iptables-firewall-only-allows-internet-traffic-if-source-port-of-80-is-allowed
Le plus simple est d'autoriser tous les paquets sortants, et autoriser les paquets entrants s'ils se rapportent à une connexion sortant déjà initialisée.
Je te recommande ce guide pour débuter :
https://www.digitalocean.com/community/tutorials/iptables-essentials-common-firewall-rules-and-commands
Pour plus de détails :
https://www.digitalocean.com/community/tutorials/a-deep-dive-into-iptables-and-netfilter-architecture
https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html
Et un diagramme utile :
https://en.wikipedia.org/wiki/Netfilter#/media/File:Netfilter-packet-flow.svg
Tout allait bien... jusqu'à la première connexion sortante, en HTTP.
Faut voir dans quel sens tu as ouvert ces ports, ce que tu as bloqué, si tu as autorisé/bloqué les paquets sortants, si tu as autorisé les réponses dans le sens inverse, ...
Nous ne sommes pas devins, merci de donner plus de détails (c'est-à-dire tes règles iptables).
Il n'est pas clair si tu veux autoriser les connexions pour un serveur HTTP(S) et FTP installé sur ton propre système, ou si tu veux filtrer les connexions sortantes de manière à autoriser uniquement le surf (HTTP/HTTPS) et le FTP vers d'autres serveurs.
Si c'est le second cas, tu te trompes... Un utilisateur peut utiliser le fait que tu autorises les ports 21/80/443 comme destination pour se connecter à un serveur quelconque (SSH, VPN, ...) qu'il aura mis sur le port 443 par exemple. Le port n'impose pas le protocole. Et puisque tu autorises les connexions sur le port 443, donc du TLS, l'utilisateur pourrait se connecter à un VPN de type TLS sur le port 443 et contourner tes restrictions. Même si tu fais de la DPI, tu verras du trafic TLS mais sans pouvoir dire si c'est du HTTP via TLS (HTTPS) ou autre-chose.
Je suspecte que tu as bloqué toutes les connexions entrantes, et autorisé les connexions entrantes à destination des ports 21/80/443 en pensant que cela permettrait aussi la communication avec des serveurs distants sur ces ports. C'est faux. Si tu inities une connexion depuis ton système vers un serveur distant sur le port 80, le port source des paquets sortants (ton ordinateur -> serveur distant) sera attribué aléatoirement (mais restera le même durant la communication). Or, c'est ce port source aléatoire qui deviendra le port de destination pour la réponse. C'est grâce à cela qu'il est possible de télécharger simultanément deux fichiers en HTTPS, parce que les deux flux se font à destination de deux ports différents de ton ordinateur (sans oublier qu'il y a sûrement un NAT entre les deux).
Cela signifie que la règle autorisant les INPUT sur le port de destination 80 est sans effet pour accepter les réponses d'une connexion vers un autre serveur sur le port 80. Il faut ajouter un règle pour autoriser les INPUT avec un port source 80, ou bien autoriser les INPUT avec état RELATED / ESTABLISHED.
Voir cette discussion :
https://superuser.com/questions/460621/iptables-firewall-only-allows-internet-traffic-if-source-port-of-80-is-allowed
Le plus simple est d'autoriser tous les paquets sortants, et autoriser les paquets entrants s'ils se rapportent à une connexion sortant déjà initialisée.
Je te recommande ce guide pour débuter :
https://www.digitalocean.com/community/tutorials/iptables-essentials-common-firewall-rules-and-commands
Pour plus de détails :
https://www.digitalocean.com/community/tutorials/a-deep-dive-into-iptables-and-netfilter-architecture
https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html
Et un diagramme utile :
https://en.wikipedia.org/wiki/Netfilter#/media/File:Netfilter-packet-flow.svg
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
Modifié le 29 oct. 2021 à 12:34
Modifié le 29 oct. 2021 à 12:34
Bonjour,
A priori il faut au moins que les ports sortants associés à FTP soient ouverts, à savoir :
Ensuite, si le serveur FTP est en mode passif, celui-ci ouvrira un port aléatoire (voir cette explication) et il faut bien évidemment que ton pare-feu te permette de t'y connecter. La plage des ports passifs est défini du côté du serveur FTP.
Note que la plupart des dépôts apt sont également accessibles via HTTP (port 80).
Ensuite, généralement, au niveau du pare-feu, on contrôle plutôt les ports de sa propre machine, plutôt que les ports auxquels on peut accéder vers une autre machine (voir ce tutoriel).
Bonne chance
A priori il faut au moins que les ports sortants associés à FTP soient ouverts, à savoir :
- le port 20 (pour les données FTP) ;
- le port 21 (pour les commandes FTP).
Ensuite, si le serveur FTP est en mode passif, celui-ci ouvrira un port aléatoire (voir cette explication) et il faut bien évidemment que ton pare-feu te permette de t'y connecter. La plage des ports passifs est défini du côté du serveur FTP.
Note que la plupart des dépôts apt sont également accessibles via HTTP (port 80).
Ensuite, généralement, au niveau du pare-feu, on contrôle plutôt les ports de sa propre machine, plutôt que les ports auxquels on peut accéder vers une autre machine (voir ce tutoriel).
Bonne chance
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
Modifié le 3 nov. 2021 à 18:04
Modifié le 3 nov. 2021 à 18:04
En complément, tu peux t'appuyer sur cette discussion pour configurer iptables de sorte à pouvoir accéder à un serveur ftp distant.
1) Assure-toi que le module
2) Ensuite on ajoute les règles
2)a) Si le serveur FTP cible est actif :
2)b) Si le serveur FTP cible est passif il faut aussi ajouter :
Bonne chance
1) Assure-toi que le module
nf_conntrack_ftpest chargé avec la commande
lsmod. Si ça n'est pas le cas tu peux le charger avec
sudo modprobe nf_conntrack_ftp. Le chargement de ce module au démarrage peut-être avec la commande :
sudo sysctl net.netfilter.nf_conntrack_helper=1
2) Ensuite on ajoute les règles
iptablesqui vont bien (tu peux dans le doute faire 2a et 2b)
2)a) Si le serveur FTP cible est actif :
sudo iptables -A INPUT -p tcp --dport 21 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 20 -j ACCEPT
2)b) Si le serveur FTP cible est passif il faut aussi ajouter :
sudo iptables -A INPUT -p tcp --dport 1024:65535 -m conntrack --ctstate RELATED -j ACCEPT
Bonne chance
Gafor
Messages postés
41
Date d'inscription
jeudi 19 juin 2014
Statut
Membre
Dernière intervention
3 juin 2023
5
31 oct. 2021 à 16:50
31 oct. 2021 à 16:50
Apparemment ProFTPd est un serveur, le problème doit être les entrées et les ports ouverts, je vois que :
« Les connexions FTP passives utiliseront des ports à partir de 1024, ce qui signifie que vous devez transférer tous les ports 1024-65535 du NAT au serveur FTP ».
« Passives » je suppose que c’est de l’UDP, bon courage au niveau sécurité.
« Les connexions FTP passives utiliseront des ports à partir de 1024, ce qui signifie que vous devez transférer tous les ports 1024-65535 du NAT au serveur FTP ».
« Passives » je suppose que c’est de l’UDP, bon courage au niveau sécurité.
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
Modifié le 2 nov. 2021 à 16:07
Modifié le 2 nov. 2021 à 16:07
Bonjour Gafor
Merci pour ton message, cependant quelques remarques :
Bonne chance
Merci pour ton message, cependant quelques remarques :
- Oui,
proftpd
est un serveur FTP. - Non, FTP est un protocole qui fonctionne traditionnellement sur TCP (voir la page wikipedia sur FTP) pas sur UDP.
- « Les connexions FTP passives utiliseront des ports à partir de 1024, ce qui signifie que vous devez transférer tous les ports 1024-65535 du NAT au serveur FTP ; Oui c'est le point dont nous parlions tous précédemment, s'il s'agit d'un serveur FTP avec connexion passive, il faut ouvrir des ports supplémentaires. Si c'est un serveur accessible en connexions actives, les ports 20 et 21 devraient suffire. Mais comme précédemment, c'est plus au niveau des connexion entrantes que sortantes qu'il faut être vigilant.
- Non, le fait qu'un protocole fonctionne sur TCP ou UDP n'a dans le cas général pas de rapport direct avec la sécurité, c'est plus les couches supérieures au sens du modèle OSI (e.g. couche 6) qui en sont responsable. Prenons un exemple : un service de VoIP fonctionne traditionnellement en UDP, ça n'empêche pas d'avoir des communications chiffrées et une authentification préalable (comme dans des logiciels comme skype ou teams).
- Il existe des serveurs FTP qui se veulent plus sûrs que la moyenne (comme
vsftpd
pour very secure ftp) mais qui sont assez pénibles à mettre en place queproftpd
ou d'autres approches (e.g. un transfert viascp
ou, dans le cas des dépôts de paquets, des serveurs https).
Bonne chance
