Lade Inhalt...

Redhat Enterprise Linux Hardening Guide

Fachbuch 2006 14 Seiten

Informatik - Angewandte Informatik

Leseprobe

Vorbemerkungen

Das verwendete Redhat System entspricht einem „Redhat Enterprise Linux Application Server“ (RHEL AS) der Version 4.

Redhat Enterprise Linux bietet in seiner neuen Version 4 zwei interessante Sicherheitsfeatures, die im Vorfeld betrachtet werden sollen.

Zum einen wird standardmäßig die Verwendung von SELinux bei der Installation des Systems vorge- merkt. SELinux (Security Enhanced Linux) ist eine Erweiterung des Linux-Kernels. Es implementiert die Zugriffskontrollen auf Ressourcen im Sinne

einer Mandatory Access Control. SELinux wurde ursprünglich von der NSA entwickelt.

Mandatory Access Control (MAC) ist ein Konzept für die Kontrolle und Durchsetzung von Zugriffs- rechten, bei der die Entscheidung über Zugriffs- berechtigungen nicht auf der Basis Identität des Akteurs (Benutzers, Prozesses) und des Objektes (Datei, Gerät) gefällt wird.

Im MAC Konzept wird jedem Objekt (Doku- ment) einer Schutzstufe zugeordnet. Die einzelnen Schutzklassen unterteilen die Objekte in “Schich- ten” (vertikale Gliederung). Jedem Subjekt (Benut- zer) wird nun ebenfalls eine Schutzstufe zugewiesen (Vertrauen). Ein Subjekt darf nur dann auf ein Objekt zugreifen, wenn die Schutzstufe des Sub- jektes mindestens so hoch ist wie die Schutzstufe des Objektes.

Die Konfiguration eines solchen Konzeptes erweist sich als außergewöhnlich aufwendig. Daher wird im Redhat Enterprise Linux ein Mittelweg einge- schlagen, bei dem zwar sicherheitskritische Anwen- dungen geschützt werden, aber sonstige Anwen- dungen keinen Einschränkungen unterliegen.

Des weiteren verwendet Redhat Enterprise Linux einen Speicherschutz namens Exec-Shield.

Exec-Shield schützt vor Angriffen, die Adressen überschreiben oder eigene Befehle einschleusen (Buffer-Overflows). Exec-Shield wurde als Ker- nelpatch eingebracht und arbeitet im Idealfall für Anwendungen transparent. Unter anderem setzt Exec-Shield für jedes Programm den höchsten Adresswert fest, der noch Ausführbares enthält.

Exec-Shield kann dadurch häufig vor absolut neuen Exploits, den so genannten 0-day Exploits (gespro- chen Zero-Day also Tag 0), die Buffer-Overflow

-

Schwachstellen ausnutzen, schützen. Exec-Shield ist allerdings per default deaktiviert. Die Aktivierung per Kernelparameter wird in die- sem Dokument beschrieben.

Das Dokument kann sowohl als Schritt für Schritt Anleitung verstanden werden, als auch als Samm- lung diverser Modifikationen, hinführend zu einem hinreichend sicheren System.

Es gilt in der Praxis immer abzuwägen, inwiefern einer der beschriebenen Mechanismen angewandt werden sollte oder nicht. Wenngleich die Angst um eine Anwendung, die sich eventuell unter

den restriktiven Bedingungen untypisch verhält, schwerer wiegt als die Angst vor dem Risiko einer Kompromittierung des Systems, müssen folgende Schritte in Bezug auf Systeme in hochsicheren Um- gebungen als Basishärtung verstanden werden.

Um die Arbeit mit dieser Anleitung zu erleichtern wurde jedem Konfigurationsschritt eine Skala mit Angaben zur Wichtigkeit, zum Risiko und Auf-

wand beigefügt. Hierdurch kann abgewägt werden, ob sich das Risiko oder der Aufwand gegenüber der Wichtigkeit eines Konfigurationsschritts rechtfer- tigt.

Bei der hier vorliegenden Beschreibung wird lediglich auf die Härtung des zugrundeliegenden Betriebssystems mit seinen Standardkomponenten eingegangen. Da jedoch immer mehr Angriffe weg vom Betriebssystem, hin zu den Anwendungen an sich führen, ist es unerlässlich, dass auch die auf dem System installierten Anwendungen einer Här- tung unterzogen werden.

Das Dokument befindet sich noch im Aufbau. Hilfreiche Hinweise, Korrekturen oder Vorschläge zu diversen Ergänzungen sind daher willkommen und können an folgende Email-Adresse gerichtet werden.

Autor: Florian.Roth@email.de

Installation

In diesem Kapitel werden Hinweise dazu gegeben, inwiefern, speziell bei der Installation des Redhat Systems, diverse Einstellungen vorgenommen wer- den können, welche die Systemsicherheit erhöhen.

1. Kickstart

Kickstart ist ein Programmpaket, welches es er- möglicht, diverse Installationsparameter festzule- gen und somit eine Installation weitestgehend auto- matisch ablaufen zu lassen. In unserem Fall benutzen wir Kickstart jedoch dazu, wichtige Parameter in Bezug auf die Sicher- heit des Systems im Vorfeld festzulegen, und somit durch eine einheitliche Installation, eine einheitlich Sicherheitskonfiguration anzuwenden.

Um Kickstart auf einem Redhat System zu in- stallieren verwendet man folgenden Befehl in der Konsole (root).

# up2date -i system-config-kickstart

Danach kann es über das Menü ausgewählt wer- den.

Eine adäquate Kickstart Konfiguration ist bei- spielsweise folgende.

#Generated by Kickstart Configurator #platform=x86, AMD64, oder Intel EM64T #System language

lang de_DE

#Language modules to install langsupport en_GB --default=de_DE #System keyboard

keyboard de-latin1-nodeadkeys #System mouse

mouse

#System timezone

timezone Europe/Berlin #Root password

rootpw --iscrypted $1$IgDOxwk9$rOZmHhegtd L95BTDADO5m/

#SELinux

selinux --enforcing

#Reboot after installation reboot

#Install OS instead of upgrade install

#Use CDROM installation media cdrom

#System bootloader configuration bootloader --location=mbr

#Clear the Master Boot Record zerombr yes

#Partition clearing information clearpart --all --initlabel

#System authorization infomation auth --useshadow --enablemd5 #Network information

network --bootproto=dhcp --device=eth0 #Firewall configuration

firewall --enabled --trust=eth0 --ssh #Do not configure XWindows

skipx

#Package install information %packages --resolvedeps

@ base-x

@ gnome-desktop @ editors

@ server-cfg @ admin-tools @ system-tools

Abbildung in dieser Leseprobe nicht enthalten

Die erzeugte Kickstart Konfiguration kann nun auf unterschiedliche Weise zum Einsatz gebracht wer- den. Zu Installation des Redhat Systems legt man CD1 der Installationsmedien ein und verwendet bei der Eingabeaufforderung folgende Ausdrücke.

Diskette

linux ks=floppy

CD

linux ks=cdrom:/ks.cfg

HTTP

linux ks= Error! Hyperlink reference not valid. >/<path>

NFS

linux ks=nfs:<server>:/<path>

Konfiguration

Folgend werden diverse Konfigurationspunkte am System beschrieben, die zu einem höheren Sicher- heitslevel beitragen.

1. BIOS Passwort

Ein BIOS Passwort ist zu vergeben.

2. Grub Passwort

Ebenso kann der Bootloader Grub mit einem Passwort versehen werden. Die folgenden Schritte beschreiben diesen Prozess.

/sbin/grub

grub> md5crypt Password: ****

Encrypted: $1$HXkKy0$xpLu8eJffYgM0uosS. ELh1

grub> quit

Daraufhin wird die folgende Zeile unter /boot/ grub/grub.conf hinzugefügt.

password -md5 $1$HXkKy0$xpLu8eJffYgM0uosS .ELh1

Abbildung in dieser Leseprobe nicht enthalten

3. root-Account

Oftmals wird zwar ein starkes Passwort für den User root vergeben, doch wird zumeist verkannt, dass der Useraccount auch auf andere Weise, wie beispielsweise durch ein Exploit, übernommen werden kann.

Für diesen Fall gilt es auszuschließen, dass der User root zu viel Handlungsspielraum besitzt.

Zuerst werden die Login Möglichkeiten beschränkt.

# echo console > /etc/securetty

Es wird ein neuer Account erzeugt, der einen nicht leicht zu erratenden Namen besitzt. (Security by Obscurity)

# adduser sadmin1 # passwd sadmin1

Daraufhin wird in der Datei /etc/sudoers ein neuer Eintrag erzeugt, der wie folgt lautet.

sadmin1 ALL=(ALL) ALL

Danach kann der root-Account stark beschränkt werden, denn es besteht nun ein „sudo“-Account der über die Rechte von root verfügt.

In der Datei /etc/passwd wird daher die erste Zeile insofern abgeändert, dass dem user root keine Lo- gin Shell zur Verfügung gestellt wird.

root:x:0:0:root:/root:/sbin/nologin

Alle zukünftigen Arbeiten am System werden mit dem User sadmin1 durchgeführt. Ein beispielhafter Aufruf (als User „sadmin1“) eines sonst nur root zugänglichem Programm sähe daher folgenderma- ßen aus.

# sudo up2date

4. Updates

Um vom Redhat Network Updates laden zu kön- nen, muss zunächst der PGP-Schlüssel zum verifi- zieren der Signaturen installiert werden.

Bei gemounteter CD1 der Installationsmedien ist folgender Befehl zu verwenden.

# sudo rpm --import /mnt/cdrom/RPM-GPG- KEY

Danach können die Updates aus dem Redhat Net-

Abbildung in dieser Leseprobe nicht enthalten

work bezogen werden. Dabei ist darauf zu achten, dass das System im Redhat Network einem Chan- nel zugeordnet ist.

# sudo up2date -u

5. Passwörter

Erfahrungsgemäß wird in Bezug auf Passwörter immer von einer Mindestlänge und Mindestkom- plexität gesprochen. Leider sorgen diese Anforde- rungen meist dafür, dass das Passwort entweder aufgeschrieben werden muss oder nicht dem entspricht, was sich der Autor ursprünglich bei der Erstellung der Richtlinien gedacht hat.

Häufig werden Passwörter verwendet, die folgen- dermaßen geartet sind.

Abbildung in dieser Leseprobe nicht enthalten

Zwar entsprechen die Passwörter in den Beispielen der Richtlinie des jeweiligen Systems, doch sind diese Verfahrensweisen so weit verbreitet, dass viele in Untergrundkreisen kursierenden Programme zur Erzeugung von „Dictionaries“ um Funktionen erweitert wurden, die eben solche Wörter erzeugen. Weitaus bessere Methoden zur Erzeugung von Passwörtern sind unter anderem folgende.

Anfangsbuchstaben

Man verwendet einen Satz und extrahiert die Anfangsbuchstaben. Beispielsweise würde der Satz „Sprich Freund und tritt ein“, bei dem man die ersten beiden Buchstaben extrahiert das Passwort „SpFruntrei“ erzeugen, welches in keinem Wörter- buch zu finden ist.

Ersetzung

Zwar existieren teilweise schon Programme, welche gezielt die Ersetzung von Buchstaben nachahmen, jedoch ist diese Methode immer noch als ebenso einfach wie effektiv anzusehen.

Man verändert das Passwort in diesem Fall so, dass man Buchstaben des Wortes durch Sonderzeichen oder Zahlen ersetzt. Beispielsweise würde das der Satz „Am Anfang war das Wort“ zu folgendem

Passwort „@m@nf@ngw@rd@$W0rt“ oder das Wort „Matrix“ zu „M@tr!ck$“. Die Ersetzung muss nicht immer gleich aussehen. Je nachdem, wie der Benutzer Ersetzung vornimmt, kann aus „Matrix“ auch das Passwort „M4tr1ck§“ generiert werden.

Vorteil der oben beschriebenen Verfahren ist zum einen, dass das Passwort (auch nicht zum Teil!) in einem Wörterbuch (Dictionary) zu finden und zum anderen leicht zu merken ist. Die Verwendung eines solchen Passworts wird für ein umfassendes Sicherheitskonzept als grundlegend angesehen.

Komplexe Passwörter, die jedoch auf einem Zettel oder schlimmstenfalls in einer Datei auf einer Fest- platte abgespeichert werden gehören nicht (!) in ein als hinreichend sicher zu bewertendes Sicherheits- konzept.

Zur Überprüfung der Passwörter kann das Pro- gramm „john“ eingesetzt werden.

Das Programm kann von „http://www.openwall. com/john“ bezogen werden.

# tar -xvzf john-1.6.tar.gz # cd john-1.6/src

# make linux-x86-any-elf # cd ../run

# sudo ./john /etc/shadow

Abbildung in dieser Leseprobe nicht enthalten

6. Klartextprotokolle

Die Verwendung von Klartextprotokollen sollte weitestgehend vermieden werden. Beispielweise ist vom Einsatz eines Telnet-Zugangs abzusehen.

Statt der Protokolle POP3 oder HTTP, sollten die Protokolle „POP3 over SSL“ und „HTTPS“ einge- setzt werden.

Jede unverschlüsselte Verbindung kann eventuell Passwörter im Klartext übertragen. Beispielsweise wird bei POP3 das Anmeldepasswort des Nutzers immer im Klartext zum Serverdienst übertragen. Auch in geswitchten Netzen können solche Ver- bindungen abgehört werden. Daher ist von deren Verwendung, soweit es möglich ist, unbedingt abzusehen.

Beispiel zum Abhören einer POP3 Anmeldung

# sudo /usr/sbin/tcpdump -A | grep PASS

Abbildung in dieser Leseprobe nicht enthalten

7. SSH

Bei der Verwendung des SSH-Dienstes ist die Au- thentifizierung per öffentlichem Schlüssel (public Key) gegenüber der Authentifizierung per Passwort vorzuziehen.

Zuerst muss die Datei /etc/ssh/sshd_config bearbei- tet werden.

Port 22

Protocol 2

hostkey /etc/ssh/ssh_host_rsa_key hostkey /etc/ssh/ssh_host_dsa_key

RSAAuthentication yes PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys X11Forwarding no

Auf dem entfernten Administrationssystem sollten jetzt folgende Schritte ausgeführt werden.

(als user, der später zugreifen will) # ssh-keygen -t rsa

# cat ~/.ssh/id_rsa.pub | ssh sadmin1@ remotehost ‘cat - >> ~/.ssh/authorized_ keys’

Danach kann die Passwortauthentifizierung auf dem Serversystem ausgeschalten werden.

(Datei /etc/ssh/sshd_config) PasswordAuthentification no

Daraufhin muss der SSH-Serverdienst neu gestartet werden.

# sudo /etc/init.d/sshd restart

Von jetzt ab, kann sich der Remote-Admin nur noch per öffentlichem Schlüssel authentifizieren. Sollte es dabei zu Problemen kommen, liegt das Problem oft an Zugriffsrechten im Verzeichnis ~/.ssh/

In einem solchen Fall kann beim Anmelden per SSH die Debugging-Ausgabe zur Fehlersuche ver- wendet werden.

# ssh -vvv sadmin1@remotehost

Abbildung in dieser Leseprobe nicht enthalten

# sudo tail -20 /var/log/secure

Auf dem Serversystem liefert ein Blick in die Datei

/var/log/secure eventuell nützliche Hinweise.

8. Sonstige Dienste

Die zu startenden Dienste sollten einer Prüfung unterzogen werden, ob ihre Ausführung wirklich als notwendig zu bewerten ist.

Die Administration erreicht man durch folgendes Kommando.

# sudo system-config-services

Abbildung in dieser Leseprobe nicht enthalten

9. Security Level Konfigurieren

Redhat Enterprise Linux stellt eine grafische Ober- fläche zur Security-Konfiguration bereit.

# sudo system-config-securitylevel

Hier können Einstellungen zur integrierten Fire- wallfunktion und zum integrierten SELinux vorge- nommen werden.

Abbildung in dieser Leseprobe nicht enthalten

Die Konfiguration der Firewall erweist sich als sehr rudimentär, kann aber bei sehr einfachen Konfigurationsvarianten ausreichen.

Die Konfiguration von SELinux ist in den Stan- dardeinstellungen brauchbar. Für einzelne Dienste können Beschränkungen vorgegeben oder entfernt werden.

Abbildung in dieser Leseprobe nicht enthalten

10. Erweiterte Firewallkonfiguration

Für eine detailliertere Firewallkonfigurationen bietet sich das Paket „Firestarter“ an, welches als fertiges Paket für RHEL 4 von der Website bezogen werden kann.

http://www.fs-security.de/download.php

Nach dem Download wird Firestarter wie folgt installiert.

# sudo rpm -Uvh firestarter-1.0.3-1.i386. rpm

Danach kann Firestarter entweder über das Menü unter „Systemwerkzeuge“ oder per Kommandozeile aufgerufen werden.

# sudo firestarter

Abbildung in dieser Leseprobe nicht enthalten

Daraufhin bietet Firestarter einen Installations-

Agenten, der Grundlegendes festlegt. In dieser Zeit verfügt die Firewall noch über keine Funktion. Die Konfiguration erweist sich als sehr intuitiv und dennoch umfassend. Die Konfiguration erklärt sich weitestgehend selbst, es muss jedoch auf jeden Fall darauf geachtet werden, dass in hochsicheren Umgebungen zwingend der „Whitelist-Verkehr“ eingesetzt wird.

Bei der Aktivierung des „Whitelist-Verkehrs“ wer- den automatisch wichtige Dienste wie ausgehende DNS-Anfragen etc. eingetragen, was sehr hilfreich ist. Gegebenfalls sollten diese automatischen Re- geln aber geprüft werden.

Sollte über den Firestarter hinaus weiterer Konfigurationsbedarf bestehen, wird empfohlen, mit dem Programmpaket „FWBuilder“ eine an das Dashboard von Checkpoint erinnernde Konfigurationsoberfläche einzusetzen.

http://www.fwbuilder.org

Abbildung in dieser Leseprobe nicht enthalten

/etc/sysctl.conf eingetragen.

Folgende Parameter sollten entweder abgeändert oder hinzugefügt werden.

Abbildung in dieser Leseprobe nicht enthalten

FWBuilder

Abbildung in dieser Leseprobe nicht enthalten

11. Kernel Parameter

Über diverse Kernelparameter kann die Systemsi- cherheit zusätzlich erhöht werden. Die Kernelpara- meter aktivieren bzw. deaktivieren diverse Funkti- onen des Kernels.

Die Kernelparameter werden hierzu in der Datei

# Verhindert das Weiterleiten # von IP-Paketen

net.ipv4.ip_forward = 0

# IP Spoofing Schutz

net.ipv4.conf.default.rp_filter = 1

# Ping Requests ignorieren

net.ipv4.icmp_echo_ignore_all = 1

# Source Routing Ablehnen

net.ipv4.conf.default.accept_source_route = 0

# Keine ICMP Redirects

net.ipv4.conf.all.accept_redirects = 0

# Ignoriere Broadcastsanfragen

net.ipv4.icmp_echo_ignore_broadcasts = 1

# Deaktiviert Anfragen an das

# System Debugging

kernel.sysrq = 0

# Aktiviert TCP Syncookies Schutz net.ipv4.tcp_syncookies = 1

# Logt Seltsame Error Messages net.ipv4.icmp_ignore_bogus_error_re- sponses = 1

# Logt gespoofte, source routed und redi- rected packets

net.ipv4.conf.all.log_martians = 1

Nach den Änderungen an der Datei ist ein Neu- start des Systems notwendig.

Abbildung in dieser Leseprobe nicht enthalten

12. Exec Shield

Infos

http:// www.redhat.com/f/pdf/rhel/WHP0006US_ Execshield.pdf

Um die in RHEL 4 mitgelieferte Exec-Shield Funk- tionalität nutzen zu können, muss ebenso ein

Kernelparameter gesetzt werden. Den aktuellen

Exec-Shield-Status des Kernels erfährt man mittels folgendem Kommando.

# cat /proc/sys/kernel/exec-shield

Die Bedeutungen der Werte sind wie folgt definiert.

exec-shield=0

Immer deaktiviert

exec-shield=1

Per default deaktiviert, außer für Anwendungen, die es gezielt aktivieren

exec-shield=2

Per default aktiviert, außer für Anwendungen, die es gezielt deaktivieren

exec-shield=3

Immer aktiviert

In einem hochsicheren System muss der Kernelpa- rameter zumindest auf einen Wert von „2“ gesetzt werden. In Systemen, in denen Anwendungen betrieben werden, bei denen nicht bekannt ist, wie sie auf den Speicherschutz reagieren, sollte (wenn möglich) die Anwendung eine gewisse Zeit mit dem Speicherschutz (Parameter 2 oder 3) getestet werden. Wenn keine Zeit zum Testen zur Verfü- gung steht, kann der per default eingestellte Wert „1“ so belassen werden.

In diesem Modus ist der Speicherschutz allerdings nur unzureichend in Verwendung, wodurch dir Gefahr von 0-day Exploits weiterhin bestehen bleibt.

Um gezielt die Ausführung von Anwendungen für Exec-Shield zu aktivieren, muss ein nicht im RHEL 4 integriertes Tool des Exec-Shield Entwicklers benutzt werden.

# wget http://www.nleinternet.net/doc/ kernel-doc-2.2.15/secure/chstk.c

# gcc chstk.c -o chstk

# ./chstk

(gegebenfalls kopieren und mittels sudo ausführen)

# sudo cp chstk /usr/sbin # sudo /usr/sbin/chstk

Abbildung in dieser Leseprobe nicht enthalten

13. Logwatch

Das Software-Paket “LogWatch” analysiert über einen Cronjob die Log-Dateien des Servers-Systems und sendet dem Systemadministrator eine Zusam- menfassung der Auffälligkeiten per Mail.

Das Programmpaket wird auf Redhat Systemen standardmäßig installiert. Ein cron Skript ist eben- so schon vorhanden und wird täglich ausgeführt. Einem entfernten Mailaccount können dadurch wichtige Informationen des Systems übermittelt werden. Folgende Einstellungen sind dazu in der Datei /etc/log.d./logwatch.conf vorzunehmen.

MailTo = responsible@dmznet.kunde.de Detail = Low

Abbildung in dieser Leseprobe nicht enthalten

14. Bastille Hardening Program (optional)

Bei Bastille Linux handelt es sich um einen Ver- such, durch Code-Modifikationen ein bestehendes Linux/Unix-System gegen Sicherheitslücken und Angriffe zu härten.

Die Initiatoren des Projekts, John Lasser und Jay Beale, konnten bei der Entwicklung aus bereits vorhandener Expertise im Härten von Solaris- und

Abbildung in dieser Leseprobe nicht enthalten

Linux-Systemen zehren. Als Basis für die Imple- mentierung von Bastille Linux nutzen sie die Maß- gaben von Security-Instanzen wie SANS oder Kurt Seifried. Daneben verwerten sie nach eigener Aus- sage jede nur erreichbare Informationsquelle zur laufenden Weiterentwicklung von Bastille Linux.

Download

http://www.bastille-linux.org/running_bastil- le_on.htm

# sudo rpm -Uvh Bastille-3.0.8-1.0.no- arch.rpm

Des Weiteren wird Perl-Tk oder Perl-Curses für die Konfiguration des Bastille Systems vorausgesetzt.

Download

http://tinyurl.com/bh2qr

# sudo rpm -Uvh --nodeps perl-Tk-804.027-

9.el4.at.i386.rpm

Danach kann Bastille gestartet werden.

# sudo /usr/sbin/bastille -x

Bastille Linux wird leider nur in englischer Sprache angeboten. Es ermöglicht an Hand diverser Fragen- kataloge zu relevanten Themen eine Härtung des Systems vorzunehmen, auch wenn kein weit rei- chendes Expertenwissen zu einem Themenbereich vorhanden ist.

Bastille kann somit als eigenständiges Hardening- Tool angesehen werden, welches zusätzlich einge- setzt werden kann, aber nicht muss. Es dient vor allem der schnellen und unkomplizierten System- härtung.

Sollte zur Härtung des Zielsystems weniger als eine Stunde zur Verfügung stehen, kann Bastille ersatz- weise zu einer weiterführenden Systemhärtung verwendet werden.

Abbildung in dieser Leseprobe nicht enthalten

Quellen

Definitionen - http://www.wikipedia.de

Redhat Security Guide - http://mirror.centos.org/ centos/4/docs/html/rhel-sg-en-4/

SSH - http://www.ssh.com/support/documentati- on/online/ssh/adminguide/32/Public-Key_Authen- tication-2.html

GNU Free Documentation License

Version 1.2, November 2002

Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.

51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other functional and useful document “free” in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commer- cially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of “copyleft”, which means that deri- vative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documen- tation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this Licen- se. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to any such ma- nual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied ver- batim, or with modifications and/or translated into another language.

A “Secondary Section” is a named appendix or a front-mat- ter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of histori- cal connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The “Invariant Sections” are certain Secondary Sections who- se titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the noti- ce that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Co- ver Text may be at most 25 words.

A “Transparent” copy of the Document means a machine- readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translati- on to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not

Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transpa- rent” is called “Opaque”.

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text.

A section “Entitled XYZ” means a named subunit of the Do- cument whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name men- tioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of

such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document.

These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disc- laimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept

compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that com- monly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires

Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and

visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these condi-

tions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machi- ne-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reaso- nably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least

one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an upda- ted version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Docu- ment under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this Licen- se, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified

Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

* A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previ- ous versions (which should, if there were any, be listed in the

History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

* B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal aut- hors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.

* C. State on the Title page the name of the publisher of the Modified Version, as the publisher.

* D. Preserve all the copyright notices of the Document.

* E. Add an appropriate copyright notice for your modifica- tions adjacent to the other copyright notices.

* F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Adden- dum below.

* G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice.

* H. Include an unaltered copy of this License.

* I. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled “History” in the Document, create one stating the title, year, authors, and publisher of the Docu-

ment as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

* J. Preserve the network location, if any, given in the Docu- ment for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History” section. You may omit a network location for a work that was published at least four years before the Document itself,

or if the original publisher of the version it refers to gives permis- sion.

* K. For any section Entitled “Acknowledgements” or “De- dications”, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

* L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

* M. Delete any section Entitled “Endorsements”. Such a sec- tion may not be included in the Modified Version.

* N. Do not retitle any existing section to be Entitled “Endor- sements” or to conflict in title with any Invariant Section.

* O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.

You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrange- ment made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Versi- on.

5. COMBINING DOCUMENTS

You may combine the Document with other documents re- leased under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this Licen- se, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in paren- theses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled “History” in the various original documents, forming one sec- tion Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedica- tions”. You must delete all sections Entitled “Endorsements.”

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided

that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Docu- ment is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover

Texts may be placed on covers that bracket the Document wi- thin the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sec- tions in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original En- glish version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Do- cument except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised ver- sions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

Details

Seiten
14
Jahr
2006
Dateigröße
676 KB
Sprache
Deutsch
Katalognummer
v109902
Institution / Hochschule
Hochschule Darmstadt
Note
Schlagworte
Redhat Enterprise Linux Hardening Guide

Autor

Teilen

Zurück

Titel: Redhat Enterprise Linux Hardening Guide