Evolution #1029
fermé
Adresses IP navigateur dans logs d'échecs d'authentification
100%
Description
Bonjour,
j'ai remarqué qu'Analog incluait non pas l'adresse IP du navigateur, mais celle du serveur. C'est sans doute pratique si l'on agrège les logs de différents serveurs, mais pour surveiller les échecs d'authentification ce n'est pas très utile.
Il serait bon d'inclure dans ces logs l'adresse IP du client, et, pour tenir compte des cas où le frontal web est lui-même derrière un reverse proxy (c'est mon cas), le contenu du header X-Forwarded-For, s'il est présent.
J'ai un patch à soumettre pour la branche master actuelle (testé sur une 0.8.3), le temps de l'emballer correctement… Si vous préférez, je peux le porter en avant vers develop, mais ça me sera moins directement utile (enfin, sauf si la 0.9 est pour tout bientôt).
Fichiers
Mis à jour par Georges Racinet il y a plus de 7 ans
- Fichier 0001-Logging-remote-IPs-in-case-of-failed-login.patch 0001-Logging-remote-IPs-in-case-of-failed-login.patch ajouté
Voici le patch, fait par rapport à master.
Mis à jour par Georges Racinet il y a plus de 7 ans
- Fichier 0001-Develop-Logging-remote-IPs-in-case-of-failed-login.patch 0001-Develop-Logging-remote-IPs-in-case-of-failed-login.patch ajouté
Et voici un portage à la branche develop (mais je n'ai pas eu l'occasion de le tester en vrai)
Mis à jour par Johan Cwiklinski il y a plus de 7 ans
- Version cible changé de 0.8.3 à 0.9
Hello,
Merci pour le patch :)
Je me posais la question de l'utilité de cette info dans les logs, alors qu'elle est déjà présente dans la table des logs de Galette. Je présume cependant qu'il est plus facile de configurer un système de surveillance sur un fichier que sur une base de données.
Don, OK pour intégrer ça, pas de soucis.
La 0.9 sortira... Quand elle sera prête. Néanmoins, il n'y aura plus de nouvelles versions de la 0.8.x désormais. Ce sera donc intégré en 0.9 uniquement.
Ce serait donc pas mal que tu puisses tester ça en 0.9 ; même si je ne vois pas de raison pour que ça ne fonctionne pas.
Je n'ai pas la possibilité de tester les histoires de proxy ; mais je présume que l'IP enregistrée dans l'historique est incorrecte elle aussi, je me trompe ?
Mis à jour par Georges Racinet il y a plus de 7 ans
Pour info, je compte utiliser fail2ban pour surveiller tout ca, et je confirme, c'est plus direct et uniforme de suivre des logs en fichiers (ou assimilés). Par exemple fail2ban peut repérer également les attaques SSH, tentatives de pollution DNS et bien d'autres. C'est utile d'avoir de l'uniformité à ce niveau quand on a des services très divers à surveiller.
Merci pour les infos sur les versions, effectivement ce qui compte pour moi c'est d'avoir le moins possible à maintenir mes propres patches, donc si la prochaine version est a priori la 0.9, ça va très bien. Je vais voir pour tester en branche 'develop', et te tiendrai au courant.
Pour l'IP enregistrée dans historique, si l'on parle bien de la colonne ip_log de la table galette_logs, effectivement je vois uniformément l'adresse du reverse proxy depuis qu'on en a un… Je peux ajouter des patches pour ça, mais il y a un petit hic dans le cas le plus genéral : X-Forwarded-For est multivalué (représente la chaîne entière de proxies), et si l'on fait confiance aveuglément en prenant la première valeur, alors c'est facile de tricher, ou simplement c'est sans intérêt (par exemple avec une adresse privée comme point de départ, et un forward-proxy, scénario courant de réseau d'entreprise ou de hotspot). Donc il faudrait un param de config indiquant quel(s) proxies on veut remplacer par l'IP amont, ça devient plus compliqué, mais je veux bien le faire.
Mis à jour par Johan Cwiklinski il y a plus de 7 ans
- Précède Evolution #1031: Prise en compte des proxy dans les logs ajouté
Mis à jour par Johan Cwiklinski il y a plus de 7 ans
Georges Racinet a écrit :
Merci pour les infos sur les versions, effectivement ce qui compte pour moi c'est d'avoir le moins possible à maintenir mes propres patches, donc si la prochaine version est a priori la 0.9, ça va très bien. Je vais voir pour tester en branche 'develop', et te tiendrai au courant.
Ok, merci :)
Pour l'IP enregistrée dans historique, si l'on parle bien de la colonne ip_log de la table galette_logs, effectivement je vois uniformément l'adresse du reverse proxy depuis qu'on en a un… Je peux ajouter des patches pour ça, mais il y a un petit hic dans le cas le plus genéral : X-Forwarded-For est multivalué (représente la chaîne entière de proxies), et si l'on fait confiance aveuglément en prenant la première valeur, alors c'est facile de tricher, ou simplement c'est sans intérêt (par exemple avec une adresse privée comme point de départ, et un forward-proxy, scénario courant de réseau d'entreprise ou de hotspot). Donc il faudrait un param de config indiquant quel(s) proxies on veut remplacer par l'IP amont, ça devient plus compliqué, mais je veux bien le faire.
Hum... Je ne pensais pas que la récupération serait si "compliquée" :-/ je te laisse juge pour le coup ; tu es actuellement le seul utilisateur ayant émis ce type de besoin.
J'ai créé un ticket à part (#1031) pour ce point précis, sachant que je ne pourrai m'en charger moi même, si tu es partant... :-)
Mis à jour par Georges Racinet il y a plus de 7 ans
Je confirme que le patch pour la branche develop fonctionne :
192.168.0.202 - 2017-05-27 14:43:39 - 4 - No entry found for login `asd` Client 192.168.0.245 X-Forwarded-For 2a01:e35:abcd:dead:beef:abcd:6385:b204
Vu pour #1031, merci, et pour ce qui est de la complexité, bah c'est l'adresse IP elle même qui n'est qu'un pis-aller.
Mis à jour par Johan Cwiklinski il y a plus de 7 ans
- Statut changé de Nouveau à Fermé
- % réalisé changé de 0 à 100
Patch intégré, merci