Vous n'êtes pas identifié(e).
Tout fonctionne... Sauf SMTP. Et je ne comprend juste pas pourquoi ! Pourtant, msmtp n'utilise pas d'autres ports que 25 ou 465 ou 587... Avec le traffic autorisé sur les 3 je ne comprend pas ce qui ne va pas. Des idées ?
Merci d'avance !
Hors ligne
Le fait que cette règle soit commentée empêche toute communication locale en IPv6 sur l'interface de loopback. Il faut accepter en INPUT et OUTPUT puisque chaque paquet passe par les deux chaînes (particularité du traffic sur l'interface de loopback).
D'une part, ICMP ne se limite pas au ping. Le bloquer totalement peut causer des dysfonctionnement, notamment en perturbant la découverte de MTU du chemin (path MTU discovery) servant à déterminer la taille maximum des paquets pouvant être envoyés vers une destination donnée.
D'autre part, le protocole ICMP est propre à IPv4. L'équivalent pour IPv6 est ICMPv6. Ces commandes doivent donc provoquer une erreur.
ICMPv6 reprend en les étendant les fonctionnalités du protocole ARP, donc bloquer ICMPv6 empêche les communications en IPv6 sur un réseau local. Si ça marche un peu, je suppose que la connectivité IPv6 ne se fait pas via une interface de type LAN (Ethernet, wifi...) mais une interface de type point à point (PPP, tunnel, VPN en mode routé...).
je ne comprend pas ce qui ne va pas. Des idées ?
La dernière règle enregistre les paquets entrant qui atteignent la fin de la chaîne dans les logs du noyau. Il faut en profiter et les examiner. Et faire de même avec les paquets sortants.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Le boulet que je suis appliquais mon ancien script
Si tu ne montres pas les règles réellement appliquées, c'est compliqué de comprendre pourquoi ça ne marche pas.
Ceci dit, je ne vois pas en quoi ces règles supplémentaires gênaient, au contraire puisqu'elles ont pour cible ACCEPT.
D'ailleurs, pas un peu "risqué" que d'autoriser tout icmpv6 ?
Oui, un peu. Il y a des types ICMPv6 dont l'usage peut être détourné, comme "redirect" qui peut servir à rediriger du trafic.
Les types ICMPv6 vraiment indispensables sont :
- les types d'erreur destination-unreachable, packet-too-big, time-exceeded, parameter-problem dans l'état RELATED
- les types de découverte du voisinage (remplaçant ARP) neighbor-solicitation, neighbor-advertisement, router-solicitation, router-advertisement dans l'état UNTRACKED avec un hl (hop limit) à 255.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par abumbra (26-04-2019 13:53:14)
Hors ligne
Et bien avec tout en drop sauf ces lignes pour l'icmpv6, smtp ne fonctionne pas.
Tu veux dire sans les règles qui acceptent tout ICMPv6 en entrée et en sortie ?
Dans ce cas il ne devait pas y avoir que SMTP qui ne fonctionnait pas. Rien ne devait fonctionner puisque toute communication IPV6 sur un réseau local Ethernet ou wifi a besoin des 4 types de découverte du voisinage mentionnés plus haut (pour déterminer l'adresse MAC destination à mettre dans les trames). Sauf si l'IPv6 ne passe pas par un réseau local mais par une interface point à point sans adresse MAC.
Toujours pas décommentée, donc les communications locales sont bloquées.
Redondant avec la règle ESTABLISHED générale.
Dernière modification par raleur (26-04-2019 14:12:47)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par abumbra (26-04-2019 14:32:05)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par abumbra (26-04-2019 15:00:04)
Hors ligne
Cette utilisation est donc plus sécurisée que tout accepter en icmpv6?
Forcément puisque cela supprime les risques associés aux types ICMPv6 non acceptés.
Ce que je ne comprend pas, c'est pourquoi tout accepter en icmpv6 et qu'en established fonctionne.
Je ne comprends pas la phrase. Les types ICMPv6 indispensables ne sont pas dans l'état ESTABLISHED.
Mais que pour faire fonctionner au cas par cas, il faut du related et untracked ?
C'est pour une meilleure sécurisation. Les paquets valides de ces types doivent avoir ces états. Un paquet qui aurait un état différent est forcément invalide et doit être bloqué.
Dernière modification par raleur (26-04-2019 15:12:41)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par abumbra (26-04-2019 15:32:52)
Hors ligne
ça revient à accepter icmpv6 qu'en established, non ?
Non, ça revient à
- accepter les paquets de n'importe quel protocole dans l'état ESTABLISHED
- et accepter les paquets du protocole ICMPv6 dans n'importe quel état
La cible ACCEPT est dite terminale : si un paquet correspond à une règle, il est définitivement accepté et les règles suivantes ne sont pas examinées.
Dernière modification par raleur (26-04-2019 15:38:53)
Il vaut mieux montrer que raconter.
Hors ligne
Si ACCEPT est terminale, quel est le process ici. Toutes les états established sont accepté, puis, port par port, tout les autres états ?
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT : accepte donc tout les états ?
ce serait donc iptables -A OUTPUT -p tcp --dport 443 -m state --state ESTABLISHED -j ACCEPT si je ne veux pas du reste ?
Dernière modification par abumbra (26-04-2019 16:02:32)
Hors ligne
Toutes les états established sont accepté, puis, port par port, tout les autres états ?
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT : accepte donc tout les états ?
Oui.
Note que la chaîne OUTPUT ne concerne que les paquets émis par la machine elle-même.
ce serait donc iptables -A OUTPUT -p tcp --dport 443 -m state --state ESTABLISHED -j ACCEPT si je ne veux pas du reste ?
Non, tous les paquets dans l'état ESTABLISHED sont déjà acceptés par la règle générale. C'est l'état NEW (le premier paquet de la connexion) qu'il faut accepter. Par contre cela peut empêcher l'utilisation de certains types de scan de port depuis cette machine.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par abumbra (26-04-2019 16:43:15)
Hors ligne
Dans ma tête, ces règles n'autorisait que les established sur les règles qui suivait.
Heureusement que non. Sinon aucune communication ne serait possible puisque toute connexion doit commencer par un paquet dans l'état NEW.
Aussi, je voulais te demander pourquoi :ip6tables -A OUTPUT -p udp --sport 51413 -j ACCEPT--sport est nécessaire, ce sans quoi smtp ne fonctionne pas
SMTP ? Je ne vois pas le rapport, d'autant plus que le commentaire précédent cette règle mentionne Transmission, qui est un client BitTorrent si je ne m'abuse.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par abumbra (26-04-2019 18:41:58)
Hors ligne
j'ai passé un bon bout de temps sur faire marcher smtp, lapsus. Transmission.
Je ne connais pas le protocole réseau BitTorrent, que je n'ai jamais utilisé. Si transmission fonctionne en client+serveur avec le même port UDP local, alors ces règles sont logiques : une pour les paquets entrants destinés à ce port local (--dport), une pour les paquets sortant émis depuis ce port local (--sport).
Les autres règles UDP pour DNS et NTP sont différentes car elles concernent des usages en tant que client uniquement, et seul compte le port destination distant des paquets de requête. Les paquets de réponse entrants sont dans l'état ESTABLISHED donc acceptés par la règle globale correspondante.
Et du coup, pas d'autres optimisations nécessaires, cette configuration est "sécurisée" ?
Pour pouvoir donner un avis sérieux il faudrait montrer le script complet actuel, car tu n'as montré que le script initial et dfes modifications partielles.
Aussi, j'ai vu sur pas mal d'exemple de :
iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
En INPUT, c'est plus sécurisé que sans state puisque cela exclut les paquets qui sont classés dans l'état INVALID.
En OUTPUT, c'est moins utile pour la sécurité. Par contre cela évite d'émettre des paquets INVALID dont l'éventuelle réponse sera forcément INVALID aussi, donc bloquée.
A propose de connexions entrantes, ta machine est-elle vraiment censée recevoir des connexions SMTP de l'extérieur ?
Ne vaut il mieux pas accepter que les états nécessaire au lieu d'un accept global ?
Oui, bien sûr.
Il vaut mieux montrer que raconter.
Hors ligne
Si je précède les règles vu avant d'un imcpv6 drop, plus rien ne fonctionne. Pourtant, les accept qui suis devraient laisser passer, non ?
Non. Comme ACCEPT, la cible DROP est aussi terminale. En revanche la cible LOG ne l'est pas.
Il vaut mieux montrer que raconter.
Hors ligne
Et je tiens à te remercier encore du temps passé à me guider, c'est très gentil (c'est que tu y as passé, du temps...).
Dernière modification par abumbra (26-04-2019 20:48:59)
Hors ligne
Cette règle ne sert pas à grand-chose sans la règle similaire dans OUTPUT (qui était commentée dans ton premier script).
Puisque l'essentiel est fait, on peut s'attaquer aux détails.
Répondre inconditionnellement au ping n'est pas dangereux en soi mais peut être exploité pour un déni de service (flood).
Tu fais comme tu veux, mais je limiterais la taille des paquets (-m length) et la fréquence (-m limit).
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne