Februar 19, 2014
1 Kommentar

nginx: HTTP Header filtern und ändern

Um mehr Kontrolle über die HTTP Header im nginx zu erhalten, empfiehlt sich das Modul ngx_headers_more. Wurde dieses erfolgreich mit kompiliert, kann zum Beispiel der Server Banner beliebig überschrieben werden:

more_set_headers    "Server: MyWebServer";

Das Entfernen von Header Einträgen geschieht via more_clear_headers, zum Beispiel:

more_clear_headers X-Powered-By X-Runtime;

Dezember 6, 2013
Kommentieren

HTTP Methoden deaktivieren

Damit ein Browser mit einem Webserver kommunizieren kann, stellt der Webdienst HTTP Methoden zur Verfügung. Zu den gebräuchlichsten gehören GET und POST. Das HTTP Protokoll kennt eine Reihe weiterer Methoden („verbs“), welche seltener gebraucht werden, jedoch für Angreifer nützlich sind. Diese sollten daher deaktiviert werden.

Konfiguration

So deaktivieren Sie HTTP Methoden unter Apache und nginx.

Hintergrund

Ein Webserver kann folgende HTTP Methoden bereit stellen:

  • GET – mit dieser Methode werden vom Client Ressourcen unter einer definierten URL vom Webserver angefordert
  • POST – sendet Daten vom Client an den Server.
  • HEAD – der Server sendet dem Client den gleichen Header wie bei einem GET Request, jedoch ohne den Body (Inhalt) mit zu senden.
  • PUT – erlaubt dem Client eine Ressource an eine URI hoch zu laden.
  • PATCH – Partieller Update einer Ressource
  • DELETE – löscht eine Ressource auf dem Server.
  • TRACE – der Server liefert eine Client Anfrage so zurück, wie er sie erhalten hat. Dies kann hilfreich sein beim Debugging.
  • OPTIONS – liefert eine Liste mit allen vom Server unterstützten Methoden zurück.
  • CONNECT – wird von HTTP Proxies unterstützt, um einen Tunnel aufzubauen.

Die obige Liste ist nicht abschliessend. Nicht verwendete Methoden werden deaktiviert, um die Angriffsfläche zu reduzieren.

Weiter kann es Sinn machen, die Grösse von Requests zu limitieren, um grössere Datenmengen für bestimmte Angriffe  zu verhindern.

Das Unterbinden der TRACE Methode verhindert, dass ein Angreifer via Webserver die lokale Topologie ausspionieren könnte.

Um nun einen Server manuell auf die zur Verfügung gestellten Methoden zu testen, kann zum Beispiel netcat verwendet werden:

echo -e "OPTIONS / HTTP/1.0\n" | nc example.com 80
HTTP/1.1 200 OK
Date: Sun, 28 Apr 2013 08:32:16 GMT
Server: Zope/(Zope 2.10.12-final, python 2.4.6, linux2) ZServer/1.1 Plone/3.3.5
DAV: 1,2
Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK
Cache-control: private
Content-Length: 0
X-Varnish: 1049029877
Age: 0
Via: 1.1 varnish
Set-Cookie: serverid=p0102; path=/
Connection: close
Content-Type: text/plain; charset=UTF-8

Und um verifizieren zu können, dass eine HTTP Methode vom Webserver aufgrund der (korrekten) Konfiguration abgelehnt wird, sollte eine Ausgabe von netcat ungefähr so aussehen:

echo -e "OPTIONS / HTTP/1.0\n" | nc google.com 80 HTTP/1.0 405 Method Not Allowed Content-Type: text/html; charset=UTF-8 Content-Length: 962 Date: Sun, 28 Apr 2013 08:31:20 GMT Server: GFE/2.0

November 29, 2013
Kommentieren

nginx: HTTP Methoden deaktivieren

Um dem nginx Webserver mitzuteilen, welche HTTP Methoden akzeptiert werden sollte, muss folgenden Konfiguration gesetzt werden:

if ($request_method !~ ^(GET|HEAD|POST)$ ) {
  return 444;
}

Im obigen Beispiel werden explizit die Methoden GET, HEAD und POST zugelassen. Alle anderen Methoden sind nicht erlaubt.

Oktober 3, 2013
Kommentieren

Die Risiken des Patching

Professionelles Patch Management ist ein wichtiger Prozess in der IT Sicherheit. Viele Firmen aber verlassen sich blind darauf und hängen dem Irrglauben nach, dass automatisch gepatchte Systeme auch automatisch sicher sind.

Patching allein genügt nicht

Um die bestmögliche Sicherheit zu gewährleisten, reicht Patching nicht aus. Ein Patch kann zwar existierende Sicherheitslücken schliessen, aber womöglich auch neue, verwundbare Funktionen bringen. Zudem besteht die Gefahr, dass bereits umgesetzte Massnahmen nichtig gemacht werden, da z.B. Konfigurationen überschrieben oder neue Standard-Werte gesetzt werden.

Reaktionszeiten

Ein wichtiger Grund, warum immer wieder von erfolgreichen Attacken zu lesen ist, sind die Reaktionszeiten. Vor allem im Linux Umfeld werden oft selbst kompilierte Module von kritischen Applikationen verwendet. Diese sind dann im Paket-Management nicht erfasst und werden beim Update übergangen.

Inzwischen ist ein Security Audit alle 1-2 Jahre zur Praxis geworden, aber auch hier besteht  die Gefahr, dass Verwundbarkeiten sehr lange Zeit unerkannt bleiben.

Automatismen nutzen

Der personelle Aufwand, um bei jedem System nach jedem Patching Konfiguration und Module zu prüfen und einem manuellen Audit zu unterziehen sind enorm und nicht tragbar. Hier gezielt auf Automatismen zu setzen, macht wirtschaftlich Sinn.

Ein Vulnerability Management System wie netsense Gravity nutzt täglich aktualisierte Scanner und prüft in frei konfigurierbaren Intervallen (z.B. täglich, wöchentlich oder monatlich) auf sämtliche bekannte Schwachstellen. Bei relevanten Issues wird der Verantwortliche umgehend alarmiert, damit er die notwendigen Schritte einleiten kann.

Ein professionelles Vulnerability Management reduziert die Reaktionszeit von Monaten hin zu Tagen oder Stunden. Und dank SaaS erfolgt dies unkompliziert und ohne grossen Initialaufwand.

August 8, 2013
Kommentieren

SSL/TLS Versionen erkennen

Bietet ein Dienst eine verschlüsselte Verbindung an, werden aus Kompatibilitätsgründen meist mehrere Verschlüsselungsoptionen auf unterschiedlichem kryptographischen Niveau angeboten.

Ein schneller Test für Webserver lässt sich einfach über unseren kostenlosen SSL Checker durchführen. Falls sie andere Services oder Ports testen wollen, erledigen Sie dies über  unsere Vulnerability Management Plattform. Falls Sie nur an den Rohdaten interessiert sind, können Sie auch ein Tool wie sslscan nutzen. Ein Beispiel:

# sslscan --no-failed <ZIEL-IP>
<snip>
Supported Server Cipher(s):
Accepted SSLv3 256 bits DHE-RSA-AES256-SHA
Accepted SSLv3 256 bits DHE-RSA-CAMELLIA256-SHA
Accepted SSLv3 256 bits AES256-SHA
Accepted SSLv3 256 bits CAMELLIA256-SHA
Accepted SSLv3 168 bits EDH-RSA-DES-CBC3-SHA
Accepted SSLv3 168 bits DES-CBC3-SHA
Accepted SSLv3 128 bits DHE-RSA-AES128-SHA
Accepted SSLv3 128 bits DHE-RSA-CAMELLIA128-SHA
Accepted SSLv3 128 bits AES128-SHA
Accepted SSLv3 128 bits CAMELLIA128-SHA
Accepted TLSv1 256 bits DHE-RSA-AES256-SHA
Accepted TLSv1 256 bits DHE-RSA-CAMELLIA256-SHA
Accepted TLSv1 256 bits AES256-SHA
Accepted TLSv1 256 bits CAMELLIA256-SHA
Accepted TLSv1 168 bits EDH-RSA-DES-CBC3-SHA
Accepted TLSv1 168 bits DES-CBC3-SHA
Accepted TLSv1 128 bits DHE-RSA-AES128-SHA
Accepted TLSv1 128 bits DHE-RSA-CAMELLIA128-SHA
Accepted TLSv1 128 bits AES128-SHA
Accepted TLSv1 128 bits CAMELLIA128-SHA

Prefered Server Cipher(s):
SSLv3 256 bits DHE-RSA-AES256-SHA
TLSv1 256 bits DHE-RSA-AES256-SHA
<snap>

Diese Ausgabe listet alle unterstützten Verschlüsselungsmöglichkeiten auf. SSLv1 – SSLv3 sollten aus Sicherheitsgründen deaktiviert werden. Auch TLSv1 kann in Kombination mit bestimmten Ciphers problematisch sein.

Die Schlüssel sollten mindestens 128bit lang sein, damit nach dem heutigen Stand der Technologie ausreichend Sicherheit gewährleistet ist. Auch sollten unsichere Verschlüsselungsalgorithmen wie DES oder Hashfunktionen wie MD5 vermieden werden.

Lesen Sie auch, wie Sie eine sichere SSL Konfiguration für Webserver erstellen.

Juli 16, 2013
Kommentieren

OS Fingerprinting

OS Fingerprinting versucht das Betriebssystem eines entfernten Servers zu erkennen. Das Vorgehen ist ähnlich wie bei der Dienst-Erkennung. Hinzu kommt das TCP/IP Stack Fingerprinting: Hier sendet der Angreifer speziell formatierte Pakete, wobei bekannt ist, dass bestimmte Implementierungen des Stacks anders reagieren. Kombinierte Proben geben so wiederum Hinweise auf die Plattform des Zielsystems.

Fingerprinting ist keine exakte Wissenschaft und arbeitet mit Wahrscheinlichkeiten. Falls ein Scanner also das falsche Betriebssystem ausweist, ist dies als verhinderter Informationsabfluss also positiv zu werten.

Es gibt durchaus Möglichkeiten, die Erkennung einer Plattform zu erschweren. Jedoch sind dazu meist tiefe Eingriffe in das Betriebssystem nötig. Um gewisse Eigenschaften des TCP/IP Stacks zu verändern, könnte man zum Beispiel folgende Optionen anpassen:

  • TCP Initial Sequence Number (ISN)
  • TCP initial window size
  • TCP options (their types, values and order in the packet)
  • IP ID numbers

Diese sogenannten Flags der Protokolle lassen sich bei Linux-/Unix-basierten Systemen über Kernel Parameter oder durch Manipulation des Source Codes verändern.

Unter Linux hat man weiter die Möglichkeit, Pakete mit folgenden Optionen zu verwerfen:

  • Pakete mit SYN und FIN aktiv
  • Pakete mit einem Reserve-Bit aktiv im TCP Header
  • Pakete, welche nicht ein ACK, SYN, RST oder FIN Flag aktiv haben
  • Pakete mit FIN, PUSH und URG

Die aufgelisteten Pakete sind gemäss TCP Standard ungültig. Meist werden aus Performancegründen Pakete nur teilweise validiert. Werden solche Pakete aber verworfen, wird die automatische Plattform-Erkennung erschwert.

Interessante weiterführende Informationen zu OS Fingerprinting finden Sie bei nmap.

Juni 11, 2013
Kommentieren

Informationsabfluss im HTTP Protokoll

Fast immer bei einer Sicherheitsüberprüfung der IT Infrastruktur findet man Dienste, welche Informationen über das HTTP-Protokoll zu Verfügung stellen. Die Informationen befinden sich in einer HTTP Antwort, die in etwa so aussieht:

Protocol version : HTTP/1.1
SSL : no
Pipelining : no
Keep-Alive : no
Options allowed : OPTIONS, TRACE, GET, HEAD, POST
Headers :

Connection: close
Date: Mon, 29 Jun 2009 17:16:57 GMT
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Content-type: text/html

Im Allgemeinen kann diese Information als nicht sicherheitskritisch eingestuft werden. Jedoch sieht man in diesem Beispiel den Namen und die Version des Webservers (Microsoft IIS  6.0). Diese Information kann nun verwendet werden, um ausfindig zu machen, ob es eine bekannte Schwachstelle zu diesem Dienst gibt. Um diesen Schritt zu erschweren, sollte dieser Informationsabfluss entfernt werden.

Siehe auch:

Mai 21, 2013
Kommentieren

Deaktivieren Sie ICMP Timestamps

ICMP Timestamps ermöglichen es, die exakte Systemzeit ausfindig zu machen. Dies kann für Timing-basierte Angriffe interessant sein.

Anleitungen

Windows: ICMP Timestamps deaktivieren

Linux: ICMP Timestamps deaktivieren

Hintergrund

Das ICMP Protokoll (Internet Control Message Protocol) dient dazu, Informationen und Fehlermeldungen über das IPv4 und IPv6 (dann auch ICMPv6) Protokoll auszutauschen. Die bekannteste ICMP-Anwendung ist der ping Befehl.

Mai 13, 2013
Kommentieren

Apache: HTTP Methoden deaktivieren

Um beim Apache Webserver die HTTP Methoden zu erlauben oder zu unterbinden, sollte die LIMIT Direktive verwendet werden.

Ein Beispiel:

<Limit TRACE OPTIONS>
Require valid-user
</Limit>

Auf diese Weise können die Methoden TRACE und OPTIONS nur von einem authentifizierten Benutzer (beispielsweise ein Administrator) benutzt werden.

Weiter kann die TRACE (bzw. TRACK) Methode auch über eine Rewrite Regel gefiltert werden:

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

Aktuellere Apache Versionen (ab 1.3.34, 2.0.55 und 2.2) unterstützten die TraceEnable Direktive in der Konfiguration:

TraceEnable off

Mai 7, 2013
Kommentieren

Warum Sie TCP Timestamps deaktivieren sollten

Über TCP Timestamps kann ein Angreifer Rückschlüsse auf die Laufzeit eines Systems machen. Er sieht also, wann das System das letzte Mal neu gestartet wurde. Dies wiederum lässt Schlüsse auf den Patchlevel zu.

Dies ist ein klassischer Informationsabfluss und sollte verhindert werden:

Hintergrund

Zeitbasierte Informationen können via TCP und ICMP entnommen werden. Dieser Artikel bezieht sich nur auf TCP Timestamps.

TCP Timestamps werden im RFC 1323 definiert. Diese Timestamps können dazu beitragen, dass TCP Packete beim Empfänger zeitlich sortiert werden können. Die Timestamp Information ist üblicherweise nicht abgeglichen mit der Systemuhr. Stattdessen wird mit ein relativer Wert verwendet, der beim Booten auf 0 gesetzt wird und in einer bestimmten Frequenz (z.B. 100Hz) erhöht wird.

Beispiel

Im folgenden Beispiel wird ein SYN Paket an einen offenen Port geschickt. Daraus lässt sich ablesen, dass der Host vor 7 Stunden neu gestartet wurde:

hping3 -S -p 443  --tcp-timestamp
len=56 ip= ttl=119 DF id=13843 sport=443 flags=SA seq=1 win=8192 rtt=12.6 ms
  TCP timestamp: tcpts=2672218
  HZ seems hz=100
  System uptime seems: 0 days, 7 hours, 25 minutes, 22 seconds