SanDisk Cruzer Extreme USB 3.0

Wer auf der Suche nach einem schnellen USB-Stick ist, dem kann ich den SanDisk Cruzer Extreme USB 3.0 nur empfehlen. In meinem Fall ist es die Variante mit 64 Gigabyte.

Ich habe lange recherchiert und mich dann doch dazu entschlossen, knapp das Doppelte im Vergleich zu einem USB 2.0 Speicherstick hinzulegen. Im Endeffekt hat es sich rentiert. Denn was bringt einem die große Speicherkapazität, wenn es Stunden dauert diese überhaupt zu füllen?!SanDisk_Cruzer_Extreme_angled

Neben dem Speicherstick habe ich mir noch ein DELOCK USB 3.0 Verlängerungskabel bestellt. So kann der Stick bequem vom Schreibtisch aus an- und abgesteckt werden.

Geschwindigkeitseinbußen durch das Kabel selbst konnte ich erfreulicherweise nicht feststellen. Vielmehr spielt eher die Größe der zu übertragenden Dateien eine Rolle. So dauert es z.B. länger eine Gesamtdatenmenge von 16GB bestehend aus vielen kleinen Files zu kopieren, als eine einzige Imagedatei der gleichen Größe. Testobjekt war das Backup von meinem Raspberry Pi.

Da die Anzeige von Windows teilweise nicht wirklich aussagekräftig ist, habe ich die Geschwindigkeit auch nochmal mit CrystalDiskMark verifiziert:

CrystalDiskMark

Das Ergebnis erfüllt die von SanDisk versprochenen Werte voll und ganz bzw. übertrifft diese sogar.

Abgerundet wird das Angebot mit der hauseigenen Software SanDisk SecureAccess. Diese schützt Dateien in einem verschlüsselten, passwortgeschützten Ordner mit 128-bit-AES-Verschlüsselung.

Firefox 22 wird Tracking-Cookies blocken

firefox-logoFür Version 22 des beliebten Firefox-Browser ist ein Patch geplant, welcher die sogenannten Third-Party-Cookies weitestgehend blockieren wird. Dies soll die Benutzer vor unerwünschten Tracking-Maßnahmen schützen. Der Werbeindustrie wird dieser Schritt ein Dorn im Auge sein, schließlich ist maßgeschneiderte Werbung das Non­plus­ul­t­ra.

Aktuell werden technisch gesehen die Cookies von Drittanbietern auch dann gesetzt, wenn man die Website des Werbetreibenden (sprich den Adserver) nicht aktiv besucht wird. Die Werbung ist quasi im Quellcode der besuchten Website eingebunden. Doch damit soll ab Version 22 Schluss sein. Der Browser wird ab dann nur noch originäre Cookies akzeptieren.

Mozilla hat sich bewusst für diesen Schritt entschieden um die Benutzer zu schützen. Auch wenn Third-Party-Cookies nicht die einzige Möglichkeit sind den Nutzer zu verfolgen, so wird sich die Werbe-Wirtschaft grundlegende Gedanken über ihre zukünftigen Geschäftsmodelle und Praktiken machen müssen.

Ein massives Problem könnten evtl. kleine Websites bekommen, da Werbung bei den Besuchern schon grundsätzlich unerwünscht ist. Wenn jetzt aber hinzukommt, dass diese Werbung noch nicht einmal auf die jeweilige Zielgruppe ausgerichtet ist, werden auch die Klickraten entsprechend zurück gehen. Große Internet-Auftritte wie die von Yahoo, Facebook & Co. werden hingegen mitunter profitieren. Sie können die Tracking-Cookies direkt auf Ihrer Seite einbinden, da die Besucher diese naturgemäß aufrufen um News zu lesen, eMail’s zu schreiben und das Messaging zu nutzen.

Wer schon heute auf Werbung verzichten möchte, der sollte sich das Add-on namens Adblock Plus mal anschauen. Dort ist eine sehr gute und regelmäßig gepflegte Liste hinterlegt, die lästige Werbung rigoros verbannt. Und das schöne daran: Adblock Plus gibt diesen Platz auch noch frei. Für einzelne Seiten können Ausnahmen hinzugefügt werden. Dies wird dann erforderlich, wenn dort ein Adblock-Check hinterlegt ist. Dieser merkt wenn bestimmte Scripte oder Elemente nicht aufgerufen werden. Aber diese Technik ist aktuell noch nicht sehr weit verbreitet.

WebDAV einrichten

WebDAV stellt eine Erweiterung des HTTP-Protokolls dar und kann nicht nur für einzelne Dateien, sondern auch zum Up- und Download von ganzen Ordnerstrukturen verwendet werden. Wenn ihr einen solchen WebDAV-Zugang habt, bietet dieser interessante Möglichkeiten um Dateien auf einen Server hochzuladen. Ein wesentlicher Vorteil ist die Tatsache, dass der gesamte Netzwerkverkehr bei WebDAV im Vergleich zu FTP (Port 21) über Port 80 und ggf. 443 (SSL) abgewickelt wird. Das sind die gleichen Ports, über welche ein Webserver standardmäßig angesprochen wird. Somit müssen an der Firewall keine zusätzlichen Portfreigaben eingerichtet werden und man kann es von (fast) überall nutzen. Die heutigen Desktop-Betriebssysteme und sogar Smartphones beherrschen WebDAV mittlerweile von Hause aus. In der Regel ist keine zusätzliche Software oder Konfiguration erforderlich.

Am Beispiel von Windows zeige ich euch, welche Schritte ihr durchführen müsst. Im Windows Explorer wählt ihr die Option „Netzlaufwerk verbinden„. Es öffnet sich daraufhin ein Dialogfenster. In diesem erfasst ihr folgende Daten:

  • Laufwerk: Beliebiger Laufwerksbuchstabe
  • Ordner: Die Adresse der Freigabe. Sie setzt sich zusammen aus dem
    • Protokoll (// oder //)
    • Servernamen
    • Freigabenamen
      Beispiel: //webdav.example.com/Freigabename
  • Häkchen bei „Verbindung bei Anmeldung wiederherstellen“ (optional)
  • Häkchen bei „Verbindung mit anderen Anmeldeinformationen herstellen“

Empfohlen wird natürlich SSL-Verschlüsselung (https). Dieses Feature ist aber von eurem Anbieter abhängig. Wenn es dort nicht angeboten wird, sollte man vorsichtig sein, da die Login-Daten usw. im Klartext übertragen werden (Vorsicht in öffentlichen WiFi-Netzwerken). Nach einem Klick auf „Fertig stellen“ öffnet sich ein weiteres Fenster wo Benutzername und Kennwort abgefragt werden. Auf Wunsch könnt ihr die Anmeldedaten auch speichern. Das erspart die erneute Eingabe nach einem Neustart. Wenn alles korrekt erfasst wurde, bestätigt die Abfrage mit „OK“ und kurz darauf sollte ein weiteres Laufwerk im Explorer erscheinen. Wenn das nicht der Fall ist, gibt es zwei der häufigsten Problemursachen:

  1. Der Anbieter unterstützt kein SSL. In diesem Fall könnte man von https auf http switchen.
    Dies ist aber sehr unschön und zieht üblicherweise ein weiteres Problem nach sich.
  2. Ein Eintrag in der Windows-Registrierung verhindert im Regelfall die Verbindung mit unverschlüsselten Freigaben, also über http.

Wenn man nun auf Biegen und Brechen die Verbindung mittels unsicherer Standardauthentifizierung herstellen möchte, muss folgender Eingriff in der Registry vorgenommen werden. Macht dies nur, wenn ihr mit dieser Materie vertraut seit. Leider kann man dort auch viel falsch machen. Ruft den Registrierungs-Editor über „Start / Ausführen / regedit“ auf. Hangelt euch dann bis zu folgender Position durch:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ WebClient \ Parameters

Dort solltet ihr einen Eintrag namens „BasicAuthLevel“ vorfinden. Ist dieser wider erwarten nicht zu sehen, überprüft zunächst ob ihr dem obigen Pfad korrekt gefolgt seid. Wenn dieser stimmt legt einen neuen DWORD-Wert (32-bit) an. Der vorhandene bzw. neue Eintrag wird auf den Wert 2 festgesetzt. Das bedeutet, dass die Authentifizierung kein SSL erfordert. Solltet ihr euch irgendwann mal umentscheiden, ändert diesen Value einfach auf 1. Wenn das soweit erledigt ist, sollte der Verbindungsaufbau nach einem Neustart funktionieren.

Wo wir aber gerade in der Registry sind, kann man bei Bedarf noch eine weitere kleine Änderung vornehmen. Standardmäßig ist die Dateigröße bei dieser Methode auf knapp 50 MB begrenzt. Das erkennt man an gleicher Stelle am Eintrag „FileSizeLimitInBytes„. Dort ist als Dezimal-Wert 50000000 vorbelegt sein. Diesen Wert könnt ihr natürlich erhöhen. Für bis zu ein Gigabyte große Dateien ersetzt diesen z.B. durch 1073741824 Bytes (1024^3). Man sollte jedoch wissen, dass ein Transfer einer Datei solchen Ausmaßes einige Zeit in Anspruch nimmt und Windows keine aussagekräftigen Geschwindigkeits- und Restzeitangaben liefert. Einen sehr guten Freeware-Client stellt in diesem Zusammenhang BitKinex dar. Dieser liefert präzise Messergebnisse und es können auch etwaige Verbindungsprobleme näher untersucht werden.

WordPress-Sicherheit erhöhen

wordpress-logo

WordPress ist ein beliebtes und dementsprechend weitverbreitetes Blogging-System. Wenn auch ihr mit dem Gedanken spielt, ein Blog mit WordPress zu realisieren, dann sind die folgenden Vorkehrungen sicherlich hilfreich. Vorweg: 100%ige Sicherheit wird es nie geben, aber eins ist sicher: So selbstverständlich wie man sein Auto zur Inspektion oder zum TÜV bringt, genauso muss man sich um einen Internetauftritt kümmern. Es reicht nicht, diesen einmal zu installieren und der technischen Seite danach keine Beachtung mehr zu schenken. Womit wir auch schon beim Thema wären…

Ich gehe an dieser Stelle davon aus, ihr habt euch die WordPress-Dateien im .zip-Format bereits aus einer offiziellen Quelle heruntergeladen. Entpackt dieses Archiv und benennt den Hauptordner in etwas Abstraktes um. Uploaded diesen dann via FTP auf euren Webspace in einen Domain-Ordner eurer Wahl. Die (Sub-)Domainzuordnung muss dann noch auf diesen abstrakten Pfad gemappt werden. Wenn der Aufruf der gewünschten URL im Browser funktioniert, sollte der Installationsprozess starten.

WordPress setzt auf PHP (serverbasierte Scriptsprache) und MySQL. Letzteres dient dazu, Einstellungen, Seiteninhalte, Artikel und alles was so dazugehört in einer Datenbank abzuspeichern. Dazu werden sog. SQL-Queries performed und die Informationen in Tables abgelegt. Diese Datenbanken und Tabellen sind natürlich ein beliebtes Angriffsziel. Man hört in diesem Zusammenhang öfters mal den Begriff SQL-Injection. Bei der Installation ist das Standard-Tabellen-Präfix wp_ vorbelegt. Das sollte man durch einen individuellen String (Beispiel: qx12_) ersetzen. Dieses prefix könnte theoretisch dazu dienen, dass man mehrere Websites in einer Datenbank unterbringt. Aus vorgenannten Gründen ist davon allerdings abzuraten. Sollte es auf einer Website zu Problemen externer Natur kommen, legen diese schlimmstenfalls nicht direkt mehrere Internetauftritte gleichzeitig lahm.

 Wenn man mit der Installation fertig ist, hat WordPress eine Datei mit dem Namen wp-config.php angelegt, wo sämtliche während der Installation abgefragten Attribute zu finden sind (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST). Ihr findet dort ebenfalls die ganzen KEYs, welche für jedes Blog individuell sind und auch sein müssen. In früheren Versionen von WordPress konnte bzw. musste man diese Schlüssel manuell über die Seite //api.wordpress.org/secret-key/1.1/salt/ erzeugen und via copy & paste einfügen. Heutzutage geschieht dies automatisch. Ihr könnt die Keys später auch von Zeit zu Zeit ändern, danach müssen sich lediglich aktuell angemeldete User neu einloggen. Legt die wp-config.php eine Verzeichnisebene höher ab. WordPress sollte bzw. wird sie dort finden. Damit sind die DB-Zugriffsdaten sicher ausgelagert.

Wenn alles soweit vorbereitet ist, sollte man sich daran machen die sicherheitskritischen Bereiche des Blogs für böswillige Besucher unerreichbar zu machen. Darunter zählt zum einen die Datei wp-login.php und zum anderen der Ordner wp-admin. Das ganze kann über .htaccess realisiert werden, sofern euer Webspace-Paket dieses Feature vorsieht. Man könnte dann entweder eine zusätzliche Passwortabfrage einbauen oder – sofern ihr über eine statische oder eine selten wechselnde IP-Adresse verfügt (z.B. Kabel-Internet ohne Zwangstrennung) – nur einen ganz bestimmten Client zulassen. Wenn ihr euch für letzteres entscheidet, dann müsst ihr eine .htaccess-Datei mit folgendem Inhalt in diesem Ordner ablegen:

<Files wp-login.php>
order deny,allow
deny from all
allow from 127.0.0.1
</Files>

127.0.0.1 müsst ihr natürlich durch die zugelassene IP ersetzen. Solltet ihr im Vorfeld schon die Permalink-Funktion aktiviert haben, so müsst ihr die bestehende .htaccess-Datei nur noch durch den obigen Code ergänzen. Bei dynamischen IP-Adressen (solltet ihr den Aufwand der Sicherheit wegen betreiben wollen) muss diese Datei nach jeder Zwangstrennung angepasst werden. Den Ordner wp-admin sichern wir mit folgendem .htaccess-Inhalt:

order deny,allow
deny from all
allow from 127.0.0.1

Hier 127.0.0.1 analog ersetzen. Diese .htaccess muss direkt im Ordner „wp-admin“ abgespeichert werden. Wer sich jetzt fragt, warum er Dateien, aber keine Verzeichnisse in einer .htaccess-Datei absichern kann, dem sei gesagt das die Verwendung der <Directory>-Direktive nicht über .htaccess möglich ist. Das bedeutet, man muss die IP nach einem Reconnect immer zweimal ersetzen. Muss jeder für sich selbst entscheiden. 😉

Wer sich für die Passwort-Methode entscheidet sollte wissen, dass dieses im Klartext übertragen wird. Ebenso beim normalen Login ins Backend. Wer nicht gerade über einen dedicated Webserver verfügt, sondern sich seinen Webspace nach dem Shared-Hosting-Prinzip teilen muss, dem sind SSL-Zertifikate leider verwehrt. In der Praxis bedeutet dieser Umstand, dass theoretisch das Mitlesen und Aufzeichnen eurer Login-Daten z.B. im unverschlüsselten WLAN eines Internet-Cafés möglich ist. Das ganze könnte man unterwegs durch den Einsatz eines eigenen VPN absichern, doch das würde an dieser Stelle den Rahmen sprengen und beansprucht einen eigenen Blog-Artikel. Dennoch hierzu eine kurze Anmerkung: Wenn ihr Euch von unterwegs, sprich von einer fremden IP, einloggen wollt, dann hättet ihr eigentlich keinen Zugriff auf das Weblog mit .htaccess-Sperre. Da ihr dies aber dann über ein VPN-Gateway macht, sieht es für den Webserver so aus, als wenn ihr vom heimischen Rechner auf ihn zugreift. Das bedeutet Sicherheit und Flexibilität.

OK, so weit, so gut. Bevor man mit dem Bloggen loslegt, empfiehlt es sich einen neuen Administrator-Account anzulegen. Dadurch können böse Besucher zum einen unter der User-ID Nr. 1 schonmal keinen Administrator-Account ermitteln und zum anderen ist die Umbenennung des Benutzernamens (gleich Login) von WordPress leider nicht vorgesehen. Der neue Administrator sollte möglichst kryptisch angelegt werden. Das man ein starkes Passwort bestehend aus Zahlen, Sonderzeichen, Gross- und Kleinbuchstaben wählen sollte erklärt sich von selbst. Mit diesem meldet man sich auch gleich an, löscht den ersten Administrator und legt einen weiteren User, z.B. in der Rolle eines Redakteurs an. Dieser Benutzer sollte dann zum eigentlichen Bloggen verwendet werden. Der Administrator wird dann nur noch für tiefgreifende Änderungen, z.B. die Struktur und sonstige Einstellungen betreffend oder das Editieren der Theme-Dateien verwendet.

Das sind im Großen und Ganzen einige Tips um WordPress sicherer zu machen. Achja, bevor ich es vergesse: WordPress sucht automatisch nach Updates der Core-Dateien, Themes und Plugins. Es empfiehlt sich diese regelmäßig durchzuführen, weil damit sowohl Sicherheitslöcher gestopft, als auch Fehler ausgemerzt  und weitere Verbesserungen implementiert werden. Bei der Menge der Plugins gilt grundsätzlich: So viele wie nötig, so wenige wie möglich. Da sich auch in den beliebten Erweiterungen Malware befinden kann, sollte man diese mit Bedacht auswählen.