Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Iptables - configuration

bruno

Je l'ai déjà dit msmtp n'utilise aucun port il se contente de transmettre au serveur configuré. Dans ton cas smtp.gmail.com:587

Si tes règles sont celles de #10 pour iPv4 et #20 pour IPv6 ça passe en IPv6 (uniquement port 25 en sortie en IPv4 et 587 autorisé en sortie pour IPv6)

Au passage tes règles autorisant l'accès au ports 25,465,587 en entrée sont inutiles (tu n'héberges pas de serveur mail)

Spino1

Redraven a écritSi, mon FAI laisse passer, ipv4 et ipv6.
De toute manière, c'est simple, si avec ip6tables tout en drop smtp ne fonctionne plus, c'est nécessairement qu'il utilisait ipv6, non ?
J'y arrive plus ou moins. J'ai même utilisé Wireshark pile au moment de l'envoi de message par msmtp. Pas plus d'infos que la connexion à smpt.gmail.com:587 ne se fait pas.
iptables est en haut, voici pour ip6tables :
]

" c'est nécessairement qu'il utilisait ipv6, non ? "

Non ! un effet une cause, ou plusieurs.

J’ai regardé vite fait, ICMP ça ne va pas, il en manque les 2/3.

Sous UFW :

Chain ufw-before-input (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ufw-logging-deny all -- anywhere anywhere ctstate INVALID
DROP all -- anywhere anywhere ctstate INVALID
ACCEPT icmp -- anywhere anywhere icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere icmp time-exceeded
ACCEPT icmp -- anywhere anywhere icmp parameter-problem
ACCEPT icmp -- anywhere anywhere icmp echo-request

bruno

@Spino1 : tu ne peux pas comparer les règles UFW (avec ses propres chaînes) et des règles iptables faites à la main.
Et aucun rapport avec ICMP. Une machine peut parfaitement bloquer le « ping » et permettre d'envoyer et de recevoir du courrier, ou d'utiliser n'importe quel service.

Spino1

bruno a écrit@Spino1 : tu ne peux pas comparer les règles UFW (avec ses propres chaînes) et des règles iptables faites à la main.
Et aucun rapport avec ICMP. Une machine peut parfaitement bloquer le « ping » et permettre d'envoyer et de recevoir du courrier, ou d'utiliser n'importe quel service.

Je n’ai pas besoin de conseils, à ce niveau de réponse, dans ce domaine donné.

Spino1

Redraven,

En ICMP input, il te faut au moins le destination unreachable, et le time exceeded n'est pas superflu pour la qualité de la connexion.

Spino1

TOR, tu n’as pas le 9001 en sortie, tu es sûr que ça marche ?

DNS, pas de 53 en UDP input ce n’est pas bon pour une connexion établie, en TCP input à éviter.

Ports pour Thunderbird output, je ne l’utilise plus, mais je crois qu’il en manque, voir pour le 993.

Tu aurais eu moins de mal en autorisant tout en sortie, filtrer par port en output ça peut être utile, quoi que fastidieux, si on peut le faire par application, mais sous Linux on ne peut pas, donc ça sort large, si un trojan ne peut pas sortir dans Firefox par exemple il choisira une autre voie, pas d’intérêt.
L’important c’est de filtrer en entrée, surtout dans ta box ou ton routeur.

Redraven

Salutations !

Oui, Tor fonctionne, je viens de faire un petit tour sur Torcheck et tout bon !

Les input étaient commenté ! il n'y a que les output pour le DNS ! c'est bon du coup ?

Pas de thunderbird !

Et smtp fonctionne, mais en autorisant tout icmpv6. Pas un peu risqué ?

Le souci c'est qu'avec des filtres types :
ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
p6tables -A OUTPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type echo-reply -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT

SMTP ne refonctionne plus. Il doit manquer quelque chose...

jlmas

bruno a écritEt aucun rapport avec ICMP. Une machine peut parfaitement bloquer le « ping » et permettre d'envoyer et de recevoir du courrier, ou d'utiliser n'importe quel service.

Mauvaise idée en IPv6.
Toutes les annonces du routeur passent par des paquets icmpv6. C'est pourquoi en IPv6, il est très important de ne pas bloquer les paquets icmpv6 en entrée et en sortie, voire de mettre en tête de liste des ip6tables des règles les acceptant explicitement en entrée (INPUT) et sortie (OUTPUT).

ip6tables -A INPUT -p icmpv6  -j ACCEPT
ip6tables -A OUTPUT -p icmpv6  -j ACCEPT

L'option -p icmpv6 normalement prend en charge tous les protocoles liés à l'icmp en IPv6

jlmas

Ne filtre pas le loopback ni en IPv4 ni en IPv6

dans ta conf IPv4 tu as cette ligne commentée

 #iptables -A OUTPUT -o lo -j ACCEPT

Je tenterais plutôt ceci

#IPv4 
iptables -A INPUT -o lo -j ACCEPT
iptables -A FORWARD -o lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

#IPv6 
ip6tables -A INPUT -o lo -j ACCEPT
ip6tables -A FORWARD -o lo -j ACCEPT
ipt6ables -A OUTPUT -o lo -j ACCEPT

Spino1 a écritTu aurais eu moins de mal en autorisant tout en sortie

C'est clair, surtout dans le but de comprendre l'utilisation des ip(6)tables

Redraven

Pas moyen de de n'autoriser justement que le strict nécessaire ? Normalement les lignes indiqués ci-dessus devraient pourtant fonctionner...

EDIT : Et c'est ce que j'avais au début ! Puis j'ai cherché à avoir le code minimal, et sans l'output de lo, tout fonctionnait encore ! Donc tant qu'à faire...

Aussi, une petite chose que je ne comprend pas :

Pour transmission j'ai :

iptables -A OUTPUT -p udp --sport 51413 -j ACCEPT

J'avais par mégarde modifié en dport, et ça ne fonctionnait plus.

En revanche tout mes output http, https etc. fonctionnent avec du output --dport.

Que se passe-t-il ?!

Merci d'avance

bruno

@jlmas : Tout à fait exact.
J'étais focalisé sur le copier/coller des règles IPv4 de ufw et je suis complètement passé à côté. Effectivement avec toutes les politiques par défaut sur « DROP » tes deux règles sont indispensables pour IPv6.

Spino1

Redraven a écritSalutations !
Les input étaient commenté ! il n'y a que les output pour le DNS ! c'est bon du coup ?
Et smtp fonctionne, mais en autorisant tout icmpv6. Pas un peu risqué ?
Le souci c'est qu'avec des filtres types :
ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
p6tables -A OUTPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type echo-reply -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
...

Si ça marche en autorisant tout ICMP dans Iptables règles IPV6, autorise, de toute façon IPV6 seul on ne sait pas complètement ce qui nous attend au niveau réseau.

Dans IPV4, il faut garder au moins destination inaccessible et le ping en retour que tu as sollicité, mais en IPV6 seul il faut faire confiance à Iptables, tu n’as pas le choix, c’est vrai qu’ICMP comporte des risques, mais on n’en entend pas beaucoup parlé, à part ces histoires de réponse au ping qui sont de la fausse sécurité.

Pour le DNS ça doit être bon, j’ai regardé dans le log UFW, je vois partir les output en UDP sur le 53, je ne vois rien revenir, et pas de règle input UDP 53 dans UFW non plus, peut être cachée, mais ça marche, donc pas de problème.

Redraven

Merci mille fois !

Et pour le --sport, qu'en penses -tu ?

Spino1

Redraven a écrit Et pour le --sport, qu'en penses -tu ?

iptables -A OUTPUT -p udp --sport 51413 -j ACCEPT

Sous réserve de mes souvenirs de la syntaxe d’IPtables, autorise les sorties en UDP du port source ( sport ) 51413.
Avec un dport ça ne pouvait pas marcher, sauf en local.

Redraven

C'est bien ce qu'il me semblait.

Mais

# NTP (horloge du serveur)
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT

fonctionne ! j'ai beau vérifier par timedatectl , tout va. Je ne comprend plus...

Spino1

Redraven a écritC'est bien ce qu'il me semblait.
Mais
# NTP (horloge du serveur)
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
fonctionne ! j'ai beau vérifier par timedatectl , tout va. Je ne comprend plus...

Autorise en sortie UDP vers le port destinataire ( dport ) 123.

jlmas

Je ne sais pas si NTP est un bon exemple pour comprendre les règles de filtrage d'iptables dans la mesure ou il fonctionne de plein de manières différentes (c'est un très très vieux protocole)

J'ai la règle inverse et ça fonctionne aussi 🙂

iptables -A INPUT -p udp  --dport 123 -m comment --comment "205 allow ntp server" -j ACCEPT

Redraven

Aaaah. Sans doute pour ça que je m'y perd un peu ahah.

Pour revenir au script entier, pas d'optimisations nécessaire, cette configuration est "sécurisée" ?

Spino1

jlmas a écritJe ne sais pas si NTP est un bon exemple pour comprendre les règles de filtrage d'iptables dans la mesure ou il fonctionne de plein de manières différentes (c'est un très très vieux protocole)
J'ai la règle inverse et ça fonctionne aussi 🙂
iptables -A INPUT -p udp  --dport 123 -m comment --comment "205 allow ntp server" -j ACCEPT

Règle entrante, serveur NTP en écoute, input sur dport 123 destinataire.

Le -m comment je ne vois pas, peut être une poignée de mains ( handshake ) avant la connexion.

jlmas

-m comment --comment "205 allow ntp server"

Cette option sert à activer les commentaires dans les iptables, ce qui donne ceci par exemple

sudo iptables -L | grep ntp
ACCEPT     udp  --  anywhere             anywhere             multiport dports ntp /* 205 allow ntp server */

C'est utile afin de se souvenir de ce que fait chacune des règles et pourquoi elle est là, surtout quand on en a beaucoup et qu'on travaille en équipe.
Ce n'est pas indispensable, mais c'est bien pratique.

« Page précédente Page suivante »