Fehlerbehebung bei der Oracle Solaris-Prüfung (Übersicht der Schritte)

In der folgenden Übersicht der Schritte wird auf Verfahren für die Fehlerbehebung bei der Oracle Solaris-Prüfung verwiesen.

So können Sie die Ausführung der Oracle Solaris-Prüfung feststellen

Wenn Sie annehmen, dass trotz aktivierter Prüfung keine Prüfdatensätze im primären Prüfverzeichnis generiert werden, versuchen Sie den Fehler zu beheben, indem Sie Folgendes durchführen.

Bevor Sie beginnen

Die Datenbank hosts im Naming Service wurde ordnungsgemäß konfiguriert und kann einwandfrei verwendet werden. Weitere Informationen zur Behebung von Fehlern beim Naming Service finden Sie in der folgenden Dokumentation:

• Manpage nsswitch.conf(4)

• Systemverwaltungshandbuch: Naming Services und Directory Services (DNS, NIS und LDAP)

• System Administration Guide: Naming and Directory Services (NIS+)

1. Stellen Sie fest, ob die Prüfung ausgeführt wird.
   • Vergewissern Sie sich, dass das Kernel-Modul c2audit geladen ist.

     # modinfo | grep c2audit

     Keine Liste weist darauf hin, dass die Prüfung nicht ausgeführt wird. Anhand der folgenden Liste können Sie erkennen, ob die Prüfung ausgeführt wird:

     40  132ce90  14230 186   1  c2audit (C2 system call)

   • Vergewissern Sie sich, dass der Prüfdämon ausgeführt wird.

     Überprüfen Sie den Status des Service auditd. Anhand der folgenden Liste können Sie erkennen, dass die Prüfung nicht ausgeführt wird:

     # svcs -x auditd
     svc:/system/auditd:default (Solaris audit daemon)
      State: disabled since Fri Aug 14 19:02:35 2009
     Reason: Disabled by an administrator.
        See: http://sun.com/msg/SMF-8000-05
        See: auditd(1M)
        See: audit(1M)
     Impact: This service is not running.

     Anhand der folgenden Liste können Sie erkennen, dass der Prüfservice ausgeführt wird:

     # svcs auditd
     STATE          STIME    FMRI
     online         10:10:10 svc:/system/auditd:default

   • Überprüfen Sie die aktuelle Prüfbedingung.

     Anhand der folgenden Liste können Sie erkennen, dass die Prüfung nicht ausgeführt wird:

     # auditconfig -getcond
     auditconfig: auditon(2) failed.
     auditconfig: error = Operation not supported(48)

     Anhand der folgenden Liste können Sie erkennen, ob die Prüfung ausgeführt wird:

     # auditconfig -getcond
     audit condition = auditing

   Wenn der Prüfservice nicht ausgeführt wird, aktivieren Sie ihn. Weitere Informationen zu dem Verfahren finden Sie unter So aktivieren Sie den Prüfservice.

2. Überprüfen Sie die Syntax der Datei audit_control.

   # audit -v /etc/security/audit_control
   audit: audit_control must have either a valid "dir:" entry 
   or a valid "plugin:" entry with "p_dir:" specified.

   Beheben Sie die Fehler. Die Meldung syntax ok gibt an, dass die Syntax der Datei ordnungsgemäß vorhanden ist.

3. Vergewissern Sie sich, dass die Datei audit_control über gültige Werte für die Schlüsselwörter flags und naflags verfügt.

   # grep flags /etc/security/audit_control
   flags:lo
   naflags:na,lp

   Geben Sie gültige Werte an, wenn die Datei audit_control ungültige Werte aufweisen sollte. Im vorhergehenden Beispiel stellt lp eine ungültige Klasse dar.

4. Vergewissern Sie sich, dass die Datei audit_user über gültige Werte für jeden Benutzer verfügt.

   # tail audit_user
   ...
   # User Level Audit User File
   #
   # File Format
   #
   #    username:always:never
   #
   root:lo:no
   admin:lp:no

   Geben Sie gültige Werte an, wenn die Datei audit_user ungültige Werte enthält. Im vorhergehenden Beispiel stellt lp eine ungültige Klasse dar.

5. Wenn Sie eine angepasste Prüfklasse erstellt haben, stellen Sie sicher, dass der Klasse Ereignisse zugewiesen wurden.

   Beispielsweise enthält die folgende Datei audit_control eine Klasse, die von der Oracle Solaris-Software nicht bereitgestellt wird:

   # grep flags /etc/security/audit_control
   flags:lo,pf
   naflags:na,lo

   Eine Beschreibung zur Erstellung der Klasse pf erhalten Sie unter So fügen Sie eine Prüfklasse hinzu.

   1. Stellen Sie sicher, dass die Klasse in der Datei audit_class definiert ist.

      Die Maske der Prüfklasse muss eindeutig sein.

      # grep pf /etc/security/audit_class
      0x10000000:pf:profile command

      Wenn die Klasse noch nicht definiert ist, definieren Sie sie. Entfernen Sie andernfalls die Klasse aus den Dateien audit_control und audit_user.

   2. Vergewissern Sie sich, dass die Ereignisse zu der Klasse zugewiesen wurden.

      # grep pf /etc/security/audit_event
      6180:AUE_prof_cmd:profile command:ua,as,pf

      Wenn der Klasse keine Ereignisse zugewiesen wurden, weisen Sie die entsprechenden Ereignisse zu dieser Klasse zu.

6. Wenn durch die vorhergehenden Schritte kein Fehler festgestellt wurde, überprüfen Sie die Systemprotokolldateien /var/adm/messages und /var/log/syslog.
   1. Suchen Sie die Fehler und beheben Sie sie.
   2. Wenn der Prüfservice ausgeführt wird, starten Sie ihn erneut.

      # audit -s

   3. Wenn der Prüfservice nicht ausgeführt wird, aktivieren Sie ihn.

      Weitere Informationen zu dem Verfahren finden Sie unter So aktivieren Sie den Prüfservice.

So verringern Sie den Umfang der erstellten Prüfdatensätze

Nachdem Sie die zu prüfenden Ereignisse an Ihrem Standort festgestellt haben, erstellen Sie anhand der folgenden Vorschläge einfach zu verwaltende Prüfdateien.

1. Verwenden Sie die standardmäßige Prüfrichtlinie.

   Vermeiden Sie insbesondere, Ereignisse und Prüf-Token zum Prüfpfad hinzuzufügen. Die folgenden Richtlinien wirken sich auf die Größe des Prüfpfads aus.

   • arge (Richtlinie): Fügt Umgebungsvariablen zu den exec-Prüfereignissen hinzu

   • argv (Richtlinie): Fügt Befehlsparameter zu den exec-Prüfereignissen hinzu

   • public (Richtlinie): Beim Prüfen von Dateiereignissen wird ein Ereignis zum Prüfpfad hinzugefügt, wenn ein prüfbares Ereignis in einer öffentlichen Datei auftritt. Zu den Dateiklassen zählen fa, fc, fd, fm, fr, fw und cl. Eine Definition der öffentlichen Datei erhalten Sie unter Terminologie und Konzepte der Prüfung.

   • path (Richtlinie): Fügt ein path-Token zu den Prüfereignissen hinzu, die ein optionales path-Token enthalten

   • group (Richtlinie): Fügt ein group-Token zu den Prüfereignissen hinzu, die ein optionales newgroups-Token enthalten

   • seq (Richtlinie): Fügt ein sequence-Token zu allen Prüfereignissen hinzu

   • trail (Richtlinie): Fügt ein trailer-Token zu allen Prüfereignissen hinzu

   • windata_down (Richtlinie): Fügt Ereignisse auf einem System hinzu, das mit Trusted Extensions konfiguriert wurde, wenn Informationen in einem beschrifteten Fenster herabgestuft wurden

   • windata_up (Richtlinie): Fügt Ereignisse auf einem System hinzu, das mit Trusted Extensions konfiguriert wurde, wenn Informationen in einem beschrifteten Fenster hochgestuft wurden

   • zonename (Richtlinie): Fügt den Zonennamen zu allen Prüfereignissen hinzu. Wenn nur die globale Zone konfiguriert wurde, wird zone, global zu allen Prüfereignissen hinzugefügt.

   Im folgenden Prüfdatensatz wird die Verwendung des Befehls ls dargestellt. Die Klasse ex wird geprüft und die Standardrichtlinie wird verwendet:

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
   path,/usr/bin/ls
   subject,jdoe,root,root,root,root,1401,737,0 0 mach1
   return,success,0

   Der folgenden Datensatz wird verwendet, wenn alle Richtlinien aktiviert sind:

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
   path,/usr/bin/ls
   attribute,100555,root,bin,136,432,0
   exec_args,1,ls
   exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root,PATH=/u
   sr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific
   path,/lib/ld.so.1
   attribute,100755,root,bin,136,4289,0
   subject,jdoe,root,root,root,root,1401,737,0 0 mach1
   group,root,other,bin,sys,adm,uucp,mail,tty,lp,nuucp,daemon
   return,success,0
   zone,global
   sequence,313540
   trailer,375

2. Verwenden Sie das Plugin audit_syslog.so, um einige Prüfereignisse an syslog zu senden.

   Diese Strategie kann nur verwendet werden, wenn keine binären Datensätze der an syslog-Protokolle gesendeten Prüfereignisse gespeichert werden müssen. Mithilfe des Befehls auditreduce können Sie anschließend diese Datensätze von den binären Dateien entfernen, wodurch sich die Größe der binären Dateien verringert.

3. Verwenden Sie die Datei audit_user, um Ereignisse für bestimmte Benutzer und Rollen zu prüfen.

   Verringern Sie den Umfang der Prüfung für alle Benutzer, indem Sie die Anzahl der Prüfklassen in der Datei audit_control reduzieren. Fügen Sie in der Datei audit_user Prüfklassen für bestimmte Benutzer und Rollen hinzu.

4. Erstellen Sie eine eigene angepasste Prüfklasse.

   Sie können Prüfklassen an Ihrem Standort erstellen. Fügen Sie alle zu überwachenden Prüfereignisse zu diesen Klassen hinzu. Eine Beschreibung des Verfahrens erhalten Sie unter So fügen Sie eine Prüfklasse hinzu.

   ---

   Hinweis - Wenn Sie vorhandene Prüfklassenzuordnungen ändern, gehen die Änderungen bei einem Upgrade zu einer neuen Version von Oracle Solaris-Betriebssystem möglicherweise verloren. Lesen Sie die Installationsprotokolle sorgfältig durch.

   ---

So prüfen Sie alle Befehle der Benutzer

An einigen Standorten erfordern die Sicherheitsrichtlinien möglicherweise, dass die Prüfdatensätze aller Befehle, die vom root-Benutzer oder von administrativen Rollen ausgeführt werden, erfasst werden. Andere Standorte erfordern möglicherweise die Erfassung der Prüfdatensätze aller Befehle, die von Benutzern ausgeführt werden.

1. Prüfen Sie die Klassen lo und ex.

   Die Klasse ex prüft alle Aufrufe der Funktionen exec() und execve(). Die Klasse lo prüft Anmeldungen, Abmeldungen und Bildschirmsperrungen. Durch die folgende Ausgabe werden alle Ereignisse in den Klassen ex und lo aufgeführt.

   7:AUE_EXEC:exec(2):ps,ex
   23:AUE_EXECVE:execve(2):ps,ex
   ...
   6152:AUE_login:login - local:lo
   6153:AUE_logout:logout:lo
   6154:AUE_telnet:login - telnet:lo
   6155:AUE_rlogin:login - rlogin:lo
   6158:AUE_rshd:rsh access:lo
   6159:AUE_su:su:lo
   6162:AUE_rexecd:rexecd:lo
   6163:AUE_passwd:passwd:lo
   6164:AUE_rexd:rexd:lo
   6165:AUE_ftpd:ftp access:lo
   6171:AUE_ftpd_logout:ftp logout:lo
   6172:AUE_ssh:login - ssh:lo
   6173:AUE_role_login:role login:lo
   6212:AUE_newgrp_login:newgrp login:lo
   6213:AUE_admin_authenticate:admin login:lo
   6221:AUE_screenlock:screenlock - lock:lo
   6222:AUE_screenunlock:screenlock - unlock:lo
   6227:AUE_zlogin:login - zlogin:lo

   • Um diese Klassen auf Administratoren zu prüfen, ändern Sie die Datei audit_user.

     Im folgenden Beispiel wurden an dem Standort drei Rollen (sysadm, auditadm und netadm) erstellt. Diese Rollen und das root-Konto werden auf die Klassen exec und lo geprüft:

     ## audit_user file
     root:lo,ex:no
     sysadm:lo,ex:no
     auditadm:lo,ex:no
     netadm:lo,ex:no

   • Um die Klasse lo auf nicht zuweisbare Ereignisse zu prüfen, ändern Sie die Datei audit_control.

     ## audit_control file
     ...
     naflags:lo
     ...

   • Um diese Klassen auf alle Benutzer zu prüfen, ändern Sie die Datei audit_control.

     ## audit_control file
     flags:lo,ex
     naflags:lo
     ...

     Es wird eine Ausgabe ähnlich der folgenden angezeigt:

     header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
     path,/usr/bin/ls
     subject,jdoe,root,root,root,root,1401,737,0 0 mach1
     return,success,0

2. Um die Argumente für Befehle aufzuzeichnen, legen Sie die Richtlinie argv fest.

   ## audit_startup script
   ...
   auditconfig -setpolicy +argv
   ...

   Durch das Token exec_args werden die Befehlsargumente aufgezeichnet:

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
   path,/usr/bin/ls
   exec_args,1,ls
   subject,jdoe,root,root,root,root,1401,737,0 0 mach1
   return,success,0

3. Um die Umgebung für die Ausführung des Befehls aufzuzeichnen, legen Sie die Richtlinie arge fest.

   ## audit_startup script
   ...
   auditconfig -setpolicy +arge
   ...

   Durch das Token exec_env wird die Befehlsumgebung aufgezeichnet:

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
   path,/usr/bin/ls
   exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root,
     PATH=/usr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific
   subject,jdoe,root,root,root,root,1401,737,0 0 mach1
   return,success,0

4. Um die Argumente und die Befehlsumgebung aufzuzeichnen, legen Sie beide Richtlinien fest.

   ## audit_startup script
   ...
   auditconfig -setpolicy +argv
   auditconfig -setpolicy +arge
   ...

   Es wird eine Ausgabe ähnlich der folgenden angezeigt:

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00
   path,/usr/bin/ls
   exec_args,1,ls
   exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root,
     PATH=/usr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific
   subject,jdoe,root,root,root,root,1401,737,0 0 mach1
   return,success,0

So suchen Sie nach Prüfdatensätzen der Änderungen an bestimmten Dateien

Wenn Sie Dateiaufzeichnungen bei einer beschränkten Anzahl von Dateien protokollieren möchten, beispielsweise /etc/passwd und die Dateien im Verzeichnis /etc/default, suchen Sie die Dateien mithilfe des Befehls auditreduce.

1. Prüfen Sie die Klasse fw.

   Indem Sie die Klasse zur Datei audit_user anstatt zur Datei audit_control hinzufügen, werden weniger Datensätze generiert.

   • Fügen Sie die Klasse fw zur Datei audit_user hinzu.

     ## audit_user file
     root:fw:no
     sysadm:fw:no
     auditadm:fw:no
     netadm:fw:no

   • Fügen Sie die Klasse fw zur Datei audit_control hinzu.

     ## audit_control file
     flags:lo,fw
     ...

2. Um die Prüfdatensätze bestimmter Dateien zu suchen, verwenden Sie den Befehl auditreduce.

   # /usr/sbin/auditreduce -o file=/etc/passwd,/etc/default -O filechg

   Durch den Befehl auditreduce wird der Prüfpfad nach allen Instanzen des Arguments file durchsucht. Der Befehl erstellt eine binäre Datei mit dem Suffix filechg, die alle Datensätze mit den Pfadnamen der gewünschten Dateien enthält. Weitere Informationen zur Syntax der Option -o file=pathname erhalten Sie auf der Manpage auditreduce(1M).

3. Verwenden Sie zum Lesen der Datei filechg den Befehl praudit.

   # /usr/sbin/praudit *filechg

So ändern Sie die Vorauswahlmaske eines Benutzers

Wenn Sie die Datei audit_control oder audit_user ändern, ändert sich die Vorauswahlmaske der bereits angemeldeten Benutzer nicht. Sie müssen das Ändern der Vorauswahlmaske erzwingen.

Bevor Sie beginnen

Sie haben die Prüfung aktiviert, die Benutzer sind angemeldet und Sie haben den Wert von flags oder naflags in der Datei audit_control geändert. Sie möchten die bereits angemeldeten Benutzer auf diese neu ausgewählten Prüfklassen prüfen.

1. Aktualisieren Sie die Vorauswahlmaske der bereits angemeldeten Benutzer.

   Es sind folgende zwei Möglichkeiten verfügbar. Sie können die vorhandenen Sitzungen beenden oder mit dem Befehl auditconfig die Vorauswahlmasken der Benutzer aktualisieren.

   • Beenden Sie die vorhandenen Sitzungen der Benutzer.

     Die Benutzer können sich abmelden und anschließend erneut anmelden oder der Administrator kann die aktiven Sitzungen manuell beenden (abbrechen). Die neuen Sitzungen übernehmen die neue Vorauswahlmaske. Das Beenden der Benutzer kann sich jedoch als unpraktisch erweisen.

   • Ändern Sie dynamisch die Vorauswahlmaske der einzelnen Benutzer.

     Beispielsweise wurde das Attribut flags in der Datei audit_control von lo in lo,ex geändert.

     1. Stellen Sie die Prüf-ID eines Benutzers und die Prüfsitzungs-ID fest.

        Suchen Sie zunächst alle gewöhnlichen Benutzer. Im folgenden Beispiel sucht der Administrator nach allen Prozessen, deren Eigentümer nicht root, daemon oder lp ist:

        # /usr/bin/pgrep -v -u root,daemon,lp | more 
        ..
        3941
        3948
        3949
        10640 ...

        Verwenden Sie anschließend einen der Benutzerprozesse, um die Prüf-ID des Benutzers zu suchen:

        # auditconfig -getpinfo 3941
        audit id = jdoe(1002)
        process preselection mask = lo(0x1000,0x1000)
        terminal id (maj,min,host) = 9426,65559,mach1(192.168.123.234)
        audit session id = 713

        Achten Sie darauf, dass die Vorauswahlmaske des Benutzers die Klasse lo enthält und die neu hinzugefügte Klasse ex nicht enthält.

     Die Prüf-ID des Benutzers lautet 1002. Die Prüfsitzungs-ID des Benutzers lautet 713.

2. Ändern Sie die Vorauswahlmaske des Benutzers.

   Verwenden Sie eine der folgenden zwei Methoden:

   • Verwenden Sie die Prüfsitzungs-ID des Benutzers, um die Vorauswahlmaske des Benutzers zu ändern.

     # /usr/sbin/auditconfig -setsmask lo,ex 713

   • Verwenden Sie die Prüf-ID des Benutzers, um die Vorauswahlmaske des Benutzers zu ändern.

     # /usr/sbin/auditconfig -setumask lo,ex 1002

3. Vergewissern Sie sich, dass die Vorauswahlmaske geändert wurde.

   # auditconfig -getpinfo 3941
   audit id = jdoe(1002)
   process preselection mask = ex,lo(0x40001000,0x40001000) 
   terminal id (maj,min,host) = 9426,65559,mach1(192.168.123.234)
   audit session id = 713

So verhindern Sie die Prüfung bestimmter Ereignisse

Aus Wartungsgründen muss an einigen Standorten möglicherweise verhindert werden, dass Prüfereignisse geprüft werden.

1. Ändern Sie die Klasse des Ereignisses in die Klasse no.

   Beispielsweise gehören die Ereignisse 26 und 27 zur Klasse pm.

   ## audit_event file
   ...
   25:AUE_VFORK:vfork(2):ps
   26:AUE_SETGROUPS:setgroups(2):pm
   27:AUE_SETPGRP:setpgrp(2):pm
   28:AUE_SWAPON:swapon(2):no
   ...

   Ändern Sie die Klasse dieser Ereignisse in die Klasse no.

   ## audit_event file
   ...
   25:AUE_VFORK:vfork(2):ps
   26:AUE_SETGROUPS:setgroups(2):no
   27:AUE_SETPGRP:setpgrp(2):no
   28:AUE_SWAPON:swapon(2):no
   ...

   Wenn die Klasse pm derzeit geprüft wird, werden die Ereignisse 26 und 27 weiterhin in den vorhandenen Sitzungen geprüft. Damit diese Ereignisse nicht geprüft werden, müssen Sie die Vorauswahlmasken der Benutzer aktualisieren.

   ---

   Achtung - Setzen Sie die Ereignisse in der Datei audit_event niemals in Kommentare. Diese Datei wird vom Befehl praudit zum Lesen binärer Prüfdateien verwendet. Archivierte Prüfdateien enthalten möglicherweise Ereignisse, die in der Datei aufgeführt sind.

   ---

2. Anweisungen zum Aktualisieren der Vorauswahlmasken der Benutzer erhalten Sie unter So ändern Sie die Vorauswahlmaske eines Benutzers.

So beschränken Sie die Größe binärer Prüfdateien

Für die Größe der binären Prüfdateien gibt es keine Beschränkung. Sie können die Größe beschränken, um die Archivierung und Suche zu erleichtern. Außerdem können Sie auch kleinere binäre Dateien aus der Originaldatei erstellen.

1. Verwenden Sie ab der Version Solaris 10 10/08 das Attribut p_fsize, um die Größe der jeweiligen binären Prüfdateien zu beschränken.

   Durch das Attribut p_fsize des Plugins audit_binfile.so können Sie die Größe einer Prüfdatei beschränken. Der Standardwert ist Null (0), wodurch keine Beschränkung für die Dateigröße besteht. Der Wert wird in Byte von 512.000 bis 2.147.483.647 angegeben. Wenn die angegebene Größe erreicht wurde, wird die aktuelle Prüfdatei geschlossen und eine neue Datei geöffnet.

   Im folgenden Beispiel wird die Größe einer Prüfdatei auf 1 MB begrenzt:

   plugin:name=audit_binfile.so; p_dir:/var/audit; p_fsize=1024000

2. Wählen Sie mit dem Befehl auditreduce die Datensätze aus und zeichnen Sie diese Datensätze in einer Datei auf, um sie für eine weitere Analyse zu verwenden.

   Durch die Optionen auditreduce -lowercase werden bestimmte Datensätze gesucht.

   Durch die Optionen auditreduce -Uppercase wird die Auswahl in eine Datei geschrieben. Weitere Informationen erhalten Sie auf der Manpage auditreduce(1M).

So prüfen Sie Anmeldungen von anderen Betriebssystemen

Bei Oracle Solaris können alle Anmeldungen unabhängig von der Quelle geprüft werden.

• Prüfen Sie die Klasse lo auf zuweisbare und nicht zuweisbare Ereignisse.

  Durch diese Klasse werden Anmeldungen, Abmeldungen und Bildschirmsperrungen geprüft.

  ## audit_control file
  flags:lo
  naflags:lo
  ...

  ---

  Hinweis - Um ssh-Anmeldungen zu prüfen, muss auf dem Oracle Solaris-System der ssh-Dämon von Oracle Solaris ausgeführt werden. Dieser Dämon wurde für die Oracle Solaris-Prüfung geändert. Weitere Informationen erhalten Sie unter Oracle Solaris Secure Shell und das OpenSSH-Projekt.

  ---

So prüfen Sie FTP- und SFTP-Dateiübertragungen

Der FTP-Service erstellt Protokolle der zugehörigen Dateiübertragungen. Der SFTP-Service, der unter dem SSH-Protokoll ausgeführt wird, kann durch die Oracle Solaris-Prüfung geprüft werden. Die Anmeldungen an beiden Services können durch die Oracle Solaris-Prüfung geprüft werden.

1. Weitere Informationen zum Protokollieren von Befehlen und Dateiübertragungen des FTP-Service erhalten Sie auf der Manpage ftpaccess(4).

   Weitere Informationen zu den verfügbaren Protokollierungsoptionen erhalten Sie im Abschnitt zu den Protokollierungsfunktionen. Insbesondere durch die Optionen log commands und log transfers erhalten Sie hilfreiche Protokolle.

2. Verwenden Sie mindestens eine der beiden folgenden Vorgehensweisen, um sftp-Dateiübertragungen zu protokollieren:
   • Prüfen Sie die Dateilesezugriffe.

     Bei Dateiübertragungen über eine SSH-Verbindung wird der Befehl sftp verwendet. Diese Übertragungen können mithilfe des Prüf-Flags +fr aufgezeichnet werden. Um fehlgeschlagene sftp-Dateiübertragungen zu prüfen, verwenden Sie das Prüf-Flag -fr.

     Im Folgenden sehen Sie die Ausgabe einer erfolgreichen sftp-Sitzung:

     header,138,2,open(2) - read,,ma2,2009-08-25 14:48:58.770 -07:00
     path,/home/jdoe/vpn_connect
     attribute,100644,jdoe,staff,391,437,0
     subject,jdoe,jdoe,staff,jdoe,staff,4444,120289379,8457 65558 ma1
     return,success,6

   • Verwenden Sie die Option für eine ausführliche Ausgabe des Befehls sftp.

     Die Option -v (verbose) kann bis zu dreimal wiederholt werden.

     # sftp -vvv [ other options ] hostname 

3. Um den Zugriff auf die FTP- und SFTP-Services aufzuzeichnen, prüfen Sie die Klasse lo.

   Wie Sie anhand der folgenden Ausgabe sehen, werden durch das An- und Abmelden beim Dämon ftpd Prüfdatensätze generiert.

   % bsmrecord -c lo | more
   ...
   in.ftpd
     program     /usr/sbin/in.ftpd    See ftp access
     event ID    6165                 AUE_ftpd
     class       lo                   (0x00001000)
         header
         subject
         [text]                       error message
         return
   
   in.ftpd
     program     /usr/sbin/in.ftpd    See ftp logout
     event ID    6171                 AUE_ftpd_logout
     class       lo                   (0x00001000)
         header
         subject
         return
   ...

   Durch die SSH-Anmeldung werden alle Zugriffe auf den Befehl sftp aufgezeichnet.

   ...
   /usr/lib/ssh/sshd
     program     /usr/lib/ssh/sshd    See login - ssh
     event ID    6172                 AUE_ssh
     class       lo                   (0x00001000)
         header
         subject
         [text]                       error message
         return