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

Grundsätzlich ja. - Aber:

(Du weißt das Folgende ja bestimmt - ich führe es nur nochmal für andere aus.)

Wenn du ohne AFWall+ nur mit einem init.d-Script arbeitest, dann hast du keinen Mechanismus mehr, der beim Wechseln der Schnittstelle (W-LAN auf Mobile Daten und umgekehrt) die DNS-Server (nochmal) ändert, nachdem via DHCP der ISP-Provider die IP, die DNS-Server und (Default-)Routen gepusht hat.

AFWall+ besitzt die Funktion "Start-Daten-Leak Fix". Wird der Haken gesetzt, wird das Script /system/etc/init.d/afwallstart angelegt. Dieses Script wird beim Booten als letztes der im Verzeichnis befindlichen Scripte gestartet und sorgt erstmal nur dafür, dass alle iptables rules auf BLOCK ALL /DROP ALL gesetzt werden. Damit wird vermieden, dass irgendetwas nach draußen geht, bevor die App AFWall+ (bzw. deren Service) startet und deine eigentlichen Regeln setzt.

Wenn dann AFWall+ aktiv ist, setzt die App zum einen die Regeln für deine Apps (laut Profil-Haken) und führt ein - für das aktuelle Profil - evtl. von dir hinterlegtes Custom-Start-Script aus. - Dieses Script ist aber etwas anderes als das o. g. afwallstart-Script (!).

Das Custom-Start-Script des jeweiligen Profils enthält dann (mindestens) deine Rules für die DNS-Server.

AFWall+ hat in den Einstellungen zusätzlich eine Option "Aktive Regeln", um die iptables rules explizit nochmal zu setzen, wenn die aktive Schnittstelle geändert wird. - Das ist wichtig, da die vom ISP gepushten DNS-Server (net.rmnet0.dns1/2) ja unerwünscht sind und überschrieben/auf OpenDNS umgebogen werden sollen.

Ja, so wie ich das verstehe, werden ja in dem Script (dhcp conf) die Schnittstellen alle generisch über Variablen konfigurierbar gemacht.

Der "Hack" ist ja, dass du unmittelbar bevor die DNS-Server gesetzt werden, nochmal hardcodiert eingreifst, um die von dir gewünschten DNS-Server zu injizieren.

Diese conf wird jedesmal beim Wechseln der aktiven Schnittstelle aufgerufen, soweit ich weiß.

Wenn man Network Log installiert hat und unter "Log Service" die Haken bei "Iptables Watchdog" und "Protokollieren nach Hochfahren", sowie unter "Allgemeine Optionen" den Haken bei "Protokolliere hinter Firewall" aktiviert, kann man sehen, zu welchem DNS-Server die Anfragen gehen.
Dann Flugmodus AN, W-LAN AN, Protokoll löschen, rebooten, surfen, in Network Log im Protokoll nachsehen unter App "0 root > IP/Domain xyz > Port 53 DNS", dann Schnittstelle umschalten auf Mobile Daten, Protokoll löschen, surfen ... etc.)

Ich würde es einfach so ausprobieren.

Ich habe noch nicht bemerkt, dass irgendwann meine iptables rules bzw. DNS-Server abweichend geändert wurden. - Das muss jetzt aber erstmal nichts heißen.

Wie oben bereits gesagt: Ich würde es einfach ausprobieren und mit Network Log überprüfen.

Allerdings nicht beide Sachen gleichzeitig benutzen; also entweder ein AFWall+ Custom Start Script für DNS ODER den DHCP Conf Hack.

Wenn man sowieso AFWall+ einsetzt, dann kann man den DHCP Conf Hack auch weglassen, denke ich. - Man spart sich auch bei ROM Updates eine "Baustelle", die man nachziehen muss. - Wenn man alles ohne AFWall+ machen möchte, kann man natürlich auch eigene init.d-Scripts und den DHCP Conf Hack benutzen (den ich selbst aber noch nicht ausprobiert habe).

Falls du in dieser Richtung etwas testest, schreib uns doch bitte deine Erfahrungen, wenn du möchtest, damit die Leute es zu lesen bekommen. - Merci!

 

@katillah

Wie gesagt, ich kenne mich mit dieser Materie nicht besonders gut aus.
Wenn du aber schreibst, dass es in deinem Heimnetzwerk alles geht (insbesondere mit der Web Cam App), dann würde ich versuchen, mir eine VPN-Verbindung für unterwegs einzurichten, um so das Phone (und damit die App) quasi im Heimnetzwerk zu haben. - Das kann aber kompliziert werden.

Evtl. fehlen nur die richtigen Einstellungen bei der Cam oder im Router (Port Forwarding wirklich aller benötigten Ports) und/oder weitere Einstellungen in der App selbst? - Hast du auf dem Phone von unterwegs (zum Testen zuhause nur Mobile Daten einschalten) mal nachgesehen, was die AFWall+ alles blockt bzw., wohin die App verbindet (Netzwerk Log konsultieren)? - Auch dein Rechner hat eine Firewall und blockt evtl. Verbindungen von außen.

Edit: Falls du auf der Arbeit/unterwegs ein Firmen-W-LAN dafür benutzt, könnte es auch an der Firmen-Firewall liegen, da es der Firmen-Admin wohl eher nicht so lustig finden wird, wenn da alle möglichen Dinge ungenehmigt raus- und reingehen - er wird solche Sachen also blocken.

Ich kann dir leider remote konkret nicht viel helfen ...


Geh auch nochmal ALLE Punkte für die DVR Maschine durch:

DVR Viewer Setup | Local Network Connection | Remote Internet Connection

Auszug am Ende der Seite:

 

Ja, ein OTA-Auto-Update (nachts) wäre optimal als Upgrade für brain.apk ;-)

20-dns.conf:
Das die ISP-Einstellungen beibehalten werden bei der dns.conf hätte ich nicht gedacht. - Gerade bei Mobilen Daten erfolgt ja ein DHCP-Push der Einstellungen. - Evtl. wird zwar die rmnet0-Schnittstelle (Mobile Daten) aktiviert, dann aber zuerst die dns.conf ausgeführt und erst abschließend die vom Provider gepushten Werte übernommen?
(Auch stellt sich mir die Frage, ob getprop | grep -i dns uns die richtigen Werte anzeigt. - Ich habe gelesen, dass Java einen eigenen DNS Cache verwaltet, also die VMs/Sandboxes der laufenden Apps. - Wir schauen uns ja die Properties des Linux-Kernels an ... Fragen über Fragen ...)

Übrigens sind die gerade aktiven (benutzten) Werte unter net.dns1 und net.dns2 abzulesen (s. a. Beispiele bei @gene hier im Thread). - Mit ip link bekommt man in einer Shell die Schnittstellen; mit ip addr die IP-Adressen.

Ich setze meine W-LAN-IPs immer als Static, nicht mit DHCP. Beim Defy kann man mit einer statisch gesetzen IP dann auch den WiFi-Standard "n" benutzen, ohne die von früher her bekannten Verbindungsabbrüche (bei längeren Datentranfers etc.) zu bekommen.

AFWall+ Leaks/Rules:
Ich habe vor einiger Zeit bemerkt, dass z. B. die Swype-Tastatur (obwohl in AFWall+ geblockt) es irgendwie schafft, nach xyz.nuance.com (Swype Domain) eine Verbindung aufzubauen (nicht beim Start, sondern wenn die Firewall Regeln bereits in Kraft sind. Das ist allerdings über "-11 Linux Kernel" gegangen (siehe Network Log dazu).

Deswegen blocke ich inzwischen auch "-11 Linux Kernel" in AFWall+. Angeblich gibt es dann Einschränkungen (Retransmissions von IP-Packets, Performanceeinbrüche beim Surfen etc.), ich habe aber davon bislang nichts bemerkt und das Blockieren der unerwünschten Verbindungen (Swype) sind mir wichtiger.

init.d:
Das mit der fehlenden init.d-Unterstützung ist ja bei "unserer" ROM (CM 11 KK 4.4.4.) nicht der Fall. - Ich bezog mich hier im Start-Posting ja auch auf diese ROM. - Aber der Daten-Leak-Fix geht nur mit korrekter init.d und der Kernel muss es unterstützen. - Das ist absolut korrekt. - Ich habe das ja auch extra ausgeführt und auch einen manuellen Workaround beschrieben.

Geleakter Traffic:
Wegen der App, die Traffic beim Booten verursacht, obwohl alles geblockt ist:
Wenn man in den Apps nachschaut, was sie an (Hintergrund-)Datenvolumen haben, kann man sich leicht täuschen lassen. - Warum? - Das, was dort an Verbrauch protokolliert wird, ist Traffic, der gezählt wird BEVOR die iptables rules (also die firewall) greifen. - Ein Teil dieses gezählten oder sogar der gesamte Traffic muss nicht notwendigerweise auch das Phone verlassen haben ... (deswegen auch der Haken bei "Hinter Firewall protokollieren" in Network Log, um nur den tatsächlich das Phone verlassenen Traffic zu sehen).

Falls nocht nicht bekannt:
Den W-LAN-Traffic bekommt man (in CM 11 KK) auch mit, wenn man in Einstellungen > Datenverbrauch > über die Menü-Taste > die Option "WLAN-Nutzung anzeigen" anhakt.

Und ja, ich bin ebenfalls ein "Fan" von iptables/AFWall+ und Netzwerk Log ...

 

Google Apps/Services

Ich habe keine GApps installiert und blocke über /system/etc/hosts entsprechende Domains (AdAway et al.). - Bestimmte IPs kann man auch im AFWall+ Custom-Start-Script als iptables rule einzeln oder als range (Bereich) blocken (z. B. alle Facebook-IPs, zu denen Verbindungen aufgebaut werden sollen).

Wenn ich eine App benötige, die mich interessiert oder ich ein Update einer App brauche, dann mache ich das über ein Extra-Phone mit GApps/Play Store, das ausschleßlich dafür da ist, Apps zu installieren/aktualisieren. - Die App (.apk) packe ich dann via copy & paste auf das Ziel-Gerät.

Apps, die die Google Services benötigen, benutze ich schon lange nicht mehr (mit den entsprechenden Nachteilen, aber auch Vorteilen).


Disable Services

Ja, "Disable Services" ist ein nettes Tool, aber eher etwas für Masochisten mit zuvel Zeit (joke). - @okij und @1ceb0x haben da auf xda im Quarx-Thread einiges in mühseliger "Handarbeit" zusammengetragen bzgl. Google-Services/-Receivers/-Listeners.


IP 173.194.113.158

Den 1000er-User blocke ich immer.
https://github.com/ukanth/afwall/issues/179

Spoiler

Dadurch kann ich zwar keine Location Based Services (Standort via W-LAN-SSID/Funkmasten) benutzen - diese mich aber auch nicht. - Außerdem sind auch evtl. andere Verbindungen möglich, die ich bis jetzt nicht interpretieren kann. - Der system-User ist der mächtigste nach root.

(Zumindest früher) war die IP 173.194.113.158 mal der Google Tag Manager (Tracking, Advertising Tools für Werbetreibende, Developer) und wird evtl. von (älteren?) Apps als hardcodierte IP immer noch benutzt?
googletagmanager.com is worth $ 248,400.00 - ViewWebStats.com

Auf NVISO ApkScan - Scan Android applications for malware kann man eine apk-Datei hochladen und sie auseinander nehmen lassen.

Hier 2 Beispiele (nicht von mir):

(Im Abschnitt "Opened network connections" unter "Network activity" des Reports sieht man dann genau die von dir registrierte Google-IP.)

NVISO ApkScan - malware analysis report (Aeon Icon Pack v2.5.7 - android-zone.org.apk)
NVISO ApkScan - malware analysis report (com.andromo.dev2.app217299.apk)

Da es verschlüsselte HTTPS-Verbindungen sind, kann man den Inhalt nicht interpretieren.


"Petzendes" A-GPS

Vielen Dank für den Link auf die A-GPS-Problematik. - Das hatte ich zwar bereits geahnt, aber jetzt ist es sicher. - Die Info ist sehr nützlich!

 

Erstmal die Möglichkeiten:

• Bei DHCP (W-LAN) werden (zunächst) die DNS-Server des Routers verwendet
• Bei statischer IP (W-LAN) immer die dort unter DNS1 und DNS2 eingetragenen Server (IPs)
• Bei DHCP (Mobile Data, also unterwegs ohne W-LAN/Hotspot) werden die DNS-Server des Providers der SIM verwendet

Wenn in AFWall+ das im Start-Posting beschriebene Custom-Script verwendet wird, dann wird in allen genannten Fällen immer der dort eingetragene Server verwendet (im Beispiel OpenDNS), egal, was der Provider oder ein W-LAN-Router gerne so alles möchte ...

DNS-Server-Priorität (bei W-LAN) ist also (höchste oben):

1. DNS-Server im AFWall-Custom-Script
2. W-LAN mit Option "Statische IP" im Phone (mit eingetragenen DNS-Servern; wichtig: immer zwei und immer unterschiedliche IPs eintragen)
3. DNS-Server, die bei DHCP vom W-LAN Router kommen

Tipp:

Ich würde im W-LAN (mit und ohne AFWall-Custom-Script) immer eine statische IP und die OpenDNS-Server im Phone fix einstellen, auch, wenn der Router via DHCP eine IP und die DNS-Server automatisch vergibt. - Dazu einfach die gerade aktive DHCP-IP des Phones so stehen lassen und auf "Statische IP" umstellen. - Dann die entsprechenden IPs für Router (Gateway) und DNS1/2 (OpenDNS) eintragen und speichern. - Danach einmalig W-LAN AUS und wieder AN (oder Flugmodus AN und dann wieder AUS).

Wenn ihr in einem fremden W-LAN seid, könnt ihr das dann übrigens genauso machen (nach Verbindung zum fremden Router auf "Statisch" und DNS-Server DNS1/2 auf z. B. die IPs von OpenDNS setzen). - Danach einmalig W-LAN AUS und wieder AN (oder Flugmodus AN und dann wieder AUS).

 

Falls du in deinem Router die Einstellung für den oder die DNS-Server-IPs machen kannst, ist das nicht verkehrt und wird die Funktionalität nicht beeinträchtigen. Schreib dir halt die IPs (allgemein alle Einstellungen) ab, bevor du etwas änderst, damit du es wieder zurücksetzen kannst, falls es doch Probleme geben sollte (oder mach Screenshots vom Web-Interface des Routers).
Zwei Dinge dazu:

1. Der Internet-Provider kann u. U. (immer) von außen in den Einstellungen deines Routers herum-ändern, wenn er das will (ob von dir evtl. gesperrt oder nicht). - Zumindest würde ich davon ausgehen.
2. Ich würde es trotzdem immer vorziehen die DNS-Server auf den End-Geräten (zusätzlich) so einzustellen, wie in #90 beschrieben (Das gleiche gilt auch für PC/Notebook/Fernseher etc.). - Auch statische IP-Adressen manuell verwalten in allen Geräten (das ist aber einmaliger Aufwand).

 

Das geht nicht. - Mit der Donate-Version von AFWall+ kann man zuvor exportierte Einstellungen und Profile wieder importieren, hat aber immer noch nichts verändert.

Die exportierten Profil-Dateien (auf SD Card) sind reine (XML-)Text-Dateien und *könnten* evtl. entsprechend kopiert/angepasst werden. - Um diese dann wieder zu importieren, braucht man die Donate-Version.

Tipp:
Die Donate-Version kann man sich vllt. auch sparen, wenn man die aktiven (Profil-)Dateien im Verzeichnis /data/data/dev.ukanth.ufirewall/shared_prefs/ entsprechend behandelt ...

Vorher ein Backup machen, dann erst mit den Dateien arbeiten.

 

Das (Standard-Profil) steckt in der Datei /data/data/dev.ukanth.ufirewall/shared_prefs/AFWallPrefs.xml drin.

 

Doch, die Firewall "merkt" sich, dass sie aktiviert wurde.

Auch ein Reboot übersteht die gemachte Einstellung (= Firewall-Einstellungen-Menü > Firewall aktivieren).

Um gleich visuell zu erkennen, ob die Firewall aktiv oder deaktiviert ist, kann man unter Firewall-Einstellungen-Menü > Einstellungen > Mitteilungssymbol anzeigen den Haken setzen und erhält dann ein

• rotes Symbol (Firewall ist deaktiviert) oder ein
• grünes Symbol (Firewall ist aktiviert)

in der Benachrichtigungs-Leiste permanent angezeigt.
___

Fehlender Start-Datenleck Fix nach (OTA-)Updates

Spoiler

Was @dmasu meint, ist, dass nach einem (OTA-)Update der ROM der Haken unter Firewall-Einstellungen-Menü > Einstellungen > Start-Datenleck Fix fehlt. - Auch sein Hinweis auf einen Taskkiller o. ä. ist sehr gut (Greenify?).

Dieser (wichtige!) Haken sorgt dafür, dass solange nichts ins Internet kann, bis die Firewall nach einem Start des Phones selbst gestartet ist, sich aktiviert und die Regeln setzt.

(Die Firewall startet sich aber immer bei jedem Reboot, wenn sie korrekt installiert und eingerichtet wurde.)

Tipps:
Nach jedem (OTA-)Update nachsehen, ob der Haken für den Start-Datenleck fix noch gesetzt ist.

Oder - noch besser - für die durch das Haken-Setzen angelegte Datei /system/etc/init.d/afwallstart ein "Überlebens"-Script im Verzeichnis /system/addon.d/ anlegen, damit die Datei ein (OTA-)Update automatisch "überlebt".

Lösung: Überlebens-Script? - Wie geht das denn?

Spoiler

(Hinweis: Beschreibung für Cyanogen-ROMS, hier CM11 - andere ROMs haben entweder die identische Funktionalität, oder andere Lokationen/Mechanismen oder haben es evtl. nicht.)

Ganz einfach:

• CM Filemanger als root öffnen
• Ins Verzeichnis /system/addon.d/ wechseln
• Auf der Datei 50-cm.sh mit langem Touch das Menü öffnen
• Hier "Kopie erstellen" antippen (> Neue Datei "Kopie von 50-cm.sh")
• Diese neue Datei dann in z. B. 98-myfiles.sh oder 98-save-my-ass.sh umbenennen
• Die Datei dann öffnen
• Die Zeile
  
  Code:

  etc/hosts

  suchen (zwischen cat <<EOF und EOF) und löschen
• Dann die folgende Zeile dort eintippen
  
  Code:

  etc/init.d/afwallstart

  Neben-Tipp: Man kann dort in jeweils einer neuen Zeile weitere Dateien schützen (z. B. eine geänderte etc/gps.conf oder etc/resolv.conf etc.), aber immer nur von der system-Partition. - Das sähe dann so aus:
  Code:

  ...
  cat <<EOF
  etc/init.d/afwallstart
  etc/gps.conf
  etc/resolv.conf
  EOF
  ...

• Die Datei dann abspeichern
• Berechtigungen der Datei nochmal überprüfen
  (root:root -rwxr-xr-x bzw. 755)

Überlebens-Script: Was macht diese neue Datei jetzt eigentlich genau?

Spoiler

Bei einem (OTA-)Update werden nicht zur ROM gehörige (bzw. manipulierte) Dateien gelöscht. - Das kennt fast jeder und ist leider ziemlich doof

Abhilfe:
Das Verzeichnis /system/addon.d/ und die darin enthaltenen Dateien sind vor ROM-Updates (Löschung) geschützt (auch die weiter oben neu angelegte Datei 98-myfiles.sh, also das "Überlebens"-Script).

Alle im Verzeichnis /system/addon.d/ liegenden Dateien (sofern ausführbare .sh-Dateien) werden bei einem Update zweimal aufgerufen: Das erste Mal, um die in ihnen vermerkten Dateien vor dem Überschreiben der ROM an eine sichere Stelle wegzukopieren (Backup). Das zweite Mal, um - nach dem ROM-Update - die zuvor gesicherten Dateien wieder an deren alten Platz zu kopieren (Restore).

Ihr kennt das z. B. von den Google Apps: Diese "überleben" automagically ein (OTA-)Update der ROM. - Das verdanken sie allerdings ebenfalls einem, im Verzeichnis /system/addon.d/ bei der Installation der GApps abgelegten Script, das genau das gleiche macht (wer GApps hat, kann bei Interesse mal nachsehen ...).

Die neu angelegte Datei sorgt also dafür, dass die Datei /system/etc/init.d/afwallstart ein Update überlebt, und dadurch, dass das Phone auch nach einem (OTA-)Update zwischen dem Booten und dem Starten der Firewall weiterhin geschützt bleibt.

Das alles funktioniert natürlich nur dann, wenn die system-Partition NICHT gewipet wird, da ansonsten auch die Dateien im Verzeichnis /system/addon.d/ wieder weg sind.

Letzter Tipp:
Wer auch diesen Fall (system-Wipe) abdecken möchte, kann sich zusätzlich ein init.d-Script in /data/local/userinit.d/ anlegen (z. B. 98-afwallstart-repair) und die Datei /system/etc/init.d/afwallstart einmalig nach /data/local/afwallstart kopieren. - Ist /data/local/userinit.d/ nicht vorhanden, muss man sich das Verzeichnis als root anlegen (Berechtigungen setzen: root:root -rwxr-xr-x bzw. 755).

(Auch die neu angelegte Datei /system/addon.d/98-myfiles.sh lässt sich übrigens so ebenfalls wieder elegant herstellen. - Dazu muss diese auch vorbereitend nach /data/local/ kopiert werden.)

Das Script 98-afwallstart-repair (root:root -rwxr-xr-x 755) sollte dann Code enthalten, der die Datei /data/local/afwallstart nach /system/etc/init.d/afwallstart kopiert- ungefähr so:

Code:

#!/system/bin/sh
# this is the script /data/local/userinit.d/98-afwallstart-repair
# (permissions root:root -rwxr-xr-x 755)
# it takes care, that the AFWall+ Firewall is correctly blocking network
# traffic at boot time (see data leak fix)

# we want to write to the system partition
mount -o remount,rw /system

# take care that (OTA-) updates do not break AFWall firewall security
cp /data/local/afwallstart /system/etc/init.d/afwallstart
chown root:root /system/etc/init.d/afwallstart
chmod 555 /system/etc/init.d/afwallstart

# take care that system wipes do not harm our tweaks
# as example we use the script file name "98-myfiles.sh"
# for this, uncomment the following 3 lines = remove the "#"
#cp /data/local/98-myfiles.sh /system/addon.d/98-myfiles.sh
#chown root:root /system/addon.d/98-myfiles.sh
#chmod 755 /system/addon.d/98-myfiles.sh

# lock up system partition read-only
mount -o remount,ro /system

Die Ausführung erfolgt dann automatisch bei jedem Start und ist etwas für "Paranoiker", die auf Nummer sicher gehen möchten.

 

@kowalski84 - Schwierig von hier aus.

"0: root ..." ist zusätzlich auch für Mobile Daten (in Spalte 3) angehakt?
Für die DNS-Anfragen, um die Server (IPs) der angesurften Seiten (Domains) zu finden.