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
HP-UX Digital-Unix SunOS 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:

  1. Änderungen in der Liste der zugelassenen Software
  2. Verfügbarkeit von neuen Softwareversionen
  3. 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.

HP-UX Digital-Unix SunOS AIX


 

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.

HP-UX Digital-Unix SunOS AIX


 

2.1.3. Unterstützte Shells

Die unterstützten "Shells" sind in der Datei /etc/shells zu definieren. Die Nutzung folgender Shells ist erlaubt:

  1. sh (Standart Unix Shell)
  2. bsh (Bourne Shell)
  3. csh (C-Shell)
  4. 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.

HP-UX Digital-Unix SunOS AIX


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.

HP-UX Digital-Unix SunOS AIX


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.

HP-UX Digital-Unix SunOS AIX


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.

HP-UX Digital-Unix SunOS AIX


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.

HP-UX Digital-Unix SunOS AIX


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.

HP-UX Digital-Unix SunOS AIX


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.

HP-UX Digital-Unix SunOS AIX


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.

HP-UX Digital-Unix SunOS AIX


2.2.2. Weitere System-Dateien

Dieser Abschnitt definiert den Schutz der sicherheits-relevanten System-Dateien, die nicht in anderen Abschnitten aufgeführt sind.

HP-UX Digital-Unix SunOS AIX


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.

HP-UX Digital-Unix SunOS AIX


2.2.3.3. Der Befehl "chroot"

Der Befehl chroot ändert das "root"-Verzeichnis für einen Befehl und erzeugt ein geschütztes Subsystem.

HP-UX Digital-Unix SunOS AIX


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.

HP-UX Digital-Unix SunOS AIX


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.

HP-UX Digital-Unix SunOS AIX


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

HP-UX Digital-Unix SunOS AIX


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

HP-UX Digital-Unix SunOS AIX


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.

HP-UX Digital-Unix SunOS AIX


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:

HP-UX Digital-Unix SunOS AIX


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

Nicht vorhanden Nicht vorhanden SunOS nicht vorhanden AIX


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:

  1. Information an der Vorgesetztem
  2. 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:

HP-UX Digital-Unix SunOS AIX


Zurück zu den Guidelines der IV-Sicherheit.

Stand: 05.03.1998 - Ansprechpartner: .........