Checkliste: Android-Phone absichern, BEVOR es das 1. Mal ins Internet geht (AFWall+)

[zcover]

Hallo Ihr,

guten Morgen, wo finde ich eine gute einleitende Erklärung zu eurem Script?
Mir ist noch gar nicht klar wofür euer Script eigentlich ist.

AfWall+
Was muss ich einstellen, damit ich die Uhrzeit mit AfWall+ auf dem Netz beziehen kann?

LineageOS 14.1 - OTA Update
@ooo hat irgendwo die Einstellungen für mögliche OTA Updates bei AfWall+ als Screenshot gepostet.
Leider finde ich die nicht mehr, kann mir jemand den Link geben, danke?
Checkliste: Android-Phone absichern, BEVOR es das 1. Mal ins Internet geht (AFWall+)

Sind da zusätzliche Screenshots hinzugekommen oder gibt es noch ein Posting dazu?

MfG
zcover

 

[Mumford]

@ooo und anderen:
Bei ein zweite gleiche Telefon hat es geklappt mit den Custom Scripts! Ich weiss nicht warum Ich bei der andere ein Fehler bekomme. Also, es liegt nicht an den Unoffical Lineage 14.1 rom!

Hallo Ihr,

guten Morgen, wo finde ich eine gute einleitende Erklärung zu eurem Script?

Mehr über den Scipts AFWall+: Wie ich persönlich die Android-Firewall nutze
Mein Wissen ist eher begrenzt, aber Ich versuche es zu verwenden um Google & Co aus mein Telefon zu halten.

AfWall+
Was muss ich einstellen, damit ich die Uhrzeit mit AfWall+ auf dem Netz beziehen kann?

-14 NTP Internet time server denke Ich

 

[Kyle Katarn]

Bei ein zweite gleiche Telefon hat es geklappt mit den Custom Scripts! Ich weiss nicht warum Ich bei der andere ein Fehler bekomme. Also, es liegt nicht an den Unoffical Lineage 14.1 rom!

Ich gratuliere dir, da hat sich deine viele Arbeit gelohnt :--))

Bei 32 hört er einfach auf und endet mit ein Fehler.

Wenn ich bei AFWall+ ein Profil "Alle Verbindungen aus" nehme - dort ist kein Programm berechtigt, eine Verbindung aufzubauen -, und nach UID sortiere (über das "umgekehrte Treppensymbol" oben rechts neben den 3 Punkten), werden erst einmal alle System-Apps und dann die installierten User-Apps aufgeführt.

Bei dir hakt es bei der Nr. 32.
Hier läuft Nr. 32 durch, braucht allerdings einige Sekunden. Nr. 33 braucht ebenfalls ein wenig Zeit.

Beim händischen Durchzählen ergibt sich für Nr.32 UID [10048]: PacProcessor
(unter der Voraussetzung, dass die Tasks bei AFWall+ in der Reihenfolge der UIDs abgearbeitet werden).
XDA-Developers hierzu: What is PacProcessor.apk? (Spekulation?!).

Nr. 33 wäre dann UID [10052] Print Service Recommendation Service.

---
Edit: Beide Services sind bei mir deaktivert, haben also keine Verbindung nach draußen.

 

[Kyle Katarn]

Eine kurze Ergänzung zu maloes ASN-Skript für AFWall+, zuletzt Beitrag #692:

Ein paar Tage später wollte ich die A-GPS-Daten mithilfe von SatStat wieder aktualisieren, allerdings klappte das nicht mehr. NetMonitor zeigte, dass SatStat hierzu nunmehr "fra15s29-in-f14.1e100.net" aufruft. Die zugehörige IP-Adresse laut NetMonitor ist 172.217.0.0.
Nach Auskommentierung dieser IP im Skript klappte es wieder.
Werde das mal weiter beobachten.

 

[Mumford]

@ooo und anderen:
Bei ein zweite gleiche Telefon hat es geklappt mit den Custom Scripts! Ich weiss nicht warum Ich bei der andere ein Fehler bekomme. Also, es liegt nicht an den Unoffical Lineage 14.1 rom!

Leider ist es dann doch nicht gelungen, Ich habe mich warscheinlich geirrt. Ich bekam zwar kein Fehler mehr, aber sah nicht dass Afwall nicht mehr angeschaltet war. Und er lässt sich auch nicht wieder anschalten.

Ich habe dann erst den Attachment von [MOD][APK+SCRIPT+ZIP] Enable Init.d for Any Phones w/o Need of Custom Kernels!!! installiert, resultat kein Testlog. Also danach Init.d App installiert um herauszufinden um Init.d zu aktivieren, leider endet der App bevor er es testen kann. Uni-initMit Titanium Backup sagt mir dass Busybox installiert ist. Jetzt weiss Ich es nicht mehr....

Edit:
@ooo & co
Wenn Ich den force-dns-ntp test script manuel eingebe, dann Ich eine andere Fehler, statt den 127 error:

Command '$IPTABLES -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 85.214.20.141.53' exited with status 2.
OUTPUT:
iptables v1.4.20: Bad IP address "85.214.20.141.53"
Try 'iptables -h' or 'iptables --help' for more information.

 

[ooo]

Leider ist es dann doch nicht gelungen

Ein LineageOS Custom ROM hat normalerweise bereits ein init.d-Verzeichnis. - Man muss das nicht manuell einrichten. - Fremde Lösungen können funktionieren, müssen es aber nicht. - Insbesondere One-Click-Lösungen sind oft fehlerhaft, weil sie nicht alle Situationen (Kombination Phone, ROM, Apps, Tweaks etc.) sauber abdecken und manchmal auch bereits total veraltet sind.

Wenn man in einem (unofficial) LineageOS Custom ROM bereits eine integrierte Superuser-Funktion hat (pre-rooted Custom ROM) und diese nachweislich nicht funktioniert, kann man diese integrierte root-Funktion evtl. ausschalten und dann das aktuellste SuperSU (von Chainfire) installieren (und sonst erstmal absolut nichts weiter; keine Apps, keine Tweaks, fremde Kernel & XPosed/Xposed-Module weglassen etc.). - Immer erstmal nur die blanke ROM verwenden.

Dadurch (SuperSU von Chainfire) kann man auch alle *eigenen* init.d-Scripte benutzen (einfach nur die *eigenen* init.d-Scripte von /system/etc/init.d/ nach /su/su.d/ moven; AFWall+ hat dazu eine Einstellung für den Pfad für afwallstart zum Datenleck-Fix und macht das dann automatisch).

AFWall+ hat eine integrierte, minimale Busybox, die man in deren Einstellungen aktivieren kann.
Eine zusätzlich installierte Busybox kann immer Probleme machen, mehrere parallel installierte sowieso (> erstmal weglassen).

Die Binaries iptables bzw. ip6tables liegen in einer (LineageOS) Custom ROM normalerweise unter /system/bin/. - Testen im Terminal kann man das mit dem Befehl which iptables bzw. which ip6tables. - Wird etwas ausgegeben, ist alles in Ordnung, sonst nicht.
(Auch hier hat AFWall+ eine Einstellung, welche iptables benutzt werden sollen: die von AFWall+ mitgebrachten eigenen oder die von der ROM ...)

Bei Fehlern sollte man alle Custom Scripts solange weglassen, bis die Firewall grundsätzlich läuft.

Wenn eine Custom ROM immer Probleme mit System-Rechten hat (auch bei anderen root-Apps), kann/sollte man die ROM wechseln.
(fehlerhafte Custom ROMs, die nicht zeitnah weiterentwickelt werden oder deren Entwicklung sogar eingestellt ist, sollte man nicht weiter benutzen ... nicht alle ROM-Developer haben die Skills, die Zeit oder die Lust, alle Fehler zu beseitigen ... dann steht man im Regen ...)

Als letzte Möglichkeit kann man sein Phone auch wieder auf die *originale* aktuellste Stock-ROM bringen (ohne irgendetwas anderes zu installieren) und dann nochmal *sauber* - wieder ganz ohne Zusätze - die gewünschte (oder eine andere) Custom ROM installieren. - Damit hat man auch die jüngste originale Firmware, die von Custom ROMs normalerweise *nicht* geändert wird (und sonst evtl. fehlt).

(Oder sich mit einer funktionierenden gerooteten Stock-ROM & AFWall+ begnügen ...)

Wenn das alles nichts bringt, anderes Phone besorgen (z. B. eines, das in der Liste der offiziell unterstützten Devices bei LineageOS steht).

Frohe Ostern!

 

[zcover]

@ooo
Hi, frohe Ostern, Du empfiehlst SuperSu von Chainfire, warum nicht Magisk?
[2018.3.28] Magisk v16.0 - Root & Universal Systemless Interface [Android 5.0+]

Was wäre bei Magisk zu beachten?

MfG
zcover

 

[ooo]

Weil SuperSU erstmal einfacher ist und sich auf die eigentliche Aufgabe konzentriert: root zur Verfügung stellen und sonst nix. - Und das auf einem höheren technischen Niveau (des Developers). - Magisk ist (inzwischen) ein Gemischtwarenladen/Rummelplatz (und für "normale" Anwender "unter der Haube" schwieriger zu kontrollieren).

Was wäre bei Magisk zu beachten?

Das hier.

 

[rudolf]

SuperSu ist seit 2.79 nicht mehr von Chainfire.

 

[ooo]

2.79

Yup, kann man hier bereits finden. - Man nimmt, was funktioniert (wenn man sich nicht damit beschäftigen will). - Mit den entsprechenden Konsequenzen ...

(Allerdings hatte Chainfire die Supervision über den Code bis zur 2.82 SR5; die Bezahl-Version ist im Google Play Store von den Chinesen CCMT - davon würde ich die Finger lassen ...)

___

Das hat aber alles erstmal nix mit AFWall+ zu tun, weil AFWall+ auf ein sauber gerootetes Phone aufsetzt ... back to topic ... (mea culpa)

 

[Mumford]

Wenn man in einem (unofficial) LineageOS Custom ROM bereits eine integrierte Superuser-Funktion hat (pre-rooted Custom ROM) und diese nachweislich nicht funktioniert, kann man diese integrierte root-Funktion evtl. ausschalten und dann das aktuellste SuperSU (von Chainfire) installieren (und sonst erstmal absolut nichts weiter; keine Apps, keine Tweaks, fremde Kernel & XPosed/Xposed-Module weglassen etc.). - Immer erstmal nur die blanke ROM verwenden.{/quote]

Titanium Backup gab schon eine Meldung dass den Pre-root vielleicht nicht zuverlässig funktionieren kann. Danke!

Frohe Ostern

 

[ooo]

Wenn Ich den force-dns-ntp test script manuel eingebe, dann Ich eine andere Fehler, statt den 127 error

Command '$IPTABLES -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 85.214.20.141.53' exited with status 2

Da muss ein Doppelpunkt (":") vor die hintere Portnummer 53 anstatt ein Punkt:

$IPTABLES -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 85.214.20.141:53

[doublepost=1522604753,1522603419][/doublepost]@Mumford - Anstatt

$IPTABLES -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 85.214.20.141:53

kannst du auch mal das hier testen:

/system/bin/iptables -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 85.214.20.141:53

wenn vorher im Terminal bei der Eingabe (als Test) von:

which iptables

das hier als Ergebnis ausgegeben wird:

/system/bin/iptables

(Phone neu starten nach Änderungen an Custom Scripts, nur zur Sicherheit ...)

 

[Mumford]

Jetzt bekomme Ich diesen Fehler:

Command '$IPTABLES -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 131.188.3.153' exited with status 2.
OUTPUT:
iptables v1.4.20: Bad IP address "131.188.3.220.153"
Try 'iptables -h' or 'iptables --help' for more information.

Fehlt dar jetzt auch ein ":"?

Edit:
@ooo

Die Binaries iptables bzw. ip6tables liegen in einer (LineageOS) Custom ROM normalerweise unter /system/bin/. - Testen im Terminal kann man das mit dem Befehl which iptables bzw. which ip6tables. - Wird etwas ausgegeben, ist alles in Ordnung, sonst nicht.

Gibt es.

(Auch hier hat AFWall+ eine Einstellung, welche iptables benutzt werden sollen: die von AFWall+ mitgebrachten eigenen oder die von der ROM ...)

Muss Ich dann bei Afwall den Iptables binary dann auf System iptables setzen oder besser auf automatisch? Änderungen haben bisher nichts gebracht.

Bei Fehlern sollte man alle Custom Scripts solange weglassen, bis die Firewall grundsätzlich läuft.

Ohne Custom scripts lief es ohne Probleme.


Andere Empfehlungen muss Ich noch testen.

 

[ooo]

Fehlt dar jetzt auch ein ":"?

Precies! ;-)

[...] --to-destination 131.188.3.1:53
[doublepost=1522606758,1522606247][/doublepost]@Mumford - Was du haben möchtest, ist aber vielleicht

[...] --to-destination 131.188.3.220:123

Also NTP-Server Port 123 der IP-Adresse 131.188.3.220 der Universität Erlangen (Zeitserver)?

Das sieht dann besser so aus:

### NTP-/Zeit-Server (Port 123) , *nicht* DNS-Server (port 53) = andere Zeile
$IPTABLES -t nat -I OUTPUT -p udp --dport 123 -j DNAT --to-destination 131.188.3.220:123

 

[Mumford]

Also, wenn Ich es richtig verstehe, diesen Regel
$IPTABLES -t nat -I OUTPUT -p udp --dport 123 -j DNAT --to-destination 131.188.3.220.153
ersetzen mit:
$IPTABLES -t nat -I OUTPUT -p udp --dport 123 -j DNAT --to-destination 131.188.3.220:123

Edit: Jetzt funktioniert es mit diese letzte Änderungen! Afwall bleibt an ohne Fehler! Daaaaaanke!
Edit2: Nächste Schritt: ausprobieren ob dieses Script auch als .sh Datei läuft.

 

[Kyle Katarn]

@Mumford
Nur ein grundsätzlicher Gedanke, leicht OT:
Es ist sinnvoll, vor der Installation eines Custom-ROM das Gerät auf den letzten Firmware-Stand zu bringen, also z.B. durch ein OTA-Update. Falls es dafür schon zu spät ist (also Custom-ROM schon installiert), könnten Anlaufstellen zum Auffinden von Firmware-Paketen z.B. Firmware Center oder die Foren bei xda-developers.com sein. Ob diese Quellen vertrauenswürdig sind, ist eine andere Sache ...

Aus den Update-Paketen lassen sich einzelne Firmware-Dateien, wie z.B. Bootloader und Modem, extrahieren und flashen. Anleitungen hierzu findest du im Forum.

Ich kenne mich mit Samsung-Geräten wie deinem leider nicht aus.
In der gerade aktuellen c't 8/2018 ab S. 174 gibt es einen längeren Artikel zum Rooting und zurück zum Stock-ROM am Beispiel von Samsungs Galaxy S5. Für Samsung-Firmware wird Updato aufgeführt. Wegen Vertrauenswürdigkeit siehe oben.

 

[Mumford]

@ooo & Co

Edit2: Nächste Schritt: ausprobieren ob dieses Script auch als .sh Datei läuft.

Wenn Ich das Skript als .sh lade aus data/media/0/Download/force-dns-ntp.sh dann bekomme Ich wieder die gleiche Fehler. Aber wenn Ich es nach /sdcard/ platziere dann geht es! Also es hängt davon ab wo die Datei gespeichert wird!

/sdcard/ ist nicht zu empfehlen, weil das Skript dann immer als root ausgeführt wird: ukanth/afwall Wo kann Ich es dann am besten platzieren?

Danke @Kyle Katarn
Werde mich später um den Firmware kummern.

 

[ooo]

Wo kann Ich es dann am besten platzieren?

Selber anlegen (nur Beispiel):

/data/local/afwall-scripts/​

oder in

/data/local/​

oder in

/system/xbin/

(hier werden die Scripts aber bei (OTA-)Updates wieder gelöscht)
​

oder, wenn mit SuperSU gerootet, in

/su/afwall-scripts/​

___

Nicht vergessen:
In AFWall+ die (neuen) Pfade/Lokationen in den Einstellungen zu "Custom Script" korrigieren.
Evtl. Phone neu starten.

 

[Kyle Katarn]

... Wo kann Ich es dann am besten platzieren?...

ukanth schreibt es selbst als Beispiel unter ukanth/afwall:

. /path/to/script.sh (e.g. . /data/local/myawesomescript.sh)

Bei mir liegen die Skripte für AFWall+ im Verzeichnis /data/local/afwall.
Dieses Verzeichnis hat die Erlaubnisse 755, ebenso alle darin befindlichen Skripte.
Owner/Group sind unbeachtlich.

/data/local hat den Vorteil, dass es bei System-Updates unverändert erhalten bleibt.
Die Endung .sh ist nicht unbedingt nötig. Sie zeigt nur an, dass es sich um ein Skript handelt.
Ohne die Endung wäre sie auch ausführbar bei 755.

 

[Mumford]

@Mumford
Nur ein grunsätzlicher Gedanke, leicht OT:
Es ist sinnvoll, vor der Installation eines Custom-ROM das Gerät auf den letzten Firmware-Stand zu bringen, also z.B. durch ein OTA-Update. Falls es dafür schon zu spät ist (also Custom-ROM schon installiert), könnten Anlaufstellen zum Auffinden von Firmware-Paketen z.B. Firmware Center oder die Foren bei xda-developers.com sein. Ob diese Quellen vertrauenswürdig sind, ist eine andere Sache ...

Aus den Update-Paketen lassen sich einzelne Firmware-Dateien, wie z.B. Bootloader und Modem, extrahieren und flashen. Anleitungen hierzu findest du im Forum.

Ich kenne mich mit Samsung-Geräten wie deinem leider nicht aus.
In der gerade aktuellen c't 8/2018 ab S. 174 gibt es einen längeren Artikel zum Rooting und zurück zum Stock-ROM am Beispiel von Samsungs Galaxy S5. Für Samsung-Firmware wird Updato aufgeführt. Wegen Vertrauenswürdigkeit siehe oben.

Noch eine kurze Frage: wenn mein PDA/Phone Nummer (Stock Rom) auf Updato aufgelistet ist, kann Ich dann davon ausgehen dass er dann schon auf den neusten Firmware geupdated worden ist? Ich habe mein Smartphone aus zweiter Hand, so Ich habe selbst diese OTA nicht gemacht.