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

[Cyrus G. <koorosh@xxxxxxx>]

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 G. 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