Le Tue, 21 Jun 2005 21:48:54 +0000, Dominique Blas a écrit :
systèmatiquement destinées au même serveur (et provenant du même client) ? ai-je écrit.
Et ? Un mec qui lit son mail en clair toute la journée sur Hotmail, c'est typiquement ce type de cas. Un gars qui passe sa vie sur Google, Le Monde Freshmeat ou Slashdot aussi. Ce sont des sites connus dont il est simple de détecter le contenu et de supprimer des logs, mais le forum des collectionneurs de boutons dorés d'autoradio des années 70 le sera probablement un peu moins.
C'est un début d'analyse comportementale il est vrai : analyser, au niveau du proxy, les relations client-serveur et sortir dans un tableau de bord (pour commencer) les << top-chartistes >> en terme de durée.
La durée n'a aucune valeur en HTTP, même si on a le keep-alive de HTTP/1.1. Une meilleure approche va amha être la fréquence des requêtes et leur répartition dans le temps, qui va clairement trahir la présence du tunnel.
-- BOFH excuse #220:
Someone thought The Big Red Button was a light switch.
Le Tue, 21 Jun 2005 21:48:54 +0000, Dominique Blas a écrit :
systèmatiquement destinées au même serveur (et provenant du même client) ?
ai-je écrit.
Et ? Un mec qui lit son mail en clair toute la journée sur Hotmail, c'est
typiquement ce type de cas. Un gars qui passe sa vie sur Google, Le Monde
Freshmeat ou Slashdot aussi. Ce sont des sites connus dont il est simple
de détecter le contenu et de supprimer des logs, mais le forum des
collectionneurs de boutons dorés d'autoradio des années 70 le sera
probablement un peu moins.
C'est un début d'analyse comportementale il est vrai : analyser, au
niveau du proxy, les relations client-serveur et sortir dans un tableau
de bord (pour commencer) les << top-chartistes >> en terme de durée.
La durée n'a aucune valeur en HTTP, même si on a le keep-alive de
HTTP/1.1.
Une meilleure approche va amha être la fréquence des requêtes et leur
répartition dans le temps, qui va clairement trahir la présence du
tunnel.
--
BOFH excuse #220:
Someone thought The Big Red Button was a light switch.
Le Tue, 21 Jun 2005 21:48:54 +0000, Dominique Blas a écrit :
systèmatiquement destinées au même serveur (et provenant du même client) ? ai-je écrit.
Et ? Un mec qui lit son mail en clair toute la journée sur Hotmail, c'est typiquement ce type de cas. Un gars qui passe sa vie sur Google, Le Monde Freshmeat ou Slashdot aussi. Ce sont des sites connus dont il est simple de détecter le contenu et de supprimer des logs, mais le forum des collectionneurs de boutons dorés d'autoradio des années 70 le sera probablement un peu moins.
C'est un début d'analyse comportementale il est vrai : analyser, au niveau du proxy, les relations client-serveur et sortir dans un tableau de bord (pour commencer) les << top-chartistes >> en terme de durée.
La durée n'a aucune valeur en HTTP, même si on a le keep-alive de HTTP/1.1. Une meilleure approche va amha être la fréquence des requêtes et leur répartition dans le temps, qui va clairement trahir la présence du tunnel.
-- BOFH excuse #220:
Someone thought The Big Red Button was a light switch.
Khanh-Dang
Une meilleure approche va amha être la fréquence des requêtes et leur répartition dans le temps, qui va clairement trahir la présence du tunnel.
Oui. D'ailleurs, avoir des statistiques temporelles donne déjà beaucoup d'informations. J'avais lu une anecdote, je ne sais plus où : juste en surveillant le nombre de commandes de pizza à livrer au Pentagone, aux alentours d'un certain 11 septembre, on pouvait se douter qu'il se passait quelque chose. Quant à savoir quoi, il faudrait savoir lire dans la pizza ;-)
Une meilleure approche va amha être la fréquence des requêtes et leur
répartition dans le temps, qui va clairement trahir la présence du
tunnel.
Oui. D'ailleurs, avoir des statistiques temporelles donne déjà beaucoup
d'informations. J'avais lu une anecdote, je ne sais plus où : juste en
surveillant le nombre de commandes de pizza à livrer au Pentagone, aux
alentours d'un certain 11 septembre, on pouvait se douter qu'il se
passait quelque chose. Quant à savoir quoi, il faudrait savoir lire dans
la pizza ;-)
Une meilleure approche va amha être la fréquence des requêtes et leur répartition dans le temps, qui va clairement trahir la présence du tunnel.
Oui. D'ailleurs, avoir des statistiques temporelles donne déjà beaucoup d'informations. J'avais lu une anecdote, je ne sais plus où : juste en surveillant le nombre de commandes de pizza à livrer au Pentagone, aux alentours d'un certain 11 septembre, on pouvait se douter qu'il se passait quelque chose. Quant à savoir quoi, il faudrait savoir lire dans la pizza ;-)
Dominique Blas
[...]
Et ? Un mec qui lit son mail en clair toute la journée sur Hotmail, c'est typiquement ce type de cas. Un gars qui passe sa vie sur Google, Le Monde Freshmeat ou Slashdot aussi. Ce sont des sites connus dont il est simple de détecter le contenu et de supprimer des logs, mais le forum des collectionneurs de boutons dorés d'autoradio des années 70 le sera probablement un peu moins.
Les serveurs utilisés en tant que relais n'affichent pas une jolie page pleine de boutons tout de même lorsqu'on leur soumet l'URL relais, si ?
[...]
La durée n'a aucune valeur en HTTP, même si on a le keep-alive de HTTP/1.1.
Je parlais de durée cumulée (sur une semaine par exemple).
db
--
Courriel : usenet blas net
[...]
Et ? Un mec qui lit son mail en clair toute la journée sur Hotmail, c'est
typiquement ce type de cas. Un gars qui passe sa vie sur Google, Le Monde
Freshmeat ou Slashdot aussi. Ce sont des sites connus dont il est simple
de détecter le contenu et de supprimer des logs, mais le forum des
collectionneurs de boutons dorés d'autoradio des années 70 le sera
probablement un peu moins.
Les serveurs utilisés en tant que relais n'affichent pas une jolie page
pleine de boutons tout de même lorsqu'on leur soumet l'URL relais, si ?
[...]
La durée n'a aucune valeur en HTTP, même si on a le keep-alive de
HTTP/1.1.
Je parlais de durée cumulée (sur une semaine par exemple).
Et ? Un mec qui lit son mail en clair toute la journée sur Hotmail, c'est typiquement ce type de cas. Un gars qui passe sa vie sur Google, Le Monde Freshmeat ou Slashdot aussi. Ce sont des sites connus dont il est simple de détecter le contenu et de supprimer des logs, mais le forum des collectionneurs de boutons dorés d'autoradio des années 70 le sera probablement un peu moins.
Les serveurs utilisés en tant que relais n'affichent pas une jolie page pleine de boutons tout de même lorsqu'on leur soumet l'URL relais, si ?
[...]
La durée n'a aucune valeur en HTTP, même si on a le keep-alive de HTTP/1.1.
Je parlais de durée cumulée (sur une semaine par exemple).
db
--
Courriel : usenet blas net
Cedric Blancher
Le Wed, 22 Jun 2005 08:16:58 +0000, Erwan David a écrit :
Et encore, difficile de faire la différence entre un tunnel et unsite web en streaming...
Pas tant que ça en fait.
Le tunnel est packet based alors que le streaming est plus stream based. Un tunnel, c'est pleins de GET et de POST à répétition, alors que le stream est un gros GET qui dure, mais sans rien dans l'autre sens.
De plus, la modélisation du comportement humain, comme la durée entre deux chargement de page permet rapidement de différencier un surf d'un outil automatique. On arrive fort bien à faire la différence entre un humain et un spider par exemple. Et un tunnel montre un comportement d'une part automatique (régularité du comportement) et d'autre part pas cohérent avec une activité de surf (rafales vs. comportement continu).
L'analyse comportementale, même simple, donne des résultats impressionnants si on ne se trompe pas de critères.
-- <html><p>Comme promis, un petit mail pour te rappeler de m'envoyer les fichiers de configuration du modem. <p>En plus t'a mon mail pro, si jamais t'a un truc urgent ( je consulte pas wanadoo tous les jours). -+- YD in Guide du linuxien pervers - "Toujours bien tenir ses promesses"
Le Wed, 22 Jun 2005 08:16:58 +0000, Erwan David a écrit :
Et encore, difficile de faire la différence entre un tunnel et unsite
web en streaming...
Pas tant que ça en fait.
Le tunnel est packet based alors que le streaming est plus stream based.
Un tunnel, c'est pleins de GET et de POST à répétition, alors que le
stream est un gros GET qui dure, mais sans rien dans l'autre sens.
De plus, la modélisation du comportement humain, comme la durée entre
deux chargement de page permet rapidement de différencier un surf d'un
outil automatique. On arrive fort bien à faire la différence entre un
humain et un spider par exemple. Et un tunnel montre un comportement d'une
part automatique (régularité du comportement) et d'autre part pas
cohérent avec une activité de surf (rafales vs. comportement continu).
L'analyse comportementale, même simple, donne des résultats
impressionnants si on ne se trompe pas de critères.
--
<html><p>Comme promis, un petit mail pour te rappeler de m'envoyer les
fichiers de configuration du modem. <p>En plus t'a mon mail pro,
si jamais t'a un truc urgent ( je consulte pas wanadoo tous les jours).
-+- YD in Guide du linuxien pervers - "Toujours bien tenir ses promesses"
Le Wed, 22 Jun 2005 08:16:58 +0000, Erwan David a écrit :
Et encore, difficile de faire la différence entre un tunnel et unsite web en streaming...
Pas tant que ça en fait.
Le tunnel est packet based alors que le streaming est plus stream based. Un tunnel, c'est pleins de GET et de POST à répétition, alors que le stream est un gros GET qui dure, mais sans rien dans l'autre sens.
De plus, la modélisation du comportement humain, comme la durée entre deux chargement de page permet rapidement de différencier un surf d'un outil automatique. On arrive fort bien à faire la différence entre un humain et un spider par exemple. Et un tunnel montre un comportement d'une part automatique (régularité du comportement) et d'autre part pas cohérent avec une activité de surf (rafales vs. comportement continu).
L'analyse comportementale, même simple, donne des résultats impressionnants si on ne se trompe pas de critères.
-- <html><p>Comme promis, un petit mail pour te rappeler de m'envoyer les fichiers de configuration du modem. <p>En plus t'a mon mail pro, si jamais t'a un truc urgent ( je consulte pas wanadoo tous les jours). -+- YD in Guide du linuxien pervers - "Toujours bien tenir ses promesses"
Cedric Blancher
Le Wed, 22 Jun 2005 15:30:37 +0000, Erwan David a écrit :
Ah oui, mais moi je pensais à faire passer ça en HTTPS. Donc là on a dans les 2 cas un CONNECT qui dure...
OK, j'en étais resté à HTTPtunnel.
Mais c'est vrai que le tunnel verra plus de données partir vers l'extérieur que le stream.
Tout à fait. De plus, si tu fais une étude dans le temps, tu vois que la répartition des échanges n'est pas du tout la même entre une utilisation "normale" et un tunnel, aussi bien en terme d'espacement, de sens que de volume. Une utilisation normale, c'est des bursts réguliers en download à chaque fois que le gars clique, puis des temps de pause, le temps qu'il lise la page et trouve le prochain lien. Un tunnel a un comportement nettement plus régulier que cela et implique souvent plus d'upload.
Ça serait rigolo de concevoir un modèle d'outil qui permettrait d'obtenir un tunnel qui communiquerait avec un comportement d'utilisateur, en utilisant des systèmes de buckets pour le déclenchement des échanges par exemple.
-- BOFH excuse #233:
TCP/IP UDP alarm threshold is set too low.
Le Wed, 22 Jun 2005 15:30:37 +0000, Erwan David a écrit :
Ah oui, mais moi je pensais à faire passer ça en HTTPS. Donc là on a
dans les 2 cas un CONNECT qui dure...
OK, j'en étais resté à HTTPtunnel.
Mais c'est vrai que le tunnel verra plus de données partir vers
l'extérieur que le stream.
Tout à fait.
De plus, si tu fais une étude dans le temps, tu vois que la répartition
des échanges n'est pas du tout la même entre une utilisation "normale"
et un tunnel, aussi bien en terme d'espacement, de sens que de volume. Une
utilisation normale, c'est des bursts réguliers en download à chaque
fois que le gars clique, puis des temps de pause, le temps qu'il lise la
page et trouve le prochain lien. Un tunnel a un comportement nettement
plus régulier que cela et implique souvent plus d'upload.
Ça serait rigolo de concevoir un modèle d'outil qui permettrait
d'obtenir un tunnel qui communiquerait avec un comportement d'utilisateur,
en utilisant des systèmes de buckets pour le déclenchement des échanges
par exemple.
Le Wed, 22 Jun 2005 15:30:37 +0000, Erwan David a écrit :
Ah oui, mais moi je pensais à faire passer ça en HTTPS. Donc là on a dans les 2 cas un CONNECT qui dure...
OK, j'en étais resté à HTTPtunnel.
Mais c'est vrai que le tunnel verra plus de données partir vers l'extérieur que le stream.
Tout à fait. De plus, si tu fais une étude dans le temps, tu vois que la répartition des échanges n'est pas du tout la même entre une utilisation "normale" et un tunnel, aussi bien en terme d'espacement, de sens que de volume. Une utilisation normale, c'est des bursts réguliers en download à chaque fois que le gars clique, puis des temps de pause, le temps qu'il lise la page et trouve le prochain lien. Un tunnel a un comportement nettement plus régulier que cela et implique souvent plus d'upload.
Ça serait rigolo de concevoir un modèle d'outil qui permettrait d'obtenir un tunnel qui communiquerait avec un comportement d'utilisateur, en utilisant des systèmes de buckets pour le déclenchement des échanges par exemple.
