Hi, I have this problem very often. I've read that the process is: - Open every directory on the system and list the files (readdir). - For every file that it found on "readdir", it tries the *stat call to see if the system can see it too.
To avoid false positive when a file is deleted, Ossec should make an other check with readdir when a problem is detected: - Open every directory on the system and list the files (readdir). - For every file that it found on "readdir", it tries the *stat call to see if the system can see it too. - For every file that stat and readdir haven't the same result, make another check with readdir to see if the readdir changed Le mardi 15 mars 2011 03:25:11 UTC+1, Jason 'XenoPhage' Frisvold a écrit : > > On Mar 4, 2011, at 2:30 PM, dan (ddp) wrote: > > I haven't done much research into this, but my guess would be that > > this is a false positive. > > /dev/shm seems to be some strange shared memory access. > > lsof is claiming that those files are deleted (type = DEL). > > > > My best guess would be that this is some kind of strange interaction > > between /dev/shm, the clustering stuff, and OSSEC's checks. I'd hit up > > support at redhat to see if they have any thoughts on the matter. > > > This happens when a file is deleted underneath an OSSEC rootkit scan. > I've seen it a few times and every time it happens it's the same > explanation. > > --------------------------- > Jason 'XenoPhage' Frisvold > [email protected] <javascript:> > --------------------------- > "Any sufficiently advanced magic is indistinguishable from technology." > - Niven's Inverse of Clarke's Third Law > > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
