Mein Ziel ist es, den Datenverkehr mit einem MITM-Proxy abzufangen. Dazu habe ich meinen Laptop so konfiguriert, dass er einen WLAN-Hotspot hostet, das Smartphone angeschlossen, den Proxy gestartet und das Smartphone so konfiguriert, dass es meinen Laptop als Proxy in diesem WLAN-Netzwerk verwendet.
Die Host-IP ist 10.42.0.1und der Client 10.42.0.2. Der Proxy lauscht auf Port 8080, jede Schnittstelle. Er wird korrekt angezeigt netstatund ich kann netcatvon localhost darauf zugreifen. Das Android-Telefon ist so konfiguriert, dass es über 10.42.0.1Port 8080 als Proxy fungiert.
Vom Telefon aus kann ich einen Ping senden 10.42.0.1; in Wireshark sehe ich die eingehenden Echoanforderungen und die ausgehenden Antworten.
Wenn das Telefon jedoch ein TCP- oder UDP-Paket sendet, antwortet das System nicht. Wenn ich mit netcat auf UDP am Hotspot lausche und UDP-Daten vom Telefon sende, werden die Daten nicht an netcat übermittelt. Ich kann das Paket mit den Daten in Wireshark eingehen sehen, aber das Terminal bleibt leer. Wenn ich auf TCP lausche, kann ich in Wireshark das vom Telefon eingehende SYN-Paket sehen, aber es wird nie bestätigt (keine SYN+ACK-Antwort).
Der Hotspot ( 10.42.0.1) verfügt eindeutig über ARP und eine Route zurück, sonst würden keine ICMP-Echoantworten ausgegeben. Es ist keine Host-Firewall installiert. Das Problem besteht nach einem Neustart weiterhin.
Was könnte das Problem sein?
Antwort1
Beim Schreiben der Frage wurde mir klar, dass ich zwar wusste, dass es keine Firewall sein konnte, weil ich keine installiert hatte, und dass es auch nicht an iptables liegen konnte, weil diese nach einem Neustart nicht bestehen bleiben würden. Allerdings wurde mir klar, dass ich nicht wirklich überprüft hatte, dass keine iptables-Regeln festgelegt waren.
# 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
Es stellte sich heraus, dass etwas, wahrscheinlich NetworkManager in seiner unendlichen Weisheit, beschlossen hat, einige Regeln für uns hinzuzufügen, und dabei erfreulicherweise eine Firewall zur Verfügung stellte.
Eine Problemumgehung besteht darin, einige Regeln zu deaktivieren und die Standardrichtlinie zurückzusetzen:
# 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
Ich kann in der NetworkManager-Dokumentation oder sogar im Quellcode keinen Hinweis darauf finden. Ich weiß nicht, was dieser Port 8528 ist, den er standardmäßig zuzulassen scheint (er ist weder registriert noch nirgends referenziert), und ich kann den relevanten Code, der iptables aufruft, nicht schnell finden oder relevante Einstellungen finden, um zu verhindern, dass die Verbindung durch eine Firewall geschützt wird. Vielleicht ruft NetworkManager eine andere Software auf, die dies anschließend installiert?