Archiv

Archiv für die Kategorie ‘Apache – PHP’

Apache SSL Einstellungen für SSLLabs A-Rating

12. Mai 2019 Keine Kommentare

Mithilfe des SSLLabs Servertests ist es möglich den eigenen Webserver hinsichtlich TLS Einstellungen stetig zu überprüfen.

Debian 9 wird aktuell mit Apache 2.4.25 ausgeliefert, der leider noch keinen Support für das neuste (und sicherste) TLS 1.3 mitbringt.
Debian 10 wird mit Apache 2.4.38 / OpenSSL 1.1.1 bestückt und unterstützt somit TLS 1.3.
Dennoch ist es möglich auch mit TLS 1.2 ein A-Rating zu erhalten, indem man lediglich die besten Ciphers anbietet und alle anderen TLS Versionen deaktiviert.

Folgende Settings in der Datei /etc/apache2/mods-enabled/ssl.conf ermöglichen dies:

SSLHonorCipherOrder On
SSLCipherSuite TLSv1.3:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384
SSLCompression off
SSLProtocol +all -SSLv3 -TLSv1 -TLSv1.1

Diese Einstellungen gewährleisten auch dass TLS 1.3 sofort unterstützt wird, sobald der Server dieses Protokoll kennt. Alle weiteren Einstellungen können auf dem Standardwert belassen werden.

Achtung: Durch den Wegfall von TLSv1 und TLSv1.1 werden sehr alte OS/Browser Kombinationen nicht mehr unterstützt. Ein Beispiel hierfür wäre IE 8 auf Windows XP. Wer diese Clients weiterhin unterstützen möchte, findet auf Applied Crypto Hardening ein passendes Konfigurationsbeispiel.

Aktuelle Clientsysteme verwenden die beiden bis dato als sicher geltenden Ciphers ECDHE-RSA-AES256-GCM-SHA384 und ECDHE-RSA-AES128-GCM-SHA256, während auch älteren Clients der Verbindungsaufbau über ECDHE-RSA-AES256-SHA384 (CBC) ermöglicht wird.
Diese CBC Cipher gilt zwar als problematisch, wird aber nur von alten Clients verwendet und beherrscht dennoch Forward Secrecy. Im SMTP Bereich spielt diese Cipher ebenfalls noch eine bedeutende Rolle und ist z.B. seitens Outlook.com die Standard-Cipher für ausgehende E-Mails.

KategorienApache - PHP, Debian

hahaha Webcrawler legt den Apachen lahm / DDoS

19. Januar 2011 Keine Kommentare

Vor ein paar Tagen war ich auf einem Rechner zu Gast, der sofort nach dem Start des Apache2 so viele Prozesse öffnete bis dieser in die Knie geht. Das error.log Dokument zeigt dies auch an ...server reached MaxClients setting...

Das access.log File zeigt zu diesem Zeitpunkt folgende Einträge an:

62.226.71.77 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
67.230.15.201 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
82.228.255.82 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
67.230.15.201 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
67.230.15.201 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
85.247.44.177 - - [01/Dec/2010:19:13:10 +0100] "GET /apache2-default/ HTTP/1.1" 200 44 "-" "hahaha"
83.119.147.38 - - [01/Dec/2010:19:13:10 +0100] "GET /apache2-default/ HTTP/1.1" 200 44 "-" "hahaha"
62.226.71.77 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
83.119.147.38 - - [01/Dec/2010:19:13:10 +0100] "GET /apache2-default/ HTTP/1.1" 200 44 "-" "hahaha"
84.24.148.207 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
81.185.240.110 - - [01/Dec/2010:19:13:10 +0100] "GET /apache2-default/ HTTP/1.1" 200 44 "-" "hahaha"
77.180.6.60 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
62.226.71.77 - - [01/Dec/2010:19:13:10 +0100] "GET /apache2-default/ HTTP/1.1" 200 44 "-" "hahaha"
86.20.52.230 - - [01/Dec/2010:19:13:10 +0100] "GET /apache2-default/ HTTP/1.1" 200 44 "-" "hahaha"
87.147.56.201 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
82.168.48.203 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
84.29.49.141 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
82.168.211.13 - - [01/Dec/2010:19:13:10 +0100] "GET /apache2-default/ HTTP/1.1" 200 44 "-" "hahaha"
207.161.34.194 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
77.180.6.60 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
87.94.124.6 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
212.99.78.126 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
83.119.147.38 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
83.119.147.38 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
87.208.63.191 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
77.180.6.60 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"
212.99.78.126 - - [01/Dec/2010:19:13:10 +0100] "GET / HTTP/1.1" 302 303 "-" "hahaha"

Es ist ziemlich leicht zu erkennen was hier passiert. Verschiedene IP Adressen rufen mittels des User Agents „hahaha“ die Webseite so oft auf, bis dem Apache2 bzw. dem Server an sich die Puste ausgeht. Man könnte hier von einer Distributed Denial of Service (DDoS) Attacke sprechen.
Der Angriff erfolgt dabei von so vielen IP Adressen, dass die Rechner die diese Anfragen absenden vermutlich nicht einmal was davon mitbekommen. Am Webserver der Domain wo alle diese Anfragen zusammenlaufen ergibt dies pro Sekunde mehrere hundert Abfragen und den damit verbundenen Ausfall.

Da die IP Adressen sehr unterschiedlich waren, war der kleinste gemeinsame Nenner dieser Anfragen der User Agent „hahaha“. Dieser wurde mit folgenden beiden Zeilen in der vhost.conf (oder auch im .htaccess File) geblockt:

# Block User-Agent Apache2
SetEnvIfNoCase User-Agent "hahaha" bad_bot
Deny from env=bad_bot

Danach erfolgten keine Angriffe mehr. Es scheint als könnte der Angreifer bei seinen Bots nur das Ziel steuern, nicht aber den Namen. Ein Glück…

KategorienApache - PHP

[error] Unable to configure RSA server private key

10. September 2010 Keine Kommentare

Heute zeigte mir ein Apache2 Webserver mit geplantem SSL Support folgende Meldung an:


[Fri Sep 10 12:29:02 2010] [error] Unable to configure RSA server private key
[Fri Sep 10 12:29:02 2010] [error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

Das hat zumeist den Grund, dass Key und SSL Zertifikat nicht zusammenpassen. Um zu prüfen ob Key (.key), Zertifikat (.crt) und Zertifikatrequest (.csr) genau zusammenpassen kann man folgende Befehle ausführen:

openssl x509 -noout -modulus -in dateiname.crt | openssl md5
openssl rsa -noout -modulus -in dateiname.key | openssl md5
openssl req -noout -modulus -in dateiname.csr | openssl md5

Nur wenn alle 3 md5 Hashes genau zusammenpassen ist alles richtig gelaufen. In meinem Fall wurde die .csr Datei falsch übertragen und es kam ein Zertifikat dabei heraus, dass nicht genau zum Key passte. Der Apache2 quittierte dann beim Starten mit oben genannter Meldung den Dienst.

KategorienApache - PHP