Serveur compromis?

Mon serveur YunoHost

Matériel: Raspberry Pi à la maison
Version de YunoHost: 3.7
J’ai accès à mon serveur : En SSH | Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modifications particulières sur votre instance ? : oui
Webadmin accessible qu’en local en modifiant config Nginx. SSH accessible par clefs uniquement en local, port non ouvert sur la box. Ajout de portsentry + quelques filtres fail2ban supplémentaires.

Description du problème

J’utilise logwatch pour avoir un rapport d’activité journalier des logs du serveur ainsi que pflogsumm pour avoir un rapport des mails reçus/expédiés.
Je ne me suis jamais inquiété jusqu’à ce jour, après avoir modifié la configuration de logwatch de cette façon:
Copie de /usr/share/logwatch/default.conf/services/http.conf dans /etc/logwatch/conf/services et modification de la variable $HTTP_USER_DISPLAY à la valeur 1 au lieu de 0.
Comme c’est indiqué: “The variable $HTTP_USER_DISPLAY defines which user accesses are displayed.

Maintenant j’ai un nouveau menu “Users logged successfully” dans les rapports.
Cependant je vois des utilisateurs non Yunohost avec des Ip venant de l’étranger qui apparaissent dans cette partie. Par exemple j’ai ceci:

     admin
     183.0.97.234: 1 Time(s)

Il s’agit d’une Ip chinoise. Pourtant la seule trace que je trouve dans les logs est dans le fichier /var/log/nginx/access.log avec ceci:

183.0.97.234 - admin [01/Apr/2020:13:09:35 +0200] "GET /web/cgi-bin/hi3510/param.cgi?cmd=getp2pattr&cmd=getuserattr HTTP/1.1" 444 0 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)"
183.0.97.234 - - [01/Apr/2020:15:37:24 +0200] "GET / HTTP/1.1" 444 0 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"

ou bien:

  PlcmSpIp
     45.143.220.101: 1 Time(s) 

avec dans le log access.log:

45.143.220.101 - PlcmSpIp [30/Mar/2020:16:36:10 +0200] "GET /aastra.cfg HTTP/1.1" 444 0 "-" "python-requests/2.23.0"

Dois-je m’en inquiéter ou dois-je ignorer ces “users logged successfully” et désactiver cette option qui n’est pas activée par défaut?

Étrange.
Change les mots de passe + clefs et vois ce que ça donne ?

Est-il possible que mettre la variable HTTP_USER_DISPLAY à 1 fait apparaître toutes les tentatives de connexion, et pas seulement celles qui réussissent ? Je n’arrive pas à trouver une documentation claire sur ça.

J’ai l’impression que logwatch et fail2ban regardent les logs de la même manière, peut-être peux-tu voir ce qu’en dit f2b pour la même alerte ?

F2b donne ceci:

2020-03-30 16:36:10,187 fail2ban.filter         [22433]: INFO    [nginx-404] Found 45.143.220.101
2020-04-01 13:09:35,946 fail2ban.filter         [24813]: INFO    [nginx-404] Found 183.0.97.234
2020-04-01 15:37:24,366 fail2ban.filter         [24813]: INFO    [nginx-404] Found 183.0.97.234

F2b détecte bien conformément au filtre nginx-404 que j’ai ajouté il y a quelques mois suite à une tentative de connexion un peu trop tenace.
Vu la réponse en 444 et aucune autre trace dans les logs, finalement je ne pense pas qu’il y ait lieu de s’inquiéter, mais j’aimerais bien comprendre.
Le point commun, tous les logs commencent par Ip - - [date] or ceux qui apparaissent dans “Users logged successfully” qui ne sont pas des utilisateurs yunohost sont dans les logs sous la forme: Ip - USER [date].
Voici ce que j’ai trouvé concernant les formats des Logs:

LogFormat "%h %l %u %t \"%r\" %>s %b"
Avec %u: The userid of the client if the request was authenticated.

Si ça parle à quelqu’un, difficile de trouve de la documentation sur le sujet.

À mon avis, c’est juste que l’attaquant a fourni le header HTTP qui va bien avec le nom de l’utilisateur, pour faire “semblant” qu’il est authentifié (sans l’être vraiment, mais peut-être en se disant que si le serveur est configuré n’importe comment, sur un malentendu ça peut passer)

À confirmer…

2 Likes

Au cas où je demande : tu n’utilises pas Tor Browser ?
Ça pourrait aussi être possible si tu utilises le même mot de passe partout ou un mot de passe vraiment simple.

L’hypothèse d’Aleks reste à creuser aussi.

1 Like

Non, je n’utilises pas Tor Browser, par contre j’ai déjà essayé mais pas à partir du serveur mais d’un PC de mon réseau local. Ça pourrait avoir un rapport?
Pour les mots de passe, je pense qu’ils sont suffisamment sécurisés concernant ssh, la webadmin et mon compte perso. Par contre, pas sûr que ce soit le cas pour tous les utilisateurs du serveur.
Vu que la réponse du serveur est en 4xx dans les logs, c’est sécure normalement, non? Est-ce suffisant?
C’est quoi exactement le header HTTP qui va bien avec le nom?

Oui 444 c’est plutôt bon signe, même si dans l’absolu si quelqu’un rentre en admin on peut imaginer que les traces soient masquées.

Pour tor browser je demandais car si tu te connectes à l’admin web par exemple via tor browser ton ip de provenance peut être de n’importe quel pays. Idem si tu as installé tor (et pas tor browser) et que tu as oublié d’éteindre le service.

Non pas de Tor browser mais possible par vpn.
Par contre la Webadmin n’est accessible qu’en local, donc pas de risque normalement de l’extérieur, j’ai modifié la conf Nginx pour n’accepter que le réseau local et j’ai ajouté une ligne dans le fichier hosts du PC à partir duquel je m’y connecte pour que le nom de domaine pointe directement sur l’Ip locale du RPI.
Pour l’instant je vais me rassurer avec l’hypothèse d’Aleks.
Sinon, avez-vous vous aussi parfois des logs Nginx avec le userid de renseigné comme ici? C’est la seule piste que j’ai pour l’instant, dès que ce userid est renseigné, ils apparaissent comme “logged”. Les seuls qui apparaissent autrement sont soit les utilisateurs yunohost, soit les partages Nextcloud avec une instance fédérée légitime.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.