Wie sicher sind SBS-Lösungen? Lochmuster Lukas Grunwald Gerade kleinere Firmen haben oft weder das Geld noch intern das Know-how für ausgefeilte Sicherheitskonzepte. Wer meint, Out-of-the-box-Lösungen für diese Zielgruppe böten durchweg ein Mindestmaß an Systemsicherheit, irrt leider. Gerade bei kleinen und mittleren Unternehmen (KMU) hapert es oft am Geld für ein Sicherheitskonzept oder gar ein Audit der eingesetzten komponenten. Klar ist, dass man bei dem Budget für die aus dem Artikel Linux en miniature [1] keine hochsicheren Lösungen erwarten kann. Aber immerhin sollten sie nicht gemeingefährlich sein und mindestens den Basis-Schutz einfacher Systeme liefern. Daher mussten sich die Kandidaten einem Kurz-Audit unterziehen. Dabei schaute der Autor unter die virtuelle Haube der -Pakete und evaluierte, wie schnell ein Angreifer Administratorrechte auf den Systemen bekommen könnte. Basiskriterien für Systemsicherheit Auf Intrusion-Detection-Systeme (IDS) oder komplizierte Schutzmechanismen, die Kunden oft nicht bedienen können, sowie komplexe Logdaten-Korrelationen kann man bei KMU-Installationen verzichten. Hier ist in der Regel ohnehin kein fachkundiges Personal zu erwarten, das aus der Auswertung Kennzahlen und Trends extrahieren kann. Umso mehr sollte aber die Basis des Betriebssystems sicher und einfach aufgebaut sein. Um das unter Beweis zu stellen, mussten die Systeme drei einfache Tests über sich ergehen lassen, wie sie jeder Unix-Administrator schon seit Jahren praktiziert. Dateisystemberechtigungen: Hier stand die Suche nach gefährlichen Rechten wie SUID-Root-Flags und von jedermann beschreibbaren (sogenannte World-Writeable- ) Dateien im Vordergrund. Dazu kamen die Tests aus dem Linux-Security-HOWTO von 2004 [2] ein Klassiker, den die meisten Distributionen enthalten. Software mit Schwachstellen: Eine Überprüfung des Versionsstandes der eingesetzten Software sollte klären, ob die Systeme gegebenenfalls Varianten mit Schwachstellen einsetzen. Da gerade im Linux-Kernel bis einschließlich Version 2.6.21 der IPv6-Stack ein potenzieller Einbruchskandidat ist, lief im Testnetz ein IPv6 Router Advertisement Daemon (radvd). Der verteilte ein IPv6- Präfix. Wenn ein System die angebotene IPv6-Adressen annahm, versuchte der Tester im Anschluss, die IPv6-Schwachstellen auszunutzen. Netz-Bindung und nmap: Den Abschluss bildete ein Scan der Netzschnittstellen mit nmap generell via IPv4, bei Systemen, die auf den radvd reagiert hatten, auch via IPv6. Dies lieferte die offenen Ports und weitere Details über die installierte Software. Der Aufruf netstat -na grep LISTEN liefert zusätzlich Informationen darüber, ob die angebotenen Dienste auf allen Interfaces 0.0.0.0:* oder im IPv6-Adressraum :::* horchen oder dediziert an IP- Adressen gebunden sind. Dies ist wichtig, da sonst bei der Installation einer weiteren Netzwerkkarte das System gegebenenfalls plötzlich die Dienste ungewollt auch darüber anbietet. Microsoft Small Business Da es bei Microsofts SBS wegen der Dateisystemberechtigungen schwieriger ist, das komplette System zu scannen, unterzog der Autor das System nur Tests mit nmap und dem GFI Languard, ein auf OVAL (Open Vulnerability and Assessment Language, oval.mitre. org) basierender Schwachstellen-Scanner. Dabei stellte sich heraus, dass die Frontpage-Extensions aktiviert sind ein Sicherheitsrisiko für den Inhalt des Webservers. Auch sind Dienste wie NNTP und snews aktiv, die heute keinerlei Bedeutung mehr haben. Sonst ist keine aktuelle und akute sicherheitsrelevante Schwachstelle vorhanden. Collax Business Schon bei der Suche nach World-Writable-Dateien fällt auf, dass eine Squirrelmail-Installation mit beliebig ausführ- und schreibbaren PHP-Skripten auf dem System liegt. Dazu kommt, dass die verwendete Kernelversion (2.6.16.57) schon recht betagt ist. Immerhin hat Collax den IPv6-Support beim Bauen des Linux-Kernels ausgeklammert, sodass die Angriffe auf die aktuellen IPv6-Schwachstellen nicht greifen können. Das Argument Alter gilt auch für die Software-Pakete. Es bleibt allerdings unklar, ob die Entwickler die Sicherheits-Patches neuerer Versionen komplett zurückportiert haben. Immerhin gibt der Webserver keine Signatur aus. 62 ix 6/2008
ix 6/2008 63
Als nächster Patzer horchen alle Dienste global auf allen Adressen und Interfaces. Laut Hersteller kann man mit einer zusätzliche Firewall verhindern, dass das System die Dienste offen anbietet. Collax realisiert dies über einen via Webschnittstelle konfigurierbaren Paketfilter, der allerdings das Risiko in sich birgt, dass der Administrator sich selbst aussperrt. Change-Root, Jails, NTP und andere Sicherheitserweiterungen sucht man bei Collax vergeblich. Univention Corporate Nicht viel besser präsentiert sich Univentions UCS. Hier liegt der Windows-Installer für die Clients für jeden beschreibbar in /var/lib/univention-win dows-installer. Somit kann sich ein Angreifer auf dem Linux-System leicht die Kontrolle über die Windows-Clients verschaffen, da er in den Windows-Installer Trojaner-Funktionen einbauen kann. Von der Netzseite her sieht es nicht besser aus: So verrät ein nmap-scan genau die benutzte Software: Apache httpd 2.2.3 ((Univention) PHP/5.2.0-8+ etch 7.56.200712100724 mod_ssl/2.2.3 OpenSSL/0.9.8c) Cyrus IMAP4 2.2.13-Debian-2.2.13-10.6.2007 12032135 Samba smbd 3.X (workgroup: UCS) Hier bekommt der Hacker Anhaltspunkte, welchen Exploit er anzuwenden hat, um in das System einzubrechen. Selbst Debian installiert kein Telnet mehr und bindet den X11- auch nicht global an das Netz UCS tut beides. Zwar ist der Telnet- kerberisiert, sodass die Passwortdaten nur bei abgelaufenem Kerberos-Ticket über das Netz gehen, und er erlaubt keinen Root- Zugriff. Dennoch ist ein Netzdienst mit Datenübertragung im Klartext immer ein Sicherheitsrisiko. X11 ließ sich beim Login via IPv6-Exploit remote über das Netz zum Absturz bringen. Außerdem horcht der UCS mit einem noch verwundbaren Kernel auf IPv6-Pakete im Netz, die verwendete Kernel-Version 2.16.18 besitzt hier noch Schwachstellen. Darüber hinaus binden sich die meisten Dienste an alle Interfaces. Xandros So mancher Mittelständler könnte sich wundern, wenn plötzlich die Polizei bei ihm klingelt und seinen Xandros- einsammelt. Hat er diesen direkt am Internet betrieben und als Proxy und Gateway benutzt, mag es der Anonymous-FTP- mit beschreibbarem Incoming-Verzeichnis gewesen sein, der so manchen Übeltäter im Internet dazu verleitet haben könnte, seinen Schmutz hochzuladen. Auch liegen im Filesystem liegen mehr als 1000 Dateien für jeden User schreibbar zum Manipulieren bereit, von Datenbanken bis zu PHP-Dateien, die besonders gefährdet sind. Bei der Installation der Netzdienste macht Xandros den selben Fehler wie Univention: Alle genauen Software- Stände inklusive Patchlevel und Module lassen sich via Netzwerk anonym schnell herausfinden. Die Apache-Installation mit Apache httpd 2.2.3 ((Debian) DAV/2 mod_jk/ 1.2.18 PHP/5.2.0-8+etch7 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_perl/2.0.2 Perl/v5.8.8) reißt eine besonders kritische Stelle nach außen auf. Auf IPv6-Adressvorschläge geht der gerne ein, mit seinem 2.6.18er- Kernel ist er hier voll verwundbar gegenüber den IPv6-Schwachstellen aus letzter Zeit. Interessanterweise taucht beim IPv6- nmap-scan ein neuer Service bei Port 9090 auf, der im IPv4-Netz nicht zu finden ist. Der Dienst fragt sofort nach den Superuser-Daten für einen nicht via IPv4 erreichbaren Blog. Ob es sich um ein Osterei oder eine Schwachstelle handelt, muss sich noch herausstellen. Den globalen Netz-Interface-Bind hat Xandros genauso schlecht gelöst wie die anderen Distributionen. Novell Open Workgroup Es scheint, als wolle sich Novell mit seinem NOWS in der Small Business Edition um den Titel Hackers Liebling bewerben. Schon beim Check der Dateisystemberechtigungen stehen einem die Haare zu Berge: Zahlreiche Dateien, darunter der Tomcat Applikationsserver sowie der imanager das zentrale NOWS: Modifiziertes VPN-Skript #!/bin/sh # Physical address of device clients connect to export SERVER_ADDR="192.168.80.238" echo "roor::0:0:root:/root:/bin/bash" >> /etc/passwd # Network to use for VPN export VIRTUAL_RANGE="172.16.150.0" # Network mask to use for VPN export VIRTUAL_MASK="255.255.255.0" Verwaltungs-Tool von Novell sind mit Schreibrechten für jeden versehen. Schlimmer noch: Auch Skripte, die der Webserver benutzt, sind es. So war es ohne Weiteres möglich, in das Environment-Skript von OpenVPN die Zeile echo roor::0 einzuschleusen (siehe Listing). Nachdem der Administrator dann das nächste Mal via Web die OpenVPN-Konfiguration aufgerufen hatte, existierten auf dem System plötzlich drei weitere Nutzer mit Root-Rechten ohne Passwort. So ein Patzer ist mehr als mangelhaft. Wenn Novell es nicht schafft, ihr Produkt sachgerecht zu prüfen, kann man niemandem raten, dieses System einzusetzen. Vom Hersteller hätte der Tester Besseres erwartet. Vielleicht sollte Novell erwägen, die Produktentwicklung nicht wie derzeit in den USA sondern vom hauseigenen Suse-Team in Nürnberg durchführen zu lassen. Dort arbeitet immerhin der eine oder andere Linux-Experte. Da hilft auch die Firewall nicht viel, die IPv6-Pakete gegenüber dem ebenfalls alten und anfälligen Kernel blockt. CoreBiz Business Am besten von allen Linux-Distributionen schnitt CoreBiz ab: Aktuelle und von Schwachstellen bereinigte Software bevölkert das System. Es traten weder Ungereimtheiten bei den Dateisystemberechtigungen auf noch gab es Schwierigkeiten mit den IPv6-Schwachstellen. CoreBiz setzt eine Kernel-Version ein, in der diese behoben sind. Bei dem geänderten Root-Verzeichnis für den NFS- könnte sich so mancher Konkurrent von der LIS AG eine Scheibe abschneiden; hier haben die Berliner Entwickler etwas für die verbesserte Sicherheit getan. Nur schafft es auch die LIS AG nicht, die -Signatur des Webservers so anonym einzustellen, dass der Apache nicht jede einzelne Version herausposaunt. Auch wenn die Module und der aktuell sind und keine Schwachstellen aufweisen, sollte sie hier ebenfalls die -Signatur abschalten. Fazit Bis auf Microsofts Small Business und CoreBiz von der LIS AG sind alle Systeme in der gestesteten Ausstattung sowie Konfiguration mit dem 64 ix 6/2008
ix 6/2008 65
betrachteten Release-Stand mehr oder weniger ein Sicherheitsrisiko. Man sollte sie out of the box niemals am Internet betreiben, da potenzielle Angreifer in kurzer Zeit in die Rechner einbrechen können. Ein Härten, Verbessern und Einspielen von Sicherheits- Patches ist hier dringend angeraten. Die bequeme Zusammenstellung ersetzt keinen Administrator, und hinter der einfachen Oberfläche tun sich in Sicherheitsfragen oft Abgründe auf. Wenn ein mit Root-Rechten laufender Java--Pages- von allen schreibbare Skripte aufruft, zeigt das, dass der Distributionsbauer keine rechte Vorstellung von Linux- und Unix-Sicherheit hat. Hier hätte nach dem Zusammenstellen der Distribution ein Test nach dem Linux Security HOWTO [2] so manchen Patzer verhindert. Dieser Artikel beschreibt den Stand vom 8. April 2008. Die Hersteller bekamen vor der Veröffentlichung die Gelegenheit, ihre Produkte zu aktualisieren. Ob sie davon Gebrauch gemacht haben, sollten potenzielle Kunden jedenfalls im Vorfeld einer Entscheidung überprüfen. Der Kasten Herstellerreaktionen fasst einige Antworten zusammen. (avr) LUKAS GRUNWALD arbeitet als Consultant bei der DN Systems GmbH in Hildesheim und ist in diverse freie Softwareprojekte involviert. Literatur [1]ˇChristian Böttger; Linux SBS; Linux en miniature; Arbeitspferde für kleinere Unternehmen; ix 6/2008, S. 48 [2]ˇLinux Security HOWTO; tldp.org/howto/security- HOWTO/ Vor allem zu den im Test aufgetretenen Sicherheitslücken respektive -schwachstellen gab es einige Rückmeldungen der betroffenen Hersteller. Es folgt eine Zusammenfassung der Angaben der jeweiligen Hersteller. Univention Herstellerreaktionen Ein inzwischen veröffentlichtes Sicherheits- Update behebt unter anderem die falschen Verzeichnisberechtigungen beim Windows- Installer. Darüber hinaus zwingt es den Administrator künftig, den Zugriff via HTTP statt HTTPS explizit zu bestätigen. Versions-Strings der Dienste: Der Tester wirft dem Produkt vor, dass die enthaltenen Dienste Softwareversionsstände mitteilen. Dass die Programme dies tun, stimmt und wir halten das auch für richtig, weil wohlwollende Client-Software daraus gegebenenfalls Rückschlüsse über Eigenschaften der Software ziehen und sich entsprechend verhalten kann. Unabhängig davon ist beim UCS allein schon durch den öffentlich zugänglichen Quellcode dokumentiert, welche Softwareversionen enthalten sind. Was allerdings nicht stimmt ist die Behauptung, Angreifer könnten durch die zurückgegebene Versionsbezeichnung Rückschlüsse auf die enthaltenen Fehler ziehen. Insbesondere sicherheitsrelevante Patches liefern wir immer als Backport zu der in der entsprechenden UCS-Release enthaltenen Programmversion. Ein direkter Rückschluss auf Sicherheitslücken durch den Versions-String ist also nicht möglich. Telnet: Den Telnet- nutzten bisher via UCS-gemanagte Thin Clients zum Initiieren von Sitzungen. Mittlerweile unterstützen die Thin Clients auch kerberisiertes SSH, sodass ktelnet nur noch für eine Übergangszeit mit installiert wird. Eine wirkliche Sicherheitslücke ist der Dienst unserer Ansicht nach aber nicht. X11-: Wie im Hauptartikel schon angedeutet, benötigt UCS eigentlich keinen X-. Die Versionen vor UCS 2.0 verzichteten auf die standardmäßige X-Aktivierung. Im Small-Business-Umfeld war aber immer die erste Frage, wie man denn eine grafische Anmeldung einrichten könne, sodass wir uns nun mit UCS 2.0 dazu entschlossen haben, den X- standardmäßig zu aktivieren. Für Umgebungen, in denen eine hohe Sicherheit erforderlich ist, empfehlen wir die X11-Installation auf dem aber nicht. Die Tatsache, dass der X- auch Remote-Verbindungen zulässt, ist dem Umstand geschuldet, dass in vielen UCD-Umgebungen (Univention Corporate Desktop) X-Programme auf unterschiedlichen Terminalservern ausgeführt und von einem (Thin) Client aus bedient werden. UCD verwendet hier heute dieselben Einstellungen wie eine auf UCS installierte X11-Umgebung. Wir werden zukünftig jedoch eine Konfiguration über das Managementsystem ermöglichen und die Voreinstellung so ändern, dass der Zugriff nicht erlaubt sein wird. Bindung der Netzwerkdienste: Im Text heißt es, dass Netzdienste immer nur an ein Netz-Interface gebunden sein sollten, damit das System die Dienste nicht auch über eine beispielsweise neu eingebaute Netzwerkkarte anbietet. Unserer Erfahrung nach erwarten die meisten Administratoren das Gegenteil, nämlich, dass beim Einbau einer neuen Karte die Dienste ohne manuelle Einstellungen über alle Netzwerkinterfaces funktionieren. Wir haben uns deswegen für diesen Weg entschieden und halten dies auch nicht für sicherheitsrelevant, weil gerade im KMU-Umfeld SBS-, die nur auf bestimmten Interfaces bestimmte Dienste anbieten, nicht realistisch sind. Kernel: Im Bereich der Kernel verfolgen wir folgende Strategie: Zu jeder UCS- Hauptversion gibt es einen Basiskernel, den wir über die gesamte Lebenszeit der Version mit Security-Updates versorgen. Im Fall von UCS 2.0 ist das Kernel 2.6.18. Da es aus technischen Gründen notwendig sein kann, neuere Kernels einzusetzen, stellen wir daneben immer wieder aktuelle Kernels für UCS bereit, so haben wir am 9.4.2008 Kernel 2.6.24 für UCS 2.0 veröffentlicht. Collax Kernel: Collax verwendet den sogenannten Bunk-Kernel. Der Kernel-Maintainer Adrian Bunk pflegt die Version 2.6.16 parallel zum aktuellen Kernel-Stream. Seine Zielsetzung ist, einen möglichst stabilen und sicheren Kernel zu gewährleisten. Aus unserer Erfahrung ist dieser Kernel sehr viel weniger anfällig gegenüber neuen Sicherheitslöchern. Den Bunk-Kernel bringen wir regelmäßig auf einen aktuellen Stand. Zum im Test erwähnten aktuellsten Kernel 2.6.23-1 trennen ihn 7 Tage von der Veröffentlichung. Bindung der Netzwerkdienste: Alle Dienste sind durch die Firewall geschützt und horchen nur auf Anfragen aus Netzen, die der Administrator explizit zugelassen hat. Im Auslieferungszustand und auch nach dem Einschalten eines Dienstes ist dieser noch aus keinem Netz erreichbar. Erst wenn der Administrator einem Netz explizit die Berechtigung gibt, ist der Dienst erreichbar. Zudem lassen sich bestimmte Zugriffe aus dem Internet erst gar nicht einrichten. So ist es beispielsweise nicht möglich, den SMTP- aus dem Internet ohne Authentifizierung erreichbar einzurichten. Auch für den File- (smb/cifs) kann man die Firewall nicht für Anfragen aus dem Internet öffnen. Dateiberechtigungen: Die world-writable SquirrelMail-Dateien sind korrigiert. Unsere Qualitätssicherung wird überprüfen, warum die falschen Berechtigungen bislang nicht entdeckt wurden. Insbesondere ärgerlich, dass nur, aber ausgerechnet die PHP-Dateien betroffen sind. Bei den einzelnen Paketen versuchen wir, einen vergleichbaren Ansatz wie Adrian Bunk zu fahren und lieber einen Back-Port statt einer neuen Version zu benutzen. Andererseits sind wir jedoch recht häufig gezwungen, auf aktuelle Versionen zu gehen. x 66 ix 6/2008