webalizer a été compilé avec les options suivante : ./configure --with-language=french --enable-dns
Bonjour
J'ai eu le même probleme ce week end, sans parvenir à le résoudre. J'ai donc choisis de confier cette opération à apache, dans httpd.conf : HostnameLookups on
a+
ps : mettre aussi ServerTokens Prod
Debellez :
Bonjour,
Je n'arrive pas à obtenir de webalizer la résolution des adresses ip dans
les statistiques d'apache.
webalizer a été compilé avec les options suivante :
./configure --with-language=french --enable-dns
Bonjour
J'ai eu le même probleme ce week end, sans parvenir à le résoudre. J'ai donc
choisis de confier cette opération à apache, dans httpd.conf :
HostnameLookups on
webalizer a été compilé avec les options suivante : ./configure --with-language=french --enable-dns
Bonjour
J'ai eu le même probleme ce week end, sans parvenir à le résoudre. J'ai donc choisis de confier cette opération à apache, dans httpd.conf : HostnameLookups on
a+
ps : mettre aussi ServerTokens Prod
EoIP
EoIP :
ps : mettre aussi ServerTokens Prod
En parlant de sécurité, c'est complètement HC mais il faut absolument que tu empêche l'apparition des extensions php, js, css et tout ce qui contient "config" dans tes stats si tu choisis de les rendre public : dans webalizer.conf par exemple HideURL *.php IgnoreURL /config*
a+
EoIP :
ps : mettre aussi ServerTokens Prod
En parlant de sécurité, c'est complètement HC mais il faut absolument que tu
empêche l'apparition des extensions php, js, css et tout ce qui contient
"config" dans tes stats si tu choisis de les rendre public :
dans webalizer.conf par exemple
HideURL *.php
IgnoreURL /config*
En parlant de sécurité, c'est complètement HC mais il faut absolument que tu empêche l'apparition des extensions php, js, css et tout ce qui contient "config" dans tes stats si tu choisis de les rendre public : dans webalizer.conf par exemple HideURL *.php IgnoreURL /config*
a+
Laurent
Je n'arrive pas à obtenir de webalizer la résolution des adresses ip dans les statistiques d'apache.
J'ai eu le même soucis, et j'ai résolu (contourné ?) le problème en patchant webalizer avec geolizer, qui mets la cerise sur le gateau en précisant plus finement les pays d'origine ... http://freshmeat.net/projects/geolizer/
Je n'arrive pas à obtenir de webalizer la résolution des adresses ip dans
les statistiques d'apache.
J'ai eu le même soucis, et j'ai résolu (contourné ?) le problème en
patchant webalizer avec geolizer, qui mets la cerise sur le gateau en
précisant plus finement les pays d'origine ...
http://freshmeat.net/projects/geolizer/
Je n'arrive pas à obtenir de webalizer la résolution des adresses ip dans les statistiques d'apache.
J'ai eu le même soucis, et j'ai résolu (contourné ?) le problème en patchant webalizer avec geolizer, qui mets la cerise sur le gateau en précisant plus finement les pays d'origine ... http://freshmeat.net/projects/geolizer/
Debellez
EoIP wrote in news:446b24ad$0$19716$:
EoIP :
ps : mettre aussi ServerTokens Prod
En parlant de sécurité, c'est complètement HC mais il faut absolument que tu empêche l'apparition des extensions php, js, css et tout ce qui contient "config" dans tes stats si tu choisis de les rendre public : dans webalizer.conf par exemple HideURL *.php IgnoreURL /config*
a+
Ok, j'ai mis en place ta solution.
Tant pis pour les stats générées jusqu'a maintenant.
Merci de ta réponse.
(mais c'est quand même bizarre que ca ne fonctionne pas avec webalizer)
EoIP <everything@over.ip> wrote in
news:446b24ad$0$19716$8fcfb975@news.wanadoo.fr:
EoIP :
ps : mettre aussi ServerTokens Prod
En parlant de sécurité, c'est complètement HC mais il faut absolument
que tu empêche l'apparition des extensions php, js, css et tout ce qui
contient "config" dans tes stats si tu choisis de les rendre public :
dans webalizer.conf par exemple
HideURL *.php
IgnoreURL /config*
a+
Ok, j'ai mis en place ta solution.
Tant pis pour les stats générées jusqu'a maintenant.
Merci de ta réponse.
(mais c'est quand même bizarre que ca ne fonctionne pas avec webalizer)
En parlant de sécurité, c'est complètement HC mais il faut absolument que tu empêche l'apparition des extensions php, js, css et tout ce qui contient "config" dans tes stats si tu choisis de les rendre public : dans webalizer.conf par exemple HideURL *.php IgnoreURL /config*
a+
Ok, j'ai mis en place ta solution.
Tant pis pour les stats générées jusqu'a maintenant.
Merci de ta réponse.
(mais c'est quand même bizarre que ca ne fonctionne pas avec webalizer)
Christophe PEREZ
Le Wed, 17 May 2006 15:27:09 +0200, EoIP a écrit:
En parlant de sécurité, c'est complètement HC mais il faut absolument que tu empêche l'apparition des extensions php, js, css et tout ce qui contient "config" dans tes stats si tu choisis de les rendre public : dans webalizer.conf par exemple HideURL *.php IgnoreURL /config*
Pour en arriver là, la sécurité du site me semble bien mal assurée. Si vos "js" contiennent des éléments confidentiels, sachez qu'ils ne doivent déjà plus l'être depuis longtemps. Quant à vos "css", j'aimerais bien savoir ce que vous souhaitez y cacher. Enfin, si vos php peuvent être "lus" (les sources), vous avez du soucis à vous faire. Et si un site est entièrement en php, qu'est-ce que vous préconisez ? De ne pas utiliser webalizer ?
En clair, si c'est pour avoir des stats d'où vous excluez tout, à quoi vous servent ces stats ?
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 17 May 2006 15:27:09 +0200, EoIP a écrit:
En parlant de sécurité, c'est complètement HC mais il faut absolument que tu
empêche l'apparition des extensions php, js, css et tout ce qui contient
"config" dans tes stats si tu choisis de les rendre public :
dans webalizer.conf par exemple
HideURL *.php
IgnoreURL /config*
Pour en arriver là, la sécurité du site me semble bien mal assurée.
Si vos "js" contiennent des éléments confidentiels, sachez qu'ils ne
doivent déjà plus l'être depuis longtemps.
Quant à vos "css", j'aimerais bien savoir ce que vous souhaitez y cacher.
Enfin, si vos php peuvent être "lus" (les sources), vous avez du soucis
à vous faire.
Et si un site est entièrement en php, qu'est-ce que vous préconisez ? De
ne pas utiliser webalizer ?
En clair, si c'est pour avoir des stats d'où vous excluez tout, à quoi
vous servent ces stats ?
En parlant de sécurité, c'est complètement HC mais il faut absolument que tu empêche l'apparition des extensions php, js, css et tout ce qui contient "config" dans tes stats si tu choisis de les rendre public : dans webalizer.conf par exemple HideURL *.php IgnoreURL /config*
Pour en arriver là, la sécurité du site me semble bien mal assurée. Si vos "js" contiennent des éléments confidentiels, sachez qu'ils ne doivent déjà plus l'être depuis longtemps. Quant à vos "css", j'aimerais bien savoir ce que vous souhaitez y cacher. Enfin, si vos php peuvent être "lus" (les sources), vous avez du soucis à vous faire. Et si un site est entièrement en php, qu'est-ce que vous préconisez ? De ne pas utiliser webalizer ?
En clair, si c'est pour avoir des stats d'où vous excluez tout, à quoi vous servent ces stats ?
-- Christophe PEREZ Écrivez moi sans _faute !
Sébastien Monbrun aka TiChou
Dans le message <news:446b24ad$0$19716$, *EoIP* tapota sur f.c.o.l.configuration :
En parlant de sécurité, c'est complètement HC mais il faut absolument que tu empêche l'apparition des extensions php, js, css
Pourquoi ?
-- Sébastien Monbrun aka TiChou
Dans le message <news:446b24ad$0$19716$8fcfb975@news.wanadoo.fr>,
*EoIP* tapota sur f.c.o.l.configuration :
En parlant de sécurité, c'est complètement HC mais il faut absolument que
tu empêche l'apparition des extensions php, js, css
Dans le message <news:446b24ad$0$19716$, *EoIP* tapota sur f.c.o.l.configuration :
En parlant de sécurité, c'est complètement HC mais il faut absolument que tu empêche l'apparition des extensions php, js, css
Pourquoi ?
-- Sébastien Monbrun aka TiChou
EoIP
Christophe PEREZ :
Pour en arriver là, la sécurité du site me semble bien mal assurée. Ce sont des détails, les détails ont toujours une importance :)
Et puis c'est une réponse que j'ai faite à la volée. Il n'a absolument rien à perdre à suivre ces conseils.
Si vos "js" contiennent des éléments confidentiels, sachez qu'ils ne doivent déjà plus l'être depuis longtemps. Quant à vos "css", j'aimerais bien savoir ce que vous souhaitez y cacher. Enfin, si vos php peuvent être "lus" (les sources), vous avez du soucis à vous faire.
Les css et js n'ont (presque) rien à cacher selon moi. Mais ça fausse les stats. Pas plus que les php, mais ça donne selon moi trop de renseignements sur l'architecture du site. C'est jamais bon d'avoir un configure.php dans les stats (surtout sur un petit site où l'administrateur occasionne beaucoup de "Hits"). En plus un moteur peut venir le répertorier vu qu'elles sont publiques, non ?
Et si un site est entièrement en php, qu'est-ce que vous préconisez ? De ne pas utiliser webalizer ?
Pour un site entièrement en php je préconise d'utiliser la réécriture d'adresse. C'est tout bénef. Et pis c'est beau :)
En clair, si c'est pour avoir des stats d'où vous excluez tout, à quoi vous servent ces stats ?
À connaitre le nombnre de visiteurs, les pages vues, pages d'entrée, pages de sortie, référents etc Pas le nombre de fois qu'a été exécuté un header.inc.php ... Pas la peine non plus d'afficher le nombre de vue d'un spacer.gif de 1px.
D'ailleurs la configuration de webalizer exclu d'origine les pages htm*. Tout comme les images et tout le reste. Après si on préfère un "1856669 Hits" c'est sûr que ça peut déranger :)
Cordialement
Christophe PEREZ :
Pour en arriver là, la sécurité du site me semble bien mal assurée.
Ce sont des détails, les détails ont toujours une importance :)
Et puis c'est une réponse que j'ai faite à la volée. Il n'a absolument rien à
perdre à suivre ces conseils.
Si vos "js" contiennent des éléments confidentiels, sachez qu'ils ne
doivent déjà plus l'être depuis longtemps.
Quant à vos "css", j'aimerais bien savoir ce que vous souhaitez y cacher.
Enfin, si vos php peuvent être "lus" (les sources), vous avez du soucis
à vous faire.
Les css et js n'ont (presque) rien à cacher selon moi. Mais ça fausse les stats.
Pas plus que les php, mais ça donne selon moi trop de renseignements sur
l'architecture du site. C'est jamais bon d'avoir un configure.php dans les
stats (surtout sur un petit site où l'administrateur occasionne beaucoup de
"Hits"). En plus un moteur peut venir le répertorier vu qu'elles sont
publiques, non ?
Et si un site est entièrement en php, qu'est-ce que vous préconisez ? De
ne pas utiliser webalizer ?
Pour un site entièrement en php je préconise d'utiliser la réécriture d'adresse.
C'est tout bénef. Et pis c'est beau :)
En clair, si c'est pour avoir des stats d'où vous excluez tout, à quoi
vous servent ces stats ?
À connaitre le nombnre de visiteurs, les pages vues, pages d'entrée, pages de
sortie, référents etc Pas le nombre de fois qu'a été exécuté un
header.inc.php ... Pas la peine non plus d'afficher le nombre de vue d'un
spacer.gif de 1px.
D'ailleurs la configuration de webalizer exclu d'origine les pages htm*. Tout
comme les images et tout le reste.
Après si on préfère un "1856669 Hits" c'est sûr que ça peut déranger :)
Pour en arriver là, la sécurité du site me semble bien mal assurée. Ce sont des détails, les détails ont toujours une importance :)
Et puis c'est une réponse que j'ai faite à la volée. Il n'a absolument rien à perdre à suivre ces conseils.
Si vos "js" contiennent des éléments confidentiels, sachez qu'ils ne doivent déjà plus l'être depuis longtemps. Quant à vos "css", j'aimerais bien savoir ce que vous souhaitez y cacher. Enfin, si vos php peuvent être "lus" (les sources), vous avez du soucis à vous faire.
Les css et js n'ont (presque) rien à cacher selon moi. Mais ça fausse les stats. Pas plus que les php, mais ça donne selon moi trop de renseignements sur l'architecture du site. C'est jamais bon d'avoir un configure.php dans les stats (surtout sur un petit site où l'administrateur occasionne beaucoup de "Hits"). En plus un moteur peut venir le répertorier vu qu'elles sont publiques, non ?
Et si un site est entièrement en php, qu'est-ce que vous préconisez ? De ne pas utiliser webalizer ?
Pour un site entièrement en php je préconise d'utiliser la réécriture d'adresse. C'est tout bénef. Et pis c'est beau :)
En clair, si c'est pour avoir des stats d'où vous excluez tout, à quoi vous servent ces stats ?
À connaitre le nombnre de visiteurs, les pages vues, pages d'entrée, pages de sortie, référents etc Pas le nombre de fois qu'a été exécuté un header.inc.php ... Pas la peine non plus d'afficher le nombre de vue d'un spacer.gif de 1px.
D'ailleurs la configuration de webalizer exclu d'origine les pages htm*. Tout comme les images et tout le reste. Après si on préfère un "1856669 Hits" c'est sûr que ça peut déranger :)
Cordialement
Sébastien Monbrun aka TiChou
Dans le message <news:446b5716$0$29182$, *EoIP* tapota sur f.c.o.l.configuration :
Les css et js n'ont (presque) rien à cacher selon moi. Mais ça fausse les stats.
Tout dépend des statistiques que l'on souhaite avoir. Webalizer englobe un ensemble de statistiques : trafic, hit, referer, navigateur, géolocalisation, etc. Mais globalement, je ne vois pas trop en quoi ces statistiques peuvent être faussées par la prise en compte des fichiers js et css, à part peut-être les hits ? Dans ce cas, il vaut mieux utiliser un compteur.
Pas plus que les php, mais ça donne selon moi trop de renseignements sur l'architecture du site.
Ça peut effectivement révéler les liens vers les pages d'administration ou les espaces privés du site. Dans ce cas, oui on peut cacher ou ignorer ces pages ou les chemins vers les espaces privés avec HideURL et IgnoreULR, mais uniquement ces pages là.
C'est jamais bon d'avoir un configure.php dans les stats (surtout sur un petit site où l'administrateur occasionne beaucoup de "Hits").
Mauvais exemple. Ces fichiers là ne sont pas accédés par le navigateur mais sont accédés directement sur le système de fichier par le script l'utilisant. Donc on ne devrait jamais y voir les URL de ces fichiers dans les statistiques.
Et si un site est entièrement en php, qu'est-ce que vous préconisez ? De ne pas utiliser webalizer ?
Pour un site entièrement en php je préconise d'utiliser la réécriture d'adresse. C'est tout bénef. Et pis c'est beau :)
Je cautionne. ;-)
Pas le nombre de fois qu'a été exécuté un header.inc.php
Mauvais exemple aussi. :-) C'est un fichier include, donc non accédé depuis un navigateur donc non vu par le serveur Web.
Après si on préfère un "1856669 Hits" c'est sûr que ça peut déranger :)
Webalizer n'est pas (qu')un outil de hits.
-- Sébastien Monbrun aka TiChou
Dans le message <news:446b5716$0$29182$8fcfb975@news.wanadoo.fr>,
*EoIP* tapota sur f.c.o.l.configuration :
Les css et js n'ont (presque) rien à cacher selon moi. Mais ça fausse les
stats.
Tout dépend des statistiques que l'on souhaite avoir. Webalizer englobe un
ensemble de statistiques : trafic, hit, referer, navigateur,
géolocalisation, etc. Mais globalement, je ne vois pas trop en quoi ces
statistiques peuvent être faussées par la prise en compte des fichiers js et
css, à part peut-être les hits ? Dans ce cas, il vaut mieux utiliser un
compteur.
Pas plus que les php, mais ça donne selon moi trop de
renseignements sur l'architecture du site.
Ça peut effectivement révéler les liens vers les pages d'administration ou
les espaces privés du site. Dans ce cas, oui on peut cacher ou ignorer ces
pages ou les chemins vers les espaces privés avec HideURL et IgnoreULR, mais
uniquement ces pages là.
C'est jamais bon d'avoir un configure.php dans les stats (surtout sur un
petit site où l'administrateur occasionne beaucoup de "Hits").
Mauvais exemple. Ces fichiers là ne sont pas accédés par le navigateur mais
sont accédés directement sur le système de fichier par le script
l'utilisant. Donc on ne devrait jamais y voir les URL de ces fichiers dans
les statistiques.
Et si un site est entièrement en php, qu'est-ce que vous préconisez ? De
ne pas utiliser webalizer ?
Pour un site entièrement en php je préconise d'utiliser la réécriture
d'adresse. C'est tout bénef. Et pis c'est beau :)
Je cautionne. ;-)
Pas le nombre de fois qu'a été exécuté un header.inc.php
Mauvais exemple aussi. :-) C'est un fichier include, donc non accédé depuis
un navigateur donc non vu par le serveur Web.
Après si on préfère un "1856669 Hits" c'est sûr que ça peut déranger :)
Dans le message <news:446b5716$0$29182$, *EoIP* tapota sur f.c.o.l.configuration :
Les css et js n'ont (presque) rien à cacher selon moi. Mais ça fausse les stats.
Tout dépend des statistiques que l'on souhaite avoir. Webalizer englobe un ensemble de statistiques : trafic, hit, referer, navigateur, géolocalisation, etc. Mais globalement, je ne vois pas trop en quoi ces statistiques peuvent être faussées par la prise en compte des fichiers js et css, à part peut-être les hits ? Dans ce cas, il vaut mieux utiliser un compteur.
Pas plus que les php, mais ça donne selon moi trop de renseignements sur l'architecture du site.
Ça peut effectivement révéler les liens vers les pages d'administration ou les espaces privés du site. Dans ce cas, oui on peut cacher ou ignorer ces pages ou les chemins vers les espaces privés avec HideURL et IgnoreULR, mais uniquement ces pages là.
C'est jamais bon d'avoir un configure.php dans les stats (surtout sur un petit site où l'administrateur occasionne beaucoup de "Hits").
Mauvais exemple. Ces fichiers là ne sont pas accédés par le navigateur mais sont accédés directement sur le système de fichier par le script l'utilisant. Donc on ne devrait jamais y voir les URL de ces fichiers dans les statistiques.
Et si un site est entièrement en php, qu'est-ce que vous préconisez ? De ne pas utiliser webalizer ?
Pour un site entièrement en php je préconise d'utiliser la réécriture d'adresse. C'est tout bénef. Et pis c'est beau :)
Je cautionne. ;-)
Pas le nombre de fois qu'a été exécuté un header.inc.php
Mauvais exemple aussi. :-) C'est un fichier include, donc non accédé depuis un navigateur donc non vu par le serveur Web.
Après si on préfère un "1856669 Hits" c'est sûr que ça peut déranger :)
Webalizer n'est pas (qu')un outil de hits.
-- Sébastien Monbrun aka TiChou
EoIP
Sébastien Monbrun aka TiChou :
Dans le message <news:446b5716$0$29182$, *EoIP* tapota sur f.c.o.l.configuration :
Je n'apprécie pas votre comportement façon peigne à poux, c'est pas la première
fois. Et c'est pour ça que je n'ai pas répondu au dessus.
J'ai donné deux petits conseils à un type (tout en apportant un semblant de solution à son problème, n'est-ce pas?) pour éviter qu'un gus passe son samedi soir à tenter je ne sais quoi. Vous, vous analysez la réponse d'une réponse. Tout ça parce que j'ai mis 'sécurité, css et js' dans la même phrase. J'aurais du ajouter 'fiabilité des stats', j'aurais gagné un quart d'heure. Désolé pour inc.php je le saurais.
Sébastien Monbrun aka TiChou :
Dans le message <news:446b5716$0$29182$8fcfb975@news.wanadoo.fr>,
*EoIP* tapota sur f.c.o.l.configuration :
Je n'apprécie pas votre comportement façon peigne à poux, c'est pas la première
fois. Et c'est pour ça que je n'ai pas répondu au dessus.
J'ai donné deux petits conseils à un type (tout en apportant un semblant de
solution à son problème, n'est-ce pas?) pour éviter qu'un gus passe son samedi
soir à tenter je ne sais quoi. Vous, vous analysez la réponse d'une réponse.
Tout ça parce que j'ai mis 'sécurité, css et js' dans la même phrase. J'aurais
du ajouter 'fiabilité des stats', j'aurais gagné un quart d'heure. Désolé pour
inc.php je le saurais.
Dans le message <news:446b5716$0$29182$, *EoIP* tapota sur f.c.o.l.configuration :
Je n'apprécie pas votre comportement façon peigne à poux, c'est pas la première
fois. Et c'est pour ça que je n'ai pas répondu au dessus.
J'ai donné deux petits conseils à un type (tout en apportant un semblant de solution à son problème, n'est-ce pas?) pour éviter qu'un gus passe son samedi soir à tenter je ne sais quoi. Vous, vous analysez la réponse d'une réponse. Tout ça parce que j'ai mis 'sécurité, css et js' dans la même phrase. J'aurais du ajouter 'fiabilité des stats', j'aurais gagné un quart d'heure. Désolé pour inc.php je le saurais.
Debellez
EoIP wrote in news:446b8306$0$21289$:
J'ai donné deux petits conseils à un type (tout en apportant un semblant de solution à son problème, n'est-ce pas?)
Très juste. Merci.
Vous, vous analysez la réponse d'une réponse. Tout ça parce que j'ai mis 'sécurité, css et js' dans la même phrase.
Tu sais je travail en "root" alors question sécurité, j'suis pas encore au top !!!
PS, question à 100 000 E : Sur mon server Debian tourne Apache et Vsftpd. Si mes dd tournent et mes fichiers logs : /var/log/apache2/access.log et /var/log/vsftpd.log restent sans trace d'activité, comment puis je vérifier ce qui se passe ?
Je connais la commande "dmesg" et les différents fichiers logs present dans /var/log/ ne m'apprennent pas grand chose.
EoIP <everything@over.ip> wrote in
news:446b8306$0$21289$8fcfb975@news.wanadoo.fr:
J'ai donné deux petits conseils à un type (tout en apportant un
semblant de solution à son problème, n'est-ce pas?)
Très juste. Merci.
Vous, vous analysez la réponse d'une réponse.
Tout ça parce que j'ai mis 'sécurité, css et js' dans la même phrase.
Tu sais je travail en "root" alors question sécurité, j'suis pas encore au
top !!!
PS, question à 100 000 E : Sur mon server Debian tourne Apache et Vsftpd.
Si mes dd tournent et mes fichiers logs :
/var/log/apache2/access.log et
/var/log/vsftpd.log restent sans trace d'activité, comment puis je vérifier
ce qui se passe ?
Je connais la commande "dmesg" et les différents fichiers logs present dans
/var/log/ ne m'apprennent pas grand chose.
J'ai donné deux petits conseils à un type (tout en apportant un semblant de solution à son problème, n'est-ce pas?)
Très juste. Merci.
Vous, vous analysez la réponse d'une réponse. Tout ça parce que j'ai mis 'sécurité, css et js' dans la même phrase.
Tu sais je travail en "root" alors question sécurité, j'suis pas encore au top !!!
PS, question à 100 000 E : Sur mon server Debian tourne Apache et Vsftpd. Si mes dd tournent et mes fichiers logs : /var/log/apache2/access.log et /var/log/vsftpd.log restent sans trace d'activité, comment puis je vérifier ce qui se passe ?
Je connais la commande "dmesg" et les différents fichiers logs present dans /var/log/ ne m'apprennent pas grand chose.
