
Mi objetivo es interceptar el tráfico con un proxy MITM. Para hacer esto, configuré mi computadora portátil para albergar un punto de acceso Wi-Fi, conecté el teléfono inteligente, inicié el proxy y configuré el teléfono inteligente para usar mi computadora portátil como proxy en esta red Wi-Fi.
La IP del host es 10.42.0.1
y la del cliente 10.42.0.2
. El proxy escucha en el puerto 8080, cualquier interfaz. Aparece correctamente netstat
y puedo acceder netcat
a él desde localhost. El teléfono Android está configurado para funcionar como proxy a través 10.42.0.1
del puerto 8080.
Desde el teléfono puedo hacer ping 10.42.0.1
; en Wireshark veo las solicitudes de eco que entran y las respuestas que salen.
Sin embargo, cuando el teléfono envía un paquete TCP o UDP, el sistema no responde. Cuando se escucha en el punto de acceso con netcat en UDP y se envían datos UDP desde el teléfono, los datos no se entregan a netcat. Puedo ver el paquete con datos entrantes en Wireshark, pero el terminal permanece en blanco. Cuando escucho en TCP, puedo ver en Wireshark el paquete SYN que llega desde el teléfono, pero nunca se reconoce (no hay respuesta SYN+ACK).
El punto de acceso ( 10.42.0.1
) claramente tiene ARP y una ruta de regreso o respuestas de eco ICMP no saldrían. No hay ningún firewall de host instalado. El problema persiste después de reiniciar.
¿Cual podría ser el problema?
Respuesta1
Mientras escribía la pregunta me di cuenta de que, aunque sabía que no podía ser un firewall porque no tenía ninguno instalado, y no podía ser iptables porque no persistirían después de un reinicio, me di cuenta de que en realidad no lo había comprobado. no se establecieron reglas de iptables.
# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
DROP all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp dpt:isakmp
ACCEPT esp -- anywhere anywhere
ACCEPT ah -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:8528
Resulta que algo, probablemente NetworkManager en su infinita sabiduría, decidió agregar algunas reglas para nosotros, feliz de proporcionarnos inesperadamente un firewall.
Una solución alternativa es eliminar algunas reglas y restablecer la política predeterminada:
# iptables -L --line-numbers
Chain INPUT (policy DROP)
num target prot opt source destination
1 ACCEPT udp -- anywhere anywhere udp dpt:bootps
2 ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
3 ACCEPT udp -- anywhere anywhere udp dpt:domain
4 ACCEPT tcp -- anywhere anywhere tcp dpt:domain
5 DROP all -- anywhere anywhere state INVALID
# iptables -D INPUT 5
# iptables --policy INPUT ACCEPT
No puedo encontrar ninguna referencia a nada de esto en la documentación de NetworkManager o incluso en el código fuente. No sé qué es este puerto 8528 que parece permitir de forma predeterminada (no está registrado ni referenciado en ninguna parte) y no puedo encontrar rápidamente el código relevante que llama a iptables, ni encontrar ninguna configuración relevante para evitar que bloquee el firewall. conexión. ¿Quizás NetworkManager llama a algún otro software que posteriormente lo instala?