[spoofing IP?]
Fermé
djedy
Messages postés
16
Date d'inscription
jeudi 25 mai 2006
Statut
Membre
Dernière intervention
5 avril 2009
-
3 juin 2006 à 21:26
hakim350 Messages postés 5 Date d'inscription dimanche 4 avril 2010 Statut Membre Dernière intervention 18 mai 2010 - 18 mai 2010 à 21:59
hakim350 Messages postés 5 Date d'inscription dimanche 4 avril 2010 Statut Membre Dernière intervention 18 mai 2010 - 18 mai 2010 à 21:59
A voir également:
- [spoofing IP?]
- Ethernet n'a pas de configuration ip valide - Guide
- Télévision ip - Accueil - Streaming
- Comment connaître son adresse ip - Guide
- Comment savoir si quelqu'un utilise mon adresse ip - Guide
- Ip local - Guide
3 réponses
Kristopher
Messages postés
3731
Date d'inscription
vendredi 18 novembre 2005
Statut
Contributeur
Dernière intervention
10 juillet 2009
105
3 juin 2006 à 22:48
3 juin 2006 à 22:48
yo man
Réponse ici :
https://fr.wikipedia.org/wiki/IP_spoofing
Suffit de chercher sur google :)
a+
Réponse ici :
https://fr.wikipedia.org/wiki/IP_spoofing
Suffit de chercher sur google :)
a+
hakim350
Messages postés
5
Date d'inscription
dimanche 4 avril 2010
Statut
Membre
Dernière intervention
18 mai 2010
3
18 mai 2010 à 21:59
18 mai 2010 à 21:59
Les attaques par spoofing d'IP servent à accéder à des serveurs dont le système de sécurité se base sur le filtrage des adresses IP. Prenons l'exemple d'un serveur protégé par un firewall dont la règle est :
- Si adresse IP distante 80.9.65.6 alors ça passe
- Sinon ça ne passe pas
Pour accéder à ce serveur, il faut donc que votre adresse IP soit 80.9.65.6. Ou plutôt, que l'adresse indiquée dans les entêtes des paquets que vous émettez vers le serveur soit 80.9.65.6. Et c'est en ça que consiste le spoofing : modifier les paquets émis pour faire croire qu'il provienne d'un autre système, autorisé à se connecter au serveur protégé.
Mais attention, il ne faut en aucun cas croire que vous allez modifier votre IP. Vous allez simplement émettre des paquets truqués. L'adresse que votre FAI vous a attribué ne change pas.
Bon, nous allons maintenant voir comment mettre pratiquement une telle attaque sur pied.
Vous vous souvenez du schéma suivi lors d'une connexion TCP ? Non ?
Bon, le revoilà
client -----SYN----> serveur
client <--ACK/SYN--- serveur
client -----ACK----> serveur
Problématique, contournement
Admettons que vous envoyez un paquet SYN spoofé au serveur. Celui-ci va renvoyé un paquet SYN/ACK, mais en direction de la machine dont vous avez spoofé l'adresse (la machine pour laquelle vous vous faites passer). Cette dernière va donc recevoir un paquet SYN/ACK alors qu'elle n'a envoyé aucun paquet SYN. Elle va donc inévitablement re-émettre un paquet RST vers le serveur, mettant ainsi fin à la tentative de connexion.
Il est donc impossible de réaliser une attaque par spoofing dans ces conditions.
Pour parer à ce problème, il faut donc empêcher l'émission du paquet RST par la machine spoofée. Comment ? En floodant, de manière à ce que la machine ne puisse pas répondre au paquet SYN/ACK qu'elle recevra du seveur.
Vous savez que lors d'une connexion TCP, le serveur envoie un paquet SYN/ACK vers le client, et va attendre la réponse de ce dernier. Tant que le client n'a pas répondu, la connexion ne peut avoir lieu. Ce qui est intéressant, c'est que la longueur de la file d'attente des transmissions incomplètes est limitée, par ce qu'on appelle le backlog. Lorsque cette limite est atteinte, les paquets SYN suivants reçus par le serveur seront ignorés.
Vous voyez le rapport avec notre problème ? Il suffira de flooder la machine spoofée avec des requêtes SYN. Ainsi, elle ne répondra pas au paquet SYN/ACK envoyé par le serveur. Ce flood doit se faire avec des paquets dont l'adresse source est inexistante.
Mais un nouveau problème se pose. En effet, l'attaquant est totalement aveugle pendant ces manipulations, puisque le serveur ne renvoie rien vers sa machine, mais tout vers la machine spoofée.
Pour éviter cela, il va falloir utiliser le "source routing". Cette option, spécifiée dans le champ "option" de l'entête IP, permet de faire passer la réponse à un paquet par un chemin spécifique. Ainsi, il est possible de faire en sorte que les paquets émis par le serveur vers la machine spoofée passe par votre machine. Avec un sniffer, vous aurez donc accès aux trames échangées. Vous n'êtes donc plus aveugle. Tout est donc reglé.
Eh bien non ! Qu'est-ce qui ne va encore pas ?
C'est simple. Vous savez que pour établir une connexion TCP, des paquets spécifiques sont échangés. Ils utilisent entre autres des numéros de séquence, pour vérifier l'établissement d'une connexion correcte.
Un rappel du fonctionnement de ces numéros ? Bon, d'accord :
* Le client envoie un paquet SYN, avec un numéro de séquence x. Ce numéro, codé sur 32bits, correspond à l'ISN (Numéro Initial de Séquence) choisit pas la machine client pour l'établissement de la connexion.
* Le serveur répond en envoyant un paquet SYN/ACK. Pour ce paquet, le numéro d'acquitement (Acknowledgment number, à ne pas confondre avec le flag ACK associé) a pour valeur x+1, et le numéro de séquence a pour valeur l'ISN choisi par le serveur pour la connexion, y.
* Enfin, le client renvoie un paquet ACK, avec son numéro d'acquittement à y+1, et son numéro de séquence à x+1.
Pour réussir à établir la connexion avec le serveur, vous devrez donc connaître l'ISN choisit par ce dernier. Aujourd'hui, les systèmes informatiques sont équipés de générateurs de nombres aléatoires puissants, ce qui peut vous compliquer considérablement la tâche. Une erreur dans ce numéro peut avoir différentes conséquences :
* Si le numéro est inférieur au numéro d'ACK attendu, le paquet est supprimé ;
* S'il est légérement supérieur, le paquet est mis en attente ;
* Et s'il est trop supérieur, le paquet est également supprimé ;
Il faudra donc recourir, lorsque c'est possible, au source routing de manière à identifier ce numéro.
- Si adresse IP distante 80.9.65.6 alors ça passe
- Sinon ça ne passe pas
Pour accéder à ce serveur, il faut donc que votre adresse IP soit 80.9.65.6. Ou plutôt, que l'adresse indiquée dans les entêtes des paquets que vous émettez vers le serveur soit 80.9.65.6. Et c'est en ça que consiste le spoofing : modifier les paquets émis pour faire croire qu'il provienne d'un autre système, autorisé à se connecter au serveur protégé.
Mais attention, il ne faut en aucun cas croire que vous allez modifier votre IP. Vous allez simplement émettre des paquets truqués. L'adresse que votre FAI vous a attribué ne change pas.
Bon, nous allons maintenant voir comment mettre pratiquement une telle attaque sur pied.
Vous vous souvenez du schéma suivi lors d'une connexion TCP ? Non ?
Bon, le revoilà
client -----SYN----> serveur
client <--ACK/SYN--- serveur
client -----ACK----> serveur
Problématique, contournement
Admettons que vous envoyez un paquet SYN spoofé au serveur. Celui-ci va renvoyé un paquet SYN/ACK, mais en direction de la machine dont vous avez spoofé l'adresse (la machine pour laquelle vous vous faites passer). Cette dernière va donc recevoir un paquet SYN/ACK alors qu'elle n'a envoyé aucun paquet SYN. Elle va donc inévitablement re-émettre un paquet RST vers le serveur, mettant ainsi fin à la tentative de connexion.
Il est donc impossible de réaliser une attaque par spoofing dans ces conditions.
Pour parer à ce problème, il faut donc empêcher l'émission du paquet RST par la machine spoofée. Comment ? En floodant, de manière à ce que la machine ne puisse pas répondre au paquet SYN/ACK qu'elle recevra du seveur.
Vous savez que lors d'une connexion TCP, le serveur envoie un paquet SYN/ACK vers le client, et va attendre la réponse de ce dernier. Tant que le client n'a pas répondu, la connexion ne peut avoir lieu. Ce qui est intéressant, c'est que la longueur de la file d'attente des transmissions incomplètes est limitée, par ce qu'on appelle le backlog. Lorsque cette limite est atteinte, les paquets SYN suivants reçus par le serveur seront ignorés.
Vous voyez le rapport avec notre problème ? Il suffira de flooder la machine spoofée avec des requêtes SYN. Ainsi, elle ne répondra pas au paquet SYN/ACK envoyé par le serveur. Ce flood doit se faire avec des paquets dont l'adresse source est inexistante.
Mais un nouveau problème se pose. En effet, l'attaquant est totalement aveugle pendant ces manipulations, puisque le serveur ne renvoie rien vers sa machine, mais tout vers la machine spoofée.
Pour éviter cela, il va falloir utiliser le "source routing". Cette option, spécifiée dans le champ "option" de l'entête IP, permet de faire passer la réponse à un paquet par un chemin spécifique. Ainsi, il est possible de faire en sorte que les paquets émis par le serveur vers la machine spoofée passe par votre machine. Avec un sniffer, vous aurez donc accès aux trames échangées. Vous n'êtes donc plus aveugle. Tout est donc reglé.
Eh bien non ! Qu'est-ce qui ne va encore pas ?
C'est simple. Vous savez que pour établir une connexion TCP, des paquets spécifiques sont échangés. Ils utilisent entre autres des numéros de séquence, pour vérifier l'établissement d'une connexion correcte.
Un rappel du fonctionnement de ces numéros ? Bon, d'accord :
* Le client envoie un paquet SYN, avec un numéro de séquence x. Ce numéro, codé sur 32bits, correspond à l'ISN (Numéro Initial de Séquence) choisit pas la machine client pour l'établissement de la connexion.
* Le serveur répond en envoyant un paquet SYN/ACK. Pour ce paquet, le numéro d'acquitement (Acknowledgment number, à ne pas confondre avec le flag ACK associé) a pour valeur x+1, et le numéro de séquence a pour valeur l'ISN choisi par le serveur pour la connexion, y.
* Enfin, le client renvoie un paquet ACK, avec son numéro d'acquittement à y+1, et son numéro de séquence à x+1.
Pour réussir à établir la connexion avec le serveur, vous devrez donc connaître l'ISN choisit par ce dernier. Aujourd'hui, les systèmes informatiques sont équipés de générateurs de nombres aléatoires puissants, ce qui peut vous compliquer considérablement la tâche. Une erreur dans ce numéro peut avoir différentes conséquences :
* Si le numéro est inférieur au numéro d'ACK attendu, le paquet est supprimé ;
* S'il est légérement supérieur, le paquet est mis en attente ;
* Et s'il est trop supérieur, le paquet est également supprimé ;
Il faudra donc recourir, lorsque c'est possible, au source routing de manière à identifier ce numéro.
hakim350
Messages postés
5
Date d'inscription
dimanche 4 avril 2010
Statut
Membre
Dernière intervention
18 mai 2010
3
18 mai 2010 à 21:59
18 mai 2010 à 21:59
Les attaques par spoofing d'IP servent à accéder à des serveurs dont le système de sécurité se base sur le filtrage des adresses IP. Prenons l'exemple d'un serveur protégé par un firewall dont la règle est :
- Si adresse IP distante 80.9.65.6 alors ça passe
- Sinon ça ne passe pas
Pour accéder à ce serveur, il faut donc que votre adresse IP soit 80.9.65.6. Ou plutôt, que l'adresse indiquée dans les entêtes des paquets que vous émettez vers le serveur soit 80.9.65.6. Et c'est en ça que consiste le spoofing : modifier les paquets émis pour faire croire qu'il provienne d'un autre système, autorisé à se connecter au serveur protégé.
Mais attention, il ne faut en aucun cas croire que vous allez modifier votre IP. Vous allez simplement émettre des paquets truqués. L'adresse que votre FAI vous a attribué ne change pas.
Bon, nous allons maintenant voir comment mettre pratiquement une telle attaque sur pied.
Vous vous souvenez du schéma suivi lors d'une connexion TCP ? Non ?
Bon, le revoilà
client -----SYN----> serveur
client <--ACK/SYN--- serveur
client -----ACK----> serveur
Problématique, contournement
Admettons que vous envoyez un paquet SYN spoofé au serveur. Celui-ci va renvoyé un paquet SYN/ACK, mais en direction de la machine dont vous avez spoofé l'adresse (la machine pour laquelle vous vous faites passer). Cette dernière va donc recevoir un paquet SYN/ACK alors qu'elle n'a envoyé aucun paquet SYN. Elle va donc inévitablement re-émettre un paquet RST vers le serveur, mettant ainsi fin à la tentative de connexion.
Il est donc impossible de réaliser une attaque par spoofing dans ces conditions.
Pour parer à ce problème, il faut donc empêcher l'émission du paquet RST par la machine spoofée. Comment ? En floodant, de manière à ce que la machine ne puisse pas répondre au paquet SYN/ACK qu'elle recevra du seveur.
Vous savez que lors d'une connexion TCP, le serveur envoie un paquet SYN/ACK vers le client, et va attendre la réponse de ce dernier. Tant que le client n'a pas répondu, la connexion ne peut avoir lieu. Ce qui est intéressant, c'est que la longueur de la file d'attente des transmissions incomplètes est limitée, par ce qu'on appelle le backlog. Lorsque cette limite est atteinte, les paquets SYN suivants reçus par le serveur seront ignorés.
Vous voyez le rapport avec notre problème ? Il suffira de flooder la machine spoofée avec des requêtes SYN. Ainsi, elle ne répondra pas au paquet SYN/ACK envoyé par le serveur. Ce flood doit se faire avec des paquets dont l'adresse source est inexistante.
Mais un nouveau problème se pose. En effet, l'attaquant est totalement aveugle pendant ces manipulations, puisque le serveur ne renvoie rien vers sa machine, mais tout vers la machine spoofée.
Pour éviter cela, il va falloir utiliser le "source routing". Cette option, spécifiée dans le champ "option" de l'entête IP, permet de faire passer la réponse à un paquet par un chemin spécifique. Ainsi, il est possible de faire en sorte que les paquets émis par le serveur vers la machine spoofée passe par votre machine. Avec un sniffer, vous aurez donc accès aux trames échangées. Vous n'êtes donc plus aveugle. Tout est donc reglé.
Eh bien non ! Qu'est-ce qui ne va encore pas ?
C'est simple. Vous savez que pour établir une connexion TCP, des paquets spécifiques sont échangés. Ils utilisent entre autres des numéros de séquence, pour vérifier l'établissement d'une connexion correcte.
Un rappel du fonctionnement de ces numéros ? Bon, d'accord :
* Le client envoie un paquet SYN, avec un numéro de séquence x. Ce numéro, codé sur 32bits, correspond à l'ISN (Numéro Initial de Séquence) choisit pas la machine client pour l'établissement de la connexion.
* Le serveur répond en envoyant un paquet SYN/ACK. Pour ce paquet, le numéro d'acquitement (Acknowledgment number, à ne pas confondre avec le flag ACK associé) a pour valeur x+1, et le numéro de séquence a pour valeur l'ISN choisi par le serveur pour la connexion, y.
* Enfin, le client renvoie un paquet ACK, avec son numéro d'acquittement à y+1, et son numéro de séquence à x+1.
Pour réussir à établir la connexion avec le serveur, vous devrez donc connaître l'ISN choisit par ce dernier. Aujourd'hui, les systèmes informatiques sont équipés de générateurs de nombres aléatoires puissants, ce qui peut vous compliquer considérablement la tâche. Une erreur dans ce numéro peut avoir différentes conséquences :
* Si le numéro est inférieur au numéro d'ACK attendu, le paquet est supprimé ;
* S'il est légérement supérieur, le paquet est mis en attente ;
* Et s'il est trop supérieur, le paquet est également supprimé ;
Il faudra donc recourir, lorsque c'est possible, au source routing de manière à identifier ce numéro.
- Si adresse IP distante 80.9.65.6 alors ça passe
- Sinon ça ne passe pas
Pour accéder à ce serveur, il faut donc que votre adresse IP soit 80.9.65.6. Ou plutôt, que l'adresse indiquée dans les entêtes des paquets que vous émettez vers le serveur soit 80.9.65.6. Et c'est en ça que consiste le spoofing : modifier les paquets émis pour faire croire qu'il provienne d'un autre système, autorisé à se connecter au serveur protégé.
Mais attention, il ne faut en aucun cas croire que vous allez modifier votre IP. Vous allez simplement émettre des paquets truqués. L'adresse que votre FAI vous a attribué ne change pas.
Bon, nous allons maintenant voir comment mettre pratiquement une telle attaque sur pied.
Vous vous souvenez du schéma suivi lors d'une connexion TCP ? Non ?
Bon, le revoilà
client -----SYN----> serveur
client <--ACK/SYN--- serveur
client -----ACK----> serveur
Problématique, contournement
Admettons que vous envoyez un paquet SYN spoofé au serveur. Celui-ci va renvoyé un paquet SYN/ACK, mais en direction de la machine dont vous avez spoofé l'adresse (la machine pour laquelle vous vous faites passer). Cette dernière va donc recevoir un paquet SYN/ACK alors qu'elle n'a envoyé aucun paquet SYN. Elle va donc inévitablement re-émettre un paquet RST vers le serveur, mettant ainsi fin à la tentative de connexion.
Il est donc impossible de réaliser une attaque par spoofing dans ces conditions.
Pour parer à ce problème, il faut donc empêcher l'émission du paquet RST par la machine spoofée. Comment ? En floodant, de manière à ce que la machine ne puisse pas répondre au paquet SYN/ACK qu'elle recevra du seveur.
Vous savez que lors d'une connexion TCP, le serveur envoie un paquet SYN/ACK vers le client, et va attendre la réponse de ce dernier. Tant que le client n'a pas répondu, la connexion ne peut avoir lieu. Ce qui est intéressant, c'est que la longueur de la file d'attente des transmissions incomplètes est limitée, par ce qu'on appelle le backlog. Lorsque cette limite est atteinte, les paquets SYN suivants reçus par le serveur seront ignorés.
Vous voyez le rapport avec notre problème ? Il suffira de flooder la machine spoofée avec des requêtes SYN. Ainsi, elle ne répondra pas au paquet SYN/ACK envoyé par le serveur. Ce flood doit se faire avec des paquets dont l'adresse source est inexistante.
Mais un nouveau problème se pose. En effet, l'attaquant est totalement aveugle pendant ces manipulations, puisque le serveur ne renvoie rien vers sa machine, mais tout vers la machine spoofée.
Pour éviter cela, il va falloir utiliser le "source routing". Cette option, spécifiée dans le champ "option" de l'entête IP, permet de faire passer la réponse à un paquet par un chemin spécifique. Ainsi, il est possible de faire en sorte que les paquets émis par le serveur vers la machine spoofée passe par votre machine. Avec un sniffer, vous aurez donc accès aux trames échangées. Vous n'êtes donc plus aveugle. Tout est donc reglé.
Eh bien non ! Qu'est-ce qui ne va encore pas ?
C'est simple. Vous savez que pour établir une connexion TCP, des paquets spécifiques sont échangés. Ils utilisent entre autres des numéros de séquence, pour vérifier l'établissement d'une connexion correcte.
Un rappel du fonctionnement de ces numéros ? Bon, d'accord :
* Le client envoie un paquet SYN, avec un numéro de séquence x. Ce numéro, codé sur 32bits, correspond à l'ISN (Numéro Initial de Séquence) choisit pas la machine client pour l'établissement de la connexion.
* Le serveur répond en envoyant un paquet SYN/ACK. Pour ce paquet, le numéro d'acquitement (Acknowledgment number, à ne pas confondre avec le flag ACK associé) a pour valeur x+1, et le numéro de séquence a pour valeur l'ISN choisi par le serveur pour la connexion, y.
* Enfin, le client renvoie un paquet ACK, avec son numéro d'acquittement à y+1, et son numéro de séquence à x+1.
Pour réussir à établir la connexion avec le serveur, vous devrez donc connaître l'ISN choisit par ce dernier. Aujourd'hui, les systèmes informatiques sont équipés de générateurs de nombres aléatoires puissants, ce qui peut vous compliquer considérablement la tâche. Une erreur dans ce numéro peut avoir différentes conséquences :
* Si le numéro est inférieur au numéro d'ACK attendu, le paquet est supprimé ;
* S'il est légérement supérieur, le paquet est mis en attente ;
* Et s'il est trop supérieur, le paquet est également supprimé ;
Il faudra donc recourir, lorsque c'est possible, au source routing de manière à identifier ce numéro.
