Même problème sur un RPI 4 que j’administre à distance. Je pense qu’il s’agit d’une attaque SSH pour ceux qui ont ouvert le port 22 sur le routeur évidemment car j’ai ça dans /var/log/auth.log :
Je ne sais pas comment le gars a pu faire ça car mon SSH a besoin d’une clé mais il a réussi à faire tomber Apache, SSH et Telnet … Et suite à ça l’heure des logs est revenue en arrière de 09:39:12 à 09:17:15? Exploitation d’une faille? Seule solution était un Hard Reset.
Je ferme le port depuis l’extérieur et on va donc voir si c’était ça le problème.
pour limiter les attaques une des solutions est d’avoir le ssh ouvert sur un port autre que 22, genre 43213 … et de faire une redirection dans ton routeur.
Merci pour vos conseils mais j’ai un vpn sur ce site, j’avais ouvert le ssh car un autre soucis (bref) mais avec clé publique/clé privée pour limiter les attaques.
Et je vous confirme que ce problème n’est pas une attaques ssh car j’ai fermé le port et ça a recommencé ! Voici les logs de /var/log/auth.log :
La suite de « @^@^@ » correspond au caractère « NULL » (équivalent \x00 en hexa).
Ca peut être un bot simple qui balance de la donnée direct à travers le port ssh sans que la donnée utilise le bon format du procotole ssh. Ou alors ça peut aussi être l’exploit d’un bug sur de vieux serveurs ssh où on pouvait faire planter le serveur avec ce type de payload (version openssh jusqu’à v5). Mais si ton serveur est à jour (openssh v8 ou 9 ?), pas de risque de ce côté là.
En tout cas, vu qu’ils ont l’air d’avoir ton ip en mémoire, t’as intérêt à bien sécuriser tes prochaines config si tu veux pas voir ton serveur se transformer en botnet, minage de bitcoin ou autre.
Il reboot chaque jour à 09:17:xx ?
L’heure avant reboot est donc fausse et il se remet à l’heure automatiquement lors du reboot ?
Le ping est une bonne piste, même en ayant désactivé ssh il continue de réponde au ping. Mais cela aussi peut se désactiver.
Il faudrait déterminer à quel moment l’heure se dérègle, s’il y a un moment précis… Ou si c’est un glissement régulier au cours de la journée?
Les heures du plantage sont à chaque fois différentes. Il faut que je précise que sur le RPI il y a un serveur openvpn qui lui répond quand ça plante : juste ssh, telnet et apache (le fameux message forbidden) ne répondent plus. L’heure qui revient en arrière je suppose que c’est du au reboot et le fait que le RPI 4 n’a pas de pile pour retenir l’heure (à confirmer).
Je relance sur ce point … ton pb peut venir d’une commande en cron par exemple, qui renvoie des données binaires sur la sortie standard (les @@@@@@), mais sans tty associé
Et je confirme qu’un RPI n’a pas de pile, donc il ne faut pas tenir compte des heures de démarrage. L’horloge est automatiquement mise à jour via le DHCP ou via NTP si le DHCP ne diffuse par l’heure
Hello,
j’ai un script en crontab pour stocker toutes les minutes l’heure du RPI dans le fichier de reference du pi qu’il utilise au redemarrage
par défaut le RPI ne fait cela qu’1 fois par heure de mémoire. en cas de reboot, retour dans le passé pour le pi. * * * * * /sbin/fake-hwclock save
cf. fake-hwclock(8) — fake-hwclock — Debian jessie — Debian Manpages
Très utile pour connaitre l’heure du plantage (c’est l’heure du reboot) avant qu’il se resynchronise avec ntp
