Vous n'êtes pas identifié(e).
j'ai configuré nftables au minimum : ssh, https et le port 22317 dont j'ai besoin :
nftables est bien démarré à priori :
mon problème est que si je scanne les ports ouverts, ça ne correspond pas du tout :
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
110/tcp open pop3
143/tcp open imap
443/tcp open https
993/tcp open imaps
on dirait mon ancienne config d'iptables. je suis coincée
merci de votre aide !
Dernière modification par llwynrt (15-08-2019 17:35:37)
Hors ligne
et sûrement autoriser d'autres services comme le DNS et autres
en "accept" tes règles au dessous ne servent a rien , tout passe
a pour effet de charger la table "filter" d'iptables si elle ne l'est pas déjà. Pour lister les règles iptables sans charger les tables d'iptables il vaut mieux utiliser
2) Tu as défini la politique par défaut de la chaîne input à accept. Accepter des ports spécifiques alors que la politique par défaut est déjà accept n'apporte rien.
Quand tu mettras la politique par défaut à drop ou ajouteras une règle drop pour les autres paquets en fin de chaîne, tu devras ajouter une règle pour autoriser les paquets de réponse aux paquets de requête émis par la machine en utilisant le suivi de connexion (established, related).
et sûrement autoriser d'autres services comme le DNS et autres
Pourquoi ?
Dernière modification par raleur (10-08-2019 10:41:00)
Il vaut mieux montrer que raconter.
Hors ligne
en "accept" tes règles au dessous ne servent a rien , tout passe
Tu as défini la politique par défaut de la chaîne input à accept. Accepter des ports spécifiques alors que la politique par défaut est déjà accept n'apporte rien.
justement tout ne passe pas, les seuls ports ouverts sont ceux cités précédemment. s'il n'y a plus rien dans iptables et si nftables ne filtre rien, pourquoi tous les ports ne sont-il pas ouverts ? (le pc est configuré en dmz sur la box, donc pas de filtrage à ce niveau là)
il y a bien un reste de config de iptables, mais rien sur les ports à ouvrir, non ?
Dernière modification par llwynrt (10-08-2019 11:01:16)
Hors ligne
pourquoi tous les ports ne sont-il pas ouverts
Tu confonds fermé et filtré/bloqué.
Les autres ports sont fermés (et non filtrés) parce qu'aucun service n'écoute dessus.
il y a bien un reste de config de iptables
Ces règles iptables sont apparemment créées par fail2ban, qu'il va falloir modifier pour utiliser nftables.
Dernière modification par raleur (10-08-2019 11:23:15)
Il vaut mieux montrer que raconter.
Hors ligne
anonyme a écrit :et sûrement autoriser d'autres services comme le DNS et autres
Pourquoi ?
c'est en test , mais par exemple le contenu de mon /etc/nftables.conf
le input " type filter hook input" bloque tout
ceci me permet de laisser passer les services en output en réponse en input => "ct state established,related accept"
sinon il faut une règle pour autorisé les ports en entrée
c'est une ébauche et en test , je suis pas très a l' aise , enicar m'a donné un sérieux coup de main sur ce coup la
Dernière modification par anonyme (10-08-2019 11:25:49)
ceci me permet de laisser passer les services en output en réponse en input => "ct state established,related accept"
Tu ne parlais donc pas d'autres services en entrée. Tu aurais pu être plus explicite.
sinon il faut une règle pour autorisé les ports en entrée
Sûrement pas pour des requêtes sortantes. Ce serait une très mauvaise idée.
a ma connaissance , il n'y a pas d' utilitaires graphique pour nftables , et a mon avis il faut supprimer et purger ceux utilisé avec iptables.
C'est graphique, fail2ban ?
Dernière modification par raleur (10-08-2019 11:29:03)
Il vaut mieux montrer que raconter.
Hors ligne
on dirait mon ancienne config d'iptables. je suis coincée
Tu n'as pas décrit ce dont tu avais besoin, quels sont les services qui vont être
disponibles sur ce serveur depuis l'extérieur ?
Dans un premier tu devrais arrêter fail2ban pour éviter qu'il crée de nouvelles règles
iptables à la volée.
Tu pourrais aussi nous montrer qu'elles étaient les règles du pare-feu avec iptables.
Hors ligne
Tu n'as pas décrit ce dont tu avais besoin, quels sont les services qui vont être
disponibles sur ce serveur depuis l'extérieur ?
Il me semble que le post initial était suffisamment explicite :
j'ai configuré nftables au minimum : ssh, https et le port 22317 dont j'ai besoin :
Il vaut mieux montrer que raconter.
Hors ligne
Il me semble que le post initial était suffisamment explicite :
bof…
Hors ligne
Si le serveur est exposé je rajouterais bien les trois règles suivantes dans la chaîne
input de la table inet filter, juste après « iff lo accept :
Les deux premières c'est pour bloquer les scans utilisant des paquets tcp NULL et
XMASS. La troisième c'est pour filtrer les paquets tcp new et related qui
n'ont pas de syn activé.
Remarquez que la famille utilisé ici est « inet ». Ça permet de regrouper les
règles pour ipv4 (famille ip) et ipv6 (famille ip6).
On peut aussi ajouter ou supprimer des logs… mais si la machine à une adresse
publique, il vaut mieux être parcimonieux avec les logs.
Edit : puisque, on autorise le traffic ipv6, j'ai rajouté une règle
autorisant les messages icmpv6 nécessaires. J'ai trouvé cette règle dans les exemples
du wiki de nftables : https://wiki.nftables.org/wiki-nftables … orkstation
Dernière modification par enicar (10-08-2019 12:40:51)
Hors ligne
tcp flags & (fin|syn|rst|psh|ack|urg) < fin
Ce ne serait pas plus clair avec "= 0" ?
tcp flags & (fin|syn|rst|psh|ack|urg) > urg
Tu es sûr de cette expression ?
Si je ne m'abuse, un paquet "Xmas tree" a tous les flags TCP activés. Si j'interprète correctement ton expression, la correspondance se fait si au moins un autre flag que URG est activé, ce qui est différent. D'autre part le flag URG ne peut pas être activé seul, il doit au moins y avoir ACK (seul le paquet SYN initial n'a pas ACK, tous les autres doivent l'avoir) donc pour moi cette expression n'a aucun sens.
Il vaut mieux montrer que raconter.
Hors ligne
enicar a écrit :tcp flags & (fin|syn|rst|psh|ack|urg) < fin
Ce ne serait pas plus clair avec "= 0" ?enicar a écrit :tcp flags & (fin|syn|rst|psh|ack|urg) > urg
Tu es sûr de cette expression ?
Si je ne m'abuse, un paquet "Xmas tree" a tous les flags TCP activés. Si j'interprète correctement ton expression, la correspondance se fait si au moins un autre flag que URG est activé, ce qui est différent. D'autre part le flag URG ne peut pas être activé seul, il doit au moins y avoir ACK (seul le paquet SYN initial n'a pas ACK, tous les autres doivent l'avoir) donc pour moi cette expression n'a aucun sens.
Absolument pas sûr, c'est un truc que j'ai trouvé sur une doc que je trouve
très approximative (et fausse donc !) : c'est ici https://www.it-connect.fr/chapitres/ger … -nftables/
J'avais compris qu'il jouait avec l'ordre des bits.
Mais effectivement, pour les tcp NULL il vaudrait mieux :
Pour les XMASs je ne sais pas trop ce qu'il faudrait mettre.
Dans la doc de nmap ils disent que les flags FIN, URG et PUSH sont activés
pour ces paquets. Ce qui ne correspond pas à « tous les flags sont activés ».
Si tous les flags sont activés, alors une expression comme :
devrait convenir.
Il faut que je réfléchisse à tout ça
Dernière modification par enicar (10-08-2019 13:11:49)
Hors ligne
Dans la doc de nmap ils disent que les flags FIN, URG et PUSH sont activés
pour ces paquets. Ce qui ne correspond pas à « tous les flags sont activés ».
En fait j'ai mal lu, il est dit « In this type of scan, Nmap will send the packets with URG, FIN, and PSH, and flags activated.» Ce qui correspond à tous les bits à 1.
Hors ligne
Dans la doc de nmap ils disent que les flags FIN, URG et PUSH sont activés
pour ces paquets. Ce qui ne correspond pas à « tous les flags sont activés ».
En effet, je vois ça. Sur Wikipédia (https://en.wikipedia.org/wiki/Christmas_tree_packet), c'est un peu contradictoire : l'article commence par dire que tous les bits d'option sont activés, puis mentionne les même flags que nmap.
EDIT : la section "talk" de la page aborde cette contradiction.
La RFC 1025 (https://tools.ietf.org/html/rfc1025) mentionne SYN,URG, PUSH, FIN comme exemple de paquet "christmas tree", laissant entendre que la définition n'est pas figée.
tcp flags & (fin|syn|rst|psh|ack|urg) = 63
Un nombre, ce n'est pas très lisible. Il vaudrait mieux utiliser une expression de la même forme que le masque (flag|flag|...).
Avec cette expression :
on devrait détecter aussi bien les scans Xmas Tree de nmap et les paquets ayant des flags en plus.
Dernière modification par raleur (10-08-2019 13:31:15)
Il vaut mieux montrer que raconter.
Hors ligne
Un nombre, ce n'est pas très lisible. Il vaudrait mieux utiliser une expression de la même forme que le masque (flag|flag|...).
Avec cette expression :
tcp flags & (fin|psh|urg) = (fin|psh|urg)
on devrait détecter aussi bien les scans Xmas Tree de nmap et les paquets ayant des flags en plus.
Bonne idée. Je vais l'écrire comme ça dorénavant, et aussi je mettrai ces règles après
la règle « ct state invalid drop », et avant « ct state related,established accept » ça permet un premier filtrage avec le suivi de connexion.
Aussi avec nftables il faut utiliser « == » ou « eq ». Il me semble qu'avec iptables c'était « = ».
https://wiki.nftables.org/wiki-nftables … xpressions
Hors ligne
En fait j'ai mal lu, il est dit « In this type of scan, Nmap will send the packets with URG, FIN, and PSH, and flags activated.» Ce qui correspond à tous les bits à 1.
Où as-tu lu cette phrase ? Sa formulation est bizarre, j'ai l'impression que soit il manque quelque chose juste avant "flags", soit ", and" est en trop.
La page de manuel et la documentation en ligne de nmap sont sans ambiguïté : "Sets the FIN, PSH, and URG flags".
Il vaut mieux montrer que raconter.
Hors ligne
on devrait détecter aussi bien les scans Xmas Tree de nmap et les paquets ayant des flags en plus.
La question que je me pose : est-il possible que certains
paquets faisant partie d'une connexion déjà existante puissent avoir ces bits de
positionnés en même temps ?
Hors ligne
Aussi avec nftables il faut utiliser « == » ou « eq ». Il me semble qu'avec iptables c'était « = ».
Possible, je ne connais pas encore la syntaxe de nftables. En revanche iptables n'utilisait pas du tout ce genre d'expression, la syntaxe était complètement différente.
Il vaut mieux montrer que raconter.
Hors ligne
Où as-tu lu cette phrase ?
ici : https://www.konsecurity.com/nmap-advance-scanning/
Mais ce n'est pas la doc de nmap comme je l'ai prétendu…
Encore une doc approximative… j'en trouve tellement de mal faite
sur ce sujet que les bons documents sont précieux.
Hors ligne
Possible, je ne connais pas encore la syntaxe de nftables.
Moi, je n'ai jamais maîtrisé la syntaxe iptables, je trouve la syntaxe nftables plus
facile à retenir et surtout à lire.
Hors ligne
La question que je me pose : est-il possible que certains
paquets faisant partie d'une connexion déjà existante puissent avoir ces bits de
positionnés en même temps ?
Normalement non, à ma connaissance. FIN annonce la fin de la connexion, et PSH et URG ne sont normalement utilisés que si le segment contient des données. Mais je ne suis pas sûr à 100% qu'un paquet FIN ne peut pas contenir de données. Ceci dit FIN implique PUSH, donc il ne devrait pas y avoir de PSH avec FIN.
Il vaut mieux montrer que raconter.
Hors ligne