There is no reliable way to tell that an interactive user has "logged off"
in Windows. Mostly because AD doesn't record an interactive logoff on the
domain controller. All the log-off messages you see on the DC are for
network sessions (e.g. accessing network drives/printers). You can get some
I wrote a decoder for Windows DHCP server logs that are being
collected through Epilog. It would be easy to adapt it to fit other
transport mechanisms. (ie NTSyslog, LASSO, etc...) I hope this helps
someone.
decoder.xml
IISWebLog|DHCPLog\s\d
windows-epilog
true
I have v1.6.1 running in a 64-bit Windows 2003 environment with no
problems.
On Dec 3, 6:37 am, [EMAIL PROTECTED] wrote:
> Installing v1.6.1 agent on 64-bit Windows 2003 server appears to have
> corrupted the event logs and sent the server into endless reboot
> cycle.
>
> Windows 2003 Server STD
Correct, 8.5.0i
On Nov 21, 8:45 pm, Michael Starks <[EMAIL PROTECTED]>
wrote:
> shadejinx wrote:
> > I installed an OSSEC agent on our McAfee server and most alerts are
> > not being picked up by OSSEC. After some research into the rules, I
> > think I found the cu
I noticed the wiki has some ISA firewall samples. Does 1.6.1 parse
these yet?
Separate reports are nice, but the I think the timely nature of IDS
information makes them ultimately useless for the function if the
IDS. Following that train of thought, they are probably best suited
for people who are a step or two removed from the monitoring or
operation of the IDS; managers
Man, you Splunk guys are on the ball.
Nice, I'll try that search, but it doesn't look efficient enough to
run in near real time, especially when parsing the uselessly verbose
Windows event logs.
On Nov 23, 4:27 am, Raffy <[EMAIL PROTECTED]> wrote:
> > Excellent question, and the answer is twofol
I installed an OSSEC agent on our McAfee server and most alerts are
not being picked up by OSSEC. After some research into the rules, I
think I found the culprit.
18101,18102,18103
windows
^McLogEvent
Grouping of McAfee Windows AV rules.
This rule is not always true. McAfee a
than having it parse the files. For the few servers that I have been
> testing OSSEC on (about 10), the output has been easy to parse for the events
> I have been looking for.
>
> -Original Message-
> From: ossec-list@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of
So far, I have been unimpressed with the WUI and decided to use Splunk
as the interface to OSSEC. If you don't know what Splunk is, head to
www.splunk.com and check it out. It's a fantastic product for
correlating log data, and there's a free version that's perfect for
the volume of data output
In the most current msauth-rules.xml, eventid 680 is disabled, stating
that it is a duplicate. Unfortunately that is not the case. A failed
680 event is how a Windows 2003 Server AD controller denotes a failed
NTLM login. A failed 672 is how it denotes failed Kerberos
connections.
These attemp
I noticed this. There appears to be a memory leak with event log
monitoring. I commented that portion out of the config and haven't
had any memory problems.
To get the event logs off, I installed SNARE and had it forward them
to OSSEC. (or rather, to a syslog-ng separated file that the OSSEC
s
12 matches
Mail list logo
