1. Horch was kommt von innen raus?
Im letzten Beitrag der Artikelserie »Your phone – Your data« haben wir aufgezeigt, wie ungewollte Datenverbindungen mit der AFWall+ verhindert werden können. Damit sind wir nun in der Lage eigenverantwortlich zu entscheiden, welche Apps und Systemkomponenten Zugriff auf das Internet erhalten und welche nicht. Zudem können versierte Anwender durch die Verwendung von Custom-Scripts in der AFWall+ feingranular auf den Netzwerkverkehr des Android-Geräts Einfluss nehmen.
Im vorliegenden Beitrag möchten wir euch ein Tool vorstellen, mit dem ihr euch ein Bild von der »Kommunikationsfreudigkeit« eures Systems bzw. Apps machen könnt. Bei der ein oder anderen App werdet ihr bei der Prüfung mit Network Log bzgl. ihrer Kommunikationsfreudigkeit bestimmt einen »Aha-Effekt« erleben. Gerade als kritische Anwender, welche die »Datenherrschaft« über ihr Smartphone erlangen und behalten wollen ist es essenziell wichtig, bei Bedarf überprüfen zu können, wann und wohin eure installierten Apps Verbindungen aufbauen.
Network Log greift zur Protokollierung bzw. für seine Logging-Routine auf Funktionen der bereits vorgestellten iptables Firewall zurück. Wie ihr im vorherigen Artikel lesen konntet, greift auch die AFWall+ auf die Funktionalitäten des mächtigen Paketfilters »iptables«, der bei vielen Linux-Distributionen zum Einsatz kommt, zurück.
- Your phone Your data – Android ohne Google Teil1
- Grundstein legen – Android ohne Google Teil2
- CyanogenMod – Android ohne Google?! Teil3
- F-Droid und AFWall+ – Android ohne Google?! Teil4
- Network Log – Android ohne Google?! Teil5
- XPrivacy – Android ohne Google?! Teil6
- Datenschutzfreundliche Apps und Dienste – Android ohne Google?! Teil7
Update
März 2016: Die Artikelserie wurde das letzte Mal im März 2016 aktualisiert. Sie lässt sich inklusive Android 6.x (Marshmallow) einwandfrei umsetzen.2. Unsere täglichen »App-Datenschleudern«
Auch wenn wir mit der AFWall+ relativ einfach entscheiden können, ob eine App Netzwerkzugriff bekommt oder nicht, kann es oftmals sehr interessant sein zu erfahren, zu welchen Services bzw. Anbietern die jeweilige App Verbindungen aufbaut.
Wie schon im vorherigen Teil beschrieben müssen wir uns nämlich immer darüber bewusst sein, dass wir mit jeder Verbindung zu einem anderen Server, unweigerlich (personenbezogene) Daten von uns preisgeben. So übermittelt unser Smartphone in jedem Fall immer die IP-Adresse an die entsprechenden Server bzw. Provider. Was die App für weitere unserer personenbezogenen Informationen an den Anbieter übermittelt und zu welchen Zwecken diese Informationen von den Anbietern verwendet werden, lässt sich oftmals aber leider nur mutmaßen.
Prominente »App-Datenschleudern« bzw. Beispiele sind hier kurz aufgelistet:
- Selbstbedienungsladen Smartphone (heise)
- Neue Android-App will mithören (heise)
- Smartphone-App Path lädt heimlich Adressbuch hoch (PCWelt)
- Smartphone-User klagen über Adressbuch-Greifer (Spiegel Online)
- Wie Facebook private Telefonbücher abgreift (Spiegel Online)
Der »Ausverkauf« unserer persönlichen Daten hat längst begonnen. Die verlinkten Beispiele stellen lediglich die Spitze des Eisbergs dar und eine Besserung ist in naher Zukunft nicht in Sicht. Rücksichtslose wirtschaftliche und staatliche Interessen stehen im krassen Widerspruch zur informationellen Selbstbestimmung eines jeden Einzelnen. Aus Einfachheit und Bequemlichkeit hat sich ein Großteil der Bevölkerung bereits der »Diktatur« der Hersteller ergeben. Ohnmächtig und berauscht von den Möglichkeiten moderner Smartphones nimmt der Otto-Normal-Verbraucher die Sammlung und Verknüpfung privater Daten hin, obwohl jegliche Transparenz, was damit eigentlich passiert, vollkommen auf der Strecke bleibt. Diese Entwicklung lässt sich übrigens nicht ausschließlich im Smartphone-Bereich beobachten, sondern erstreckt sich mittlerweile auf große Teile unseres Lebens.
3. Network Log
Die Funktion dieser wertvollen App lässt sich relativ einfach zusammenfassen: Detaillierte Auflistung und Darstellung über alle ein- und ausgehenden App-Verbindungen, inklusive statistischer Auswertungsmöglichkeiten und Filterfunktionen. Vereinfacht ausgedrückt könnt ihr mit Network Log feststellen, zu welchen Zielen bzw. Anbietern im Internet eine App Verbindungen aufbaut. Hierdurch ist es euch insbesondere möglich, »schwarze Schafe« bei euren installierten Apps zu entlarven und den Netzwerkverkehr detailliert zu beobachten und ggf. zu reglementieren.
Update
28.11:2017: Network Log wird nicht mehr in F-Droid angeboten. Ihr könnt auf die Alternative PCAPdroid zurückgreifen, die ganz ähnlich funktioniert.Es sei an dieser Stelle angemerkt, dass wir in diesem Beitrag aufgrund der Komplexität dieser App, nicht alle Funktionen von Network Log erläutern werden. Vielmehr werden wir uns auf die Darstellung der Kernfunktionalitäten dieser App beschränken: Eine Darstellung von Kommunikationsbeziehungen, die von eurem System oder den installierten Apps nach »draußen« initiiert werden.
Hinweis
Eine Protokollierung der Verbindungen durch Network Log ist nur bei einem gerooteten Android Gerät möglich. Wie ihr euer Gerät rooten könnt, haben wir in bereits in Teil 2 der Artikelserie beschrieben.3.1 Erste Schritte und Bedeutung der Ausgabe
Habt ihr Network Log aus dem F-Droid bezogen und installiert, geht es auch gleich los. Unmittelbar nach dem Start von Network Log seht ihr eine Auflistung eurer installierten Apps und Systemservices, sortiert in alphabetischer Reihenfolge.
Bevor ihr jedoch mit dem Logging und der Auswertung der Logs beginnt und hierbei von Informationen »erschlagen« werdet, empfiehlt es sich zunächst eine spezielle Einstellung vorzunehmen. Hierzu klickt ihr auf die drei »Drei Punkte in der rechten unteren Ecke –> Einstellungen –> Allgemeine Optionen« . In diesen Optionen solltet ihr bei »Protokollieren hinter Firewall« ein Häkchen setzen. Diese Einstellung hat zum Effekt, dass nur noch die entsprechenden Apps protokolliert werden, denen ihr den Zugriff in der AFWall+ erlaubt habt. Somit werden die schon in der AFWall+ blockierten Verbindungen nicht mehr von Network Log erfasst. Vielmehr lassen sich diese geblockten Verbindungen im Protokoll der AFWall+ nachvollziehen. Ihr könnt euch daher durch die »Protokolliere hinter Firewall«- Funktion auf das Wesentliche fokussieren und die gestatteten Kommunikationsverbindungen genau unter die Lupe nehmen.
Aus Neugierde oder einfach mal um zu sehen, wie »kommunikationsfreudig« euer Android Gerät ist, könnt ihr die Option »Protokollieren hinter Firewall« auch deaktiviert lassen. Ihr werdet hierbei schnell feststellen, dass selbst ein Gerät mit CyanogenMod, das mittels Freecyngn von proprietären Google Apps sowie Bibliotheken befreit wurde, trotz alledem fleißig Verbindungen mit der »Außenwelt« aufnehmen will.
3.2 Start der Protokollierung
Um die Protokollierung zu starten, reicht ein kurzer Klick auf den Button »Logging Aus«. Mit diesem Klick wird Network Log automatisch in den Protokoll-Modus versetzt. Ihr werdet unmittelbar nach dem Aktivieren der Protokollierungsfunktion (je nach Einstellungen in der AFWall+) einen Eindruck davon bekommen, wie kommunikationsfreudig euer Android-Gerät tatsächlich ist. Network Log erfasst im Rahmen der Kommunikation einer App, die nachfolgend (am Beispiel von Firefox) beschriebenen Informationen.
Die von Network Log ausgegebenen Protokollierungsinformationen geben uns insbesondere Auskunft darüber:
- Wohin, also zu welcher IP-Adresse bzw. Gegenstelle eine Verbindung initiiert wird. Diese Meldung ist eine der wohl interessantesten Informationen, die wir später nochmal aufgreifen.
- Welcher Port bzw. Remote-Service zur Kommunikation benutzt wurde. Im vorliegenden Beispiel sehen wir die Bezeichnung HTTP, der analog für den Port 80 steht. Diese Namensauflösung lässt sich unter den Optionen deaktivieren.
- Welches Protokoll (hier TCP) bei der Verbindung verwendet wurde.
- Über welches Netzwerkinterface die Verbindung aufgebaut wurde. Android verfügt über mehrere logische Netzwerk Interfaces. Dazu zählen beispielsweise wlan* (WLAN-Interface), rmnet* (3G / mobile Daten) und tun* (VPN). Aus der Darstellung könnt ihr entnehmen, dass die Pakete über das WLAN-Interface »wlan0« übertragen wurden.
- Wie viele Netzwerkpakete gesendet wurden. Network Log erfasst die Anzahl der übertragenen Pakete und summiert die Paketgröße zu einer Gesamtanzahl.
- Wie viele Netzwerkpakete empfangen wurden. Analog zu den gesendeten werden ebenfalls die empfangenen Pakete von Network Log protokolliert.
Falls ihr euch dafür interessiert, wer bzw. welcher Anbieter sich hinter der in Punkt 1 beschriebenen IP-Adresse verbirgt, könnt ihr dieses mittels einer »whois – Abfrage« über das Terminal oder über den Webdienst who.is bewerkstelligen.
Hinweis: Alternativ könnt ihr auch die in Network Log eingebaute »Whois Suche« nutzen. Durch ein längeres Drücken auf die IP (Punkt 1) erscheint ein Optionsmenü, bei dem ihr »WHOIS IP Adress« selektieren könnt. Bei dieser Funktion von Network Log wird mittels des von euch ausgewählten Browsers, ein Webseitenaufruf zu »http://www.whois.com« durchgeführt und hierbei Informationen der entsprechenden IP-Adresse abgerufen.
Bezogen auf unser vorstehendes Beispiel gehört die IP-Adresse »62.138.116.11« demnach zum Netzbereich 62.138.0.0 – 62.138.255.255, der dem Unternehmen »Host Europe GmbH« mit Sitz in Deutschland zugeordnet werden kann. Weiterhin können wir die IP-Adresse eventuell in einen DNS-Namen auflösen. Dafür eignet sich nslookup oder das Heise Netzwerk Tool DNS-Abfrage. In diesem Fall haben wir allerdings kein Glück:
Diese Information deutet darauf hin, dass für die IP-Adresse 62.138.116.11 kein Reverse DNS Eintrag vorhanden ist. Da es sich bei der vorliegenden IP-Adresse um eine Gegenstelle handelt, die auf Port 80 einen Webserver-Dienst anbietet, können wir unser Glück auch über den Browser versuchen:
Aufgrund unserer Nachforschungen haben wir deshalb relativ einfach herausfinden können, dass es sich hier um eine Adresse handelt, die nicht direkt erreichbar sein soll. Möglicherweise werden von diesem Server Inhalte (Bilder, Videos) für die Domain »www.spiegel.de« nachgeladen. Durch die Informationen, die uns Network Log zur Verfügung stellt, wissen wir aber nun genau bzw. können genau nachvollziehen, dass wir am 12.08.2014 um 15:20 Uhr mit der Firefox App Uhr die Spiegel-Webseite geöffnet haben. Diese Informationen können je nach »Einsatzszenario« unter Umständen sehr nützlich für uns werden.
Am nachfolgenden Beispiel könnt ihr erkennen, welche Informationen uns ein »nslookup« bei Adressen ausgibt, die »Reverse-DNS« unterstützen. Das nachfolgende Beispiel zeigt ein nslookup der heise.de IP-Adresse:
Mithin lässt sich deshalb festhalten, dass wir mit ein paar »simplen« Tools wie whois oder nslookup einiges über die Gegenstelle in Erfahrung bringen können. Wir erfahren hierdurch nämlich in den meisten Fällen:
- Wer ist Verantwortlich für das Hosting?
- In welchem Land wird der Dienst bereitgestellt?
- Welches Unternehmen steckt hinter der IP-Adresse?
- Und noch vieles mehr…
All diese Informationen lassen sich wie ein Puzzle zusammensetzen und ergeben anschließend ein nahezu vollständiges Gesamtbild von der Gegenstelle.
3.3 Verbindungsnotifications
Wollt ihr in Echtzeit darüber informiert werden, wohin eine App gerade »telefoniert«, lässt sich dieses mit kleinen Popups von Network Log bewerkstelligen. Diese erscheinen immer dann, wenn eine App eine neue Verbindung zu einer Gegenstelle initiiert.
Diese sinnvolle aber schnell auch störende Funktion könnt ihr durch das Tippen auf den Button: »Drei Punkte –> Einstellungen –> Verbindungsnotifications« aktivieren. Die Aktivierung dieses Menüpunktes hat zum Effekt, dass ihr nach der Aktivierung ein visuelles Feedback in Form von kleinen Popups am unteren Bildschirmrand erhaltet. Dieses sieht dann etwa so aus:
3.4 Grafische Darstellung der Netzwerkverbindungen
Unter dem Menüpunkt »Graph« verbirgt sich eine grafische Darstellung aller App-Verbindungen. Auf der Y-Achse werden die jeweils übertragenen Datenmengen erfasst. Die X-Achse lässt sich über die zwei Zeitvariablen am oberen Bildschirmrand beeinflussen. Mittels der Häkchen könnt ihr zudem festlegen, welche Apps in diesem Diagramm grafisch dargestellt werden sollen.
Der Kuketz-Blog ist spendenfinanziert!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
3.5 Verdächtige Verbindungen!?
Wir müssen attestieren, dass die Beurteilung und Bewertung, ob ausgehende App-Verbindungen »verdächtig« sind oder nicht, kein leichtes Unterfangen ist. Die Beurteilung fällt uns immer bei den Apps leicht, denen wir mittels AFWall+ die Kommunikation verboten haben. Wenn ihr die Funktion »Hinter Firewall protokollieren« in Network Log nicht aktiviert habt, lässt sich deshalb sehr schnell feststellen, was die in der AFWall+ verbotenen Apps, alles für Verbindungen aufmachen wollen. Das kann euch in eurer Entscheidung, die entsprechende App zu blocken, entsprechend bestärken.
Die Beurteilung, ob sich eine App »verdächtig« verhält, ist jedoch bei den Apps problematisch, denen wir den Zugriff auf die entsprechenden Netzwerkverbindungen mittels AFWall+ gestattet haben. Wir sollten uns nämlich immer vor Augen führen, dass eine App meist eine oder mehrere Gegenstellen benötigt, um Informationen oder Daten auszutauschen.
Bei der Überprüfung bzw. der Bewertung, ob sich eine App »verdächtig« verhält, empfiehlt es sich , wie folgt vorzugehen:
- Zunächst müssen wir für uns selber entscheiden, ob die entsprechende App Zugang zum Internet erhalten soll. Das können wir noch relativ einfach mittels AFWall+ bewerkstelligen.
- Wollen wir einer App den Internetzugriff gestatten, sollten wir uns unbedingt in einem weiteren Schritt fragen, zu welchen »Anbietern« bzw. IP’s die App Verbindungen grundsätzlich aufbauen darf. So bezieht bspw. der Werbleblocker AdAway seine Aktualisierungen von zwei unterschiedlichen IP-Adressen, während das Web-Analyse Tool Matomo meist von einer Quelle seine Daten abfragt. Ähnliches gilt für den Mail-Client K9-Mail. Dieser sollte lediglich Verbindungen zum konfigurierten Mail-Server aufbauen und nicht noch weitere IP-Adressen »kontaktieren«. Eine Kalender-App, die ihr beispielsweise über eine CalDAV-Schnittstelle mit einen Server synchronisiert, sollte nicht noch andere IP-Adressen bzw. Gegenstellen kontaktieren.
Stellt ihr mittels der Auswertung in Network Log fest, dass eine App Verbindungen zu mehr IP-Adressen aufbaut, als ihr für notwendig erachtet, solltet ihr dieser App mit Skepsis begegnen und weitere Nachforschungen anstellen.
Diese Vorgehensweise empfiehlt sich jedoch nicht für alle Apps. Gerade bei Browsern ist diese Vorgehensweise eher »kontraproduktiv«. Denn gerade bei Browsern ist es ja grundsätzlich gewollt, dass sie Verbindungen mit den unterschiedlichsten IP-Adressen (Webservern) aufbauen, um die aufgerufenen Webseiten letztlich auf dem dem Screen des Smartphones darzustellen. Der Datensammelwut einiger Webseitenanbieter bzw. der Intransparenz der Datenverarbeitung auf einigen Webseiten könnt ihr durch den Einsatz der im vorigen Artikel beschriebenen Custom-Scripts der AFWall+ zuvorkommen. Hierzu müsste ihr die entsprechenden IP’s bzw. Netzwerkbereiche direkt in die Sperrliste eurer Custom-Scripts aufnehmen.
Als abschließende Empfehlung möchten wir euch noch folgende Ratschläge mit auf dem Weg geben:
- Protokolliert den Datenverkehr eures Smartphones über einen längeren Zeitraum
- Verwendet zur Analyse der Verbindungen Tools wie whois und nslookup
- Besonders bei Anwendungen, die sensible Daten (Kontaktdaten, E-Mails, Termine usw.) verarbeiten, solltet ihr immer genau hinschauen, zu wem diese Apps „telefonieren“ wollen
- Um der Informationsflut in Network Log Herr zu werden, empfiehlt sich oftmals der Einsatz der eingebauten Filterfunktion. Mit dieser könnt ihr gezielt den Netzwerkverkehr einzelner Apps analysieren. Ihr erreicht die entsprechenden Einstellungsmöglichkeiten durch das Klicken auf »Drei Punkte –> Filter«
- Eine Liste der standardisierten Ports kann euch dabei helfen einen Dienst genauer zu identifizieren und in Verbindung mit der Auswertung von IP-Adressen, entsprechende Rückschlüsse auf das Kommunikationsverhalten von Apps zu ziehen.
4. Fazit
Smartphones beinhalten heute oftmals mehr und sensiblere Informationen als jedes private Tagebuch. Und doch machen sich nur die wenigsten Menschen Gedanken über den darauf abgelegten Daten und Informationen. Mit Network Log können wir uns nun ein Bild davon machen, zu welchen Anbietern bzw. Gegenstellen Apps Verbindungen initiieren, um »möglicherweise« heimlich Daten von uns zu sammeln.
Im kommenden Beitrag widmen wir uns der Kontrolle über unsere sensiblen Daten. Denn obwohl uns AFWall+ vor ungewollten Datenverbindungen schützen kann, so wissen wir nicht mit absoluter Sicherheit, welche Informationen Apps übertragen, denen der Zugriff auf das Internet prinzipiell erlaubt ist. Das »kaputte« Android-Berechtigungssystem können wir mit XPrivacy unter Kontrolle bekommen und feingranular entscheiden, auf welche Informationen eine App tatsächlich Zugriff erhält.
Autoren:
Bildquellen:
Network Log: „Logo“, https://code.google.com/p/iptableslog/
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
F-Droid und AFWall+ – Android ohne Google?! Teil4
AFWall+: Digitaler Türvorsteher – Take back control! Teil4
AFWall+: Wie ich persönlich die Android-Firewall nutze
Klimaschutz mit Datenschutz? Der große Elektroauto-Ladeapp-Test
Datenschutzfreundliche Apps und Dienste – Android ohne Google?! Teil7
15 Ergänzungen zu “Network Log – Android ohne Google?! Teil5”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit.
Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Hallo,
ich teste Network Log nun seit einer Woche. Sehr feines Programm! Konnte schon diverse IPs durch Custom Script in AFWall+ blocken.
Allerdings funktioniert die App immer nur ca. 10min. In dieser Zeit loggt sie sehr schön den Traffic hinter der Firewall und liefert die jeweiligen IP Adressen. Dann jedoch kommen plötzlich keine Meldungen mehr auch wenn ich dieselben Apps nutze, die vorher korrekt geloggt wurden. Nach Neustart des Telefons geht wieder alles für einige Zeit.
Hat das schon mal jemand beobachtet?
Gruß
Gert
Kann es sein, dass du der App nur für zehn Minuten root-Rechte gewährst?
Dafür vielleicht mal „Superuser-Zugriff dauerhaft merken“ einschalten.
Großes Lob & dicken Dank für den Fünfteiler „Android ohne Google“ – dieser Leitfaden ist eine unschätzbare Hilfe für alle, die ihr Smartphone (soweit wie möglich) befreien wollen.
Mittels AFWall+ habe ich probehalber die folgenden Dienste/Apps geblockt:
– 0: (Root) – Apps die Root-Rechte benötigen
– 10013: Google Backup Transport, Google-Dienste-Framework, Google-Kontakte synchronisieren, Google Account Manager, Google Play-Dienste
Wenn ich nun über Network Log den Netzwerkverkehr beobachte, fällt mir auf, dass dort die folgenden Dienste/Apps nach wie vor Datenverkehr erzeugen:
– (0) root
– (10013) Google Account Manager
– (10013) Google Backup Transport
– (10013) Google Play-Dienste
– (10013) Google-Dienste-Framework
– (10013) Google-Kontakte synchronisieren
Weiß jemand, wieso das so ist?
Hast du die Funktion »Protokollieren hinter Firewall« aktiviert?
Ja, so wie oben im Artikel empfohlen, habe ich diese Option in den Einstellungen aktiviert. Deshalb wundere ich mich auch, wieso Network Log nach wie vor Datenverkehr von diesen Diensten protokolliert.
Die Antwort auf meine obige Frage habe ich inzwischen selbst gefunden, u. zw. genau hier im Blog (wo sonst :))
Im 4. Teil der gegenständlichen Artikelserie (https://www.kuketz-blog.de/f-droid-und-afwall-android-ohne-google-teil4/ ) wird im Abschnitt 4.6 „Besonderheiten ab Android 4.3+“ genauer darauf eingegangen. Dort wird auch kurz erläutert, was man ggf. machen kann, um den Datenverkehr (in erster Linie DNS-Anfragen) durch AFWall+ erfassen bzw. filtern zu lassen.
Hallo,
interessante Reihe und ich habe mich auch sofort an die Umsetzung begeben…allerdings erzeugt Network-Log bei mir öfters einen Neustart des Telefons. Ich benutze aktuell CM11-Snapshot-20141008
Gruß
Michael
Hallo Mike,
mit großem Interesse habe ich Deinen Blog verfolgt.
Am Handset (Android 4.4.2, Root, Standardfirmware) als Info/Kontroll APPS AFWall+, NetworkLog, XPrivacy, Link2SD.
Nun stelle ich immer wieder Verbindungen vom „Google Backup Transport“ zu unterschiedlichen IP Adressen (verschiedene im Bereich von 173.194.112.1-173.194.112.254) fest.
In den Einstellungen (des Handsets) „Sichern und zurücksetzen“ gibt es KEIN Sicherungskonto, KEINE automatische Wiederherstellung und KEINEN Hacken bei „Meine Daten sichern“.
Die Verbindungen erfolgen dennoch.
Habe Google Backup Service mit Link2SD (alternativ Chef’s App Freezer) eingefroren, Telefon neu gebootet, SELBES Resultat.
Hast Du dazu eine Idee?
Wie bekomme ich das Senden an diesen Google Backup Transport „Service“ weg?
Kann ich die IP-TRange im AFWall+ Skript blocken? Wenn ja, wäre das dann so
$IPTABLES -A „afwall“ -d 173.194.112.0/24 -j REJECT
korrekt?
(Werden einzelne Adressen aus dem Bereich, den Network Log aufzeichnet, mittels AFWall+ gesperrt [und dann neugestartet, zur Sicherheit], verwendet Google Backup Transport eine andere IP Adresse…)
Herzliche Grüße,
Markus
Hast du die Funktion »Protokollieren hinter Firewall« aktiviert?
Weil erst diese Informationen sind wirklich relevant. Alles andere sind lediglich »Versuche«, eine Verbindung nach außen aufzubauen.
Servus,
ja, „Protokollieren hinter Firewall ist aktiv.“ -> Deine Aussage beruhigt.
Was mich allerdings dennoch wundert, ist, warum Google Backup Transport trotz des „Einfrierens“ zu senden versucht; und das auch auf einer ganzen IP-Range…
Besten Dank vorab,
Markus
Wenn das Häkchen bei »Protokollieren hinter Firewall« gesetzt ist, sollte dich das eher beunruhigen. Denn das bedeutet, dass die Pakete tatsächlich auch versendet werden. Ich würde an deiner Stelle nochmal alle Häkchen überprüfen und in jedem Fall mit dem White-List Modus der AFWall+ arbeiten. Denn dann dürfen nur jene Apps raus, denen du dies per Häkchen erlaubt hast.
Lies dir Teil 4 und Teil 5 nochmal in Ruhe durch – im Prinzip steht dort alles drin.
Warum das Google Backup immer noch raus möchte bzw. kann, das kann ich dir leider auch nicht beantworten.
Hallo Mike. Ist das korrekt das beim Log von Firefox nur die Verbindung zum Provider gelogt wird? Wenn nein, was kann man tun um auch die anderen Verbindungen zu protokoliieren?
Danke+Gruß Tecc
Die App ,,AdAway“ hat auch eine Log-Funktion integriert. Diese zeigt die Quelle des Anbieters direkt an, ohne die IP-Adresse analysieren zu müssen. Zudem kann man einzelne Verbindungen separat durch eine erstellte ,,Blacklist“ blockieren. Die Sache hat allerdings einen Haken: Die Verbindungen können nicht eindeutig den betreffenden Apps zugeordnet werden. Es werden also alle Verbindungen zusammengefasst.
Hallo Mike,
Vielen Dank für die informative Artikelserie.
Leider konnte ich Network Log auf Cyanogenmod 13 nicht zum laufen bekommen, d.h. der Netzwerkverkehr wird bis auf wenige Ausnahmen nicht aufgezeichnet. Das liegt evtl. nach Angaben auf derPlaystore-Seite der App an „restrictive SELinux policy“; was das allerdings sein soll übersteigt mein Anfängerwissen bei weitem.
Meine Frage: gibt es brauchbare Alternativen? Bis jetzt habe ich selber keine finden können…
Danke und Grüsse!