[gull] Attaque SSH

Christian ALT calt at tla.ch
Wed Dec 13 14:55:19 CET 2006


Ce que Daniel dit est tout à fait correct.

Il existe différentes mesures que l'on peut prendre. Chacune des mesures est
ce que nous appelons un "contrôle". Pour chaque risque on peut avoir
différents contrôles. On le voit dans ce cas de sécurisation de l'accès ssh.

L'utilisation de denyhost est une mesure réactive. Le changement de port,
l'introduction d'une authentification préalables sur un firewall, les
réjections des utilisateurs sont des mesures proactives.

Si l'utilisation de SSH depuis l'extérieur, c'est pour l'administrateur
système ou pour les tâches de maintenance, on peut demander une première
authentification à la périphérie sur le firewall. Un exemple une société
recourt à des développeurs externes. Pour cela ils ont besoin d'échanger
fréquemment des versions de code par CVS. On va placer  le serveur
partageant le code dans une DMZ. L'accès au serveur depuis l'extérieur se
fait par ssh. Pour réduire les tentatives d'accès ssh depuis Internet, on
introduit une authentification sur le firewall. Une fois le développeur
authentifié il est autorisé à faire son accès ssh. Cela permet également une
tracabilité des accès.

Lors des conférences Infosec 2006, j'ai eu l'occasion de manger avec un des
collaborateurs de MELANI. Nous leur avons parlé de d'un cas similaire et sa
réponse a été d'écrire un courrier au provider. En résumé même la police
fédérale n'a pas beaucoup plus de possibilités.

Christian 

-----Original Message-----
From: gull-bounces at lists.alphanet.ch [mailto:gull-bounces at lists.alphanet.ch]
On Behalf Of Daniel Cordey
Sent: mercredi, 13. décembre 2006 12:00
To: Groupe romand des Utilisateurs de Linux et Logiciels Libres (Liste
technique)
Subject: Re: [gull] Attaque SSH

On Wednesday 13 December 2006 11:35, Christian ALT wrote:

> Toute mesure prise qui réduit les risques est une "méthode de protection".
> Le port 22222 c'est très bien, pas cher, efficace contre certains robots.

Je ne serais pas supris de decouvir, a l'avenir, que les tentatives 
d'intrusion sur ssh se mettent a utiliser les ports 222, 2222, 22222; voir a

faire un nmap prealable. La plupart de ces tentatives essaient d'ailleurs de

se connecter en 'root'., 'test', 'admin', etc. Il est deja facile de rejeter

systemetiquement les tentatives de login ssh pour ces utilisateurs dans la 
config de sshd. Ensuite, pas de 'sudo' automatique; CAD sans devoir entre le

mot de passe ! C'est deja une bonne barriere.

L'utilisation de denyhost permet de mettre en quarantaine les systemes
fautif, 
ceci pendant une periode que l'on peut definir (jours, semaines, etc.).
C'est 
assez utile car les tentatives sont repetitives.

> La modification des règles sur le firewall c'est très bien.
> Une bonne méthode de protection est d'ajouter de l'authentification en
> entrée sur le firewall. Cela veut dire gérer des utilisateurs sur le
> firewall qui peuvent faire du SSH.

Tu veux dire : n'autoriser que les connexions ssh depuis des adresses 
reconnues ? 

Dans ce cas, c'est un peu restrictif si tu as besoin d'etre itinerant. Une 
solution peut-etre alors d'utiliser la technologie de 'port-knocking'. C'est

conteste par certains, mais offre, a mon avis, un degre de diificulte 
suplementaire aux crackers. Pas trop complique a mettre en place...

> En ce qui concerne les contacts avec les ISPs pourquoi pas si ils sont en
> Suisse. Ailleurs cela devient plus problématique. Il faut déterminer si
> l'attaque est ciblée ou si elle fait partie du bruit de fond. Dans le
> second cas cela ne vaut pas la peine.

Il y a longtemps, j'avais remonte al trace de certains 'crackers' et elles 
menaient toutes en Asie... on oublie :-) Sans compter que certaines 
tentatives sont effectuees a partir de PC 'cracques' a l'insu de leurs 
proprietaires.

dc
_______________________________________________
gull mailing list
gull at lists.alphanet.ch
http://lists.alphanet.ch/mailman/listinfo/gull




More information about the gull mailing list