PHPGangsta - Der praktische PHP Blog

PHP Blog von PHPGangsta


Archive for the ‘nginx’ tag

SSLv3: Uralt, bröckelig, abschalten!

with 6 comments

[EDIT] Tja, da schreibt man gerade drüber und ein paar Minuten später wird die Lücke veröffentlicht: Poodle . Details im Google Blog. Das Problem liegt im SSLv3 Protokoll selbst, es wird keine Patches geben, es muss ausgeschaltet werden. Eigentlich wäre nur uralt-Software wie der IE6 unter WindowsXP betroffen, aber durch Downgrade-Attacken die bei TLS möglich sind, sind alle betroffen und können auf das schwache SSLv3 downgegraded werden wenn es denn auf Server+Client unterstützt wird. Also abschalten!

Seit 2 Tagen gibt es Gerüchte über eine kritische Lücke in SSLv3. Aktuell (Mitternacht) ist noch nichts publik geworden außer ein eventuell interessanter Patch von Microsoft, und eine Falschmeldung eines OpenBSD-Patches, der in Wirklichkeit schon einige Monate alt ist.

Sicher ist dass SSLv3 18 Jahr alt ist, und vor 15 Jahren durch TLSv1.0 abgelöst wurde. Bei mail.de haben wir SSLv3 bereits vor einigen Monaten deaktiviert auf den Webseiten da kaum ein Client dieses alte Protokoll benutzte außer der IE6 auf WindowsXP Systemen. Da wir den IE6 eh schon lange nicht mehr unterstützen war es sehr einfach, SSLv3 abzuschalten.

Für die anderen Protokolle wie IMAP, POP3 und SMTP haben wir SSLv3 allerdings noch aktiviert gelassen da es noch diverse E-Mail-Clients gibt die TLS >1.0 noch nicht beherrschen. Auch einige ältere Smartphones beherrschen noch kein TLS1.0 oder neuer, sodass es Sinn machte es noch aktiviert zu lassen, denn es gab auch (noch) keine bekannten Angriffsvektoren.

Weiterlesen »

Written by Michael Kliewe

Oktober 15th, 2014 at 12:18 am

SPDY Support in den Alexa Top 10k

with 3 comments

SPDYEin Großteil der Browser unterstützt es, und fast alle Webserver ebenso: SPDY, der heiße Kandidat für das neue HTTP 2.0 Protokoll. Nach den ersten Tests der SPDY-Implementation in nginx im Juni 2012 habe ich mich gefragt wie verbreitet die Nutzung mittlerweile ist.

Dazu habe ich die Alexa Top 1 Million Liste als CSV heruntergeladen und die Top 10.000 mit Hilfe des Kommandozeilen-Tools spdycat untersucht. Außerdem kann man auf meiner kleine Unterseite eine URL eingeben und sich das Ergebnis anzeigen lassen. Probiert es einfach mal aus:

http://spdyservertest.phpgangsta.de

Weiterlesen »

Written by Michael Kliewe

Januar 24th, 2014 at 3:43 pm

SPDY Beta-Patch für nginx verfügbar: Ein erster Test

with 12 comments

Endlich ist es soweit, mein favorisierter Webserver nginx erhält SPDY Support. Für Apache gibt es schon seit längerem ein SPDY-Modul das seit einigen Wochen als stabil gekennzeichnet ist. SPDY wird wahrscheinlich das neue HTTP 2.0, von Google entwickelt bietet es einige neue Features die das Web schneller und sicherer machen sollen. Unter anderem wird alles komprimiert (auch die Header), SSL ist zwingend vorgeschrieben und mittels Multiplexing können alle Resourcen über eine TCP-Verbindung geladen werden, und noch einiges mehr. Wer mehr über SPDY wissen will schaue sich am besten das Video von Google über SPDY an, es ist sehr empfehlenswert!

Weiterlesen »

Written by Michael Kliewe

Juni 16th, 2012 at 10:08 am

Posted in Server-Software

Tagged with , , , , , ,

Letzte Aktion in 2011: Server via IPv6 verfügbar machen

with 11 comments

So, damit es nicht heißt mein Blog wäre in 2011 nicht via IPv6 erreichbar gewesen ist meine letzte Aktion dieses Jahr meinen Webserver via IPv6 erreichbar zu machen. Da mein Hoster nun auch endlich IPv6 für virtuelle Server anbietet war das ziemlich einfach: Man mußte im Kundenbereich die IPv6 Konnektivität aktivieren und 10 Minuten warten. Und schon war der Server via IPv6 erreichbar:

$ ifconfig venet0 | grep inet6
inet6-Adresse: 2a01:238:42b6:2a00:e661:84eb:4a08:ee54/128 Gültigkeitsbereich:Global
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine

Dann mußte ich gerade noch den nginx neu kompilieren für die IPv6 Funktionalität (wurde eh mal wieder Zeit, war noch eine alte 0.8.53 Version), sodass ich nun die aktuelle 1.0.11 verwende:

Weiterlesen »

Written by Michael Kliewe

Dezember 31st, 2011 at 12:13 pm

Client-IP Problem bei Reverse-Proxy-Betrieb

without comments

In einem meiner letzten Artikel schrieb ich ja bereits über Reverse-Proxies. Der Reverse-Proxy nimmt die Verbindung vom Client (Browser) entgegen, dann kann er entweder selbst den Request bedienen (statische Dateien von der lokalen Platte oder aus dem Cache), oder er verbindet sich zu einem der Backend-Webserver, ruft dort die geforderte Datei ab, und sendet sie dem Client zurück.

Ein Problem entsteht nun auf dem Backend-Webserver: Alle Requests kommen vom Reverse-Proxy. Wenn nun in den PHP-Scripten die Client-IP-Adresse verwendet wird, steht darin die IP des Reverse-Proxies.

Betroffen ist in diesem Fall die PHP-Variable  $_SERVER[‚REMOTE_ADDR‘]  als auch das Apache-Log, denn dort taucht auch immer nur die IP des Reverse-Proxy auf.

xforwardedfor3

127.0.0.1 - - [03/Oct/2009:10:45:24 +0200] "GET /phpinfo.php HTTP/1.0" 200 7800 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) FirePHP/0.3"

127.0.0.1 deshalb, da ich direkt auf der Linux-Maschine sowohl den nginx als auch den Apache laufen habe.

Da gibt es natürlich Lösungen. Zuerst einmal müssen wir die Client-IP irgendwie an den Backend-Webserver übergeben. Dafür gibt es den Header „X_FORWARDED_FOR“, da wird der nginx die Client-IP reinschreiben.

Im nginx muss dann folgendes gesetzt werden:

location / {
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect off;
........

Ein phpinfo() liefert dann die korrekte Client-IP in X_FORWARDED_FOR (34 ist der Server, 33 der Client):

xforwardedfor4

Nun installieren wir noch ein Apache-Modul. Dieses Modul sorgt dafür, dass in die Variable $_SERVER[‚REMOTE_ADDR‘]  der Wert aus X-FORWARDED-FOR geschreiben wird, damit wir keine PHP-Scripte anpassen müssen. Außerdem sorgt dieses Modul dafür, dass im Apache-Log dieser Wert auftaucht.

Das Module, das es für diese Aufgabe gibt, lautet „mod_rpaf“. Einfach danach googlen, downloaden und in der Apache-Konfiguration laden. Oder unter Linux:

sudo apt-get install libapache2-mod-rpaf

Noch kurz konfigurieren /etc/apache2/mods-available/rpaf.conf:

<IfModule mod_rpaf.c>
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1
</IfModule>

Das Ergebnis sieht dann so aus:

xforwardedfor2

192.168.1.33 - - [03/Oct/2009:10:47:23 +0200] "GET /phpinfo.php HTTP/1.0" 200 7808 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) FirePHP/0.3"

Möchte man das Modul nicht installieren, muß man überall in seinen PHP-Scripten die Variable $_SERVER[‚X_FORWARDED_FOR‘] statt $_SERVER[‚REMOTE_ADDR‘] nutzen, und das Apache-Log anpassen:

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

Damit hätten wir das Problem auch gelöst, überall steht nun die Client-IP zur Verfügung, die Anwendungen und Logs laufen wieder korrekt.

Written by Michael Kliewe

Oktober 7th, 2009 at 8:35 am