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

[dmasu]

Hi ooo,

wie immer von Dir eine super recherchierte und verständliche Anleitung

Zum folgenden Punkt:

Tipp zu DNS und AFWall+:

Wer etwas noch Zentraleres auf dem gerooteten Phone haben möchte, der kann auch AFWall+ verwenden und dort im Menü Einstellungen unter Punkt "Skript festlegen" im ersten Feld die folgenden Zeilen (jede Zeile dabei ohne Enter/Return immer weiter schreiben, Groß- und Kleinschreibung exakt beachten) eintragen und mit [ OK ] bestätigen:

iptables -t nat -D OUTPUT -p udp --dport 53 -j DNAT --to-destination 208.67.222.222:53 || true
iptables -t nat -D OUTPUT -p tcp --dport 53 -j DNAT --to-destination 208.67.222.222:53 || true

"208.67.222.222" (hier also OpenDNS) ist zu ersetzen mit der IP-Adresse des gewünschten (zu verwendenden) DNS-Servers.
Das Phone bei einer Änderung neu starten, um den DNS-Cache zu löschen und die Einstellung zu aktivieren.

Hinweis: Wenn man mit mehreren Profilen arbeitet, dann muss man diese Einstellung in jedem der Pofile vornehmen. - Um dies für ein bestimmtes Profil durchzuführen, muss das Profil aktiviert sein.

Diese Einstellung sorgt dafür, dass immer (bei W-LAN und auch bei Mobilen Daten über 3G/2G) der gewünschte DNS-Server benutzt wird.

Der Ersatz des voreingestellten Google DNS-Servers erfolgt über ein Shell-Script, dass beim Booten ausgeführt wird. Das könnte ich also auch ohne AFWall+ zu benutzen selber in init.d ablegen, wenn ich das richtig verstanden habe, oder?

In diesem Thread wird beschrieben, wie ich den DNS-Server durch Veränderung der /etc/dhcpcd/dhcpcd-hooks/20-dns.conf ebenfalls verändern kann. Ich habe bei mir die Zeile:

new_domain_name_servers="208.67.222.222 208.67.220.220 $new_domain_name_servers"

für die OpenDNS eingefügt und im TE mit

$ getprop grep | dns

überprüft. Nach erneuter Verbindung mit dem WLAN standen beide Server an Pos 1 und 2. Kann ich davon ausgehen, dass das nicht nur für WLAN, sondern auch für mobile Daten gilt?

Auf XDA habe ich hier gelesen, dass es vorkommen kann, dass Einstellungen von iptables in init.d später wieder überschrieben werden können.

Nehmen wir mal an, das würde eben auch das AFWall+ Script betreffen, wäre dann die Änderung der 20-dns.config die bessere Methode oder was denkst Du darüber?

 

[ooo]

[...] Der Ersatz des voreingestellten Google DNS-Servers erfolgt über ein Shell-Script, dass beim Booten ausgeführt wird. Das könnte ich also auch ohne AFWall+ zu benutzen selber in init.d ablegen, wenn ich das richtig verstanden habe, oder? [...]

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.

[...] DNS-Server durch Veränderung der /etc/dhcpcd/dhcpcd-hooks/20-dns.conf ebenfalls verändern [...] Kann ich davon ausgehen, dass das nicht nur für WLAN, sondern auch für mobile Daten gilt? [...]

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.

[...] Auf XDA habe ich hier gelesen, dass es vorkommen kann, dass Einstellungen von iptables in init.d später wieder überschrieben werden können.

Nehmen wir mal an, das würde eben auch das AFWall+ Script betreffen, wäre dann die Änderung der 20-dns.config die bessere Methode oder was denkst Du darüber?

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]

@ooo
Ich benutze ein "Avenir H.264 DVR". Die Hauseigene-App von Avenir für diese DVR funktioniert nicht, weswegen ich auf IP Cam Viewer zugegriffen habe. Diese DVR lässt sich nur mit dem IE Browser erreichen, mit aktiviertem ActiveX... Mozilla, Chrome etc funktionieren nicht.

Von zuhause hab ich vollen zugriff, funktioniert über jeden PC. Und mit der erwähnten App auch.

Muss aber mal versuchen über die OpenDNS-Server mich mit IE zu verbinden, wenn ich zuhause bin. Auf den ArbeitsPC kommt IE nicht drauf ;-)

Die DVR ist ist mit Ports über den Router eingestellt und hat Zugriff drauf (DynDns). Kann mir also nicht so recht vorstellen, dass es tatsächlich der DNS wegen ist, da ich ja so gesehen nicht direkt drauf zugreife, sondern über DynDns.

 

[ooo]

@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:

DVR Viewer / Transmitter Troubleshooting Techniques

1. Ensure that your internal IP address to your DVR has not changed buy going through this section again to a ssign an IP address to your DVR. If your IP address changed, then you need to setup port forwarding rules again based on that new IP address, so go here to setup port forwarding on your router.
2. Make sure that you have the correct IP address for your Internet connection. Ask your ISP for your IP address if using a static IP address. You can also look up the IP address of your internet connection here:
   
   Get My IP Address
3. Make sure that your router does not have any advanced firewall rules in place by consulting the manual.
4. Call your ISP and ask them if your modem has a firewall that you can disable.
5. Call your ISP and make sure that they do not block any incoming ports to your Internet connection.

 

[dmasu]

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

Nein, leider nicht. So ist das mit der brain.apk: Updates zu installieren ist verdammt schwierig ;-)

Zum DHCP-Tweak:
Das Hardcodieren der DNS-Server in der /etc/dhcpcd/dhcpcd-hooks/20-dns.conf wirkt sich nur auf WLAN-Verbindungen aus. Die Überprüfung mit Networklog zeigt, dass bei mobilen Verbindungen die vom Provider gesetzten DNS Server verwendet werden. Ich habe normalerweise mobile Daten gar nicht aktiviert, so habe ich bei der "getprop grep | dns" nur die "[dhcp.wlan0.dns1]" Einträge gesehen. Nach Aktivierung der Daten und Nutzung erhalte ich, wie auch @gene im Tweak war ja auch vom Themenstarter dafür gedacht, in seinem Heimnetz einen eigenen DNS-Server zu verwenden.

Überschreiben von iptables:
Das habe ich wohl auch etwas missverstanden. Tatsächlich gibt es Probleme mit dem Datenleck-Fix, siehe in der Wiki des Entwicklers. Auch in meinem Link zu XDA geht es um das block all/drop all, also den Datenleck Fix. Wenn ich die Kommentare der AFWall+-Entwickler richtig interpretiere, liegt es an mangelnder init.d-Unterstützung der Android-Version. Darum ist es wohl auch unter den "experimentellen Einstellungen". Im obigen Link zum Wiki sind übrigens auch Alternativen zum Datenleck-Fix beschrieben, wenn das eigene Android init.d nicht unterstützt.

Ich habe übrigens bei diesem Test eine App von mir dabei ertappt, unerwünscht Daten beim Booten zu versenden. Ist für gewöhnlich unproblematisch, da ich sonst keine Daten aktiviert habe. In CM11 kann man diese Apps übrigens schon mit Bordmitteln unter Einstellungen - Datenverbrauch ausfindig machen. Dort kann man dann auch für einzelne Apps die Hintergrunddaten deaktivieren. Das Verhalten bei WLAN-Verbindung lässt sich aber nicht beeinflussen und es wird nicht angezeigt, mit wem die App telefoniert. Dafür muss man AFWall+ und Networklog verwenden.

Obwohl ich nur wenige Apps nutze und keine mobilen Daten verwende sehe ich für mich mittlerweile zur Verwendung von AFWall+ und Networklog keine Alternative.

 

[ooo]

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 ...

 

[dmasu]

Bei mir laufen ja sowieso nicht so viele Apps und dennoch habe ich die Einrichtung der Firewall gleich dazu genutzt noch weiter auszumisten. Alles was hier unaufgefordert raustelefonieren will, fliegt raus. Gleichzeitig habe ich auch alle GApps bis auf das Google-Dienste-Framework deaktiviert. Ich bevorzuge sowieso F-Droid, aber für einige Apps aus dem PlayStore habe ich noch keine Alternative und zumindest eines davon greift auf das Framework zurück. Falls ich dann doch noch mal in den PlayStore will, muss ich halt das Notwendige (Google Play Store, Google Play-Dienste und Google Account Manager) wieder aktivieren und das Konto neu anlegen. Damit spare ich mir auch das in die Mode gekommene "disable services" ;-)

Genug des OT. Bei mir bleiben in der Firewall anfragen der App-Gruppe 1000 HWA Einstellungen usw. hängen. Das eine sind A-GPS Anfragen (SUPL) an 173.194.65.192:7276 des GPS, das andere geht auch an Google: 173.194.113.158:443, aber dabei weiß ich nicht von wem, weshalb und wie ich das abstellen kann. Wie gesagt, eigentlich läuft von Google ja nur noch das Dienste-Framework. Was will den aus der Gruppe eine gesicherte Verbindung zu Google? Vielleicht weißt Du ja was, ich bin bisher per Internet-Suche nicht weitergekommen.

Eine schönes Schmankerl für alle Google Tracking Fans findet sich übrigens in diesem Link. Von wegen SUPL-Anfragen sind anonym, da verzichtet man doch gerne auf A-GPS. (Die Jungs haben echt an alles gedacht...)

 

[ooo]

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

@ukanth, I'm tossing around the idea of adding more instrumentation to make it easier to collect data on failures seen in the field. What do you think about adding features that:

Display the output of the most recent failed shell command on the firewall rules (aka: diagnostics) page
Display tethering status as a tristate: isWifiApEnabled()=true, isWifiApEnabled()=false, or "couldn't invoke isWifiApEnabled()"
Display the Android OS version
Add a "send problem report" button (which of course would need to be allowed through the firewall)

Regarding traffic blocking, there are two cases that are causing heartburn for users:

UID 0 (root) needs 53/udp open for DNS on Android 4.3. Should we make this configurable, or just open it up unconditionally? Unfortunately the DNS proxy feature does open up the risk of rogue apps establishing DNS tunnels, if they really want to bypass the firewall rules.

UID 1000 (system) needs 123/udp open for NTP. Phones can use NITZ but wifi-only tablets need NTP. Whitelisting all traffic from UID 1000 could allow malware such as MotoBlur to leak personal information. Would it be worth adding a separate line item for NTP only?

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!

 

[wewede]

Ich muss noch einmal dumm dazwischen fragen, und zwar zum Starter-Thema, Seite 1:
5. Ein Wort zu Google- bzw. Provider-DNS...
Wenn mein Handy über WLAN ins Internet geht, läuft die Anfrage an den Server dann über die im Router eingestellte DNS-Adresse oder über die im Handy vorgegebene Google oder Provider -Adresse?
Danke.

 

[ooo]

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).

 

[wewede]

Danke, das werde ich nachher gleich umsetzten.
Da ich via Handy zu 99,9 % (ausser Urlaub) nur mein eigenes WLAN nutze, kann ich hier ja schon ein bißchen eingreifen.
Jetzt wird es ein bißchen OT (falls sich jemand auskennen sollte):
Kann bzw. soll ich am Telekom-Router die DNS auf die empfohlenen Provider ändern oder handle ich mir da Probleme ein (technische bzw. funktionelle)?

 

[ooo]

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).

 

[dmasu]

IP 173.194.113.158

Den 1000er-User blocke ich immer.

Danke für die Tipps. Den 1000er-User habe ich auch geblockt, aber ich bin natürlich neugierig, wer da sein Schindluder treibt. Ansonsten herrscht bei mir auch absolute Funkstille, wenn ich mich mit dem Internet verbinde.

Als Alternative für A-GPS mit SUPL Anfragen an Google-Server kann ich übrigens nur wärmsten das get-gps-lto- Script aus dem Wiki empfehlen. Nach anfänglichen Zweifeln, ob die LTO-Datei wirklich genutzt wird, bin ich nach ein paar Tests mittlerweile überzeugt. Allerdings lädt man natürlich die LTO Datei auch bei jemandem herunter und der Service von gllto.gpals.com scheint von Amazon betrieben zu werden. Dennoch denke ich, dass bei einem Dateidownload dann doch weniger persönliche Daten übertragen werden.

 

[mratix]

Wie kann man in der AFWall ein Profil ins andere kopieren?
z.B. Profil 2 zum Standard.

 

[ooo]

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.

 

[mratix]

@ooo Danke für die Antwort.

Irgendwie sehe ich in /data/data/... das Standard-Profil nicht.
Die anderen sind vorhanden und auch der Inhalt entspricht den Settings in AFWall.

Hab ich was übersehen?

 

[ooo]

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

 

[ooo]

[...] Merkt die AFWall+ sich das nicht, daß die eingeschaltet sein soll, muß ich das nach jedem Reboot neu setzen? [...]

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
  

  etc/hosts

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

  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:

  ...
  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:

#!/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]

Moin,

erstmal auch von mir ein Danke für das tolle Tutorial. Ich habe alle Schritte befolgt und es klappt soweit alles ganz gut. Allerdings funktioniert mein mobiles Internet nicht mehr wirklich. Ich habe zwar Empfang und die gewünschten Apps in AFWall+ aktiviert, aber mir wird ständig die Meldung gemacht, dass kein Server gefunden werde.

Mit W-Lan ist es kein Problem, aber sobald ich auf mobilen Datenverkehr umstelle funktioniert nichts mehr. Wie gesagt, der Haken in AFWall+ ist z.B. für Firefox an Position 3 gesetzt - die Firewall kann es also eigentlich nicht sein.

Hat da jemand eine Idee?
Danke

 

[ooo]

@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.