Filtrer des IP entrantes en amont ?

[rantopi]

Bonjour,

Depuis quelques jours, ma box est scannée de manière répétée par un attaquant qui tente d'établir une connexion pptp (VPN) entrante.
La plage d'adresse entrante est toujours la même : 92.63.194.xxx (identifiée en Russie)

Question simple : est-il possible d'ajouter un filtrage sur des IP entrantes pour que toute tentative de scan ou connexion soit rejetée pour celles-ci ?

Merci pour vos conseils.
Cdt

[Fyr]

Non, pour filtrer un paquet il faut l'avoir reçu.

Si vous n'avez pas ouvert le port pptp pour un service à vous, son paquet sera discardé sans plus de travail. Si ca vous bouffe la bande passante ca devient une autre histoire et il faudra contacter le support, en urgence

Comme je suis pas techos chez K-Net je peux pas m'engager pour eux mais à moins d'un vrai grave problème personne ira foutre une règle en amont sur un gros routeur pour bloquer des tentatives pptp sur une IP, fut-elle russophone. Si c'est votre routeur, configurer votre règle de block policy pour ne rien répondre (pas d'ICMP "administratively filtered"/"unreach", ou un "tcp rst", just un drop silencieux) comme ça il aura un process bloqué en attente de réponse de sa tentative... et ça peut le faire chier.

Après y a des FAI qui ont des lessiveuses à paquet avec "en amont" des Arbor  (de merde qui oblige à faire des trucs très sales en architecture, ca devient un trou noir de réseau avec tout qui passe par cet équipement) et on commence à faire des bricolages très très crades. Ca plait beaucoup aux jeunes. A une époque on décrochait son phone. Ou on laissait un mail avec son num on disant "rappelez moi !", on expliquait la vie aux AS concernés et si y avait pas de réponse on annonçait ses réseaux à Pampelune. Ah tient mon téléphone sonne comme c'est bizarre !

Y a un client de K-Net y a qqs mois qui s'est fait bloqué automatiquement chez Ielo parce qu'il bouffait sa bande passante légitimement, certainement par une saleté d'Arbor.

[Vincent O]

Fyr a tout bon.

Même si effectivement il semble y avoir des rapports de scans venant de cette plage (exemple : https://www.abuseipdb.com/check-block/92.63.194.91/24), il y a plusieurs aspects à considérer :
- la plage d'IP complète n'est pas forcément pleine de machines qui scannent, il peut aussi y avoir des machines qui hébergent des services légitimes, et vous ne vous en rendrez compte qu'une fois bloqué ; ce qui mène au deuxième point...
- si on met une règle sur nos "gros" routeurs, ça n'est que semi-automatisé, et vous n'y aurez clairement pas accès. Donc s'il faut débloquer la plage pour une raison ou une autre, ça prendra plusieurs heures / jours le temps que le support remonte l'information et qu'on le fasse
- on a une limite sur le nombre d'ACL qu'on peut mettre sur nos "gros" routeurs
- et probablement le plus important, on a un devoir de neutralité du net, donc à moins qu'il y ait un risque pour l'intégrité du réseau (DoS / DDoS), une demande légitime venant d'un juge ou autorité compétente (à ma connaissance, ça n'est jamais encore arrivé), ou qu'il y ait un risque vraiment critique pour les clients (le seul cas que je vois serait un 0-day sur nos routeurs, le temps qu'on corrige le bug), on ne bloque pas de nous même

[Fyr]

- on a une limite sur le nombre d'ACL qu'on peut mettre sur nos "gros" routeurs

En plus y a un pb MAJEUR à metter des ACL sur les gros routeurs, très en amont, et qui gèrent bcp de trafic : une règle de filtrage (ACL) ca implique de prendre -tous- les paquets, de les sortir des mécaniques harwadre de routage dans les puces spécialisées et de les envoyer dans le CPU général pas fait pour ça, qui lui à l'intelligence pour comparer les paquets à une règle administrative, et du coup ca flingue les performances de routage et l'impact est global. Versus un impact local et mineur de connexion pptp.

Tu peux te dire : OK, mettons la règle alors plus loin dedans l'infra, vers un routeur moins global, plus proche du pb à traiter, et on revient au soucis d'encombrer l'infra de paquets à jetter juste à coté du routeur client. Hors danger, la solution la moins moche est de le laisser se fracasser au niveau de votre routeur. Et y a pas de maintenance de ces règles à gérer.

[Vincent O]

une règle de filtrage (ACL) ca implique de prendre -tous- les paquets, de les sortir des mécaniques harwadre de routage dans les puces spécialisées et de les envoyer dans le CPU général

Oh la, non, nos routeurs principaux font ça en hardware, certains ont même des puces spécifiquement pour gérer les ACL.

Même les Icotera ont des ACL appliquées en hardware.

[Fyr]

Oh mince ! déjà !

[Steph]

C'est des SOC?

[Vincent O]

C'est des SOC?

Pour appliquer une ACL, il y a en gros 3 parties :
- parser les paquets entrants
- lookup des ACL pour trouver celles qui correspondent
- appliquer la décision

Les ASIC de forwarding sur les "gros" routeurs doivent déjà parser tous les paquets entrants (pour trouver l'adresse MAC de destination, IP de destination, terminer les tunnels, gérer les VLAN, QoS, ...), donc ça ne change rien. Appliquer la décision, c'est simple aussi.

Ça fait un moment que les SoC/ASIC peuvent appliquer des ACL (comme dit précédemment, même le SoC des Icotera peut le faire).

La gestion de la mémoire sur un routeur par contre, c'est un peu plus tordu.

- Le CPU a sa propre RAM
- L'ASIC a des buffers internes et "externes" pour stocker les paquets en attente de traitement / d'envoi
- L'ASIC a plusieurs types de mémoires spécifiques, par exemple TCAM, LEM, LPM... Et il a besoin de stocker un certain nombre de tables différentes dedans : MAC table, ARP table, les routes, les préfixes, les règles pour les ACL, QoS, ...

Ces types de mémoire ne sont pas généralement de la RAM. Pas d'accès aléatoire (je veux "cette" adresse). La mieux documenté c'est la TCAM : au lieu de lui donner une adresse à accéder, on lui donne un motif à chercher (exemple : je cherche un mot de 8 bits, qui commence par 101010, et peu importe la valeur des 2 bits restants), et elle va retourner toutes les valeurs correspondantes. La LEM est similaire, mais retourne un seul résultat, le plus spécifique.

Savoir quel table va dans quelle mémoire est un peu tordu : ça va bien sur dépendre du modèle de l'ASIC mais aussi de la taille de la donnée à stocker (un préfixe IPv6 peut partir dans un type de mémoire, et un autre dans un autre type), et du profil choisi (on peut choisir parmi des "TCAM profiles" prédéfinis, qui en gros définissent le "partitionnement" de la mémoire : tant de mémoire pour cette table, tant de mémoire pour telle autre table).

Les ACLs sont généralement stockées dans la TCAM. Problème de la TCAM : 1) c'est cher ; 2) au plus c'est gros au plus c'est lent (il faut tout parcourir pour trouver les correspondances); 3) il faut partager.

Un constructeur a mis une puce à part sur certains switchs/routeurs pour gérer la mémoire des ACL (une sorte de MMU je suppose), couplé à de la "vrai" RAM et une modif du pipeline de l'ASIC.
https://www.arista.com/assets/data/pdf/Whitepapers/Arista_7280_Switch_Architecture.pdf

La partie intéressante c'est Algomatch, mais je conseille de lire complètement de la page 13 jusqu'à 21 "Arista 7280R Universal Leaf Platform Packet Forwarding Pipeline".

Un peu plus de détails : https://www.arista.com/assets/data/pdf/Whitepapers/AlgoMatch_ProductBrief.pdf

Au vu de l'évolution des ASIC (quasiment complètement programmables (voir Broadcom Elastic Pipe et SDKLT) et qui semble gérer de la RAM), je suppose qu'il n'y a même plus besoin de chip à part pour les dernières générations des ASIC de forwarding.

[Steph]

Merci Vincent.
C'est tout un monde en soi le routage!
J'ai de quoi lire pour un moment...