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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [email protected] http://lists.alphanet.ch/mailman/listinfo/gull _______________________________________________ gull mailing list [email protected] http://lists.alphanet.ch/mailman/listinfo/gull
