AFwall+ custom script regeln werden nicht übernommen

Hallo,

vielleicht könnte mir wer weiter helfen!?
Wenn ich das custom script von hier → https://www.kuketz-blog.de/afwall-digitaler-tuervorsteher-take-back-control-teil4/
für mich angepasst verwenden möchte, scheitert er jedesmal beim Regeln setzen.
Woran könnte es liegen, das die Regeln nicht angewendet werden, er scheitert direkt beim start?

Wie kann ich dort denn den Systemweiten DNS auf eine private DOT domain leiten anstatt mittels udp an dismail auf port 53 wie im script.

Müssen / Können / dürfen die Kernel tweaks übernommen werden, fahre ein android OsygenOS 13 gerooted?

Welche standard Einstellungen, also die relevanten müssen gesetzt sein, damit das script mit den Regeln funktioniert?
Ich habe gefühlt schon jede Einstellung verändert und weiß nicht mehr was standard ist.

Danke schonmal.

Ich kann nur noch nach meiner Aktenlage antworten, habe AFWall+ gerade nicht mehr im Einsatz. Vielleicht hilft’s ja trotzdem … :thinking:

Dann ist das die ideale Gelegenheit, nochmal von vorne zu beginnen. Meine ich ernst. :face_with_monocle:

Ich nehme an, Du meinst die beiden Skripte aus 4.1 Startup- und Shutdown-Skript. Die sollten mit den Standard-Einstellungen laufen.

Funktionieren die Skripte ohne Deine Anpassungen?

Mir fallen verschiedene Möglichkeiten ein. Das gute ist, Du kannst Dich langsam herantasten.

Die Tweaks werden ggf. nicht von Deinem OS unterstützt.

Mehrere GitHub Issues bemerken, dass die Flush/Purge rules keine gute Idee sind. #1075, #852, #775.

Mit dem Hinweis aus dem Wiki - Adding custom rules ist das nicht mehr nötig. Mit aktivierten Inbound-Verbindungen gibt es auch afwall-input, die ebenfalls genutzt werden kann und automatisch gelöscht wird. Und mit aktiviertem Tor-Control gilt das gleiche für die nat Tabelle, die dann auch eine afwall Chain besitzt.

Weiterhin können bei Deinem OS die IP(6)TABLES Definitionen falsch sein. Tatsächlich sind sie gar nicht notwendig, da AFWall+ bereits $IPTABLES, $BUSYBOX, $IPV6 (0/1) korrekt setzt. Wenn Du IPv6 aktiviert hast, werden die Skripte übrigens zweimal aufgerufen, einmal für IPv4 und einmal für IPv6.

Und, wie schon angedeutet, weiter herantasten. Zuerst ohne Shutdown-Skript probieren. Dann im Startup-Skript immer mehr Zeilen löschen.

Mit iptables? Gar nicht. Sind verschiedene Protokolle.

1 „Gefällt mir“

Könnte in Erwägung gezogen werden.

Ja einfach das Startscript und das Shutdownscript. Kann ich mir nicht vorstellen, aber werde es probieren.

Ich habe manche Zeilen auskommentiert, DNS-Server und WLAN Netz angepasst.
IPv6 hatte ich aktiviert zur Überwachung.

Und wie mache ich das dann sonst in diesem Fall? Weil das war jetzt der Hauptgrund warum ich das Script überhaupt verwenden wollte, um das komplette System Ausnahmslos zu meineni DNS Server zu leiten und an keinen anderen, wie es ja anscheinend geschieht.

:+1:

Probiere auch erst einmal die Einstellungen aus Take back control! Teil4. Dort ist IPv6 deaktiviert. Die Skripte sehen mir auch danach aus, dass sie auf einen IPv4-only use case zugeschnitten sind.

Denn sonst passiert wahrscheinlich sowas wie in AFWall+ Github #1279.

Damit ich das richtig verstehe und nicht zu Beginn etwas missverstanden habe, was willst Du erreichen? Was ist der „Systemweite DNS“ den Du umleiten willst? netd, der unverschlüsselte (!) DNS requests auf UDP bzw. TCP port 53 versendet?

Wieso reicht es nicht einfach unter Privates DNS den Hostname des privaten DNS-Anbieters zu konfigurieren?

1 „Gefällt mir“

Ich bin noch nicht dazu gekommen AFwall+ zurück zusetzten und neu aufzusetzen, aber wenn werde ich nach der Anleitung gehen.
Ich habe ipv6 aktiviert zur Überwachung, weil ich gelesen habe das ipv6 dazu in der Lage ist durch jede ipv4 Firewall einfach durch zu rooten, sobald das Protokoll auf einer Netzwerkschnittstelle hinter der Firewall aktiviert ist.
Das fand ich nicht so cool.

Das habe ich unter Android unter den Verbindungseinstellungen auch so gesetzt, aber es wird ja gesagt das android trotz eines Systemweiten DNS Eintrag noch Prozesse ausführt die (sogar am VPN vorbei) eigene DNS querys an Google senden, das würde ich gerne auf irgendeine Weise unterbinden und ich meine das custom script wurde als workaround dafür genannt.

Hast Du auch Belege dafür?

Was „ja gesagt [wird]“, ist mir nur als nicht mal ohne Private DNS bekannt. Nur, dass manchmal die VPN DNS Einstellungen ignoriert werden. Wie sieht es mit Private DNS aus?

Bei systemweiten DNS nehme ich jetzt einfach mal an, dass Du unverschlüsselte UDP/TCP DNS Anfragen meinst. Private DNS benötigt dieses eigentich nur, um die eigene Domain aufzulösen.

Aber OK. Ohne Private DNS benötigts Du eine weitere App. Netguard erwähnt z.B. Nebulo oder personalDNSfilter. Zu pDNSf findest Du einiges hier oder im alten Forum.

Z.B. mit pDNSf den nicht-VPN Modus wählen, und auch nicht root. Es bietet auch eine eigene iptables Integration an, die aber inkompatibel zu AFWall+ ist. Bietet aber Anhaltspunkte, wie die Regeln in der -t nat -A "afwall" Tabelle aussehen könnten.

Ungefähr so

$IPTABLES -t nat -A "afwall" -p udp --dport 53 -j REDIRECT --to-ports $PORT
$IPTABLES -t nat -A "afwall" -p tcp --dport 53 -j REDIRECT --to-ports $PORT

Dann aber auch noch Unix & Linux Stack Exchange beachten (Achtung: muss auch wieder gelöscht werden).

$IPTABLES -t nat -A POSTROUTING ! -s 127.0.0.0/8 -d 127.0.0.0/8 -p udp --dport $PORT -j SNAT --to-source 127.0.0.1
$IPTABLES -t nat -A POSTROUTING ! -s 127.0.0.0/8 -d 127.0.0.0/8 -p tcp --dport $PORT -j SNAT --to-source 127.0.0.1

Und noch fehlende Regeln in den afwall bzw. afwall-input Chains bzw. AFWall+ Freigaben, je nach Log-Output.


Edit: kleinere Korrekturen
Edit2: Aussage über ohne Private DNS richtiggestellt

1 „Gefällt mir“

Stand doch vor kurzem im Blog
https://www.kuketz-blog.de/warnung-android-leakt-beim-connectivity-check-daten-an-vpn-verbindungen-vorbei/

keine Ahnung, ich gehe mal davon aus das es mit private DNS genauso ist.

Nein, systemweit selber setzen kann man den DNS doch erst seit kurzem mit Android 11 oder 12 (keine Ahnung) und das auch mit der Option eines privaten DNS, die ich auch dort gesetzt habe mit dnsforge.

Wenn Du sagst, das es bei der Nutzung mit private DNS nicht zu so einem Leak kommen kann, wie kann ich das denn überprüfen? Auf Testseiten werden mir nie google DNS Server angezeigt nur der von dnsforge. Reicht das als Überprüfung? Denke mal nicht, sonst wäre das ja schon früher bekannt geworden, oder?

Ich fange mal mit der letzten Frage an

Was bekannt worden? Dass „Prozesse […] eigene DNS querys an Google senden“? Hier fehlt immer noch ein Beleg.

Da steht nichts von DNS.

Ich muss mich übrigens korrigieren. Dass unverschlüsseltes DNS an Google sendet, ist mir nicht bekannt. Nur dass es die VPN DNS Server Einstellungen manchmal ignoriert.

Ging vorher auch schon für unverschlüsseltes DNS über WLAN. Nur mobile Daten konnte man nicht einstellen.

Also ist „systemweit“ gleichzusetzen mit Private DNS? Wo kann man das noch einstellen? („auch“ im Zitat)

Habe ich nicht behauptet. Private DNS benötigt unverschlüsseltes DNS für die Auflösung der eigenen Domain. Das sollte dann eigentlich genügen. Ob es so ist, weiß ich nicht.

Z.B. indem Du Pakete mit iptables (NF)LOG Target loggst. Anhaltspunkt z.B. hier.

# !!! ATTENTION: adapt next rule if according to the rule found within afwall-reject !!!
$IPTABLES -A afwall-custom-drop -m limit --limit 1000/min -j LOG --log-prefix "{AFL}" --log-tcp-options --log-ip-options --log-uid

Ja, das Daten an Google gesendet werden am VPN vorbei, DNS Query hatte ich den Bezug wegen der Namensähnlichkeit zu DNS Leak.

Naja, das ist schon ein großer Unterschied ob ich ich den DNS Systemweit setze oder halt nur wenn ich im WLAN bin.

Da wir von verschiedenen Leaks ausgingen könnten wir wieder zu meiner Problemlösung mit dem script kommen.
Dazu habe ich nur eine Frage und zwar welcher DNS wird für die Namensauflösung für die Domain von DoT DNS verwendet?

Nachfolgend habe ich einen Neuanfang für AFwall+ gemacht, außer optische Änderungen in der Standard Konfiguration und das nicht Deaktivieren von IPv6, habe ich nur wie im Blog beschrieben einen Whiteliste Betrieb mit Startscript im /service.d und das Deaktivieren von netd vorgenommen.
Die Haken nur bei root Apps, ntp und media Server gesetzt.
Beim costum script habe ich alles auskommentiert außer iptables, defaults und outgoing traffic.
Im stop script musste ich die purge/flush Regeln auskommentieren, weil sonst die firewall nicht auszuschalten ging.

Das Ergebnis, ist leider, das kein Internet zur Verfügung steht, obwohl der Browser eine Freigabe hat und nach ca. 2 Minuten wird die Datenverbindung dann ganz deaktiviert, beim wechseln von Profilen um die Verbindung wieder herzustellen bootet mein smartphone dann einfach mal neu, das gleiche beim zweiten und dritten Versuch.

Ich denke mal das liegt an den Unterschiedlichen DNS Möglichkeiten von früher zu heute, das script geht ausschließlich davon aus, das DNS querys unverschlüsselt mit dem im System gesetzten DNS Server, oder halt dem Neudefinierten wie im Script, getätigt werden.
Ich gehe weiter mal davon aus, dass der private DNS als transparenter Proxy läuft und alles an Port 53 umleitet.
So ungefähr habe ich das von unbound und Konsorten zumindest verstanden, die fungieren als DNS Proxys.

Um das zu testen, habe ich im start script den Eintrag für den DNS auskommentiert und auf den von dnsforge 176.9.93.198 geändert und die Ausnahme für mein Wlan angepasst. Doch leider mit dem gleichen Ergebnis.
Es funktioniert nichts.

Das log von Afwall+ schreibt in der Zeit wo das script aktiv ist immer ein unbekannte App mit der UID -100 welche geblockt wird, versucht irgendwelche google Adressen zu erreichen uid 1073 und uid 1000 werden auch blockiert wobei Tethering, Cell Brodcast (1073) auch google erreichen will, abwechselnd port 80 und 433 und healthservice, Dynamic System updates,…(1000) ständig auf Port 80 Richtung amazon will.

Also auch wenn das script nun fehlerfrei gestartet wird, bewirkt es nicht mehr das, wofür es gedacht ist. So ist es nicht mehr zu gebrauchen, bzw. läuft so falsch, das ein Reboot erzwungen wird.

Ich werde mich mal durch das wiki kämpfen und schaue ob ich dort aktuelle brauchbare Einträge für das script finde und melde mich wieder.