Le projet que je vais utiliser ici s’appelle Durandal, et c’est un projet français !!.

Le logiciel en question supporte :

Linux/Windows en 32 et 64 bits et est capable de péter du MD5,SHA1/256/512,NTLMv1 et MYSQL via GPU par CUDA (pas d’OpenCL pour le moment), soit par brute force, soit par les chaines de markov (j’ai pas tout lu sur le sujet, mais ça a l’air passionant xD).

Il fonctionne en distribué (possibilité d’avoir donc plusieurs machines effectuant les calculs nécessaire au cracking).

CUDA (partie apparement pas obligatoire)
Pour ce tuto, j’utilise ubuntu 11.10, avec un Phenom 810 X4 et une GTX260, avec les drivers NVidia de base (depuis la version 260, les drivers fournit proposent un support direct de CUDA, il suffit donc de récupérer et d’installer le « CUDA Toolkit for Ubuntu Linux 10.10″, c’est juste pour choper le nvcc et générer le cubin plus tard).

Puis on indique les path de cuda dans le ~/.bashrc :

Ensuite sur ubuntu la version de GCC/G++ est la 4.6 et cuda ne supporte pas les version au-dessus de la 4.5
Donc on install la 4.4, et l’on créer les update-alternatives pour switcher à nouveau en 4.6, histoire d’être pas trop crade

Un petit coup de update-alternatives pour switcher entre les version 4.6 et 4.4

Durandal

On passe à l’installation de durandal (la manip est indiqué sur le site web) :

Dans le README, il est conseillé de faire un nvcc sur le fichier src/agent/kernels/md5.cu, puis faire un bin/cudump md5.cubin, mais le fichier hpp généré ne peut être utilisé (le build plante, au final, mon GPU sera tout de même détecté et utilisé donc c’est pas trop grave).

Donc on passe direct à la compil/install.

Ensuite, il suffit de suivre les instructions des différents executables

durandal.sh, qui créer le serveur en demandant les ports d’administration (j’utilise le port 21000) et de cracking (j’utilise le port 20000) pour les clients

admin, qui drope une console d’admin pour ajouter hashes

agent, qui permet au client de lancer le cracking (à distance, ou en local)

Les petits screenshots (avec le md5 mis en exemple sur le site du projet durandal) :

le serveur et la console d’administration :

le client avec le benchmark à son lancement (sur la même machine dans mon cas), ma GTX260 n’est pas aussi bien que ce que j’espérais, mais elle à quand même deux ans ^^ :

Un projet sympa à suivre …

Ressources :
Durandal : http://durandal-project.org/index.html
Alternative Gcc/G++ : http://askubuntu.com/questions/26498/choose-gcc-and-g-version
CUDA (toolkit et SDK) : http://developer.nvidia.com/cuda-toolkit-40

Articles similaires :

• Cracking de WPA/PSK (Pyrit/CowPatty)
• Téléchargement Direct et Linux (Tucan)
• BT3 dans les bacs … les hackeurs vont se régaler
• Commandes linux sympa
• Exemple de Bot d’Authentification et de clic en Php

Dans la suite de mon article sur « le hacking facile » avec metasploit et meterpreter, voici venu celui avec l’encodage de payloads dont je parlais rapidement à la fin du précédent article, et que j’ai supprimé suite à de nombreuses critiques sur des forums de hack (selon eux, le fait de piper des msfencode en format raw bousillait la payload, mes tests étaient pourtant concluant lors de l’écriture de l’article (j’ai peut-être du me gourrer de payloads mais … simple question de logique : à quoi d’autre pouvait donc servir le format raw ?).

Une autre méthode (officielle et plus propre que celle-ci est dispo en anglais : http://www.room362.com/blog/2011/7/17/metasploit-payloads-explained-part-1b.html)

Depuis la dernière version de metasploit un nouvel outil pour encoder est apparu : msfvenom (une fusion de msfpayload et msfencode), et j’ai donc voulu tester si ce nouvel outil était lui aussi capable de piper les encodages … et la réponse est Oui ^^.

Alors à quoi ça sert de piper les encodages ? De nombreux antivirus détecte généralement le premier encodage des payloads metasploit, mais si l’on en met plusieurs à la suite, certain antivirus deviennent inefficace (comme l’antivirus Comodo à mon grand regret :s).

De base, msfvenom s’utilise ainsi :

Pour lister les encodages, les nops et les payloads, vous pouvez faire un :

Et y’a de tout : du linux, du windows, du mac, du php, …

On peut aussi utiliser les options -x et -k pour utiliser des templates et contourner certain antivirus en utilisant des executables windows de confiances.

Et pour piper les encodage ?

Pour le premier msfvenom on spécifie la payload, ici un reverse_tcp pour meterpreter, au format raw, l’encodage (et son itération si l’envie vous en prend ), et pour le second on fournit la platforme et l’architecture, ainsi que notre encodage et le format (du moment que l’on reste en raw on devrait pouvoir les piper).

Et un executable devrait ressortir, ici meter.exe (si cet executable est lancé sur le PC d’une victime (volontaire ), son pc devrait essayer de se connecter sur 192.168.1.12 et sur le port 4444 pour lancer une session meterpreter).

La récupération de la session se fait en utilisant le multi/handler
soit en passant par msfconsole :

soit plus rapidement en passant par msfcli (beaucoup plus rapide) :

Donc voilà, j’ai peut être pu me tromper dans mon précédent article, mais maintenant, c’est officiel, on peut piper du venom ^^.

Bon amusement

Petite note sur les anti-virus suite à ce test :
Avant ce test, je comptais utiliser Comodo, l’antivirus/firewall (avec HIPS et sandboxing) qui semblait pas mal efficace, pour remplacer avast qui me semblait pas au top, après le test des encodages de payloads je pense que je vais rester sur avast : il détecte direct la payloads, alors que comodo ne dit rien du tout :s … (et comodo est plutôt lourd et à tendance à tout sandboxer).

A noter que la dernière version d’Avast comporte un système de sandboxing, reste à voir si il est performant … celui de Comodo est lourd à souhait :s.

Articles similaires :

• Sortie de Metasploit 3.2
• BT3 dans les bacs … les hackeurs vont se régaler
• Metasploit et Meterpreter pour du piratage facile ?
• Un projet de scanneur de vulnérabilités web open source
• Pourrir des votes avec bash et wget

Suite à mes articles sur la protection DDoS (soft et hard en logiciel …), le serveur que je protegeais (minefield) à subit d’autres attaques DDoS de plus en plus forte … jusqu’à il y a peu une attaque à 5gb/s qui à finalement provoquée la fermeture du serveur par l’hébergeur.

D’abord une à 100mb/s pendant 5/10 minutes mercredi 30 mars, que personne n’aura senti, notre machine branchée en 1Gb/s tiendra le choc sans souci, et le firewall a très bien fait son boulot, aucun service ne crashera et aucun d’eux ne sera même ralenti.

La suivante du samedi 2 avril (à 981mb/s sur le graphe … à 5gb/s selon l’hébergeur) saturera complètement notre baie (45 machines sur un routeur 10Gb) nous sera fatale (il parait que c’est même pour ça que tout le réseau d’online à été ralentie pendant ce week-end, provoquant la coupure d’autres machines sur la même baie) :

Sans revenir dans les détails, sur les milliers d’ip qui nous ont assailli, seule 200 ip on passées notre première règle anti-ddos (le hitcount de la protection soft), et se sont retrouvés définitivement banni par la protection « hard » (en hosts.deny et en règles iptables), aucune n’aura été fatale pour les services en eux-mêmes, les graphes de ram et de cpu nous montre que l’attaque a entièrement (en grande partie) été encaissée par le firewall.

Lorsque j’ai mis ces protections en place, je ne pensais pas que ça allait être très efficace sur de très grosses attaques (ok tout est relatif, mais pour un amateur, se prendre du 5gb/s c’est quand même une consécration ^^ d’autant plus que c’était pour protéger des petits cubes), cette attaque m’a permit de constater qu’iptable est un outil très puissant et sur lequel on peut compter même sur de grosses attaques, mon seul regret a été la réaction d’online, qui ne nous a même pas proposé de passer sur des services « pro », ou même juste nous filer d’autres ip (branchées sur d’autres ports du switch ou sur un autre routeur) pour faire du bonding (notre machine possédait plusieurs cartes ethernet) et faire de la répartition de charge (aurait-ce été suffisant pour contrer cette attaque ?).

Donc voilà, chez online vous avez du super matos pour un prix défiant toute concurrence, mais vous n’avez pas de SAV digne de ce nom : les admins de minefield sont allés sur leur chan IRC chercher de l’aide, ils n’ont eu que des insultes (des « propos » insultant et non des insultes en soi) en retour, les différentes demandes de prises de contacts ont toutes échouées (par mail et par ticket). Tant que vous n’avez pas de problème, online c’est génial, après, faut voir ailleurs.

En espérant un prompt rétablissement de minefield, en outre-rhin cette fois, nous testerons la « Deutsche Qualität », avec un réseau redondant et parait-il protégé en « partie » contre les DDoS (possibilité d’ignorer des ip/plage directement sur les routeurs en amont).

Articles similaires :

• Checker la validité d’une adresse mail en PHP via SMTP
• Tentative de Hack … quand les kikoolols attaquent!!!
• Exemple de Bot d’Authentification et de clic en Php
• Protection Ddos (soft)
• Syn Flooding, optimisation PHP, …

Aujourd’hui j’ai joué a « qui a la plus grosse » config ssl et c’est là que j’ai remarqué que le mod_ssl d’apache ne supportait que les protocoles SSLv3 et TLSv1.0 (le TLSv1.1 est en cours de dev) ce qui donnait un score pitoyable à mon blog sur ssllabs (qui permet d’avoir une idée du niveau de sécurité de l’implémentation ssl/tls d’un serveur web).

(Au passage certaine banques françaises en sont encore au niveau F, donc c’était déjà pas trop mal pour un blog ^^).

Ma configuration pour le mod_ssl ressemblait à ça, avec un certificat gratuit de chez startssl :

Mais bon, si l’on peut faire mieux gratuitement, on ne va pas s’en priver, donc on installe :

A noter au passage, que gnutls supporte le SNI (utilisation de plusieurs certificat SSL sur une seul et même IP), et le protocole TLSv1.1

et on rajoute la conf :

Au passage, on remarque qu’il y a des fichiers en moins entre la config du mod_ssl et celle de gnutls … WTF ?!, en fait on a pas besoin du ca.crt, par contre, il faut concaténer le certificat du site (blog.crt) avec celui de la « chaine » (sub.class1.server.ca.crt).

Ce que l’on peut faire par un simple :

On peu lancer un apache2ctl configtest, pour vérifier si la conf est bonne et redémarrer si il n’y a aucun problème.
Pour ma part avec startssl, le format de mon fichier key n’était pas supporté :

Il a fallut supprimer la protection par mot de passe de la clé (pas bien :s), que j’ai fait sur le site de startssl, ou que l’on peut faire via la commande openssl.

Et si l’on refait un test, on a un meilleur score :
.

Le but de cet article n’était pas de dénigrer le mod_ssl (le fait que TLSv1.1 et TLSv1.2 ne soit pas encore supporter est juste due à ma version d’openssl de ma debian 6.0), mais juste de présenter le module gnutls (et son utilisation avec des certificats de chez startssl) qui ne semble pas supporter la renégociation et la compression (malgré l’utilisation du mot clé COMP-DEFLATE), mais qui peut supporter l’authentification par clé pgp et plein d’autre truc …

Un peu de doc au passage sur les différents systèmes de chiffrement :

• Les ciphers suites
• La doc officiel

Articles similaires :

• Utiliser plusieurs certificats SSL sur un seul serveur apache
• Sécurité : Coupler l’IDS Prelude avec mod_security
• Administration de serveurs apache : virtualhost
• Des certificats SSL gratuit et valide pour vos sites web
• Réduire la consommation de bande passante (Apache mod_deflate)

un petit retour sur le Ddos de ce week-end … conformément aux prédictions de certains concernant mon précédent article, un ban permanent n’est généralement pas une bonne idée, notemment lorsque les paquets sont forgés :

• ça remplit inutilement les règles du firewall (la dernière attaque avait finit avec 600 lignes de DROP, ce qui rend difficile la lecture des règles mise en place)
• en cas de ban d’un « client/joueur », il est banni à vie
• il y a un risque si l’attaquant connait l’ip de l’admin et la fait bannir en floodant avec son ip
• …

Donc on m’a filé une autre commande, plus courte et aussi performante, sans remplir inutilement les règles iptables :
(il faut supprimer l’espace entre les deux – - dans les commandes suivantes, wordpress les transforme en un seul -)

Ici, on surveille tout les nouveaux paquets sur le port 25565 et si la même ip renvoit de nouveaux paquets on incremente un compteur, si celui-ci atteint le hitcount (ici 5) dans les 60 secondes, on drop les paquets.

Si le visiteur lambda se fait drop, il devra juste attendre la fin de l’intervalle depuis son dernier paquet envoyé (ici 60 secondes à chaque fois),

Si c’est une attaque dos, il ne pourra envoyer que 5 nouveaux paquets par minutes, réduisant de ce fait la puissance de son attaque (si à chaque syn envoyé une nouvelle ip est forgée, cette protection ne servira à rien … et mon ban permanent aussi d’ailleurs ).

Et maintenant que la machine est « protégée » (c’est relatif hein ), il faut tester la sécurité ^^, on flood donc notre machine en envoyant des paquets SYN (avec scapy) sur le port du service que nous avons protégé.

On crée donc un fichier avec ce contenu en changeant les valeurs des ip, la valeur du loop et le port (derrière une NAT ça remplace l’ip source par votre adresse ip) :

Pour vérifier que les paquets sont drop, on fait un tcpdump sur le port en question et on compte le nombre de paquets provenant du port 1337.

(Si la règle en interdit plus de 5 et qu’on reçoit les 10 y’a un problème) ou l’on check les stats d’iptables via

Par contre, on peut s’amuser avec scapy à randomiser les ip (à faire sur des machines non natées) et tenter de flooder le service sans se faire drop un seul paquet :

Et là on se rend compte que l’on peut facilement contourner la règle iptables précédente, et qu’il devient important de mettre en place une règle globale pour toute les ip sur un service en particulier.

Donc pour mettre en place une limite globale par exemple sur le port 80 qui peut traiter au max 1000 connexions en parallèle (en imaginant qu’une requête est traitée en 1 seconde (téléchargement d’une page web en générale) ce qui n’est pas forcément vrai pour tout les services, donc on laisse au mimimum 10% du nombres des connexions pour les connexions en cours) ce qui donne :

Et si l’on rebalance un SYN flood avec le script précédent, en lançant plus de 1000 syn en parallele, seul une partie d’entre eux devrait passer.

Ce système permet surtout de protéger les services derrière le firewall en cas d’attaque permettant de passer les règles présentées jusque là.

Articles similaires :

• DDoS le retour … à 5gb/s :s
• Tentative de Hack … quand les kikoolols attaquent!!!
• Mes Applications/Scripts
• Protection DDos et ban de masse
• Syn Flooding, optimisation PHP, …

La plupart du temps lorsque l’on recherche des protections DDos on trouve des sites qui recommandent de mettre direct un limit sur un port sans tenir compte de la source … ce qui peut se révéler utile sur des petits serveurs, mais pas lorsque l’on tourne à plusieurs centaines de connexion seconde.

La sécurisation de base est très simple, il « suffit » de limiter le nombre de syn sur le port particulier du service, ici le 25565, mais dans le cas des serveurs de jeux, il peut arriver que l’on dépasse le nombre de SYN (genre lors d’une deco/timeout), donc côté firewall ça donne ce genre de règle :

Pour les explications :
Si il y a plusieurs paquets TCP SYN sur le port 25565 provenant d’une même IP on lui applique la règle « syn-flood ».
Tant qu’il y a moins de 2 syn/seconde, avec un burst à 5 syn on laisse passer, sinon, on LOG le paquet (histoire d’avoir une trace de l’ip) et on drop.

Le problème c’est que si l’on subit une attaque soutenu, le firewall va bosser en continu à checker les règles, mais comme on a log l’ip, on peut y mettre une règle avec OSSEC et mettre un ban permanent.

La règle de base à rajouter dans rules/local_rules.xml :

Qui aura pour effet de bannir pour un certain temps (par défaut 6 minutes) l’ip incriminée.

Génial, mais comme c’était du flood continu, une fois les 6 minutes passé, le flood continuait, et comme le flood se faisait avec 150 machines, le serveur était inondé en continu, malgré les règles iptables.

Donc on peut reprendre, mes règles de ban définitif et les appliquer ici.

Donc on rajoute dans local_rules.xml

Et on modifie /etc/ossec.conf en ajoutant l’id 100035 dans « l’active response » du « deny-for-life » de mon autre article (dans mon cas j’ai réécrit la règle pour utiliser le firewall) et boum … après 4 heures avec ces règles un coup de :

Retourne 150 ip bannit et plus de SYN sur le port 25565 … victoire !! Par contre :

Montre que le firewall drop toujours encore des paquets sur les ip banni … l’attaque est toujours en cours, mais semble endiguée \o/.

Articles similaires :

• DDoS le retour … à 5gb/s :s
• Protection Ddos (soft)
• Tentative de Hack … quand les kikoolols attaquent!!!
• Mes Applications/Scripts
• Syn Flooding, optimisation PHP, …

today du ban au menu, à la base j’utilise au minimum fail2ban pour me protéger des attaques par bruteforce et ossec pour une protection plus personnalisée, mais depuis peu, j’ai remarqué que bannir un host 5/10 minutes ne servait à rien contre des machines automatisées dédiée à cette tâche, et une fois la période de ban terminée recommençaient leur manège, me polluant de mails me signalant une tentative de bruteforce.

Alors j’ai imaginé des règles plus simple pour mettre en place un ban définitif des méchants cracker pour ossec :
L’idée est simple, j’ai deux utilisateurs sur ma machine (toto et root, root ne s’authentifiant que par clé et toto par mot de passe) :

• tout utilisateur tentant de se logguer en root via mot de passe est banni définitivement
• tout utilisateur tentant de se logguer via un utilisateur invalide (autre que toto) est banni définitivement

Comme ça, on évite les bruteforces à répétition, et on est tranquille pour longtemps avec ces ip là.

Côté règles sur ossec, c’est assez simple à mettre en place :
Dans le fichier rules/local_rules.xml on ajoute entre les balises (group) :

La règles 5716 (if_sid) étant celle des authentifications failed par mot de passe  et match root  pour trouver l’utilisateur root (ça veux donc dire que si on à le bon mot de passe root du premier coup, on peut quand même se logger, ce qui peut être utile dans certain cas, et assez improbable pour un cracker de se logguer).

Ensuite on ajoute dans le fichier etc/ossec.conf

La règle 100033 étant celle que l’on vient de rajouter et la règle 5710, étant l’utilisation d’un mauvais login, et on applique à ces deux règles la commande host-deny-for-life qui rajoute l’ip au fichier /etc/hosts.deny sans timeout (pour autoriser l’ip, il faudra l’enlever à la main).

Et comme ça plus de bruteforce sur des utilisateurs invalide et sur root.

Cela dit, on peut rajouter se genre de système de ban pour le serveur smtp lorsque d’autres machines tente de l’utiliser comme relay, voir faire des règles de ban automatique pour des serveurs de jeux vidéo avec des logs sur des cheaters, …

Si vous voulez en savoir plus sur ossec, un bouquin de syngress (de très bon bouquin sur l’IT en général) dédié à Ossec a été en partie publié et téléchargeable en pdf sur le site officiel (ça couvre l’installation, la configuration et la création de règle maison).

Articles similaires :

• Ossec et Iptables : ban à durée variable
• Protection DDos et ban de masse
• Crackage de MD5 … encore
• Sécuriser un blog WordPress par un IPS avec wpsyslog2 et ossec
• Notification Ossec sur Twitter en perl

Vous êtes seul responsable de vos actes sur internet, et veillez à toujours avoir les autorisations nécessaire pour pénétrer un réseau (autorisation écrite).

J’ai eu récemment à auditer les réseaux wifi d’une entreprise suite à des problèmes wifi inconnus (oui ça met en confiance ^^) … Certes, les articles de cracking wpa sont légions sur internet, mais mon approche étant un peu différente de la normal (une commande de kikoolol s’est cachée dans cet article ), j’ai pensé utile de relater mon expérience ici.

Côté soft, j’ai utilisé la suite aircrack-ng, et pyrit/cowpatty.

On démarre une interfaces virtuelle en monitor (pour les cartes atheros)  :

airmon-ng start wlan0

Puis on commence par récupérer des handshakes WPA, on peut le faire de manière naturelle, en attendant une nouvelle handshake :

airodump --channel 1,2,3 --w audit-entx mon0

L’entreprise ayant 5 réseaux wifi sur différent canaux, l’option –channel suivie de chiffres séparés par des , permet d’enregistrer dans des fichiers préfixés « audit-entx », les handshakes nécessaires au cracking des passes.

Si besoin est, on peut demander des déconnexions des clients, pour récupérer plus rapidement les handshakes :

aireplay-ng -e "essid d'un reseau" -0 5 mon0

A partir de là s’arrête l’attaque online … ça n’aura duré d’une dizaine de minutes pour récupérer une dizaine de handshakes par réseaux wifi … un seul par réseaux aurait suffit, mais on ne sait jamais …

Cela dit, comparé à une attaque wep (en ne passant pas par l’envoi de deauth), une attaque sur un réseau WPA reste très « furtive », puisqu’aucun paquets n’est forgés, les IDS déployés sur le wlan ne découvre rien concernant l’attaque.

Pour la suite, il y a plusieurs possibilités :

Utiliser l’outil airolib (prend une bonne demi journée), qui génére une matrice de mot de passe associé à l’essid du réseau, pour ce faire, il faut un dictionnaire de mot de passe (cherchez password list sur google ou utilisez celui de backtrack 4 ) et la liste des essid sur lesquels il faut lancer l’attaque.

L’entreprise étant la seule dans les environs à utiliser du TKIP/PSK, les commandes suivante créées un fichier nommé essid avec la liste des essid répondant à mes critères, importe dans la base de données sqlite « audit-entx » les essid et la liste de mot de passe (~2 millions de mot de passes entre 8 et 32 caractères).

iwlist ath0 scan|egrep -B 10 "TKIP|PSK"|grep ESSID|awk -F\" '{print $2}' > essid
airolib-ng audit-entx --import essid essid
airolib-ng audit-entx --import passwd malistedepasse

Il faudra ensuite générer les hash associant le mot de passe et l’essid, soit pour mon cas environ 8 millions de combinaisons différentes :

airolib-ng audit-entx --batch

Cette opération peut prendre beaucoup de temps (une demi journée dans mon cas … en tournant à 300PMK/s).

et on lance le crack avec (nécessite la compilation de aircrack avec sqlite)

aircrack-ng -r audit-entx monfichier.cap

Utiliser l’outil pyrit (qui prend environ 10 minutes avec une bonne carte graphique pour moi une GTX 260 et un phantom X4 en SSE2).

Pour installer pyrit et cpyrit_cuda, suivre la manip ici, installer CUDA et le CUDAToolkit (sinon il va manquer des libs lors de la compilation du soft).

Une fois installé, on ajoute les essid et la liste de pass, et on commence le batch :

pyrit -e "monessid" create_essid
pyrit -i passwd.lst import_passwords
pyrit batch

En 5 bonnes minutes, mes 5 réseaux était « batchés » :

Plus qu’à passer au cracking :

pyrit -r monfichier.cap attack_db

Manque de pot, l’outil me renvoi une erreur d’argument de la fonction unpack … a part en mettant les doigts dans la bête, je ne pouvais rien faire. Il faut donc ensuite passer par cowpatty pour terminer le crack :

pyrit -e "monessid" -o hash export_cow
cowpatty -d hash -r monfichier.cap -s "monessid"

Et en 5 secondes on a le mot de passe (si il a le malheur d’être dans la liste de mot de passe).

Donc voilà, pour ma première expérience de cracking en WPA avec pyrit … et la première fois que j’ai pu entendre les ventilo (package Zotac) de ma GTX260 faire du gros boucan (SC2 et HON ne pompent pas assez de ressources pour passer les 75°C requit pour le lancement des ventilo xD).

Articles similaires :

• Cracking de pass via GPU (Cuda) avec Durandal (MD5, SHA, …)
• Téléchargement Direct et Linux (Tucan)
• BT3 dans les bacs … les hackeurs vont se régaler

Il peut arriver que l’on s’ennuie lors de participations à des « lan party », rencontres du libre (quoique) et que l’on veuille amuser la galerie, sans trop se faire remarquer.

Le but ici est de faire un man in the middle, pour rediriger toutes les requêtes http sur notre serveur HTTP avec une page étonnamment belle.

Les outils nécessaire :

• des accès http autorisés sur le réseau (sinon, personne ne tombera dans le « piège »).
• ettercap (paquet ettercap) ou arpspoof (paquet dsniff) pour le man in the middle
• dnsspoof (paquet dsniff) pour le dns spoofing
• un serveur http en place (voir le serveur http python en 1 ligne de commande dans l’article précédent)

la Manipulation :

• On met en place le forwarding
• On créer un fichier qui renverra vers notre ip tout les domaines.
• On met en marche notre spoofing dns sur notre interface réseau
• On met en place notre serveur HTTP (cf script plus bas)
• On met en place le man in the middle

Et tout le monde sur le réseau se retrouvera sur votre serveur HTTP à afficher notre belle page html …

Pour le serveur HTTP on peut utiliser le script suivant :
C’est un serveur un peu spécial, puisque pour n’importe quelle requête http reçu (et pour n’importe quelle page), il renvoit l’index.html courant

une idée d’index.html à afficher (j’en suis trop fière quand même ^^ ) :

Et voilà … vous êtes paré pour quelques fou rires en lan …mais il ne faut pas trop en abuser ça devient vite lassant :s.

Articles similaires :

• Mes Applications/Scripts
• Envoyer des sms via google calendar et php … socket party ^^
• Les liens du week-end
• DNS Tunneling par la pratique
• BT3 dans les bacs … les hackeurs vont se régaler

ça fait déjà depuis quelques temps que la version 1.0 de prewikka (le frontend python de l’IDS prelude) est présente dans les dépôts de testing, mais comme je viens seulement de faire la mise à jour … ^^. (Au passage, prelude a aussi été mise à jour et OSSEC est passé en 2.4 le mois dernier … il était donc temps de mettre à jour l’architecture de mon système de sécurité).

Et oui les loupzeurs, la seule espèce de geek au monde à déployer un HIDS, un PKI, un IPS, un système de portknocking et un VPN pour les accès public pour sécuriser un blog visité par 110 personnes par jour !!!!!!! (lol je blague … en fait le PKI n’est pas encore en place xD).

Bref, pourquoi s’intéresser à la version 1.0.0 de prewikka ? Un truc tout bête qui existait sur pas mal d’autres outils, l’affichage de statistiques sur les attaques répertoriées par le prelude-manager (le « centralisateur » des données que peuvent lui envoyer OSSEC-agent, prelude-lml et plein d’autres (h|n)IDS/IPS ou système de logs). Et les statistiques avec plein de couleur et tout et tout, ça fait toujours classe.

Et donc voilà la tête de quelques stats pas forcément utiles (surtout dans mon cas) :

Les adresses focus pour les attaques … (genre on attaque mon NS … mon ‘dnstunnel’ n’est pas là )

Les sources d’attaques, en mettant à jour certaine règles, d’autres types d’erreurs sont désormais loggés d’où les pics d’attaques à la fin. (On remarque un petit rigolo attaquant 24h/24h mon serveur ^^).

Le plus important : les types d’attaques, on remarque un login session closed et opened qui prennent à eux seul 85% des types d’attaques … il s’agit de la config par défaut d’OSSEC qui log un peu tout et n’importe quoi … (j’ai désactivé la chose il y a quelques mois, mais mes stats sont quant même pourri par ce truc :s).

Au final, en analysant la chose, les plus grosses attaques se trouvent être des trucs super naze, en 1 an de service, ces systèmes n’auront été utiles qu’une vingtaines de fois (pour 2 SQL Injection, 1 ploucs avec acunetix 1 noob avec un script perl de type nikto et des tentatives de comments flooding par des bots russes …).

Trop de sécurité tue l’insécurité ^^. Donc voilà, profitez bien de vos mise à jour .

Articles similaires :

• Sécurité : Installation de l’IDS Prelude sur debian
• Installer la dernière version de firefox et firebug
• [UBUNTU] Mise à jour du paquet Edyuk
• Edyuk version 1.1.0 released
• Sortie de Metasploit 3.2