Month: November 2013

Copie en SCP depuis et vers un Cisco

Posted by – November 16, 2013

Recuperer des fichiers, IOS, conf, crashdump ou autre depuis un equipement Cisco peut se faire de plusieurs manieres: tftp, ftp, http… ma prefere etant SCP.

Dans un article precedent, j’expliquais comment configurer SSH.

Ici, je me suis butte a une erreur embetante mais assez simple a resoudre.

More

Botnet & 100% CPU

Posted by – November 15, 2013

Il y a quelques jours, je recois un appel d’un client. Plus d’internet, plus de partage reseaux, plus de telephone vers l’externe : La panique!

Hop, je lance putty, j’arrive a me connecter a l’equipement. Premier check que je fais, le CPU et on dirait que j’ai bien fait

 

Il semblerait que le probleme soit la depuis un petit bout de temps. Mais pas de bol, je perds ma session ssh au bout de quelques minutes. A peine eu le temps de regarder ce qui pouvait causer ce probleme:

En affichant la liste des processus, je vois:

Le point interessant ici a voir est la valeur a gauche du slash. Cette valeur indique le % d’utilisation du CPU cause par les interrupts. Il existe plusieurs raisons pour lesquelles un routeur peut etre surcharge par des interrupts.

CEF etant active, pas d’interface ATM, je pars du principe qu’il n’y a pas de bug dans l’IOS et je ne vois aucune erreur d’alignements, il reste donc un choix possible: le routeur est surcharge de trafic.

Le seul probleme dans ce cas, c’est que je perds la main assez souvent du coup il me faut un autre moyen pour recuperer les infos. Avec de l’EEM, je vais pouvoir recuperer un tas d’infos

Le script suivant va me permettre de monitorer l’utilisation CPU toutes les 0.5 sec et lorsque la valeur atteint 70% on declenche les actions qui suivent:

Un event syslog, et la recuperation d’infos qui vont directement dans un fichier sur la flash.

Pour info, l’EEM est actif a partir du moment ou l’event est cree, pas besoin de commandes supplementaires.

Une fois que j’ai recupere le fichier, je peux l’analyser et je m’apercois plusieurs choses. La premiere chose est que l’event a ete declenche de nombreuses fois, ensuite j’ai pu voir les infos suivante sur une des interfaces et les memes valeurs mais en output sur une autre interface.

Du coup, je me decide de concentrer mes recherches sur l’interface qui recoit le trafic, pour aller jusque la source. Cette interface se trouve etre une interface de mon reseau local. Il y a donc un flood provenant de l’interieur.

Apres 2/3 analyses rapides, il existe 3 machines sur ce sous-reseau, qui sont des serveurs. En utilisant de l’EPC, Embedded Packet Capture, je peux effectuer une capture de packet directement sur mon interface et analyser le trafic qui est forward. En mettant en place un buffer lineaire d’une taille suffisante et en filtrant la source je vais pouvoir capturer un echantillon. J’utilise donc encore de l’EEM pour activer la capture car lors d’un burst CPU je perds la main

 

On recupere le fichier par scp, premierement on active la fonctionnalite sur le routeur:

Et avec un client scp classique j’ouvre le fichier et la je vois des choses interessantes:

La premiere choses est qu’il y a un nombre impressionant de requetes/sec provenant d’un seul serveur.

cap1

 

La deuxieme chose est que ce sont exactement les meme paquets. De l’UDP sur le port 6733 avec un payload de 1 octet.
cap2

 

Apres avoir vu cela, je me dis qu’il serait sage de deconnecter cette machine du reseau et de lui faire passer un scan anti-viral avant de la rebrancher.

Le temps que cette operation se fasse, une ACL classique permet de proteger le control-plane contre une sur-utilisation du CPU.

La chose comique dans cette histoire est que la cible de cette attaque est:

De quoi les mettre a l’epreuve!