SARG : Nom d'utilisateur à la place de l'adresse IP
-
Bonjour,
Dans le cadre de mon projet, je dois mettre en place un système de surveillance de logs dans le cadre de la loi de la conservation des données informatique.
Je suis partis sur un pfSense avec, installé et fonctionnel, un portail captif + squid (proxy transparent)Squid me génère bel et bien des logs que SARG du pfSense peut très bien les lire, le soucis étant que les postes utilisateurs sont en DHCP et que SARG fait une liste en fonction des IP des postes.
Le problème étant que, dans cette configuration, on ne peut pas savoir qui a eu tel IP a tel moment.C'est pour cela que j'ai besoin de vous ; j'aimerais savoir si c'est possible de changer l'IP par le nom d'utilisateur (entré dans le portail captif) ?
Pour illustrer mes propos, veuillez retrouver en pièce-jointe un screenshot de la situation actuel(sarg.jpg) et celle que j'aimerais(sarg2.jpg). (Notez l'utilisation experte de Paint !)
-
2me post et toujours pas lu A LIRE EN PREMIER …
Ce sujet n'a strictement rien à voir avec pfSense : ce n'est lié qu'à Squid !
Il est même possible que choisir pfSense soit un handicap pour réussir la question (comme toujours quand on pense solution avant besoin !).Votre problème est d'incorporer l'authentification à l'intérieur de Squid.
Comme vous ne décrivez pas comment identifier un utilisateur ...Une bonne présentation :
- j'ai un parc de PC, qui sont tous membres d'un domaine Windows,
- ils passent tous par un proxy http Squid
- comment récupérer le nom d'utilisateur (=le profil Windows) dans les logs de Squid, et partant dans un outil de reporting tel Sarg.
Comme cela, on sait où chercher ...
-
Je confirme que le besoin, le projet sont (très) mal exprimés. On commence par des solutions squid (proxy transparent), donc à l'envers. Et forcément cela ne fonctionne pas. Et cela ne peut pas fonctionner d'ailleurs.
Et c'est bien un problème dans lequel Pfsense n'a rien à voir. -
Effectivement ça ne peut pas marcher parce que le proxy en mode transparent ignore complètement la notion d'utilisateur et ne peut en aucun cas prendre celle-ci en compte puisque, by design, le proxy est inconnu du browser (c'est le principe du mode transparent). Il ne pourra donc jamais répondre à la requête HTTP 407 de demande d’authentification du proxy.
J'ajouterai que identifier une adresse IP ne permet pas non plus d'identifier un utilisateur.
Et en allant un peu plus loin, idem pour l'adresse MAC ;DCeci étant, je me demande bien pourquoi lorsqu'il y a une question relative au DNS ou au VPN vous ne tenez pas, de la même manière, ce propos ferme de dire :
"mais c'est du DNS qu'on peut faire tourner sur une autre machine, ça n'a rien à voir avec pfSense !"::)
-
Effectivement ça ne peut pas marcher parce que le proxy en mode transparent ignore complètement la notion d'utilisateur et ne peut en aucun cas prendre celle-ci en compte puisque, by design, le proxy est inconnu du browser (c'est le principe du mode transparent). Il ne pourra donc jamais répondre à la requête HTTP 407 de demande d’authentification du proxy.
J'ajouterai que identifier une adresse IP ne permet pas non plus d'identifier un utilisateur.
Et en allant un peu plus loin, idem pour l'adresse MAC ;DIl n'est en effet pas inutile de le rappeler.
Ceci étant, je me demande bien pourquoi lorsqu'il y a une question relative au DNS ou au VPN vous ne tenez pas, de la même manière, ce propos ferme de dire :
"mais c'est du DNS qu'on peut faire tourner sur une autre machine, ça n'a rien à voir avec pfSense !"::)
La raison est peut être que les fonctionnalités vpn et dns sont natives dans Pfsense. Ce qui n'est pas le cas de Squid. On pourrait étendre, dans les deux sens, le raisonnement à d'autres services: DHCP, portail captif, NTP, Wake-on-LAN …
-
Ce qui est fort dans mon propos, outre que le problème est exclusivement SQUID,
- pfSense est peut-être un handicap : j'aurais dû écrire 'sûrement' car il est probable/possible que l'on ne peut y ajouter ce qui est nécessaire
- je propose une façon de poser l'identification (démarche positive)
Conclusion :
La réponse au besoin (une analyse de la navigation par identification utilisateur) ne peut être mise en place sur pfSense.
Une bonne réponse passe par un proxy dédié, dûment configuré avec identification (et wpad).Concernant l'identification, l'ip et la mac address n'ont pas grand sens, bien sûr, quel que soit l'artifice (ip fixé par le serveur dhcp, sauf peut-être nac).
Concernant dns et vpn, comme écrit par ccnet, c'est natif pfSense et cela ne risque pas dégrader les perf d'un pfsense au contraire d'un addons … (ah la volonté de faire polémique ...)
-
@jdh:
Concernant dns et vpn, comme écrit par ccnet, c'est natif pfSense et cela ne risque pas dégrader les perf d'un pfsense au contraire d'un addons … (ah la volonté de faire polémique ...)
Pas de polémique dans mon propos. ;)
Je n'adhère juste pas à cette position, que je considère comme rigide, et qui consiste à dire:
"les packages que pfSense propose nativement via son interface… ils ne devraient pas les proposer parce que ce sont des packages"
Si ce n'est qu'un aspect "performance", comme tu le mets en avant de temps en temps, ça n'a pas beaucoup de sens car cela dépend à la fois du hardware, du nombre d'utilisateurs, de la complexité des règles de filtrage de Squidguard... bref, oui ça consomme des ressources mais si tu fais beaucoup de tunnels VPN, ça consomme également ::)
Donc la performance comme point d'opposition systématique au proxy en local sur pfSense ... bof.
Si le point est que pfSense ne devrait pas proposer de fonctionner en UTM étendu, ce qui peut se défendre, il faut aller le discuter dans les sections générales du forum en anglais pour expliquer que cette stratégie n'est pas la bonne mais tant que les packages sont disponibles depuis l'interface native de pfSense, il est, à mon sens, assez difficile de tenir, de manière honnête, une position non argumentée (je veux dire sérieusement, car la performance.. ::)) pour dire qu'il ne faut pas le faire.
Et, pour conclure, si le but est de dire que le FW ne devrait servir que de FW, alors il faut s'opposer avec autant de force aux autres services, DNS, DHCP, VPN, portail captif etc...
Je ne comprends pas cette opposition systématique au proxy uniquement lorsqu'elle n'est pas factuellement argumentée.
PS1: https://www.pfsense.org/hardware/#requirements
PS2: si tu en as l'occasion, configure un pfSense avec de nombreux tunnels VPN et tu constateras qu'en terme de CPU, même si c'est nativement intégré à pfSense, ça consomme pas mal. -
Polémique retour : comme d'hab …
Oui, je considère qu'un firewall doit s'occuper essentiellement de firewall !
Bien évidemment il y a des services qui peuvent, compte tenu de sa position, être assuré par le firewall :- DNS : au moins relais
- DHCP : pour un petit site ou pour des zones telles 'Wifi Guest', ...
- VPN : le contrôle se fait mieux au niveau du firewall puisque c'est la 'protection périmétrique' (Oui le cryptage nécessite de la puissance cpu)
- Portail Captif : le mettre ailleurs ? où ?
- NTP : pourquoi ne pas avoir un seul client vers l'extérieur (le fw) et rediffuser en interne ?
...
Inversement certains éléments natifs pfSense ne devraient pas être utilisés sur le firewall :
- Gestion des certificats : les gérer en interne
- Gestion Users : pourquoi pas gérer plusieurs administrateurs, mais pas pour gérer des users de portail captif ou Squid ...
...
Bien évidemment, des addons tel Squid auront une bien meilleure place sur une machine dédiée pour de multiples raisons : charge cpu, mémoire, disque
Maintenant, le simple bon sens recommande de mettre le moins de choses possibles (et inutiles) sur une machine tel un firewall.
Du fait de la stabilité de fonctionnement nécessaire qui peut être perturbée par des fonctionnnalités ou addons non nécessaires voire non sécurisés (addons en particulier).Le simple bon sens n'est pas uniformément réparti ....
Merci de ne pas polluer ce fil ...