iptables REJECT

So wird SSLv3 deaktiviert: Apache, Nginx, Postfix, Dovecot, Chrome, Firefox & IE

Seitdem vergangenen Wochenende ist nun öffentlich bekannt geworden, dass SSLv3 eine Lücke hat und es dafür keinen Patch mehr geben wird. Daher ist man besser beraten, wenn man SSLv3 (ca. 18 Jahr alt) deaktiviert und auf TLS (ca. 15 Jahre alt) setzt. Jetzt gilt es sich vor einem möglichen POODLE-Angriff zu schützen. Ein paar Tweets zum Thema SSL/TLS hatte ich gestern auch schon gepostet. Nun sind aber einige Mails und DMs bei mir angekommen, wo ihr wissen wollt wie man SSLv3 deaktiviert. Ich hab das für Euch mal kurz zusammengefasst und neben SSLv3 wird auch gleich SSLv2 deaktiviert:

Apache
Je nachdem wie euer Apache Webserver konfiguriert ist, muss die folgende Zeil in die „httpd.conf“ oder in die entsprechende VHOST-Datei:
# Apache bis Version 2.2.22
SSLProtocol all -SSLv2 -SSLv3
# Apache ab Version 2.2.23
SSLProtocol TLSv1 TLSv1.1 TLSv1.2

Nginx
Bei Nginx muss die folgende Zeile hinzugefügt werden:
ssl_protocols TLSv1.1 TLSv1.2 TLSv1;

Postfix
Die Konfigurationsdatei „main.cf“ von Postfix muss mit diesen Zeilen angpasst werden:
smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
smtp_tls_mandatory_protocols = !SSLv2 !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2 !SSLv3

Dovecot (ab Version 2.1)
Auch wenn es vielleicht ziemlich unwahrscheinlich ist das über IMAPS was kommt, hier die Zeile für Dovecot:
ssl_protocols = !SSLv2 !SSLv3

Continue reading…

NGINX

Nginx: SSL Session Cache

Wer einen Nginx Webserver hat und auf diesem auch SSL benutzt, sollte einige Optimierungen für HTTPS vornehmen:

SSL Session Cache aktivieren
Vielleicht ist es Euch schon mal aufgefallen, dass die meisten HTTPS-Aufrufe immer etwas länger dauern als normal. Der Grund hierfür ist die Aushandlung von Parametern. Diese werden bei der ersten Verbindung ausgehandelt und können bei Nginx im SSL Session Cache gespeichert werden. Dadurch gehen die darauffolgenden Anfragen deutlich schneller, weil die Parameter schon feststehen.

Damit der SSL Session Cache von Nginx auch läuft, sind nur 2 Zeilen in der Konfiguration (meistens in der „nginx.conf“) zu ergänzen:

http {
ssl_session_cache shared:SSL:40m;
ssl_session_timeout 10m;
}

Eventuell kann es nötig sein die Cache-Größe höher einzustellen. Laut Nginx Dokumentation können bei 1 MB Cache ca. 4000 Sessions gespeichert werden.

NGINX

Nginx: TLS statt SSL nutzen

TLS ist der Nachfolger von SSL und wird inzwischen von den meisten Browsern bevorzugt. Es wird auch weiterhin SSL-Verbindung heißen, obwohl man TLS nutzt. TLS ist sicherer als SSL und sollte dadurch auch bevorzugt genutzt werden.
Daher sollte man auf SSLv1, SSLv2 und SSLv3 ganz verzichten und nur noch TLSv1, TLSv1.1 oder TLSv1.2 erlauben/nutzen. Ich glaube der IE6 ist der einzige Browser der kein TLS kann. Aber wer benutzte den noch.

Der Standardwert der SSL-Protokolle bei Nginx sieht so aus:
http {
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
}

Wenn man nur noch TLS einsetzen möchte, dann lautet die Zeile:
http {
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
}

Wichtig hierbei ist allerdings, dass dies nur funktioniert wenn OpenSSL 1.0.1 oder höher bei Euch auf dem Server läuft.

NGINX

Schnell und schlank: Nginx Webserver

Vor einigen Jahren habe ich mich entschieden statt dem Apache Webserver zukünftig nur noch Nginx als Webserver einzusetzen. Ich hatte damals irgendetwas über den Nginx Webserver gelesen und seither begeistert er mich immer wieder. Gerade habe ich wieder so einen Moment und deswegen schreib ich diese Zeilen. Der von Igor Sysoev entwicklete Webserver ist nicht nur ein Webserver, sondern kann auch als Reverse Proxy und als E-Mail-Proxy eingesetzt werden.
In den vergangenen Jahren wurde der modulare Webserver immer beliebter und wird von vielen Firmen eingesetzt. Bekannte Nginx Nutzer: Netflix, Hulu, Pinterest, Airbnb, Wikimedia, Golem.de, CloudFlare, SourceForge, ComputerBase, SoundCloud, MaxCDN, GitHub und WordPress.com. Die Gründe für Nginx sprechen für sich: sehr schlank, sehr schnell, modularer Aufbau und flexible Konfiguration. Gerade bei hoher Last verbraucht Nginx deutlich weniger Ressourcen als seine Mitbewerber. Am besten Ihr schaut Euch Nginx einfach selber mal an. Ich werde mal schauen welche Tipps und Tricks ich Euch mit auf den Weg geben kann …

Linux: Handy Varnish commands

Experimentiere gerade etwas mit Varnish und da sind die Befehle ganz nützlich:

varnishlog
See what Varnish is currently processing.

varnishtop -i RxHeader -I ^Referer
Show the referer (sic) header for requests.

varnishtop -b -i TxURL
Shows requests made to the backend (-b) where the line matches (-i) the transmit URL (TxURL). Basically, shows you what is being passed to the backend and isn???t being cached. It will list all requests going to a backend, grouped by URL and sorted by a decaying average of frequency. Basically the number on the left should be single-digit and preferably all 1s or less (a higher number means the backend request is taking place frequently). [Technically, you don’t even need the „-b“ as the TxURL is only set when making requests to the backend anyway]

varnishhist
Shows a histogram chart of the last 1,000 requests (by default) to the Varnish proxy showing ???|??? as a ???hit??? on the cache and ???#??? as a miss. The more ???|??? to the left of the chart, the better. The scale on the bottom is in seconds with 1e0 being ???1??? second and 1e-6 being 0.000001seconds (1e-1 being 0.1seconds). The vertical scale is shown in the top left hand corner.

varnishstat
Shows various information about varnish ??? I???m sure I???ll figure out what they mean in time???

Blog wegen Angriff auf Websenat nicht erreichbar

Jetzt musste ich hier aber mal etwas härter durchgreifen als gedacht. Seit letztem Wochenende ist das Websenat Blog etwas schwer zu erreichen. Nicht wegen dem Server, sondern wegen irgendwelchen Skriptkiddies die meinen ihren tollen „Securityscanner“ mal an meinem Server auszuprobieren. Durch die andauernden Anfragen auf meinen Webserber (Apache 2) wird die Last auf dem Server zu hoch, so dass dieser dann den Webserver abschaltet. Dadurch sind das Websenat Blog und andere Websites nicht mehr erreichbar.
Nun habe ich entsprechende Gegenmassnahmen (per Firewall werden die IP-Adressen geblockt) vorgenommen, mal schauen ob dies schon reicht. Ansonsten werde ich andere Mittel ergreifen. Alle IP-Adressen die sich ein 1&1 Servern zuordnen lassen, werde ich entsprechend 1&1 melden.
Die Anfragen sind immer das gleiche (Auszug aus dem Logfile):

xxx.xxx.xxx.xxx – – [03/Apr/2009:23:04:53 +0200] „GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1“ 400 302 „-“ „-“
xxx.xxx.xxx.xxx – – [03/Apr/2009:23:04:54 +0200] „GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1“ 400 302 „-“ „-“
xxx.xxx.xxx.xxx – – [03/Apr/2009:23:04:54 +0200] „GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1“ 400 302 „-“ „-“
xxx.xxx.xxx.xxx – – [03/Apr/2009:23:04:56 +0200] „GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1“ 400 302 „-“ „-„

Anhand von „w00tw00t.at.ISC.SANS.DFind“ scheint es sich um das Tool DFind zu handeln. Dieser ist ein vulnerability Scanner, der den Server auf folgende Schwachstellen durchsucht (Symantec Hacktool.DFind):

Open TCP and UDP ports
HP Web JetAdmin
PSOProxy Server
HP Web Server
Microsoft Frontpage
Hacktool.Radmin
RealServer
Apache Servers
IIS servers
Windows Media Service
IPC$ shares without password protection.
Weak write permissions in Microsoft IIS web server.
Backdoor.OptixPro.10 and variants.
Dictionary attacks on SQL Servers
NULL/NTAuth/Passworded connections on Hacktool.Radmin
The CCBill webserver module
The PHPbb webserver module
The PHP-Nuke webserver module.
WebDav enabled on IIS5.0 webservers
The Microsoft Windows IIS Index Server ISAPI System-level Remote Access Buffer Overflow (MS01-033)
The Microsoft SQL Server MDAC buffer overflow (MS02-040)

Wenn es nur ein paar Anfragen wären, dann wär das noch okay. Aber in meinem Fall sind das hunderte/tausende am Tag! Werde auch mal anstreben meinen Server auf ein aktuelles Linux umzuziehen, damit der Apache nicht immer abstürzt.