Android Kontakte mit Owncloud synchronisieren

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)

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?

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.

 

Amazon KDP und Korrektur von Fehlern

Die Fehler, die man selbst beim Schreiben macht, findet man schwer. Bevor ich die erste Version hochgeladen hatte, bin ich das Skript immer wieder durchgegangen. (In ausgedruckter Form). Dennoch habe ich etliche Fehler übersehen! 👿

Der nächste Fauxpas, den ich begangen hatte war, dass ich mich auf die Rechtschreibkorrektur von Jutoh verlassen habe. Offenbar war hier etwas falsch konfiguriert, weshalb es danach ausschaute, als ob alles in Ordnung wäre.

Fragt mich nicht warum, aber wie ich das E-Book dann auf meinem Kindle hatte, „sprang“ mich ein Fehler nach dem andren an.

„Mist!“ … das macht keinen guten Eindruck, das muss ich korrigieren.

Ich kann nur jedem raten, das Skript von anderen Leuten lesen zu lassen, BEVOR man es hochladet! Bestenfalls liest man es selbst auch MEHRFACH durch. Vielleicht an unterschiedlichen Tagen und ausgedruckt.

Dumm, dass sich in meinem Umfeld kaum jemand für die von mir behandelte Thematik interessiert. Nach der ersten Seite wurden – ob des Inhaltes – die Augen verdreht…

Naja alles keine IT-Menschen…

Fehlerkorrektur leicht gemacht (nicht)

Aufgrund der oben angeführten Problematik, kam es schließlich zu mehreren Aktualisierungen (Uploads). Mittlerweile ist die Version 5 online.

17 Leute haben sich das Book während der Gratisaktion geladen. Ja, aber das war das Buch mit den Fehlern, die eigentlich nicht passieren dürften.

Amazon macht das schon

Wenn man nun denkt, dass Amazon das Book automatisch aktualisiert, dann liegt man ziemlich daneben. Bei einer Aktualisierung gehen nämlich u.a. vom Leser gesetzte Lesezeichen verloren.

Um dies zu vermeiden, gibt es grundsätzlich kein automatisches Update.

Als „Herausgeber“ des Buches, muss man Amazon kontaktieren und die Fehler exakt benennen.

Dies umfasst den Vergleich von:

  1. Fehlerbehaftetem Abschnitt / korrigiertem Abschnitt
  2. Genaue Angabe der Textposition (sieht man im Kindle oder auch in der App, wenn man zum Beispiel nach dem Fehler sucht – Textsuche)

Nur, sofern Amazon befindet, dass die Fehler von gravierender Natur sind, erhalten Leser, die das Buch bereits gekauft haben, eine E-Mail und können es dann per „Einstellungen / Sync und Download“ auf den Kindle laden.

Es gibt also keine Automatik!

Fazit

Ich finde es unschön, dass eine Fehlerkorrektur mit derlei Schikanen behaftet ist. Schade, dass es keine Lösung dafür gibt, dass Lesezeichen dennoch erhalten bleiben, auch wenn man ein Update ladet.

Ich bin jedenfalls momentan in Kontakt mit Amazon. Alle, die sich die Mühe gemacht haben das Buch zu laden, sollen auch die korrigierte Fassung angeboten bekommen!

Anmerkung: Die Fehler beeinträchtigen die Funktion des Servers nicht!

Teslacrypt-Entwickler geben auf … oder doch nicht

Wie man unter Anderem in diesem Artikel liest haben die Teslacryptentwickler aufgegeben. Allerdings ist der Artikel für mich nicht ganz schlüssig.

Denn etwas weiter unten im Text steht auch:

Dazu wechselten die Cyberkriminellen, die für die Verbreitung der Malware hauptverantwortlich waren, den Anbieter und setzen mittlerweile auf CryptXXX.

Also was nun?

Aufgegeben, oder eben doch nur die „Waffe“ gewechselt?