Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

tentative de bruteforce ssh

smokeh

bonsoir
j'ai en ce moment des tentatives de bruteforce ssh venant de plusieurs ip différentes ( ukraine chine allemagne etc etc...)
j'ai seulement ssh installé sur mon petit pi ( il me sert à faire la sauvegarde en sftp d'un ordinateur distant)
Les données sont pas hyper méga importante mais bon c'est histoire d'avoir un backup....
j'ai souscris à un dyndns chez dynu.com au cas ou les livebox change d'ip . (tout fonctionne correctement) > je me demande si les attaques peuvent provenir de là!?!?
j'ai donc décider d'installer fail2ban avec 3 tentatives accepté et un ban de L'ip pendant 1 an sinon. ( j'ai aussi l'impression que c'est des machines bot qui bruteforce )
j'ai tout de suite changé mon mot de passe par un autre ( par précaution ) et lancer un rkhunter sur le pi pour vérifier s'il y avait pas d'infection (tout à l'air ok pour le moment).

Avez vous d'autre conseils à me donner??? ( des choses à vérifier )
- Existe t'il une possibilité avec iptable d’autoriser 1 IP fixe (la mienne à mon domicile) et une IP dynamique (celle de la machine qu'il faut sauvegarder = du coup avec un nom en toto.dynu.com correspondant à l'ip dynamique)

- Je ne sais pas si on peut passer par des clé rsa pour faire des transfert sftp avec WinSCP ? Si oui comment faut t'il procéder?

Je vous donnerai le maximum d'info possible pour faire ça le mieux possible.
Pour le moment j'ai l'impression d'avoir était précis.

Merci d'avance de tous vos conseils linuxiens 🙂

Laurent85

Bonjour, l'authentification par clé publique rend ce type d'attaque sans danger. Mais tu peux aussi laisser tourner en plus un fai2ban pour bannir ces ip, les robots ne pourront pas initier de connexion.

smokeh

oui par clé c'est mieux ... mais je voulais savoir si ça marche avec un client winscp sur le poste informatique ou je veux faire la récupération de sauvegarde. et si oui comment faire ça proprement.
SInon oui le ban fonctionne . Mais quand il y à brute force il peuvent continuer leurs passlist en utilisant d'autres IP non?

Visiblement ici j'ai un check reverse (donc sur l'adresse dns si j'ai bien compris):
Certaine ip font partie de la base de donnée du site abuseipdb:

Jan 25 23:40:19 raspberrypi sshd[2374]: reverse mapping checking getaddrinfo for vps2411.inrr.ru [192.162.101.217] failed - POSSIBLE BREAK-IN ATTEMPT!

Sont vilain ces pirates ... et c'est pas beau le bruteforce...

Merci de ton retour ! Si il y en à d'autre je suis preneur aussi!

bruno

Bonjour,

Dés qu'un serveur SSH est actif sur le port standard (22) il subit ce type d'attaque. Comme tu l'as deviné il s'agit de tentatives d'accès par force brute utilisant généralement des botnets, donc des IP qui changent très souvent.

Il ne faut pas trop s'en inquiéter si on a un mot de passe solide et pas du tout si la connexion se fait exclusivement par clé (je te laisse regarder la doc de WinSCP pour voir si c'est possible).

Il est souvent conseillé de changer le port standard 22 par un autre. Cela n'augmente pas la sécurité, mais évite de voir les logs se remplir avec ces attaques et diminue le trafic réseau.

fail2ban est intéressant mais, à mon avis, peu utile dans ce cas. Il consomme pas mal de mémoire, n'est pas efficace face à des botnets (IP qui changent sans arrêt) et il agit a posteriori en analysant les logs.

Donc pour résumer :
- éventuellement changer le port par défaut (pas + de sécurité);
- si connexion par mot de passe : pas de connexion avec root , nom d'utilisateur non trivial (éviter admin, ftp, pi, etc.) et mot de passe bien solide (long avec minuscules, majuscules, chiffres et autres caractères, du genre : Fc14;@éça54b?+{rs7 ) ;
- si connexion par clé exclusivement on peut autoriser l'accès root directement. Il faut une clé sûre : au minimum rsa 4086 bits ou ed2519.

mazarini

Bonjour,

L'utilisation d'un nom dont l'ip change ne marche pas avec iptable. Le nom est résolu lors du chargement des tables et ensuite les changements ne sont pas pris en compte.

A défaut de bloquer toutes les ip et autoriser 2 ip, tu peux autoriser une IP et un réseau comme XXX.0.0.0/16 (correspondant à celui utilisé par ton fai). C'est large, mais ca devrai limiter les tentatives.

Autrement, bloquer 1 ans me semble très long et gourmand en ressource.

smokeh

bon je suis passé en clé rsa pour l'authentification ssh. par contre j'ai trouvé des clé rsa qui était accepté dans ~/.ssh/authorized keys. je les ai suprimé pour rajouter les miennes (public bien sur ).
comment fait t'on pour être sur que ssh n'accepte pas d'autre clé rsa ?
J'ai peur que le bot soit bien rentré sur mon serveur en ssh et il à rajouté une entrée dans le fichiers authorised keys.
comment faire pour vérifier?
Merci

mazarini

smokeh a écritbon je suis passé en clé rsa pour l'authentification ssh. par contre j'ai trouvé des clé rsa qui était accepté dans ~/.ssh/authorized keys. je les ai suprimé pour rajouter les miennes (public bien sur ).
comment fait t'on pour être sur que ssh n'accepte pas d'autre clé rsa ?
J'ai peur que le bot soit bien rentré sur mon serveur en ssh et il à rajouté une entrée dans le fichiers authorised keys.
comment faire pour vérifier?
Merci

Ca me semble louche les clés déjà présentes dans ~/.ssh/authorized. Le plus simple serai de refaire l'installation.

Peut être que ca vient d'une image mal nettoyée (volontairement ou pas). Sur le pi on copie une image toute faite sur sur une carte SD si je me souvient bien.
A vérifier tout de suite après la réinstallation.

Dans mes souvenir, chez OVH, il y a (avait ?) une clé d'OVH dans les clés de root pour faciliter les tests des admins en cas de problème. Clé que l'on peut laisser ou pas et dont la présence est plus ou moins bien signalée.

smokeh

hum cela viens d'une raspbian officiel. et les clef dans authorised keys etait signée a la fin par un nom bot ce qui m'a semblé suspicieux alors j'ai tout de suite viré

mazarini

Je te conseille de faire la réinstallation. Si quelqu'un a ajouté des clés, difficile de savoir ce qu'il a fait d'autre.

robindesbois

Ben je dirais que pour voir si tu as (dans le futur proche ou un peu éloigné (une dizaine de jours), des clefs ssh(rsa) différentes des tiennes qui sont installées, comme tu sais maintenant où ça se trouve sur le disque dur, tu n'as qu'à jeter un œil de temps en temps (ces jours-ci faudra le faire tous les jours). Maintenant, le mec est sûrement rentré par ce truc ssh, et il est possible qu'il n'ait pris le temps que de mettre les siennes (une fois qu'il était passé par ton port ssh), mais comme maintenant tu t'authentifies par une clé rsa publique, c'est possible qu'il soit bloqué... Et définitivement.

Enfin, ça c'est basé sur le scénario que le gars n'est pris le temps de ne faire que cela par peur de se faire choppé s'il restait trop longtemps ? Ou, si le livreur de pizza venait de sonner à la porte et qu'il a été bouffer... Bon, ce n'est que mon idée, elle vaut ce qu'elle vaut pffff ! Mais ça pourrait peut-être t'aider ces simples vérifications futures de présences de clefs rsa non autorisées, ce serait même peut-être suffisant donc. @ plus.....

[supprimé]

Salut,

Puisque tu as un usage précis de ton PI, pourquoi ne pas utiliser les fichiers /etc/hosts.deny et /etc/hosts.allow.
Par defaut, tu refuses tout en connexion et tu autorises seulement l'ordinateur distant pour son backup dans hosts.allow ainsi que ton réseau privé si besoin.

Fail2ban est un excellent outil mais comme ton usage est somme tout modeste, autant utiliser la simplicité ! Par ailleurs, je rejoins mazarini, utiliser une image PI officielle n'est sans doute pas top pour la sécurité. Autant installer une Debian toute fraîche avec le strict minimum tournant dessus ! Si tu as besoin d'un serveur X, LXDE est normalement supporté par ton modeste PI.

smokeh

libc6 a écritSalut,

Puisque tu as un usage précis de ton PI, pourquoi ne pas utiliser les fichiers /etc/hosts.deny et /etc/hosts.allow.
Par defaut, tu refuses tout en connexion et tu autorises seulement l'ordinateur distant pour son backup dans hosts.allow ainsi que ton réseau privé si besoin.

Fail2ban est un excellent outil mais comme ton usage est somme tout modeste, autant utiliser la simplicité ! Par ailleurs, je rejoins mazarini, utiliser une image PI officielle n'est sans doute pas top pour la sécurité. Autant installer une Debian toute fraîche avec le strict minimum tournant dessus ! Si tu as besoin d'un serveur X, LXDE est normalement supporté par ton modeste PI.

merci je n'ai pas besoin d'un serveur x . et je suis parti d'une raspbian lite.(en gros une distribution basé sur débian et spécialement faite pour le pi)
j'ai déjà vu pour le host.allow et host.deny. Mais merci quand même!

robindesbois

libc6 a écrit Par ailleurs, je rejoins mazarini, utiliser une image PI officielle n'est sans doute pas top pour la sécurité. Autant installer une Debian toute fraîche avec le strict minimum tournant dessus ! Si tu as besoin d'un serveur X, LXDE est normalement supporté par ton modeste PI.

Salut, de part mon expérience, je confirme aussi ceci, une installe de Debian toute fraîche avec le strict minimum avait réglé tous mes problèmes.

Bonne continuation smokeh...