RE: Re : Re: [LA-discussions] Test d'intrution openssh

je me permets d'expliquer en détail vue que maintenant je suis disponible:

Avant tout, je n'ai pas été précis dont je m'en excuse . Alors, l’année prochaine je prépare un examen qui dure 35 min top chrono dont je dois parler sur la sécurisation des échanges avec le protocol SSH.

Vous avez sans doute compris que pendant les 35 min , je dois prouver aux inspecteurs mes compétences informatique et non pas de délinquance ^^.

Même si je suis conscient que ce genre de situation peut arriver, mais ce n'est pas ce qu'attend les inspecteurs. Idem pour les Malware ou autre car la on va entrer dans un domaine de forensics dont cela devient hors sujet avec mon thème.

j'ai que 35 min pour attirer l'intention et c'est pour cela qu'il faut employer une sécurité paranoïac pour rendre l'objectif difficile.

Je sais que la sécurité informatique peut être aussi large que l'univers mais je ne dois pas sortir de mon contexte dont le voici:

Vous êtes un pentesteur,le client vous a contacté afin d'effectuer des tests d'intrusions sur le serveur SSH .

démontrer que le serveur puisse résister à divers attaque informatique.

C'est comme un challenge informatique, marquer le plus de points possible donc effectuer le maxime de test d'instrusion sur les failles du protocol SSH.

J'ai identifié des failles toute bête mais d'autre dont j'ai du mal à imaginer une attaque.

les éléments que je dispose:

le port par default (22) a été modifié par 7856

les scans sont neutralisés par le firewall Iptable/sharewall

les clients disposent d'un outils qui permet de stocker les mots de passes dont eux-même sont crypter en AES-256

fail2ban est installé pour évité les attaques de bruteforce dont l'ip de l'attaquant sera stocker en blacklist

un groupe a été crée "SSH" dont seulement les user dans ce groupe pourront se connecter au serveur SSH.

les connexions par mot de passe sont désactivées

les connexions SSH sont établie par un système de clé RSA dont la clé privé est dans un TOKEN.

le root est réservé par les utilisateurs qui ont besoins de tous les droit en fonction de leur secteur métier

Voila le défis, trouvé une faille et l'exploité, j'ai réussi à faire du spoofing mais j'ai galéré.

j'ai beau regarder dans la BDD de exploitDB mais rien qui me permets de tenter quelque chose.

Cdlt,

nicolas cyrus

> Date: Sat, 19 Oct 2013 17:07:08 +0200
> Subject: Re : Re: [LA-discussions] Test d'intrution openssh
> From: koorosh@xxxxxxx
> To: discussions@xxxxxxxxxxxxxxxx
>
> Ps: je suis au labo et desoler pour l'orthographe car je suis sur le phone et la batterie est faible.
>
> Enfaite je l'ai pas précisé mais on exclu le vol car le but justement de ce projet c' est prouver techniquement que le serveur est robuste aux attaques majeurs du protocol SSH.
>
> Si j'ai fais un ban au bout d'1 erreur c'est parceque le collaborateur doit juste entrer la passphrase et il y a generalement 10% de chance que l'user se trompe. Apres il y a des consignes à savoir mais la ca reste un cercle vissieux.
>
> Ce qui m'interresse cest par exemple:
>
> Attaque bruteforce : bloqué parceque justement j'ai mis en place fail2ban.
>
> Etc ....
>
> Por mon exam j'aurai que 35 min ce qui est court dont j'ai pas beaucoup de temps pour montrer au jurie mes competences techniques.
>
> En fonction des elements si-dessus, quelle type d'attaque serait il possible ? En excluant le vol de cle usb ou pc .
>
> --- Message initial ---
>
> De : "hamster" <hamster@xxxxxxxxxxx>
> Envoyé : 19 octobre 2013 16:52
> A : discussions@xxxxxxxxxxxxxxxx
> Objet : Re: [LA-discussions] Test d'intrution openssh
>
> Le 19/10/2013 16:05, Cyrus GOHARPOUR a écrit :
> > Bonjour mr et mesdames,
> >
> > Je me permets de poster ce message pour demander votre expériance .
> > En 2014, je vais passer mon diplome en informatique et mon projet se sera la mise en place d'une politique de securite sur les connexion securisees SSH.
> >
> > Voici la config:
> >
> > Port ssh modifie par 7856
> > Installation de fail2ban (ban au bout d'1 erreur)
> > Authentification par clé public/privé (la clé privé du collaborateur est uniquement dans une clé usb )
> > Seulement les connexions par echange de clé rsa sont authorisées et toutes les autre connexions sont refusées.
> > Seulement les users dans le groupe SSH sont authoriser a utiliser les connexions SSh.
> >
> > voila, est ce que certain d'entre vous connait une faille de securite dans mon installation ! ? :)) OU un moyen de contourner ma securite ?
>
> Oh oui, c'est tres simple : tu pique la clef d'un utilisateur (vol
> d'ordi par exemple). Si elle est protegee par une phrase de passe tu
> pique aussi la phrase de passe (piratage de son ordi et installation
> d'un keylogger ou meme en lui tapant dessus jusqu'a ce qu'il te la
> donne). Ensuite t'a toutes facilites pour te connecter en ssh avec sa clef.
>
> Comme toujours le maillon faible de la securite c'est l'interface entre
> la chaise et le clavier. Les mesures techniques sonta politique de
> securite c'est pas uniquement des mesures techniques, elles sont
> necessaires mais pas suffisantes. Il faut aussi mettre en place des
> regles de comportement pour les utilisateurs (en preventif mais aussi en
> curatif : comment reagir si on se fait pirater) et de la formation.
>
> De plus ca me fait tres bizarre que tu fasse une politique securite sans
> parler de l'utilisation qui sera faite de cette connexion. C'est un peu
> comme choisir un vehicule sans savoir ce qu'il devra transporter ni sur
> quelles routes il devra rouler.
> - Quel est le besoin de securite ? Si c'est pour le serveur d'un hopital
> la politique n'est pas la meme que si c'est pour le serveur qui heberge
> le site web de ton club de boules...
> - A quoi servent ces connexions ? Si c'est pour qu'un serveur de backup
> puisse se connecter toutes les nuits et faire la backup c'est pas pareil
> que si c'est sur un serveur d'hebergement et que des dizaines de gens
> s'en servent pour mettre a jour leur site web.
> - Les gens qui se connectent sont ils root ou simples utilisateurs ?
> - Les gens qui se connectent sont ils informaticiens ou novices ?
> - Si c'est sur une machine qui est exposee a tout ce qui circule sur
> internet c'est pas pareil que si c'est une machine isolee sur un reseau
> local.
> - Etc.
>
> Certaines de tes mesures me semblent parano sans apporter beaucoup a la
> securite :
> - fail2ban au bout d'une seule erreur, donc les utilisateurs n'ont pas
> droit d'etres distraits. Si tu mettais 2 ou 3 erreurs ca serait pas
> dramatique en terme de securite. Se faire bannir a la premiere erreur ca
> va faire chier l'utilisateur discret mais pour le pirate ca va juste
> l'obliger a re-essayer depuis une autre IP a chaque fois au lieu d'avoir
> a changer d'IP tous les 2 ou 3 essais.
> - Port 7856, hum, ca t'evite les innombrables tentatives de connexion
> sur le port 22 mais ces connexions la auraient de toutes facons echoue a
> cause de la connexion par clef uniquement. Si quelqu'un veut vraiment
> pirater cet ordi il peut tres bien tester tous les ports et quand il en
> trouve un ou un serveur ssh repond "connexion refusee" il s'acharne sur
> ce port la. Inversement un port exotique comme le 7856 ca fait chier les
> utilisateurs qui sont obliges de s'en rappeller, d'aller le mettre dans
> la configuration de leur pare feu, se retrouver bloques quand ils sont
> pas chez eux (quand t'es chez un copain si tu dois aller modifier la
> conf de son pare feu pour te connecter c'est pas top) etc.
> - Seules les clef RSA sont autorisees. Et pourquoi pas aussi les clef DSA ?
>
> Peut etre tu peux aussi configurer le serveur SSH pour qu'il refuse les
> connexions en root. Comme ca les utilisateurs doivent se connecter en
> simples utilisateurs et faire sudo ensuite. Mais y'a des cas ou une
> telle regle n'est pas possible, par exemple si t'a un serveur de
> sauvegarde qui se connecte automatiquement a ton truc : il a besoin de
> se connecter en root pour faire la sauvegarde.
>
> Apres, je suis pas non plus un expert en securite. T'a lu le manuel
> securite de debian ?
>
> PS : une formation en orthographe te ferait pas de mal, mettre "er" a la
> fin de chaque mot qui finit en é c'est pas top.
>
> --
> Liste de discussions de LinuxArverne
> http://wiki.linuxarverne.org/listes_de_diffusion
>
>
> --
> Liste de discussions de LinuxArverne
> http://wiki.linuxarverne.org/listes_de_diffusion
>