Archiv der Kategorie: Hosting

Firefox: Diese Verbindung ist nicht sicher

/ Hosting

Seit der Version 52 von Firefox stellen viele Internetnutzer fest, dass bei vielen Websites auf einmal die Meldung „Diese Verbindung ist nicht sicher“ erscheint.

Was hat es damit auf sich?

Dieser Hinweis ist eine neue Funktion. Firefox weist ab jetzt beim Ausfüllen von Formularen mit Passwortfeldern darauf hin, wenn die Datenübertragung zu einer Website nicht mit einem SSL-Zertifikat verschlüsselt stattfindet.

Schon immer gilt: Sie sollten persönliche Daten, insbesondere Bank- oder Kreditkartendaten sowie Passwörter nur auf Websites eingeben, bei denen https:// und ein Schlüsselsymbol in der Adresszeile zu sehen sind:

 

 

Wenn das nicht der Fall ist, wenn also z.B. nur http:// ohne ein „s“ am Ende sichtbar ist, erfolgt die Übertragung der von Ihnen eingegebenen Daten unverschlüsselt. Falls irgendjemand illegalerweise die Daten mitliest, erhält er Ihre Daten im Klartext.

Was ist aber, wenn diese Meldung auf Ihrer eigenen Website, z.B. beim Anmelden am Backend Ihres CMS-Systems, erscheint? Zunächst einmal: Keine Panik! Es ist nicht so, dass die Verbindung zu der gewählten Websites auf einmal nicht mehr sicher ist, während sie es früher war. Wenn Sie bisher noch kein SSL-Zertifikat installiert hatten, war die Verbindung noch nie in dem Sinne sicher, dass die Daten verschlüsselt übertragen werden. Neu ist, dass Firefox jetzt darauf hinweist.

Am besten ist es natürlich, wenn Sie die Datenübertragung von und zu Ihrer komplette Website mit einem SSL-Zertifikat verschlüsseln. Die gute Nachricht: deLink bietet ab sofort für jede bei deLink gehostete Website (ab dem Hosting-Paket WebHome) ein kostenloses SSL-Zertifikat an. Für die deLink-Cloud-Pakete können Sie für einen Aufpreis von EUR 1,- pro Monat ein SSL-Zertifikat bestellen.

Aber bitte beachten Sie: Bei einigen CMS-Systemen wie z.B. WordPress ist es erforderlich, die Inhalte auf einen Einsatz von https anzupassen. Bei älteren Hosting-Paketen kann ein Umzug auf einen neueren Server erforderlich werden. Dazu beraten wir Sie gerne.

Website auf neuem Server testen

/ Hosting

Immer, wenn eine bestehende Website auf einen neuen Webserver umziehen soll, stellt sich die Frage: Wie kann ich die neue Website testen oder bearbeiten, während die zugehörige Domain noch auf die alte Website zeigt? Nehmen wir als Beispiel meinedomain.de. In den DNS-Einträgen für meinedomain.de (und normalerweise auch www.meinedomain.de) ist ja die IP-Adresse des alten Servers eingetragen, und alle Zugriffe über http://www.meinedomain.de werden auf den alten Server geleitet.

Mit einem kleinen Trick kann man erreichen, dass – nur für einen selbst und nicht für die Öffentlichkeit –  http://www.meinedomain.de auf den neuen Server geleitet wird. Die DNS-Auflösung, also die Zuordnung einer Domain zu einer IP-Adresse, startet damit, dass der Browser in der HOSTS-Datei auf dem lokalen Rechner nachschaut, ob er für die aufgerufene Domain einen Eintrag findet. (Zu Anfangszeiten des Internet, als es noch keine öffentlichen Nameserver gab, war dies übrigens die einzige Möglichkeit, eine DNS-Auflösung zu bekommen. Jeder Anwender musste sämtliche Domains mit den zugehörigen IP-Adressen selbst in seiner HOSTS-Datei eintragen und pflegen.)

Die Lösung ist also ganz einfach: Man muss nur in der HOSTS-Datei auf seinem Rechner einen Eintrag vornehmen, der die Domain mit der IP-Adresse des neuen Servers verknüpft. Der Eintrag selbst ist auch ganz einfach, er besteht aus einer einzigen Zeile, die man am besten an das Ende der Datei anfügt. Die Zeile hat die Form

<IP-Adresse> <Domain> … <Domain>

Nach der IP-Adresse können eine oder mehrere Domains stehen, Wenn also z.B. mydomain.de auf den Server mit der IP 88.127.4.92 umziehen soll. muss die Zeile

88.127.4.92 mydomain.de www.mydomain.de

an die lokale HOSTS-Datei angefügt werden. Allerdings gibt es meistens praktische Probleme, diesen Eintrag durchzuführen.

  • Wo finde ich die lokale HOSTS-Datei?
  • Wie kann ich sie editieren?
  • Wie kann ich sie speichern?

Auf LINUX-Systemen finden sich die lokalen HOSTS-Einträge in der Datei /etc/hosts und lassen sich mit jedem Texteditor, also z.B. mit vi oder nano bearbeiten.

Auf Windows-Systemen ist die lokale HOSTS-Datei etwas mehr versteckt, und das – je nach Windows-Version – an unterschiedlichen Orten. Am besten stellt man sich auf der Platte C: in das Verzeichnis Windows und sucht dann nach hosts (ohne Dateiendung). Auf einem Windows 7 32bit findet man dann z.B.

C:\Windows\System32\Drivers\etc\hosts

exec_as_adminDas nächste Problem ist es, diese Datei zu editieren. Windows sperrt sich – sinnvollerweise – aus Sicherheitsgründen dagegen. Ein Weg ist es, das Programm Editor (meistens unter Start -> Alle Programme -> Zubehör zu finden) mit erweiterten Rechten auszuführen. Dazu das Icon Editor mit dem rechten Mausknopf anklicken und dann Als Administrator ausführen wählen. Jetzt muss man zulassen, dass durch das Programm Änderungen am Computer vorgenommen werden und anschliessend zum Verzeichnis navigieren, in der hosts liegt. Nun noch eine kleine Hürde: Standardmässig sieht man hosts jetzt nicht, weil der Editor nur Textdateien (*.txt) auflistet. Also noch auf Alle Dateien (*.*) umstellen, und dann kann man hosts in den Editor laden.

Die Datei ist im Originalzustand nur ein paar Zeilen lang. Jetzt einfach die gewünschte Zeile unten anfügen und speichern. Hierbei kann wieder ein Problem auftreten: Viele Virenschutzprogramme lassen Änderungen an der lokalen HOSTS-Datei nicht zu und verhindern das Abspeichern. Falls das der Fall ist, muss noch die Einstellung im Virenschutzprogramm so geändert werden, dass hosts auch gespeichert werden kann. Hier die EInstellung am Beispiel von AVIRA Professional Security:

hosts_aviraDer Haken bei Windows hosts Datei vor Änderungen schützen muss entfernt werden.

Bevor die geänderte Einstellung wirksam wird, müssen sämtliche Browserfenster geschlossen und der Browser neu gestartet werden. Wenn alles funktioniert hat, erscheint jetzt die Website auf dem neuen Webserver – aber nur auf dem Rechner, auf dem diese Änderungen durchgeführt wurden.

Die Tatsache, dass der Browser neu gestartet werden muss, kann man dazu nutzen, die alte und die neue Website parallel anzusehen: Einfach in einem Browser (z.B. Safari) die Website aufrufen, bevor man die Änderung an der hosts speichert (dann ist in diesem Browser die alte Website zu sehen), dann die Änderung speichern und sie danach mit einem anderen Browser (z.B. Firefox) aufrufen. Mit mehreren Fenstern oder Instanzen ein und desselben Browsers funktioniert das nicht; man muss unterschiedliche Browser-Typen verwenden.

Zum Schluss: Nachdem man mit den Tests und der Bearbeitung der neuen Website fertig ist, nicht vergessen

  • die Änderungen an der HOSTS-Datei wieder zu entfernen
  • ggfs. im Virenschutzprogramm die Änderungssperre für die HOSTS-Datei wieder zu aktivieren

 

 

 

 

Shellshock bei deLink

/ Hosting

bash

1985 wurde die von Brian Fox entwickelte UNIX-Shell entwickelte UNIX-Shell bash weit verbreitet als Ersatz für die Bourne Shell eingeführt. Seit damals existiert eine Sicherheitlücke, über die Angreifer weitgehenden Zugriff auf Systeme erlangen können, auf denen bash installiert ist. Diese Lücke wurde erst in der letzten Woche entdeckt! Die ersten Meldungen zu der Shellshock genannten Lücke erreichten deLink am 24.09.2014. Der Natur des Problems entsprechend waren alle LINUX-Systeme bei deLink, egal ob Debian, CentOS oder SUSE, betroffen. Bereits am nächsten Tag waren alle kritischen Systeme mit den entsprechenden Patches gesichert.

Gleich darauf wurden weitere Lücken in bash veröffentlicht, die ein erneutes Patchen aller Server erforderten. Am Sonntag, dem 28.09.2014 war dann der zweite Update auf allen kritischen Systemen, Hosting-Servern, Managed Servern und Mailservern installiert und auf Wirksamkeit getestet. Alle Kunden, die eigenverwaltete Server gemietet haben, wurden mit einer entsprechenden Anleitung zur Problembehebung informiert.

Die sorgfältige Prüfung aller Server ergab an keiner Stelle eine Hinweis darauf, dass die Lücken in bash ausgenutzt worden wären.

 

 

Heartbleed bei deLink

/ Allgemein, Hosting

heartbleedDer kleine, aber gravierende und weitreichende Fehler in der Verschlüsselungssoftware openSSL, der es unter dem Namen Heartbleed-Bug zu großer Bekanntheit auch ausserhalb von Fachkreisen gebracht hat, betrifft auch deLink und die Kunden von deLink.

Auf etwa 30% aller Server von deLink war openSSL mit diesem Fehler installiert. Unmittelbar nach dem Bekanntwerden des Problems haben wir auf allen betroffenen Servern die Fehlerbehebung installiert. Ab dem 08.04.2014 15:01 CET gab es bei deLink keinen Server mehr, der die Lücke aufwies. Trotzdem bedeutet dies, dass die Daten von SSL-Zertifikaten und damit verschlüsselten Passwörter in der Zwischenzeit in falsche Hände gekommen sein könnten.

Wichtig für Sie

Die Domain- und Serververwaltung und der Kunden-Verwaltungsbereich bei deLink waren zu keinem Zeitpunkt von diesem Problem betroffen. Hier besteht für Sie kein Handlungsbedarf.

Das Emailsystem von deLink war von diesem Problem betroffen. Die Verschlüsselungssoftware sowie das SSL-Zertifikat wurden ausgetauscht. Sicher (nach heutigem Stand) ist Ihre Email aber erst wieder, wenn Sie Ihre Passwörter geändert haben. Wir haben alle Email-Kunden dazu informiert.

Sämtliche von deLink bezogenen, eventuell betroffenen SSL-Zertifikate wurden kostenlos ausgetauscht. Alle Kunden, die SSL-Zertifikate von anderen Anbietern auf deLink-Servern installiert haben, wurden informiert.

Fazit

Wieder einmal zeigt sich, dass eine zu starke Zentralisierung auch bei kleinen Problemen globale Folgen haben kann. Bisher haben wir keinerlei Anzeichen dafür, dass der Heartbleed-Bug Schaden für die Kunden von deLink angerichtet haben könnte. Hoffen wir, dass es dabei bleibt.