Même si j'avais parlé d'authentification SSH via les fameux fichiers id_rsa et id_rsa.pub. Penses-tu que leur usage fragilise un système ? Après tout, si on s'en fait piquer un, on compromets directement le système ( et du coup effectivement interdire l'accès root est très pertinent )?
Oui en effet la sécurisation des fichiers de clé eux même sont un peu la faiblesse de ce système : il faut être bien sûr quelles sont stockés de manière à ce que personne d'autre ne puisse potentiellement y avoir accès et ce n'est malheureusement pas toujours évident.
L'autre problématique importante quand on généralise leur utilisation est le risque de se faire pourrir les machines à la chaîne : la machine A est vulnérable à une quelconque faille, l'attaquant obtient l'accès à un un compte utilisateur avec les clés pour se connecter sur B et C même si ces machines ne sont pas vulnérables.
Après il faut en tenir compte et je ne dis pas que c'est forcément une mauvaise façon de faire, les clés ont aussi leurs avantages.
Le nom de l'utilisateur root n'est effectivement jamais changé et les tentatives de brute force se font régulièrement sur cet utilisateur car après tout c'est de loin le plus intéressant pour l'attaquant. Donc pour moi la règle est simple : PermitRootLogin est à no sur toutes les machines que j'administre pour un peu plus de tranquillité.
Sinon, utiliser un honeypot et un fail2ban sur le 22, ça me semble "dangereux" si quelqu'un zappe le numéro de port? Enfin, c'est sûr que ça ajoute en sécurité...
Oui et ça m'est naturellement déjà arrivé ^_^. J'ai une solution tout bête : les adresses IP de plusieurs machines auxquelles je peux avoir accès par internet sont en liste blanche sur les honeypots. Comme ça même si je me plante alors que suis dans un cyber café à l'étranger je peux toujours me loguer sur une autre machine pour me dé-bannir (sans oublier de préciser le port cette fois là).
Sinon en adaptant un peu le script python que j'utilise pour les honeypots il serait assez facile de mettre en place une séquence de port knocking pour se faire dé-bannir et là plus besoin de liste blanche.
[^] # Re: Premières investigations
Posté par Chris K. . En réponse au message Piratage de ma machine ???. Évalué à 2.
Oui en effet la sécurisation des fichiers de clé eux même sont un peu la faiblesse de ce système : il faut être bien sûr quelles sont stockés de manière à ce que personne d'autre ne puisse potentiellement y avoir accès et ce n'est malheureusement pas toujours évident.
L'autre problématique importante quand on généralise leur utilisation est le risque de se faire pourrir les machines à la chaîne : la machine A est vulnérable à une quelconque faille, l'attaquant obtient l'accès à un un compte utilisateur avec les clés pour se connecter sur B et C même si ces machines ne sont pas vulnérables.
Après il faut en tenir compte et je ne dis pas que c'est forcément une mauvaise façon de faire, les clés ont aussi leurs avantages.
Le nom de l'utilisateur root n'est effectivement jamais changé et les tentatives de brute force se font régulièrement sur cet utilisateur car après tout c'est de loin le plus intéressant pour l'attaquant. Donc pour moi la règle est simple : PermitRootLogin est à no sur toutes les machines que j'administre pour un peu plus de tranquillité.
Oui et ça m'est naturellement déjà arrivé ^_^. J'ai une solution tout bête : les adresses IP de plusieurs machines auxquelles je peux avoir accès par internet sont en liste blanche sur les honeypots. Comme ça même si je me plante alors que suis dans un cyber café à l'étranger je peux toujours me loguer sur une autre machine pour me dé-bannir (sans oublier de préciser le port cette fois là).
Sinon en adaptant un peu le script python que j'utilise pour les honeypots il serait assez facile de mettre en place une séquence de port knocking pour se faire dé-bannir et là plus besoin de liste blanche.