Logs effacés.

[piper]

Et ?
Ce paramétrage empêche quiconque de réussir à se connecter en ssh avec le compte root
Mais il n'empêche pas d'essayer.

Si tu cherches, je suis sûr que tu vas trouver des tentatives de connexion en ssh avec le user "admin" pourtant, ce user n'existe pas ! Ta log te montre les essais réalisés.

Le seul moyen d'empêcher toute tentative c'est de couper le service ssh ou de bannir l'ip de la personne qui essaie (elle essaiera quand même avant d'être bannit et ces tentatives avant bannissement seront dans tes logs)
C'est à cette fin qu'on utilise fail2ban.

[thierryR]

Par knock knock knock on pourrait démarrer SSH. Comme ça ne me sert que quand j'interviens sur la framboise, ce n'est pas souvent.
Il suffirait de faire un script.
Je vais creuser l'idée.

[Artemus24]

Salut à tous.

Etes-vous certain d'avoir été piraté ?
Comme vous, je n'arrive pas toujours à bien lire les logs de la raspberry.

Pour ce qui est de la sécurité, j'utilise sous SSH, une clef d'autorisation (authorized_keys) afin d'être le seul à pourvoir me connecter à ma raspberry.
J'ai aussi un site web, dont j'accède aussi de la même façon. Mes accès se font pas putty !

Dans votre routeur, vous pouvez bloquer tous les ports que vous n'utilisez plus. Il suffit de ne pas les déclarer dans votre NAT.
Si vous avez besoin d'un accès depuis l'extérieur, ne changez pas le port 22 car il est fait pour gérer le SSH.

J'utilise seulement iptables pour la sécurité de ma raspberry et bien entendu, j'ai tout verrouillé.
Comment j'ai fait ? J'ai pris mon temps, en testant chaque port dont j'ai besoin et chaque commande que j'utilise fréquemment.
Maintenant, j ne suis pas un expert de la sécurité, mais je n'ai rien vu d'alarmant chez moi.

Vous pouvez renommer les comptes "pi" et "root" mais surtout ne pas les supprimer.
Ne nommez pas le compte "root" du genre "admin", "supervisor" ou encore "mastercontrol". Essayez d'être un peu plus original.

Attention à la multiplicité des logiciels de sécurité qui ne feront que vous compliquer l'existence.

Cordialement.
Artemus24.
@+

[thierryR]

Fin de la partie pour moi. Mon raspi distant qui était branché derrière une box SFR et attaqué par un robot ne l'est plus. Maintenant il y a une box 4G et le problème devient différent. L'IP devient variable et est surtout privée. ( Pas d'accès au net directement) .
Quant aux logs, je reste perplexe sur son contenu. Il y a des trous, mais il serait intéressant de savoir s'il y en a chez tout le monde. Auquel cas, je pourrais mettre un doute sur une éventuelle intrusion.

[dyox]

AU fait, quelle est la commande pour lire les logs ?

Pour lire les journaux ssh depuis le reboot : journalctl -u ssh
Et non je n'ai pas de trous et le restart du service y est notifié.

$ last (pour voir les derniers users connectés sur la Pi)

Je n'ai pas relu les 4 pages, les commandes ont p-ê déjà été données

[thierryR]

J'utilise aussi journalctl pour lire les logs. Comme il y a des trous je suppose que mon robot a réussi a entrer et a effacer ces traces. Comme dit plus haut j'avais oublié de retirer un fichier donnant le sudo à pi, malgré le fait d'avoir supprimé cet utilisateur.

[piper]

Attention : si pendant un certains moment tu avais désactivé l'enregistrement en dur des logs (comme moi). Alors elles sont perdus au reboot mais les précédentes restent.
Ca peut generer un trou si plus tard tu reactives leur ecriture en dur.


Envoyé de mon SM-J710F en utilisant Tapatalk

[thierryR]

C'est ce que j'ai fait aussi, c'est pour ça que le doute subsiste.

[Artemus24]

Salut à tous.

Dans tous les cas ce sont des usines à gaz.

Cela s'adresse à des gens qui maitrisent le sujet et non à des débutants.

Cordialement.
Artemus24.
@+

[piper]

Pour protéger ssh avec fail2ban, tu n'as même pas besoin de comprendre comment fonctionne le pare-feu.
Il suffit de dire à fail2ban qui tu utilises firewalld ou iptables et que tu active la règles de protection de ssh
Tu obtiendras une protection minimale mais suffisante dans bien des cas (bannissement pendant 10 minutes après 3 tentatives d'authentification ssh infructeuses)

Un pare-feu est nécessairement une usine à gaz s'il c'est un vrai pare-feu (je veux dire par là que les cas à traiter sont nombreux)

Et si, effectivement, j'ai longtemps préféré firewalld (lors de sa sortie, à cause de sa syntaxe plus claire) à iptables , j'en suis revenu pour des raisons de performances :

En effet, lorsque fail2ban travaille, et particulièrement si vous activez la règle de bannissement pour tentatives de récidives, le nombre d'ip bloquées peux monter à des centaines , voir un millier ou plus pour un serveur en prod, hébergeant des sites que vous avez référencé correctement sur les moteurs de recherche
A ce niveau là, firewalld devient d'une lenteur absolue (lorsque vous ajoutez ou supprimez une règle manuellement), alors que iptables continue de réagir au car de tour.

Ceci est démonstratif, si vous avez mis des bannissements permanents : avec fail2ban sur firewalld, le reboot d'un serveur bien équipé peut prendre 6 minutes (donc 5 minutes pour que les services fail2ban/firewalld s'arrêtent)

Du coup, je n'utilise plus fail2ban (sauf pour les tentatives d''attaques via un formulaire sur site web)
Pour ssh et d'autres services d'administration, je mets en place des règles de pare-feu qui n'autorisent que certaines ip à se connecter (celles que moi ou mon équipe on est susceptible d'utiliser)
Et cela, en plus des clés d'authentifications.