On Tue, Nov 19, 2013 at 07:48:35PM -0800, Michel Py <mic...@arneill-py.sacramento.ca.us> wrote a message of 18 lines which said:
> Je ferai néanmoins remarquer que la technique qui consiste à > prépender les AS intermédiaires pour le chemin de retour propre est > un bon moyen de se faire prendre. Ca dénote une extrêmement bonne > compréhension de BGP, ceci dit. Ou la capacité à lire l'article de Kapela et Pilosov, qui date de cinq ans, et qui décrit cette technique (et d'autres, que les attaquants détectés par Renesys n'ont pas utilisé). Cela donne une idée du délai entre une publication à DEFCON et sa détection dans la nature (détection != utilisation : si on ne regarde pas, on ne voit rien). > Ceci étant dit, quand on fait ce genre de chose et qu'on veut éviter > de se faire remarquer, il y a bien plus discret: trafic de retour à > travers un tunnel qui se termine au bon endroit près du préfixe > kidnappé. Les services cybersecrets biélorusses recrutent, si tu veux quitter la Californie pour Minsk. > Ca demande un peu plus de préparation, mais c'est nettement plus > discret; une partie des algorithmes de détection de ce genre de > chose est basée sur l'analyse de l'AS_PATH du préfixe kidnappé qui > est trop long et qui paraît louche quand comparé à la topologie. Ici, l'analyse du RTT aurait bien marché, aussi. Et, contrairement au TTL ou au chemin d'AS, c'est quasi-inmodifiable par l'attaquant. Donc, dans votre système de supervision, n'oubliez pas une alarme pour les cas où le RTT dépasse une certaine valeur. Avec le plugin Nagios check_ping, le RTT est le premier chiffre du seuil qu'on indique, le deuxième étant le taux de perte. Et RIPE Atlas est en train de terminer la mise au point d'un système d'alerte qui permet de déclencher une alarme quand plus de N sondes Atlas voient un problème. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
