retrouver site consulter par un utilisateur sans squid



  • Bonjour
    Je suis administrateur system et j'utilise pfsense comme firewall et portail captif avec authentification via radius.

    Je cherche a retrouver un utilisateur aillant consulter un site a une date précise est ce possible sans squid ? (log, requete DNS ou autre)

    Cordialement



  • Bonjour,

    Avec les log sur les règles, vous pourrez avoir les ip des serveurs mais pas le site.

    pF n'est pas non plus le meilleur emplacement pour squid ...



  • OK je télécharge les logs je vais voir si je retrouve l'ip du site.
    Grep fonctionne pas :).



  • Tout va dépendre des longs que vous avez activè et de quelle manière ils sont stockés. Ce sera un travail probablement fastidieux à condition de connaître l'url du site.



  • @bobstay said in retrouver site consulter par un utilisateur sans squid:

    Grep fonctionne pas :).

    C'est nouveau ça.

    [2.4.3-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: cd /var/log
    [2.4.3-RELEASE][admin@pfsense.brit-hotel-fumel.net]/var/log: ls -al
    total 45192
    drwxr-xr-x   7 root        wheel           1024 May 10 22:06 .
    drwxr-xr-x  32 root        wheel            512 May 10 22:06 ..
    -rw-------   1 root        wheel         511488 Aug 10 07:31 dhcpd.log
    -rw-r--r--   1 root        wheel          10025 Jun  8 07:41 dmesg.boot
    -rw-------   1 root        wheel         511488 Aug  7 02:00 filter.log
    -rw-------   1 root        wheel         511488 Aug  9 16:47 gateways.log
    -rw-------   1 root        wheel          38454 Jan 29  2015 installer.log
    -rw-------   1 root        wheel         511488 May 18  2016 ipsec.log
    -rw-------   1 root        wheel         511488 May  9  2016 l2tps.log
    -rw-r--r--   1 root        wheel              0 Jan 29  2015 lastlog
    drwxr-xr-x   2 munin       munin            512 Jan 29  2015 munin
    drwxr-xr-x   2 root        wheel            512 Feb 21  2017 nginx
    -rw-------   1 root        wheel         835549 Feb 21  2017 nginx-error.log
    -rw-------   1 root        wheel         511488 Aug 10 07:31 nginx.log
    drwxr-xr-x   2 root        wheel            512 Jan 29  2015 ntp
    -rw-------   1 root        wheel         511488 Aug  6 02:41 ntpd.log
    -rw-------   1 root        wheel         511488 Aug  9 23:50 openvpn.log
    drwxr-xr-x   2 root        wheel            512 Jun  7  2016 pfblockerng
    -rw-------   1 root        wheel         511488 May  9  2016 poes.log
    -rw-------   1 root        wheel         511488 Aug 10 07:20 portalauth.log
    -rw-------   1 root        wheel         511488 Feb 15 16:54 ppp.log
    -rw-------   1 root        wheel         511488 May  9  2016 pptps.log
    drwx------   5 root        wheel            512 Apr 19 07:57 radacct
    -rw-------   1 freeradius  freeradius         0 May 10 17:26 radius.log
    -rw-------   1 freeradius  freeradius      1680 Aug 10 07:30 radutmp
    -rw-------   1 freeradius  freeradius         0 Apr 17 07:39 radwtmp
    -rw-------   1 root        wheel         511488 Jul 27  2016 relayd.log
    -rw-------   1 root        wheel         511488 Aug  9 22:10 resolver.log
    -rw-------   1 root        wheel         511488 Jul 30 08:17 routing.log
    -rw-r-----   1 root        wheel       34465023 Aug 10 07:30 sqltrace.sql
    -rw-------   1 root        wheel         511488 Aug 10 07:31 system.log
    -rw-------   1 root        wheel         630364 Jul 12 10:33 userlog
    -rw-r--r--   1 root        wheel            394 Aug 10 07:30 utx.lastlogin
    -rw-------   1 root        wheel          78927 Aug 10 07:30 utx.log
    -rw-------   1 root        wheel         511488 May  9  2016 vpn.log
    -rw-------   1 root        wheel         511488 Oct 25  2017 wireless.log
    [2.4.3-RELEASE][admin@pfsense.brit-hotel-fumel.net]/var/log:
    

    Déjà le fait que pas mal de fichier log ont exactement la même taille, ça fait réfléchir, non ;)

    clog dhcpd.log | grep 'INFORM'
    

    Le format d'un fichier log est 'circular' et binaire (ça évite l'utilisation de logrotate), il te faut l'outil 'clog' pour le voir en clair.



  • Cette question, ou une question très proche, a été posée, sur ce forum, il y a juste 1 ou 2 semaines !

    Alors pourquoi ne pas rappeler, à ce débutant, ce principe ELEMENTAIRE 'd'abord chercher dans le forum si une question similaire a été posée' ?

    On voit qu'il est capable de chercher mais il ne va pas assez loin ('grep fonctionne pas').

    En gage, je propose que bobstay cherche et rédige une raison, pratique et facile à comprendre, qui explique pourquoi un firewall n'est pas capable de donner une url de navigation alors qu'un proxy sait le faire ...

    NB : pour boucler, bien évidemment, des réponses ... ont déjà été données sur ce forum !

    Mention spéciale à Gertjan qui fournit une information peu connue : la circularisation des logs !



  • Bonjour,

    Merci d'avoir lu mon sujet, j'ai fait la recherche sur le forum avant de poster mais peut être que le titre était pas assez explicite.

    Je suis bien conscient qu'un firewall n'est pas capable de donner une URL mais le service DNS de pfsense si.

    grep ne confectionne pas = grep -r chose *

    Solution:!
    Pour simplifier ma recherche en évitant clog pipe grep et autre... j'ai télécharger le dossier log et ouvert note-pad, recherché et mis l'adresse ip du site concerné et espérant qu'il y ai pas cloudflare :), log 'circular' et binaire ou pas sa à l'aire de lire.



  • Non, encore une fois, vous ne cherchez PAS ASSEZ : 'Question sur le suivi des site contactés' (contacté = consulté, non ?). Prenez un peu plus de temps ...

    C'est un raisonnement que tout le monde n'a pas pas :

    • une machine qui navigue fait une requête dns juste avant

    Mais, cela ne donne que le tout début de l'url : très insuffisant.
    Et il ne faut pas que le noms soit resté dans le cache ...
    Bref méthode peu fiable.

    J'attendais une autre remarque, plus en rapport avec le protocole ...



  • Je pense qu'au lieu de donner des leçons sa serait plus constructif de donner des solutions, si mon sujet vous dérange ni répondez pas et allez voir ailleurs.

    En rien le sujet ne m'aide a part dire utilisé un proxy ...

    Je ne comprend pas votre remarque j'ai peut être une vision obtus de la chose:

    une personne veut consulter un site, elle se log, tape dans google sont site, le selectionne, la requete DNS demande qui est le site reponse xxx.xx.xx.xx et go

    le début de l URL me suffit pas besoin de l’arborescence du site.



  • salut salut

    Merci de baisser vous aussi de ton, bien que mes petits camarade puissent passablement irrité par la présentation et le contenu plus que limite de certain topic, je vais vous répondre sur certain de votre non connaissance du sujet qui je reconnais n'est pas si simple à assimiler et pourtant.

    1- un pare feu n'a pour fonction que deux choses à faire ==> laisser passer ou ne pas laisser passer tel ou tel paquet réseau dans un sens donné.
    2- il a été rajouter des fonctions connexes et annexe au fil du temps comme le services dhcp, vpn... qui ne sont que des additifs pour tout avoir sous la main (dans la même boite) mais cela implique aussi de savoir de quoi l'on va parler et pour vous vouloir faire au final.

    Pour vous c'est un besoin de bloquer x ou y url, bon ok, mais avez vous fait une rechercher sur les outils qui permettaient de sniffer car c'est ce cela qu'il s'agit et aussi d'analyser les log des dites url ? qui ne sont pas des addons propre à pf ou au pare feu en général et qui sont quand ils tournent sur des machines dédiées (physiques ou virtuelles) donne plus d'information et permettent plus d'analyse de ces informations. En vrac "elasticsurch" pas sur de l'acronyme exacte par exemple. whilshark pour la capture des paquets et analyse à froid. tous les ips en addon ou sur machines dédiées font le taf.

    Par contre si cela est pour avoir une analyse en direct il y a des outils matériels qui eux coutent la peau des fesses même pour une dsi,

    Donc en résumé ici pf n'est pas forcement le bons outils pour l'analyse, si on ne lui dit pas "ceci ne passe pas dans tel sens" il le laissera passer, après reste pour l'aspect législatif du problème que tous dsi et direction d'entreprise doivent prendre conscience de se qu'il peut etre fait ou pas. Des entreprises ont joué et ont perdu très gros.

    Cordialement cette fois ci.

    ps : eux comme moi répondons de manière bénévole, nous ne faisons pas parti de l'éditeur et ou de fabriquant du matériel.



  • Bon, je fais le constat que vous répondez, par 2 fois, très rapidement à ce que j'écris. De mon point de vue, c'est que vous ne passez pas assez de temps à rechercher, à lire, à analyser, bref à tirer profit de ce qui a été déjà écrit. Et c'est fort dommage ...

    J'aurais au moins apprécié que vous écriviez qu'en effet, un fil avec un questionnement identique avait déjà été posée (et qu'en filigrane la solution proxy est la seule efficace). J'ai même donné le titre du fil, mais non.

    Quel serait l'intérêt d'un forum où les mêmes questions seraient posées tout les 15 jours ? AUCUN bien évidemment.

    Quand on connait la célèbre phrase de Maimonide et du poisson, je préfère toujours faire apprendre à pêcher, parce que c'est une action de bien plus longue durée ...
    Il y a des sociétés pour ceux qui manger tout de suite ...



  • Je vois qu'ici on aime étaler sa science !



  • comment ne pas etre ...

    bon aller ...

    Au surtout pas revoir


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy