[Réseau] Iptables et redirection DYNAMIQUE de flux

Support Debian
#1

Bonjour !

Je me tourne une fois encore vers vos lumières pour une problématique un peu particulière qui concerne ces bonnes vieilles iptables.
Je sais depuis longtemps qu’il est tout à fait possible de ré-diriger des flux grâce au SNAT et DNAT mais je me pose une petite question depuis quelques jours : est-il possible de rediriger DYNAMIQUEMENT le trafic venant d’une adresse IP spécifique si celle ci vient à correspondre à une règle iptables?
La question qui se cache derrière est en fait de savoir si il est possible pour mon petit proxy de rediriger une potentielle attaque [D]DOS vers une autre cible si il l’identifie comme tel.

Merci d’avance pour vos réponses ! :smiley:

#2

Qu’entends-tu exactement par “dynamiquement” ? Un exemple concret et détaillé du processus ?

Regarde peut-être la correspondance [mono]recent[/mono].

#3

Bonjour Pascal,

Petite mise en situation.
22 Novembre.
Le froid s’installe doucement à l’extérieur mais la chaleur des ventilos caresse mon visage alors que mes trois serveurs ronronnent silencieusement à coté de moi.
Emmitouflé dans mon drap je surveille calmement mon moniteur de contrôle, mes yeux bondissants du graphique représentant mon flux réseau à celui du nombre de client connectés.
Alors que je m’étire en baillant de tout mon saoul, l’accélération de la ventilation à coté de moi m’interpelle. J’ouvre les yeux et constate avec effroi que le trafic réseau sur le proxy en charge de la redirection des flux sur mes deux serveurs s’envole à tout allure! Toutes sortes d’idées folles me traversent la tête : "Une mise à jour? Impossible, je n’ai rien programmé aujourd’hui. Un rootkit sur l’un des serveurs? J’ai pourtant vérifié tout le système hier …"
Et c’est alors que la vérité me frappe comme une évidence : un attaque DDOS
Mon rythme cardiaque diminue alors, je pose calmement ma tasse et esquisse un sourire.
“Je t’attendais” me dis-je.
Sans perdre un instant je me connecte au proxy et active les règles iptables que je brulais de pouvoir tester depuis une éternité. Le trafic s’effondre alors sur les serveurs attaqués et la redirection du trafic suspect vers le serveur “puit de trafic” que j’avais configuré pour ne pas répondre aux requête se fait correctement.
Je lève ma tasse symboliquement à l’attaquant et lui adresse un poli “Une prochaine fois peut-être”.

Bon après ce petit pavé inutile mais que je me suis bien amusé a écrire, tu aura compris que j’ai deux serveurs cachés derrière un troisième que je nomme proxy. Les clients adressent ce proxy directement sur des ports qui sont redirigés vers l’une ou l’autre des machines derrière par de simples règles de NAT afin de rendre invisible au client les serveurs qui traitent sa demande.
Ce que je souhaite que si quelqu’un attaque sur l’un des ports du proxy, le proxy détecte cette attaque et crée dynamiquement une règle de routage pour l’adresse IP attaquante vers un serveur “puit de trafic” que j’ai configuré pour ne pas répondre aux requêtes.
Je viens de regarder du coté de --recent et c’est exactement ce qu’il me faut mais est-il possible de l’associer a du reroutage?
Je vous joint un schéma sommaire :

En gros si une attaque est détectée, le proxy redirige vers le 1.5 le trafic du suspect.
J’espère que j’ai été clair, j’ai souvent du mal à exprimer ma pensée, n’hésite pas à me demander plus d’infos j’y répondrai du mieux possible!

#4

Si c’est une machine en charge de rediriger des requêtes entrantes vers des serveurs web “backend”, on parle de reverse proxy. Pas proxy tout court.

Et pour espérer survivre à un DDOS ou même à un petit DOS, il te faut un reverse proxy “event-driven”. C’est une manière de programmer inhabituelle. Typiquement, Nginx est programmé ainsi.
Ensuite, tu peux mettre un analyseur de logs qui ajouterait des règles dans iptables d’après les logs de Nginx. Comme le fait fail2ban mais fail2ban n’est probablement pas suffisamment orienté performances AMHA.

(et puis la performance de iptables s’écroule avec un gros nombre d’IPs du genre > 100k. Il faut utiliser les sets de nftables pour cela)

Et si tu ne veux pas te prendre le chou, tu fais sur Google une recherche sur “DDOS mitigation service” et tu cherche un fournisseur qui propose un service gratuit. 5 minutes de configuration plus tard tu peux partir au bord de la plage.

–
AnonymousCoward

#5

Routage et redirection NAT (DNAT), ce n’est pas du tout la même chose.

Je ne vois pas bien l’intérêt de ce serveur par rapport à bloquer le trafic directement sur le proxy.

Concernant la question principale, sur quels critères se ferait la détection d’un DDoS ?

#6

Merci, j’utilisais ce terme à défaut d’un autre car je savais pas vraiment comment l’appeler.

Comme je ne connaissais pas l’existence de ce genre de soft, je vais y jeter un coup d’oeil également.

Le but c’est de m’occuper moi même de cette problématique et non de la déléguer à quelqu’un d’autre (c’est également un projet pour mon école donc je me vois mal leur expliquer que j’ai filé ça à un hébergeur qui s’en occupe ahahah)

Oui je suis d’accord, c’est sur ce point que je ne suis pas encore sur de la manière de procéder : est ce que je redirige le trafic via NAT si le trafic est suspect ou par routage?

J’ai lu quelque part que laisser passer le trafic demandais moins de ressource à la machine que le blocage c’est pour cela que j’étais parti sur l’idée de renvoyer ça à une machine dédiée.

Le nombre de paquets par seconde, leur type (SYN par exemple) et d’autres critères que je découvrirais surement au fur et à mesure que je me documenterai sur les différentes attaques possibles.
Le but pour moi étant de juste trouver la syntaxe iptables pour une redirection dynamique que je pourrai adapter à mes besoins.

EDIT : a votre avis est-ce que cette commande pourrait convenir pour de trop nombreuses connexions ?

iptables -t nat -A PREROUTING -d reverse-proxy/32 -i eth0 -p tcp -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DNAT --to-destination puit-trafic:port

Merci pour votre aide en tout cas!

#7

[quote]
J’ai lu quelque part que laisser passer le trafic demandais moins de ressource à la machine que le blocage c’est pour cela que j’étais parti sur l’idée de renvoyer ça à une machine dédiée.[/quote]
On t’a menti : ne rien faire est le plus simple.

#8

Pourtant c’est la protection mise en place par Orange sur son coeur de réseau pour certains clients entreprises.

#9

Qu’est-ce que ça change ?

#10

Au niveau mémoire, le match des access-lists (ou iptables) demande plus de ressources CPU qu’une règle de routage qui ne va demander que de la RAM lorsqu’il va traiter le paquet

#11

Hum, c’est un point intéressant en effet
(dans ton cas, tu vas quand même appliquer les règles : le paquet t’es destiné, à toi proxy/LB, non ? L’IP dest n’est pas ton proxy ?)

#12

Pour moi un reverse proxy fonctionne au niveau applicatif. Ici, il s’agit de simple redirection NAT au niveau réseau.

Dans l’absolu tu peux faire l’un ou l’autre. La différence principale est que le routage ne modifie pas l’adresse de destination, contrairement à la NAT.

Cela doit dépendre de l’architecture de la machine. C’est peut-être vrai pour une machine conçue avec des circuits spécialisés dans le routage, mais pas pour une machine bâtie autour d’un processeur à usage général comme un PC.

Je ne recours pas assez souvent la correspondance [mono]recent[/mono], d’usage complexe, pour vérifier si la forme est correcte. Par contre les valeurs sont clairement inadaptées : 10 connexions en 60 secondes, ce n’est pas un DoS, il en faut bien plus pour l’affichage de certaines pages web. Aussi, cela peut détecter et bloquer un attaquant isolé mais pas un DDoS bien fait qui répartit la charge entre un grand nombre d’attaquants.

Je me méfie de la cible [mono]recent[/mono] dans un contexte de sécurité, car il est facile de l’abuser par usurpation d’adresse (IP spoofing). Je ferais plus confiance à un système de détection (IDS, fail2ban…) qui crée des règles à la volée quand une attaque est identifiée.