CM13/14.1: Linux Kernel will im Sekundentakt auf Internet zugreifen ...

[Heizoelkocher]

Moin Zusammen!

... und afwall zeigt es nur falsch an

An diesem Punkt bin ich mittlerweile auch.
Laut Screenshots in Post 11 zeigt AFWall folgendes an:

• In den Meldungen der blockierten Zugriffe steht "Linux-Kernel (-11)" // -11 ist die App-ID
• Im Protokoll (Hauptansicht) steht dagegen "Linux Kernel (0)"
  
• Im Protokoll (Alte Ansicht) steht wiederrum "Apps mit Root-Rechten (0)"

Also hat der Linux-Kernel laut AFWall in den Zugriffsmeldungen die ID -11 und im Protokoll neuer Art die ID 0.
Im Protokoll in der alten Ansicht ist dagegen die ID 0 den Apps mit Root-Rechten zugeordnet - da ist etwas faul :-(

Nun gut, um hier Klarheit zu erlangen, müsste man einfach mal eine endere FW installieren. Das ist aber nicht so einfach: die No-Root-FWs protokollieren den Kernel nicht mit (kein Eintrag für den Kernel), und die einzige Root-FW ist die Droid-Wall. Leider ist die neueste Version von 2011.

Ich hab sie testweise installiert und dem Kernel (sowie einigen anderen Anwendungen) den Netzzugang gesperrt.
Nach Starten der gesperrten Anwendungen geben die auch brav Fehlermeldungen raus ("... kein Internet ..."), aber das Protokoll bleibt leer :-( und damit gibt's leider keine Kontrollmöglichkeit für die Kernel-Zugriffe.
Scheinbar gibt's mit ner 2011-er Version unter A7.1 kein Protokoll oder die alte Droidwall ist diesbezüglich fehlerhaft.

Einen andere Alternative für AFWall+, die auch den Kernel protokolliert, habe ich leider nicht gefunden.

Das Paket Capture sehe ich mir mal an ...

 

[milli4503]

Statt mit AFWall+ zu kontrollieren, mache es mal auf der Shell mit " tcpdump". In eine Datei ( pcap ) schreiben lassen u. mit PCAP READER anschauen.

Voraussetzung: root, busybox, app pcapreader, app terminal emulator.

z.B. tcpdump -i wlan -w kontroll.pcap

Nur mal so eine Idee.

Gruss..

 

[Cynob]

Das Packet Capture Tool ist genau das selbe - da ist tcpdump unter der Haube

 

[Heizoelkocher]

Das Packet Capture Tool ist genau das selbe . . .

Tut aber net
Es protokolliert leider nur Zugriffe von Anwenderapps inklusive der Play-Dienste (übrigens ein guter Tip - wirklich klasse das Teil!).
Das Protokoll zeigte aber leider keinen einzigen Zugriff von Root-Apps (App-ID 0) oder Linux-Kernel (App-ID -11).

Die alte Droidwall hat übrigens doch ein Protokoll hin gekriegt (nachdem das Tablet über Nacht lag und heute morgen genutzt wurde: 341 Zugriffe vom Kernel. Die Ziele sind aber andere als auf dem LG G3.

Hab' mal den Author der AFWall+ angeschrieben. Villeicht melder er sich ja und kann etwas beitragen ...

 

[Cynob]

guck mal da hat sich der Entwickler von AF schon darüber ausgelassen:
Android kernel traffic · ukanth/afwall Wiki · GitHub

 

[Heizoelkocher]

Ahh - guter Hinweis!
Wenn ich das richtig verstehe, ist es wohl bestätigt. Die Kernel von MIUI und CM senden Informationen "nach Hause" .

 

[vetzki]

wo liest du das?

 

[Cynob]

Das interessante ist der Absatz:

Remember: Some Messenger, services and apps need root (0) enabled in AFWall+. The question is why? - Answer: E.g. Threema use GCM (Google Cloud Messaging) or ( if no Google Play Services is installed as alternative polling), which working both via external services like Google Play Services (or there own implemented polling) so if root is blocked this means GCM/polling can connect via netd (you'll see a red icon in Threema). WhatsApp fix such behavior with external ports and services (so in this case root 0 isn't necessary) - and this is the reasons why root 0 (Android OS/Play Services) sometimes shows huge traffic, in fact it does not generate any traffic itself, it's called by external apps like Threema.

 

[Sunny]

@Cynob
Also konkret bzw kurz und knapp in einem Satz für Otto normal Verbraucher verständlich auf Deutsch [emoji3]?

 

[Heizoelkocher]

@vetzki

Ich lese das hier heraus:

There is absolute no malware/trojan/spyware/bloatware/whatever within UID 1000/0, please stop mention this or open bug reports with such questions. Android does not 'spy' in any way on you or your private data. Aftermarket firmware like CyanogenMod/MUI only have an opt-in/opt-out to send statistics to improve the product (but no personally information are been collected if it's enabled)! . . . .

 

[Cynob]

Das ist ein Fallback vom System. Der Kernel kann von Google Play Services z.B. angestubbst werden das zu tun - was wiederum irgend ne Software auf dem System sein kann. ( Also ist der Kernel selbst nicht dafür zuständig)
Was für Programme sind denn auf den betroffenen Geräten installiert?
[doublepost=1482070403,1482070258][/doublepost]@Heizoelkocher da steht CyanogenMod/MUI only have an opt-in/opt-out was soviel bedeutet wie: Du wirst gefragt ob du Statistiken hochladen möchtest - da geht nix "hintenrum".

 

[Heizoelkocher]

... was wiederum irgend ne Software auf dem System sein kann. ( Also ist der Kernel selbst nicht dafür zuständig) ...

Ja, das erklärt vieles.

Was für Programme sind denn auf den betroffenen Geräten installiert?

Nun, eines ist Google-frei, das andere nicht. An sonsten: Adaway, Blitzer Plus, Busybox, Business-Calendar, Open Camera, CalDAV-Sync, Snap Camera, DS Note, Firefox, Foldersync, Maps, OpenTasks, Nova Launcher, MusicFolderPlayer, Osmand, Quickalarm, Threema, Whatsapp, Track-ID, Wetter-App, Windguru11, Windyty, Total Commander mit WEBDAV, Keepass, AFWall+ und Torque.

. . . Du wirst gefragt ob du Statistiken hochladen möchtest - da geht nix "hintenrum".

Hoppla - da muss ich ja direkt mal gucken, was ich da eingestellt habe :blushing:

 

[Cynob]

wenn ich mir das so anschaue:
Threema nimmt unsern AF Entwickler ja schon als Beispiel..... Windguru11 (wenn es das ist was der Name vermuten lässt) könnte seine Wetterdaten von Windfinder.com holen....

 

[vetzki]

Wenn das neueste Android 7.1 bzw. 14.1 die im Artikel beschriebene Schwachstelle haben sollte, wäre es (von außen) angreifbar.

Warum aber der Linux-Kernal aber im Sekundetakt auf's Netz zugreifen will, lese ich da nicht heraus. Dann müsste im neuesten CM14.1 ja schon ein Botnet-Client eingebaut sein . . .

Zugriffsziele sind laut Protokoll:
224.0.0.22:0
79.199.204.51:5006 // Telekom
172.16.72.1:60657 // mein Router, der Port ist aber völlig unbekannt
172.16.72.1:58135 // mein Router, der Port ist aber völlig unbekannt
5.148.175.198:5222 // Nine Internet Solutions AG ?????
172.217.22.14:80 // irgend etwas in Californien ????
172.217.22.4:443
158.85.58.109:443 // District Of Columbia, Washington
194.25.134.51:993 // vermutlich Telekom

...

Deine geposteten ip adressen sehen eigentlich recht "normal" aus

79.199.204.51:5006 // Telekom
172.16.72.1:60657 // mein Router, der Port ist aber völlig unbekannt
172.16.72.1:58135 // mein Router, der Port ist aber völlig unbekannt
5.148.175.198:5222 // Nine Internet Solutions AG ????? --> Threma
172.217.22.14:80 // irgend etwas in Californien ???? --> google
172.217.22.4:443 --> google
158.85.58.109:443 // District Of Columbia, Washington -> Scheint whatsapp zu sein
194.25.134.51:993 // Telekom

 

[Heizoelkocher]

Ja ja, und auf beiden Geräten sind die Statistiken eingeschaltet

Da haben wir es mal wieder selber verbockt
[doublepost=1482071752,1482071611][/doublepost]Also Entwarnung - alles im grünen Bereich.
Die Statistiken lasse ich dann drin. Wer so eine tolle Leistung bietet (CM13/14 für alte Geräte), soll auch Statistiken von mir bekommen.

Aber dennoch interessant, darüber zu sprechen bzw. darüber zu schreiben. Vielleicht stolpert ja noch mal jemand darüber und wird hier fündig.

Herzlichen Dank an aller Beteiligten!

Schöne Grüße,
Uwe

 

[Sunny]

Ja, war eine tolle Diskussion [emoji4]
Wieder viel gelernt heute

 

[rudolf]

@Cynob
Also konkret bzw kurz und knapp in einem Satz für Otto normal Verbraucher verständlich auf Deutsch [emoji3]?

Es gibt Netzwerkdienste wie auch der netd(network deamon) welche den Apps bestimmte dienste bereitstellen um ihren Netzwerkverkehr abzuwickeln. Sozusagen kleine Helferleins. Nutzt eine App ein Helferlein, so erscheint der Verkehr in dem Firewall Protokoll nicht unter der User Nummer der App, sondern unter der des Helferleins. Und da die Helferleins als Kernelerweiterungen (deamon) laufen erscheint der traffic der App als Kernel traffic im log. Ich hoffe das hilft.

 

[Sunny]

@rudolf
Super, toll erklärt.
Vielen Dank [emoji4]

 

[milli4503]

Richtig! Und deswegen sollte man zu allererst diesen netd deaktivieren, oder man kann sich gleich eine Firewall sparen.
In der AFWall+ ist das auch in den Einstellungen möglich.

 

[Heizoelkocher]

Hmm - in AFWall+ ist die entsprechende Option zur Deaktivierung von netd funktional als DNS-Service für Apps bezeichnet. Deaktiviert würde das Gerät keinen Netzzugang mehr haben (lt. AFWall+-Beschreibung).

So richtig schlüssig ist das aber auch noch nicht: ich hab' den Kenel immer noch durch AFWall geblockt (und damit offensichtlich auch netd, der ja als Service für andere Apps fungiert), und trotzdem gehen alle Apps