Daniel

TP-Link Archer MR200 – Drei Hutchison und 4G – fixe IP

von

Der TP-Link Router bietet mehr Möglichkeiten wie der Webgate3, deshalb schickte ich mit heutigem Tage den braven Gate in die Pension. Zuvor entfernte ich natürlich noch die Simkarte und steckte sie in den SIM-Slot des TP-Link.

Da ich externe Antennen verwende, blieben die mitgelieferten Stummelantennen originalverpackt in der Verpackung liegen.

Nur noch das CAT-Kabel anschließen, die Stromversorgung anstecken und Power UP.

„Das wird eine Plug and Play Installation“, dachte ich mir.

Standardmäßig hat der MR200 die IP 192.168.1.1. Ich arbeite mich durch den kurz gehaltenen Assistenten, sehe dass mein Provider samt APN drei.at bereits erkannt worden ist, klicke hastig weiter…

Internet Verbindung wird überprüft… und überprüft… und FEHLER, keine Verbindung

Kurz überlegt, was hab ich falsch gemacht, mir fällt nichts ein. Signalstärke liegt bei 100%. Trotzdem hol ich die Stummelantennen raus. Signalstärke fällt auf 70%. Der Verbindungstest schlägt fehl.

Ich wechsle in das Menü „Internet“ im Backend des Router. Stelle den Network Mode von Auto auf 4G. Keine Verbindung. Na gut, dann versuch ich halt auch noch 3G. Plötzlich lese ich „connected“.

Jetzt, wo ich eine Internetverbindung zu Stande gebracht habe, kann ich gleich ein Firmware-Update durchführen. (vielleicht behebt ja das das Problem). Ein unspektakuläres Firmware Update später, muss ich jedoch feststellen, dass die Aktualisierung genau „nichts“ gebracht hat. Es funktioniert immer noch nicht.

Bleibt mir wohl der Griff zum Telefon nicht erspart – Hotlinetime.

Gibt es vielleicht irgendwelche Einschränkungen seitens der Providers? Meine letzte Hoffnung zerstört der sehr freundliche Mitarbeiter mit einem „Uns ist egal, welche Hardware sie einsetzen, sie müssen nur den APN: drei.at einstellen.“ (Anm.: Ich habe gefragt, ob das auch bei fixer IP so ist).

Mist, da hat wohl der Router einen Defekt… Doch dann passierte es ;-).

Mir schoss in den Kopf, dass ich irgendwo mal etwas vom APN: static.drei.at gelesen hab. (Gedankengang: static.drei.at … statische IP, könnte vlt. klappen).

Ich stelle also den APN auf static.drei.at um, schalte auf 4G und der Router connected. Damit meine Verbindung allerdings auch auf 3G zurück fallen kann, belasse ich dann die Einstellung auf Auto.

Fazit

Wer Drei Hui Flat in Verbindung mit einer statischen (fixen) IP verwendet und nicht den Webgate3 einsetzt, muss den APN manuell auf static.drei.at setzen, sonst klappt die Verbindung per 4G nicht!

static_drei

Acer Iconia Tab A700 – Recovery Menü

von

Stunden hab ich nun gebraucht, um ein mir nicht bekanntes Acer Iconia A700 in das Recovery Menü zu bringen. Es ist in einem Bootloop festgesteckt. (Ich wusste, nicht welche Androidversion installiert war…)

Wipe Data / Factory Reset per Recoverymenü hat es schließlich gerettet. 😉

…und Volume minus ist der Teil der Wippe der 2 Punkte hat, Volume + der Teil der nur einen Punkt als Markierung hat… Logisch? Nein!!! *WTH!!!*

 

Gefühlte 100 Interneitseiten und Tastenkombinationen später… (DANKE: http://forum.xda-developers.com/showpost.php?p=32374546&postcount=2)

With JB there is a change on the A700 (can’t test on A701):

Boot into recovery:

– Press [vol-] + [power]
– Once the tablet vibrated, let go [power] and keep [vol-].
– Now the tablet vibrates a second time, let go [vol-] and press [vol+] quick
– Once the text that appears on the screen („loading recovery kernel image“), let go [vol+].

Android Kontakte mit Owncloud synchronisieren

von

Nachdem ich mich in letzter Zeit recht intensiv mit dem Abkoppeln von den Bigplayern in Sachen Cloudservices beschäftige, habe ich mir heute angeschaut, wie ich denn meine Kontakte von meinem Android Smartphone in die ownCloud bringe.

Zuallererst muss natürlich die Kontakteapp in Owncloud installiert werden.

Einerseits  testete ich das kostenlose CardDAVSync-free, das nur Kontakte synchronisieren kann.

Hier bin ich auf ein Problem gestoßen: Ändere ich in Owncloud den Namen des Kontaktes, ändert sich dieser nach der Synchronisierung am Smartphone nicht (jedenfalls nicht so, wie ich es erwartet habe).

Nehmen wir hierfür ein Beispiel: Ein Kontakt ist nur mit Vorname „Sonja“ gespeichert. Ich ändere in Owncloud-Kontakte im obigen Bereich den Kontakt auf „Test Sonja“ und synchronisiere.

testsonja
Von Sonja auf Test Sonja umbenannt

Dennoch bleibt am Smartphone der Name zumindest bei der Kontaktliste (Anzeigename) auf Sonja stehen.

Geht man in die Detailansicht des Kontaktes, dann erkennt man, dass hier sehr wohl „Test Sonja“ hinterlegt ist.

contactdetails1

Der Anzeigename in Owncloud entspricht nicht dem Vornamen und Nachnamen des Kontaktes im Smartphone. Das ist zumindest meine Annahme. Ändert man die Details direkt am Smartphone und synchronisiert erneut, funktioniert es wie erwartet.

Dies war der Grund weshalb ich noch eine kostenpflichtige Smartphone-App getestet habe – DAVDroid.

Beide Apps legen am Smartphone ein eigenes -dem Konto zugeordnetes- Adressbuch an. Im Falle von DAVDroid nennt sich das Adressbuch somit DAVdroid. Anfangs ist das Adressbuch noch leer.

Konfiguration der App

Grundsätzlich sollte https bei der Verbindung zum ownCloud-Server verwendet werden. Die Konfiguration ist eigentlich schnell erledigt. Man muss nur Username / Passwort und den richtigen „dav-pfad“ angeben.

Für Owncloud lautet dieser /remote.php/dav/ der komplette URL würde beispielsweise dann so lauten: https://owncloud.deinedomain.com/remote.php/caldav/

Anmerkung: Im obigen Beispiel wird angenommen, dass owncloud direkt per Subdomain „owncloud“ angesteuert werden kann, weshalb hier im Pfad /owncloud wegfällt.

Natürlich wird auch noch der ownCloud Benutzername und das Passwort von DAVDroid gefordert, um die Verbindung aufbauen zu können.

Details zur Konfiguration findet man auch auf der Website des Entwicklers.

Kontakte von GMAIL nach DAVDroid verschieben

Auf meinem Smartphone (Android 6.0.1) kopiere ich alle Kontakte von meinem Googlekonto zu DAVDroid, wobei ich die Kontakte jedoch auf meinem Googlekonto belasse (Backup).

Danach blende ich in der Kontakteapp nur die Kontakte von DAVDroid ein.

Synchronisierung anstossen

Auf dem PC bereits in Owncloud (Kontaktapp) eingeloggt, starte ich die Synchronisierung und beobachte dabei das Logfile meines Apachen (owncloud_access.log). Ich sehe etliche PUT Kommandos. Gut… Die Kontaktapp von Owncloud füllt sich mit Inhalten.

Alles funktioniert soweit, wie bei der Gratisapp auch.

ABER: Ich laufe wieder in selbiges Problem (siehe oben).

Ein Denkfehler meinerseits? Ein Konfigurationsfehler? ein Bug?

Ich weiß es im Moment nicht…

 

 

Owncloud 9.0.3 — Datenverzeichnis aus dem Internet erreichbar (falsche Meldung im Adminbackend)

von

Ihr Datenverzeichnis ist möglicher Weise aus dem Internet erreichbar. Die .htaccess-Datei von ownCloud funktioniert nicht. Wir raten Ihnen dringend, dass Sie Ihren Webserver dahingehend konfigurieren, dass Ihr Datenverzeichnis nicht länger aus dem Internet erreichbar ist, oder Sie verschieben das Datenverzeichnis außerhalb des Wurzelverzeichnisses des Webservers.

So, oder so ähnlich, tönt es momentan im Adminbackend von Owncloud 9.0.3, obwohl man (bis auf das Owncloud Upgrade auf die Version 9.0.3) nichts am Server gemacht hat.

Das Problem bzw. genauer gesagt die „Falschmeldung“ ist wohl auf einen Bug zurückzuführen.

Dennoch sollte man versuchen, ein File aus dem Datenverzeichnis aufzurufen, ohne eingeloggt zu sein:

Bsp: https://dein.owncloud.com/data/owncloud.log

Startet der Download, ohne dass man eingeloggt ist, dann sollte man sich schleunigst um die Konfiguration des Webserver kümmern. Hier wird dann vermutlich die .htaccess Datei wirklich nicht berücksichtigt.

Ansonsten handelt es sich bei dieser Meldung im Adminbackend um eine Fehlermeldung, die nicht der Wahrheit entspricht.

https://github.com/owncloud/core/pull/25331

In dem Fall also auf 9.0.4 warten, um den vermeintlichen Fehler los zu werden.

SSL – Schadsoftware – Sicherheit im Internet – gibts das wirklich?

von

Die Angriffsszenarien aus dem Internet sind mannigfaltig. In den letzten Monaten werden wir – die im Internet unterwegs sind und vielleicht auch Dienste (Server) laufen haben – von einer Ransomwarewelle geradezu überrollt.

Es gibt „klicki-bunti“ Ransomwarebaukästen, mit dem sich so gut wie jeder seinen eigenen Trojaner zusammenklicken kann. Kombiniert mit unbedarften Anwendern, die Emailanhänge ohne nachzudenken öffnen, ist das Chaos programmiert.

Knackpunkt TLS / SSL Verschlüsselung

Das Folgende ist nicht Neues, dennoch möchte ich darauf eingehen…

Eigentlich sollte SSL zur Verschlüsselung des Datentransfers dienen. Dies verhindert, dass ein Dritter die Daten ausspähen kann. Eine gute Sache.

Nehmen wir jetzt zum Beispiel jedoch die Verhaltensweise diverser Ransomware und auch von andren Trojanern her, sieht das dann so aus:

infection

Das Problem, auf das man hier unter Umständen stößt ist, dass ein eventuell vorhandener Security-Gateway zwar unverschlüsselte Datenströme analysiert, verschlüsselte Datenströme jedoch nicht überprüft. Würde jetzt also beispielsweise ein Makro innerhalb der Datei, die man per Email erhält (Anhang), die Schadsoftware per HTTPS nachladen, käme diese ungecannt bis auf den PC und könnte böses anstellen.

Sofern es die Möglichkeit des SSL-Scans am Security-Gateway gibt, sollte man dies auf jeden Fall aktivieren. Um zu überprüfen, ob z.B. Downloads vom Gateway gescannt werden, bietet sich der Eicar-Testvirus an.

Unter www.eicar.org kann man sich „Testviren“ herunterladen.

Entschließt man sich für die Aktivierung des HTTPS-Scans, sollte man bedenken, dass es zu Sicherheitswarnungen in div. Browsern kommen kann, da sich die Appliance quasi in den verschlüsselten Datenstrom einschaltet. Um diese Sicherheitswarnungen zu umgehen, sollte man das Zertifikat des Gateway in den verwendeten Browser importieren.

Firefox

ffzertifikat

Internet Explorer

iezert

Bitte unbedingt auch die HTTPS Downloads ausprobieren. Kommt das File durch, ohne abgefangen zu werden, scannt eine eventuell vorhanden Appliance den verschlüsselten Datenstrom nicht, oder ist falsch konfiguriert.

Blockieren von Email-Anhängen am Security Gateway

Für mich hat es sich als sehr sinnvoll herausgestellt, diverse Anhänge (nach Dateiendung/Typ) bereits am Security-Gateway zu blocken.

blocked_attachments

Hier gilt jedoch ebenso: Hat man am Gateway den SSL-Scan für Emails nicht aktiviert, kommen diese Anhänge bis auf den Client durch, sofern die Verbindung verschlüsselt abgewickelt wird!

Fazit

100%ige Sicherheit gibt es -wie wir alle wissen- nicht. Man kann jedoch etwas dazu beitragen, um den Erfolg von Angriffen zu minimieren.

  • Kopf einschalten, bevor man auf dubiose Anhänge klickt und selbige ausführt
  • Richtige Konfiguration von vorhandenen Sicherheitsmechanismen
  • Regelmäßige Prüfung auf korrekte Funktion
  • Informiert bleiben
  • Nicht als Administrator arbeiten
  • Im Client-/Serverbereich: Zugriffsrechte entsprechend vergeben. Dort wo ein User keinen Zugriff hat, kann auch der Verschlüsselungstrojaner nichts anstellen.