[Résolu]Réseau Local

[ndietrich]

Salut,


Je me permets de faire un post assez gros pour cette fois....

Je voudrais juste faire une petite précision sur ces attaques dites par spoofing, c'est un sujet assez mal compris en général.

Le spoofing d'IP consiste à communiquer avec une machine distante en lui faisant croire que nous sommes quelqu'un d'autre.

Ca revient à envoyer des packets (TCP, UDP) avec une adresse IP source différente de notre vraie addresse, ce qui peut être fait en construisant manuellement ses packet avec des Raw Sockets.

Le gros problème de ces attaques est qu'elles sont toutes des "blind attacks", des attaques aveugles.
Cela vient tout simplement du fait que une fois ces packets envoyés avec une IP source modifiée, la destination va dans la plupart des cas essayer de répondre à la machine source, ce qui est impossible, il va envoyer sa réponse à une autre machine (celle qui détient vraimenent l'IP spoofée).

Prenons le cas des communications TCP. Une communication TCP est un "hand shake" entre deux machines, qui fonctionne comme suit:
1/ La source envoie un packet SYN (ouverture de connexion)
2/ La destination répond avec un packet SYN/ACK (OK pour l'ouverture de cette connexion)
3/ La source renvoie alors un packet SYN pour répondre que la connexion TCP est établie

Dans le cas de spoofing TCP, imaginons 3 machines:
* REAL : vraie IP du hacker
* VICTIM : machine hackée
* FAKE : la machine identifiée par l'IP spoofée que le hacker utilise

ça veut donc dire que la communication "spoofée" est :
1/ REAL envoie un SYN à VICTIM avec comme IP source FAKE
2/ VICTIM répond à FAKE en envoyant un SYN/ACK - Le hacker espère qu'il n'y a pas de vraie machine FAKE online !!!
3/ REAL utilise un timeout au bout du quel il envoie un packet SYN toujours avec l'IP de FAKE à VICTIM pour que la connexion passe en établie

Pourquoi est-ce que le hacker espère au 2/ qu'il n'y aura pas de vraie machine FAKE online ? Parce-que si elle est online et qu'elle n'a pas fait de demande de connexion auprès de VICTIM, elle va répondre avec un NACK (Non Acknownlegment) qui va couper la communication entre REAL et VICTIM.
Donc l'attaque est rattée et REAL ne sera même pas au courant.

Donc déjà on peut voire que faire ce genre d'attaque en UDP est assez simple, mais en TCP il faut pas mal de facteurs concordants pour que ça fonctionne.

Par contre effectivemement, l'intérêt de modifier la table de routage de destination (VICTIM) est d'être sûr qu'une machine spécifique ne sera jamais joignable (FAKE) et donc que REAL pourra continuer à se faire passer pour elle.

Donc effectivement dans certaines attaques par spoofing, on peut voir sur la machine victime une table de routage avec des entrées anormales, qui sont là pour interdire la communication avec une certaine machine.

Par contre, quand sébastien du dis:

grâce à cette table de routage modifiée, se fasse passer pour une machine de notre réseau local, ayant une adresse de type 192.168.254.xxx

Non, pas vraiment. Si tu as un firewall en amont de ton réseau, il fera (entre autres) du filtrage de packets.

Le filtrage de packets fonctionne pas "flux".
Un flux est une sorte de "vecteur" identifié par 5 choses, et appliqué à un adaptateur (carte réseau):
* IP Source
* Port Source
* IP Destination
* Port Destination
* Direction

Donc même si ton firewall voit passer une requete venant de ton WAN avec une IP source 192.168.254.xxx, déjà le filtrage doit lui interdire car la direction n'est pas normale (WAN --> ROUTER), et en plus ton routeur ne pourra pas faire de routage entre tes 2 adaptateurs car le subnet est le même (le routage ne peut se faire que entre 2 subnets différents).

Donc définitivement ça n'est pas une attaque que tu as eu.

On peut se demander d'où viennent ces entrées, ça serait possible qu'une application modifie par code la table de routage de ton client, mais je n'y crois pas trop. Je pencherais plutot pour une config qui a été faite il y a longtemps et qui a été oubliée (par ton admin ou par toi).


Sinon pour ton pb, as tu regardé dans ta table ARP après un ping sur la machine qui ne fonctionne pas ? (arp -a)


Espérant mettre un peut de clair dans tout ça...(quel flooder ce ndietrich...)

[sebastienw]

Originally posted by Merville_ZOO@20 Apr 2004 10:17
tu arrive à pinger depuis les machines clients?

Non plus..

Je viens de connecter un nouvel ordinateur derrière de la fibre optique (convertisseur fibre cuivre + switch 100 mbits) .. injoignable également..

Aucun problème pour pinger depuis les serveurs linux, et ce, dans les deux sens,..

J'ai essayé avec un TTL de 255 (on sait jamais) et ca ne fonctionne pas non plus..

Là, je cale..

[Syrcam]

J'ai eu un cas une fois ou le switch (un 3com) etait incompatible avec la carte rezo d'un PC (un compaq).

Aurais tu le moyen de mettre un autre switch ou de voir la configuration de celui deja en place (si celui ci est administrable)...

Syrc@m.

[sebastienw]

Originally posted by ndietrich@20 Apr 2004 11:22
Salut,


Je me permets de faire un post assez gros pour cette fois....

Je voudrais juste faire une petite précision sur ces attaques dites par spoofing, c'est un sujet assez mal compris en général.

Le spoofing d'IP consiste à communiquer avec une machine distante en lui faisant croire que nous sommes quelqu'un d'autre.

Ca revient à envoyer des packets (TCP, UDP) avec une adresse IP source différente de notre vraie addresse, ce qui peut être fait en construisant manuellement ses packet avec des Raw Sockets.

Le gros problème de ces attaques est qu'elles sont toutes des "blind attacks", des attaques aveugles.
Cela vient tout simplement du fait que une fois ces packets envoyés avec une IP source modifiée, la destination va dans la plupart des cas essayer de répondre à la machine source, ce qui est impossible, il va envoyer sa réponse à une autre machine (celle qui détient vraimenent l'IP spoofée).

Prenons le cas des communications TCP. Une communication TCP est un "hand shake" entre deux machines, qui fonctionne comme suit:
1/ La source envoie un packet SYN (ouverture de connexion)
2/ La destination répond avec un packet SYN/ACK (OK pour l'ouverture de cette connexion)
3/ La source renvoie alors un packet SYN pour répondre que la connexion TCP est établie

Dans le cas de spoofing TCP, imaginons 3 machines:
* REAL : vraie IP du hacker
* VICTIM : machine hackée
* FAKE : la machine identifiée par l'IP spoofée que le hacker utilise

ça veut donc dire que la communication "spoofée" est :
1/ REAL envoie un SYN à VICTIM avec comme IP source FAKE
2/ VICTIM répond à FAKE en envoyant un SYN/ACK - Le hacker espère qu'il n'y a pas de vraie machine FAKE online !!!
3/ REAL utilise un timeout au bout du quel il envoie un packet SYN toujours avec l'IP de FAKE à VICTIM pour que la connexion passe en établie

Pourquoi est-ce que le hacker espère au 2/ qu'il n'y aura pas de vraie machine FAKE online ? Parce-que si elle est online et qu'elle n'a pas fait de demande de connexion auprès de VICTIM, elle va répondre avec un NACK (Non Acknownlegment) qui va couper la communication entre REAL et VICTIM.
Donc l'attaque est rattée et REAL ne sera même pas au courant.

Donc déjà on peut voire que faire ce genre d'attaque en UDP est assez simple, mais en TCP il faut pas mal de facteurs concordants pour que ça fonctionne.

Par contre effectivemement, l'intérêt de modifier la table de routage de destination (VICTIM) est d'être sûr qu'une machine spécifique ne sera jamais joignable (FAKE) et donc que REAL pourra continuer à se faire passer pour elle.

Donc effectivement dans certaines attaques par spoofing, on peut voir sur la machine victime une table de routage avec des entrées anormales, qui sont là pour interdire la communication avec une certaine machine.

Par contre, quand sébastien du dis:

Non, pas vraiment. Si tu as un firewall en amont de ton réseau, il fera (entre autres) du filtrage de packets.

Le filtrage de packets fonctionne pas "flux".
Un flux est une sorte de "vecteur" identifié par 5 choses, et appliqué à un adaptateur (carte réseau):
* IP Source
* Port Source
* IP Destination
* Port Destination
* Direction

Donc même si ton firewall voit passer une requete venant de ton WAN avec une IP source 192.168.254.xxx, déjà le filtrage doit lui interdire car la direction n'est pas normale (WAN --> ROUTER), et en plus ton routeur ne pourra pas faire de routage entre tes 2 adaptateurs car le subnet est le même (le routage ne peut se faire que entre 2 subnets différents).

Donc définitivement ça n'est pas une attaque que tu as eu.

On peut se demander d'où viennent ces entrées, ça serait possible qu'une application modifie par code la table de routage de ton client, mais je n'y crois pas trop. Je pencherais plutot pour une config qui a été faite il y a longtemps et qui a été oubliée (par ton admin ou par toi).


Sinon pour ton pb, as tu regardé dans ta table ARP après un ping sur la machine qui ne fonctionne pas ? (arp -a)


Espérant mettre un peut de clair dans tout ça...(quel flooder ce ndietrich...)

Tout d'abord un grand merci pour la réponse qui m'éclaire sur certains points (je ne connaissais rien de l'IP spoofing hier encore) et surtout, du temps consacré à tout expliquer.

Je me doute bien que ce type d'attaque doit avoir un taux de succès très limité vu tous les paramètres en jeu.

Par contre, de ce que j'ai retrouvé sur le net traitant de ce sujet, il est possible parait-il de spoofer une IP d'une machine qui est online !! Sauf qu'il faut flooder la machine pendant la durée de l'attaque.. Wééé les deux doigts dans le nez ça !!

Je me doutais aussi également que notre routeur (un flowpoint) doit être assez rigide dans le filtrage.. à vérifier quand même.

Pour ce qui est de la configuration du portable, c'est un nouveau Acer 1703 que j'ai immédiatement reformaté et installé "à ma manière", donc aucun paramètre d'usine n'y réside. De plus, je suis la seule personne à y avoir accès..

Encore merci !
Seb

[sebastienw]

Originally posted by Syrcam@20 Apr 2004 11:32
J'ai eu un cas une fois ou le switch (un 3com) etait incompatible avec la carte rezo d'un PC (un compaq).

Aurais tu le moyen de mettre un autre switch ou de voir la configuration de celui deja en place (si celui ci est administrable)...

Syrc@m.

Je teste et te tiens au courant,
Merci !

[sebastienw]

Bon, je suis actuellement dans le local où se trouve l'armoire principale avec le routeur, les switches et les convertisseurs FO cuivre.

Si je patch mon portable sur le switch 3com sur le port 8, ca fonctionne !!
Sur le port 7, ca ne fonctionne pas, sur le port 9 non plus.. C'est tout ce qui me reste de libre, donc je teste pas sur les autres.

Le problème est que ce switch est administrable, sauf que 3COM fait toujours à part des autres, donc je n'ai pas encore le câble RS-232 femelle-femelle pour y appliquer une IP et ouvrir le port telnet. Donc je ne sais pas voir ce qu'il se passe au niveau configuration des ports de ce switch là.

Il s'agit donc apparemment, comme syrcam l'a supposé, d'un problème de compatibilté hardware.. Le switch 3COM ayant toujours les paramètres d'usine.

Bon allez, je retourne dans mon bureau, c'est pas très confortable ici..

Un grand merci à tous les intervenants.
Seb

[Syrcam]

Ouaaaaahhh !

I am zi best of the world ! lol

Bon courage pour la configuration du 3com...

(en fait j'ai jamais essayé parceque je m'etait pas pris la tete : j'avais un autre switch a disposition donc je l'avais mis devant lol)

Syrc@m.

[ndietrich]

Content que ça marche

[sebastienw]

J'ai mis une carte réseau 3COM PCMCIA dans le portable, tout patché comme avant, et strictement aucun problème !

Carte réseau interne au Acer 1703SM apparemment de mauvaise qualité (à base de SiS 900, rien de tel que du 3COM), peut-être qu'une mise à jour des drivers règlera le problème..

Ceci explique celà, le prix démocratique des portables Acer se ressent dans les composants utilisés.

Reste le problème de la table de routage.. cela restera un grand mystère

Merci encore !
Seb

[sebastienw]

ENCORE MOI !

Mise à jour des drivers de la carte réseau interne SiS 900

Tout marche nickel... Piouf...