Fail2ban named-refused-udp et ip spoofing

Salut,
Las d’avoir dans mes logs ceci j’ai activé la protection de bind9 avec fail2ban:

Il y a deux options: udp et tcp.
Dans le fichier de conf de fail2ban, il y a un avertissement au sujet du filtre udp à propos de l’IP spoofing (et un lien vers ce site: nion.modprobe.de/blog/archives/6 … -fail.html)

J’avoue que c’est un peu brumeux pour moi.

Si j’ai bien compris, activer le filtre udp permettrait à un malfaisant (j’adore on dirait du Audiard) de provoquer un blocage du serveur.

J’avais activé udp et tcp, ça fonctionnait bien, je bloquais des dizaines de demandes interdites chaque heure. J’ai finalement désactivé la partie udp, car après lecture je ne suis plus trop sur que ce soit une bonne idée…

Une protection antispoofing ne suffit pas à se protéger ?
Le fait d’avoir l’IP en liste blanche dans fail2ban n’est pas suffisant pour se protéger ?

Si quelqu’un branché sur cette question pouvait m’aider à comprendre ce serait sympa!

Sur internet, il est facile d’usurper une adresse IP, c’est-à-dire d’envoyer un paquet IP avec une adresse source arbitraire. Une requête DNS en UDP se composant d’un unique datagramme, on peut faire bannir des adresses IP par fail2ban en les usurpant (spoofing) pour envoyer des requêtes DNS à ton serveur. Par conséquent, les utilisateurs légitimes de ces adresses IP ne pourront plus faire de requêtes DNS à ton serveur.

C’est beaucoup plus difficile en TCP car l’établissement d’une connexion passe par le “3-way handshake”, la poignée de main qui consiste à envoyer un paquet SYN au serveur, qui répond par un SYN/ACK auquel il faut répondre par un ACK. Là est la difficulté : si on n’est pas le propriétaire de l’adresse, ou si on n’est pas sur le chemin entre lui et le serveur pour intercepter les paquets, on ne reçoit pas le SYN/ACK qui contient un numéro de séquence initial repris dans le ACK. On peut certes répondre en aveugle, mais d’une part les attaques par prédiction du numéro de séquence sont devenues extrêmement difficiles avec les OS actuels, et d’autre part la machine qui reçoit un SYN/ACK inattendu risque de renvoyer un RST au serveur, coupant la connexion.

La poignée de main TCP est en soi une bonne protection anti-spoofing. En UDP il n’y a rien de tel. Cela peut être réalisé par le protocole de niveau supérieur utilisant le transport UDP, mais là encore il n’y a rien de tel dans UDP qui est conçu pour être aussi léger que possible. Mais tous ne le font pas, et permettent l’usurpation d’adresse.

La seule protection anti-spoofing IP ne peut être réalisée que par les FAI qui allouent des adresses IP à leurs clients, en vérifiant qu’un client n’utilise que les adresses qui lui sont allouées. Au pis un FAI peut faire en sorte que rien ne sorte de son réseau avec une adresse qui ne lui appartient pas.

Cela protège l’adresse de la mise au ban. Mais pas de l’usurpation.

Que fait ton serveur DNS exactement ? S’il ne fait que DNS cache récursif pour les machines de ton réseau, tu peux filtrer le trafic DNS en fonction de l’adresse source avec iptables, ainsi les requêtes DNS extérieures seront bloquées.
S’il fait cache pour ton réseau et sert des zones pour tout le monde, tu peux définir deux vues (views) : une récursive visible seulement par le réseau local, et une sans récursion visible par le reste du monde.

Salut,
Merci pour les eclaircissements. Pas de risque de me bloquer moi-même donc, c’est dejà ça…

Pour l’instant mon dns ne sert qu’un seul domaine, qui n’est même pas utilisé…
Pour les autres domaines, j’ai choisi d’utiliser le dns de OVH (ou d’autres Registrar)

Je ne vois finalement pas trop l’intérêt de m’occuper moi même de cette partie…
Ça fonctionne bien comme ça. Pourquoi s’emmerder avec son propre dns, il y a un intéret que je ne capte pas ?

Il suffit donc que mon dns ne serve que localhost (éventuellement tun0 pour le vpn), et je laisse tomber le reste.

Merci d’avoir pris le temps de m’expliquer tout ça. :smiley:

Pour la partie gestion de zones, l’intérêt est d’être indépendant du registrar (en partie seulement si on utilise ses NS secondaires), et de pouvoir faire des choses que le registrar ne supporte pas, ou qui seraient fastidieuses en passant par son interface de gestion (changement fréquents, types d’enregistrements non supportés…)
Pour la partie cache récursif, l’intérêt est d’être indépendant de son FAI pour la résolution DNS.

Pour la partie gestion de zones, l’intérêt est d’être indépendant du registrar (en partie seulement si on utilise ses NS secondaires), et de pouvoir faire des choses que le registrar ne supporte pas, ou qui seraient fastidieuses en passant par son interface de gestion (changement fréquents, types d’enregistrements non supportés…)
Pour la partie cache récursif, l’intérêt est d’être indépendant de son FAI pour la résolution DNS.[/quote]

C’est très clair. Rien (à part le récursif pour le serveur lui-même) qui ne me soit indispensable.
Mes entrées sont “régulières” et stables. A part ajouter de temps en temps un sous domaine rien d’extraordinaire.
Je vais donc laisser l’accès à mon dns par l’interface externe seulement à quelques ip “amies” qui pourraient en avoir besoin (dont moi même avec ma passerelle Internet…).

Merci beaucoup.