Frage zu Tripwire (welche Dateien sollten überprüft werden?)

[killerhorse]

Hallo,

Habe vor in Zukunft auf meinem Server Tripwire einzusetzen. Habe dazu das tw.pol File, mit den Informationen die auf mein System zutreffen, neu erstellt. Das heisst ich hab nicht vorhandene Dateien entfernt und z.B. bei de Binaries /usr/local/apache2/bin hinzugefügt.
Es sind nun zwei Probleme aufgetreten die mir nicht ganz klar sind:

1. File system error.
Filename: /proc/26297/fd/3
No such file or directory
File system error.
Filename: /proc/26297/task/26297/fd/3
No such file or directory

Warum findet er da 2 Dateien nicht, die garnicht explizit angegeben sind? Es ist lediglich /proc angegeben. Sieht so aus:

# Critical devices
#
(
rulename = "Devices & Kernel information",
severity = $(SIG_HI),
)
{
/dev -> $(Device) ;
/proc -> $(Device) ;
}



Die zweite Frage: welchen Sinn hat es überhaupt das proc Filesystem, so wie in der Standartkonfiguration, zu überprüfen? Bei mir gibt es da bei jedem Integritätscheck massenweise Unterschiede in Form von hinzugefügten und gelöschten Dateien!?


Mein System läuft übrigens mit Debian Sarge und einem selbstgebackenen 2.6.8er Kernel. Die Möglichkeit Module hinzuzuladen ist deaktiviert.

Würde mich freuen wenn mir jemand weiterhelfen kann.

MfG

Christian

[pibi]

Warum findet er da 2 Dateien nicht, die garnicht explizit angegeben sind? Es ist lediglich /proc angegeben. Sieht so aus:Ob es Sinn macht, das /proc in TripWire einzubinden, sei mal ausdruecklich dahingestellt. Und wenn, dass natuerlich nur diejenigen Items, die in der Regel konstant bleiben. Bei mir sieht der betr. Passus so aus:
(
rulename = "Kernel Process Information",
severity = $(SIG_HI),
emailto = $(SIG_HI_MAILRECIPIENTS)
)
{
/proc/ksyms -> $(SEC_PROC) ;
/proc/cpuinfo -> $(SEC_DYN_PROC) ;
/proc/devices -> $(SEC_PROC) ;
/proc/dma -> $(SEC_PROC) ;
/proc/pci -> $(SEC_PROC) ;
/proc/ioports -> $(SEC_PROC) ;
#/proc/iomem -> $(SEC_PROC) ; # This module may not be present in some Kern
els.
#/proc/isapnp -> $(SEC_PROC) ; # This module may not be present in some Kern
els.
/proc/modules -> $(SEC_DYN_PROC) ;
/proc/mounts -> $(SEC_DYN_PROC) ;
/proc/partitions -> $(SEC_DYN_PROC) ; # This changes quite often
/proc/net -> $(SEC_DYN_PROC) ;
/proc/sys -> $(SEC_DYN_PROC) ;
/proc/sys/dev -> $(SEC_PROC) ;
/proc/filesystems -> $(SEC_PROC) ;
/proc/interrupts -> $(SEC_DYN_PROC) ;
#/proc/rtc -> $(SEC_PROC) ; # This module may not be present in some Kern
els.
#/proc/scsi -> $(SEC_PROC) ; # Uncomment this if you have SCSI devices
/proc/self -> $(SEC_DYN_PROC) ;
/proc/stat -> $(SEC_DYN_PROC) ;
/proc/loadavg -> $(SEC_DYN_PROC) ;
/proc/uptime -> $(SEC_DYN_PROC) ;
/proc/locks -> $(SEC_DYN_PROC) ;
/proc/version -> $(SEC_PROC) ;
#/proc/mdstat -> $(SEC_PROC) ;
/proc/meminfo -> $(SEC_DYN_PROC) ;
/proc/cmdline -> $(SEC_PROC) ;
/proc/misc -> $(SEC_PROC) ;
}
Die dazugehoerigen Definitionen:
SEC_PROC = $(IgnoreNone)-bramcsi ; # Used for scanning the Kernel Process area

SEC_DYN_PROC = $(IgnoreNone)-bramcsiSHMC ; # Used for scanning the Kernel Process area for processes that change contents.

Die zweite Frage: welchen Sinn hat es überhaupt das proc Filesystem, so wie in der Standartkonfiguration, zu überprüfen? Bei mir gibt es da bei jedem Integritätscheck massenweise Unterschiede in Form von hinzugefügten und gelöschten Dateien!?Meine Rede;-)

Gruss Pit.