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

@eldoblo - Nein, nein. - Der NTP-Verkehr in deinen Screenshots ist okay.

Ist jetzt der amazonaws.com-Verkehr nach dem Einfrieren von "com.sec.android.app.bluetoothtest" auch noch da?
 
Moin 000,

der "amazonaws.com-Verkehr" ist nach dem Einfrieren von "com.sec.android.app.bluetooth-test" wohl nicht mehr da.

Ich kann aber jetzt noch nicht von Liebe sprechen, jedoch von einem sehr angenehmen Gefühl. Muss weiter testen.

Wenn es nur kleines Darstellungsproblem ist und Networkblog es nicht anders anzeigen kann, ist die " 50 Stück Appansammlung (1000)", mit der immer gleichen Byteangabe, "leider" zu akzeptieren.

Du hast den Zusammenhang in den vorangestellten Artikeln sehr gut erklärt.

Verständlich ist aber auch, dass dadurch oft wieder die Frage entsteht -"geht nun doch traffic an der AWFall vorbei oder ist das so ok"-.

Es bleibt eben so ein Unbehagen des nicht abschätzen können.
 

Anhänge

  • Screenshot_2015-03-12-08-16-00.png
    Screenshot_2015-03-12-08-16-00.png
    91,9 KB · Aufrufe: 261
Moin, eldoblo,

Das wollte ich lesen. - Dann hätten wir jetzt deine Haupt-Probleme gelöst:

  • Die Firewall funktioniert (mit Custom Scripts)
  • Als DNS-Server wird der gewünschte von OpenDNS benutzt (anstatt der des Providers oder von Google)
  • Der dubiose ausgehende Traffic in die Amazon-Cloud (...amazonaws.com/Samsung Spy Crap/Bluetooth-Test-App) wird durch das Einfrieren (pm disable ...) aktuell unterbunden
  • Datum und Zeit werden bei einem gewünschten NTP-Zeitserver (Uni) geholt
Herzlichen Glückwunsch von mir :smile:

Ich weiß, es ist niicht einfach, sich dieses komplexe Thema zu erarbeiten - egal, was man für einen Wissensstand besitzt. - Es ist anfangs immer harte Arbeit ...

Du hast dir jetzt aber die Grundlagen erarbeitet und kennst die Werkzeuge/Techniken, um dir selbst weiter zu helfen. - Das unangenehme Gefühl wird aber bleiben ... und der Schutz vor diesen invasiven Dingen ist ein nicht-endendes "Projekt".

__

Da ich von dir nicht gelesen habe, ob du die App AdAway installiert hast, möchte ich dir diese nochmals sehr ans Herz legen, falls du sie nicht benutzt.

AdAway spart dir jede Menge "blinden" (Werbe-)Traffic und hat nur Vorteile.

Werbe-Traffic (und allgemein nicht von dir angeforderter/ausgelöster Traffic)

  • verbraucht dein mobiles Daten-Volumen
  • kostet dich damit unnötig dein Geld
  • verlangsamt deinen Seiten-Aufbau beim Surfen (und in anderen Apps)
  • kostet damit deine Lebenszeit
  • verbraucht Akku-Energie durch die Downloads von Werbung und das anschließende Rendering zur Darstellung
  • verringert damit die Laufzeit deines Phones
  • stört/beeinträchtigt das Arbeiten in/mit Werbe-finanzierten Apps
    (Nein, ich habe kein Mitleid mit den Developern, bin u. a. selbst einer. - Wer sich als technische Marketing-/Werbe-"Hure" verkauft/missbrauchen lässt, gehört aus der Zunft ausgeschlossen. - Aber das ist "nur" Philosophie/Politik/meine Meinung - oder einfach nur "Rückgrat", man gehört ja bereits per Geburt nicht zur Klasse der wirbellosen Kriechtiere - aber streichen wir das ...)
  • verfolgt dich und stellt einen immensen Vertrauensbruch/Einbruch in die Privatsphäre dar
  • kostet zusätzlich Zeit und andere Ressourcen, um sich dagegen zu wehren
Deswegen empfehle ich immer die Installation und den Einsatz einer derartigen App, wie AdAway (dabei aber das Donate bitte nicht vergessen), bis die Leute, die Advertising/Tracking ungefragt einsetzen, es kapiert haben und ihr Geschäftsmodell ändern.

AdAway kann auch gegen das Abfließen von persönlichen Daten helfen, die von der ROM/den System-Apps ungefragt und heimlich verschickt werden (siehe Beispiel zu amazonaws.com/anonymen Vebindungen in die Cloud etc.).

Einen schönen Tag noch.
_
 

Anhänge

  • AdAway-Hostnamen-blockieren-2.png
    AdAway-Hostnamen-blockieren-2.png
    17,7 KB · Aufrufe: 299
  • AdAway-Hostnamen-blockieren-4.png
    AdAway-Hostnamen-blockieren-4.png
    12,1 KB · Aufrufe: 312
  • AdAway-Hostnamen-blockieren-5.png
    AdAway-Hostnamen-blockieren-5.png
    13,9 KB · Aufrufe: 286
  • AdAway-Hostnamen-blockieren-6.png
    AdAway-Hostnamen-blockieren-6.png
    19,8 KB · Aufrufe: 292
  • AdAway-Hostnamen-blockieren-7.png
    AdAway-Hostnamen-blockieren-7.png
    28 KB · Aufrufe: 293
  • AdAway-Hostnamen-blockieren-8.png
    AdAway-Hostnamen-blockieren-8.png
    27,2 KB · Aufrufe: 270
  • AdAway-Hostnamen-blockieren-9.png
    AdAway-Hostnamen-blockieren-9.png
    37,6 KB · Aufrufe: 293
Zuletzt bearbeitet:
  • Danke
Reaktionen: eldoblo
@ 000,

ich glaub es geht schon wieder los..............

Kann mir keine vorhandene Hostdatei in AdAway ansehen. Benötige ich ein anderes tool als 920-Text Editor?

Dateien sind runtergeladen und instaliert, lt. AdAway ok!

Was ist jetzt wieder falsch?
 
@eldoblo - Keine Sorge. - Die hosts-Datei ist ca. 1 MB groß (ca. 38.400 Zeilen, also 38.400 geblockte potentielle Daten-"Abzocker" - kein Witz ...) und für AdAway oder 920 Text Editor schwer zu öffnen. - Bei mir dauert es in 920 TE ca. 30 bis 60 Sekunden. - Während dieser Zeit wirkt das Phone wie eingefroren. - Wenn man dann noch zusätzlich herumtippt, wird es schlimmer. - Besser ist es, die Datei auf einen PC zu kopieren und dort zu inspizieren (siehe Notepad++).
 
Zuletzt bearbeitet:
Moin 000,

stimmt, wenn die Hosts Datei geladen wird kann man erst mal einen trinken. Hatte mich total iritiert weil der 920-Text Editor gar nicht mehr "zuckte".

Nachdem AdAway die "bad-domains" installiert hat, kann root doch wieder entzogen werden und die Haken in AFWall auch (wie in der Anleitung auf den ersten Seiten)?

Die Blockierung der Tracking-Adressen läuft dann automatisch im System-Hintergrund, und nur "ab und an" sollte wieder root erteilt werden um die Liste zu aktualisieren.

Vielen Dank für deine Unterstützung
 
@eldoblo - Du liegst mit Allem richtig.

Anstatt AdAway nach einer Aktualisierung root zu entziehen und in der Firewall wieder zu sperren (Haken entfernen), kann man auch alles so lassen und die App einfach nur mit dem Android Terminal einfrieren:
Code:
su
pm disable org.adaway
Wenn man AdAway dann wieder benutzen möchte:
Code:
su
pm enable org.adaway
Damit spart man sich das root Erteilen und das Haken setzen in der Firewall.
Wem das Terminal nicht gefällt, kann eine App benutzen, die Apps einfrieren und auftauen kann. - Die Kaufversion von Titanium Backup kann dies z. B., es gibt aber auch noch andere Apps.

Das Einfrieren hat auch den Zusatz-Nutzen, dass kein RAM verbraucht wird, da AdAway beim Starten des Phones ebenfalls mitstartet, um die Bad-Domain-Updates (hosts-Datei) automatisch holen zu können, wenn dies so eingestellt wurde.
 
Zuletzt bearbeitet:
@000,

mit root-Rechten für Terminal Emulator, ohne Hakenzulassung.
In AFWall kann AdAway obwohl diese App auch root-Rechte hat eingefroren werden und der Boot Vorgang von AdAway entzogen werden?

Nach dem einfrieren/disable erscheint aber auch die AdAway-App nicht mehr auf dem Phone-(Display).

Kann ich noch auf anderem Wege kontrollieren ob die App wirklich aus ist, da diese ja dennoch root hatt(e).

Leider "geht" jetzt Software update und you tube raus?!

Internet Zeitserver kein Haken, you tube kein Haken. Auf einmal auch "Darstellungsproblem"
 

Anhänge

  • Screenshot_2015-03-13-12-44-14.png
    Screenshot_2015-03-13-12-44-14.png
    85 KB · Aufrufe: 215
@000,

wird mit dem Setzen des Haken für -14 NTP Internet Zeitserver
in AFWall erzwungen das die Zeit sich ausschließlich nur über den Internet-Server (hier, bei mir mit Uni-Zeit-Server) synchronisiert?

Also, entweder nur über Mobil oder nur über I-Server?

Eher doch wohl nicht, oder?

Dann die Frage ob es überhaupt 0 sinnvoll ist den Zeitserver zu wählen?

Oder bin ich jetzt janz neben der Spur⚠
 
eldoblo schrieb:
@000,

mit root-Rechten für Terminal Emulator, ohne Hakenzulassung.
In AFWall kann AdAway obwohl diese App auch root-Rechte hat eingefroren werden und der Boot Vorgang von AdAway entzogen werden?
Einfrieren von Apps:
Es spielt keine Rolle, ob eine App Root-Rechte besitzt oder in der Firewall freigeschaltet wurde oder nicht. - Wenn du AdAway einfrierst, wird es genau in diesem Zustand eingefroren. - Die App wird dir in AFWall dann immer noch angezeigt, "lebt" aber nicht mehr (Frozen, Koma, ...) - Das ist ja gerade das Schöne daran ... :)

___
eldoblo schrieb:
Nach dem einfrieren/disable erscheint aber auch die AdAway-App nicht mehr auf dem Phone-(Display).
Nein, von den Homescreens wird sie entfernt. - Der Anwender kann sie ja auch nicht mehr benutzen, weil sie "tot" ist ...

___
eldoblo schrieb:
Kann ich noch auf anderem Wege kontrollieren ob die App wirklich aus ist, da diese ja dennoch root hatt(e).
Vergiss root, die App ist so deaktiviert als wäre sie deinstalliert worden. - Keine weitere Kontrolle notwendig ...

___
eldoblo schrieb:
Leider "geht" jetzt Software update und you tube raus?!

Internet Zeitserver kein Haken, you tube kein Haken. Auf einmal auch "Darstellungsproblem"
Über welche App? - Wenn es der Browser ist (youtube-Domain) ist das ja okay, weil du diesen freigeschaltet hast (den Browser). - "Software Update": Ist das etwas Samsung-ROM-spezifisches? - Das kann man evtl. in den Einstellungen abschalten.

Alles Andere kann ich von hier leider nicht beurteilen, da ich dir ja nicht permanent zuschauen kann, wenn du diverse Haken setzt/wieder wegnimmst, weitere Apps de-/installierst, Einstellungen änderst. - Geh einfach auf einen stabilen Zustand zurück. - Normalerweise macht man immmer zwischendurch mal eine Sicherung des Phones, wenn man zufrieden ist oder bereits viel Arbeit hineingesteckt hat. - Das ist aber jetzt ein völlig anderes und weites Thema. - Dafür gibt es für jedes Phone eigene Foren-Threads ... einfach suchen (TWRP Recovery, Voll-Backup, nandroid etc.) und dann dort fragen.

"Darstellungsproblem" klingt eher nach einem YouTube-Film o. ä., für das dein Phone/die ROM nicht "geschaffen" ist.

___
eldoblo schrieb:
@000,

wird mit dem Setzen des Haken für -14 NTP Internet Zeitserver
in AFWall erzwungen das die Zeit sich ausschließlich nur über den Internet-Server (hier, bei mir mit Uni-Zeit-Server) synchronisiert?

Also, entweder nur über Mobil oder nur über I-Server?
Nein, es wird dadurch erlaubt, dass über eine aktive Internet-Verbindung von *irgendeinem* Zeit-Server über das Protokoll NTP (Network Time Protocol, Port 123) Datum und Uhrzeit geholt werden dürfen.
Wir haben im AFWAll+ Custom Script dafür gesorgt, dass dabei nur der Zeit-Server der Uni angesteuert wird.
Wenn "-14 NTP" in AFWall+ erlaubt ist, dann kann dies über die W-LAN-Schnittsstelle oder über deine präferierte Mobile-Daten-Schnittstelle (also Mobilfunk) passieren. - Wenn beides an ist, wird immer W-LAN bevorzugt. - Die Bevorzugung hat aber nichts mit dem Zeitserver zu tun, das ist Android-Standard, weil ein W-LAN i. d. R. immer kosten-günstiger und schneller ist, als Mobilfunk. Die eine Schnittstelle wird dann für den *gesamten* Traffic benutzt (entweder - oder).
___

Lass mal alles ein wenig "sacken" ... dann machst du in Ruhe weiter.
 
Zuletzt bearbeitet:
eldoblo schrieb:
Nach dem einfrieren/disable erscheint aber auch die AdAway-App nicht mehr auf dem Phone-(Display).
Kann ich noch auf anderem Wege kontrollieren ob die App wirklich aus ist, da diese ja dennoch root hatt(e).
Wenn Du mit Titanium einfrierst, kannst Du ein Titanium-Widget auf dem Home-Screen mit einem Einfrieren/Auftauen Toggle platzieren.
Dabei bleibt das Original-Icon erhalten und wird mit einem roten/grünen Schloss-Symbol überlagert
 

Anhänge

  • Screenshot_2015-03-13-15-28-26.jpg
    Screenshot_2015-03-13-15-28-26.jpg
    2,8 KB · Aufrufe: 532
  • Danke
Reaktionen: linolino
Nur mit der Kauf-Version von Titanium Backup.
 
Mir sind noch zwei Fragen aufgekommen, wenn ich darf?

Hab gestern WhatsApp erwischt, wie er 8.8.8.8 kontaktieren wollte. Xprivacy hat es enttarnt. Da ich unterwegs (Datenverbindung) war, dachte ich zunächst ein DNS-Push durch den Provider wäre der Auslöser. Daraufhin hab ich gleich die resolv.conf gecheckt. Die nameserver waren fix auf OpenDNS.

Ist es etwas hardkodiertes oder wie kommt er drauf, er müsse das Google-Telefonbuch verwenden?

---

Von diversen Apps kommen immer wieder (WLAN im LAN) Anfragen an localhost. Es ist nicht der Broadcast oder Multicast, sondern die eigentlichen Seitenanfragen an site.domain.tld:80 / :443. Die versuchen es gerne gelegentlich bei 127.0.0.1:80 / :443

Könnte es der Rückläufer von Adaway/hosts sein? Also, die blockierten Seiten/Domains die an localhost umleitet werden und dann entsprechend so aufschlagen?

Der ursprüngliche Beitrag von 21:40 Uhr wurde um 22:01 Uhr ergänzt:

Nachtrag: Mir fällt noch was ein. In Xprivacy gibt es die Kategorie Netzwerk/-Adressen. Die versorgt die App mit Infos über die vorhandenen Interfaces und Adressen.
Evtl. versucht dann die App gleichzeitig eine Verbindung über *any* ?
 
Zuletzt bearbeitet:
Ja, manche Apps benutzen von sich aus abweichende DNS-Server, da die zugehörigen IPs (oder Host-/Domain-Namen) entweder hardcodiert im Code einprogrammiert wurden oder aber in deren Einstellungen als Vorgabe-Wert (evtl. änderbar) hinterlegt wurden. - Für WhatsApp kann ich dazu keine konkrete Aussage machen, da ich es nicht benutze.

Allerdings wird durch die im Start-Posting angeführte Regel für die OpenDNS-Server, jede Verbindung zu Port 53 (DNS) auf die OpenDNS-Server "umgebogen" - egal, zu welcher IP die Anfrage gemacht wird, so dass auch WhatsApp nicht zum Google-DNS-Server kommt.
___
Die häufigen 127.0.0.1 (localhost) Anfragen kommen sehr wahrscheinlich von der durch AdAway veränderten hosts-Datei, werden aber nur in Network Log protokolliert, wenn "Hinter Firewall protokollieren" nicht angehakt ist.
___
Zu XPrivacy kann ich keine veritable Aussage treffen, da ich mich mit XPosed bzw. den Modulen nicht intensiv beschäftige. - Ich setze es nicht (mehr) ein, weil XPosed bestimmte Standard-Dateien einer ROM verändert und ich dies (für mich) als unsicher einordne.
 
Zuletzt bearbeitet:
Woran kann es liegen, dass die Einstellung "Start-Datenleck Fix" deaktiviert wird?
Ich habe ein HTC M7 mit S-Off. Ich musste es schon zweimal wieder aktivieren.
 
Jemand eine Idee wie man per Android-Intent (Llama) ein Profilwechsel in afwall auslösen kann?
 
ooo schrieb:
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.

Die Anfrage ist schon ein bisschen her, aber den Tipp habe ich soeben umgesetzt. Die kompletten Einstellungen des Standardprofils sind in der AFWallPrefs.xml abgespeichert. Weitere Profile muss man sich zuerst anlegen, bzw. die ersten drei einmal aufrufen. Dann finden sich an der selben Stelle die jeweiligen Profil-Einstellung AFWallProfile1.xml usw. Jetzt speichert man das Standardprofil AFWallPrefs.xml unter dem Namen der anderen Profile ab oder kopiert den Inhalt auf anderem Wege hinein und ruft anschließend in AFWall die Profile auf, um nur noch die gewollten Änderungen vorzunehmen. Man erspart sich die erneute Eingabe der Skripte usw. Ich habe vor den Änderungen die Firewall deaktiviert und beendet. Achtung, natürlich nie ohne Backup arbeiten.

Es kann notwendig sein, dass man die xml-Dateien an einen anderen Speicherort kopieren muss, um Sie zu bearbeiten (oder die Berechtigungen erweitert). Vor dem zurückkopieren muss man dann ggf. die dort bestehenden Dateien zuerst löschen. Danach die Berechtigungen und Besitzverhältnisse wieder richtig setzen. Die Gruppe konnte ich nicht direkt setzen, hat AFWall dann aber beim ersten Aufrufen des Profils korrigiert.
 
  • Danke
Reaktionen: ooo
Hab mir gestern auch die Donate geholt. Wollte gleich mal testen, ob und wie es funktioniert.

Export in AFWall gemacht, Komplettes Verzeichnis nochmal weggesichert.
Gleiche ROM reflashed,..
Backup importiert und über das Versagen gestaunt.

Ergebnis: App-Settings und Profilnamen waren wieder da, Standardprofil leer (ohne einen Häckcken), die anderen Profile waren befüllt (wahrscheinlich auch nur weil die Dateien vorhanden waren). Die Einträge der Scripte waren in keinem Profil drinnen.

Gut dass ich nicht gewiped habe.
Der Export/Import gehört noch ziemlich überarbeitet.
 
mratix schrieb:
[...] Der Export/Import gehört noch ziemlich überarbeitet.

Siehe hier:
[4.0+][ROOT][2.0.0-PREALPHA] AFWall+ IPTables Firewall [23 MAR 2015] - Post #2382 - XDA Forums
[4.0+][ROOT][2.0.0-PREALPHA] AFWall+ IPTables Firewall [23 MAR 2015] - Post #2383 - XDA Forums
[4.0+][ROOT][2.0.0-PREALPHA] AFWall+ IPTables Firewall [23 MAR 2015] - Post #2388 - XDA Forums

(Original-Dateien in /data/app/dev.ukanth.ufirewall/shared_prefs/ mit tar wegsichern, nach ROM-Updates tar wieder in /data/local/tmp/ auspacken Group und User evtl. auf die (neue) Android UID von AFWall+ setzen mit Terminal/ADB shell und "chown <newuserid>:<newgroupid>, an die Original-Postition kopieren, dann reboot" - kann man sich ein shelll-Script zu schreiben ...)

___

<OT>
:lol: Ich bin "berühmt"! -In den AFWall+ FAQs sind meine Vorschläge für das Schützen/Überleben des "Data Leak Fix" gelandet ...

https://github.com/ukanth/afwall/wiki/FAQ#48-how-can-my-script-survive-an-over-the-air-ota-update
https://github.com/ukanth/afwall/wiki/FAQ#49-how-can-my-script-survive-an-system-wipe

Nette Geste ... Danke an *Unknown*.
</OT>
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: linolino, Pizzapeter, mratix und 2 andere

Ähnliche Themen

F
  • Felix76
Antworten
6
Aufrufe
664
Felix76
F
R
Antworten
14
Aufrufe
446
RoBeat1
R
R
Antworten
7
Aufrufe
665
Meerjungfraumann
Meerjungfraumann
Zurück
Oben Unten