I'm wondering the same thing. Whats the difference between the 2
anyway?
I'm ultimately trying to have 2 frequency rules and the second one
doesnt fire. I suspect its something to do with the if_sid or
if_matched_sid.
On Jun 27, 2:09 pm, "dan (ddp)" wrote:
> Hi Jason,
>
> On Mon, Jun 27, 2011 at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/2011 12:16 PM, Christopher Moraes wrote:
> Hi everyone,
>
> Continuing with my enhancements to support agent configuration profiles
> (see thread
> :
> http://groups.google.com/group/ossec-list/browse_thread/thread/28a76c8180e28a4b),
> I hav
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/06/2011 08:15 PM, jplee3 wrote:
> One other question I have regarding frequency rules and hierarchy. We
> currently have two frequency rules setup to trigger against a parent
> rule where the difference is the frequencies - one is set to trigger
Thanks for the suggestion. I tried this out briefly and it doesn't seem to
work. The rule that triggers is the upper but I never saw the lower trigger.
On Thu, Jul 7, 2011 at 10:07 AM, Jason 'XenoPhage' Frisvold <
xenoph...@godshell.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
So, is there any other way to disable this? My
/var/ossec/logs/ossec.log is at 10 GB now.
William
Other than the log message there isn't any indication the processes
are running in debug mode.
This is how they generally look in debug mode:
root 4356 4.4 0.4 7600 7720 ?? S 29Jun11 185:22.82
/var/ossec/bin/ossec-syscheckd -d
ossecm 36 0.0 0.2 4564 4940 ?? S 29Jun11
On Thu, Jul 7, 2011 at 11:44 AM, dan (ddp) wrote:
> Other than the log message there isn't any indication the processes
> are running in debug mode.
> This is how they generally look in debug mode:
> root 4356 4.4 0.4 7600 7720 ?? S 29Jun11 185:22.82
> /var/ossec/bin/ossec-syscheckd
Hello Folks,
I am at wits' end with an issue: I have written up an OSSEC rule that
detects whether a Zimbra mail server is acting up.
There is no issue with the syntax of the rule: it passes the ossec-
logtest with flying colors. The rule works 100% when I deliberately
insert for testing purposes
Hi William,
It is possible that someone may have accidentally changed the following
debug flag in your OSSEC installation.
I suggest you check the following -
Go to the directory from where you installed OSSEC,
locate the src/shared directory
open the file debug_op.c
Around line #16, you will se
Just guessing here, but the issue could be the use of spaces v/s tabs.
Which decoders are being used for mailbox.log and audit.log?
I faced a similar issue when I copied and pasted a log into a test file (the
tabs got copied over). However when I ran a script to insert the logs into
a log file,
Hello All,
Taking some advice on this list, I converted all my agents to a
minimal ossec.conf(just the server IP). Inside the agent.conf
file on the server, I have my entire configuration. This is working
quite nicely now, but I have one nagging issue. I keep getting
alerts regarding file changes
Try deleting the agent.conf file on the agent and restart the ossec server
(ossec-control restart) and then restart the ossec agent. See if the new
agent.conf file gets copied. I've seen with 2.5.1 that the agent.conf file
doesnt get overwritten in some instances, regardless of permissions, owners.
I am using the same decoder for both log files (that's log4j above)
I did paste the log entry into a text file, whose contents I then
piped through a Linux command into the target log, be it audit.log or
mailbox.log. I mad sure that the log entry was free of tabs. What gets
me is that the zimbra s
I have the same issue. I have a custom decoder, and 2 composite
(frequency/reoccurring) rules.
The first composite rule matches properly, even when testing with
ossec-logtest.
I'm trying to match the same IP for a lower bound threshold and an
upper bound thresdhold.
Example:
10 in 3 minutes
20 i
I'd like to add that mailbox.log is a rotating log and that we
schedule this log to rotate every night. Also note that mailbox.log is
about 40 x larger than audit.log
On Jul 7, 5:33 pm, blacklight wrote:
> I am using the same decoder for both log files (that's log4j above)
>
> I did paste the lo
On 07/06/2011 08:00 PM, Jeremy Lee wrote:
Thanks Michael.
I guess that means that in the actual alert, once it triggers, the alert
will come from whatever box it got triggered at?
Well, the *alert* actually comes from the OSSEC manager, and the alert
will contain the logs that compromise the
16 matches
Mail list logo