elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Trabajando con las ramas de git (tercera parte)


+  Foro de elhacker.net
|-+  Comunicaciones
| |-+  Redes
| | |-+  Proxies
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: Proxies  (Leído 1,985 veces)
SDCC

Desconectado Desconectado

Mensajes: 55


Ver Perfil
Proxies
« en: 6 Febrero 2020, 04:30 am »

He estado siguiendo dos libros basicos de hacking (Black Hat Python y Attacking Networks Protocols) y en ambos llevo rato trabajando en todo lo relacionado principalmente con proxies. He practicado un poco con los ejercicios que contempla principalmente el libro de Python para poder construir mis limitados proxies que simplemente consisten principalmente en un socket que reenvía contenido a su destino únicamente por un puerto. Ademas he estado leyendo un poco sobre la variedad de proxies que existen, como son:

1. Proxies basados en Socks4, 4a y 5
2. Proxies HTTP
3. Forwarding Port( Es el primero que vi y con el que he podrido interactuar más con Python)

Me queda clara la idea de un proxy a grandes rasgos y entiendo un poco las diferencias entre cada uno de manera no muy detallada:

1. Sockes4, 4a, 5. El 5 es muy bueno en el sentido de que ofrece autenticacion por varios mecanismos, se puede adaptar a las aplicaciones sin tanto esfuerzo, etc.
2. Proxies HTTP. Especifico para transmision de datos mediante el protocolo HTTP
3. Forwarding Port. Una instancia de este programa se encarga simplemente de abrir un puerto y reenviar los datos entrantes hacia una dirección destino.

Mi principal problema es cuando intento verlo desde el punto de vista de programación. Es decir:

1. Forwarding Port. A nivel de programación lo puedo ver como un socket TCP o UDP que simplemente se encarga de atender a un único cliente y reenviar lo que le llega a la dirección que se le fue especificada como dirección final. Creo que la principal dificultad es que las aplicaciones que lo utilizan deben tener la opción para especificar la dirección y puerto de destino , ademas que se complica si las peticiones que lanza la aplicación aveces varian de objetivo., haciendo practicamente imposible hacer un proxie casero de esta manera que sea generico y que de paso a transmitir la información sin tener que modificar el programa cliente o el programa que esta utilizando el proxie.

2. Proxie HTTP. Entiendo que es una especie de proxie destinado para tráfico del protocolo HTTP pero no me termina de quedar claro como trabaja. Es decir, yo puedo configurar mi Navegador para que use un Proxie HTTP y el proxy se va encargar de retransmitir toda la comunicación existente pero ¿Como lo hace?. Acaso hay algunas estandar para la construcción de Proxie HTTP entre otros que me diga algo al estilo:
PASOS PARA SINCRONIZAR INICIO ENTRE UN NAVEGADOR Y UN PROXIE HTTP.
1. El navegador se va encargar de crear una conexión al proxie HTTP.
2. Hacen un procedimiento de Handhsake
3. El navegador envia mensajes con un formato HTTP , en donde exista una Cabecera DESTINO_FINAL que tendra la IP hacia donde debe ser enviado ese paquete

NOTA. He visto y como era de esperarse, que el navegador usa varios puertos para despachar las peticiones de paginas que hacen cada pestaña e intuyo que de alguna manera una vez sincronizado el navegador con el proxy deben crear un mecanismo para permitir tener varios SUB_CLIENTES (Pestañas virtuales) para cada navegador,  para que sea posible que si hay 3 pestañas haciendo peticiones desde una misma computadora, entonces el proxy puede generar 3 sockets o conexiones auxiliares para darle seguimiento a cada petición, esto debido a que incialmente el navegador esta enviando peticiones HTTP al servidor como si el fuera el servidor web pero como le dice cual es el verdadero destino para cada petición.

3. Finalmente tengo los proxies SOCK..., he visto que estos los que mas facilmente pueden adaptarse a las aplicaciones de manera génerica y he visto que tienen un estandar al estilo como el inventado de HTTP de unos parrafos arriba. Pero entonces esto me esta implicando que cada aplicación que quiera usar este tipo de proxie debe tener un mecanismo dentro de ella que permita la comunicación con un proxie de este estilo, o es posible que realmente la aplicación siga haciendo las mismas cosas que hace comunmente y jamas sepa que realmente primero se esta comunicando con un proxie SOCK.

Por último solo quiero recalcar que mi principal duda esta en que tan genericos se supone que deben ser los proxies en especifico el SOCK, es decir, en todos los casos la aplicación debe tener una opción para habilitar la comunicación con este tipo de proxies o como se logra que aplicaciones que no soportan estas opciones se puedan adaptar. ¿Se supone que puedo utilizar un proxie Socks para redirigir todo el tráfico que sale de mi interfaz de red, como si a gran nivel tuviera un cliente del proxie que prácticamente dijera SOY EL REPRESENTANTE LOCAL DEL PROXIE Y DE ALGUNA FORMA ESCUCHO TODO LO QUE SALE POR LA INTERFAZ DE RED Y ME ENCARGO DE PASARSELO AL PROXIE Y RETORNAR LAS RESPUESTAS? o ¿ debo ir aplicación por aplicación activando la configuración de proxie para que la aplicación se encargue de individualmente conectar su puerto de salida a la dirección del servido?


En línea

SDCC

Desconectado Desconectado

Mensajes: 55


Ver Perfil
Re: Proxies
« Respuesta #1 en: 12 Febrero 2020, 06:54 am »

Retroalimentando la situación. He seguido viendo cosas relacionadas con el tema y me he topado con una posible respuesta a la pregunta de ¿Como hacer un proxie generico?, es decir, que no tenga que estar modificando las configuraciones de cada aplicación.

He encontrado que se puede lograr crear un buffer o cola intermedia entre los paquetes que estan entrando y saliendo de mi interfaz mediante el siguiente comando:
Código
  1. iptables -I INPUT -j NFQUEUE --queue-num 0
Código
  1. iptables -I OUTPUT -j NFQUEUE --queue-num 0

He hecho algunas pruebas en Python(Adjunto el código al final) y he visto que efectivamente parece funcionar en el sentido de que esta capturando todos los datos y me permite procesarlos antes de que salgan o entren. ¿Ahora mi pregunta es si esta implementación es la que realizan los VPN o proxies? y ¿Qué pasa si la cola llega a su limite de capacidad? , ¿Donde esta definido dicho limite en Linux?. Ademas si alguien cuenta sobre que información un poco mas detallada sobre como esta afectado iptables el funcionamiento del stack de TCP/IP debido a que la fuente que estoy siguiendo no habla mucho al respecto y simplemente se limita a explicar la abstracción.

Código
  1. import netfilterqueue
  2.  
  3. # Vinculación de los paquetes de entrada y salida con la cola
  4. # iptables -I INPUT -j NFQUEUE --queue-num 0
  5. # iptables -I OUTPUT -j NFQUEUE --queue-num 0
  6.  
  7.  
  8. def process_packet(packet):
  9.  # Procesamiento de paquete antes de salida
  10.  print(f"Proceso entrante: {packet}")
  11.  # Reenvio del paquete hacia su destino
  12.  packet.accept()
  13.  
  14.  
  15. def main():
  16.  queue = netfilterqueue.NetfilterQueue()
  17.  queue.bind(0, process_packet)
  18.  queue.run()
  19.  
  20.  
  21. if __name__ == "__main__":    
  22.  main()



En línea

Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines