ADMINISTRATION. Open Source im Einsatz KOMPAKT. Mit OpenStack zur eigenen Private Cloud. Backup mit Bacula 7 Do-it-yourself-NAS

Transkript

1 Mit DVD KOMPAKT ADMINISTRATION Ein Sondereft des Magazins für professionelle Informationstecnik, 3/2014 Auf der Heft-DVD Fertige VMs zum Ausprobieren: Debian mit Baculaˇ7, CentOS mit Icingaˇ2 und Icinga Webˇ2, UCS (25 User) Software, Tools, Doku: FreeNAS , nützlice Administrations-Helferlein für Linux, MacˇOSˇX und Windows, Kerberos-Key- Management, Netz- Tools, RFCs u.ˇv.ˇa.ˇm. Systemkonfiguration: Backup mit Bacula 7 Do-it-yourself-NAS Sicereit: Compliance-Management mit OpenSCAP SELinux und Grsecurity effektiv nutzen Netzwerk: Traffic-Analyse mit Wiresark WLAN mit RADIUS Monitoring: Nagios und Icinga 2 Logdatenanalyse Linux-AD-Integration: FreeIPA-Tutorial Kerberos Tools und Tipps Open Source im Einsatz Cloud-Tutorial: Mit OpenStack zur eigenen Private Cloud

2

3 EDITORIAL Cat-Content satt Nac landläufiger Meinung soll beim sogenannten Cat- Content angeblic kein Sysadmin widersteen können egal ob Cat-5e oder lebende Miezekätzcen. Wärend sic Letztere in diesem ix-kompakt zu Administration mit Open-Source-Tools als Aufmacerbilder tummeln, spielen Cat-x-Kabel als Transportmedium im Tagesgescäft der IT eine tragende Rolle. Sie sind quasi die Nervenenden des globalen Rückgrats Internet, über das Anwender und Anwendungen Daten austauscen. Im Internet funktionierten von Anfang an große Teile der In frastruktur mit Open-Source-Betriebssystemen und -Programmen etwa Linux oder der Webserver Apace. In anderen Bereicen war freie Software zunäcst überwiegend tecnik - affinen und experimentierfreudigen Naturen vorbealten. Doc inzwiscen at das dainter steende Entwicklungsmodell große Verbreitung und Akzeptanz gefunden. Selbst klassisce IT-Unternemen wie HP, IBM und Co. setzen für ire Angebote teilweise Tendenz steigend auf freie Komponenten. Die wiederum müssen in vielen Bereicen den Leistungsvergleic mit iren kommerziellen Gegenstücken nict sceuen, laufen inen zum Teil sogar den Rang ab. Ein aktuelles Beispiel ierfür ist OpenStack. Das ursprünglic von der NASA und der amerikaniscen Rackspace Inc. initiierte Projekt at sic mit mittlerweile rund 200 unterstützenden Firmen zum Quasi-Standard für offene Cloud-Angebote gemausert. Allein die Liste der Gold- und Platin-Mitglieder liest sic wie das Wo-is-Wo der IT-Brance. Dabei setzen produktseitig nict nur die üblicen Verdäctigen wie Red Hat, SUSE oder Canonical auf OpenStack, auc HP und IBM aben darauf basierende Cloud-Angebote im Portfolio. Apropos: Ein dreiteiliges Tutorial in diesem Heft zeigt Scritt für Scritt, wie sic das aktuelle OpenStack Iceouse im eigenen Umfeld einsetzen lässt. Aber nict nur bei den Infrastrukturkomponenten kann Open Source punkten, auc beim Administrieren und Steuern der zugeörigen Systeme existieren neben dem breiten Strauß kommerzieller Pakete leistungsfäige freie Alternativen. Letztlic kommen vor allem in komplexen Umgebungen die IT-Verantwortlicen nict one effiziente Werkzeuge für die Systemverwaltung aus. Hier kann die Community ein vielfältiges Angebot vorweisen. Gerade im Bereic Monitoring setzt man derzeit quasi die Standards dessen, was macbar ist. Jedoc fordert die Komplexität der Anwendungen iren Tribut: Die gängige Vorstellung, Open-Source-Software koste ja nicts, stimmt nur bedingt. Zwar fallen keine Lizenzkosten an, aber für einen wirkungsvollen Einsatz muss man entweder in das Know-ow seiner Mitarbeiter investieren oder externes Wissen von Dienstleistern einkaufen. Der Gewinn, der in jedem Fall bleibt, ist die Offeneit der eingesetzten Tools. ANDRÉ VON RAISON ix Kompakt 2014 Open-Source-Administration 3

4 INHALT IX KOMPAKT Eine Frage der rictigen Überwacung Wem seine IT am Herzen liegt, der kümmert sic nict erst bei Felern um das Wolbefinden der Systeme. Die Open-Source-Pakete Nagios und das daraus entstandene Icinga sind eute die verbreitetsten Anwendungen für das Monitoring. Wie man mit diesen und weiteren Tools seine Um - gebung automatisc erfasst sowie sie sicer im Auge beält ab Seite 81 Sicereit Betriebssystem-Security Grsecurity für das Härten von Linux-Systemen 8 Compliance-Management Systemüberprüfungen mit OpenSCAP 16 SELinux-Tutorial Mandatory Access Control auf Linux-Systemen 24, 28 Identitätsmanagement FreeIPA-Tutorial Linux- und Windows-Welt mit dem freien Identity-Management-Framework verbinden 34, 40, 46 Single Sign-on Merfaktor-Autentifizierung durc Kerberos 52 Active-Directory-Tools Kerberos-Keytab-Management mit msktutil 58 Systemkonfiguration AD-Integration Mit Linux via SSSD ins Active Directory 62 Backup Daten sicern mit Bacula 7 67 Wiederverwendung Ältere Hardware mit FreeNAS weiternutzen 72 Softwareverteilung Linux-Clients per m23 zentral verwalten 76 Monitoring Security Best Practises für sicere Monitoring-Systeme 82 Inventarisierung Octopussy für die automatisce Bestandserfassung 90 Werkzeuge Systemüberwacung mit Icinga 2 96 Linux-Tools Systemaktivität überwacen 105 Log-Management Ein integriertes Monitoring-System mit Logstas 106 Systemüberwacung Mit Octopussy Logdateien zentral verwalten 112 Netzwerk DDoS-Abwer Offene DNS-Server als Waffe im DDoS-Angriff ix Kompakt 2014 Open-Source-Administration

5 Wer ist wer Früer oder später stellt sic in gemiscten Umgebungen die Frage, wie man die Benutzerverwaltung von unixoiden und Windows-Systemen unter einen Hut bekommt. Für das Temenfeld Identity- Management bietet die Open-Source-Community leistungsfäige Alternativen. ab Seite 33 Cloud und mer Im Open-Source-Cloud-Umfeld at sic das Projekt OpenStack mittlerweile zum De-facto-Standard ent - wickelt die Zal von über 200 unterstützenden Unternemen sprict für sic. Ein Tutorial bescreibt Scritt für Scritt den Weg zur eigenen Private Cloud. ab Seite 135 Administrations-Tools Netzproblemen per Wiresark auf die Spur kommen 120 Siceres Linux Mandatory Access Control für IP-Pakete 124 Zugriffskontrolle Port-based 802.1x-Autentifizierung mit RADIUS 128 Virtualisierung und Cloud OpenStack-Tutorial Grundstein für die eigene Private Cloud 136, 142, 148 Linux-Container Mit Docker Anwendungen virtualisieren 155 Open-Source-Tools MCollective und Rundeck für das zentrale Administrieren virtueller Mascinen 159 Sonstiges Editorial 3 Impressum 6 Inserentenverzeicnis 6 Informationen zur UCS-Demo-Appliance 6 Auf der Heft-DVD Software zum Heft: Bacula 7.0.3, FreeNAS , Kerberos-Tools (kstart 4.1, msktutil 0.5.1, realmd , SSSD ), Logstas (Elasticsearc 1.1.1, Kibana 3.0.1, Redis 2.8.9), Octopussy , OpenSSL 1.0.1g (Windows), WinSCP 5.3.3, Wiresark , Zenmap 6.46 Weitere Tools: 7-Zip, dd_rescue 1.40, dd_relp 0.1.2, EterAPE , Iperf 2.0.5/3.0, liboping 1.6.2, Ncat 6.46, Ndisc , Netperf 2.6.0, Nmap 6.46, Nping , OpenVPN 2.3.3, OpenVPN GUI 1.0.3, p7zip , Putty, tinc , Tunnelblick Dokumentation: M23-Handbuc, OpenLDAP Admin Guide, Wiresark User Guide, über 350 RFCs Fertige VMs zum Ausprobieren: ˇDebian-Weezy mit Baculaˇ7 ˇCentOS 6.5 mit Icingaˇ2 und Icinga Webˇ2 ˇUnivention Corporate Server (25 User) Hinweis für Käufer der digitalen Ausgaben PDF- und ipad-version: In der ix-app finden Sie einen Button zum Download des DVD-Images. PDF-E-Book: Folgen Sie im Browser der unter Alle Links angegebenen URL zum DVD-Image. Alle Links: Artikel mit Verweisen ins Web Alle Links: entalten am Ende einen Hinweis darauf, dass diese Webadressen auf dem Server der ix abrufbar sind. Dazu gibt man den ix-link in der URL-Zeile des Browsers ein. Dann kann man auc die längsten Links bequem mit einem Klick ansteuern. Alternativ stet oben rects auf der ix-homepage ein Eingabefeld zur Verfügung. ix Kompakt 2014 Open-Source-Administration 5

6 SERVICE IMPRESSUM/INSERENTEN MAGAZIN FÜR PROFESSIONELLE INFORMATIONSTECHNIK ix Kompakt 3/2014 Administration Postfac , Hannover; Karl-Wiecert-Allee 10, Hannover Redaktion: Telefon: 05 11/ , Fax: 05 11/ , Cefredakteur: Jürgen Seeger (js) -386 Konzeption und redaktionelle Leitung: André von Raison (avr) -377, Ständige Mitarbeiterin: Barbara Lange Autoren dieser Ausgabe: Cristop Arnold, Cristian Berendt, Peter Fetzer, Oliver B. Fiscer, Alexandros Gougousoudis, Safuat Hamdy, Peer Heinlein, Patrick Preuß, Mark Pröl, André von Raison, Micael Riepe, Torsten Scerf, Andreas Scmidt, Norbert Tretkowski, Tilman Wittenorst, Erkan Yanar Abbildungen Can Stock Poto Inc.: Siberia (Titel, DVD, DVD-Hülle), fikmik (S.ˇ4, 33), Kirill (S.ˇ4, 81), myrainjom01 (S.ˇ4), taden (S.ˇ4, 135), vladstar (S.ˇ7), cfoto (S.ˇ8), cynoclub (S.ˇ16, 72), ESIGHT (S.ˇ24), jgroup (S.ˇ28), andreykuzmin (S.ˇ34, 40, 46) 2002Lubava1981 (S.ˇ52), vitalytitov (S.ˇ58), Paknyuscyy S.ˇ61), bloodua (S.ˇ62), McIninc (S.ˇ67), ifong (S.ˇ72), oxilixo (S.ˇ76), pterwort (S.ˇ90), tobkatrina (S.ˇ96), w20er (S.ˇ105), maigi (S.ˇ106), McIninc (S.ˇ112), pontuse (S.ˇ128), flibustier (S. 136, 159), Meldes (S. 142), Colecanstock (S. 148), Svet_lana (S. 155), Abbildungen Fotolia.com: Eric Isselée (S.ˇ82, 117, 120), Ana Gram (S.ˇ118), Patryk Kosmider (S. 124) Redaktionsassistenz: Carmen Lemann (cle) -387, Micael Mentzel (mm) -153 Korrektorat: Silke Peters, Hinstorff Verlag, Rostock Layout und Satz: Enrico Eisert, Katleen Tiede, Mattias Timm, Hinstorff Verlag, Rostock; Jürgen Gonnermann, Heise Zeitscriften Verlag Titelidee: ix, André von Raison Verlag: Heise Zeitscriften Verlag GmbH & Co. KG, Postfac , Hannover; Karl-Wiecert-Allee 10, Hannover; Telefon: 05 11/ , Telefax: 05 11/ Gescäftsfürer: Ansgar Heise, Dr. Alfons Scräder Mitglied der Gescäftsleitung: Beate Gerold Verlagsleiter: Dr. Alfons Scräder Anzeigenleitung: Micael Hanke (-167), Druck: Dierics Druck + Media GmbH, Kassel Verantwortlic: Textteil: Jürgen Seeger; Anzeigenteil: Micael Hanke ix Kompakt 3/2014 Administration: Einzelpreis 12,90, Österreic 14,20, Scweiz sfr 25,80, BeNeLux: 14,80, Italien: 16,80 Eine Haftung für die Rictigkeit der Veröffentlicungen kann trotz sorgfältiger Prüfung durc die Redaktion vom Herausgeber nict übernommen werden. Kein Teil dieser Publikation darf one ausdrücklice scriftlice Genemigung des Verlages verbreitet werden; das scließt ausdrücklic auc die Veröffentlicung auf Websites ein. Printed in Germany Copyrigt by Heise Zeitscriften Verlag GmbH & Co. KG Die Inserenten B1 Systems 9 bytec dpunkt Galileo Press 17 Hostserver 2 Hütig 39 Netways 31 Tomas Krenn 11 uib GmbH 45 Webtropia 13 Die ier abgedruckten Seitenzalen sind nict verbindlic. Redaktionelle Gründe können Änderungen erforderlic macen. Demo-Appliance mit Univention Corporate Server Die Heft-DVD entält eine vorinstallierte und -konfigurierte virtuelle Appliance mit dem Univention Corporate Server (UCS) in der Version Sie umfasst eine bis gültige Lizenz für bis zu 25 Benutzer für Testzwecke und den Einsatz im privaten, nict kommerziellen Bereic. Mit der Appliance lassen sic komplexe Serverstrukturen mit Master-, Slave- und Backup-Servern aufsetzen, Nutzer und Gruppenberectigungen anlegen sowie zusätzlice Enterprise-Apps installieren und verwalten. Die virtuelle Appliance ist auf Bridge Mode eingestellt, sodass das UCS-System über das lokale Netzwerk erreicbar ist. Nac dem Entpacken des VMware-Images, Laden der vmx-datei in den VMware Player und Starten der virtuellen Mascine ersceint das Boot-Menü. Nac einigen Sekunden färt dessen vorausgewälter Eintrag Univention Corporate Server (UCS) oc, und ein Einrictungsassistent fürt Scritt für Scritt durc die Inbetriebname. Als erster Scritt folgt die Auswal der Systemrolle. Bei der Erstinstallation von UCS ist der vorausgewälte Domaincontroller Master zu verwenden, Sprac-, Tastatur- und Zeitzoneneinstellungen scließen sic an. Danac fragt der Assistent den Recnernamen inklusive Domäne ab und generiert daraus automatisc einen Windows-Domänennamen. Diesen Namen kann man später nict mer ändern! Zum Test einer Active-Directory-(AD)-Migration muss der Windows- Domänenname der zu migrierenden AD-Domäne entsprecen (siee Alle Links ). Recnername und IP-Adresse des UCS-Systems müssen sic ingegen vom AD-Server untersceiden. Das festzulegende Root-Passwort gilt automatisc auc für das Administrator-Konto. Zwar ist die Netzkonfiguration auf DHCP voreingestellt, man kann aber auc eine statisce Adresse vergeben. In den restlicen Abscnitten kann man die vorgesclagenen Einstellungen übernemen. Je nac Testzweck lassen sic nun weitere Software-Komponenten wie Sambaˇ4 als AD-kompatibler Domaincontroller auswälen oder später über das App Center nacinstallieren. Remote-Zugriff per SSH Im Anscluss daran nimmt das Einricten der Domäne und die Installation der zusätzlicen Softwarekomponenten einige Minuten in Anspruc. Nac einem Neustart ist das UCS-System einsatzbereit. Der Remote-Zugriff kann entweder per Secure Sell (SSH) als Benutzer root mit dem vergebenen Passwort oder im Web-Managementsystem als Administrator erfolgen. Hat man die KDE-Desktop-Umgebung installiert, kann man sic dort ebenfalls mit dem Administrator-Konto anmelden. UCS kann durc die Integration von Sambaˇ4 als AD-kompatibler Domänen-Controller fungieren und Benutzer, Drucker, Recner sowie Rictlinien verwalten. Mit dem Beitritt eines Win dows Client zur UCS-Domäne lässt sic der Funktionsumfang von UCS am einfacsten testen. Weitere Testszenarien sind mit dem App Center scnell aufgebaut, beispielsweise zum Evaluieren von Migrationsszenarien oder einzelner Business-Applikationen wie Groupware oder File-Saring-Ansätze. 6 ix Kompakt 2014 Open-Source-Administration

7 Sicereit: Flatterafte Werte Sensible Informationen verscwinden oft scneller aus IT-Systemen als mancem lieb ist. Die für die Zugangsberectigungen verantwortlicen Administratoren fülen sic ier scnell ans spricwörtlice Flöe üten erinnert. Wer aber ein bisscen Aufwand nict sceut, kann sic mit weniger flüctigen Daten scätzcen belonen. Linux effektiv ärten mit Grsecurity 8 Compliance-Management via OpenSCAP 16 SELinux I: Mandatory Access Control für Linux 24 SELinux II: Eigene Policy-Erweiterungen umsetzen 28 ix Kompakt 2014 Open-Source-Administration 7

8 SICHERHEIT BETRIEBSSYSTEM-SECURITY Linux-Systeme ärten mit Grsecurity Abgrenzungsilfe Safuat Hamdy Für die Härtung von Linux- Systemen stet Grsecurity in einer Reie mit anderen Frameworks wie AppArmor, SELinux, SMACK oder TOMOYO. Es untersceidet sic von diesen jedoc nict nur in Details, sondern ebt sic grundsätzlic durc einige spannende Features ab. mit einem Rootkit, könnte es Teil eines Botnetzes und anscließend für weitere illegale Aktivitäten missbrauct werden. Ein prominentes Beispiel ierfür ist das Ende 2011 bekannt gewordene Rootkit Ebury. Hierbei ersetzten die Angreifer im Zuge der Kompromittierung das ssd-binary und weitere Programme. In der Folge dienten die befallenen Systeme dazu, Zugangsdaten zu erbeuten, Spam zu versenden und Websurfer auf Seiten umzuleiten, die Malware über Drive-by-Downloads verteilen (siee Onlinequellen, [a]). Systemärtung eine Begriffsabgrenzung Obwol der konzeptionelle Merwert von Security-Frameworks wie AppArmor, SELinux, SMACK oder TOMOYO und anderen unbestritten ist, finden diese in der Praxis jedoc kaum Anwendung. Das Hauptindernis ist oft der mit dem Einstieg verbundene Lernaufwand, vor allem beim Erstellen einer braucbaren Policy. Dieser Artikel zeigt, wie der Einstieg in Grsecurity mit relativ moderatem Aufwand gelingt. Der Betrieb exponierter Systeme wie Webserver oder Mail- Relays stellt aus Sicereitssict nac wie vor eine besondere Herausforderung dar. Solce Systeme sind auf versciedenen Ebenen angreifbar. Dies gilt besonders für Webserver mit komplexen Webanwendungen. Kritisce Scwacstellen könnten dazu füren, dass Angreifer Dienste oder gleic das gesamte System beeinträctigen und sclimmstenfalls übernemen können. Infiziert ein Hacker im Zuge eines solcen Angriffs ein System Allgemein sind Betreiber dazu angealten, ire Systeme zu ärten, doc ist dieser Begriff etwas scwammig. Als erstes fällt da das Abscalten unnötiger Dienste und das Deinstallieren unnötiger Software ein, um die Angriffsoberfläce zu verkleinern. Diese an sic gute Idee kann sic aber als trickreic erweisen, da viele Pakete in einem komplexen Geflect aus Abängigkeiten verstrickt sind. Daneben steen Standardmaßnamen wie der Einsatz von Paketfiltern und Anti-Viren-Software, das Einscränken von Zugriffsrecten, ein restriktives Handaben von su und sudo, Passwörter für den Bootloader, ein Reduzieren der Programme mit SUID-Bit auf das absolut Notwendige et cetera. Im Netz existieren versciedene ausfürlice Härtungs-Guides wie die Bencmarks des Center for Internet Security [b], die ein gewissenafter Administrator Punkt für Punkt abarbeiten kann. Doc diese Maßnamen kratzen nur an der Oberfläce und bleiben auf bestenfalls albem Weg zu einem robusten System steen. Viele Einzelmaßnamen geen am Punkt vorbei. Nimmt man den Fall Ebury, dann erfolgte die Kompromittierung offenbar über das Abfangen von Root-Passwörtern an anderer Stelle da ilft es nur wenig, seine (auf Servern nict so zalreic vorandenen) Benutzer einzuscränken, rigide Passwort-Rictlinien durczusetzen und die Anzal der SUID-root-Programme auf ein Minimum zu reduzieren. 8 ix Kompakt 2014 Open-Source-Administration

9 Andere Malware setzt oft auf Zero-Day-Exploits, um sic Zugang zu Systemen zu verscaffen. Hierbei nutzt sie in der Öffentlickeit noc unbekannte Scwacstellen aus. Auc da aben die oben genannten Maßnamen oft nur die Wirkung, die Angriffsoberfläce zu verkleinern. Das ist nict verkert, aber Härtung ist mer, als einem Angreifer nur auszuweicen letztlic kann man die Angriffsoberfläce nict beliebig verkleinern. Für einen bestimmten Zweck im Internet betriebene Systeme müssen einem Angriff auc widersteen können. Kaum mer als ein Feigenblatt: croot Administratoren von Unix-Systemen preisen croot-umgebungen immer wieder gern als Maßname zur Eraltung der Systemintegrität. Diese Umgebungen sind aber nict wasserdict, es sind im Lauf der Zeit versciedene Ausbrucsmetoden bekannt geworden. Tatsäclic ist croot nict als Sicereitsmecanismus entstanden, sondern nur als Mittel, die Sict auf das Dateisystem einzuscränken. Zudem ist das korrekte Aufsetzen einer croot-umgebung nict trivial. Eine Weiterentwicklung von croot-umgebungen bestet in Containern wie OpenVZ oder Linux Containern (LXC) siee Seite 155. In einem solcen Container bekommen die darin entaltenen Prozesse nict nur eine eingescränkte Sict auf das Dateisystem, sondern auf fast alle Aspekte des Betriebssystems, etwa eigene Prozesstabellen, Netz-Interfaces mit eigenen IP- Adressen und Firewall-Regeln et cetera. Aber auc ier gibt es Fallstricke LXC beispielsweise war bis vor kurzem nict in der Lage, einen Superuser inneralb eines Containers von dem Superuser des Wirts abzugrenzen. RBAC und MAC erweiterte Zugriffskontrolle Eine konzeptionell ausgezeicnete Maßname gegen eine große Klasse noc unbekannter Scwacstellen bestet in rollenbasierter Zugriffskontrolle (Role Based Access Control, RBAC) im Zusammenspiel mit rictliniengesteuerter Zugriffskontrolle (Mandatory Access Control, MAC). RBAC berut im Wesentlicen darauf, versciedene Berectigungen in Rollen zu bündeln und diese dann kollektiv Benutzern bezieungsweise Prozessen zu gewären. Oberfläclic betractet ist dies dem Gruppenkonzept rect änlic, tatsäclic bestet aber ein konzeptioneller Unterscied, da Gruppen Benutzer bündeln, denen man kollektiv einzelne Recte gewären kann. MAC berut darauf, Zugriffe über eine zentrale Rictlinie zu steuern, auf die die einzelnen Benutzer oder Prozesse keinen Einfluss aben. Das unter Unix und Linux ierfür üblice Modell ist identitätsbasierte Zugriffskontrolle (Identity Based Access Control, IBAC) im Zusammenspiel mit benutzergesteuerter Zugriffskontrolle (Discretionary Access Control, DAC), das eißt, man muss den Linux-Kernel für RBAC und MAC erst um die entsprecenden Funktionen erweitern. Im Lauf der Zeit integrierten die Entwickler versciedene Frameworks für RBAC und MAC in den Linux-Kernel, allen voran SELinux, von dem es inzwiscen sogar Portierungen zu BSD (SEBSD) und Mac OS (SEDarwin) gibt. Das Erstellen von ix Kompakt 2014 Open-Source-Administration 9

10 SICHERHEIT BETRIEBSSYSTEM-SECURITY SELinux-Rictlinien erfordert jedoc eine oe Kompetenz, was de facto eine breitere Nutzung von SELinux verindert. Die beiden Artikel ab Seite 24 und 28 wollen dazu beitragen, den Kreis der SELinux-User zu erweitern. Andere Frameworks wie AppArmor, SMACK oder TOMOYO sind mit dem Anspruc angetreten, relativ leict nutzbar zu sein, jedoc zeigt die Praxis, dass auc ier der Teufel im Detail steckt. Ein Einsatz erfordert meist Handarbeit Ein weiteres Framework für RBAC und MAC wurde in Grsecurity implementiert. Grsecurity bietet allerdings weit mer als RBAC und MAC, aber es ist kein Bestandteil des offiziellen Kernels, was die Nutzung leider zusätzlic erscwert. Wie es aussiet, wird sic daran auc nicts ändern [c]. Für einen Betreiber liegt die Hürde zur Nutzung von Grsecurity damit rect oc. Dies ist rect bedauerlic, denn Grsecurity kann mit Fug und Rect als ein gelungener Beitrag zur Linux-Sicereit bezeicnet werden. Zudem ist Grsecurity einfacer zu andaben als SELinux [d, e]. Unter den genannten Frameworks zur Linux-Härtung stet Grsecurity etwas abseits, da es nict die LSM-Scnittstelle (Linux Security Modules) nutzt, sondern aus einem Satz von Patces bestet, der viele Bereice des Linux-Kernels berürt. Diese muss der Nutzer eigenändig installieren und den Kernel kompilieren. Das ist nict jedermanns Sace. Es gibt leider nur wenige Distributionen wie Hardened Gentoo, bei denen die Maintainer die Integration übernemen. Für Projekte wie Debian oder Ubuntu steen zumindest inoffizielle Kernel-Pakete mit Grsecurity zur Verfügung (siee Alle Links ). Auc Arc Linux und Linux from Scratc bieten einen Grsecurity-gepatcten Kernel an, ebenso wie die Slackware-Variante SlackPax, die aber ansceinend seit 2013 nict so rect gepflegt wird. Die großen kommerziellen Distributionen wie RHEL, SLES oder Mandriva kommen dagegen öcstens mit integriertem SELinux daer. Es gibt viele Gründe dafür, dass Grsecurity LSM nict nutzt. Abgeseen davon, dass der Hauptentwickler von Grsecurity, Brad Spengler, eine tiefe Abneigung gegen LSM pflegt, gibt es den ganz pragmatiscen Grund: Der Funktionsumfang von Grsecurity get weit über die Möglickeiten von LSM inaus (siee Alle Links ). So entält Grsecurity Maßnamen zum Abdicten Listing 1: User-bezogener Abscnitt der Policy role root ug role_transitions admin sutdown role_allow_ip /32 role_allow_ip /32 # Role: root subject /bin/ping6 o { / /bin /bin/ping6 x /etc /etc/ost.conf r /etc/osts r /etc/ld.so.cace r /etc/nsswitc.conf r /etc/resolv.conf r /lib rx /lib/modules /usr /usr/lib/libcrypto.so rx -CAP_ALL +CAP_NET_RAW bind disabled connect disabled sock_allow_family ipv6 von croot-umgebungen und scränkt den Zugang zum Kernel über /dev/mem, /dev/kmem et cetera ereblic ein. Darüber inaus ist PaX ein Bestandteil von Grsecurity. PaX bringt Härtung gegen diverse Speicerprobleme mit sic, unter anderem Address Space Layout Randomization (ASLR, ein Begriff, den das PaX- Projekt geprägt at), und verindert die Ausfürung von screibbaren Speicerbereicen (auc bekannt als Data Execution Prevention, DEP). Weitere Grsecurity-Features besteen in Trusted Pat Execution (TPE) zum Verindern der Ausfürung von Trojanern, Einscränkungen bei der Sict auf die Prozesstabelle sowie beim ptrace-systemaufruf und viele andere. Eine umfassende und übersictlice Bescreibung aller Features findet sic auf der Website des Projekts [f]. Hauptentwickler Spengler at dort auc ein gutes Tutorial zur Einfürung in RBAC interlegt [g]. Grsecurity ein praktiscer Einstieg Da Grsecurity wie scon erwänt nict Bestandteil des offiziellen Kernels ist, muss man die Patces von Hand installieren, den Kernel konfigurieren und übersetzen. Eine Scwierigkeit dabei kann darin liegen, dass die Patces für den sogenannten Vanilla -Kernel-Quellcode gelten; ein Konflikt mit den modifizierten Quellen einzelner Distributionen ist denkbar. Als Betreiber riskiert man beim Einsatz eines inoffiziellen Kernels zudem den Verlust des Supports von Distributionen wie RHEL oder SLES. Wer sic auf das (lonende) Unternemen Grsecurity einlässt, sollte daer besser professionellen Support inzuzieen. Nun kommt der eigentlic spannende Teil, wie man eine RBAC-Rictlinie erstellt. Eine Bescreibung findet man im Wiki zu Grsecurity []. Dessen Pflege ist allerdings nict optimal, wesalb man im Zweifelsfall die ausfürlice Bescreibung in der mitgelieferten Policy eranzieen muss. Ist alles installiert und einsatzbereit, gibt es zwei Möglickeiten: Entweder startet man ausgeend von der zum Softwareumfang geörenden Policy oder betreibt Grsecurity im vollen Lernmodus. Über Letzteren kann sic ein Administrator eine Policy erstellen. Man untersceidet zwiscen Full System Learning sowie rollen- und subjektspezifiscem Learning (siee unten). Ersteres berücksictigt alle Systemaktivitäten für den Lernprozess, das spezifisce Learning ziet nur die Aktivitäten bestimmter Rollen oder Subjekte eran. Der Lernprozess erfolgt so, dass das System alle Zugriffe und die dazugeörigen Parameter protokolliert. Nac dem Beenden des Lernmodus lässt sic aus dem Protokoll eine Policy erzeugen. Die befindet sic in /etc/grsec/policy, dieser Pfad ist fest vorgegeben. Full System Learning startet der Superuser mit dem Kommando gradm -F -L /etc/grsec/learning.log Zuvor muss er aber einige Passwörter setzen, nämlic für Grsecurity an sic, für die Rolle admin und für die Rolle sutdown. Dies bewerkstelligen die Kommandos gradm -P gradm -P admin gradm -P sutdown Die Passwörter (das eißt deren Has-Werte) speicert gradm in der Datei /etc/grsec/pw. One diese weigert sic Grsecurity (genauer die RBAC-Komponente), in Aktion zu treten. Hintergrund: Grsecurity wird (wenn die Policy vorliegt) mit dem Kommando gradm -E scarf gescaltet und per gradm -D deaktiviert. Letzteres auc aus dem Lernmodus erfordert das Grsecurity-Passwort. Für administrative Tätigkeiten muss man in die Rolle admin wecseln. 10 ix Kompakt 2014 Open-Source-Administration

11

12 SICHERHEIT BETRIEBSSYSTEM-SECURITY Für den Lernmodus sind zwei Dinge ser wictig: Zum Einen darf man darin keine administrativen Tätigkeiten ausfüren. Sonst lernt das System, dass privilegierte Operationen auc in den gewönlicen Nutzungsszenarien vorkommen dürfen und die daraus abgeleitete Policy fällt viel zu großzügig aus. Zum anderen sollte man das System für eine gewisse Dauer so benutzen, dass alle legitimen Nutzungsszenarien merfac durcgespielt werden. Hierzu geören alle Formen der Anmeldung am System, sei es über SSH oder auc über eine virtuelle Konsole. Ist man zu der Ansict gelangt, dass die Trainingspase alle Nutzungsszenarien abgedeckt at, kann man Grsecurity mit gradm -D deaktivieren und den Lernmodus beenden. Ruft man gradm erneut im Lernmodus auf, ängt Grsecurity die Protokolleinträge an die mit dem Parameter -L spezifizierte Datei an. Die ersten Scritte zur Policy Für das Bilden einer Policy nutzt man nun gradm -F -L /etc/ grsec/learning.log -O /etc/grsec/newpolicy. Diese Policy ist in Bezug auf die im Lernmodus durcgefürten Aktionen äußerst restriktiv. Für jeden im Lernmodus aktiven Benutzer legt Grsecurity eine eigene Benutzerrolle an. Hat beispielsweise der User Root /bin/ping6 aufgerufen, dann ersceint in der Policy ein Ausscnitt wie in Listingˇ1 gezeigt. Der Ausscnitt besagt: Es gibt eine Rolle root; diese ist eine Benutzerrolle zu erkennen an dem Rollenmodus-Flag u, das eißt, jeder Prozess mit der tatsäclicen UID von Root erält sie automatisc. Die effektive UID eines Prozesses ist ierfür irrelevant, der Wecsel in eine andere Benutzerrolle erfolgt nur dann, wenn der entsprecende Prozess den Systemaufruf setuid() verwendet. Neben Benutzerrollen gibt es noc Gruppenrollen sowie spezielle Rollen. Gruppenrollen sind durc den Modus g gekennzeicnet und funktionieren analog zu User-Rollen. Ist keine Benutzer- oder Gruppenrolle für einen Benutzer anwendbar, kommt die Default-Rolle zum Einsatz. Gibt es aufgrund der UID und der GID merere Möglickeiten für eine Rollenzuweisung, at die Benutzerrolle Vorrang vor der Gruppenrolle. Spezielle Rollen sind durc s gekennzeicnet und keiner UID oder GID zugewiesen. Zum Wecseln in diese Rollen muss man per gradm eine Rollen-Transition veranlassen. Dies erfordert in der Regel eine Autentisierung, man muss für die Rolle also ein Passwort spezifizieren. Diese Transitionen können aber auc mit Autentisierung nict willkürlic erfolgen. Zunäcst muss für eine Rolle das Nutzen von gradm und des daintersteenden Mecanismus zulässig sein. Dies kennzeicnet der Rollenmodus G. Außerdem sind alle zulässigen Transitionen in der Rictlinie aufzufüren per Rollenattribut role_transition. Im Beispiel von Listingˇ1 darf ein Nutzer aus der Rolle root in die (nict weiter aufgefürten) speziellen Rollen admin und sutdown wecseln. Ein weiteres Rollenattribut ist role_allow_ip. Es screibt vor, dass man eine Benutzerrolle (ier root) nur dann einnemen kann, wenn man sic von einer der unter diesem Attribut vermerkten IP-Adressen aus angemeldet at. Dies dürfte man in der Regel anpassen wollen, da der Lernmodus in vielen Fällen ierfür kein sinnvolles Ergebnis erzielen kann. Zu jeder Rolle geört die Spezifikation einer Reie von Subjekten entweder Programme oder Verzeicnisse. Letzteres fasst alle darunter im Dateisystembaum steenden Programme zusammen. Das Beispiel zeigt die Subjekt-Spezifikation für /bin/ping6. Dabei folgen dem Programmnamen die Subjektmodus-Flags, ier der Modus o (override). Zu den Subjektmodi später mer. Der interessanteste Teil ist die Objektspezifikation. Sie legt fest, auf welce Dateien das Subjekt wie zugreifen darf, markiert durc den Objektmodus. Neben den traditionellen Zugriffsarten r (read), w (write) und x (execute) nimmt Grsecurity eine weitere Differenzierung vor. So gibt es noc a (append), c (create), d (delete), l (link) und (ide), wobei Letzteres eine Zugriffseinscränkung bedeutet die so markierten Objekte sind für das Subjekt sclict unsictbar. Von Subjekten, Objekten und iren Flags Ein Objekt kann eine einzelne Datei oder ein Verzeicnis sein. Die Angabe eines Verzeicnisses bewirkt das rekursive Anwenden des Objektmodus auf alle inner- und unteralb liegenden Dateien und Verzeicnisse. Für das Spezifizieren mererer Objekte sind * und? als Wildcards zulässig. Für die Zugriffsregeln auf eine Datei gilt, dass ein spezifiscerer Pfad Vorrang vor einem unspezifisceren at. So ist eine Regel für /bin/ping6 spezifiscer als eine für /bin oder /, aber auc als eine für /bin/*. Listing 2: Rictlinienausscnitt zur Vererbung Listing 4: Beispiel Recte übertragen subject / { / /bin rx /usr/bin rx /lib rx /lib/modules /usr/lib rx -CAP_ALL +CAP_DAC_READ_SEARCH subject /bin/foo { /usr/libexec -CAP_DAC_READ_SEARCH +CAP_NET_ADMIN rx subject /sbin/mydaemon { / /bin /bin/rm xi /var /var/lib /var/lib/mydaemon rwcdl Listing 3: Zu stark eingescränkte Recte Listing 5: Änlice Einträge zusammenfassen subject /bin/rm o { / /bin /bin/rm x /etc /etc/ld.so.cace r /lib /lib/ld-2.15.so x /lib/libc-2.15.so rx /var /var/spool/cron/lastrun/lock wd -CAP_ALL bind disabled connect disabled subject /bin/rm o { /mydir /mydir/somefile /mydir/someoterfile /mydir/yetanoterfile subject /bin/rm o { /mydir /mydir/* wd wd wd wd 12 ix Kompakt 2014 Open-Source-Administration

13 Im Beispiel für ping6 besitzt das Objekt / den Modus, das eißt, a priori tappt das Programm in absoluter Dunkeleit. Ganz one Dateizugriffe get es aber nict. Dies beginnt mit den dynamisc gebundenen Laufzeitbiblioteken und endet bei versciedenen, DNS-bezogenen Dateien. Im Listing siet man gut die Optimierungen, die beim Ableiten der Policy stattfinden. ping6 benötigt diverse Sared Librarys aus /lib, aber nur eine einzelne aus /usr/lib. Daer ist /lib zunäcst pauscal mit rx freigegeben, kritisce Bereice wie die Kernel-Module (/lib/modules) bleiben jedoc weiter unter Verscluss. Die einzelne Bibliotek aus /usr/lib berücksictigt dagegen ein direkter Eintrag. Nac dem Festlegen der Objekte und der darauf zulässigen Zugriffe folgt eine Angabe der Capabilities, mit denen das Subjekt andeln darf. Listingˇ1 entziet ping6 zunäcst alle Capabilities und gewärt anscließend CAP_NET_RAW. Das eißt, unabängig davon, dass Root der Superuser ist, darf auc er ping6 nur mit eingescränkten Privilegien nutzen. Die letzten drei Einträge legen noc fest, dass ping6 keine UDP- und TCP-Sockets nutzen darf weder aktiv (connect) noc passiv (bind) und dass auc IPv6 erlaubt ist. Zum Abscluss einige Polierarbeiten Weitere ier nict gezeigte Möglickeiten sind die Angabe subjektbezogener Ressourcenscranken sowie PaX-Flags. Ebenfalls nict aufgefürt sind subjektspezifisce Attribute, über die sic einscränken lässt, zu welcer UID oder GID ein Programm inneralb des Subjekts wecseln darf, selbst wenn die entsprecenden Prozesse die Capabilities CAP_SET_UID bezieungsweise CAP_SET_GID besitzen. Dennoc kann man bereits gut erkennen, wie Grsecurity die Privilegien von Programmen auf das erforderlice Minimum zurectstutzen kann. Es empfielt sic, eine automatisc erzeugte Policy zunäcst zu sicten und gegebenenfalls ein wenig naczuarbeiten. Das soll zum einen unplausible Einträge in der produktiven Policy verindern. So at der Autor bei den Recercen zum Artikel festgestellt, dass das System für den SSH-Dienst in der Benutzerrolle root zu jeder IP-Adresse das Rollenattribut role_ allow_ip aufnimmt, von der aus ein Verbindungsversuc erfolgt, auc bei felgesclagener Autentifizierung. Ist das System und im Speziellen der SSH-Dienst aus dem Internet nutzbar, landen so auc die IP-Adressen von Brute-Force-Angreifern im Regelwerk. Zum anderen gilt dasselbe Problem für die connect- und bind-regeln eines Subjekts: So erzeugt der Trainingsmodus für einen Webserver für jede einzelne Adresse eine Regel. Für einen Webserver, der aus dem Internet aus erreicbar sein soll, lassen sic diese Regeln durc eine Regel wie bind /0:80 stream tcp zusammenfassen. Daneben erstellt der Lernmodus von Grsecurity rollenbezogene Subjekte für jedes verwendete Kommando. Hier kommt eine weitere Stärke der Policy-Gestaltung von Grsecurity zum Tragen Vererbung. Wie scon gesagt kann man Subjektregeln nict nur für einzelne Programme, sondern auc für Verzeicnisse erstellen. Diese Regeln werden dann rekursiv an alle Programme im Baum unteralb des Verzeicnisses vererbt. Das in Listingˇ2 gezeigt Rictlinienfragment sagt, dass es für eine (ier nict genannte) Rolle lesende und ausfürende Zugriffe auf /bin, /lib, /usr/bin und /usr/lib gewärt und dass alle Prozesse über keine Capabilities außer CAP_DAC_READ_ SEARCH verfügen. Das Programm /bin/foo bekommt zusätzlic lesende und ausfürende Recte in /usr/libexec, gleiczeitig wird im die Capability CAP_DAC_READ_SEARCH entzogen und CAP_NET_ADMIN gewärt. Zu beacten ist, dass die VeriX Kompakt 2014 Open-Source-Administration

14 SICHERHEIT BETRIEBSSYSTEM-SECURITY erbung nict für Socket-Regeln implementiert ist man muss für jedes Subjekt jeweils eigene Regeln für connect und bind spezifizieren. Soll die Vererbung für ein Subjekt nict zum Tragen kommen, ist dies durc das Subjektmodus-Flag o (override) anzuzeigen. Dann sind die Regeln für alle Objekte, beginnend mit /, vollständig anzugeben; würde man im Beispiel beim Subjekt /bin/foo den Modus o one weitere Änderung ergänzen, würde gradm die Policy mit der Begründung abweisen, dass vor der Definition des Objekts /usr/libexec zunäcst Definitionen für / und /usr erfolgen müssen. Beim Erstellen der Rictlinien aus dem Learning-Log erzeugt gradm für alle wärend der Lernpase genutzten Programme ein Subjekt mit dem Modus o. Für interaktiv via Kommandozeile aufgerufene Programme bieten sic geeignete Zusammenfassungen an, da Grsecurity sonst die Nutzungsmöglickeiten dieser Kommandos unnatürlic einscränkt, wie das Listingˇ3 zeigt. Steuern des Lernprozesses In der entsprecenden Rolle darf man mit rm nur eine einzige Datei löscen. Das kann so beabsictigt sein ist es aber in der Regel nict. Genauer gesagt, muss man zwiscen den Fällen untersceiden, in denen der Aufruf eines Kommando interaktiv oder von anderen Programmen wie cron erfolgt. In letzterem Fall kann eine derartige Einscränkung durcaus sinnvoll sein. Eine Möglickeit, die für ein Subjekt spezifizierten Recte an ein aufgerufenes Programm zu übertragen, bietet der Objektmodus i (inerit). Listingˇ4 zeigt für einen ypotetiscen Daemon, wie der seine Zugriffsrecte auf /bin/rm überträgt. Änlic stellt sic die Situation im umgekerten Fall dar: Eine Subjektdefinition wie im oberen Teil von Listing 5 wird man warsceinlic wie im unteren Teil zusammenfassen wollen. Einige Zusammenfassungen lassen sic programmatisc über Einträge in der Datei /etc/grsec/learn_config automatisieren. Eine Bescreibung findet sic im Wiki zu Grsecurity sowie in der mitgelieferten Datei learn_config. Einträge der Form always-reduce-pat /mydir/always legen beispielsweise fest, dass Grsecurity alle Zugriffe auf /mydir/always oder auf Dateien in beliebigen Unterverzeicnissen darin auf /mydir/always vereinigt. Es bildet statt jeweils einzelner Einträge in der erzeugten Policy nur einen Eintrag für /mydir/always. Andere Spielarten sind ig-reduce-pat dont-reduce-pat /mydir/ig /mydir/dont Hier findet eine Reduktion für /mydir/ig nur statt, wenn viele Zugriffe auf Dateien unteralb des Verzeicnisses erfolgen, Listing 6: include, replace und define /etc/grsec/policy: include </etc/grsec/defns> subject /bin/foo { /etc r $etc_denied $FOOLIB r subject /bin/bar { /etc r $etc_denied /usr/lib rw $FOOLIB /etc/grsec/defns: replace FOOLIB /usr/lib/foo define etc_denied { /etc/ss /etc/ssl /etc/sadow /etc/sadow- wärend keine Reduktion für /mydir/dont erfolgt. So lässt sic eine ser differenzierte Policy erzeugen. Für Anwendungen, die weitere Programme starten, lässt sic die Rectevererbung steuern. Ruft beispielsweise /bin/foo versciedene andere Programme auf, die in diesem Kontext dieselben Zugriffsrecte wie /bin/foo eralten sollen, kann man dies so ausdrücken inerit-learn /bin/foo Ein weiteres Steuern des Lernprozesses erfolgt über die Angabe besonders scutzbedürftiger Objekte wie /etc/ss, /etc/ssl, /etc/sadow oder /lib/modules. Die Angabe protected-pat ig-protected-pat /sys /etc/ss bewirkt, dass Grsecurity für jedes Programm, das auf diese Dateien zugreift, ein eigenes Subjekt anlegt. Die als ig protected gekennzeicneten Objekte eralten zudem stets das Objektmodus-Flag und sind damit allgemein unsictbar. Sind Änderungen an der Policy vorzunemen, muss man nict gleic eine vollständig neue Lernpase durclaufen. Dabei spielt es keine Rolle, ob sic das Veraltensprofil geändert at, eine Software nac einem Upgrade eine andere Dateistruktur aufweist, neue Rollen angelegt wurden oder man ein besteendes Profil verfeinern möcte. Grsecurity bietet an, für spezifisce Rollen oder Subjekte den Lernmodus zu aktivieren, wärend die Policy für alles andere scarf gescaltet bleibt. Hierzu fügt man der Rolle oder dem Subjekt das Modus-Flag l (learn) inzu, beispielsweise role pkiadmin sgl oder subject /usr/sbin/ssdˇl. Scutz vor Informationsabfluss Das Aktivieren und Deaktivieren von Grsecurity erfolgt über gradm -E -L /etc/gradm/learn.log bezieungsweise über gradm -D; das in die Policy einzubauende Fragment erzeugt das Kommando gradm -L /etc/gradm/learn.log -O /etc/grsec/newpolicy. Darüber inaus bietet Grsecurity einige spannende Funktionen zur weiteren Härtung, die der Lernmodus nict aktiviert. So lassen sic vor allem in der Subjektdefinition Modus-Flags angeben, die der fortgescrittenen Härtung dienen. Diese Flags stellt der näcste Abscnitt vor. Normalerweise sind versciedene Attribute eines Prozesses über per /proc/<pid>/ erreicbare Pseudodateien allgemein einsebar Tools wie ps oder top nutzen diese intensiv. Grsecurity scränkt die Sictbarkeit von /proc onein stark ein, sodass ein Prozess, der nict einer speziellen Gruppe angeört (meist GID 10, weel ) nur Informationen über Prozesse mit derselben UID einseen kann. Möcte man noc inneralb einer UID zwiscen versciedenen Prozessen untersceiden, muss man das Subjektmodus-Flag (ide) für Programme verwenden, deren Prozessinformationen unsictbar sein sollen. Diese lassen sic dann nur von Prozessen einseen, deren Modus das Flag v (view) entält. Daneben lassen sic versciedene Informationen über Prozesse zu scützen, one diese Prozesse zu verbergen. Das Subjektmodus-Flag d verindert den Zugriff auf die File-Deskriptoren, die Speicerbelegung, die vollständige Kommandozeile (einscließlic aller Parameter) sowie die Umgebungsvariablen. Ein aufebendes Flag analog zu v existiert jedoc nict. Dieser Modus bietet sic vor allem für Programme an, die vertraulice Informationen nutzen, zum Beispiel Passwörter oder Sclüssel. In eine änlice Rictung zielt das Subjektmodus-Flag A zum Scutz von Sared Memory. Dieser Mecanismus kommt oft zur effizienten Interprozesskommunikation zum Einsatz. Sind die 14 ix Kompakt 2014 Open-Source-Administration

15 Parameter für einen Sared-Memory-Abscnitt bekannt, kann ein Prozess derselben UID darauf zugreifen. Das Flag A bewirkt, dass ausscließlic Prozesse (das eißt Objekte) in diesem Subjekt auf das Sared Memory des Subjekts zugreifen können. Das Anwendungsszenario änelt dem von d. Scutz der Systemintegrität Für den Umgang mit unbotmäßigen Programmen dient das Subjektmodus-Flag K. Es legt fest, dass das System einen unter den Objekten eines Subjekts aufgefürten Prozess terminiert, wenn er wegen einer Regelverletzung eine Grsecurity-Warnung ervorruft. Noc bracialer get Grsecurity beim Subjektmodus- Flag C vor: Die Software fürt für jeden Prozess die IP-Adresse mit, auf die sic dessen Ausfürung zurückfüren lässt. Beim Auftreten einer Grsecurity-Warnung beendet Grsecurity sämt - lice mit dieser IP-Adresse assoziierten Prozesse unabängig davon, ob sie zur Regelverletzung beigetragen aben oder nict. Grsecurity nutzt das Konzept für ausfürbare, aber nict screibbare Programmdateien in Form von Trusted Pat Execution (TPE). TPE lässt sic auf versciedene Arten nutzen, dieser Artikel bescränkt sic auf eine Bescreibung der Nutzung im Kontext von RBAC und MAC. Hierfür dient das Flag T. Als Rollenmodus-Flag fürt T dazu, dass Nutzer in der Rolle keine screibbaren Programme ausfüren können. Die Prüfung erfolgt dabei zur Laufzeit. Als Subjektmodus-Flag bewirkt T, dass Grsecurity RBAC nur dann aktivieren kann, wenn die darunter gefassten Programme und Skripte durc ein beliebiges anderes Subjekt screibbar sind; ausgenommen iervon sind Subjekte in administrativen Rollen. Die Prüfung erfolgt zum Zeitpunkt der Aktivierung von Grsecurity RBAC. Ein weiteres Subjektmodus-Flag dient dem Scutz vor trojaniscen Sared Libraries: s. Es aktiviert einen Mecanismus, der auc beim Aufruf von SUID-/SGID-Programmen zum Tragen kommt. Der setzt das Prozessattribut AT_SECURE mit der Folge, dass unter anderem der Linker (/lib/ld-linux.so) die sicereitskritiscen Umgebungsvariablen LD_LIBRARY_PATH, LD_PRELOAD, LD_AUDIT et cetera ignoriert. Strukturieren der Policy Unter /etc/grsec/policy findet sic die von Grsecurity genutzte Policy. Bei vielen Rollen, Benutzern und Subjects kann die Datei jedoc rect unübersictlic werden. Daer darf man die Policy in merere Dateien aufteilen, die die Direktive include in die Hauptdatei einbindet. So bietet es sic an, die Definition der einzelnen Rollen in separate Dateien auszulagern. Daneben bietet Grsecurity die Option, über die Direktive replace Platzalter zu definieren, sowie über define oft verwendete Blöcke zu benennen. Listingˇ6 zeigt ein Beispiel für den Einsatz der drei genannten Direktiven. Über diese Direktiven lässt sic selbst eine komplexe Policy noc übersictlic gestalten. Wer noc raffiniertere Möglickeiten zur Gestaltung brauct, etwa die Nutzung von Templates für versciedene Rollen, der sollte auf Makroprozessoren wie m4 zurückgreifen. Fazit Onlinequellen T[a]Ebury-Rootkit [b] Center for Internet Security [c] J. Edge: Te future for Grsecurity [d] M. Fox et al.: SELinux and grsecurity [e] NixCraft: Linux Kernel Security [f] Funktionsübersict [g] B.Spengler: RBAC-Tutorial [] Grsecurity Wikibook uploads/2014/03/operation_windigo.pdf bencmarks.cisecurity.org/downloads/ lwn.net/articles/313621/ SELinuxCaseStudy.pdf grsecurity.net/features.pp grsecurity.net/rbac_tutorial.pdf en.wikibooks.org/wiki/grsecurity Grsecurity weist viele gute Ansätze zur Systemärtung auf, von denen der Artikel nur eine Auswal anreißen konnte. Als dickster Minuspunkt ist zu vermerken, dass Grsecurity nict Bestandteil des offiziellen Kernels ist. Dies bedeutet beispielsweise, dass IT-Betreiber, die aus Support-Gründen ein Linux von der Stange nemen müssen, nur unter erscwerten Bedingungen in den Genuss von Grsecurity kommen wenn überaupt. Ein weiterer kritiscer Punkt bestet in der Abängigkeit von Brad Spengler, dem Hauptentwickler von Grsecurity. Die Zukunft des Projekts stand scon mermals auf der Kippe, aber zumindest derzeit gibt es genügend Sponsoren, die über ire Unterstützung die Pflege und Weiterentwicklung von Grsecurity ermöglicen. Darüber inaus lässt die verfügbare Dokumentation oft noc an Klareit zu wünscen übrig. Obwol Grsecurity eigentlic relativ leict zu bedienen ist, erfordert die Klärung von Details zur Wirkung versciedener Mecanismen bisweilen einige Experimente. Aus Sict der Policy wäre es wünscenswert, automatisce Transitionen in spezielle Rollen zu ermöglicen; dies ist beispielsweise unter SELinux möglic. Ideal wäre es, wenn man eine derartige Transition über eine Spezifikation versciedener Programme veranlassen könnte. Im besteenden Regelwerk lässt sic dies nict ausdrücken Brad Spengler at dazu auc durcblicken lassen, dass er darin keinen Gewinn siet. Ein weiteres Manko bestet darin, dass ein Prozess in der Regel nict feststellen kann, in welcer Rolle er sic gerade befindet. Mittelfristig wäre es auc erforderlic, IPv6-Adressierung zu integrieren, derzeit lässt sic lediglic die komplette Nutzung gewären oder verweigern. Zu wünscen wäre es ebenfalls, den Vererbungsmecanismus (zumindest optional) für Subjekte auf Socket-Regeln auszudenen. Doc trotz aller Kritik kommt man nict an der Feststellung vorbei, dass Grsecurity ein ectes Higligt der IT-Sicereit ist und dass die vom Team um Brad Spengler gescaffene Software Hand und Fuß at. Auf dem Weg zu einer ecten Härtung für den Einsatz in potenziell feindseligen Umgebungen jenseits des scablonenaften Abarbeitens üblicer Härtungs-Guides stellt Grsecurity zumindest einen großen Sprung nac vorn dar. (avr) Dr. Safuat Hamdy arbeitet als Security Consultant bei der Secorvo Security Consulting GmbH in Karlsrue. Alle Links: x ix Kompakt 2014 Open-Source-Administration 15

16 SICHERHEIT COMPLIANCE-MANAGEMENT Systemüberprüfungen mit OpenSCAP Verteilte Absicerung Torsten Scerf Für immer mer Firmen ist Compliance-Management ein wictiger Aspekt bei der Einrictung, Wartung und Bescreibung irer IT-Landscaft. In der Praxis gestaltet sic die Umsetzung jedoc nict immer einfac. Hier versprict SCAP Abilfe, das Security Content Automation Protocol. Damit und mit den Tools aus dem OpenSCAP-Paket lässt sic die Einaltung von IT-Rictlinien komfortabel überprüfen. Das Tema Compliance-Management umfasst viele versciedene Temengebiete und lässt sic demzufolge unter untersciedlicsten Aspekten betracten. Vereinfact gesprocen fasst man unter dem Begriff alle in einem Unternemen eingericteten Maßnamen und Prozesse zusammen, die die Einaltung geltender Gesetze und Rictlinien sicerstellen sollen. In diesem Umfeld existiert eine Reie international anerkannter Zertifizierungen, besonders wictig sind ier die Evaluation Assurance Level der Common Criteria (CC EAL, siee Onlinequellen, [a]) sowie die ISO Zertifizierung [b]. In Deutscland kann das Bundesamt für Sicereit in der Informationstecnik (BSI) beide vergeben, wenn die zu evaluierende IT-Landscaft den Anforderungen entsprict. Für ISOˇ27001 muss sie konform zu den Anforderungen des BSI-IT-Grundscutzes sein, für die EAL-Zertifizierung die Anforderungen der einzelnen Common-Criteria-Level erfüllen. Dabei setzen die meisten Zertifizierungen bestimmte Systemkonfigurationen voraus. Diese wiederum basieren auf Rictlinien sowie diversen Konfigurationsbescreibungen für ein IT-System, die wie bei EAL teilweise eine bestimmte Hardwarekonfiguration umfassen können. Bei ISO kommen weitere Gesictspunkte inzu, beispielsweise sind ier auc ITIL-relevante Temen auf dem Prüfstand. Die Systemkonfiguration bildet ier also nur einen kleinen Teilbereic der Zertifizierungsanforderungen. Dieser Artikel beandelt primär die zu erfüllenden Rictlinien zur Systemkonfiguration, strebt man eine entsprecende Zertifizierung an oder möcte man die eigenen Systeme einfac unter 16 ix Kompakt 2014 Open-Source-Administration

17 Best-Practice-Gesictspunkten konfigurieren. Von diesen Vorgaben existiert eine ganze Reie. Teilweise überscneiden sic diese sogar oder sprecen Empfelungen aus, die in einer anderen Rictlinie komplett felen. Hier muss man vor dem Hintergrund der angestrebten Zertifizierung darauf acten, welce Rictlinie für die eigene Systemlandscaft am eesten passt. Untersciedlice Rictlinien In SCAP berücksictigte Standards CCE CPE CVE CVSS OVAL XCCDF ab Version 1.2 zusätzlic ARF CCSS OCIL TMSAD Common Configuration Enumeration Common Platform Enumeration Common Vulnerabilities and Exposures Common Vulnerability Scoring System Open Vulnerability and Assessment Language Extensible Configuration Cecklist Description Format Asset Reporting Format Common Configuration Scoring System Open Cecklist Interactive Language Trust Model for Security Automation Data In OVAL-Repository finden sic aktuell mer als 22ˇ000 Definitionen; ein Großteil davon entfällt auf Windows und Unix/Linux (Abb.ˇ1). So sind beispielsweise für sämtlice Systeme des US-Verteidigungsministeriums die Secure Tecnical Implementation Guides (STIG) [c] der DISA FSO (Defense Information Systems Agency, Field Security Operations) maßgebend. Der Standard für Systeme in der Kreditkartenindustrie ist ingegen PCI-DSS, der Payment Card Industry Data Security Standard [d]. Daneben gibt es noc allgemeinere Härtungsrictlinien wie die Security Configuration Bencmarks vom Center for Information Security (CIS) [e]. Alle diese Rictlinien bescränken sic primär auf die Bescreibung, welce Einstellungen auf einem IT-System vorzunemen sind, damit es als sicer gilt und somit dem jeweiligen Standard entsprict. Aspekte, die unter dem allgemeinen Begriff des IT-Service-Managements fallen, oder auc globale Fragen der pysiscen Gebäudesicereit sind nict Gegenstand solcer Härtungsmaßnamen. Im Folgenden get es vor allem um die STIG der DISA FSO und die CIS Security Configuration Bencmarks, da es sic bei diesen um den De-facto-Standard bei allgemeinen Härtungsrictlinien für Linux-Systeme andelt. Alle ier getätigten Aussagen lassen sic aber genauso auc auf andere Rictlinien anwenden. Beide Organisationen stellen sogenannte Security Re-