Le Sun, 12 Jun 2005 09:59:55 +0000, LKSD a écrit :
Je voudrais savoir comment detecter tout ce qui est flux tunnelises bidon ?
C'est difficile. Il faut souvent passer par de spécificités comportementales. Par exemple, les connexions HTTP sont majoritairement courtes, multiples et de volume faible, alors qu'un tunnel implique une connexion unique, longue avec un volume conséquent. La répartition de ce volume dans le temps est en outre complètement différente.
Exemple : mes utilisateurs qui font passer n'importe quoi sur le port 80 de mon firewall alors que ca devrait etre que de l'acces Web ?
Mettre un proxy HTTP qui les obligera à tunneliser dans du HTTP sera déjà un pas. Limiter la durée des connexions risque de les gêner un peu aussi. Mais il ne faut pas rêver, il n'y a pas de solution miracle...
-- BOFH excuse #291:
Due to the CDA, we no longer have a root account.
Le Sun, 12 Jun 2005 09:59:55 +0000, LKSD a écrit :
Je voudrais savoir comment detecter tout ce qui est flux tunnelises bidon ?
C'est difficile. Il faut souvent passer par de spécificités
comportementales. Par exemple, les connexions HTTP sont majoritairement
courtes, multiples et de volume faible, alors qu'un tunnel implique une
connexion unique, longue avec un volume conséquent. La répartition de ce
volume dans le temps est en outre complètement différente.
Exemple : mes utilisateurs qui font passer n'importe quoi sur le port 80
de mon firewall alors que ca devrait etre que de l'acces Web ?
Mettre un proxy HTTP qui les obligera à tunneliser dans du HTTP sera
déjà un pas. Limiter la durée des connexions risque de les gêner un
peu aussi.
Mais il ne faut pas rêver, il n'y a pas de solution miracle...
Le Sun, 12 Jun 2005 09:59:55 +0000, LKSD a écrit :
Je voudrais savoir comment detecter tout ce qui est flux tunnelises bidon ?
C'est difficile. Il faut souvent passer par de spécificités comportementales. Par exemple, les connexions HTTP sont majoritairement courtes, multiples et de volume faible, alors qu'un tunnel implique une connexion unique, longue avec un volume conséquent. La répartition de ce volume dans le temps est en outre complètement différente.
Exemple : mes utilisateurs qui font passer n'importe quoi sur le port 80 de mon firewall alors que ca devrait etre que de l'acces Web ?
Mettre un proxy HTTP qui les obligera à tunneliser dans du HTTP sera déjà un pas. Limiter la durée des connexions risque de les gêner un peu aussi. Mais il ne faut pas rêver, il n'y a pas de solution miracle...
-- BOFH excuse #291:
Due to the CDA, we no longer have a root account.
Sylvain Eche
Oui
contrairement au tunnel SSL fait en connect sur le port 443 ou tu peux t'en sortir en white listant déja le port 443 et également les sites HTTPS.
Pour le tunnel HTTP j'ai un peu regardé la gueule des requête HTTPORT et ben bonjour pour détecter ca ! ca ressemble vraiment à du HTTP normal. l'approche comportementale semble la seule solution un papier sur le sujet pour creuser : http://www.ll.mit.edu/IST/pubs/Pack-IEEE2002.pdf
tu peux tenter detect http tunnel sous google aussi
Mais bon si t'arrive a détecter ces tunnels HTTP, il vont te faire des tunnels DNS !!
C'est pas simple tout ça heureusement que l'utilisateur Lambda n'a pas souvent les connaissances nécessaires pour faire ce genre de chose.
Je voudrais savoir comment detecter tout ce qui est flux tunnelises bidon ?
C'est difficile. Il faut souvent passer par de spécificités comportementales. Par exemple, les connexions HTTP sont majoritairement courtes, multiples et de volume faible, alors qu'un tunnel implique une connexion unique, longue avec un volume conséquent. La répartition de ce volume dans le temps est en outre complètement différente.
Exemple : mes utilisateurs qui font passer n'importe quoi sur le port 80 de mon firewall alors que ca devrait etre que de l'acces Web ?
Mettre un proxy HTTP qui les obligera à tunneliser dans du HTTP sera déjà un pas. Limiter la durée des connexions risque de les gêner un peu aussi. Mais il ne faut pas rêver, il n'y a pas de solution miracle...
Oui
contrairement au tunnel SSL fait en connect sur le port 443 ou tu peux
t'en sortir en white listant déja le port 443 et également les sites HTTPS.
Pour le tunnel HTTP j'ai un peu regardé la gueule des requête HTTPORT et
ben bonjour pour détecter ca ! ca ressemble vraiment à du HTTP normal.
l'approche comportementale semble la seule solution
un papier sur le sujet pour creuser :
http://www.ll.mit.edu/IST/pubs/Pack-IEEE2002.pdf
tu peux tenter detect http tunnel sous google aussi
Mais bon si t'arrive a détecter ces tunnels HTTP, il vont te faire des
tunnels DNS !!
C'est pas simple tout ça heureusement que l'utilisateur Lambda n'a pas
souvent les connaissances nécessaires pour faire ce genre de chose.
Je voudrais savoir comment detecter tout ce qui est flux tunnelises bidon ?
C'est difficile. Il faut souvent passer par de spécificités
comportementales. Par exemple, les connexions HTTP sont majoritairement
courtes, multiples et de volume faible, alors qu'un tunnel implique une
connexion unique, longue avec un volume conséquent. La répartition de ce
volume dans le temps est en outre complètement différente.
Exemple : mes utilisateurs qui font passer n'importe quoi sur le port 80
de mon firewall alors que ca devrait etre que de l'acces Web ?
Mettre un proxy HTTP qui les obligera à tunneliser dans du HTTP sera
déjà un pas. Limiter la durée des connexions risque de les gêner un
peu aussi.
Mais il ne faut pas rêver, il n'y a pas de solution miracle...
contrairement au tunnel SSL fait en connect sur le port 443 ou tu peux t'en sortir en white listant déja le port 443 et également les sites HTTPS.
Pour le tunnel HTTP j'ai un peu regardé la gueule des requête HTTPORT et ben bonjour pour détecter ca ! ca ressemble vraiment à du HTTP normal. l'approche comportementale semble la seule solution un papier sur le sujet pour creuser : http://www.ll.mit.edu/IST/pubs/Pack-IEEE2002.pdf
tu peux tenter detect http tunnel sous google aussi
Mais bon si t'arrive a détecter ces tunnels HTTP, il vont te faire des tunnels DNS !!
C'est pas simple tout ça heureusement que l'utilisateur Lambda n'a pas souvent les connaissances nécessaires pour faire ce genre de chose.
Je voudrais savoir comment detecter tout ce qui est flux tunnelises bidon ?
C'est difficile. Il faut souvent passer par de spécificités comportementales. Par exemple, les connexions HTTP sont majoritairement courtes, multiples et de volume faible, alors qu'un tunnel implique une connexion unique, longue avec un volume conséquent. La répartition de ce volume dans le temps est en outre complètement différente.
Exemple : mes utilisateurs qui font passer n'importe quoi sur le port 80 de mon firewall alors que ca devrait etre que de l'acces Web ?
Mettre un proxy HTTP qui les obligera à tunneliser dans du HTTP sera déjà un pas. Limiter la durée des connexions risque de les gêner un peu aussi. Mais il ne faut pas rêver, il n'y a pas de solution miracle...
Eric Razny
Le Mon, 13 Jun 2005 08:54:24 +0000, Sylvain Eche a écrit :
Mais bon si t'arrive a détecter ces tunnels HTTP, il vont te faire des tunnels DNS !!
Amha celui la c'est simple. Pour lui tordre le cou :
- méthode "propre" : un proxy DNS avec redirection des flux vers le proxy si necéssaire.
- méthode "bourrin" : on filtre 53/TCP et 53/UDP et on drop si ça ne va pas sur les serveurs DNS choisis.
Il reste certes une dernière méthode de tunneling DNS : la requète spécieuse, avec le correspondant qui possède son DNS qui sera donc interrogé in fine. Ca ne laisse fuir que peu d'information (en entrée ça peut être plus conséquent) mais dans le cas d'un surf relativement libre (ie pas uniquement vers des domaines/IP choisis) je vois mal comment ce serait parable.
C'est pas simple tout ça heureusement que l'utilisateur Lambda n'a pas souvent les connaissances nécessaires pour faire ce genre de chose.
Mouais, enfin pour le Beta il suffit d'un peu de recherche sur un moteur quelconque :)
Eric
Le Mon, 13 Jun 2005 08:54:24 +0000, Sylvain Eche a écrit :
Mais bon si t'arrive a détecter ces tunnels HTTP, il vont te faire des
tunnels DNS !!
Amha celui la c'est simple. Pour lui tordre le cou :
- méthode "propre" : un proxy DNS avec redirection des flux vers le
proxy si necéssaire.
- méthode "bourrin" : on filtre 53/TCP et 53/UDP et on drop si ça ne va
pas sur les serveurs DNS choisis.
Il reste certes une dernière méthode de tunneling DNS : la requète
spécieuse, avec le correspondant qui possède son DNS qui sera donc
interrogé in fine. Ca ne laisse fuir que peu d'information (en entrée
ça peut être plus conséquent) mais dans le cas d'un surf relativement
libre (ie pas uniquement vers des domaines/IP choisis) je vois mal comment
ce serait parable.
C'est pas simple tout ça heureusement que l'utilisateur Lambda n'a pas
souvent les connaissances nécessaires pour faire ce genre de chose.
Mouais, enfin pour le Beta il suffit d'un peu de recherche sur un moteur
quelconque :)
Le Mon, 13 Jun 2005 08:54:24 +0000, Sylvain Eche a écrit :
Mais bon si t'arrive a détecter ces tunnels HTTP, il vont te faire des tunnels DNS !!
Amha celui la c'est simple. Pour lui tordre le cou :
- méthode "propre" : un proxy DNS avec redirection des flux vers le proxy si necéssaire.
- méthode "bourrin" : on filtre 53/TCP et 53/UDP et on drop si ça ne va pas sur les serveurs DNS choisis.
Il reste certes une dernière méthode de tunneling DNS : la requète spécieuse, avec le correspondant qui possède son DNS qui sera donc interrogé in fine. Ca ne laisse fuir que peu d'information (en entrée ça peut être plus conséquent) mais dans le cas d'un surf relativement libre (ie pas uniquement vers des domaines/IP choisis) je vois mal comment ce serait parable.
C'est pas simple tout ça heureusement que l'utilisateur Lambda n'a pas souvent les connaissances nécessaires pour faire ce genre de chose.
Mouais, enfin pour le Beta il suffit d'un peu de recherche sur un moteur quelconque :)
Eric
Cedric Blancher
Le Mon, 13 Jun 2005 10:48:29 +0000, Eric Razny a écrit :
- méthode "propre" : un proxy DNS avec redirection des flux vers le proxy si necéssaire. - méthode "bourrin" : on filtre 53/TCP et 53/UDP et on drop si ça ne va pas sur les serveurs DNS choisis.
Oui, mais là tu ne fais pas face à un tunnel, juste à un gars qui essaye de faire passer un flux à travers UDP/53 ou TCP/53.
Il reste certes une dernière méthode de tunneling DNS : la requète spécieuse, avec le correspondant qui possède son DNS qui : sera donc interrogé in fine. Ca ne laisse fuir que peu d'information (en entrée ça peut être plus conséquent) mais dans le cas d'un surf relativement libre (ie pas uniquement vers des domaines/IP choisis) je vois mal comment ce serait parable.
Peu d'information ? Avec un outil comme nstx, tu fais un tunnel IP over DNS sans problème. C'est juste un lent.
-- Un inconnu du nom de Mailer-Daemon reçoit mes mails. Comment cela est possible ? Comment l'eviter. Répondre très rapidement, car mon mois d'essai se termine ce soir, et je suis très inquiete de ce piratage ? -+- Exorcisme dans le GNU - Satan l'habite, son bit l'attend -+-
Le Mon, 13 Jun 2005 10:48:29 +0000, Eric Razny a écrit :
- méthode "propre" : un proxy DNS avec redirection des flux vers le
proxy si necéssaire.
- méthode "bourrin" : on filtre 53/TCP et 53/UDP et on drop si ça ne
va pas sur les serveurs DNS choisis.
Oui, mais là tu ne fais pas face à un tunnel, juste à un gars qui
essaye de faire passer un flux à travers UDP/53 ou TCP/53.
Il reste certes une dernière méthode de tunneling DNS : la requète
spécieuse, avec le correspondant qui possède son DNS qui : sera donc
interrogé in fine. Ca ne laisse fuir que peu d'information (en entrée
ça peut être plus conséquent) mais dans le cas d'un surf relativement
libre (ie pas uniquement vers des domaines/IP choisis) je vois mal
comment ce serait parable.
Peu d'information ? Avec un outil comme nstx, tu fais un tunnel IP over
DNS sans problème. C'est juste un lent.
--
Un inconnu du nom de Mailer-Daemon reçoit mes mails. Comment cela est
possible ? Comment l'eviter. Répondre très rapidement, car mon mois
d'essai se termine ce soir, et je suis très inquiete de ce piratage ?
-+- Exorcisme dans le GNU - Satan l'habite, son bit l'attend -+-
Le Mon, 13 Jun 2005 10:48:29 +0000, Eric Razny a écrit :
- méthode "propre" : un proxy DNS avec redirection des flux vers le proxy si necéssaire. - méthode "bourrin" : on filtre 53/TCP et 53/UDP et on drop si ça ne va pas sur les serveurs DNS choisis.
Oui, mais là tu ne fais pas face à un tunnel, juste à un gars qui essaye de faire passer un flux à travers UDP/53 ou TCP/53.
Il reste certes une dernière méthode de tunneling DNS : la requète spécieuse, avec le correspondant qui possède son DNS qui : sera donc interrogé in fine. Ca ne laisse fuir que peu d'information (en entrée ça peut être plus conséquent) mais dans le cas d'un surf relativement libre (ie pas uniquement vers des domaines/IP choisis) je vois mal comment ce serait parable.
Peu d'information ? Avec un outil comme nstx, tu fais un tunnel IP over DNS sans problème. C'est juste un lent.
-- Un inconnu du nom de Mailer-Daemon reçoit mes mails. Comment cela est possible ? Comment l'eviter. Répondre très rapidement, car mon mois d'essai se termine ce soir, et je suis très inquiete de ce piratage ? -+- Exorcisme dans le GNU - Satan l'habite, son bit l'attend -+-
Franck Yvonnet
Ainsi Parlait Eric Razny
Il reste certes une dernière méthode de tunneling DNS : la requète spécieuse, avec le correspondant qui possède son DNS qui sera donc interrogé in fine. Ca ne laisse fuir que peu d'information (en entrée ça peut être plus conséquent) mais dans le cas d'un surf relativement libre (ie pas uniquement vers des domaines/IP choisis) je vois mal comment ce serait parable.
Tu fais des statistiques de requetes DNS par adresse interne. Ceux qui dépassent une certaine limite gagnent un LARTage en rêgle.
-- Franck Yvonnet I remember when trolls were fairy tale creatures who lived under bridges. Now homeless people live there and trolls live on Usenet.
Ainsi Parlait Eric Razny <news_01@razny.net>
Il reste certes une dernière méthode de tunneling DNS : la requète
spécieuse, avec le correspondant qui possède son DNS qui sera donc
interrogé in fine. Ca ne laisse fuir que peu d'information (en entrée
ça peut être plus conséquent) mais dans le cas d'un surf relativement
libre (ie pas uniquement vers des domaines/IP choisis) je vois mal comment
ce serait parable.
Tu fais des statistiques de requetes DNS par adresse interne. Ceux qui
dépassent une certaine limite gagnent un LARTage en rêgle.
--
Franck Yvonnet <fyvonnet@gmail.com>
I remember when trolls were fairy tale creatures who lived under bridges.
Now homeless people live there and trolls live on Usenet.
Il reste certes une dernière méthode de tunneling DNS : la requète spécieuse, avec le correspondant qui possède son DNS qui sera donc interrogé in fine. Ca ne laisse fuir que peu d'information (en entrée ça peut être plus conséquent) mais dans le cas d'un surf relativement libre (ie pas uniquement vers des domaines/IP choisis) je vois mal comment ce serait parable.
Tu fais des statistiques de requetes DNS par adresse interne. Ceux qui dépassent une certaine limite gagnent un LARTage en rêgle.
-- Franck Yvonnet I remember when trolls were fairy tale creatures who lived under bridges. Now homeless people live there and trolls live on Usenet.
Dominique Blas
[...]
c'est pas evident ! Merci
Dites-moi (tous les contributeurs de ce fil), que je me rafraîchisse un peu la mémoire : le tunnelling HTTP (*) passe bien par un usage éhonté de requêtes POST ou GET systèmatiquement destinées au même serveur (et provenant du même client) ?
db
(*) En HTTPS la seule parade reste la bonne vieille politique du << tout ce qui n'est pas expressément autorisé est interdit >> ce qui a pour autre effet agréable de neutraliser le phishing bancaire.
--
Courriel : usenet blas net
[...]
c'est pas evident !
Merci
Dites-moi (tous les contributeurs de ce fil), que je me rafraîchisse un
peu la mémoire : le tunnelling HTTP (*) passe bien par un usage éhonté
de requêtes POST ou GET systèmatiquement destinées au même serveur (et
provenant du même client) ?
db
(*) En HTTPS la seule parade reste la bonne vieille politique du << tout
ce qui n'est pas expressément autorisé est interdit >> ce qui a pour
autre effet agréable de neutraliser le phishing bancaire.
Dites-moi (tous les contributeurs de ce fil), que je me rafraîchisse un peu la mémoire : le tunnelling HTTP (*) passe bien par un usage éhonté de requêtes POST ou GET systèmatiquement destinées au même serveur (et provenant du même client) ?
db
(*) En HTTPS la seule parade reste la bonne vieille politique du << tout ce qui n'est pas expressément autorisé est interdit >> ce qui a pour autre effet agréable de neutraliser le phishing bancaire.
--
Courriel : usenet blas net
Cedric Blancher
Le Tue, 21 Jun 2005 14:40:21 +0000, Dominique Blas a écrit :
Dites-moi (tous les contributeurs de ce fil), que je me rafraîchisse un peu la mémoire : le tunnelling HTTP (*) passe bien par un usage éhonté de requêtes POST ou GET systèmatiquement destinées au même serveur (et provenant du même client) ?
Oui.
Mais ceci dit, HTTP repose sur un usage massif de POST et GET également :)))
-- Alors la ca dépasse l'entendemment, même clara dans sa splendeur n'était pas aussi dérangée ... A chacun de ses post j'entend la petite musique de la quatrième dimension -+- AM in GNU-SE : La dimension de l'infiniment con -+-
Le Tue, 21 Jun 2005 14:40:21 +0000, Dominique Blas a écrit :
Dites-moi (tous les contributeurs de ce fil), que je me rafraîchisse un
peu la mémoire : le tunnelling HTTP (*) passe bien par un usage éhonté
de requêtes POST ou GET systèmatiquement destinées au même serveur (et
provenant du même client) ?
Oui.
Mais ceci dit, HTTP repose sur un usage massif de POST et GET également :)))
--
Alors la ca dépasse l'entendemment, même clara dans sa splendeur
n'était pas aussi dérangée ... A chacun de ses post j'entend la
petite musique de la quatrième dimension
-+- AM in GNU-SE : La dimension de l'infiniment con -+-
Le Tue, 21 Jun 2005 14:40:21 +0000, Dominique Blas a écrit :
Dites-moi (tous les contributeurs de ce fil), que je me rafraîchisse un peu la mémoire : le tunnelling HTTP (*) passe bien par un usage éhonté de requêtes POST ou GET systèmatiquement destinées au même serveur (et provenant du même client) ?
Oui.
Mais ceci dit, HTTP repose sur un usage massif de POST et GET également :)))
-- Alors la ca dépasse l'entendemment, même clara dans sa splendeur n'était pas aussi dérangée ... A chacun de ses post j'entend la petite musique de la quatrième dimension -+- AM in GNU-SE : La dimension de l'infiniment con -+-
Khanh-Dang
le tunnelling HTTP (*) passe bien par un usage éhonté de requêtes POST ou GET systèmatiquement destinées au même serveur (et provenant du même client) ?
Oui. Mais il y a pire : du tunnelling SMTP par exemple. Je vous laisse imaginer pour ceux qui n'en ont jamais vu.
le tunnelling HTTP (*) passe bien par un usage éhonté
de requêtes POST ou GET systèmatiquement destinées au même serveur (et
provenant du même client) ?
Oui. Mais il y a pire : du tunnelling SMTP par exemple. Je vous laisse
imaginer pour ceux qui n'en ont jamais vu.
le tunnelling HTTP (*) passe bien par un usage éhonté de requêtes POST ou GET systèmatiquement destinées au même serveur (et provenant du même client) ?
Oui. Mais il y a pire : du tunnelling SMTP par exemple. Je vous laisse imaginer pour ceux qui n'en ont jamais vu.
Michel Arboi
On Tue Jun 21 2005 at 19:10, Khanh-Dang wrote:
Oui. Mais il y a pire : du tunnelling SMTP par exemple. Je vous laisse imaginer pour ceux qui n'en ont jamais vu.
Tu laisses les utilisateurs se connecter directement au SMTP "tunnel" ou ils doivent passer par le SMTP officiel (FAI, entreprise...) ?
Dans le premier cas, on peut envoyer un gros paquet de données avec DATA, et pour le retour, profiter des codes de continuation genre : 220- le début 220- la suite 220 la fin
Dans le second cas, je ne vois pas comment éviter que ça rame puissamment. Autant faire de l'IP sur pigeon voyageur :) Est-ce seulement utilisable ? J'encapsulerais plutôt des protocoles de haut niveau (passerelle SMTP -> HTTP...)
De toute façon, on pourra toujours tunneler n'importe quoi dans n'importe quoi si on n'est pas pressé. Mise à part une analyse statistique sur le trafic, je ne vois pas bien comment contrer ça de façon générique, sauf à se palucher régulièrement _toutes_ les logs, mais il faut n'avoir que ça à foutre.
Oui. Mais il y a pire : du tunnelling SMTP par exemple. Je vous laisse
imaginer pour ceux qui n'en ont jamais vu.
Tu laisses les utilisateurs se connecter directement au SMTP "tunnel"
ou ils doivent passer par le SMTP officiel (FAI, entreprise...) ?
Dans le premier cas, on peut envoyer un gros paquet de données avec
DATA, et pour le retour, profiter des codes de continuation genre :
220- le début
220- la suite
220 la fin
Dans le second cas, je ne vois pas comment éviter que ça rame
puissamment. Autant faire de l'IP sur pigeon voyageur :)
Est-ce seulement utilisable ? J'encapsulerais plutôt des protocoles de
haut niveau (passerelle SMTP -> HTTP...)
De toute façon, on pourra toujours tunneler n'importe quoi dans
n'importe quoi si on n'est pas pressé.
Mise à part une analyse statistique sur le trafic, je ne vois pas bien
comment contrer ça de façon générique, sauf à se palucher
régulièrement _toutes_ les logs, mais il faut n'avoir que ça à foutre.
Oui. Mais il y a pire : du tunnelling SMTP par exemple. Je vous laisse imaginer pour ceux qui n'en ont jamais vu.
Tu laisses les utilisateurs se connecter directement au SMTP "tunnel" ou ils doivent passer par le SMTP officiel (FAI, entreprise...) ?
Dans le premier cas, on peut envoyer un gros paquet de données avec DATA, et pour le retour, profiter des codes de continuation genre : 220- le début 220- la suite 220 la fin
Dans le second cas, je ne vois pas comment éviter que ça rame puissamment. Autant faire de l'IP sur pigeon voyageur :) Est-ce seulement utilisable ? J'encapsulerais plutôt des protocoles de haut niveau (passerelle SMTP -> HTTP...)
De toute façon, on pourra toujours tunneler n'importe quoi dans n'importe quoi si on n'est pas pressé. Mise à part une analyse statistique sur le trafic, je ne vois pas bien comment contrer ça de façon générique, sauf à se palucher régulièrement _toutes_ les logs, mais il faut n'avoir que ça à foutre.
Mais ceci dit, HTTP repose sur un usage massif de POST et GET également :)))
systèmatiquement destinées au même serveur (et provenant du même client) ? ai-je écrit.
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.
db
--
Courriel : usenet blas net
[...]
Mais ceci dit, HTTP repose sur un usage massif de POST et GET également :)))
systèmatiquement destinées au même serveur (et provenant du même client) ?
ai-je écrit.
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.
Mais ceci dit, HTTP repose sur un usage massif de POST et GET également :)))
systèmatiquement destinées au même serveur (et provenant du même client) ? ai-je écrit.
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.
