Twitter RSS
formats

Modifier ses trames en Hexa

Publié le 25 février 2013, par dans Non classé.

Bonjour à tous,

 

Cela fait longtemps que je n’avais pas rédiger un petit article. Et pour vous faire plaisir celui-ci est bien réseau comme on les aimes.

 

J’ai récemment eu besoin de tester des certificats et notamment les types de déclaration de common name dans les certificats.

Le point sur lequel je vais m’attarder est le format de common name, il en existe plusieurs mais ceux qui m’intéresse ici sont STRING et UTF8.

 

Je rencontrais quelques problèmes avec certains certificats, alors j’ai donc commencer à comparer un ne posant pas de problème avec un posant des problèmes. Je me suis rendus compte que la majeur différence venait du format des common name, celui qui fonctionnait était en STRING et celui qui ne marchait pas était en UTF8.

 

Pour valider de manière simple mon test j’ai alors capturer les communications avec les 2 différents certificats.

 

Capture échange certificat STRING :

Capture échange certificat UTF8 :

 

Ce n’est pas google que j’ai testé mais le principe reste le même, j’ai re-modifier la capture pour que le certificat soit délivré en UTF8 au lieu de TELETEXSTRING normalement.

 

Mon problème étant avec les UTF8  j’ai donc souhaiter re-modifier ma capture pour que l’envoi ce face en STRING.

D’abord, j’ai repéré comment était déclaré google en UTF8 :

Puis, j’ai repéré comment était déclaré le deuxième certificat en String :

Ici le common name est identique mais le plus important est de relever le octect chiffre Hexa qui défini le type du common name.

Le deuxième octect représente le nombre de caractère dans le common name. Il n’est donc pas nécessaire de le modifier.

Pour modifier première capture afin d’obtenir la deuxième, il faut l’enregistrer au format texte  comme suit :

 

Vous pouvez ensuite éditer le texte avec notepad par exemple.

Vous pouvez ensuite rechercher les caractères qui vous intéressent et les remplacer :

Ici recherche :  0C\|0b\|2a\|2e\|67\|6f  et remplacer par 14\|0b\|2a\|2e\|67\|6f

Une fois appliqué tous les envois de certificats google seront maintenant dans votre capture passeront de UTF8 à String.

 

Vous n’avez plus qu’à ré-ouvrir le fichier texte avec wireshark et le sauvegarder en PCAP pour le rejouer avec un TcpReplay par exemple.

Vous pouvez déjà bien vous amuser à modifier vos captures.

 

formats

Les mumbos jumbos frames

Bonjour à tous,

Aujourd’hui je vais vous parler d’un truc barbare, les « jumbos frames ».  Pour ceux d’entre vous qui côtoient le monde du réseau surement ce mot vous évoque quelque chose. Alors, pour tout le monde je vais  rapidement expliquer de quoi il s’agit et quel peut être le problème rencontré.

 

D’abord les jambo frames ce sont de paquets réseaux dont la taille dépasse les paramètres de configuration du réseau aussi appelé MTU (Maximum Transmission Unit).

Dans la pratique, les réseaux sont paramétrés avec une taille de paquet défini pour éviter les pertes, l’affaiblissement et garantir un réseau fonctionnel. Dans le monde ethernet cette valeur est le plus souvent à 1500.

Si c’est plus ou moins standard, pourquoi verrait-on des jambos frames sur notre réseau et quel peut être l’impact.

Tout d’abord il faut savoir que les routeurs qui reçoivent des jambos frames doivent les fragmenter pour les router sur le réseau. Ce procéder créé de la charge CPU pour les routeurs en plus de ses taches de routage ce qui n’est pas forcément une bonne chose. De plus certains équipements tel des firewall ou équipements drop ces trafics.

Dans la généralité avoir du trafic jambo frames n’est pas très bon pour un réseau, ce qui ne veut pas dire qu’il ne faut qu’il y en ait mais plutôt qu’il vaut mieux contrôler leur circulation.

Il existe aussi des mécanismes qui permettent de détecter la MTU utilisant les jumbos frames pour détecter le maximum utilisable. Sachant que les routeurs retourne des paquets ICMP au poste générant des jambo frames pour l’en avertir.

 

Je vais vous expliquer comment simplement trouver un host qui génère des jumbo frames.

Si vous possédez un firewall linux il est très simple de les détecter, tout d’abord en executant la commande  :

ifconfig
eth0               Link encap:Ethernet HWaddr 00:90:0B:20:E1:89
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:48740 errors:653 dropped:0 overruns:0 frame:653
TX packets:46690 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:12375281 (11.8 Mb) TX bytes:14504062 (13.8 Mb)
Memory:feae0000-feb00000

Ici on voit que on reçoit des jumbo frames : RX (frames : 653) et on se rend compte que le serveur les drops (errors:653)

 

Maintenant, il faut s’assurer que les jumbos frames sont encore envoyés donc que l’activité supérieur à la MTU est encore présente dans notre réseau.

apt-get install ethtool

Une fois installé vous pouvez consulter les jumbo frames grâce à la commande qui suit :

ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256

Ici, plus de jumbo frames donc pas d’inquiétude il n’y a plus de soucis. Néanmoins si j’en avait trouvé j’aurais pu les retrouver grâce à une capture tcpdump.

Voici la commande permettant de retrouver les machines qui génèrent des jumbos frames :

tcpdump -c 2500 -s 0 -i eth0 -w jumbo.pcap

-s 0           valeur par defaut de chaque paquet

-i eth0      choix de l’interface eth0

-c 2500    nombre de paquet à capturer

L’option la plus importante est l’option -s 0 qui permet de ne pas définir la size des paquets donc tous les paquets supérieur à la MTU seront aussi sauvés.

Il suffira alors de vérifier quels paquets sont supérieurs à la MTU via wireshark et retrouver les machines correspondantes.

Ce genre de problèmes est assez fréquent, et il est toujours bon de vérifier l’état de son parc. Voila vous avez maintenant toutes les informations importantes sur les jumbos frames.

 

formats

Test de vulnérabilité Reset-TCP

Bonjour à tous,

j’ai récemment testé une vulnérabilité sur une de mes machines, NESSUS me révélant que ma machine était vulnérable aux reset-TCP. J’ai alors décider de tester moi même pour mieux comprendre le problème et je souhaitais vous partager les résultats.

 

D’abord pour mieux combattreune vulnérabilité,  il faut  la comprendre. Lorsqu’une session est établie des échanges s’effectue entre les deux machines pour la gardée ouverte et qu’elle puisse continuée. Si pour une raison divers l’une des deux machine rencontre un problème par exemple pas de nouvelle requête pendant un certain temps, un mécanisme TCP permet de reset la connexion, pour de nouveau établir une session sur des bases saines.

Exemple directement pris de mes tests, si vous créez une communication en python via les lib scapy, au début de la communication le système voyant que la session qui est entrain de se déroulée n’est pas sous son contrôle, le système va de lui même envoyer des reset-TCP ou RST  pour clore la connexion et si besoin la crée lui même. Typiquement ici, le système s’aperçoit que quelque chose n’est pas normale et tente de reprendre le contrôle.

 

Donc quelle est la vulnérabilité ? Passons maintenant du coté d’un malware ou d’un attaquant qui souhaite couper la connexion a un service. Pour lui c’est simple, si vous êtes vulnérable il lui suffira d’envoyer des reset-TCP en se faisant passer pour vous, ce qui aura pour conséquence de couper votre connexion.

 

Pour tester, j’ai rapidement trouvé un script C qui permet d’envoyer en boucle les requêtes RST.

Disponible ici.

 

Alors comment l’utiliser :

 

  • Installer les librairies
apt-get install libnet1-dev

 

  • Editer le fichier et remplacer les valeurs des adresses MAC :

Exemple :

u_char enet_src[6] = {0x9c, 0xaf, 0xca, 0x8f, 0x5a, 0xcf};
u_char enet_dst[6] = {0×00, 0xE0, 0x4B, 0×21, 0×59, 0×62};

enet_src : Adresse mac du client (vue par la sonde donc potentiellement celle d’une passerelle)
enet_dst : Adresse mac de la sonde attaquée

 

  • Compiler :
gcc reset-tcp.c -o reset-tcp /usr/lib/libnet.a
  • Lancer l’attaque :

Usage: ./reset-tcp [interface] [src ip] [src port] [dst ip] [dst port] [window size]

Exemple pour une session ssh sur la sonde :

./reset-tcp eth0 172.16.17.151 49252 10.205.3.6 22 65536

eth0 : interface utilisée pour l’attaque
172.16.17.151 : adresse ip du client
49252 : port source utilisé par le client
10.205.3.6 : adresse ip de la sonde attaquée
22 : port destination (port ssh ici)
65536 : Taille de la fenêtre TCP (pas important mais requis)

 

Une fois lancé vous perdez la session car elle est coupé par l’attaquant qui envoi des reset, ce script ne coupe que temporairement donc permet de récupérer la connexion après. Cependant, si vous jouez ce script en boucle il est possible de couper la connexion.

Il faut voir ici que la machine est vulnérable car elle ne vérifie pas la cohérence du reset qu’elle reçoit, elle ne vérifie pas que les numéros de séquences concordent avec l’émetteur et clos la communication.

Vous pouvez donc tester ça chez vous. L’impact est minime.

 

Infos complémentaires :

Nessus : Plugin 12213 

 

formats

Générer et déployer ses clés

Publié le 30 novembre 2012, par dans admin, Linux, Serveur.

Lorsque l’on fait de l’administration système on se retrouve souvent avec une multitude de site à gérer.

Et pour s’y connecter si on s’impose un minimum de sécurité, ça devient vite compliqué.

C’est pourquoi tant pour le coté pratique que sécuritaire utiliser des clés de chiffrement c’est une bonne solution. Premièrement plus besoin de taper de password à la connexion et deuxièmement pour une meilleure sécurité.

Alors comment procéder, tout d’abord il faut générer sa clé.

ssh-keygen -t rsa -b 4096

-t rsa/dsa méthode de chiffrement 

-b 4096 pour les plus parano d’entre vous (taille de la clé par défaut à 2048) 

Après avoir générer votre clé il faut ensuite la déployée comme suit.

ssh-copy-id -i ~/.ssh/id_dsa.pub <username>@<ipaddress>

Enfin si vous le souhaitez vous pouvez blinder la sécuritée en ajoutant dans les paramètres ssh de n’autoriser que la connexion par clé de chiffrement.

/!\ Attention le serveur ne vous authentifiera que si vous avez la bonne clé.

Script : activation connexion par clé :

#!/bin/bash
sed -i ‘s/#PasswordAuthentication yes/PasswordAuthentication no/’ /etc/ssh/sshd_config
sed -i ‘s/UsePAM yes/UsePAM no/’ /etc/ssh/sshd_config
/etc/init.d/ssh reload
exit[

Script : désactivation connexion par clé
#!/bin/bash
sed -i ‘s/PasswordAuthentication no/PasswordAuthentication yes/’ /etc/ssh/sshd_config
sed -i ‘s/UsePAM no/UsePAM yes/’ /etc/ssh/sshd_config
/etc/init.d/ssh reload
exit

 

formats

Tester son site avec des outils apache

Bonjour, aujourd’hui et après avoir tester les performances du site avec httperf, je vous propose de tester avec ab (apache benchmark)

 

Pour cela, il faut installer les outils apache :

apt-get install apache-utils

 

Ensuite on peut procéder au test :

ab -n <nombre de connexions> -c <nombre de sessions concurrentes> <site web>

 

Voici le test sur mon site :

ab -n 6000 -c 35 https://www.learn-it.fr/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking learn-it.fr (be patient)
Completed 600 requests
Completed 1200 requests
Completed 1800 requests
Completed 2400 requests
Completed 3000 requests
Completed 3600 requests
Completed 4200 requests
Completed 4800 requests
Completed 5400 requests
Completed 6000 requests
Finished 6000 requests
Server Software: Apache/2.2.16
Server Hostname: learn-it.fr
Server Port: 80
Document Path: /
Document Length: 49301 bytes
Concurrency Level: 35
Time taken for tests: 184.339 seconds
Complete requests: 6000
Failed requests: 0
Write errors: 0
Total transferred: 297902342 bytes
HTML transferred: 295928491 bytes
Requests per second: 32.55 [#/sec] (mean)
Time per request: 1075.312 [ms] (mean)
Time per request: 30.723 [ms] (mean, across all concurrent requests)
Transfer rate: 1578.18 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 17 440 2319.6 95 93333
Processing: 306 473 55.4 466 1239
Waiting: 25 103 43.2 98 914
Total: 324 913 2320.3 564 93760
Percentage of the requests served within a certain time (ms)
50% 564
66% 582
75% 597
80% 609
90% 678
95% 3565
98% 3622
99% 4236
100% 93760 (longest request)

On voit ici que le résultat est rassurant mais que le temps de latence max atteint 90s ce qui tant à montrer que mon site atteint ses limites.

Cependant, sur 6000 requêtes avec 35 concurrentes, 90% ont eu leur réponse en moins de 1 seconde ce qui un bon temps et 99% à 4s.

 

Nouveau test pour tester le nombre de sessions concurrentes possibles.

ab -n 300 -c 150 https://www.learn-it.fr/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking learn-it.fr (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Finished 300 requests
Server Software: Apache/2.2.16
Server Hostname: learn-it.fr
Server Port: 80
Document Path: /
Document Length: 49301 bytes
Concurrency Level: 150
Time taken for tests: 9.476 seconds
Complete requests: 300
Failed requests: 0
Write errors: 0
Total transferred: 14975528 bytes
HTML transferred: 14876199 bytes
Requests per second: 31.66 [#/sec] (mean)
Time per request: 4738.083 [ms] (mean)
Time per request: 31.587 [ms] (mean, across all concurrent requests)
Transfer rate: 1543.30 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 18 142 457.9 70 3144
Processing: 359 488 163.6 443 1225
Waiting: 29 119 157.1 70 971
Total: 424 630 479.5 517 3823
Percentage of the requests served within a certain time (ms)
50% 517
66% 538
75% 571
80% 599
90% 729
95% 1162
98% 3438
99% 3549
100% 3823 (longest request)

Ici moins de connexions en tout mais plus de sessions conccurentes.

On voit que le site tient 150 sessions concurrentes avec à 95% un temps de réponse à environ 1s.

On va aller plus loin et afficher ces données en image sous forme de graphique car ab le permet.

Pour cela :

ab -n 300 -c 150 -g ./bench.data https://www.learn-it.fr/

-g <fichier> Générer un fichier exploitable au format plot 

 

Il faut maintenant installer les outils gnuplot pour traiter ses données.

apt-get install plotutils

On peut maintenant exploiter ces données pour générer un graph comme suit :

gnuplot
gnuplot> set terminal png
gnuplot> set output « Benchmark learn-it.png »
gnuplot> set title « ab -n 300 -c 150″
gnuplot> set size 1,1
gnuplot> set grid y
gnuplot> set xlabel « Request »
gnuplot> set ylabel « Response time (ms) »
gnuplot> plot « bench.data » using 9 smooth sbezier with lines title « varnish »

- terminal pour configurer le format de sortie

- output pour définir le fichier de sortie

- titre pour définir le titre

- size pour définir la taille (1 = 100%)

- grid pour spécifier l’affichage de la grille en ordonnée

- xlabel et ylabel pour définir le champs abscisse et ordonnée

- plot pour générer le graphique; using pour spécifier le nombre de colonnes; smooth pour le type de lissage

Et voila votre graphique est alors généré !

© learn-it.fr