Iptables+android

Support Debian
#61

L’idée générale est correcte, mais parler de “sortir du LAN” pour un paquet entrant depuis le LAN qui passe par la chaîne INPUT (entrée) est contre-intuitif.

Non. Pour le serveur destinataire qui reçoit le paquet et exécute la règle, le port source du paquet est le port distant.

Même remarque que ci-dessus : parler d’“entrer sur le LAN” pour un paquet sortant vers le LAN qui passe par la chaîne OUTPUT (sortie) est contre-intuitif.

Le port 22 (SSH), tu veux dire ?

  • Ces règles sont syntaxiquement incorrectes : il faut écrire -i eth0 ou -o eth0 selon la chaîne au lieu de -eth0 ; il ne faut pas d’espace après la virgule dans la liste des états.
  • L’état RELATED ne sert à rien car les paquets de connexions HTTP ne sont jamais dans cet état.
  • La seconde règle ne sert à rien pour autoriser les connexions HTTP sortantes.
  • Il faut une règle pour accepter les paquets entrants avec l’état ESTABLISHED dans le sens retour de la connexion, soit spécifique avec le port source (–sport) 80, soit globale pour tous les types de connexion.
#62

J’ai toujours le sentiment dans tes réponses qu’on n’a pas le même point de vu. C’est un peu comme si je regardais dans une direction et toi dans l’autre. Je ne suis jamais dans le bon sens.
Pourquoi je devrais écire la règle en fonction du serveur destinataire ? Je croyais que j’écrivaits une règle en fonction de ma machine :confused:[quote=“PascalHambourg, post:61, topic:74898”]
Le port 22 (SSH), tu veux dire ?
[/quote]
oui

#63

Comment je déclare l’état NEW alors ? çà se fait tout seul ??

#64

Tu ne dois pas écrire les règles en fonction du destinataire mais en fonction de la machine qui les exécute. Tu dois te placer du point de vue de la machine qui exécute les règles.

L’état NEW est pris en charge dans la première règle qui traite les paquets dans le sens aller. Les paquets dans le sens retour d’une connexion ne sont jamais dans l’état NEW.

#65

Donc on parle bien de cette règle là. Mais elle n’est pas sortante , elle est entrante. Elle traite des paquets en retour. Pourquoi dis-tu qu’elle traite des paquets sortants ? Sortant de chez moi, hein ?

#66

Donc le routeur Serveur-Debian.

#67

Donc 2 possibilités :
iptables -A INPUT -p tcp --sport 80 -i eth0 -m --state ESTABLISHED -j ACCEPT (spécifique avec le port source (–sport) 80)
iptables -A INPUT -i eth0 -m state --state ESTABLISHED -j ACCEPT (globale pour tous les types de connexion).

Il me semble plus simple de mettre la même règle globale pour tous les types de connexion tcp et udp. Je ne me suis pas encore penché sur le cas de ICMP.

On peut faire çà ?

# suivi de connexion des paquets sur eth0 vers l'exterieur
iptables -A INPUT -p tcp -i eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp -i eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -o eth0 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp -o eth0 -m state --state ESTABLISHED -j ACCEPT
#68

Je n’ai pas écrit que cette règle est sortante ni qu’elle traite des paquets sortants. J’ai parlé de connexion sortante. La direction d’une connexion est la direction des paquets aller.

Les règles ne sont ni sortantes ni entrantes, ce sont les paquets qui le sont. Cette règle est dans la chaîne INPUT qui traite les paquets entrants. Elle ne traite pas des paquets retour mais des paquets aller puisqu’elle se base sur le port destination.

Oui, c’est correct.

On peut aussi. Mais alors il faut ajouter des règles pour prendre en compte chaque protocole utilisé. Et franchement, je ne vois pas trop l’intérêt de traiter séparément l’état ESTABLISHED des différents protocoles si tu n’utilises pas de critères supplémentaires spécifiques aux protocoles, par exemple des combinaisons de drapeaux TCP valides pour cet état.

#69

Bien, je vais donc spécifier à chaque fois l’état dans les règles.

Du LAN vers l’extérieur, on a donc le même type d’écriture :

Exemple pour https :

# paquet sortant venant du LAN vers le serveur https
iptables -A FORWARD -p tcp --dport 443 -i br0 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
paquet entrant venant du serveur https vers le LAN
iptables -A FORWARD -p tcp --sport 443 -i eth0 -o br0 -m state --state ESTABLISHED -j ACCEPT

Le protocole ICMP (ping, traceroute,…)

du LAN vers le routeur
iptables -A OUTPUT -p icmp -o br0 -j ACCEPT
iptables -A INPUT -p icmp -i br0 -j ACCEPT

#70

C’est correct.

Pour ICMP, il est recommandé de ne pas laisser passer n’importe quoi depuis l’extérieur. Mais il ne faut surtout pas bloquer les paquets ICMP de types destination-unreachable, time-exceeded et parameter-problem dans l’état RELATED qui qui signalent des erreurs liées à des connexions existantes.

Note : traceroute n’utilise pas que des paquets ICMP. La version traditionnelle d’Unix/Linux envoie des paquets UDP vers des ports séquentiels (port initial par défaut mentionné dans la page de manuel) et attend des paquets d’erreur ICMP. La version de Windows (ou Unix avec une option) envoie des paquets ICMP echo-request (comme ping) et attend des paquets ICMP echo-reply ou des paquets d’erreur ICMP. Des variantes ou options envoient des paquets TCP SYN, par défaut vers le port 80, et attendent des paquets TCP SYN/ACK ou TCP RST et des paquets d’erreur ICMP.

#71

J’ai trouvé çà pour les types ICMP : https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml

ICMP destination-unreachable (type 3)

iptables -A OUTPUT -p icmp --icmp-type 3 -o br0 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 3 -i br0 -j ACCEPT

Donc sur le même modèle :

time-exceeded type 11
parameter-problem type 12

#72

Avec l’état RELATED.
On peut mettre les noms au lieu des numéros de type/code, c’est plus lisible pour le commun des mortels. Liste des noms reconnus avec (de mémoire) :

iptables -p icmp -h
#73 
iptables -A OUTPUT -p icmp --icmp-type destination-unreachable -o br0 -m state --state RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -i br0 -m state --state RELATED -j ACCEPT

idem avec time-exceeded

iptables -A OUTPUT -p icmp --icmp-type time-exceeded -o br0 -m state --state RELATED -j ACCEPT
iptables -A INPUT -p cimp --icmp-type time-exceeded -i br0 -m state --state RELATED -j ACCEPT

idem avec parameter-problem

iptables -A OUTPUT -p icmp --icmp-type parameter-problem -o br0 -m state --state RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type parameter-problem -i br0 -m state --state RELATED -j ACCEPT
#74

N’oublie pas la chaîne FORWARD, et l’interface eth0 dans les chaînes INPUT et OUTPUT.
C’est surtout lors des communications avec l’extérieur que ces messages d’erreur ICMP sont importants.
D’ailleurs, ces paquets doivent être acceptés sur toutes les interfaces donc inutile de vérifier l’interface.

#75

Résumons :

J’ai un modèle de règle pour les protocoles tcp/udp du serveur-debian vers le net :

iptables -A INPUT -p tcp --sport 80 -i eth0 -m --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -o eth0 -m --state NEW,ESTABLISHED -j ACCEPT

J’ai un modèle de règle pour les protocoles tcp/udp du Lan vers le serveur-debian

iptables -A OUTPUT -p tcp --sport 2222 -o br0 -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 2222 -i br0 -m state --state NEW,ESTABLISHED -j ACCEPT

J’ai un modèle de règle pour les protocoles tcp/udp du LAN vers l’extérieur

iptables -A FORWARD -p tcp --dport 443 -i br0 -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -p tcp --sport 443 -i eth0 -o br0 -m state --state ESTABLISHED -j ACCEPT

J’ai un modèle pour le protocole icmp du LAN vers le serveur-debian

iptables -A OUTPUT -p icmp --icmp-type parameter-problem -o br0 -m state --state RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type parameter-problem -i br0 -m state --state RELATED -j ACCEPT

Il me manque encore quoi ? Tout plein de trucs ?? :sweat_smile:

#76

Visiblement mes règles icmp ne servent à rien ou plutôt ne sont pas suffisantes.

#77

icmp et la chaine FORWARD, INPUT et OUTPUT

iptables -A FORWARD -p icmp --icmp-type parameter-problem -m state --state RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type parameter-problem -m state --state RELATED -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type parameter-problem -m state --state RELATED -j ACCEPT

Je n’ai pas encore de règle du ‘serveur-debian’ vers le LAN. Est-ce nécessaire ?

#78

Oui.

Non. Tu as remis le même modèle que ci-dessus (connexion sortante) en changeant juste l’ordre des commandes.

Oui.

Pas pour tout le protocole ICMP, juste pour les messages d’erreurs indispensables. Il y a aussi le ping par exemple, qui utilise les types echo-request et echo-reply avec les états NEW et ESTABLISHED.

Pas suffisantes pour quoi faire ?

Simple et suffisant pour un type d’erreur ICMP.

As-tu besoin que le serveur initie des communications vers le LAN ?

#79

Du serveur, si je veux faire un netstat -tl je ne pourrais plus ? ou un nmap -sP 172.16.10.0/28 ?

#80

J’ai corrigé. C’est ok ?