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

[anonymousdark]

@ 000

Spoiler: OT Serv

Möchte das ganze ja erstmal testen, bzw. bin ja dabei. Wenn das hinterher dann zu Pflegeintensiv (Sicherheit/ Updates /Upgrades/ Backups) ist, dann bringt mir das nichts (zu zeitintesiv). Also kann man bspw. auf ein ArmBoard, auf dem Debian & Owncloud installiert/eingerichtet sind, kann zusätzlich Jabber/XMPP, Vpn, E-mail-Serv. (einfach) installieren/ einrichten?

 

[ooo]

Also soll ich DNS über netd de/aktivieren auf automatisch lassen?

Sorry, aber ich habe den Link gesetzt, weil ich mich mit der Tethering-Problematik nicht groß beschäftigt habe (Samsung-Geräte kenne ich nicht bzgl. der Thematik). - Das Beste ist in deinem Fall vllt., du fragst beim Entwickler oder z. B. im XDA-Forum zu AFWall nach.

___

Also kann man bspw. ... (einfach) installieren/ einrichten?

Ja. - Aber "einfach" wird es - je, nach dem - nicht, der Weg wird eher lang, kalt, blutig und tränenreich sein ... das kann ich dir versprechen ... (joke)

 

[N008]

Ich habe ein Problem mit AFwall+ 2.2.1 vom 02.03.2016 aus dem F-Droid Store. Seit dem Update hat das hier auf der ersten Seite unter Punkt 3.2.1. beschriebene Custom Script zur Einrichtung eines alternativen DNS Dienstes zufolge, dass sich die Firewall deaktiviert, sobald das Script gespeichert wird. Ein Klick auf "Firewall aktivieren" bleibt erfolglos - die Firewall bleibt deaktiviert und blockiert sämtlichen Netzwerkverkehr von meinem Moto E 2015 im heimischen WLAN.

 

[ooo]

Was passiert, wenn man das Custom Script entfernt? - Oder nur die DNS.Regeln auskommentiert? - Jeweils Phone neu starten. - Alte Version wieder installieren würde erstmal helfen.

Ist das Custom Script evtl. verändert worden (ein "dummer" Fehler hat sich eingeschlichen)?
Bei mir läuft die neue Release 2.2.1 ohne Fehler.

 

[N008]

Wenn ich das Script auskommentiere bzw. ein ungenutztes Profil aktiviere, in dem kein Custom Script eingetragen ist, kann ich die Firewall problemlos aktivieren. Neustart und Cache-wipe habe ich bereits durchgeführt. Ich versuche es jetzt erst einmal mit der Vorgängerversion.

Update: Ich habe die Version 2.2.1 gelöscht, den Cache erneut gewipet, Version 2.1.3 installiert, vollständig eingerichtet (das Custom Script per copy 'n' paste) sowie (erfolgreich) getestet und dann auf die neue Version aktualisiert. Jetzt läuft wieder alles. Danke fürs Beispringen zu so später Stunde.

 

[an0n]

Seit dem ich auf CM13 bin, funktioniert das custom-DNS script über Afwall nicht mehr (nur UID 0 wird umgeleitet). Ich überleg jetzt mir custom-DNS über OpenVPN-verbindung einzurichten, einige VPN-Provider haben eigene DNS-server. Ich frag mich:
1) Muss ich über die OpenVPN-App beim einrichten einer VPN-verbindung DNS-IPs einstellen, oder ist es vom VPN-Provider bereits im Server eingestellt?
2) Habe gelesen, dass eine VPN-verbindung über UDP schneller ist als TCP, TCP soll aber sicherer sein. Die ISPs und besuchte Webseiten können anhand des VPN-UDP ports erkennen, dass man VPN benutzt bei TCP (port 443) ist es nicht direkt erkennbar und Emailserver können übrigens auch nur über TCP ports empfangen werden.) Wenn ich also TCP benutze, kann ich alle UDP ports blocken (ausser eventuell port 53 für custom-DNS)?

 

[N008]

Hier sind deutsche opennic-DNS:
185.97.7.7
5.9.49.12
78.138.97.93

Soweit ich weiss kann man auch garnicht via custom-DNS mit Hotspots, Hotel- oder Uni-Netzwerken verbinden, da hat das interne Netzwerk eine zugewiesene DNS.

Verstehe ich das richtig, dass die Einstellung "DNS über netd deaktivieren" sowie das Einbinden eines alternativen DNS Dienstes (in meinem Fall der hier empfohlene DNS.WATCH) per custom script dem Zwischenschalten eines Proxies zwischen meinem Smartphone und der Außenwelt gleichkommt? Ähnlich dem oben zitierten Beitrag habe ich bei manchen öffentlichen Hotspots das Problem, dass das Captive Portal des Netzwerkbetreibers nicht immer gefunden wird. Bei der Telekom etwa werde ich bei der Eingabe einer beliebigen URL auf eine vorgeschaltete Seite zur Authentifizierung geleitet. Hingegen beim Anbieter Wall etwa, der der eingegebenen URL das Präfix "wifi.wall/authen/?Host=" vorsetzt, funktioniert das Auflösen der URL nicht.

Gibt es eine Möglichkeit, AFWall+ so zu konfigurieren, dass die Namensauflösung lokal im jeweiligen Netz "bevorzugt" wird? Oder einen walkaround, dass ich unterwegs nicht "die Hosen runter lassen muss" (DNS über netd auf auto, custom script auskommentieren, Neustart), falls ich mich in einen öffentlichen Hotspot einwählen möchte?

Die Domäne "fritz.box" meines Routers findet/kennt der gewählte DNS Dienst natürlich nicht. Aber ich habe in diesem Router bereits einen DNS Server eingetragen. Brauche ich also zusätzlichen den Eintrag in meinem Smartphone und das Deaktivieren des DNS Proxies? Oder verwendet Android/Cyanogenmod stets den Google-DNS, auch wenn ich in meinem Router einen eigenen Server eingetragen habe bzw. der Betreiber eines öffentlichen Hotspots wiederum einen eigenen gewählt hat?

 

[an0n]

Das dns ist nur für adressauflösung da bzw. wenn eine webseite/ip geföffnet wird. Es ist kein proxy bzw. verbindung die traffic umleitet. Da standardmäßig der ISP das macht und die aufgelösten IPs loggt und ggf.zensiert, werden sichere dns gewählt.

Das zitierte dns-eintrag ist von opennic (nicht zu empfehlen, da es oft offline geht).
Das deaktivieren des 'dns via netd' sollte verhindern das das netd-programm die dns-auflösung veranlasst bzw. dass der Kernel es statdessen macht, da netd datenlecks verursacht und den port 53 beansprucht. Ab android 6/cm13 scheint diese funktion in afwall wohl nicht zu funktionieren (bei mir zumindest nicht).

Das Captive Portal Login bzw. das automatische Hotspot-Login gehört zu Google, man sollte es deaktivieren/löschen (da es sich mit googleservern immer verbindet) und sich stattdessen manuell einloggen.

Wenn man sich mit einem Hotspot verbindet, dann übernimmt ja deren Netz das dns-auflösen bzw. es wird umgeleitet oder es kommt zu gar keiner verbindung (war in einem hotspot, das ich mit custom-dns testete). Es macht in dem Fall also keinen Sinn das am Phone da einzustellen. Bei WLAN bzw. Verbindung mit eigenen Router muss man das in den Router-Einstellungen via PC-Verbindung machen.

Bei Hotspots ist man ausserdem dem Betreiber gegenüber immer nackt, falls es kostenpflichtig ist, schliesslich hat derjenige ja die Anmeldungsdaten.
Alternativ mache ein Profil in afwall für Telefonnetz mit customdns und eines für Hotspots ohne.

 

[N008]

Soweit habe ich das alles verstanden und AFWall+ so konfiguriert, dass ich mich auch in öffentlichen Netzen anmelden kann. Ich weiß nicht, ob sich in den letzten releases etwas geändert hat, aber ich musste zwingend den Browser auch in der Spalte LAN die Kommunikation nach außen erlauben, da sonst laut Log von AFWall+ das Auflösen lokaler Domänen blockiert wurde. Damit hatte ich vorher keine Probleme.

Muss ich eigentlich zwingend neustarten, wenn ich zwischen zwei Profilen mit und ohne custom script für einen alternativen DNS Server wechsle? Das Auflösen bereitet dann nämlich wieder Probleme. Ich vermute, das liegt am Cache, oder?

Die Tage bin ich außerdem wieder auf ein altes Problem gestoßen, weshalb ich überhaupt mein Moto E gerootet und mit CM 12.1 sauber aufgesetzt und mit AFWall+ abgesichert habe. Beim Checken meiner Verbindungsübersicht stieß ich wieder auf das Muster, das ich hier bereits beschrieben habe: Surnia (LTE) - Moto E funkt ungefragt nach draußen
Jeden Tag bis jeden zweiten Tag werden in kurzen Abständen zwei Verbindungen aufgebaut und je 1 KB große Datenpakete ausgetauscht. Selbst wenn ich im heimischen WLAN bin, wird diese Verbindung über das deaktivierte, mobile Netz aufgebaut. Das Protokoll von AFWall+ meldet keinen Traffic. Ich habe mir nun einmal Network Log aus dem F-Droid-Store installiert und werde mal den Traffic ein paar Tage loggen und vergleichen. Ich kann mir diese Verbindungen leider nicht erklären?!

 

[York]

Hallo zusammen,

ich probiere derzeit sämtliche Sicherheitseinrichtungen für systemless root anzupassen, d.h. den System Ordner in keinster Weise zu verändern. Ich habe bereits mit Hilfe von [APP][Root][2.1+][UNOFFICIAL] AdAway v3.1 :: [10.09.2015]
erfolgreich system/etc/hosts auf su/etc/hosts verlinken können. Mit einer kleinen Anpassung des mitinstallierten Start-Scripts, in ähnlicher Form system/etc/resolv.conf zu su/etc/resolv.conf verknüpft.

Bei jedem Start des Geräts wird dann immer
mount -o bind /su/etc/hosts /system/etc/hosts;
mount -o bind /su/etc/resolv.conf /system/etc/resolv.conf;
ausgeführt

Jetzt hat man in Afwall nun die Möglichkeit die Iptables Binaries auf Built-in zu setzten anstatt die des Systems (die in system/bin/iptables liegt) zu nutzen. Hätte das irgendwelche Nachteile?

Oder könnte ich evtl. genauso wie bei der Hosts und resolv.conf Datei vorgehen? Also die Original iptables z.b. nach su/bin kopieren und per mount bind auf system/
bin/iptables?

 

[mratix]

@York irgendwie blicke ich da nicht durch, wo der Sinn der Modifikationen sein soll.

Vor allem warum das ganze so umständlich? Wo ist der Unterschied beim bind vs. symlink?

 

[York]

Chainfires systemless root ab Android 5.1.1 ist so gedacht, dass das Gerät gerootet wird, ohne irgendwelche Veränderungen am System Ordner vorzunehmen. Das ermöglichte z.B. bis vor Kurzem das Nutzen von Android Pay (US Nutzer) trotz vorhandenem Root oder vereinfacht wohl OTA updates falls gewünscht. Statt system neu zu flashen, muss man für OTA wohl nur das boot image flashen. Hier zwei Artikel für weitere Informationen:

Chainfire Releases Systemless Root For Android 6.0

Google Nexus Devices Systemless Root – VigilCode Blog

Da Chainfire, soweit ich das mitbekommen habe, dies als Default-Root-Methode vorgesehen hat für aktuelle und zukünftige Versionen, versuche ich mein eigenes Nutzungsverhalten was Android-Anpassungen betrifft daran zu gewöhnen, ebenfalls system nicht anzurühren. Es ist also eine reine Glaubenssache und experimentelle Neugierde, warum ich das mache ;-) Und insgesamt ist es irgendwo auch eleganter, keine Anpassungen an dem System Ordner vorzunehmen und stattdessen solche Workarounds zu nutzen.

Das oben verlinkte Adaway Skript bewirkt, dass man eben nicht mehr auf system/etc/hosts schreibt, sondern nur Adaway in dem Glauben lässt, es würde auf system/etc/hosts zu schreiben, stattdessen wird aber auf su/etc/hosts zugegriffen. Und außerdem kann man statt ooo's init.d Mod zu nutzen, seine Startskripts einfach in su/su.d ablegen. Afwall+ erkennt sogar systemless root inzwischen und kriegt das sogar selber beim Häkchen setzen hin, dass das Startskript genau dort abgelegt wird.

Zum Unterschied zwischen bind und symlink kann ich dir leider nichts sagen, da ich es nicht so sehr mit den Linux Befehlssätzen habe.

Mit den iptables werde ich es in den nächsten Tage einfach mal probieren wie es läuft, wenn ich diese nach su/bin kopiere und mit mount bind auf system/bin/iptables verweise.

Aber anderes Thema: Wer von euch nutzt Verschlüsselung und Root parallel? Hab irgendwo mal gelesen, man müsste den su daemon zum Verschlüsseln deaktivieren und danach wieder aktivieren? Hat da jemand erfahrung mit einem verschlüsselten System und den ganzen Sicherheitsapps? Funktioniert das Zusammenspiel reibungslos oder muss man sich auf Probleme gefasst machen?

 

[fireburner]

Bezüglich encryption: Bei CyanogenMod geht das einfach aus dem Menü heraus, ohne das man etwas zusätzlich machen müsste. Hatte es mit CM11 mal probiert. Bei meinem Gerät ist es aber sinnlos, da dass i9100 eine separate Partition für die sdcard hat, die nicht verschlüsselt wird und somit nur die App Daten in /data verschlüsselt sind.
Macht ergo nur Sinn bei Geräten mit emhlierter Sdcard unter /data/sdcard.

 

[ooo]

Jetzt hat man in Afwall nun die Möglichkeit die Iptables Binaries auf Built-in zu setzten anstatt die des Systems (die in system/bin/iptables liegt) zu nutzen. Hätte das irgendwelche Nachteile?

Nein, aber das ist unnötig, wenn die ROM eigene iptables hat (/system/bin/ip..."). AFWall+ bringt eigene iptables/ip6tables-binaries in der App mit und benutzt diese, wenn keine system-binaries vorhanden sind, mit der EInstellung "Auto". (s. a. AFWall+-Einstellungen, und "/data/data/dev.ukanth.ufirewall/...")

• "System iptables" sind die ROM-eigenen
• "Built-In iptables" sind die, die AFWall+ selbst mitbringt

Oder könnte ich evtl. genauso wie bei der Hosts und resolv.conf Datei vorgehen? Also die Original iptables z.b. nach su/bin kopieren und per mount bind auf system/
bin/iptables?

Das ginge technisch zwar, ist aber unnötig und eine weitere potenzielle Fehlerquelle.

<OFF TOPIC>

Aber anderes Thema: Wer von euch nutzt Verschlüsselung und Root parallel? Hab irgendwo mal gelesen, man müsste den su daemon zum Verschlüsseln deaktivieren und danach wieder aktivieren? Hat da jemand erfahrung mit einem verschlüsselten System und den ganzen Sicherheitsapps? Funktioniert das Zusammenspiel reibungslos oder muss man sich auf Probleme gefasst machen?

Root und Verschlüsselung haben erstmal nichts miteinander zu tun. - Die Information "SuperSU-Daemon ausschalten" hängt ohne den exakten Kontext (Situation) völlig in der Luft und ist nicht bewertbar. - Ich hatte noch nie durch root bedingte Probleme mit der Geräte-Verschlüsselung.

(Wer auf Nummer sicher gehen möchte, verschlüsselt sein Gerät bzw. dessen data-Partition zunächst ungerootet in der Stock-ROM und rootet danach oder installiert sich eine Custom ROM. - Die data-Partition bleibt i. d. R. verschlüsselt - auch nach einem Wipe in TWRP. - Erst mit TWRP > Wipe > Format Data ist auch die Verschlüsselung wieder weg ...)
</OFF TOPIC>

 

[wewede]

Ich drücke mal ein kurze Frage dazwischen (ich habe zwar den ganzen Thread fast von Anfang an mitverfolgt, aber einen Teil doch wieder vergessen und alles nochmal lesen...):
Warum brauchen "Apps, die Rootrechte benötigen" unbedingt Internetberechtigung, damit ich ins Internet komme?

Danke,
W.

 

[ooo]

Das sind keine (Android-Root-)Apps, die Root-Rechte benötigen, sondern der Betriebssystem-User (Linux) mit der User-ID "0" = Username "root" (unterhalb von Android, System-Programme, z. B. DNS-Resolver = KEINE Android-App) und verwirrt die Leute nur ...

Wenn man in den Einstellungen von AFWall+ den netd-Daemon (Binaries > DNS Proxy) ausschaltet, muss man "(0) root" in das Internet lassen, damit das DNS funktioniert (Auflösung Domain-Namen nach IP-Adressen).

 

[Pizzapeter]

Hi
habe 2 Probleme, das erste ist: Habe vermutlich (weis ich nicht mehr) meine AFWall+, damals nach dem Rooten meines Defy+, aus dem Playstore installiert. Inzwischen hab ich CM11, und nicht mehr so viel Lust was aus dem Playstore zu holen, also hab ich versucht die AFWall+ mit F-Droid zu aktualisieren, mit der Meldung, siehe Screen. Habe Version 1.3.4.1.
Ist es wirklich erforderlich die alte erst zu deinstallieren, um dann erst die Neue zu installieren? In der Zwischenzeit könnten diverse Apps die ich inzwischen habe, ins Netz....

Problem 2: Meine Lieblings-Gastronomie hat ein neues Wlan Netz mit Sicherheitsvorkehrungen, das niemand etwas Downloaden kann... so sagte es der Chef. Mein Habbit Browser wird von der Firewall geblockt, weil er auf eine andere ip Adresse, als die, die im Script steht zugreifen will oder so ähnlich
Nun hab ich gedacht, vielleicht das Script zeitweilig zu deaktivieren, oder löschen und voher speichern, geht nicht, oder doch? Oder ein zweites Profil ohne Script, geht das?

 

[fireburner]

Zu Punkt 1: ja leider musst du erst deinstallieren und dann von F-Droid neu installieren. Aber wie du ganz ohne Unterbrechung vorgehen kannst, weiß ich leider auch nicht.

 

[Miss Montage]

Notfalls kann man sich die .apk herunterladen und manuell installieren, während das Gerät im Flugmodus ist.

 

[fireburner]

Das wäre eine gute Idee, nur bin ich mir nicht sicher, ob dann über F-Droid geupdatet werden kann.
Aber eigentlich müsste ja die apk auf der F-Droid page mit dem selben key signiert sein.