Zugschlusbeobachtungen (Entries tagged as security)

Spezifikation von Firewallregeln - do's and dont's

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 11 Jan 2010 10:29:40 +0100

Wenn eine Applikation über das Netz kommuniziert, funktioniert sie natürlich nur dann, wenn das Netz zwischen den beteiligten Maschinen diese Kommunikation auch durchleitet. Das ist im Internet üblicherweise der Fall; beim Übergang zwischen privaten Netzen und dem Internet in aller Regel nicht: Dort ist eine Firewall im Einsatz, die üblicherweise nach der Deny-all-Strategie alle Kommunikation blockiert, die nicht explizit freigegeben ist.

Auf diese Weise wird man im allgemeinen für eine neue Applikation eine Anpassung an der Firewall vornehmen müssen - es sei denn, die Applikation gibt sich Mühe, wie ein Dienst auszusehen, der üblicherweise freigegeben ist. Das tun zunehmend viele Applikationen und geben sich durch Benutzung von http als Transportprotokoll als Webclient und Webserver aus, was in vielen Firewalls direkt freigegeben ist. Doch dies ist Stoff für einen anderen Artikel.

In diesem Artikel möchte ich davon schreiben, wie die Spezifikation aussehen soll, damit der Firewalladmin auch weiß, was er für eine neue Applikation in seiner Firewall freischalten soll. In vielen Dokumentationen über (freie oder kommerzielle) Software findet man Listen von Ports, die mehr oder weniger vollständig und mehr oder weniger korrekt sind. Leider trifft in den meisten Fällen das “weniger” zu.

Doch zunächst ein paar Grundlagen zum Thema TCP/IP. Damit man in der Firewall nicht zu viel freigeben muss, sollten die notwendigen Kommunikationsbeziehungen möglichst eng beschrieben sein. Eine TCP/IP-Kommunikationsbeziehung fast aller Mainstreamprotokolle beschreibt ein Fünftupel, bestehend aus Source-IP, Destination-IP, Protokoll, Source-Port und Destination-Port.

Wenn ein Client C mit einem Server S sprechen möchte, dann ist das Protokoll, das er dafür benutzen möchte, in der Applikation festgelegt. TCP wird für Datenübertragung benutzt, bei der man sich darauf verlassen möchte, dass die Daten bei ihrer Ankunft am Ziel korrekt und vollständig sind, und bereit ist, dafür erhöhten Netzaufwand und unregelmäßige Übertragungszeiten in kauf zu nehmen. UDP benutzt man üblicherweise, wenn es sich nur um winzige Datenmengen (z.B. DNS-Anfragen und ihre Antworten) handelt oder es eher darauf ankommt, dass Daten entweder gar nicht oder halbwegs zeitlich passend ankommen (Streaming, Telefonie etc).

In beiden Fällen würfelt sich der Client normalerweise einen seiner freien Ports aus und benutzt diesen als Source-Port. Der Destination-Port ist meist mit der Applikation festgelegt und bestimmt auf der Seite des Empfängers den Prozess, bei dem das Paket abgeliefert werden soll. In der Programmierung funktioniert das so, dass der Serverprozess sich an den von ihm gewünschten Port bindet, ihn sozusagen “abhört” (im englischen nennt man das passender “listen on the port”) und alle dorthin gesendeten Daten empfangen kann.

So hat eine DNS-Anfrage üblicherweise das Protokoll UDP (Protokollnummer 17), die Destination-IP des Nameservers und den Destination-Port 53. Der Server dreht bei seiner Antwort das Tupel um und sendet seine Antwort mit Source-Port 53 mit der IP des Clients als Destination-IP und der vom Client als seinen Source-Port gewählten Portnummer als Destination-Port. Das sieht “auf dem Kabel” in etwa so aus:

01: proto=UDP srcip=192.168.218.21 srcport=49221 dstip=206.251.36.94 dstport=53
02: proto=UDP srcip=206.251.36.94 srcport=53 dstip=192.168.218.21 dstport=49221

Hier hat sich der Client also den Port 49221 gewürfelt. Die Antwort des Servers kommt bei der Client-Applikation an, weil sie an den Port 49221 geschickt wurde - der Client kann also die Antwort anhand des Destination-Ports des Antwortpaketes der Frage zuordnen.

Bei TCP (Protokollnummer 6) ist’s im Prinzip dasselbe, nur dass schon der Verbindungsaufbau (also bevor überhaupt ein Bit Nutzdaten geflossen sind) aus drei Paketen (dem sogenannten Dreiwegehandshake) besteht. Hier dasselbe für TCP und eine kurze http-Anfrage:

01: proto=TCP flags=SYN srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80
02: proto=TCP flags=SYN,ACK srcip=81.169.179.176 srcport=80 dstip=192.168.218.21 dstport=37734
03: proto=TCP flags=ACK srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80
04: proto=TCP flags= srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80
05: proto=TCP flags= srcip=81.169.179.176 srcport=80 dstip=192.168.218.21 dstport=37734
06: proto=TCP flags= srcip=81.169.179.176 srcport=80 dstip=192.168.218.21 dstport=37734
07: proto=TCP flags= srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80
08: proto=TCP flags=FIN srcip=81.169.179.176 srcport=80 dstip=192.168.218.21 dstport=37734
09: proto=TCP flags= srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80
10: proto=TCP flags=FIN srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80
11: proto=TCP flags= srcip=81.169.179.176 srcport=80 dstip=192.168.218.21 dstport=37734

Das bedarf dann doch einer kleinen Erklärung: Die Pakete 01 bis 03 sind der Dreiwegehandshake für den Verbindungsaufbau (SYN, SYN/ACK, ACK). In Paket 04 übermittelt der Client seinen http-Request, der in Paket 05 vom Server quittiert wird. Paket 06 ist die (in ein Paket passende) Antwort; Paket 07 die dazu gehörende Quittung. Da der Server keine weiteren Daten zu übermitteln hat, signalisiert er in Paket 08 den Wunsch des Verbindungsabbaus (FIN). Paket 09 ist die Quittung dafür; die Pakete 10 und 11 sind der Verbindungsabbau seitens des Clients und die dazu passende Quittung.

Abgesehen von den oben gezeigten Standardfällen gibt es noch einen ganzen Haufen von Sonderfällen. So hat ESP als IP-Protokoll keine Portnummern, so dass ein Paket einer ESP-Verbindung nur durch das Tripel Source-IP, Destination-IP, Protokollnummer 50 (ESP) klassifiziert werden kann. In einigen wenigen Protokollen spielt die Absenderportnummer eine Rolle; und wieder andere wenige Protokolle benutzen TCP UND UDP, dies aber auf derselben Portnummer. Und dann gibt es natürlich “kranke, firewallfeindliche” Protokolle wie ftp, SIP, nfs, amanda, RPC (inklusive MS-RPC), bei denen die Portnummern für den “eigentlichen” Dienst beidseitig erst durch eine Unterhaltung der beteiligten Systeme durch eine Steuerverbindung auf einem wohldefinierten Port ermittelt werden.

Wir sehen auch, dass im allgemeinen die Kommunikation zwischen zwei Systemen nahezu immer bidirektional stattfindet. Nur in ganz wenigen Sonderfällen (von denen mir gerade partout keiner einfallen möchte) versendet die eine Seite ein Paket, ohne sich jemals für eine Antwort oder Quittung zu interessieren. Glücklicherweise braucht man sich darum in der Regel heutzutage bei halbwegs aktuellen Firewalls nicht mehr zu kümmern: Es reicht, wenn man für eine erwünschte Kommunikationsbeziehung das jeweils erste Paket erlaubt; die direkt oder indirekt dazu gehörenden Pakete werden von der Firewall automatisch als solche erkannt und automatisch durchgelassen. Das trifft meist auf die direkten Antwortpakete zu, aber bei besseren Systemen auch auf kompliziertere Fälle wie den unabhängigen Datenkanal bei “kranken” Protokollen wie ftp oder zur Verbindung gehörende ICMP-Fehler wie “host unreachable” oder “fragmentation needed”.

Für die beiden oben zitierten Paketdumps reichen also zwei Regeln:

proto=UDP srcip=192.168.218.21 srcport=49221 dstip=206.251.36.94 dstport=53
proto=TCP flags=SYN srcip=192.168.218.21 srcport=37734 dstip=81.169.179.176 dstport=80

Halt, stop. Da ist noch was zu viel: Der Source-Port wird vom Client jeweils neu ausgewürfelt; wir dürfen die Firewallregeln also nicht ganz so eng fassen, wenn der Dienst auch beim zweiten Zugriffsversuch noch funktionieren soll:

proto=UDP srcip=192.168.218.21 dstip=206.251.36.94 dstport=53
proto=TCP flags=SYN srcip=192.168.218.21 dstip=81.169.179.176 dstport=80

Wie wir alle wissen, benutzt DNS im Normalfall UDP, fällt aber bei manchen Fehlern auf das (langsamere, aufwändigere) TCP zurück - beispielsweise wenn die Antwort nicht mehr in ein Antwortpaket passt. Also braucht’s noch eine dritte Regel, die den DNS-Sonderfall abdeckt:

proto=TCP flags=SYN srcip=192.168.218.21 dstip=206.251.36.94 dstport=53

Bei TCP ist es zweckmäßig, nur “erste” Pakete durchzulassen, die auch korrekterweise das SYN-Flag gesetzt haben. Sonst lässt man im Zweifel Pakete bis zum Host durch, von denen wir schon wissen, dass sie nicht koscher sind, und dass der Host sie eh nur verwerfen wird.

Auf Unix-ähnlichen Systemen gibt es noch eine weitere Unterscheidung: Die Ports 1-1023 bleiben dem Benutzer root vorbehalten; nur Prozesse, die als root laufen, dürfen diese Ports des lokalen Systems verwenden. Man sieht deswegen in Firewallregeln wie den oberen oft die Begrenzung auf die “hohen” Ports ab 1024. Eine solche Begrenzung bringt aber keine zusätzliche Sicherheit, denn ein Prozess, der einen der “niedrigen” Ports benutzen darf, könnte genauso gut einen “hohen” Port verwenden. Ich empfehle deswegen das KISS-Prinzip und den allgemeinen Verzicht auf Beschränkungen des Source-Ports bei so einfachen Regeln.

Aus diesen Informationen dürfte klar sein, dass an Herstellerdokumentationen “erlauben Sie Port 80 TCP/UDP” oder “Wir benutzen die Ports 514 und 443 incoming und outgoing” oder “benötigt: Port 1024-65535” wenig Sachkenntnis beteiligt war. Wer stur nach solchen Regeln arbeitet, reißt sich große Sicherheitslöcher in seine Infrastruktur und ist nur noch durch das vielleicht vorhandene NAT vor den fatalen Folgen solcher Konfigurationsfehlern geschützt - oder eben nicht.

Je länger die Portliste, desto höher ist die Wahrscheinlichkeit, dass manche dieser Ports nur noch aus historischen Gründen in der Liste stehen und von der Applikation seit etwa 1948 nicht mehr genutzt werden. Gerne sieht man das bei Applikationen, die unter Windows entweder Laufwerke mappen wollen oder in irgend einer Art mit dem Active Directory sprechen: Microsoft hat diese beiden Zugriffsmethoden in den letzten zehn Jahren mehrfach umspezifiziert und jedes Mal neue Ports verwendet, und die älteren Portnummern braucht man nur, wenn auch noch ältere Versionen im Einsatz sind. In aktuellen Netzen reißt man sich damit potenzielle Sicherheitslöcher, denn auch die aktuellen Server lauschen natürlich im Interesse der Rückwärtskompatibilität auch auf den “älteren” Ports.

Viele andere Ports aus solchen ellenlangen Listen werden nur dann benötigt, wenn man ein bestimmtes obskures Feature der Software verwendet. Oder ein Eintrag in einer Portliste ist schlicht und einfach inkorrekt. Auch schon passiert: Ein essentiell wichtiger Port steht aus irgend einem Grund nicht in der Liste und lässt die Applikation auch dann subtil versagen, wenn man die Portdokumentation sklavisch in Firewallregeln konvertiert hat.

Deswegen lautet meine Empfehlung ganz klar, vom Hersteller einer Software gelieferte Portlisten komplett zu ignorieren und aus tcpdump und Firewall-Log herauszudestillieren, welche Kommunikationsbeziehungen die Applikation im gegebenen Anwendungsszenario wirklich zu benutzen gedenkt. Das funktioniert allerdings selten auf Anhieb, weil oftmals der nächste Port erst benutzt wird, wenn der Zugriff auf den erstfreigegebenen Port erfolgreich war. Man ist also gut beraten, wenn man die Applikation entweder selbst bedient oder den Anwender vorher darauf vorbereitet, dass man mehrere Iterationen von “probier’s nochmal, ah ja, moment” benötigen wird bis die Applikation benutzbar sein wird - denn sonst wird einem diese Trial-and-Error-Methode gerne als unstrukturiertes oder unfähiges Vorgehen missinterpretiert. Außerdem muss man darauf vorbereitet sein, im Rahmen dieser Vorgehensweise auch die obskureren Funktionen der Software bis hin zum “Agent-Update auf dem Client” auszuprobieren, denn sonst fällt einem die Sicherheitspolicy vielleicht irgendwann im laufenden Betrieb schmerzhaft auf den Fuß.

Wenn man die aufwändige Phase einmal abgeschlossen hat, wird man nicht selten mit einem schlanken, gut dokumentierten Regelwerk belohnt, von dem man weiß, dass es keine unnötigen Risiken enthält. Außerdem bekommt man durch die Arbeit mit dem Firewall-Log und tcpdump ein Gefühl für die Kommunikation und genug Erfahrung mit den Tools, um später im Fehlerfall souverän mit den Tools umgehen zu können und deren Ausgabe sinnvoll interpretieren zu können. Und es erspart einem unnötige Aktionen mit der Glaskugel um zu raten, was der Hersteller mit seiner unvollständigen Dokumentation, die nicht selten stur aus einer Portliste ohne Protokoll- und Richtungsangabe besteht, wohl gemeint haben könnte.

Abschließend noch eine Wunschliste: Wenn Ihr den Firewallbetreuern Eurer Anwender einen großen Gefallen tut, dann beschreibt die Kommunikationsbeziehungen Eurer Software vollständig. Das bedeutet also im Zweifel eine Liste wie hier:

name=DNS proto=(UDP/TCP) srcip=(1) dstip=(2) dstport=53
name=http proto=TCP srcip=(1) dstip=ivanova.notwork.de,*.zugschlus.de dstport=80
name=amanda-control proto=UDP srcip=client dstip=server dstport=10080
name=amanda-data proto=TCP srcip=client srcport=50000 dstip=server dstport=50000-50100

(1)=IP-Adresse des lokalen Systems
(2)=Full Service Resolver für das lokale System

Dokumentation gehört zum Regelwerk dazu, denn man möchte auch in zwei Jahren noch verstehen, warum man das, was da drin steht, auch reingeschrieben hat. Deswegen liefert Eurem Firewaller bitte auch, wie das System heißt, für das da die Regeln eingetragen werden sollen, und was es tut. Er wird dann noch das aktuelle Datum und Euren Namen dazuschreiben, und dann ist die Dokumentation brauchbar.

Wenn es sich um ein Testsystem handelt, ist es sinnvoll, die damit verbundenen Regeln zeitlich zu beschränken. Dazu muss der Firewaller aber wissen, dass es ein Test ist, und wie lange er voraussichtlich dauern wird. Manche Firewallsysteme können bei jeder Regel sofort ein Verfallsdatum dazuschreiben. ab der die Regel automatisch nicht mehr angewendet wird. Sonst muss man das halt manuell mit Kommentaren im Regelwerk machen. Geht auch.

Scan eingehender Mail auf Malware

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 07 Nov 2008 18:30:43 +0100

Dadurch, dass mein Mailsystem in seiner Eigenschaft als Nichtwindows nicht besonders anfällig gegen Malware ist und ich auch nicht blind auf jeden Anhang klicke, leiste ich mir seit einigen Jahren den Luxus, dass der Clamav auf meinem Mailserver nur die Malware ablehnt, die ich explizit konfiguriert habe. So werde ich die lästigsten Störer automatisch los und habe trotzdem einen Überblick darüber, was im Moment so an Malware unterwegs ist, weil der Clamav natürlich auch Malware, die nicht auf der Reject-Liste steht, markiert.

Es gab zwischendrin eine Zeit, da kam ungefähr gar nichts. So wenig jedenfalls, dass ich ernsthaft darüber nachgedacht habe, die CPU-Zyklen für den Scan eingehender Mail auf Malware einzusparen und den Mailvirenscanner abzuschalten.

Gut, dass ich das nicht gemacht habe, denn in den letzten zwei bis drei Wochen kommt durchaus wieder Malware per Mail in signifikanter Menge (also mehr als zwanzig pro Tag). So hat der Clamav wieder ein wenig mehr zu tun, und ich werde in Zukunft nicht mehr so schnell darüber nachdenken, einen nicht störenden Sicherheitsmechanismus wegen “irrelevant, braucht man heutzutage nicht mehr” abzuschalten.

fail2ban andersrum

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 30 Aug 2008 15:36:08 +0200

Auf einem Webserver möchte ich nicht, dass phpmyadmin, das Dokumentations-Wiki und das awstats von überall verfügbar sind. Andererseits möchte derjenige, der das CMS auf eben dieser Maschine betreut, genau diese Webapplikationen jederzeit und von überall benutzen können. Was tun?

Die erste Idee ist, dem Webmenschen auf der Shell des Servers ein Script bereitzustellen, dass den virtuellen Host für die Utilities per sudo aktiviert und ihn aus dem cron regelmäßig wieder zu deaktivieren. Dann kommt mir die Idee, das ganze beim Login aus dem ~/.profile zu automatisieren. Und wenn wir schon dabei sind, sollen die Utilities auch nur für den Host freigegeben werden, von dem sich der Benutzer gerade eingelogged hat.

Das #!/usr/bin/perl -w, use strict ist schon geschrieben und ich mache mir gerade Gedanken darüber, wie ich das auth.log zur Gewinnung der Quell-IP-Adresse des Logins am besten durchforsten kann (denn dieses File kann potenziell groß sein), da kommt mir der Geistesblitz. Wir haben doch schon einen Daemon, der beim (gehäuften) Auftreten eines bestimmten Logeintrags eine Aktion durchführen kann und diese nach einiger Zeit auch automatisch wieder rückgängig macht: fail2ban macht dies, mit der Intention, eine IP-Adresse zu blockieren, sobald von dieser Adresse zu oft fehlerhafte Loginversuche ausgehen.

Diesmal wollen wir es gerade umgekehrt: Wir wollen einen Dienst für eine IP-Adresse temporär freigeben, sobald ein erfolgreicher Login von dieser Adresse verzeichnet werden konnte. fail2ban widersetzt sich dieser, seiner eigentlichen Intention diametral entgegengesetzten Aufgabe kaum, so dass mit der folgenden Konfiguration das Ziel erreicht wird:

/etc/fail2ban/jail.local:

[ssh-success]

enabled = true
port    = https
filter  = sshd-success
logpath  = /var/log/syslog/auth.log
maxretry = 1
action = iptables-allow[name=%(_name_)s]
bantime = 7200

/etc/fail2ban/action.d/iptables-allow.conf:

[Definition]
actionstart = iptables --new-chain fail2ban-<name>
              iptables --append fail2ban-<name> -j DROP
              iptables --insert INPUT -m state --state NEW --protocol   --dport <port> -j
fail2ban-<name>
actionstop = iptables --delete INPUT -m state --state NEW -p <protocol> --dport
<port> -j fail2ban-<name>
             iptables --flush fail2ban-<name>
             iptables --delete-chain fail2ban-<name>
actioncheck = iptables --list INPUT | grep -q fail2ban-<name>
actionban = iptables -I fail2ban-<name> 1 -s <ip> -j ACCEPT
actionunban = iptables -D fail2ban-<name> -s <ip> -j ACCEPT

[Init]
name = default
port = https
protocol = tcp

/etc/fail2ban/filter.d/sshd-success.conf:

[Definition]
failregex = Accepted publickey for \w+ from  port \d+ ssh2$
ignoreregex =

Dabei kommt mir zu gute, dass ich die Utilities als einzige https-Dienste auf dem System angeboten werden und ich somit radikal mit dem Port arbeiten kann. Theoretisch könnte ich mir aber vorstellen, dass das Verfahren auch dazu geeignet ist, eine .htaccess-Datei mit den entsprechenden allow-Klauseln zu füllen bzw. diese nach einiger Zeit wieder zu entfernen.

Das einzige, was etwas verwirrend ist, ist die Terminologie von fail2ban, das in Konfigurationsdateien und Logs natürlich davon ausgeht, nach fehlgeschlagenen Zugriffen eine Sperre durchzuführen und nach dem Ablauf der Zeit wieder aufzuheben, während es in der Praxis auf einen erfolgreichen Zugriff mit einer Freigabe reagiert:

2008-08-30 11:46:01,544 fail2ban.actions: WARNING [ssh-success] Ban 85.214.68.41
2008-08-30 11:46:08,553 fail2ban.actions: WARNING [ssh-success] Ban 92.227.69.188
2008-08-30 13:46:02,041 fail2ban.actions: WARNING [ssh-success] Unban 85.214.68.41
2008-08-30 13:46:09,049 fail2ban.actions: WARNING [ssh-success] Unban 92.227.69.188

Wenn man sich einmal an die verwirrende Sprache gewöhnt hat, macht fail2ban auch seinen umgekehrten Job ganz gut.

fail2ban fuer ssh fuer Arme

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 28 Apr 2008 15:58:48 +0200

Wer einen Server in einschlägig bekannten Netzwerksegmenten (sprich: Bei den großen Housing-Anbietern) betreibt und wenigstens von Zeit zu Zeit mal in dessen Logs guckt kennt es: Irgendwelche Rechner aus Fernost oder anderswo werfen dem ssh-Daemon wild zusammengewürfelte Kombinationen aus Username und Passwort zu und tun dies mit einer bemerkenswerten Persistenz. Und wenn man auf dem System “fremde” User hat, lebt man als Admin stets mit der Angst, dass einer der Versuche der Angreifer irgendwann mal Erfolg hat.

Gegen diesen Typ der Brute-Force-Angriffe sind einige Wässerchen gewachsen, und ich möchte eine kleine Auswahl davon in diesem Artikel vorstellen.

Möglichkeit 1 ist die sauberste, aber leider nicht immer praktikable: Man schalte Password Authentication im ssh-Daemon ab und authentifiziere sich ausschließlich mit einem public/private-Key-Paar. Dann kommen die Cracker zwar immer noch am System an, man kann die Angriffe aber guten Gewissens ignorieren - sie haben eh keine Chance. Auf den meisten meiner Systeme ist der ssh-Login noch per Einschränkung des Keys (siehe man sshd, AUTHORIZED_KEYS FILE FORMAT, from=“”) und per tcp-wrapper (/etc/hosts.deny: sshd: ALL oder ALL: ALL) so zugenagelt, dass der Login nur von einigen meiner üblichen Aufenthaltsorte möglich ist - dank OpenVPN und/oder festen IP-Adressen kann man sich hier noch etwas verschanzen. Auf Systemen, die sowieso einen Paketfilter haben, ist auch im Paketfilter der Zugang zum ssh-Port auf die kurze Liste von IP-Adressen beschränkt.

Möglichkeit 2 ist security by obscurity: Man verschiebe den ssh-Daemon auf einen anderen Port. Die Cracker gehen davon aus, es mit ungepflegten Systemen in Standardkonfiguration zu tun zu haben und suchen nur auf tcp/22 nach dem sshd. Dann ist schlagartig Ruhe im Log; dafür hat man dann Schmerzen dort, wo schon jemand anders eine Freischaltung für tcp/22 durchgeboxt hat und man nun denselben Kampf mit dem Firewall-Admin für “seinen” Spezial-ssh-Port führen darf.

Möglichkeit 3 heißt fail2ban. Das ist ein in python (*würg*) geschriebener Userspace-Daemon, der in konfigurierbaren Logfiles nach konfigurierbaren Regexps sucht, die Logfiles auch beim Wachsen beobachtet und bei konfigurierbar gehäuftem Auftreten von auf diese Regexps matchenden Logeinträgen eine konfigurierbare Operation durchführt und diese nach konfigurierbarer Zeit wieder rückgängig macht. In der Defaultkonfiguration wird /var/log/auth.log auf “ROOT LOGIN REFUSED”, “Authentication failure”, “Failed foo for bar” und ähnliches gemonitored und im Falle des gehäuften Auftretens ein “iptables -I fail2ban-<name> 1 -s <ip> -j DROP” ausgeführt, d.h. alle weiteren Zugriffe von dieser IP-Adresse schon im Paketfilter verworfen. Das ist was feines, erzeugt keine Fehlalarme, braucht aber einen Userspace-Daemon in einer von mir ungeliebten Programmiersprache.

Da mir fail2ban nicht so wirklich zusagt, habe ich mir Möglichkeit 4 ausgedacht, die keine Zusatzsoftware benötigt, sondern mit dem in neueren Kerneln enthaltenen hashlimit match von iptables arbeitet und somit die ganze Geschichte direkt im Paketfilter abfackeln kann.

Hier ein Beispiel in der Notation von ferm:

def $SECONDS=600;
def $HITCOUNT=5;
def $LOGLIMIT=“3/minute”;
def $LOGBURST=10;
def $BLOCKSECONDS=600;

table filter {
  chain INPUT {
    mod state state NEW proto tcp dport 22 subchain {
      # all new tcp connections to port 22

      # insert into recent table
      mod recent
        name sshratelimit set NOP;

      # if excessive, log and drop
      mod recent
        name sshratelimit update seconds $SECONDS hitcount $HITCOUNT subchain {
          mod hashlimit
            hashlimit $LOGLIMIT hashlimit-burst $LOGBURST
            hashlimit-mode srcip hashlimit-name sshratelimit1
          LOG log-prefix “sshratelimit1 ”;
          DROP;
      }
    }

    # if a host has been recorded for excessive ssh connects, drop and
    # log everything from there
    mod recent
      name sshratelimit rcheck seconds $BLOCKSECONDS hitcount $HITCOUNT subchain {
        mod hashlimit
          hashlimit $LOGLIMIT hashlimit-burst $LOGBURST
          hashlimit-mode srcip hashlimit-name sshratelimit2
        LOG log-prefix “sshratelimit2 ”;
        DROP;
      }
  }
}

Dieser Code schickt erstmal alle Pakete, die eine neue TCP-Verbindung zu Port 22 aufmachen wollen, in eine Subchain. In dieser Subchain werden alle Pakete über den “recent” match in eine Hashtabelle aufgenommen und im nächsten Schritt jedes Paket, das über $HITCOUNT innerhalb $SECONDS eingeht, mit einem Limit zur Vermeidung von Log-DoS gelogged und dann ohne Limit verworfen. Der zweite Abschnitt sorgt dafür, dass jeglicher Traffic von einem Host, der es einmal in den Zustand “block” geschafft hat, ebenfalls limitiert gelogged und dann ebenfalls verworfen wird.

Im Log sieht das dann so aus:

Apr 27 10:25:23 q ippl: port 22 connection attempt from 61.237.230.6 (61.237.230.6:52070->84.16.252.249:22)
Apr 27 10:25:28 q sshd[20642]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=61.237.230.6  user=root
Apr 27 10:25:31 q sshd[20642]: Failed password for root from 61.237.230.6 port 52070 ssh2
Apr 27 10:25:31 q ippl: port 22 connection attempt from 61.237.230.6 (61.237.230.6:52242->84.16.252.249:22)
Apr 27 10:25:37 q sshd[20648]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=61.237.230.6  user=root
Apr 27 10:25:39 q sshd[20648]: Failed password for root from 61.237.230.6 port 52242 ssh2
Apr 27 10:25:39 q ippl: port 22 connection attempt from 61.237.230.6 (61.237.230.6:52408->84.16.252.249:22)
Apr 27 10:25:45 q sshd[20659]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=61.237.230.6  user=root
Apr 27 10:25:47 q sshd[20659]: Failed password for root from 61.237.230.6 port 52408 ssh2
Apr 27 10:25:47 q ippl: port 22 connection attempt from 61.237.230.6 (61.237.230.6:52575->84.16.252.249:22)
Apr 27 10:25:53 q sshd[20665]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=61.237.230.6  user=root
Apr 27 10:25:55 q sshd[20665]: Failed password for root from 61.237.230.6 port 52575 ssh2
Apr 27 10:25:55 q kernel: sshratelimit1 IN=eth0 OUT= MAC=00:02:a5:79:45:3a:00:0c:db:eb:dc:40:08:00 SRC=61.237.230.6
DST=84.16.252.249 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=58324 PROTO=TCP SPT=52749 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Apr 27 10:25:56 q kernel: sshratelimit2 IN=eth0 OUT= MAC=00:02:a5:79:45:3a:00:0c:db:eb:dc:40:08:00 SRC=61.237.230.6
DST=84.16.252.249 LEN=52 TOS=0x00 PREC=0x20 TTL=49 ID=50655 PROTO=TCP SPT=52575 DPT=22 WINDOW=136 RES=0x00 ACK URGP=0
Apr 27 10:25:57 q kernel: sshratelimit2 IN=eth0 OUT= MAC=00:02:a5:79:45:3a:00:0c:db:eb:dc:40:08:00 SRC=61.237.230.6
DST=84.16.252.249 LEN=52 TOS=0x00 PREC=0x20 TTL=49 ID=0 PROTO=TCP SPT=52575 DPT=22 WINDOW=136 RES=0x00 ACK URGP=0
Apr 27 10:25:58 q kernel: sshratelimit1 IN=eth0 OUT= MAC=00:02:a5:79:45:3a:00:0c:db:eb:dc:40:08:00 SRC=61.237.230.6
DST=84.16.252.249 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=58325 PROTO=TCP SPT=52749 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Apr 27 10:26:00 q kernel: sshratelimit2 IN=eth0 OUT= MAC=00:02:a5:79:45:3a:00:0c:db:eb:dc:40:08:00 SRC=61.237.230.6
DST=84.16.252.249 LEN=52 TOS=0x00 PREC=0x20 TTL=49 ID=0 PROTO=TCP SPT=52575 DPT=22 WINDOW=136 RES=0x00 ACK URGP=0
Apr 27 10:26:04 q kernel: sshratelimit1 IN=eth0 OUT= MAC=00:02:a5:79:45:3a:00:0c:db:eb:dc:40:08:00 SRC=61.237.230.6
DST=84.16.252.249 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=58326 PROTO=TCP SPT=52749 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

Man sieht hier sehr schön, wie der angreifende Zombie aus dem China Railway Telecommunications Center mit seinen Root-Login-Versuchen viermal am sshd selbst abprallt, bevor der Paketfilter zuerst mit sshratelimit1 verkündet, dass er jetzt zu viele ssh-Verbindungsversuche gesehen hat, und in Zukunft weitere Versuche mit sshratelimit2 ohne weitere Prüfung verwirft. Man sieht hier zwar nur ssh-Zugriffe, aber ein intelligenterer Angreifer könnte ja zeitgleich versuchen, andere Dienste auf dem Host anzugreifen.

Natürlich hat dieses Setup auch Nachteile: Es zählt jeden ssh-Verbindungsversuch - auch die erfolgreichen - und sperrt somit auch legitime User aus, die zu häufig connecten. Besonders auf Systemen, bei denen öfter mal Prozesse extern per ssh angestoßen werden, oder bei denen scp verwendet wird (das für jede Datei eine neue Verbindung öffnet), erzeugt man mit der hashlimit-Lösung schon mal ein false positive. Aber dafür kommt es ohne Userspace und vor allen Dingen ohne python aus.

Dieses Setup habe ich jetzt seit etwa einem halben Jahr auf einem meiner Mehrbenutzerrechner in Betrieb und habe noch keine Beschwerden gehört. Ich denke, es ist eine sparsame und brauchbare Alternative zu einer aufwendigeren Lösung wie fail2ban und werde es in den nächsten Wochen auf den restlichen Systemen ausrollen, die aufgrund ihrer Dienst- und Userstruktur nicht mit Security nach Möglichkeit 1 versorgt werden können.

PKI-loses TLS

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 05 Jan 2008 13:00:19 +0100

Florian hat im April 2007 eine Notiz über PKI-loses TLS unter Verwendung von selbstsignierten Zertifikaten veröffentlicht. Er ist ja immer für provokative Aussagen gut, und in der Notiz erklärt er seine Beweggründe gut und hat bei mir einen Denkprozess ausgelöst.

Ich werd das in den nächsten Monaten mal für den einen oder anderen Dienst, z.B. OpenVPN, ausprobieren und gucken, ob dieser Ansatz in der Praxis funktionieren könnte. Für die Anwendung im Webumfeld sehe ich ja eher schwarz, weil dank der verDAUung des Internets ein https-Server mit selbstsigniertem Zertifikat gemeinhin als unsicherer angesehen wird wie ein Server mit unverschlüsseltem http. Weil bei Ersterem der Browser weint, und bei Zweiterem nicht.

Funktastaturen sind immer noch böse

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 01 Dec 2007 17:39:20 +0100

Funktastaturen sind dafür, dass sie gegenüber klassischen Tastaturen eigentlich nur Nachteile haben, erschreckend weit verbreitet. Sie sind nur unwesentlich weniger unhandlich wie kabelgebundene TastBaturen, fressen dafür Batterien wie blöde, verringern den Kabelsalat nicht - und unsicher sind sie oft auch.

Funktastaturen sind besonders im Firmenumfeld fast ausschließlich dort zu finden, wo mit vertraulichen Strategiedaten umgegangen wird, nämlich in der Chefetage. Dort sind die Informationen, die tagein, tagaus in die Tastaturen gehämmert werden, in aller Regel sensibler als dort, wo es aus Kostengründen keine Funktastaturen gibt (sie aber eventuell sinnvoller wären). Schließlich erwartet man gerade von den großen Herstellern mit L und mit M, dass sie sich ein Mindestmaß über die Vertraulichkeit der über die meist proprietären Funkstrecken Gedanken machen.

Schon vor fünf Jahren konnten meine Kollegen mit ihren L-Tastaturen die Eingaben der Firma eine Etage höher abgreifen, und laut heise online hat es jetzt die mit einem dem Stand der Technik von 1540 entsprechenden 8-Bit-XOR-Schlüssel gesicherten Funktastaturen von M erwischt. So eine “Verschlüsselung” reicht gerade, um dem Laien zu zeigen, dass da keine Klartextdaten über die Luftschnittstelle gehen; einem mit unterdurchschnittlicher Energie ankommenden Angreifer hält so eine “Sicherheit” geschätzt dreieinhalb Sekunden stand, und dann liegen alle getippten Passworte und Buchhaltungsdaten dem Mithörer weit offen.

Und so muss meine Empfehlung weiterhin lauten: Finger weg von Funktastaturen. Und wenn es partout ein Statussymbol sein muss, oder der Einsatz einer Funktastatur ausnahmsweise mal Sinn und Zweck haben (z.B. bei einem Entertainment-PC, den man auch vom Sofa aus bedienen können will), sollte man wenigstens das Geld für eine Bluetooth-Tastatur in die Hand nehmen: Das ist ein offener Standard, dessen Sicherheit zwar nicht berauschend gut ist, aber eine derartige Peinlichkeit, wie sie sich Vendor M mit seinen Produkten geleistet hat, ist dort eher nicht zu erwarten.

Ach ja, übrigens: Wenn Ihr mich richtig ärgern wollt, nehmt mir meine kabellose Maus weg. Besonders mit Bluetooth ist das Klasse, wenn das Notebook das Bluetooth-Interface bereits eingebaut hat und man am Notebook überhaupt nichts einstöpseln muss und die Maus trotzdem einfach funktioniert. Aber das Konzept war wohl zu einfach und nicht proprietär genug, denn Vendor L hat die MX 900 schon vor vielen Monaten aus dem Programm genommen.

Serendipity 1.0.2 fixes XSS vulnerability

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 19 Oct 2006 19:01:35 +0200

Hallo Dirk, zu Deinem Artikel möchte ich noch hinzufügen, dass Serendipity 1.0.2 ein Security-Update ist, das XSS Vulnerabilities behebt.

Man möchte dieses Update also nicht verzögern, sondern unverzüglich installieren!

Berufsverbot

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 21 Sep 2006 10:38:28 +0200

Das Bundesministerium der Justiz bereitet einen Gesetzentwurf vor, der den Schutz vor Computerkriminalität mit strafrechtlichen Maßnahmen verbessern soll. Und handelt Deutschland erneut den Verlust von zahlreichen hochqualifizierten Arbeitsplätzen im Hochtechnologiesektor ein.

Der Gesetzentwurf zur Änderung des StGB fügt einen neuen Paragrafen 202 c “Vorbereiten des Ausspähens und Abfangens von Daten” in das Strafgesetzbuch ein.

Wer eine Straftat nach § 202 a oder § 202 b vorbereitet, indem er

Passworte oder sonstige Sicherungscodes, die den Zugang zu Daten (§ 202 a Abs. 2) ermöglichen, oder

Computerprogramme, deren Zweck die Begehung einer solchen Tat ist, herstellt, sich oder einem anderen verschafft, verkauft, einem anderen überlässt, verbreitet oder sonst zugänglich macht,

wird mit Freiheitsstrafe bis zu einem Jahr oder mit Geldstrafe bestraft.

§ 202 a ist heute schon “Ausspähen von Daten”; § 202 b wird “Abfangen von Daten”.

Es wird also in Zukunft verboten sein,

Proof of Concepts für Schwachstellenausnutzung zu erstellen (“herstellen”)
Bugtraq, Full Disclosure oder ähnliche Mailinglisten auch nur abonniert zu haben (“sich verschaffen”)
Schwachstellenanalysen durchzuführen (da man sich vorher Tools entweder verschaffen oder herstellen muss)
“Live Hacking” als Schockeffekt in Seminaren (“sonst zugänglich machen”)
Linux-Distributionen, die nmap oder nessus enthalten zum Download bereitzuhalten (“verbreiten”)

Was bleibt einem Security-Consultant in Deutschland dann noch als Arbeitsmöglichkeiten offen?

Ich glaube, ich muss doch auf Schafzucht oder Lokführer umsatteln. Qualifizierte Arbeitsplätze sind in Deutschland wohl unerwünscht.

Sind Firewalls noch zeitgemäß?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 19 Jul 2006 13:55:36 +0200

Die meisten restriktiven Security Policies haben inzwischen ein Alter von drei bis fünf Jahren erreicht. Damals hat man das als Policy niedergelegt, was im gerade führenden Fachbuch stand, und somit auch schon einige Jahre auf dem Buckel hatte. Auf solch einer alten Policy aufgesetzte Sicherheitsmaßnahmen, die typischerweise das böse Internet mit einer (!) Firewall von dem einen (!) internen Netz abtrennen und bestenfalls eine kleine Handvoll Servicenetze (vulgo “DMZ”, wobei “mehr als ein Servicenetz” immer noch mit “Respekt! Das ist aber gut durchdacht!” kommentiert wird) beinhalten, sind in der heutigen Welt kaum mehr zeitgemäß; es ist Zeit, hier anzusetzen.

Mit Policies auf dem technischen Stand von vor fünf Jahren ist heute ein messbarer Sicherheitsgewinn kaum mehr erreichbar. Zu sehr verschwimmen in den letzten Jahren die Netzgrenzen, werden durch Inter-, Extra- und Intranet, VPN-Tunnel, UMTS, Wireless LAN, Mobile Devices, Suspendmodi und andere Dinge immer weiter aufgeweicht, so dass eine einzige klassische Firewall am Unternehmenseingang heute nicht mehr zeitgemäß ist. Mit solchen Lösungen erreicht man nur, dass die Leute, die die Arbeit machen, bei ihrer Leistungserbringung massiv behindert werden, was die IT-Kosten in ihrer Gesamtheit in astronomische Höhen treibt. Außerdem bauen die Leistungsträger sich in so einer Umgebung policykonforme Workarounds, die nur deswegen policykonform sind, weil es sie zum Zeitpunkt der Policyerstellung schlicht noch nicht gab und sie deswegen in der Policy nicht verboten sind. Interessant finde ich übrigens, dass es kaum eine Security Policy gibt, die die in der Technik seit 20 Jahren übliche Maxime “Es ist alles verboten, was nicht ausdrücklich erlaubt ist” (vulgo “default deny”) zur Grundlage hat. Nein, die meisten Policies ergehen sich in seitenlangen Listen von Dingen, die bei sofortiger Entleibung niemalsnie passieren dürfen. Das Ergebnis ist der GAU: Hohe Kosten bei nur mäßigem Sicherheitsniveau.

Nun, wie schon so oft: Kris Köhntopp hat das schon vor Jahren ausgeforscht. Seine Präsentation über Mobile Devices spricht mir aus der Seele, und er hat natürlich Recht. Besonders seine Aussage, dass die Benutzer immer kreativer werden, je restriktiver die Policy ist, ist eine viel zu selten in dieser Deutlichkeit ausgesprochene Wahrheit.

Was lernen wir daraus? Eine Security Policy ist nur dann sinnvoll, wenn man sie aktuell hält. Wobei “aktuell” nicht nur heißt, dass man die technischen Weiterentwicklungen, die den Sinn der alten Policy in Frage stellen, verbietet - nein, das wird man eh nicht durchhalten können, weil viele dieser technischen Weiterentwicklungen als Spielzeug für die Entscheider taugen und man deren Verbot deswegen eh nicht wird durchhalten können. Es ist vielmehr sinnvoll, die existierende Policy in regelmäßigen Abständen - am besten innerhalb eines formellen Review-Prozesses - zu hinterfragen und zu modernisieren. Das bedeutet freilich auch, dass manche Verbote aufgehoben oder abgeschwächt gehören und man sich nach anderen Wegen zur Reduktion des Risikos umsehen muss. Die Security wird in den nächsten Jahren wieder näher an die Daten selbst, also an die Server, heranrücken müssen, und dafür wird Geld in die Hand genomen werden müssen. Als Belohnung winken schneller ablaufende, weniger kostende IT-Projekte in der Zukunft.

Viele Unternehmen werden externen Rat nötig haben, und zwar sowohl im Prozess der Policyanpassung als auch bei der Umsetzung der neuen Policy. Es wird viel zu tun geben - fragen Sie bitte jemanden, der sich auskennt!

Microsoft über den Umgang mit kompromittierten Systemen

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 21 May 2006 09:06:42 +0200

Im Microsoft Technet stehen von Zeit zu Zeit echte Perlen. Aber die hier ist so gut (und so wahr), dass ich sie sogar hier zitieren muss.

Jesper M. Johansson, Ph.D., CISSP, MCSE, MCP+I, seines Zeichens Security Program Manager bei der Microsoft Corporation, schreibt in einem Artikel mit dem Titel “Help: I Got Hacked. Now What Do I Do?” aus dem Mai 2004:

You can’t clean a compromised system by patching it. Patching only removes the vulnerability. Upon getting into your system, the attacker probably ensured that there were several other ways to get back in.
You can’t clean a compromised system by removing the back doors. You can never guarantee that you found all the back doors the attacker put in. The fact that you can’t find any more may only mean you don’t know where to look, or that the system is so compromised that what you are seeing is not actually what is there.
You can’t clean a compromised system by using some “vulnerability remover.” Let’s say you had a system hit by Blaster. A number of vendors (including Microsoft) published vulnerability removers for Blaster. Can you trust a system that had Blaster after the tool is run? I wouldn’t. If the system was vulnerable to Blaster, it was also vulnerable to a number of other attacks. Can you guarantee that none of those have been run against it? I didn’t think so.
You can’t clean a compromised system by using a virus scanner. To tell you the truth, a fully compromised system can’t be trusted. Even virus scanners must at some level rely on the system to not lie to them. If they ask whether a particular file is present, the attacker may simply have a tool in place that lies about it. Note that if you can guarantee that the only thing that compromised the system was a particular virus or worm and you know that this virus has no back doors associated with it, and the vulnerability used by the virus was not available remotely, then a virus scanner can be used to clean the system. For example, the vast majority of e-mail worms rely on a user opening an attachment. In this particular case, it is possible that the only infection on the system is the one that came from the attachment containing the worm. However, if the vulnerability used by the worm was available remotely without user action, then you can’t guarantee that the worm was the only thing that used that vulnerability. It is entirely possible that something else used the same vulnerability. In this case, you can’t just patch the system.
You can’t clean a compromised system by reinstalling the operating system over the existing installation. Again, the attacker may very well have tools in place that tell the installer lies. If that happens, the installer may not actually remove the compromised files. In addition, the attacker may also have put back doors in non-operating system components.
You can’t trust any data copied from a compromised system. Once an attacker gets into a system, all the data on it may be modified. In the best-case scenario, copying data off a compromised system and putting it on a clean system will give you potentially untrustworthy data. In the worst-case scenario, you may actually have copied a back door hidden in the data.
You can’t trust the event logs on a compromised system. Upon gaining full access to a system, it is simple for an attacker to modify the event logs on that system to cover any tracks. If you rely on the event logs to tell you what has been done to your system, you may just be reading what the attacker wants you to read.
You may not be able to trust your latest backup. How can you tell when the original attack took place? The event logs cannot be trusted to tell you. Without that knowledge, your latest backup is useless. It may be a backup that includes all the back doors currently on the system.
The only way to clean a compromised system is to flatten and rebuild. That’s right. If you have a system that has been completely compromised, the only thing you can do is to flatten the system (reformat the system disk) and rebuild it from scratch (reinstall Windows and your applications). Alternatively, you could of course work on your resume instead, but I don’t want to see you doing that.

Ein weiser Mann. Ich wünsche mir, dass einige Manager in Zukunft auf diesen weisen Mann hören.

Gefunden hab ich das übrigens bei Dirk, und der hat’s von El Loco.

Trennung von Webapplikationen mit Extrainstanzen des Apache

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 18 Feb 2006 16:21:24 +0100

Die Artikelreihe zum Thema “Trennung von Webanwendungen untereinander”, die mit fastcgi, suphp und zwei Artikeln über das klassische suexec begann, findet heute ihren vorläufigen Abschluss mit dem Setup, für das ich mich letztendlich entschieden habe.

Da auf dem von mir angepeilten Zielsystem nur eine Handvoll Präsenzen mit ähnlich wenigen verschiedenen Webanwendungen ins Hosting kommen wird, könnte ich mich für eine Lösung entscheiden, deren Skalierungsverhalten sie für “richtiges” Hosting uninteressant macht. Jede Webapplikation bekommt einen eigenen apache, der gleich unter einer nicht priviligierten uid gestartet wird und auf einem hohen Port von 127.0.0.1 Verbindungen annimmt. Das Mapping auf die “offizielle” IP und Port 80 übernimmt ein zentraler “normaler” apache als reverse proxy.

Dieser Artikel entstand ursprünglich im Jahr 2006. Fünf Jahre später hat auch Debian es geschafft, mehrere apache-Instanzen “ordentlich” zu unterstützen, und ganz ohne gepatchte Scripts. Diese überarbeitete Version dieses Artikels beschreibt die Vorgehensweise unter dem in 2011 aktuellen Debian squeeze.

Das ganze Verfahren unter Debian stable mit apache2 zu implementieren war verhältnismäßig einfach. Ich habe mich bemüht, die Arbeit der Debian-Maintainer so weit wie möglich zu nutzen, da mir das Packaging von apache2 außerordentlich gut gefällt. Also sind ein patch gegen apache2ctl, ein kompletter Rewrite von a2[en|dis][mod|site] und ein severely patched initscript dabei rausgekommen, mit deren Hilfe das Management der vielen verschiedenen Apaches einfach geworden ist. Debian hat meine Patches natürlich nicht 1:1 übernommen, aber inzwischen geht es auch ohne gepatchte scripts.

Auf dem Zielsystem setzen wir das Verfahren wie folgt ein:

Jeder Apache bekommt einen eigenen Unix-User (user-appname) mit eigenem Homedirectory.
In diesem Homedirectory kann der User nicht schreiben, die Dateien dort gehören user:user-webapps
unter /home/user-appname/apache wird eine abgespeckte Apache-Konfiguration hinterlegt, in der auch konfiguriert ist, dass der apache untr dem Account user-appname laufen und auf einem hohen Port unter 127.0.0.1 horchen soll.
Diese Konfiguration wird nach /etc/apache2-user verlinkt
Ein spezielles Initscript /etc/init.d/apache2-user wird aus /usr/share/doc/apache2.2-common/examples/secondary-init-script (z.B. mit /usr/share/doc/apache2.2-common/examples/setup-instance) erzeugt
Mit insserv apache2-user wird das Initscript aktiviert und an der passenden Stelle in die dependency-based Bootreihenfolge eingehängt
Die Applikation liegt in /home/user-appname/applikation.
Apache-Module lassen sich mit dem erweiterten a2enmod einfach lokal aktivieren.
Der Apache lässt sich dann mit dem erweiterten Initscript einfach unabhängig von den anderen apaches starten.
Der “Haupt-Apache” wird per ProxyPass und ProxyPassReverse so konfiguriert, dass Zugriffe auf den entsprechenden Namensraum zum “richtigen” User-apache weitergereicht werden.

mod_rpaf sorgt in den Applikations-Apachen dafür, dass die vom Proxy übermittelten Client-IPs in den Logs landen und IP-basierte Auswertungsmechanismen (z.B. zur Spamabwehr) funktionieren.

Auf diese Weise ist sichergestellt, dass die Webapplikationen getrennt voneinander laufen. Per Rechtevergabe im Dateisystem kann man nun erreichen, dass eine Webapplikation nur dort lesen und schreiben kann, wo es unbedingt notwendig ist. Die apache-Konfiguration kann entsprechend abgespeckt sein.

Diese Lösung hat natürlich auch ein paar Nachteile, zum Beispiel den exorbitanten Speicherbedarf duch die wirlich vielen apache-Prozesse im Speicher und die Tatsache, dass manche Webapplikationen sich herausgefordert fühlen, wenn plötzlich Portnummern in den URLs stehen und der Client mit anderen URIs kommt als man selbst weggeschickt hat. Weitere Nachteile sind mir in den fünf Jahren, die das Setup auf dem Zielsystem so bereits in Verwendung ist, bis heute nicht aufgefallen.

Wenn die Applikation Cookies benutzt, ist zu beachten, dass die Applikation ihre Cookies mit einer Domain versieht, und zwar in der Regel mit 127.0.0.1:x, weil der Applikations-Apache nicht weiß, unter welchem Domainnamen der Server letztendlich läuft. Das hat mich mit meinem Blog einige Tage Debuggingarbeit gekostet, und ohne die Hilfe von Garvin, Isotopp, Rince und anderem wäre das niemals erfolgreich gewesen.

Die Lösung ist in der Konfiguration des Reverse Proxy:

ProxyPassReverseCookieDomain 127.0.0.1:1312 blog.zugschlus.de 
ProxyPassReverseCookieDomain 127.0.0.1 blog.zugschlus.de

Der doppelte ProxyPassReverseCookieDomain ist nötig, weil aus irgendwelchen gründen manche Cookies mit und manche ohne Portnummer gesendet werden.

virtually exploitable

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 19 Jan 2006 09:59:42 +0100

Seit Jahren schon unke ich darüber, dass Virtualisierung a la vmware, Xen und Co zwar sehr kostensenkend und vereinfachend sein kann, aber mit einer Reduktion des Sicherheitsniveaus einhergeht. Und auch seit Jahren werde ich dafür belächelt und die virtuelle Umgebung trotzdem weiter ausgerollt.

So erfüllt es mich mit wenigstens etwas Befriedigung, dass der von mir vorhergesagte Fall inzwischen eingetreten ist: Durch einen Buffer Overflow im vmware-NAT-Treiber ist - sowohl unter Linux als auch unter Windows - die Übernahme des Gastgebersystems möglich. Und da dieser Treiber ziemlich weit unten im Gastsystem eingreift, gibt’s die root- und/oder Administratorprivilegien gratis und franko gleich dazu. Dazu, dass dieser Exploit ausgerechnet (oder
erwartungsgemäß?) die kommerzielle Virtualisierungsvariante vmware betrifft, sag ich lieber nichts, denn die entsprechende Lücke in einer der freien Alternativen kommt bestimmt.

vmware hat gepatched und eine korrigierte Version ohne diese Schwachstelle herausgegeben, die alle vmware-Admins nun bitte schnellstmöglich auf ihre Systeme ausrollen mögen.

Es bleibt das etwas schale Gefühl, Recht gehabt zu haben mit der Unkerei. Gut tun tut das irgendwie nicht.

fastcgi

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 30 Dec 2005 14:18:31 +0100

In Fortsetzung der Artikelreihe zur Entfernung von PHP-Scripts aus dem Accountkontext des Webservers ist heute FastCGI an der Reihe.

Kurzzusammenfassung aus der Theorie: Es ist vermutlich performanter als suexec und suphp, bringt aber weder Erleichterung in der Handhabung noch in der Sicherheit.

In diesem Artikel bekommt auch das debianhowto.de apache2-php-fcgi-HOWTO sein Fett weg.

Auf der Suche nach Dokumentation zu diesem Thema landet man recht schnell beim
debianhowto.de HOWTO für apache2 mit PHP 4/5 als FastCGI. Mit den Jungs von Debianhowto bin ich ja in der Vergangenheit schon einmal aneinander geraten, aber im Vergleich zu diesem Machwerk ist das exim4-vexim-HOWTO gerade noch harmlos.

Das HOWTO ist ein reines HOWTO im “übelsten” Sinne: Es wird mit kaum einem Wort erklärt, was die 1:1 abtippbaren Dinge überhaupt machen. Damit mag man vielleicht schnell ans Ziel kommen, aber sobald man aus irgend welchen Gründen vom Weg des HOWTO abweichen muss, wird man mangels Hintergrundwissen auf die Schnauze fallen. Einige Fallen sind zwar im HOWTO erwähnt, aber ich finde es sportlich, dass man davon ausgeht, dass jeder, der jemals in Zukunft mit dem so eingerichteten System arbeiten wird, auch mit dem HOWTO vertraut ist.

Vorteile von PHP per FastCGI:

PHP mit FastCGI ist thread safe, das apache2 worker-mpm wird einsetzbar.
Dadurch, dass - wie bei mod_php - der PHP-Interpreter geladen bleibt, ist die Performanz besser als bei suexec oder suphp, wo der PHP-Interpeter als CGI läuft und für jeden Aufruf neu geladen und initialisiert werden muss. Bei FastCGI erfolgt dies allerdings nicht auf einer per-Webserver, sondern auf einer per-Vhost-Basis, so dass die geladenen Interpreter mit den richtigen Benutzerrechten laufen können.

Nachteile

mod_fastcgi steht unter einer seltsamen Lizenz, die im Debian-Projekt unter non-free geführt wird. Das bedeutet, dass es für mod_fastcgi nicht den aus Debian gewöhnten guten Support gibt.
Der Benutzerkontextwechsel wird mit mod_suexec erreicht und hat somit alle Nachteile, die suexec mit sich bringt.
mod_fastcgi ist in der Version 2.4.2 (Debian stable, testing, unstable, Stand 2005/12) fehlerhaft und funktioniert nicht mit apache. Es ist also derzeit der Einsatz eines Development-Snapshots notwendig. Wirklich maintained sieht mod_fastcgi ausserdem nicht aus, der letzte Release ist aus dem Jahr 2003, der “aktuelle” Development-Snapshot aus dem April 2004.

Probleme, die ich mit dem HOWTO sehe

Die Zusammenhänge werden so gut wie gar nicht erklärt.
Ebenso wird nicht erklärt, was die einzelnen Konfigurationsschritte nun wirklich tun.
Es wird genau erklärt, wie man sich ein eigenes PHP5 baut, ohne dass darauf hingewiesen wird, dass man auf diese Weise den Support von Debian verliert. Immerhin wird der User dazu angehalten, sein lokales PHP nach $HOME zu installieren, und bei der Anleitung zur Installation der inoffiziellen PHP5-Pakete fehlt auch der Hinweis auf den mangelnden Security-Support nicht.
Die Aussage, dass es kein fcgi-enabletes php4-cgi in Debian sarge gibt, halte ich für falsch. Zumindest erhalte ich beim Aufruf von php4-cgi -i auf einem Debian sarge die Ausgabe “ServerAPI: CGI/FastCGI”.
Der “aktuelle” Development-Snapshot wird von den HOWTO-Usern ohne Sonderprefix unter Umgehung des Packagesystems direkt nach /usr geballert.
Weiter unten wird erwähnt, dass es in Debian sarge ein libapache2-mod-fastcgi gibt. Das ist allerdings genau die fehlerhafte Version 2.4.2, die laut der Aussage zwei Bildschirmseiten weiter oben “nicht funktioniert”, leider ohne weitere Erklärung des Fehlverhaltens.
Von a2enmod und a2ensite scheint der HOWTO-Autor nix zu wissen
Später wird mit dem Immuteable-Bit hantiert, und hier wird’s dann vollends gefährlich.
- Arbeitet man auf einem Filesystem, das das Immuteable-Bit unterstützt, ist die Aktion noch halbwegs sauber.
- Böse Falle für Leute, die später das System in die Hand bekommen ist, dass Kopieren des Dateibaums des virtuellen Hosts das Immuteable-Bit nicht mitkopiert. Sprich: In einem simpel mit cp -a kopierten Baum fehler dieses Bit auf den betroffenen Dateien, was ein riesengroßes Sicherheitsloch aufreißt. Das ist zwar im HOWTO klar erklärt, aber wie gesagt - derjenige, der den Dateibaum kopiert, muss nicht notwendigerweise das HOWTO gelesen oder gar verstanden haben.
- Für Filesysteme, die das immuteable-Bit nicht unterstützen, legt das HOWTO dem Benutzer nahe, suexec zu patchen, und liefert eine idiotensichere Anleitung mit, wie das getan werden kann. Dabei werden zwar die Debian-Sourcen verwendet, aber das entstehende Binary wird natürlich wieder manuell an die passende Stelle im Dateisystem geschoben - erneut unter Umgehung des Packagesystems. Ich möchte kein System in die Finger bekommen, das auf diese Weise so verhunzt wurde. Übel. Immerhin - das neu gebaute, unsicherere suexec wird nicht benutzt um das “Original-suexec” zu überschreiben, sondern erhält einen eigenen Dateinamen, suexec-fcgi, was den Knieschusseffekt dieser Operation wenigstens etwas dämpft.
Ich würde mich wundern, wenn die Verwendung von Documentroots ausserhalb /var/www für die Benutzer dieses HOWTOs funktioniert. Das Debian-suexec ist relativ strikt übersetzt, und dieser Fall ist im HOWTO mit keinem Wort erwähnt. Für Newbies - mithin die Hauptzielgruppe des HOWTO - ist das eine böse Falle.

Bitte, bitte, bitte. Lest Eure Texte bevor ihr sie veröffentlicht. Schreibt kurze, prägnante Sätze, vermeidet Umgangssprache, schreibt Zahlen zwischen eins und zwölf als Worte. Technische Dokumentation verdient besseres Deutsch!

Fazit: Debianhowto.de ist in meiner Achtung wieder ein Stück gesunken, die von mir erhoffte Standardlösung für ein Standardproblem habe ich immer noch nicht gefunden.

Demnächst in diesem Theater: Für jede PHP-Applikation einen eigenen Apache.

suphp

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 11 Dec 2005 21:59:38 +0100

Schon bei den Vorarbeiten zu diesem und diesem Artikel hat man mir sehr nahegelegt, suphp anzugucken. Das habe ich heute getan.

Suphp kommt als Apache-Modul in der Debian-Package libapache2-mod-suphp daher. In Sarge ist eine 0.5-Version; in sid eine 0.6.0-Version, die zur Laufzeit flexibler konfigurierbar ist. Upstream hat vor zwei Wochen eine 0.6.1 released, die bisher noch nicht ihren Weg nach Debian gefunden hat.

suphp tut auf Anhieb das, was man von ihm erwartet: Das php-Script läuft mit den Rechten des Dateiinhabers. Die Überraschungen sind im Detail, und ich weiss noch nicht genau, was ich darüber denken soll.

suphp ist wie suexec ein suid root laufendes Binary, das seine Rootrechte - wie suexec - zuerst zum Zieluser fallen lässt, und dann den php4-Interpreter aufruft. Daraus folgt:

Der PHP-Interpreter läuft nicht als Apache-Modul

libapache2-mod-php kann raus. Beziehungsweise: Es muss raus, denn der Parallelbetrieb von mod-php und suphp ist nicht unterstützt. Es kann laut Aussage des Upstreams alles passieren. Also lieber nicht machen.

suphp ist erheblich weniger pingelig als suexec. Das erleichtert zwar die Arbeit erheblich, weil es sofort so tut wie erwartet, aber über den damit eingehandelten Sicherheitskompromiss muss ich mir erstmal klar werden.

Die bei suphp 0.5 mitgelieferte Dokumentation ist die vom Upstream, die davon ausgeht, dass das Modul mit --with-setid-mode=force oder =paranoid übersetzt wurde. Die Debian-Package ist aber mit --with-setid-mode=owner gebaut. In der Folge führt die Beachtung der Anleitung zu einem nicht mehr startenden Apache, weil das mit =owner gebaute apache-Modul die Direktive suPHP_UserGroup nicht kennt und einem somit spontan um die Ohren fliegt wenn man die Anleitung befolgt.

suphp 0.6 ist zur Laufzeit besser konfigurierbar, was eventuell einen weiteren Sicherheitskompromiss bedeutet. Außerdem kann suphp 0.6 auch “normale”; CGI-Scripts ausführen und mutiert somit zum nahezu vollwertigen suexec-Ersatz.

Als Debian-Packages daherkommende Applikationen werden eher schwer unter suphp einsatzfähig sein, weil man die Dateien an einen anderen Benutzer “verschenken” muss. Ob das mit dpkg-statoverride einfach machbar ist, werden Experimente mit Dokuwiki in den nächsten Tagen zeigen.

Wie gut suphp für “normale” CGI-Scripts tut, werden Experimente mit munin-cgi-graph in den nächsten Tagen zeigen.

Momentan tendiere ich dazu, auch auf den sarge-Webservern einen Backport von suphp 0.6 einzusetzen, weil mir die Konfigurationsmöglichkeiten sexy erscheinen. Vielleicht komme ich irgendwann auch mal zu einer Meinung bezüglich der Sicherheitskompromisse. Jedenfalls steht die Kommentarfunktion dieses Artikels bereit, und ich freue mich auf Eure Meinungen.

Nachtrag

Nachdem ich Ende Dezember einige Fragen auf der suphp-Mailingliste gestellt habe, und diese Fragen genauso wie die explizite Nachfrage beim Autor drei Wochen später unbeantwortet verhallten, habe ich die Experimente mit suphp abgebrochen.

To self-signed or not to self-sign?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 08 Dec 2005 14:52:05 +0100

Auf der Nesus-Mailingliste fand ich heute eine Mail, deren Autor sich darüber wundert, dass
Nessus bei einem Self-Signed Certificate keine Warnung wirft.

Schließlich ist das eine schlechte Security-Maßnahme weil auf diese Weise Man-in-the-Middle-Attacken möglich werden. Das sei insbesondere im kommerziellen Umfeld ein Problem.

Nun, meine Meinung dazu ist, dass es sicherer sein kann, ein selbstsigniertes Zertifikat selbst zu verifizieren als sich blind auf die durchaus durchwachsenen Prozesse einer kommerziellen CA zu verlassen.

Ach ja, die oben zitierte Mail kam von einem Verisign-Mitarbeiter.