Ausführungsbestimmungen der Sicherheitsrichtlinien () für
den Betrieb und die Konfiguration von UNIX-Systemen bei ...
Organisationshandbuch Teil 02
Dienstanweisung
Geltungsbereich ....
-vertraulich und Eigentum der ........
Inhalt
1. Einführung
1.1. Überblick
1.1.1. Zugriffsrechte und Systemsicherheit
1.1.2. Account-Management
1.1.3. Systemparameter
1.2. Anwendbarkeit der Ausführungsbestimmungen
1.3. Verantwortlichkeiten
1.4. Sicherheits-Statusberichte und Eskalationsprozeduren
2. Schutz von Dateien und Verzeichnissen
2.1. Systemdateien
2.1.1. Geräte-Beschreibungs-Dateien
2.1.2. Hauptspeicher-Beschreibungs-Dateien
2.1.3. Unterstützte Shells
2.1.4. Aufzeichnung und Überprüfung
von Dateizugriffen
2.1.5. Gruppendatei
2.1.6. Netzwerk-Konfigurations-Dateien
2.1.7. Crash Dump-Dateien
2.1.8. Scheduled AdministrativeCommands
2.1.9. Systemstart Kommandoprozeduren
2.2. Benutzer-Account-Dateien
2.2.1. Weitere Dateien in den Verzeichnissen
/etc und /usr/sbin
2.2.2. Weitere System-Dateien
2.2.3. Schutz von bestimmten Befehlen
2.3. System-Verzeichnisse
2.4. Temporäre System-Verzeichnisse
2.5. Allgemein beschreibbare Verzeichnisse
2.6. SUID und SGID Programme
2.7. Benutzer-Dateien
2.7.1. Schutz der Home-Verzeichnisse
2.7.2. Zugriffspfad auf das Home-Verzeichnis
2.7.3. Mail-Dateien des Benutzers
2.8. Mail Aliases
3. Shell Variablen
3.1. Default Datei- Schutz (umask)
3.2. PATH Variable
3.3. Für Benutzer von csh
3.4. Für Benutzer der Bourne Shell
4. Benutzer-Accounts
4.1. Account-Arten
4.1.1 Anforderungen für alle Accounts
4.1.2. Accounts mit allgemeinem Systemzugang
4.1.3. Accounts für externe Mitarbeiter
4.2. Der Account "root" bzw.
"superuser"
4.3. Einrichten, Ändern, Sperren und
Löschen von Accounts
4.4. Verlängern von Accounts
4.5. Offene Accounts
4.6. Accounts für Systemunterstützung
4.7. Anmelde-Kommando-Prozedur (Login Shell)
5. Superuser-Privilegien
5.1. Kontrolle von "Superuser"-Zugriffen
5.2. Protokollierung von "Superuser"-Zugriffen
6. Paßworte
6.1. Paßwort-Schutz
7. Zugriff über Modems
8. Netzwerk-Sicherheit
8.1. Die Dateien /etc/hosts.equiv und .rhosts
8.1.1. Die Datei hosts.equiv
8.1.2. Die Datei .rhosts
8.2. Die Datei /etc/hosts
8.3. Telnet
8.4. File Transfer Program (ftp)
8.4.1. Anonymous ftp
8.4.2. .netrc-Dateien
8.5. Trivial File Transfer Program (tftp)
8.6. Ungenutzte Netzwerk Services
9. Network File System (NFS)
9.1. Mounten von NFS Datei-Systemen
9.2. Überwachung von NFS-Zugriffen
10. UUCP UNIX to UNIX Copy Program
11. Anzeige der Meldung, daß unerlaubter
Zugang zum System verboten ist
12. Überwachung
12.1. Konfiguration der Überwachung
12.2. Auswertung der Überwachungs-Aufzeichnungen
12.3. Audit Data Backup
12.4. Änderung der Überwachung
12.5. Management des Überwachungs-Datei-Systems
12.6. Schutz der UNIX-Überwachung
13. "Lookup Services"
13.1. Lokale "root"-Accounts
13.2 Lokale group-Datenbasis
13.3. Anmerkungen zu NIS-Zeigern (Pointers)
13.4. Schutz der "Domain"- und
der "Server"-Liste
14. Weitere sicherheitsrelevante Regelungen
14.1. Handhabung von vermuteten Sicherheitseinbrüchen
14.2. Druck-Dateien
14.3. Batch-Verarbeitung
Anhang:
Anhang A Konfigurationstabellen IBM-AIX
Anhang B Konfigurationstabellen Digital-UNIX
Anhang C Konfigurationstabellen HP-UX
Anhang D Konfigurationstabellen SunOS
Anmerkung zur Benutzung dieses Dokumentes
Innerhalb dieses Dokumentes wird teilweise sehr detailliert auf
die Konfiguration eines UNIX-Systems eingegangen. Obwohl die Unterschiede
zwischen den Konfigurationen der verschiedenen UNIX-Derivate bei
X nur klein sind, sind sie trotzdem im Anhang tabellarisch aufgelistet.
Sollte direkt zu einem Absatz eine Tabelle mit Konfigurationsdaten
vorhanden sein, so wird dies durch die Icons der Betriebssysteme
angezeigt:
|
HP-UX |
|
Digital-UNIX |
|
SunOS |
|
IBM-AIX |
|
 |
|
 |
|
 |
|
 |
1. Einführung
Diese Ausführungsbestimmungen konkretisieren den Umgang mit
den Vorschriften der Sicherheitsrichtlinie X.
Sie dienen den Systemadministratoren und IV-Sicherheitsverantwortlichen
zur Installation und Betrieb sicherer IV-Systeme. Ziel ist es, diese
Ausführungsbestimmungen mittels IV-Werkzeugen zu implementieren
und deren Einhaltung automatisch zu überprüfen.
Sie sollen einen Schritt zur werks- und systemübergreifenden
Vereinheitlichung der IV-Sicherheit leisten.
Erweiterungen sind mit den Sicherheitsbeauftragten abzustimmen
und genehmigen zu lassen.
Die in den Anhängen angegebenen
Konfigurationstabellen sind im Dezember 1995 entstanden. Für Anregungen
und Ergänzungen wenden Sie sich bitte an ....
1.1. Überblick
Folgende Bereiche werden von den Ausführungsbestimmungen geregelt:
- Zugriffsrechte und Systemsicherheit
- Account-Management
- Systemparameter
- Überwachung/Alarme
1.1.1. Zugriffsrechte und Systemsicherheit
Regelungen für die Einrichtung von Benutzern und Benutzergruppen
bilden die Voraussetzung für eine angemessene Vergabe von Zugriffsrechten
und für die Sicherstellung eines geordneten und überwachbaren
Betriebsablaufes.
1.1.2. Account-Management
Wesentliche Ursache für Sicherheitslücken ist mangelhaftes
Account-Management. Nur umsichtige Kontrolle und Pflege der Accounts
können sicherstellen, daß nur loyale, interne und externe
Mitarbeiter Zugang zu den Systemen haben, und daß das Maß
an Zugriffsmöglichkeiten dem Arbeitsbereich entspricht. Nur
ein sorgfältiges Account- und Passwort-Management (Passwortlänge,
Zusammensetzung und Gültigkeitsdauer) reduziert die Anfälligkeit
der Systeme.
Netzwerke bieten traditionell einen relativ offenen Zugang. Diese
Ausführungsbestimmungen sollen die Zugangsmöglichkeiten
zum ....-Netzwerk regeln und auf eine kontrollierte Nutzung absichern.
1.1.3. Systemparameter
Sicherheitsrelevante Systemparameter definieren die Schwelle, bei
deren Überschreiten ein System Verletzungen erkennt und entscheidet,
was geschehen, gemeldet und dokumentiert werden soll.
1.2. Anwendbarkeit der Ausführungsbestimmungen
Die Ausführungsbestimmungen der Sicherheitsrichtlinie (.......)
gelten für alle UNIX-Systeme im Netzwerk inkl. aller externen
Zugangsmöglichkeiten. Sie stellen Minimalanforderungen an die
Sicherheit der Systeme dar. Ausnahmen müssen vom IV-Sicherheitsverantwortlichen
genehmigt werden.
1.3. Verantwortlichkeiten
Der Systemmanager bzw. Systemadministrator ist dafür verantwortlich,
daß die Systemsoftware auf aktuellem Stand ist.
Sollen Systeme über einen längeren Zeitraum mit einer
älteren Version der Systemsoftware betrieben werden, so ist
eine Genehmigung beim zuständigen IV-Sicherheitsbeauftragten
einzuholen.
Das Architekturgremium bei ... pflegt die Liste der zugelassenen/aktuellen
Software und verteilt diese Liste innerhalb der ...
Das Architekturgremium bei .... informiert die Systemmanager bzw.
Systemadministratoren über:
- Änderungen in der Liste der zugelassenen Software
- Verfügbarkeit von neuen Softwareversionen
- obligatorische Patches
Der IV-Sicherheitsbeauftragte ist vom Systemmanager über die
Existenz von Sicherheits-Patches zu informieren. In Zusammenarbeit
ist dann abzustimmen, ob und innerhalb welcher Frist dieser Patch
zu installieren ist.
Wenn eine Softwareversion aus der Liste der zugelassenen Software
entfernt wird, hat der Systemmanager 180 Tage Zeit, die neue Version
zu installieren.
Bei einer zeitlich darüber hinaus gehenden Nutzung, wird das
System vom Netzwerk abgezogen.
Der zuständige IV-Sicherheitsbeauftragte nimmt an allen lokalen
und netzwerkweiten Sicherheitsbesprechungen teil und ist für
die Genehmigung, regelmäßige Überprüfung und
Beseitigung der aufgezeigten Mängel von Accounts verantwortlich.
1.4. Sicherheits-Statusberichte und
Eskalationsprozeduren
Der zuständige IV-Sicherheitsbeauftragte definiert die Prozeduren
für Sicherheits-Statusberichte und Eskalation von sicherheitsrelevanten
Ereignissen. Er veröffentlicht diese an die zuständigen
Systemmanager, Systemadministratoren und Sicherheitsverantwortliche
der .....
2. Schutz von Dateien und Verzeichnissen
Dieser Abschnitt beschreibt sowohl den geforderten als auch den
empfohlenen Zugriffsschutz für Dateien und Verzeichnisse.
2.1. Systemdateien
Die folgenden Absätze beschreiben den Schutz der sicherheitsrelevanten
Systemdateien eines UNIX-Systems im Allgemeinen und die konkrete
Realisierung speziell für Sun, Digital, HP-Unix und AIX.
2.1.1. Geräte-Beschreibungs-Dateien
Der Zugriff auf Platten und andere Peripheriegeräte erfolgt
über entsprechende Geräte-Beschreibungs-Dateien. Ungenügend
geschützte Geräte-Beschreibungs-Dateien beinhalten ein
großes Sicherheitsrisiko.
Alle Geräte-Beschreibungs-Dateien (Device Special Files) müssen
im Verzeichnis /dev abgelegt werden. ("Hacker" stellen
Geräte-Beschreibungs-Dateien in andere Verzeichnisse und versuchen
so die Sicherheitsmechanismen des Systems zu umgehen.)
- Die Mount-Option nodev verhindert, daß der Zugriff
auf die Geräte-Beschreibungs-Dateien von anderen Datei-Systemen
als dem "root"-Dateisystem aus erfolgen kann. Beim Mounten
aller Dateisysteme ist diese Option zu nutzen. Davon ist nur das
root-Dateisystem ausgenommen, das das Dateisystem mit dem Verzeichnis
/dev enthält. Geben Sie die Option nodev in der Beschreibung
des Dateisystems in der Datei /etc/filesystems oder /etc/fstab
an. Bitte beachten Sie, daß auch plattenlose Systeme ein
"root"-Verzeichnis auf dem zugeordneten Server haben.
- Alle Geräte Beschreibungsdateien sollten den Schreibzugriff
nur für den Benutzer "root" erlauben. Ausnahmen
sind restriktiv zu handhaben. Insbesondere ist zu überprüfen,
ob die Gerätedateien für die Bandlaufwerke (in der Regel
/etc/rmt oder ähnlich) Schreibberechtigungen für
Benutzer benötigt.
2.1.2. Hauptspeicher-Beschreibungs-Dateien
Die Hauptspeicher-Beschreibungs-Dateien /dev/mem und /dev/kmem
regeln den Zugriff zum Hauptspeicher. Wer hierauf Zugriff hat, hat
uneingeschränkten Zugriff auf den gesamten Speicher des Systems.
Diese Dateien sind empfindlich gegen Ausspähungen. Hier ist
allen Benutzern (außer "root") der Lese- und Schreibzugriff
zu verbieten, da sich im Hauptspeicher möglicherweise Usernamen
und Paßwörter befinden, die durch das Auslesen (z.B.
mit dem "string"-Befehl) Unbefugten zugänglich gemacht
werden könnten. Durch Schreibzugriffe können eigene Codesegmente
in laufende Programme eingebracht werden und somit die Systemschutzmechanismen
unterlaufen werden.
2.1.3. Unterstützte Shells
Die unterstützten "Shells" sind in der Datei /etc/shells
zu definieren. Die Nutzung folgender Shells ist erlaubt:
- sh (Standart Unix Shell)
- bsh (Bourne Shell)
- csh (C-Shell)
- ksh (Korn Shell)
Größte Vorsicht ist bei der Änderung der Einträge
in der Datei /etc/shells und deren Programmen geboten. Versichern
Sie sich immer, daß diese aus zuverlässiger Hand stammen.
Die Shells-Datei sollte regelmäßig auf Konsistenz geprüft
werden. Angreifer könnten versuchen sich Systemzugang durch
einschleusen unsicherer Shell-Programme zu ermöglichen.
2.1.4. Aufzeichnung und Überprüfung
von Dateizugriffen
Logdateien protokollieren Aktivitäten auf dem System. Da in
ihnen auch sicherheitsrelevante Ereignisse (unzulässige Dateizugriffe,
Einbruchsversuche, usw.) dokumentiert werden, sind diese besonders
zu schützen. Der Lesezugriff von Logdateien darf nur dem Benutzer
"root" zugeordnet sein. Es kann sonst passieren, daß
Paßwörter durch einfaches lesen der Logdateien ausgespäht
werden können.
2.1.5. Gruppendatei
Die Datei /etc/group enthält eine Liste der Gruppen
und die Mitglieder jeder Gruppe. Diese Gruppen sollten die Struktur
der Aktivitäten auf dem System widerspiegeln. Die richtige
Syntax der Einträge ist dabei besonders wichtig.
Bis zur Implementation eines einheitlichen Werkzeuges sind neue
Gruppen mit dem Befehl smit oder /usr/bin/mkgroup einzutragen, Änderungen
sind mit chgroup und rmgroup durchzuführen. Bei Änderungen
der Datei /etc/group ist folgendes zu prüfen:
Die Datei darf keine
- Leerzeilen,
- doppelte Gruppennamen,
- doppelte Gruppen-Nummern (GID s),
- doppelte Benutzernamen innerhalb einer Gruppe
enthalten.
Jeder Eintrag muß vier Felder - durch Komma getrennt - umfassen.
- Gruppenname, bestehend aus bis zu 8 Zeichen (Kleinbuchstaben,
Ziffern 0-9, und Sonderzeichen), wobei das erste Zeichen ein Kleinbuchstabe
sein muß.
- verschlüsseltes Paßwort
- Gruppen-Paßworte sind nicht zugelassen.
- Der zulässige Wertebereich für GID s beträgt:
|
kleinster Wert |
größter
Wert |
GID range |
1 |
+59999 |
- Die Nutzung von negativen Werten für GID s ist unter UNIX
nicht erlaubt.
- Alphanumerische Benutzer ID s, durch Kommata getrennt (keine
Leerzeichen).
Änderungen der Zugehörigkeit eines Benutzers zu einer
Gruppe wirken erst bei der nächsten Anmeldung.
2.1.6. Netzwerk-Konfigurations-Dateien
Der Schreibschutz für Netzwerk-Konfigurations-Dateien ist
wichtig, um Netzwerk-Zugriffe auf das System kontrollieren zu können.
Entfernen Sie alle Schreibrechte für "group" und
"others" von den Netzwerk-Konfigurations-Dateien.
2.1.7. Crash Dump-Dateien
Crash Dump-Dateien enthalten u.U. die gesamten Informationen eines
Programmes zum Zeitpunkt des Crashes. Diese Informationen dürfen
nicht allgemein zugänglich gemacht werde, da sich auch hier
Informationen gewinnen lassen, welche einen Angriff auf das UNIX-System
stark erleichtern können.
2.1.8. Scheduled Administrative Commands
Die Dateien /var/spool/cron/crontabs/[user] oder /usr/spool/cron/crontabs/[user]mit
{root,adm,sys} für [user] enthalten Befehle und
Anweisungen mit Angaben wann und wie diese ausgeführt werden
sollen. Die Datei wird von /usr/sbin/cron genutzt, welcher beim
Starten des Systems angestoßen wird und dann kontinuierlich
weiterläuft.
- Der Schreibzugriff für alle Dateien und Verzeichnisse,
die in /usr/bin/crontab spezifiziert sind, muß auf "root"
begrenzt werden.
2.1.9. Systemstart Kommandoprozeduren
Die Kommandoprozeduren /etc/inittab und /etc/rc und /etc/rc.* kontrollieren
den automatischen Startprozeß des Systems. Modifikationsmöglichkeiten
erlauben eine Manipulation des Gesamtsystems.
- Die Dateien und Pfadnamen, die in /etc/inittab und /etc/rc.*
spezifiziert sind, sind vor Schreibzugriffen von "world"
zu schützen. Dieses gilt nicht für die Verzeichnisse
/tmp, /usr/tmp, /var/tmp, /dev/null, und die Geräte-Beschreibung
für Pseudo-Terminals.
2.2. Benutzer-Account-Dateien
Die Benutzer-Account-Dateien kontrollieren wer sich bei dem System
anmelden darf.
Insbesondere die Datei /etc/passwd muß vor schreibzugriffen
für "world" und "group" geschützt
und regelmäßig auf Konsistenz geprüft werden.
Der Einsatz einer sogenannten "shadow", einer gesonderten
Datei in der die verschlüsselten Passworte gespeichert werden,
ist soweit unter dem jeweiligen UNIX-Derivat möglich empfehlenswert.
Die "shadow" Datei kann dann auf den Modus 600 gesetzt
werden, womit es nicht mehr möglich ist, durch einschlägige
"Crack"-Programme die Passwörter der Benutzer oder
des Systemadministrators auszuspähen.
2.2.1. Weitere Dateien in den Verzeichnissen
/etc und /usr/sbin
Der folgende Abschnitt ergänzt den Zugriffs-Schutz für
sensible Daten in den Verzeichnissen /etc und /usr/sbin.
2.2.2. Weitere System-Dateien
Dieser Abschnitt definiert den Schutz der sicherheits-relevanten
System-Dateien, die nicht in anderen Abschnitten aufgeführt
sind.
2.2.3. Schutz von bestimmten Befehlen
Dieser Abschnitt enthält Sicherheits-Empfehlungen für
bestimmte UNIX Befehle.
2.2.3.1. Der Befehl "wall"
Der Befehl wall sendet eine Nachricht an alle angemeldeten Benutzer.
Er sollte für normale Benutzer deaktiviert werden um Missbrauch
zu verhindern.
2.2.3.2. Der Befehl "uudecode"
Der Befehl uudecode entschlüsselt Dateien, die durch uuencode
verschlüsselt wurden.
- Zeiger auf Alias-Namen für den Befehl uudecode sind aus
der Datei der Mail-Alias-Namen zu entfernen.
2.2.3.3. Der Befehl "chroot"
Der Befehl chroot ändert das "root"-Verzeichnis
für einen Befehl und erzeugt ein geschütztes Subsystem.
2.2.3.4. Die Befehle "rwho" und "finger"
Benutzer eines anderen Systems im Netzwerk können wertvolle
Informationen über ihr System durch die Anwendung der Befehle
rwho und finger erhalten.
Netzwerk-Zugriffe mittels finger und rwho sind restiktiv durch
den Systemadministratoren zuzulassen.
- Die Dateien .plan und .project sollen gesperrt sein, d.h. sie
dürfen keine Daten abgeben, wenn mit dem Befehl finger darauf
zugegriffen wird.
- Sperren von "rwho"-Meldungen:
- Der "rwhod-daemon" empfängt und versendet System-Status-Informationen
über das lokale Rechner-Netz. Der "rwhod-daemon"
wird in der Prozedur /etc/rc gestartet.
- Sperren von "finger"
- Der "finger"-Eintrag in /etc/inetd.conf ist zu entfernen
oder auszukommentieren.
2.3. System-Verzeichnisse
Die Systemverzeichnisse dürfen keine Schreibrechte für
"other" erlauben. Ebenso sollte bei Verzeichnissen auf
die nur der Superuser "root" Zugriff haben muß im
Einzelfall überprüft werden, ob ein Zugriffmodus von 750
oder sogar 700 eine Einschränkung des normalen Betriebes darstellt.
Wann immer dieser Modus keinerlei Einschränkungen darstellt
ist er für Systemverzeichnisse zu nehmen.
2.4. Temporäre System-Verzeichnisse
Temporäre (tmp) Verzeichnisse sind mit dem "Sticky Bit"
zu versehen, um zu verhindern, daß Benutzer sich gegenseitig
Dateien zerstören können. Das "Sticky Bit" bei
Verzeichnissen (o.d.R.Modus 1777) erlaubt es nur dem Eigentümer
( =Erzeuger ) einer Datei diese zu Verändern oder zu löschen.
Bei automatischer Überprüfung der korrekten Zugriffsrechte
von Temporären System-Verzeichnissen ist zu beachten, daß
das Verzeichnis /usr/tmp häufig ein symbolischer link
nach /var/tmp ist.
2.5. Allgemein beschreibbare Verzeichnisse
Bei Allgemein beschreibbaren Verzeichnissen ist das Sticky Bit
zu setzen.
2.6. SUID und SGID Programme
- Kommando-Prozeduren (Shell Scripts) dürfen keine Erlaubnis
haben, SUID oder SGID zu nutzen.
- Es dürfen keine Kommandos oder Programme das SUID oder
SGID bit gesetzt haben aus denen sich Shells starten lassen. Wenn
möglich sind SGID den SUID Programmen vorzuziehen, da sie
weniger starke Rechteerweiterungen zulassen.
- Root SUID Programme in Benutzer-Verzeichnissen (/usr/users und
andere) sind nicht zugelassen. Dieses ist regelm;aauml;ß
zu prüfen.
- Der Schreib-Zugriff auf ein SUID-Programm ist auf den Owner
und den Systemadministrator zu beschränken.
2.7. Benutzer-Dateien
2.7.1. Schutz der Home-Verzeichnisse
Die Home-Verzeichnisse der Benutzer haben folgende Berechtigungen:
Owner: |
Benutzer (außer Accounts für spezielle Zwecke) |
Gruppe: |
system |
Zugriffsart: |
751 |
2.7.2. Zugriffspfad auf das Home-Verzeichnis
Alle Verzeichnisse zwischen dem Verzeichnis "root" und
dem Home-Verzeichnis des Benutzers haben folgende Berechtigungen:
Owner: |
root |
Gruppe: |
jede Gruppe |
Zugriffsart: |
755 |
2.7.3. Mail-Dateien des Benutzers
2.8. Mail Aliases
Die Datei der Mail-Alias-Namen aliases im Verzeichnis /etc/,
/usr/lib bzw /sendmail wird zur Weiterleitung von
Nachrichten durch sendmail genutzt.
3. Shell Variablen
Shell-Variablen dienen zur Anpassung der Benutzerumgebung an seine
Bedürfnisse. Der folgende Abschnitt behandelt die sicherheitsrelevante
umask und die Shell-Variablen PATH und HOME.
3.1. Default Datei- Schutz (umask)
T FACE="CorpoS" > Die Benutzermaske (umask) definiert den Schutz
von neu angelegten Dateien.
- Voreingestellte umask für alle Accounts: 027
- umask für unprivilegierte Accounts: 027
- umask für privilegierte Accounts: 022
3.2. PATH Variable
Die PATH-Variable definiert die Liste der Verzeichnisse, in denen
nach zulässigen Kommandos gesucht wird.
Die PATH-Variable wird in den Benutzer-Startup-Dateien und in /etc/envirinment
definiert. Dabei sind folgende Anforderungen einzuhalten:
- Die PATH-Variable darf nur absolute Suchpfade enthalten.
- Die Nutzung von $HOME im Such-Pfad ist nicht erlaubt.
- Die Nutzung von relativen Dateizugriffspfaden ist nur erlaubt,
wenn vorher alle notwendigen PATH-Variablen definiert sind. Damit
werden alle Suchpfade eindeutig definiert.
- Allgemein beschreibbare Verzeichnisse (world writable directories)
dürfen nicht Bestandteil der PATH-Variablen sein.
- Das current working directory von unprivilegierten Accounts
(aktuelles Verzeichnis, auf dem der Benutzer gerade arbeitet)
darf nur an letzter Stelle im Such-Pfad stehen.
- Das current working directory von privilegierten Accounts (root)
darf nicht im Such-Pfad stehen.
3.3. Für Benutzer von csh
- Für alle Benutzer von csh als default shell, muß
die benutzerspezifische PATH-Variable in der Datei .cshrc definiert
werden.
3.4. Für Benutzer der Bourne
Shell
- Für alle Benutzer der Bourne Shell als default shell, muß
die PATH-Variable in die benutzerspezifische Arbeitsumgebung (environment)
exportiert werden.
- Die systemseitig voreingestellte PATH-Variable wird in der Datei
/etc/security/.profile definiert.
4. Benutzer-Accounts
Dieser Abschnitt definiert die Ausführungsbestimmungen für
den Umgang mit allen Arten von Accounts auf Unix-Systemen, und beschreibt,
wenn möglich, spezifische Prozeduren um die Anforderungen zu
erfüllen.
4.1. Account-Arten
4.1.1. Anforderungen für alle
Accounts
- Grundsätzlich darf kein Account eingerichtet werden, wenn
nicht eine unterschriebene Anforderung vorliegt.
- Der Account-USERNAME ist nach dem Schema der HOST-USER-ID zu
vergeben.
- Gruppen-Accounts sind nicht zugelassen.
- USERNAMEN dürfen sofort wiederbenutzt werden.
- USERNAMEN dürfen nicht "leer" (blank) sein.
- Die UID eines Accounts darf nach dessen Löschung nicht
wiederbenutzt werden.
- Der zulässige Wert für eine UID liegt im Bereich zwischen
0 und 60 000.
- Accounts müssen auf die Zugangsmöglichkeiten beschränkt
werden, die sie benötigen.
- Die Bestimmungen zur Wiederverwendung von Usernamen und UID
s finden keine Anwendung, wenn ein Mitarbeiter das Unternehmen
verläßt und sein Account gelöscht wurde. Wenn
dieser Mitarbeiter zurückkommt, kann dem Mitarbeiter
sein alter Username und seine alte UID wiedergegeben werden.
4.1.2. Accounts mit allgemeinem Systemzugang
Benutzer-Accounts mit allgemeinem Systemzugang können alle
unprivilegierten UNIX-Befehle nutzen.
- Alle Accounts mit allgemeinem Systemzugang müssen einem
Mitarbeiter der .... zugeordnet werden, und sind so einzurichten,
daß erkennbar ist, welcher Mitarbeiter für diesen Account
persönlich verantwortlich ist.
4.1.3. Accounts für externe
Mitarbeiter
- Die Accounts für externe Mitarbeiter müssen nach den
gleichen Bestimmungen wie normale Mitarbeiter eingerichtet werden.
- Die Accounts für externe Mitarbeiter müssen die Firma
identifizieren, deren Mitarbeiter er ist. Auch diese Accounts
sind einem .....-Mitarbeiter zuzuordnen, der für diesen Account
verantwortlich ist.
- Die Gültigkeit von Accounts für externe Mitarbeiter
ist auf die Vertragslaufzeit zu begrenzen. Bei Verträgen
mit einer Laufzeit von mehr als einem Jahr ist die Gültigkeit
auf max. 360 Tage zu setzen. Verlängerungen haben schriftlich
zu erfolgen.
4.2. Der Account "root"
bzw. "superuser"
Einige Tätigkeiten auf dem System sind auf den Account "root"
beschränkt. Diese Einschränkung schützt die System-Integrität
und die Integrität der Hilfestellungen für die Benutzer
durch den Systemadministrator. Darum ist größte Vorsicht
geboten, wenn der Account "root" genutzt wird.
Der zuständige Systemadministrator ist für den Account
"root" und dessen Nutzung verantwortlich.
4.3. Einrichten, Ändern, Sperren
und Löschen von Accounts
Die folgenden Richtlinien stellen Minimalanforderungen bezüglich
Einrichten, Ändern, Sperren und Löschen von Accounts dar:
- Jeder Account, der seit 90 Tagen nicht genutzt wurde, ist zu
sperren (nach Möglichkeit automatisch).
- Jeder Account der seit 180 Tagen nicht genutzt wurde kann gelöscht
werden.
- Jeder Account, der seit 360 Tagen nicht genutzt wurde muß
gelöscht werden.
- Accounts, die nie benutzt worden sind, sind sofort zu löschen.
Die Mitarbeiter müssen sich sofort in ihren neuen Account
anmelden und das vorgegebene Passwort ändern.
- Accounts von ausgeschiedenen Mitarbeitern sind sofort zu sperren.
Es sind organisatorische Maßnahmen zu erarbeiten, die sicherstellen,
daß die verantwortlichen Systemmanager über das Ausscheiden
von Benutzern ihres Systems informiert werden.
- Accounts von externen Mitarbeitern muß mit dem Ende seines
Vertrages gesperrt werden.
- Accounts von Mitarbeitern, die versetzt wurden, sind sofort
zu sperren.
4.4. Verlängern von Accounts
- Eine regelmäßige schriftliche Verlängerung von
Accounts erfolgt nicht.
- Über Versetzungen und Auscheiden von Mitarbeitern wird
der Systemmanager schriftlich informiert.
4.5. Offene Accounts
Offene Accounts sind eine spezielle Form von unprivilegierten Accounts,
die entweder kein Passwort haben, oder deren Passwort allgemein
im Unternehmen veröffentlicht wurde.
- Es ist verboten offene Accounts einzurichten.
4.6. Accounts für Systemunterstützung
Die folgenden Richtlinien gelten für mitgelieferte Systemunterstützungs-Accounts:
- Jeder Systemunterstützungs-Account muß sofort nach
Benutzung wieder gesperrt werden.
- Systemunterstützungs-Accounts, die nicht benötigt
werden, sind sofort zu löschen.
- Bei der Öffnung eines Systemunterstützungs-Accounts
ist dafür zu sorgen, daß dieser Account am folgenden
Tag automatisch wieder gesperrt wird.
- Systemunterstützungs-Accounts, die systemnahe Applikationen
unterstützen, sind in ihren Möglichkeiten weitestgehend
zu beschränken.
4.7. Anmelde-Kommando-Prozedur (Login
Shell)
Das Feld eines Eintrages in der Datei /etc/passwd mit dem Zeiger
auf die Anmelde-Kommando-Prozedur (login shell field) spezifiziert
das Programm, das ausgeführt wird, wenn die Anmeldung erfolgreich
war. Wenn dieses Feld nicht besetzt ist, wird die Prozedur /bin/csh
gestartet.
Accounts, die nicht interaktiv arbeiten
Die Anmelde-Kommandoprozedur für die Accounts, die nicht interaktiv
arbeiten, oder die sich nicht anmelden können, darf keine Befehle
enthalten, die interaktive Prozesse starten. In der folgenden Liste
sind die zugelassenen Befehle aufgeführt.
Liste der zulässigen Befehle:
/bin/date |
/bin/false |
/bin/time |
/bin/rsh |
5. Superuser-Privilegien
"Superuser" bzw. "root" ist ein privilegierter
Account mit der UID '0'. Ein Prozeß mit der UID 0 hat "superuser"-Privilegien
und kann jeden Datei- und Verzeichnisschutz umgehen und fast jede
Funktion ausführen.
Die folgende Regelung gilt für Superuser-Zugriffe und die
Prozesse mit der UID '0 :
- Das "superuser"-Passwort darf nur dem System-Administrator
bekannt sein.
- Alle Mitarbeiter, die das "superuser"-Passwort kennen,
müssen einmal im Jahr überprüft werden.
5.1. Kontrolle von "Superuser"-Zugriffen
Direkte "superuser"-Zugriffe auf das System werden durch
eine Kombination aus Wissen des "superuser"-Passwortes
und dem Inhalt der Datei /etc/security/user kontrolliert.
- Anmeldungen als "root" sind nur von den Terminals
erlaubt, die in der Datei /etc/security/user aufgeführt sind.
- Die Verpflichtung, sichere (secure) Terminals einzurichten ist
einmal im Jahr vom Sicherheitsverantwortlichen zu überprüfen.
5.2. Protokollierung von "Superuser"-Zugriffen
Die Datei /var/adm/sulog protokolliert alle Versuche "superuser"-Privilegien
zu erhalten.
Die Datei /var/adm/sulog ist vom zuständigen Sicherheitsverantwortlichen
auf folgende Vorkommnisse zu untersuchen:
- Vergebliche Versuche "superuser"-Privilegien zu bekommen.
Dies ist alle 90 Tage zu prüfen.
- Benutzer, die unzulässigerweise das "root"-Passwort
kennen. Dies ist alle 90 Tage zu prüfen.
6. Paßworte
Die Minimalanforderungen an Paßworte sind in der ..... geregelt.
6.1. Paßwort-Schutz
Unerlaubter Systemzugang unter Benutzung von gültigen Paßworten
kann das Resultat von leichtfertigem Umgang mit dem Paßwort
sein. Wenn Paßworte in Dateien oder elektronischen Mails gespeichert
werden, kann ein unberechtigter Benutzer mit geringem Aufwand das
Paßwort lesen und versuchen mit diesem Paßwort auf anderen
Systemen, wo dieser Benutzer einen Account hat, einzubrechen. Auf
diese Weise kann sich dann ein unberechtigter Benutzer von System
zu System hangeln, und somit viel Schaden anrichten.
Die Benutzer-Authorisierungs-Datei ist /etc/passwd. Diese Datei
enthält alle notwendigen Informationen, die zur Prüfung
des zulässigen Systemzuganges für einen bestimmten Benutzer
benötigt werden. Alle Informationen sind darin direkt enthalten
und für jedermann lesbar, nur das verschlüsselte Paßwort
ist durch ein '* ersetzt und muß in der Datei /etc/security/passwd
gespeichert werden.
Die folgenden Richtlinien gelten für Paßworte:
- Hinterlegte Paßworte müssen in einem verschlossenen
Schrank aufbewahrt werden.
- Paßworte dürfen nicht unmittelbar einem Benutzer
oder Account zugeordnet werden können. (z.B. Paßwort
auf der Rückseite der Visitenkarte)
- Paßworte dürfen nicht in Klartext in Dateien gespeichert
werden. (z.B. Programm-Quellcode oder Kommandoprozeduren)
- Paßworte müssen alle 90 Tage geändert werden.
- Die Wiederverwendung von Paßworten ist für unprivilegierte
Benutzer nach 360 Tagen erlaubt.
- Die Wiederverwendung von Passworten ist für privilegierte
Benutzer verboten.
- Das Paßwort muß mindestens 8 Zeichen lang sein.
7. Zugriff über Modems
Externe Netzwerkzugänge mit Wähl-Modems sind nur in Verbindung
mit "Firewall"-Systemen zulässig.
- Die Nutzung von Modems ist restriktiv zu handhaben.
- Alle Modems sind ausdrücklich vom Sicherheitsbeauftragten
genehmigen zu lassen.
8. Netzwerk-Sicherheit
Das Protokoll TCP/IP wird als Standard-Netzwerk-Protokoll für
die UNIX-Systeme eingesetzt. Der folgende Abschnitt regelt die Sicherheits-Anforderungen
für den Zugriff auf Systeme mittels TCP/IP.
8.1. Die Dateien /etc/hosts.equiv
und .rhosts
Die System-Datei /etc/hosts.equiv und deren Benutzer-Pendant .rhosts
identifizieren fremde Systeme und fremde Benutzer, die ohne Passwort-Spezifikation
auf das lokale System zugreifen dürfen (trusted user). Dabei
besteht die Gefahr, daß ein einziger Account als Türöffner
für andere Accounts im Netzwerk genutzt werden kann. Ein Einbruch
in einen solchen Account bewirkt, daß nicht nur das lokale
System ausgespäht werden kann, sondern auch alle anderen Systeme,
in denen dieser Benutzer als "trusted" Account eingetragen
ist.
8.1.1. Die Datei hosts.equiv
Die Datei /etc/hosts.equiv ist eine System-Datei, die die Namen
der fremden Systeme enthält, deren Benutzer ohne Passwort-Spezifikation
sich über das Rechner-Netz auf dem lokalen System anmelden
und/oder Kommandoprozeduren auf dem lokalen System starten können.
Ein Benutzer eines fremden Systems, dessen Account-Name in der Datei
/etc/hosts.equiv aufgeführt ist, kann auf einen lokalen Account
mit dem entsprechenden Account-Namen zugreifen.
Folgende Anforderungen an die Datei /etc/hosts.equiv sind zu beachten:
- "Wildcard"-Einträge, d.h. Zeilen, die nur ein
+ enthalten, sind verboten.
- Die NIS-Einträge +@group und -@group können
genutzt werden.
- Knotennamen von Systemen, die nicht zum Rechnernetz der ...
gehören, dürfen nicht eingetragen werden.
- Bei Remote-Rechnern ("NIS-Client") ist der entsprechende
Name vollständig einzutragen.
8.1.2. Die Datei .rhosts
Die Datei .rhosts eines Benutzers ist dessen persönliche Erweiterung
der System-Datei /etc/hosts.equiv . Die Gültigkeit der Datei
.rhosts ist auf den Benutzer-Account beschränkt, während
die Datei hosts.equiv für alle Accounts des Systems (außer
"root") gilt.
Die Datei .rhosts enthält die Knotennamen von Remote-Systemen
und möglicherweise Remote-Benutzern, die Zugang zum lokalen
System bekommen können und sich ohne Passwort-Spezifikation
anmelden und/oder Kommandoprozeduren starten können.
Folgende Anforderungen an die Datei .rhosts sind zu beachten:
- Knotennamen von Systemen, die nicht zum Rechnernetz der .....
gehören, dürfen nicht eingetragen werden.
- Bei Remote-Rechnern ("NISS-Client") ist der entsprechende
Name vollständig einzutragen.
- Die Datei .rhosts darf kein symbolischer Zeiger (symbolic link)
sein.
Folgende Anforderung gilt zusätzlich für die Datei .rhosts
von "root":
- Der Account "root" darf die Datei /.rhosts nur für
notwendige System-Management-Aufgaben oder Netzwerk-Backups benutzen.
8.2. Die Datei /etc/hosts
Die Datenbank-Datei /etc/hosts enthält Internet-Adressen der
über Internet verbundenen Systeme. Der Eintrag in dieser Datei
erlaubt Benutzern des lokalen Systems fremde Systeme über Alias-Namen
zu adressieren, anstelle der IP-Adresse oder des vollständigen
Knotennamens.
- Die Nutzung einer NIS-Datenbasis für remote Systeme wird
als Ergänzung zur Datei /etc/hosts empfohlen.
- Die Einträge in der Datei /etc/hosts müssen vollständig
mit drei Zonen angegeben werden, z.B. hostname..DE
- Die Komponenten sollen die Adresse in richtiger Reihenfolge
enthalten.
8.3. Telnet
Das telnet-Interface zum TELNET-Protokoll ist innerhalb des ......-Netzwerkes
zugelassen. Die Nutzung von telnet im INTERNET ist restriktiv zu
handhaben und darf nur über einen Firewall-Server erfolgen.
8.4. File Transfer Program (ftp)
Das Programm ftp (file transfer program) überträgt Dateien
zwischen den Systemen im Netzwerk.
- Die Nutzung von ftp ist restriktiv zu handhaben.
8.4.1. Anonymous ftp
Anonymous ftp ist eine spezielle Konfiguration von ftp, die jedem
Netzwerk-Benutzer den Zugriff auf die Dateien in einem ftp-Verzeichnis
erlaubt, indem der Benutzername anonymous und ein Passwort (üblicherweise
der Knotenname des Remote-Systems) angegeben wird.
Schutz der ftp-Verzeichnisse und ftp-Dateien:
8.4.2. .netrc-Dateien
Die Datei .netrc ist eine Datei aus der Benutzerumgebung, die login-Information
für remote ftp-Accounts enthält.
- Die .netrc-Dateien dürfen keine Passworte enthalten.
8.5. Trivial File Transfer Program
(tftp)
Der tftp-Service sollte nicht für normalen Datei-Transfer
genutzt werden. Dieser Service benötigt keine Identifikation
der Benutzer und gibt dem Benutzer den Zugriff auf die Dateien,
die für alle lesbar sind. Der ftp-Service verlangt eine Identifizierung
und stellt somit eine sichere Alternative dar.
Wenn es keine Alternative gibt, kann tftp für System-Management-Funktionen
wie:
- Booten von plattenlosen Workstations durch tfpboot
- Laden von X-Stations mit dem X-Windoe-Server-Code von der RS6000
- Übertragung von System-Konfigurations-Informationen zum
Drucker
eingesetzt werden.
Der Einsatz des Trivial File Transfer Protocols (tftp) beinhaltet
erhebliche Sicherheitsrisiken. Bei richtiger Konfiguration, werden
die Remote-Systeme, deren Zugriff auf das lokale System mit tftp
erlaubt ist, kontrolliert.
- Die Erlaubnis zur Nutzung von tftp ist restriktiv zu handhaben.
8.6. Ungenutzte Netzwerk Services
Ungenutzte Services müssen gesperrt werden. In der Datei inetd.conf
dürfen nur genutzte Einträge enthalten sein. Diese ungenutzten
Services müssen auch aus der InetServ-Class in ODM entfernt
werden.
9. Network File System (NFS)
Das Network File System ermöglicht das Mounten und Dismounten
von Datei-Systemen und Verzeichnissen über das Netzwerk und
behandelt diese Verzeichnisse so, als seien sie lokal.
Die Datei /etc/exports beinhaltet die Datei-Systeme und Verzeichnisse,
die mit NFS exportiert werden dürfen. Dabei sind die folgenden
Bedingungen einzuhalten:
- Export nur zu namentlich bekannten Systemen
- Die Datei-Systeme /, /bin, /dev, /etc, /usr,/var und /usr/bin
dürfen nicht exportiert werden.
- Die Nutzung der Option ro für nur lesbare Datei-Systeme
ist vorgeschrieben.
- Die NFS-Option secure muß innerhalb einer verteilten NFS-Konfiguration
genutzt werden.
- Die Option nodevs ist in der nfs-Datei-System-Beschreibung /etc/filesystems
hinzuzufügen.
- Der Import von Datei-Systemem ist nur über die Option nosuid
erlaubt.
9.1. Mounten von NFS Datei-Systemen
Vorsicht ist geboten, wenn sensitive Informationen auf Remote-Datei-Systemen
außerhalb der eigenen Management-Kontrolle abgespeichert werden.
- Datei-Systeme, die von Systemen importiert werden, die nicht
der eigenen Management-Kontrolle unterliegen, müssen mit
der Option noexec versehen werden.
9.2. Überwachung von NFS-Zugriffen
Folgende Prüfungen sind durchzuführen:
- Regelmäßige Überprüfung der Datei /etc/exports
auf neue Einträge
- Eingabe des Befehls showmount mit der Option -a, um zu sehen,
welche Systeme Datei-Systeme oder Verzeichnisse des lokalen Systems
gemountet haben.
Beispiel: # /usr/bin/showmount -a
- Der Zugriff auf Netzwerke und Systeme außerhalb des eigenen
Verwaltungsbereiches ist verboten.
10. UUCP UNIX to UNIX Copy Program
Das Programm UUCP (UNIX to UNIX Copy Program) stellt Netzwerkdienstleistungen,
wie Versenden von Nachrichten, Kopieren von Dateien, Ausführen
von Befehlen auf Remote-Rechnern, zur Verfügung.
Die Nutzung von UUCP ist nicht zulässig.
11. Anzeige der Meldung, daß
unerlaubter Zugang zum System verboten ist
Jedes der bei .... eingesetzten UNIX-Derivate erlaubt die Anzeige
einer Loginmeldung (z.B. aus der Datei /etc/security/login.cfg oder
/etc/issue).Diese Meldung darf keine verwertbaren Informationen
enthalten, die Neugierde schüren und Einbruchsversuche attraktiv
machen könnten. Besonders sind Informationen über das
Betriebssystem und die Art der Nutzung zu vermeiden.
Ein authorisierter Benutzer benötigt diese Informationen nicht
vor der Anmeldung.
Die Rechtsprechung in Deutschland verlangt einen Hinweis, daß
der unerlaubte Zugang zum System untersagt ist.
Die folgende Eingangsmeldung soll vor dem Anmelden eines Benutzers
angezeigt werden:
Unerlaubter Zugang
zu diesem System ist verboten. |
12. Überwachung
Hintergrund der Überwachung ist das Sammeln von Informationen
über:
- Wer führt welche Operationen aus?
- Welche Operationen werden ungewöhnlich oft genutzt?
- Wer führt ungewöhnliche Operationen aus?
Die Überwachung eines UNIX-Systems kann zu einem komplexen
Prozeß werden und ist abhängig vom Umfang und Art der
Überwachung. Der Einsatz von Werkzeugen ist zu empfehlen.
12.1. Konfiguration der Überwachung
Die Überwachung ist bis zur Implementierung eines einheitlichen
Tools nach folgenden Geschichtspunkten zu gestalten:
- Es müssen alle sicherheitsrelevanten Ereignisse überwacht
werden.
- Die Konfiguration sollte derart gestaltet sein, daß das
Datenvolumen der Überwachungsdateien nicht unnötig groß
wird.
12.2. Auswertung der Überwachungs-Aufzeichnungen
- Die Auswertung der Überwachungs-Aufzeichnungen muß
vom Sicherheitsverantwortlichen täglich erfolgen.
12.3. Audit Data Backup
- Die Überwachungs-Daten müssen periodisch gesichert
werden. Dabei ist das Standard Network-Backup-Tool zu nutzen,
welches unabhängig vom zu sichernden System arbeitet.
- Die Daten sind off-line für 30 Tage aufzubewahren.
12.4. Änderung der Überwachung
Die Änderung der Überwachung ist nur mit Zustimmung des
zuständigen IV-Sicherheitsbeauftragten zugelassen.
12.5. Management des Überwachungs-Datei-Systems
Überwachung generiert üblicherweise ein großes
Datenvolumen, das verdichtet und analysiert werden muß. Bis
dahin müssen die "Rohdaten" ausreichend verwaltet
werden.
Es ist darauf zu achten, daß das die Überwachungsdaten
möglichst auf benachbarten System angelegt werden. So wird es erschwert
Spuren von Einbrüchen in ein System zu verwischen. Es bietet
sich an, daß die entsprechenden Dateisysteme wechselweise
eingerichtet werden.
Wenn das entsprechende Dateisystem "voll" ist, wird folgender
Prozeß gestartet:
Sicherungskopie erstellen |
leeren der Datei (flush)
z.B. mit dem Befehl "cat /dev/null > audit_filename" |
12.6. Schutz der Überwachungsdateien
Die Dateien, die zur Überwachung benötigt werden, sind
vor lesezugriffen von "normalen" Benutzern zu schützen
Eigentümer |
Gruppe |
Modus |
root |
system/admin/audit |
640 |
13. "Lookup Services"
"Lookup Services" sind Systemmechanismen, um vielen Systemen
im Netzwerk die Möglichkeit zu geben Datenbankzugriffe zu tätigen
und Systeminformationen, wie Paßworte, Rechnernamen und Gruppennamen
nachzusehen.
"Lookup Services" müssen sicher sein, damit der
unerlaubte Systemzugang erschwert wird.
Die Systeme im .........Netzwerk nutzen:
- BIND (Programm zur Implementation von DNS)
- NIS (Network Information Service)
13.1. Lokale "root"-Accounts
Der "root"-Account bzw. jeder Account mit der UID 0 darf
aus folgenden Gründen nicht über das Netz in einer BIND-
(DNS)- oder NIS-Umgebung verteilt sein:
Ein Einbruch in einen verteilten "root"-Account hat zur
Folge, daß die Systeme, auf die der "root"-Account
verteilt wurde, ebenfalls unsicher geworden sind.
Einige UNIX-Funktionen erfordern einen lokalen "root"-Account.
Unter Umständen wird das Fehlen eines lokalen "root"-Accounts
so wie ein "root"-Account ohne Paßwort behandelt.
Sollte die Server-Datenbasis nicht verfügbar sein, ist Systemmanagement
mit einen lokalen "root"-Account möglich und ermöglicht
das System von einer zweiten Datenbasis wiederherzustellen.
13.2. Lokale group-Datenbasis
In NIS sollte jeder Client und jeder Server seine eigene lokale
"group"-Datenbais haben.
13.3. Anmerkungen zu NIS-Zeigern
(Pointers)
+ oder - Einträge in die Datenbasis der Server-Paßworte
sind nicht zulässig. Diese Einträge können zu Fehlinterpretationen
führen.
Beim Import von Gruppen aus der Group-Datenbasis des Servers ist
Vorsicht geboten. Die Nutzung von + Einträgen kann zur Folge
haben, daß Gruppenrechte an Benutzer vergeben werden, die
diese nicht bekommen sollen.
- + oder - Einträge in der Server-Datenbasis /etc/group sind
nicht erlaubt.
- Die Datei /etc/hosts.equiv darf keine +@ oder -@ Einträge
enthalten.
13.4. Schutz der "Domain"-
und der "Server"-Liste
- Das Schutzkennzeichen (secure flag (-S)) muß im Eintrag
/etc/ypbind im Script /etc/rc.local gesetzt sein.
14. Weitere sicherheitsrelevante
Regelungen
14.1. Handhabung von vermuteten Sicherheitseinbrüchen
Die folgenden Prozeduren sind bei einem vermuteten Einbruch in
Ihrem Verantwortungsbereich anzuwenden:
- Information an der Vorgesetztem
- Benachrichtigung der IV-Sicherheit (Tel.: .....) bzw. des örtlichen
IV-SiBe
14.2. Druck-Dateien
- Die Benutzung der "-s" Option im Befehl lpr ist vorgeschrieben.
14.3 Batch-Verarbeitung
- Die Dateien /usr/lib/cron/at.deny und at.allow müssen vorhanden
sein, um den Zugriff auf das Werkzeug "cron" zur Batch-Verarbeitung
zu beschränken.
Schutz der Dateien für die Batch-Verarbeitung:
Zurück zu den Guidelines
der IV-Sicherheit.
Stand: 05.03.1998 - Ansprechpartner:
.........