Schlagwort-Archive: Webserver

IPV6-Netze Praxis-Erfahrungen

Einleitung IPV6 Praxis

Ich konnte die IPV6-Funktionalität mit den Providern Selfhost, SIXXS, T-Mobile, Telekom und verschiedenen Routern (AVM Fritz.Box 7390, 7490 und 6840 LTE) unter Linux testen. Über meine Erfahrungen berichtet dieser Text. Bei den AVM-Routern habe ich zwei Probleme festgestellt und an den Support weiter gemeldet.

Fritz.Box 7390 mit der Deutschen Telekom (Festnetz)

Hier sieht es schon gut aus. Der Provider vergibt bereits dynamische IPV6-Adressen, die auch den Geräten korrekt zugewiesen werden. Portfreigaben für IPV6 sind möglich und funktionieren. Auch mit dem SIXX-Tunnel ist alles zufriedenstellend. Allerdings hat man dann immer ein statisches Präfix, auch wenn Ubuntu 13.10 per Privacy-Extensions den Identifier zyklisch ändert. Weil der Präfix bei jedem Internetzugriff sichtbar ist, habe ich mich gegen diese Lösung entschieden. Eine dynamische Weitergabe der IPV6-Adressen an Selfhost hat nicht funktioniert. Der Eintrag der statischen IPV6-SIXXS-Tunnel-Adresse ist jedoch möglich. Hier benötigt man dann theoretisch keinen dynamischen Account mehr für den Fall dass die Domain nur per IPV6 erreichbar sein soll.

Fritz.Box 7490 mit LTE-Speedstick III (3) und T-Mobile

Wie beim 6840 (oben) erfolgt keine Vergabe von IPV6-Adressen durch T-Mobile. Eine Einwahl in den SIXXS-Tunnel funktioniert. Wichtig ist, dass man dafür sorgen muss, dass man eine öffentliche Adresse bekommt. Dies kann man per Ändern der APN in internet.t-d1.de versuchen. Leider hat es nicht immer funktioniert. Für solche Fälle besteht dann die Möglichkeit den SIXXS-Tunnel vom Hartbeat- auf das AYIYA-Verfahren umzustellen, und per AICCU-Client anzubinden.

Hier gibt es leider mit der 7490 noch Probleme (Stand 8.3.14 FRITZ!Box 7490 FRITZ!OS 6.05 (113.06.05)). Eine Korrekte Vergabe der IPV6-Adressen auf die Rechner erfolgt leider nicht. Zu diesem Problem bin ich mit dem AVM-Support im Gespräch. Eine Änderung der Firmware von 6.03 nach 6.05 hat keine Verbesserung ergeben.

Fritz.Box 6840 LTE mit T-Mobile

Eine Vergabe von IPV6-Adressen hat generell nicht funktioniert. Per SIXXS-Tunnel erfolge dann eine Anbindung über Anpassung der APN zu einer öffentlichen IP. Es wurde den Geräten automatisch eine vollständigen Adresse zugewiesen. Leider kann man in der 6840 keine IPV6-Portfreigabe durchführen. Der Reiter in der Web-Oberfläche fehlt (noch, Stand 8.3.14 Version FRITZ!Box 6840 LTE FRITZ!OS 6.03 (105.06.03)).  Eine Korrektur wurde für die nächste Zeit vom AVM-Support zugesagt. Es wurde auf den komplexen Prozess der Firmwareerstellung hingewiesen.

 

 

 

 

 

 

 

 

BUFFALO Linkstation Webserver (LIGHTTPD) mit SSL/HTTPS-Umleitung und Verzeichnisschutz

Ziel ist der Schutz eines Webseiten-Ordners auf der BUFFALO Linkstation durch SSL und Verzeichnisschutz (Umleitung von http nach https). Praktisch habe ich einen 1und1 Account per DYNDNS und Fritz.Box dynamisch auf die LSDUO aufgeschaltet. Die eigentliche Webseite habe ich dann noch per CNAME Eintrag auf das DYNDNS-Account weitergeleitet. Dies funktioniert selbst mit HTTPS.

1. SSH Zugriff via PUTTY

1.1. Möglichkeiten

Die Script-Alternative ist einfach, aber hat den Nachteil, dass, wenn der Webserver wegen Fehlern stoppt, nicht mehr per SSH darauf zugegriffen werden kann. Man muss die LSDUO erst per Werkseinstellung neu initialisieren. Dieser Zugang eignet sich daher eher für kleinere Änderungen an der Konfiguration des Webservers (Lighttpd). Voraussetzung ist der eingeschaltete Webserver und das Kennen des angegebenen Ordners.

1.2. Script von http://buffalo.nas-central.org/wiki/Category:LS-WXL

<?php
$file = ‚../../../../etc/pam.d/sshd‘;
$fh=fopen($file, ‚w‘) or die(„can’t open file“);
$stringData = „account required pam_unix.so\n“;
fwrite($fh, $stringData);
$stringData = „session required pam_unix.so\n“;
fwrite($fh, $stringData);
$stringData = „auth required pam_permit.so\n“;
fwrite($fh, $stringData);
fclose($fh);
?>

1.3. Offene Firmware hier aus dem Forum von Shonk

Die andere Alternative ist, die Firmware von Shonk zu flashen. Damit entfällt das jeweilige Setzen auf Werkseinstellungen.

hxttp://www.mediafire.com/file/25zmjmf50mh/ls_series-131-mod1.rar Wenn man eine neuere Firmware als die 1.31 verwendet muss man die Updater-Konfig anpassen (Debug-Modus):

htxtp://www.discountnetz.com/buffalo-linkstation/software/76-wie-mache-ich-aus-einer-linkstation-live-eine-linkstation-pro?start=2

2. Zertifikat

Zum Beschaffen des Zertifikates habe ich mich grob an die Anleitung in [url]http://www.asconix.com/howtos/debian/lighttpd-ssl-howto[/url] gehalten. Ich habe den Key per Linux auf einem separaten Rechner mit OPENSSL erstellt. Ca-Cert kann ich nicht empfehlen, da es in den aktuellen Browsern nicht unterstützt wird (Nachinstallation notwendig). Der startssl-Key (bekanntester kostenloser Anbieter) mit der Länge von 4000 Byte funktionierte bei mir nicht auf der LSDUO. Zur 2 KByte-Version kann ich nichts sagen. Man hat bei startssl nur eine einzige Möglichkeit ein kostenloses Zertifikat zu erwerben!

Quellen:

hsttp://www.startssl.com

hsttp://de.wikipedia.org/wiki/StartCom

Für das SSL-Zertifikat habe ich die beiden erhaltenen Dateien xyz.de.key und xyz.de.crt in die Verzeichnise ssl.key und ssl.crt abgelegt unter /etc/ abgelegt (mittels Befehle mkdir und cp). Die Zertifikatdateien habe ich in den Web-Ordner abgelegt und dann per Putty an das Ziel kopiert.

Privater Schlüssel: /etc/ssl.key/example.com.key

Zertifikat: /etc/ssl.crt/example.com.crt

Für das Vereinen:

cat /etc/ssl.key/example.com.key /etc/ssl.crt/example.com.crt >> /etc/lighttpd/example.com.pem

Das Verwenden anderer Verzeichnisse führt zum Stoppen des Servers. Zu beachten sind die Rechte- und Gruppenzuweisungen.

Quelle: http://www.ssl-sicherheit.info/ssl-zert … httpd.html

3. Bearbeiten der LIGHTTPD-Konfiguartion

Mit

vi /etc/lighttpd/lighttpd.conf

wird die Konfiguration bearbeitet.

Am Anfang müssen drei Module durch Entfernen der „#“ aktiviert werden (rewrite, redirect und auth):

server.modules = (
„mod_rewrite“,
„mod_redirect“,
„mod_alias“,
„mod_access“,
# „mod_cml“,
# „mod_trigger_b4_dl“,
„mod_auth“,
# „mod_status“,
# „mod_setenv“,
# „mod_proxy“,
# „mod_simple_vhost“,
# „mod_evhost“,
# „mod_userdir“,
# „mod_compress“,
# „mod_ssi“,
# „mod_usertrack“,
# „mod_expire“,
# „mod_secdownload“,
# „mod_rrdtool“,
# „mod_webdav“,
„mod_accesslog“
)

Am Ende wird folgender Code eingefügt:

$SERVER[„socket“] == „:81“ {
$HTTP[„host“] =~ „(.*)“ {
url.redirect = ( „^/(.*)“ => „https://%1/$1“ )
}
}

$SERVER[„socket“] == „:444“ {
ssl.engine = „enable“
ssl.pemfile = „/etc/lighttpd/xyz.de.pem“
}

auth.debug = 2
auth.backend = „plain“
auth.backend.plain.userfile = „/mnt/array1/WWW/password.txt“

auth.require = ( „“ =>
(
„method“ => „basic“,
„realm“ => „Password protected area“,
„require“ => „user=xxxx“
)
)

In der Zeile auth.require kann man zwischen den „“ den Pfad des zu schützenden Verzeichnisses angeben. Wenn hier nichts hinterlegt ist, bleibt der gesamte Ordner gesperrt.

Es ist auch möglich den Lighty so zu konfigurieren, dass er nur auf https://… reagiert (Quellen).

In der passwort.txt wird der User:Key „xy:12345“ angegeben. Die Rechte- und Gruppenzuweisungen sind zu beachten.

Port 81 ist zum Erreichen der ungesicherten Version aktiv. Auf Port 80 hört das WEBIF.
Normalerweise läuft https auf Port 443. Da hat aber die LSDUO schon den APACHE mit dem WEBIF gesichert. Somit musste ich den Port 444 verwenden.

Jetzt kann Putty per exit geschlossen werden. Die LSDUO muss jetzt per WEBIF System/Wartung/Neustart neu initialisiert werden. Leider gibt es aus meiner Erfahrung (viele Versuche) keine Möglichkeit den LIGHTTPD einzeln zu re-starten.

Quellen:
http://redmine.lighttpd.net/wiki/lightt … ttpToHttps
http://www.root-on-fire.com/2010/06/17/ … eichnisse/

4. Portfreischaltung in der Fritz.Box o. a. Routern

In der Fritz Box müssen jetzt nur noch die folgenden Ports umgeleitet werden:

TCP 80 LS-WXL188 81

TCP 443 LS-WXL188 444

Damit sollte alles funktionieren.

Quelle des eigenen Textes: httxp://forum.discountnetz.com/buffalo-linkstation-duo/webserver-lighttps-mit-ssl-https-umleitung-und-verzeichnisschutz-t682.html

Buffalo Logo
Buffalo Logo

Apache mod_expires Konfiguration für ein schnelles Joomla auf dem QNAP Webserver

Einleitung mod_expires

Um den Browsercache beim Clienten für einen schnelleren Seitenaufbau benutzen zu können, benötigt man das Apache-Webserver-Modul mod_expires. Es werden möglichst viele unveränderte Dateien beim Nutzer aus dem Browsercache geladen. Dadurch verringert sich der Traffic und die Ladezeit deutlich.

Die Datei apache.conf

Um dieses Modul in die Apache-Konfiguration laden zu können, muss man den richtigen Speicherort der Apache.conf finden. Ich habe ihn durch ausprobieren suchen müssen. Beim 259er ist er in:

/mnt/HDA_ROOT/.config/apache/apache.conf

Mit dem VI-Editor kann man das Modul durch folgenden Text einfügen:

LoadModule expires_module /mnt/ext/opt/apache/modules/mod_expires.so

Nach einem Neustart des Apache kann man das Vorhandensein in Joomla-Systeminformation-php-Information bzw. z.B. mit Google-Pagespeed prüfen.

/etc/init.d/./Qthttpd.sh restart

Anpassung der Datei .htaccess

In der .htaccess kann dann mit dem folgenden Script die Cache-Dauer gesteuert werden. Die .htaccess muss in alle betreffenden Verzeichnise abgelegt werde. Mit dem Google-Tool habe ich eine optimale Einstellung der betreffenden Dateien finden können. Damit rutschte der Speed-Index meiner Seite deutlich nach oben.

<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/jpg "access plus 8 day"
ExpiresByType image/gif "access plus 8 day"
ExpiresByType image/jpeg "access plus 8 day"
ExpiresByType text/css "access plus 8 day"
ExpiresByType image/png "access plus 8 day"
ExpiresByType application/x-javascript "access plus 8 day"
#ExpiresDefault "access plus 8 day"
</IfModule> 

Unterstützung durch JCH-Optimize

JCH Optimize hilft mit etlichen Optionen die Geschwindigkeit deutlich zu erhöhen. Allerdings funktioniert Dies nur mit Probieren. Außerdem muss man beim Austesten ständig den Joomla-Cache löschen und den Browser-Verlauf leeren, damit sich die Auswirkungen im Chrome-Browser mit PageSpeed messen lassen. Ich habe folgende Einstellung setzen können:

Combine CSS Files Ja
Replace @import Ja
Combine JavaScript Files Ja
GZip JavaScript and CSS Ja
Minify CSS Ja
Minify javascript Ja
Minify HTML Nein
Defer javascript Ja

Umbau der Bahnbauwerke-Seite

Hallo Bahnbauwerke – Freunde,

derzeit wird die Bahnbauwerke-Seite überarbeitet. Die bisherigen Fotos werden schrittweise neu eingestellt. Bitte habt etwas Geduld und Verständnis. Vielen Dank

05.06.13 Nach umfangreichen Tests habe ich mich für einer Hardware-Erweiterung entschieden. Diese ist bedeutend leistungsfähiger als die vorherige Lösung. Im Moment bin ich noch bei der Fein-Anpassung des Systems bevor es mit der Migration der bisherigen Daten weitergeht. Konkret teste ich Googles MOD_PAGESPEED für den Indianer (Apache-Webserver) und den APC-Cache für PHP. Diese beiden Module konnte ich vorher auf dem alten Server leider nicht aktivieren. Die Laufzeiten prüfe ich mit Seitenreport.de und PageSpeed Insight.

08.06.13

Die Tests sind weitgehend abgeschlossen. Damit kann ich den nächsten Schritt (Datenmigration) fortsetzen.

10.06.13

Derzeit teste ich noch bezüglich Geschwindigkeit und Sicherheit mit zwei Systemen.

15.06.13

Die Tests sind abgeschlossen.