retrouver site consulter par un utilisateur sans squid
-
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