 Autor
|
Tema: ¿como filtra paquetes wireshark? (Leído 5,810 veces)
|
Kaxperday
 Desconectado
Mensajes: 702
The man in the Middle
|
Hola a todos, estoy usando wireshark y me gustaría saber como filtra los paquetes.
Es decir cuando pongo por ejemplo "http" que hace exactamente ¿mostrar todos los paquetes con puerto de destino 80?, ¿o hay algo más?.
Para paquetes como ftp o https ¿el procedimiento es el mismo?, ¿simplemente haría un filtro de paquete para los paquetes de puerto de destino 21 y 443?.
Supongo también puede darse el caso de que una página web tenga esos servicios implementados en otro puerto, ¿como podríamos detectarlo entonces?
Saludos.
|
|
|
|
|
En línea
|
Cuando el poder económico parasita al político ningún partido ni dictador podrá liberarnos de él. Se reserva el 99% ese poder.
|
|
|
|
engel lex
|
básicamente es como dices al inicio, "http" y "ftp" son protocolos de capa de transporte y se distinguen únicamente por el numero de protocolo... pero en realidad cualquier protocolo, con el servidor correctamente configurado puede viajar por esos puertos tambien (como se ve mucho que hacen los vpn que viajan por dns, https u otros)
|
|
|
|
|
En línea
|
El problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.
|
|
|
|
MinusFour
|
El filtro http busca por paquetes http asi viajen por el puerto 80 o por otro puerto. Pero si van en un tunel cifrado (por SSL por ejemplo) el filtro no lo inspecciona a menos que el filtro sea del tunel, en todo caso ves el tunel no el contenido. Si te fijas, no tienes un filtro https en wireshark y por http tampoco vas a encontrar https. ¿Como lo hacen? Pues no estoy seguro, pero es casi seguro que inspeccionan los paquetes y si el paquete tiene una característica del protocolo entonces lo etiqueta como parte del protocolo. Por ejemplo los requests HTTP empiezan asi: METODO /Recurso VersionHTTP Por ejemplo: |
|
|
|
|
En línea
|
|
|
|
Kaxperday
Desconectado
Mensajes: 702
The man in the Middle
|
Gracias por las respuestas. ¿Como lo hacen? Pues no estoy seguro, pero es casi seguro que inspeccionan los paquetes y si el paquete tiene una característica del protocolo entonces lo etiqueta como parte del protocolo. A eso es a lo que voy, pues estoy intentando filtrar los paquetes de la red, y un filtro podría ser el de puerto 80 para HTTP, 21 FTP, 22 SFTP, 443 SSL, 110 POP3... Pero claro, eso no garantiza que vayamos a recoger todos los paquetes de un protocolo, pues puede haber protocolos usando distintos puertos y ya no recogeríamos esos datos, la idea sería poner un filtro simple y eficiente. De todas formas filtrando solo el puerto, filtraríamos la mayor parte del tráfico ya que la inmensa mayoría de servicios usan esos puertos para los protocolos especificados. Pero a donde quería llegar con esto es a encontrar ese filtro que vaya más allá de el de puerto, como dice MF podría buscar los HTTP req con el método. Pero creo que el filtro debería de empezar filtrando el tipo: (bytes 12 y 13 de la cabecera del paquete), allí confirmamos que es TCP, ya que lo que buscamos es siempre algo orientado a conexión. Por ejemplo en un ARP nos dice que es ARP en el tipo.. Luego ya quizás pasaría a un filtro de puerto, o debería estudiar los paquetes que quiero sniffar y ver los campos que tienen y de ahí ya diferenciarlos, pero quedarían bastantes condiciones (if) y quemaría un poco el CPU, de primeras creo que usaré el filtro de tipo, luego de puerto, y luego quizás implemente algo para cada paquete y quite lo del puerto, si pienso algo mejor. Saludos y gracias. Edito: De todas formas esto quizás pueda facilitar las cosas. |
|
|
|
« Última modificación: 13 Julio 2015, 17:21 pm por Kaxperday »
|
En línea
|
Cuando el poder económico parasita al político ningún partido ni dictador podrá liberarnos de él. Se reserva el 99% ese poder.
|
|
|
|
MinusFour
|
Ciertamente no tiene sentido aplicar todos los filtros a todos los paquetes porque algunos filtros excluyen a otros. HTTP es un protocolo de texto (HTTP/2.0 creo que no), mientras que TCP es un protocolo binario. Los protocolos binarios son generalmente mucho más fáciles de identificar.
|
|
|
|
|
En línea
|
|
|
|
Kaxperday
Desconectado
Mensajes: 702
The man in the Middle
|
De todas formas no entiendo, ¿HTTP no es un paquete de tipo TCP/IP? Claro tiene su cabecera binaria, y en su contenido texto plano. Pero es TCP/IP. El filtro le pondría que sea para TCP/IP, y luego que vaya viendo con unos condicionales si es de un tipo u otro, no usar un filtro para todos XD, por ejemplo si tiene (metodo /...) es un HTTP, else if (...) .. eso ya una vez identificado que es TCP/IP, creo que sería lo mejor. Saludos.  |
|
|
|
|
En línea
|
Cuando el poder económico parasita al político ningún partido ni dictador podrá liberarnos de él. Se reserva el 99% ese poder.
|
|
|
kub0x
Enlightenment Seeker
Colaborador
Desconectado
Mensajes: 1.486
S3C M4NI4C
|
De todas formas no entiendo, ¿HTTP no es un paquete de tipo TCP/IP? Claro tiene su cabecera binaria, y en su contenido texto plano. Pero es TCP/IP. El filtro le pondría que sea para TCP/IP, y luego que vaya viendo con unos condicionales si es de un tipo u otro, no usar un filtro para todos XD, por ejemplo si tiene (metodo /...) es un HTTP, else if (...) .. eso ya una vez identificado que es TCP/IP, creo que sería lo mejor. Saludos. HTTP no siempre va en TCP, ahí tienes por ejemplo SSDP que usa HTTP con UDP. Pero vamos que para web si se utiliza TCP. El caso es que TCP/IP no son más que dos capas que definen el tipo de protocolo de transporte, dirección de origen/destino, puerto origen/destino, checksums, data length, longitud de cabecera etc.. Los datos llegan en la capa de aplicación, que es donde realmente van los datos, ya que si desglosas el paquete verás que detrás de la capa de transporte (UDP/TCP) viene la data (en Wireshark se ve esto muy bien).
|
|
|
|
|
En línea
|
|
|
|
|
MinusFour
|
Creo tambien que IPX/SPX pueden usar HTTP pero no estoy seguro. Lo mejor sería trabajarlo por capas.  |
|
|
|
|
En línea
|
|
|
|
|
 |
