Scapy : requête HTTP

Version imprimable

19/11/2008, 17h52
sorry60

Scapy : requête HTTP
Bonjour,

Je cherche à envoyer un simple requête HTTP en utilisant Scapy.
Je fais donc :
Code:

1 2 3 4 5 6 >>> a=sr(IP(dst="www.google.com")/TCP(dport=80)/"GET / HTTP/1.0\r\n\r\n") Begin emission: Finished to send 1 packets. * Received 1 packets, got 1 answers, remaining 0 packets
Donc ça semble fonctionner.
Mais quand je le fais sur mon site, ça ne marche pas :
Code:

1 2 3 4 5 6 >>> a=sr(IP(dst="monsite.ath.cx")/TCP(dport=80)/"GET / HTTP/1.0\r\n\r\n") Begin emission: Finished to send 1 packets. .......^C Received 7 packets, got 0 answers, remaining 1 packets
J'ai donc regardé avec Wireshark ce qu'il se passe... :

Citation:

> Frame 2............
> Ethernet II............
> Internet Protocol...............
> Transmission Control Protocol...........
> FTP Data
FTP Data : GET / HTTP/1.0\r\n\r\n

Voilà donc c'est du FTP Data qui sort, et non pas du HTTP :aie:
J'ai essayé en passant par Raw("GET / HTTP/1.0\r\n\r\n") mais c'est pareil...

Si quelqu'un a un bout d'aide..
Merci !
19/11/2008, 18h21
sorry60
J'ai un peu plus étudier les trames capturées avec Wireshark, et j'ai trouvé comment solutionner le problème de FTP Data au lieu de HTTP.

Il faut preciser le port source du protocole TCP, car par defaut il envoie sur le 20 (donc c'est interpreté comme du ftp data...).

En mettant donc :
Code:

1 2 a=sr(IP(dst="monsite.ath.cx")/TCP(sport=55110,dport=80)/"GET / HTTP/1.0\r\n\r\n")
J'ai bien du HTTP dans ma trame sortante.
Par contre, le paquet n'est toujours pas reçu... :aie:

Une idée ? mon serveur est derrière une livebox, firewall ?

Edit : quand je fais un GET en passant par telnet, ça fonctionne... bizarre :aie:
20/11/2008, 19h47
dividee

Il faudrait pas faire le handshake TCP avant d'envoyer des data, par hasard ?
20/11/2008, 21h33
sorry60

Citation:

Envoyé par dividee

Il faudrait pas faire le handshake TCP avant d'envoyer des data, par hasard ?

Si ! J'y travaille ;)

Salut,

Je viens de tomber sur ce sujet en cherchant une réponse à un problème quasi similaire.
En effet je dispose de 2 serveurs distant (1 dedibox, 1 hébergement mutualisé 1&1).

J'essai donc via SCAPY d'emettre un requete HTTP de ma dedibox vers mon 1&1.
Donc dans un 1er temps j'effectue une connexion TCP/IP en 3 temps (SYN, SYN_ACK, ACK), ou lors de ma dernière requete j'emet ma requete HTTP, donc la poignée de main ce passe bien, seulement je ne reçois pas les données demandées lors de ma requete HTTP, un autre problème me gêne également c'est que lors du dernière échange (donc le retour de ma requete) le flag de la connexion TCP a pour valeur "R" donc connexion reset...

Je ne comprend pas ce qui cloche, la connexion ce fait bien et d'un coup reset.

J'ai également essayé de requeter google, le resultat est le meme ça ce termine avec un reset

Voir ci-dessous mon code et son resultat :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
 
###[ IP ]###
  version= 4
  ihl= None
  tos= 0x0
  len= None
  id= 1
  flags= 
  frag= 0
  ttl= 64
  proto= tcp
  chksum= 0x0
  src= xxx.xxx.xxx.xxx
  dst= Net('www.google.fr')
  options= ''
###[ TCP ]###
     sport= 55110
     dport= www
     seq= 0
     ack= 0
     dataofs= None
     reserved= 0
     flags= S
     window= 8192
     chksum= 0x0
     urgptr= 0
     options= {}
Begin emission:
...Finished to send 1 packets.
.......*
Received 11 packets, got 1 answers, remaining 0 packets
###[ IP ]###
  version= 4L
  ihl= 5L
  tos= 0x0
  len= 44
  id= 12429
  flags= 
  frag= 0L
  ttl= 50
  proto= tcp
  chksum= 0xdca
  src= 209.85.147.103
  dst= xxx.xxx.xxx.xxx
  options= ''
###[ TCP ]###
     sport= www
     dport= 55110
     seq= 3674604423L
     ack= 1
     dataofs= 6L
     reserved= 0L
     flags= SA
     window= 5720
     chksum= 0x8141
     urgptr= 0
     options= [('MSS', 1430)]
###[ Padding ]###
        load= '\x00\x00'
###[ IP ]###
  version= 4
  ihl= None
  tos= 0x0
  len= None
  id= 1
  flags= 
  frag= 0
  ttl= 64
  proto= tcp
  chksum= 0x0
  src= xxx.xxx.xxx.xxx
  dst= Net('www.google.fr')
  options= ''
###[ TCP ]###
     sport= 55110
     dport= www
     seq= 1
     ack= 3674604424L
     dataofs= None
     reserved= 0
     flags= A
     window= 8192
     chksum= 0x0
     urgptr= 0
     options= {}
###[ Raw ]###
        load= 'GET / HTTP/1.0'
Begin emission:
Finished to send 1 packets.
...............*
Received 16 packets, got 1 answers, remaining 0 packets
###[ IP ]###
  version= 4L
  ihl= 5L
  tos= 0x0
  len= 40
  id= 56552
  flags= 
  frag= 0L
  ttl= 50
  proto= tcp
  chksum= 0x6176
  src= 209.85.147.99
  dst= xxx.xxx.xxx.xxx
  options= ''
###[ TCP ]###
     sport= www
     dport= 55110
     seq= 3674604424L
     ack= 0
     dataofs= 5L
     reserved= 0L
     flags= R
     window= 0
     chksum= 0xaf49
     urgptr= 0
     options= {}
###[ Padding ]###
        load= '\x00\x00\x00\x00\x00\x00'

Le code source SCAPY :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
#!/usr/bin/python
from scapy.all import *
 
syn = IP(dst='www.google.fr') / TCP(sport=55110, dport=80, flags='S')
syn.show()
syn_ack = sr1(syn)
 
syn_ack.show()
 
request = IP(dst=syn_ack[IP].src)/TCP(dport=80, sport=syn_ack[TCP].dport,\
           seq=syn_ack[TCP].ack, ack=syn_ack[TCP].seq + 1, flags='A') / "GET / HTTP/1.0"
 
request.show()
reply = sr1(request)
 
reply.show()

09/12/2011, 19h38
rvbp13
Après une petite recherche j'ai modifié le parfeu de ma dedibox avec ça :
Code:

1 2 iptables -A OUTPUT -p tcp --tcp-flags RST RST -s xxx.xxx.xxx.xxx -j DROP
(xxx.xxx.xxx.xxx) Ip de la dedibox, j'obtiens donc cette fois ci une réponse de type ACK à ma requete HTTP, j'ai donc réussi à supprimer la réponse de type flags=R (reset) par contre coté 1&1 toujours pas de nouvelles de ma requete dans les logs de connexion apache...

Je ne la vois pas passer, si quelqu'un à une idée de l'endroit ou ça bloque ?
Pas de trace également dans netstat de la connexion...