Hi Chris,
Thanks for the information. This is indeed a false positive and can
easily be ignored by adding the
following local rule:
<rule id="100101" level="0">
<if_sid>510</if_sid>
<match>^NTFS Alternate data stream found</match>
<regex>Program Files/Exchsrvr/Mailroot/</regex>
<description>Ignored common NTFS ADS entries.</description>
</rule>
I will make sure to add that to the default list of valid ADS for the
next version...
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Nov 4, 2007 1:20 PM, Chris Buechler <[EMAIL PROTECTED]> wrote:
>
>
> On 11/3/07, Dennis Borkhus-Veto <[EMAIL PROTECTED]> wrote:
> > I have received the following error on a win 2003 svr with exchange 2003
> > how should I go about checking this.
> >
> > rootcheck
> > Rule: 510 fired (level 7) -> "Host-based anomaly detection event
> > (rootcheck)."
> > Portion of the log(s):
> >
> > NTFS Alternate data stream found: 'C:\/Program Files/Exchsrvr/Mailroot/vsi
> > 1/Queue/NTFS_63bb493301c81d7f00000d86.EML:PROPERTIES-LIVE'. Possible hidden
> > content.
> >
>
> This is your Exchange SMTP queue. It uses alternate data streams to function.
>
> From http://technet.microsoft.com/en-us/library/bb124461.aspx
>
> "Messages are categorized only once. For messages in the \Queue folder
> on the file system, the categorizer uses alternate data streams, a
> little known NTFS feature, to persist the MailMsg property stream,
> which includes message envelope and categorization information.
> Alternate data streams enable data storage in hidden files, which are
> linked to a visible file on an NTFS partition. When the SMTP service
> cannot transfer a message immediately and must retry at a later time,
> the message is saved and closed. Part of that operation involves
> saving the existing MailMsg property stream, so that it can be
> reloaded and used when the message transfer is retried. However, if
> you must categorize a message again (for example, if it is queued for
> a destination server that no longer exists) you will notice that
> categorization is not performed a second time."
>
>
> So this is normal. I'm not familiar enough with OSSEC yet to tell you
> how to silence this, but hopefully somebody else will weigh in on
> that.
>
> Chris
>
