Backups, Updates, Viren und Malwaretests für Webseiten

Bei den genannten Themen herrscht im Gespräch mit unseren Kunden häufig ein betretenes Schweigen. Bei den meisten Webseiten ist es tatsächlich ohne Fachkenntnisse fast nicht möglich, ein vollständiges, aktuelles Backup zu erstellen.
Dabei gilt für Webseiten eigentlich das gleiche wie für den Computer, mit dem man arbeitet: tages- oder zumindest wochenaktuelle Backups sollte es für den Fall der Fälle geben.

Aber von vorne angefangen: Warum haben so wenige Personen oder Unternehmen Backups von der ersten Visitenkarte, die ein neuer Kontakt als erstes zu sehen bekommt? Warum werden Webseiten für teils mehrere 10.000 Euro erstellt, diese dann jahrelang liebevoll mit Content gepflegt, die Seiten teilweise nochmal aufwändig erweitert und es existieren nur sporadische Backups?

Unsere Einschätzung ist, dass einfach das Angebot und das Bewusstsein fehlt. Mit beidem will ich hier aufräumen.

Das Internet ist ein gefährlicher Ort

Es werden nicht nur Drogen und Waffen über das Internet gehandelt, jeden Tag denken sich Hacker, Phracker, Cracker, Script Kiddies und andere Personengruppen neue Wege aus, Deine Webseite zu hacken. Dabei geht es schon lange nicht mehr rein um das destruktive Zerstören der gesamten Seite. Vielmehr geht es darum, Traffic (also Besucher oder Datenverkehr) umzuleiten, Daten von der Webseite oder dessen Nutzern zu stehlen (Datendiebstahl) oder über die Webseite Schadsoftware zu verteilen oder den vorhandenen Inhalt zu verändern. Die Wege dieser Personen werden dabei immer perfider und sind zumeist nicht auf den ersten Blick zu erkennen.

Leider – und mit steigender Anzahl – sind diese Versuche oft erfolgreich.

Was kann ich machen, damit meine Webseite nicht gehackt wird?

Glücklicherweise veröffentlichen die Hersteller und Entwickler der meisten CMS und den Erweiterungen regelmäßig Updates, um die Sicherheitslücken zu schließen, sobald diese erkannt werden. Die beste Verteidigung gegen diese Angriffe ist somit, die regelmäßige Aktualisierung des Systems. Abhängig von Deiner Webseite sind ggf. zusätzliche Sicherheitsmaßnahmen vom Hersteller empfohlen. Einer der wichtigsten Faktoren ist jedoch immer die regelmäßige Aktualisierung der Webseite!

Optimalerweise funktionieren die Updates des Systems vollautomatisch. Dies geht leider nicht bei den meisten CMS. Im Idealfall wird die Webseite geklont, das Update in der geklonten Umgebung durchgeführt. Darauf wird ein Test durchgeführt, der Änderungen optisch/inhaltlich erkennt. Wenn alles korrekt funktioniert, wird das Backup angefertigt und das Update im Live-System durchgeführt.

Aber wie erkennt man überhaupt, dass seine Webseite gehackt ist?

Im schlechtesten anzunehmenden Fall siehst Du oder gar einer Deiner Kunden in den Google Suchergebnissen den Hinweis „Diese Website wurde möglicherweise gehackt“ oder wenn Du darauf klickst siehst Du eine rote Bildschirm-Benachrichtigung „Diese Website kann Ihren Computer beschädigen“. Dann hat sogar schon Google mitbekommen, dass Deine Webseite offenbar ein Problem hat.

Nicht ganz so gravierend (aber immernoch peinlich genug): Du siehst auf einmal Inhalte auf der Seite, die nicht von Dir oder Deinem Team stammen. Hier können zwei Dinge passiert sein: 1. Deine Passwörter und Benutzerdaten sind irgendjemandem in die Hände gefallen oder 2. Das CMS Deiner Webseite hat eine Sicherheitslücke, die ausgenutzt wurde. Im besten Fall sind in beiden Fällen nur Inhalte ausgetauscht worden. Vielfach werden in einem solchen Fall aber auch noch eine oder gleich mehrere Hintertüren zu der Homepage geöffnet.

Diese Webkonsolen, Malware, Viren oder sonstige Schadsoftware bekommt man mit einem Viren-, Malwarescanner oder auch Diff-Tool (zeigt Unterschiede zu einem Backup oder dem originalen Code des CMS) zumeist identifiziert, sodass man sie entfernen kann. Das kann jedoch einige Zeit dauern, weshalb auch in einem solchen Fall meist ein aktuelles Backup einfacher erledigt wäre.

Was ist noch wichtig für die Sicherheit meiner Webseite?

Security Audits zum Beispiel. Hier werden Antworten auf die folgenden Fragen gegeben:

  • Ist eine Sicherheitslösung im CMS integriert?
  • Ist eine Web Application Firewall (kurz WAF) vor dem CMS? Diese filtert DDoS-Angriffe und ist in der Lage verdächtigen Datenverkehr zu filtern.
  • Von wann ist das letzte Backup?
  • Ist das Backup integer? Zur Erläuterung: Ein Backup ist erst dann ein Backup, wenn man getestet hat, dass sich daraus das System wiederherstellen lässt.
  • Sind das CMS und dessen Erweiterungen/Plugins aktuell?
  • Wie sieht die Serverumgebung (Webserver, Datenbank, …) aus?
  • Ist das System gehärtet? Unter Hardening versteht man in der Regel die Absicherung gegen Angriffe von außen. Ein Hack ist zumeist ein Umstand mehrerer unglücklicher Zufälle, daher sollte man sich nicht immer auf die erste Instanz verlassen, sondern im Vorfeld das System auch bestmöglich sichern, sodass ggf. auftretende Sicherheitslücken nicht ausgenutzt werden können.

Gibt es regelmäßige Status-Berichte und was kostet diese sinnvolle Ergänzung zur Webseite?

Am Ende des Tages oder besser am Monatsende will ich wissen, wie der Status meines Systems ist. Wir können über diesen – zu großen Teilen vollautomatisierten Prozess – einen Report erstellen, sodass man auch immer weiß, wann was passiert ist. Wir kümmern uns um etliche Websites. Sodass wir diese natürlich auch alle im Auge behalten wollen.

Erledigt man alles händisch (Backups, Updates) einmal je Woche, was durchaus möglich ist, so ist man – je nach Internetverbindung – einige Stunden zugange.

Wir bieten all das ab 35 Euro netto je Monat je Webseite an. Wir erledigen Backups, Updates und machen Deine Webseite sicherer und schneller. Für unsere Hostingkunden bieten wir sogar alles in einem nochmal attraktiverem Paket an.

Kontaktieren Sie uns gerne – kostenfrei und unkompliziert versteht sich!

Plesk auf Debian installieren

Plesk (eine Webserver-Distribution mit Konfigurationstool für Webhosting) auf Linux besser gesagt Debian installieren? nichts leichter als das: Laden Sie den Autoinstaller von der Webseite von der Website von Odin herunter:


wget http://autoinstall.plesk.com/plesk-installer

Fügen Sie Ausführungsberechtigungen hinzu:


chmod +x plesk-installer

Wechseln sie für die Installation am besten zum root-User

su root

Starten Sie den Autoinstaller mit dem folgenden Befehl:

./plesk-installer

Weitere Informationen finden Sie in der Plesk Installationsanleitung auf der Webseite von Odin:
http://download1.parallels.com/Plesk/PP12/12.0/Doc/de-DE/online/plesk-installation-upgrade-migration-guide/

*: vom Hersteller Parallels Inc. [ehemalige SWsoft Inc.]; Im März 2015 benannte Parallels den Service Provider Geschäftsbereich in Odin um.

E-Mails an AOL können nicht gesendet werden

Dein E-Mail-Server kann keine E-Mails an *@aol.de-Adressen senden? Hier zeigen wir, wie Dein Postmaster diesen Missstand beheben kann und wie Dein Mailserver auf die Whitelist von AOL kommt.

Symptom der E-Mail-Probleme mit AOL

Auf einem unserer neueren Server trat das Problem auf, dass keine E-Mails an AOL gesendet werden konnten. Und das trat auf, obwohl der RDNS-Eintrag gesetzt war und wir auch auf keiner Blacklist standen. Die E-Mails sind einfach in der E-Mail-Warteschlange und irgendwann kommt folgende Fehlermeldung an den Absender:

Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)
I'm not going to try again; this message has been in the queue too long.

Explizites Whitelisting bei AOL zur Lösung nötig

Nach kurzer Recherche im Internet habe ich folgendes Portal bei AOL gefunden:
postmaster.aol.com

Dann ist hier ein Tool zum Prüfen der IP-Reputation:

postmaster.aol.com/ip-reputation

In unserem Fall war die Reputation gut, unter dem Ergebnis findet man jedoch den Hinweis:
„DYN:T1 errors usually occurs if you send high volume of mail. To resolve DYN:T1 errors, please apply for Whitelist.“. OK, nicht unbedingt schlüssig bei 10 Mails pro Woche an AOL, aber ich war zwischenzeitlich auch etwas ratlos.

Um sich auf die Whitelist eintragen zu lassen, auf postmaster.aol.com/whitelist-request den Bereich expandieren, Haken setzen und auf den nächsten Seiten alle Daten angeben. 10 Minuten später kommt eine E-Mail, die bestätigt werden muss, und ab diesem Moment kann man über den entsprechenden Server auch wieder E-Mails an AOL versenden.

Offene mDNS-Server schließen

Heute lag noch eine Nachricht von CERT-Bund Reports also dem Computer Emergency Response Team der Bundesverwaltung www.cert-bund.de bei mir im Postfach, die mich darauf aufmerksam gemacht haben, dass auf einem unserer Server ein offener Multicast DNS-Server läuft.

Warum ein offener mDNS-Service nachteilig sein kann

Multicast DNS (mDNS) dient der Auflösung von Hostnamen zu IP-Adressen in lokalen Netzwerken, welche nicht über einen DNS-Server verfügen. Implementierungen von mDNS sind z.B. Apple ‚Bonjour‘ oder ‚Avahi‘ bzw. ’nss-mdns‘ unter Linux/BSD. mDNS verwendet Port 5353/udp [1].

Neben der Preisgabe von Informationen über das System/Netzwerk können offen aus dem Internet erreichbare mDNS-Dienste für DDoS-Reflection/Amplification-Angriffe gegen Dritte missbraucht werden [2][3].

Im Rahmen des Shadowserver ‚Open mDNS Scanning Projects‘ werden Systeme identifiziert, welche mDNS-Anfragen aus dem Internet beantworten und dadurch für DDoS-Angriffe missbraucht werden können, sofern keine anderen Gegenmaßnahmen implementiert wurden.

CERT-Bund erhält von Shadowserver die Testergebnisse für IP-Adressen in Deutschland, um betroffene Systembetreiber benachrichtigen zu können.

Weitere Informationen zu den von Shadowserver durchgeführten Tests finden Sie unter [4].

Schließen eines mDNS-Services unter Linux

Um herauszufinden, welcher der Services hier verantwortlich ist, filtert man den eingehenden Traffic auf dem UDP-Port 5353:


# netstat -anp|grep 5353
udp     0    0    0.0.0.0:5353    0.0.0.0:*   2013/avahi-daemon:
udp     0    0:::5353    :::*    2013/avahi-daemon:

Die folgenden Befehle können den Service deaktivieren:


# service avahi-daemon stop
# chkconfig avahi-daemon off
# chkconfig --del avahi-daemon

Referenzen:
[1] Wikipedia: Multicast DNS en.wikipedia.org/wiki/Multicast_DNS
[2] US-CERT: UDP-based Amplification Attacks www.us-cert.gov/ncas/alerts/TA14-017A
[3] US-CERT: Multicast DNS (mDNS) implementations may respond to unicast queries originating outside the local link http://www.kb.cert.org/vuls/id/550620
[4] Shadowserver: Open mDNS Scanning Project mdns.shadowserver.org


7 Tipps zur erfolgreichen Multilingualen Seite mit WPML

Die Wahl eines Themes ist der erste Schritt zu einer erfolgreichen Webseite. Natürlich ist dieser Prozess ein sehr wichtiger Schritt, die Wahl eines Themes bestimmt maßgeblich wie die eigene Webseite von anderen wahrgenommen wird.Aus diesem Grund hat das WPML Team hunderte von Themes getestet und eine Datenbank mit den Ergebnissen auf ihrer Webseite veröffentlicht.

Das eigene Theme übersetzen

Bevor man das Theme mit Beiträgen füllt sollte sichergestellt werden, das alles korrekt übersetzt worden ist, um die beste Benutzererfahrung zu gewährleisten.Auf der Website von WPML sind 3 Möglichkeiten erklärt wie dies am besten zu bewerkstelligen ist. Weitere Informationen findet man hier.

Eigene Beiträge selbst übersetzen

Wer in der glücklichen Position ist mehrere Sprachen zu beherrschen, kann mit WPML sehr einfach die eigenen Beiträge übersetzen. Das Team rund um WPML hat einen Guide zur manuellen Übersetzung veröffentlich, die WPML Neulingen eine großartige Übersicht zu allen Funktionen bietet, die zur Erstellung einer multilingualen Webseite nötig sind.Diesen Guide und vieles mehr befindet sich auf der offiziellen Webseite.

WooCommerce Seiten übersetzen

Eine WooCommerce Seite zu übersetzen bedarf mehr als nur der simplen Übersetzung der Produktinformationen. WPML WooCommerce Multilingual ist eine Erweiterung zu WPML, die unter anderem lokalisierte Bestellprozesse, von der Sprache abhängige URLs, Lieferzonen und verschiedene Bezahloptionen, je nach Land, bietet.Der Hersteller dieser Erweiterung hat auf seiner Webseite ein Tutorial veröffentlich, was diesen komplizierten Prozess vereinfacht. Zu finden ist dieses Tutorial hier.

Page Builder und WPML

Page Builder sind eine exzellente Möglichkeit, schnell und effizient Beiträge zu gestalten. Sie erfordern nahezu keine Programmierkenntnisse und das beste ist, WPML bietet eine Unterstützung für die populärsten Page Builder.Eine Hilfe zur Erstellung von Webseiten mit Page Buildern befindet sich auf der WPML Webseite.

Benutzerdefinierte Taxonomien übersetzen

Eine gute Webseite hat neben den üblichen WordPress Kategorien und Tags noch eigene, benutzerdefinierte Taxonomien. Diese  zu übersetzen ist ebenfalls sehr leicht, wie dieses Tutorial zeigt.

SEO und mehrsprachige Webseiten

Selbst mit den besten Beiträgen und der schönsten Webseiten erreicht man niemanden, wenn es nicht zu finden ist. Search Engine Optimization ist schon seit Jahren ein großer Begriff im Bereich von WordPress und auch WPML bietet eine Integration für einige Plugins die einem damit helfen. Eines davon ist Yoast SEO, welches in Kombination genutzt werden kann, um mehrsprachige Beiträge bessere zu optimieren.Eine Hilfe zur Integration und Nutzung von Yoast SEO und WPML findet sich hier.

Speicherfresser per Konsole und dem Befehl du feststellen

Irgend ein Script „ballert“ den Webspace oder den Server voll? Per FTP-Programm bekommt man nu nicht die Speicherauslastung je Verzeichnis raus, daher hier die Lösung per Konsole:

du -h --max-depth=1 .

Dabei habe ich mich vorher per SSH mit dem Server und dem entsprechendem Webspace verbunden und erhalte folgend eine Auslastund der Unterverzeichnisse und kann den Übeltäter schnell identifizieren.

Aber langsam: Was ist dieser Befehl du überhaupt? Der Befehl du (steht für „Disk Usage“) ist ein Standard-Befehl aller Unix/Linux-Systeme, er wird gebraucht um Informationen darüber zu erhalten, wie viel Festplattenplatz durch Dateien und Verzeichnisse genutzt wird.
Der Befehl du hat dabei viele mögliche Parameter, für diesen speziellen Fall nutze ich:

-h für eine schicke Ausgabe der Speicherverbräuche (human readable) in KB, MB und GB.

--max-depth=1 für eine Ausgabe aller Unterordner, die maximal einen Ordner unter dem aktuellen liegen.

.Der Punkt gibt nur noch den aktuellen Ordner an, an dem ich aktuell eh schon bin. Alternativ kann hier auch der vollqualifizierte Ordnerpfad angegeben werden, zu dem ich weitere Informationen haben möchte, bspw.: var/www/vhosts/coding-pioneers.com

Ich hoffe das hilft Dir nun ein wenig weiter und du verstehst den Linux/Unix-Befehl du für den hier genannten Fall!

Doppelt hält Besser (IPv4/IPv6): Dual Stack mit neuem Server

Seit nun fast 5 Jahren testen wir unsere Webseiten auch mit IPv6, heute ist es dann nun auch soweit, dass unsere Webseite https://www.coding-pioneers.com über IPv6 endlich verfügbar ist. Ebenso können alle unsere Hosting-Kunden ebenfalls ihre Webseite im Dual Stack-Betrieb mit IPv4 und IPv6 auf unseren Servern betreiben.

Doch der Reihe nach: Was ist eigentlich dieses IPv6 und was macht das im Web?

Mit der Protokollerneuerung von IPv6 ändern sich grundsätzliche Abläufe der Netzwerkkommunikation. Die Erweiterung des Adressraums von 32 auf 128 Bit wirkt dabei zum einen der Verknappung der IPv4-Adressen entgegen. Zum anderen ermöglicht der neue Standard, alle Endgeräte in einem Netzwerk eindeutig zu adressieren. Anders als IPv4 setzt die Version 6 des Internet-Protokolls den Grundgedanken des Ende-zu-Ende-Prinzips konsequent um.


IPv6, noch Fragen?

IPv6 steht für „Internet Protocol Version 6“ und ist ein Verfahren zur Übertragung von Datenpaketen in paketvermittelnden Rechnernetzen, insbesondere dem Internet. Zusammen mit vielen weiteren Netzwerkprotokollen bildet IPv6 die Grundlage für die Kommunikation im Internet der Zukunft. Zentrale Funktionen von IPv6 sind die Adressierung von Netzwerkelementen über die IPv6-Adressen sowie die Paketweiterleitung zwischen Teilnetzen (Routing). Dazu setzt IPv6 an der Vermittlungsschicht (dem Layer 3 des OSI-Schichtenmodells) an.

Die Vergabe von IP-Adressen erfolgt über sogenannte RIRs (Regional Internet Registries), die von der IANA (Internet Assigned Numbers Authority) jeweils eigene IP-Adressbereiche zugeteilt bekommen. Die zuständige RIR für Europa, den Nahen Osten und Zentralasien ist das RIPE NCC (Réseaux IP Européens Network Coordination Centre).

IPv6 vs. IPv4

Das neue Adressformat der 6. Protokoll-Version unterscheidet sich auf den ersten Blick deutlich von dem des Vorgängers IPv4.

  • IPv4-Adresse: 62.108.36.46
  • IPv6-Adresse: 2a00:0f70:abcd:0102:0000:0000:245:0002

Während bei IPv4 32 Bit-Adressen zum Einsatz kommen, setzt der Nachfolger IPv6 auf 128 Bit-Adressen, die aufgrund der besseren Lesbarkeit hexadezimal dargestellt werden.

So wird das zentrale Anliegen des neuen IP-Standards umgesetzt: Mit 128 Bit lassen sich deutlich mehr einzigartige IP-Adressen generieren als mit 32 Bit.

  • Adressbereich von IPv4: 32 Bit = 232 Adressen ≈ 4,3 Milliarden Adressen
  • Adressbereich von IPv6: 128 Bit = 2128 Adressen ≈ 340 Sextillionen Adressen

Wer sich nun darunter kaum etwas vorstellen kann: Der Adressbereich von IPv4 mit ca. 4,3 Milliarden IPs reicht nicht einmal, um jeden Menschen auf der Welt mit einer einzigartigen Adresse zu versorgen, während sich mit dem 128 Bit-System theoretisch jedem Sandkorn der Erde gleich mehrere IP-Adressen zuweisen lassen würden. Die Einführung von IPv6 ist somit als Investition in die Zukunft zu betrachten. Durch das Internet der Dinge (engl. „Internet of Things“, oder kurz: IoT) wird die Zahl der Geräte, die eindeutig identifizierbar mit dem Internet verbunden werden müssen, in den nächsten Jahren deutlich zunehmen.

Aufbau einer IPv6-Adresse

Die 128 Bit einer IPv6-Adresse sind in acht Blöcke à 16 Bit geteilt. Durch hexadezimale Schreibweise lässt sich ein 16-Bit-Block mit vier Ziffern (0-9) bzw. Buchstaben (A-F) notieren. Als Trennzeichen dient der Doppelpunkt:

  • 2a00:0f70:abcd:0102:0000:0000:245:0002

Um eine IPv6-Adresse lesbarer zu gestalten, gibt es Verkürzungen: Führende Nullen innerhalb eines Hexadezimalblocks dürfen weggelassen werden (dezimal zu vergleichen mit 0100 ist 100). Besteht ein Block nur aus Nullen, muss die letzte Null erhalten bleiben:

  • 2a00:0f70:abcd:0102:0000:0000:245:0002
  • 2a00:f70:abcd:0102:0:0:245:0002

Einmal je IPv6-Adresse dürfen aufeinanderfolgende Null-Blöcke gestrichen werden:

  • 2a00:f70:abcd:0102:0:0:245:0002
  • 2a00:f70:abcd:0102::245:0002


Die aufeinanderfolgenden Doppelpunkte (im Beispiel oben nach dem 5. Block) zeigen diese Streichung an.

Praktisch stehen dem Internet weniger Adressen zur Verfügung, als das 128 Bit-Format vermuten lässt (ähnlich wie bei IPv4). Der Grund ist das Gestaltungsprinzip: Der neue Standard soll eine echte Ende-zu-Ende-Verbindung ermöglichen und die Übersetzung von privaten in öffentliche IP-Adressen auf Basis von NAT (Network Address Translation) überflüssig machen (wie es bei IPv4 noch der Fall ist). Grundsätzlich ließe sich auch mit IPv4 einen Ende-zu-Ende-Verbindung realisieren; da der IPv4-Adressraum jedoch zu klein ist, um jedes Gerät mit einer einzigartigen Adresse zu versorgen, wurde ein System mit getrennten Adressbereichen und der vermittelnden Komponente NAT entwickelt. Mit dem neuen Standard lässt sich jetzt jedes Endgerät, das an ein Netzwerk angeschlossen ist, über eine eigene IP logisch adressieren. IPv6-Adressen beinhalten daher zusätzlich zu dem Abschnitt zur Netzwerkadressierung (auch Netzadresse oder Routing-Präfix genannt) einen eindeutigen Interface-Identifier, der sich aus der MAC-Adresse der Netzwerkkarte des Endgeräts ergibt oder manuell erzeugt wird. Das Routing-Präfix als auch der Interface-Identifier umfassen dabei je 64 Bit einer IPv6-Adresse.

Aufbau: Routing-Präfix

Das Routing-Präfix einer IPv6-Adresse ist in der Regel in ein Netzwerkpräfix und ein Subnetzpräfix gegliedert. Dargestellt wird dies in der sogenannten CIDR-Notation (Classless Inter-Domain Routing). Dazu wird die Präfixlänge, sprich die Länge des Präfixes in Bits, mit einem Slash (/) an die Netzwerkadresse angehängt.

Die Notation 2a00:f70:abcd:0102::/64 beschreibt beispielsweise ein Subnetzwerk mit den Adressen 2a00:f70:abcd:0102:0000:0000:0000:0000:0000 bis 2a00:f70:abcd:0102:FFFF:FFFF:FFFF:FFFF:FFFF.

In der Regel bekommen Internetprovider (ISP) von der RIR /32er-Netze zugeteilt, die diese wiederum in Subnetze gliedern. An Endkunden werden entweder /48-Netze oder /56-Netze vergeben.

Das Paketformat von IPv6

Gegenüber IPv4 zeichnet sich IPv6 durch ein vereinfachtes Paketformat aus. Um die Verarbeitung der Pakete zu erleichtern, wurde für den Header eine Standardlänge von 40 Bytes (320 Bits) festgelegt. Optionale Informationen, die nur in Ausnahmefällen notwendig sind, werden in den Extension-Headers (EH) (dt.: Paketkopf-Erweiterungen) ausgelagert, die zwischen dem Header und der eigentlichen Nutzlast (Payload) eingebettet werden. So lassen sich Optionen einfügen, ohne dass der Header verändert werden muss.

Der IPv6-Paketkopf umfasst so nur noch acht Kopffelder, wohingehend bei IPv4 noch dreizehn Felder zum Einsatz kommen.

Jedes Feld im IPv6-Header enthält bestimmte Informationen, die für die Paketvermittlung über IP-Netze benötigt werden:

FeldErklärung
Version Beinhaltet die Version des IP-Protokolls, nach der das IP-Paket erstellt wurde (4 Bit)
Traffic Class Dient der Prioritätsvergabe (8 Bit)
Flow Label Pakete mit demselben Flow Label werden gleich behandelt (20 Bit)
Payload Length Gibt die Länge des Paketinhaltes (ohne Header) inklusive Erweiterung an (16 Bit)
Next Header Gibt das übergeordnete Transport-Layer-Protokoll an (8 Bit)
Hop Limit Gibt die maximale Anzahl an Zwischenschritten (Routern) an, die ein Paket passieren darf, bis es verfällt (8 Bit), und ersetzt damit das TTL aus IPv4
Source-IP-Address Beinhaltet die Absender-Adresse (128 Bit)
Destination-IP-Address Beinhaltet die Adresse des Empfängers (128 Bit)

Durch die Einführung der Extension-Header lassen sich optionale Informationen einfacher implementieren als bei IPv4. Auf dem Zustellungspfad eines Pakets mit IPv6-Extension-Header werden diese nicht vom Router geprüft noch verarbeitet, und so werden diese zumeist erst am Ziel ausgelesen. Somit ergibt sich eine deutliche Verbesserung der Routing-Performance von IPv6 zu IPv4, da diese optionalen Daten nicht mehr untersucht werden müssen.

Die Extension Header können unter anderem folgendes enthalten:

  • Knoten-zu-Knoten-Optionen
  • Zieloptionen
  • Routing-Optionen
  • Optionen zur Fragmentierung
  • Authentifikation und Verschlüsselung

Funktionalitäten von IPv6

Ein Großteil der Internetnutzer bringt IPv6 vor allem mit der Erweiterung des Adressraums in Verbindung. Der neue Standard bietet mehr: Weitere Funktionen, mit denen sich Einschränkungen von IPv4 überwinden lassen. Dazu gehört vor allem die konsequente Umsetzung des Ende-zu-Ende-Prinzips, die den Umweg über NAT überflüssig macht. Eine Implementierung von Sicherheitsprotokollen wie IPsec ist somit deutlich einfacher.

Darüber hinaus ermöglicht IPv6 die automatische Adresskonfiguration mit dem sog. Neighbor Discovery als auch die Vergabe mehrerer eindeutiger IPv6-Adressen pro Host mit unterschiedlichen Geltungsbereichen, um verschiedene Netzwerk-Topologien abzubilden. Neben der optimierten Adresszuordnung sorgen die Vereinfachung des Paketkopfes und die Auslagerung von optionalen Informationen für die Paketvermittlung in Extension-Headers für ein schnelleres Routing.

Mit QoS (Quality of Service) verfügt IPv6 über einen integrierten Mechanismus zur Sicherung der Dienstgüte, der für eine Priorisierung dringlicher Pakete sorgt und das Datenpaket-Handling effizienter gestaltet. Dazu wurden die Felder „Traffic Class“ und „Flow Label“ direkt auf die QoS-Methodik zugeschnitten.

Von HTTP auf HTTPS via Apache mittels .htaccess oder nginx-Webserver-Konfiguration weiterleiten

Eine verschlüsselte Verbindung über SSL (bzw. TLS) ist immer eine gute Idee um sensible Daten gegen Dritte zu schützen. Aber was bringt es wenn das SSL-Zertifikat im Webhosting-Paket installiert und die Verschlüsselung aktiviert ist, aber die Webseite trotzdem noch per HTTP erreichbar ist? Sämtlicher Verkehr über HTTP muss auf die HTTPS-Verbindung weitergeleitet werden.

Voraussetzung: Die Apache-Erweiterung mod_rewrite ist aktiviert und Webserver bereits via HTTP und HTTPS erreichbar. Beim Webserver nginx muss nur die Konfiguration veränderbar sein.

HTTP auf HTTPS weiterleiten via .htaccess

Die .htaccess-Datei liegt in der Regel im root-Verzeichnis der Webseite. In dieser Konfiguration werden sämtliche Verbindungen, die per HTTP auf den Server kommen, auf HTTPS weitergeleitet. Für den Endnutzer bleibt dieser Vorgang weitestgehend unsichtbar.

RewriteEngine On<br>
RewriteCond %{SERVER_PORT} !^443$<br>
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]<br>

Zunächst (Zeile 1) wird mod_rewrite aktiviert (das ist nicht erforderlich, wenn ohnehin schon getan). In Zeile 2 wird überprüft (in der Rewirte Condition) ob die Anfrage an den Server über den Port 443 (also den Standard-Port von HTTPS) kam. Wenn dies nicht der Fall ist, führt er die Regel aus Zeile 3 aus. Diese leitet sämtliche Anfragen via Statuscode 301 (permanent redirect) auf HTTPS um.

Das ist eine von verschiedenen Möglichkeiten um die Weiterleitung von HTTP auf HTTPS zu realisieren, eine andere Möglichkeit ist:

RewriteEngine On<br>
RewriteCond %{HTTPS} off<br>
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]<br>

Das Ergebnis ist das gleiche, nur der Weg ist ein minimal anderer: Es wird explizit geprüft ob eine HTTPS-Verbindung genutzt wird, ist dies nicht der Fall, so wird weitergeleitet.

HTTP auf HTTPS durch nginx-Konfiguration

Nginx (gesprochen „engine x“) ist ein alternativer Webserver, der im Vergleich zum Marktführer Apache in der Regel schneller ist. Daher hier noch die Konfiguration, wie das gleiche über die Konfiguration des nginx-Server (bzw. im Plesk-Konfigurationsbereich) gelöst wurde:

if ($scheme !~* ^https ){<br>
    rewrite ^ https://www.coding-pioneers.com$request_uri? permanent;<br>
}<br>

Warum den Statuscode 301 und nicht 302?

Im Standard wird in der RewriteRule mit R (Redirect) die Weiterleitung spezifiziert. Diese liefert (wenn man keinen abweichenden Status angibt) den HTTP-Statuscode 302 (found), also eine temporäre Weiterleitung zurück. Es ist zu empfehlen den Statuscode 301 (permanent redirect) zu nutzen, um auch im Bereich SEO keine Nachteile zu erhalten.

Umlaut-Domain per mod_rewrite umleiten

Um im Netz keinen Dublicate Content zu erzeugen, leiten wir auf unseren Apache-Webservern mittels mod_rewrite die verschiedenen Domains immer auf eine URL zusammen.

Unter Apache mit mod_rewrite funktioniert das wie folgt:

RewriteCond %{HTTP_HOST} ^(www\.)?domain1\.de$ [NC,OR]<br>
RewriteCond %{HTTP_HOST} ^(www\.)?domain2\.de$ [NC,OR]<br>
RewriteCond %{HTTP_HOST} ^(www\.)?domain3\.de$ [NC,OR]<br>
RewriteCond %{HTTP_HOST} ^domain0\.de$ [NC]<br>
RewriteRule (.*) http://www.domain0.de/$1 [R=301,L]

Dabei werden alle Domains auf domain0.de weitergeleitet.

Bei den Rewrite Conditions kännen sog. Flags angehängt werden, die in eckigen Klammern geschrieben werden:

’nocase|NC‘ (no case)

Dieses Pattern macht den Test case-insensitive also er differenziert nicht mehr zwischen Groß- und Kleinschreibung: ‚A-Z‘ und ‚a-z‘ werden gleich behandeltd im Test-String und dem Cond-Pattern.

‚ornext|OR‘ (or next condition)

Dieses Flag kann genutzt werden, um die Regeln mit einem oder zu kombinieren. In der Regel würden diese mit einem AND verknüpft

Als Sonderfall haben wir nun noch Domains mit Umlauten, die weitergeleitet werden sollten. Im Web findet man häufig Referenzen, dass die Umlaute direkt eingegeben werden könnten, bei uns hat das nicht funktioniert. Es musste nicht die native Form des IDNs (sog. U-Label), sondern die ASCII-Darstellung (sog. ACE-Form) genutzt werden.

Beispiel:
IDN-Form: müll.de
ACE-String: xn--mll-hoa.de (Puny-Code)

Die Konvertierung erfolgt dabei nach dem sog. IDNA-Standard (RFCs 5890 bis 5894), mit Unterstützung für Unicode 5.2 und mit Hilfe des IDNA Compatibility Processing im „nontransitional“ Modus aus dem Unicode Technical Standard #46.