Hi BP9906,
Could you please provide an configuration example? thanks.
On 12月21日, 上午3時02分, BP9906 wrote:
> We had to do that also, since we found it difficult to make sure
> machines were communicating correctly. Like the server looking for
> ossec agent errors in its own log, and also when an ag
Confirmed.
So to re-cap and clarify on Jake's discovery, the repeated_offenders block goes
on the AGENTS' ossec.conf file. Also important is that the repeated_offenders
block is NOT on the server's ossec.conf (I had repeated offenders in each
active response block, and the agents were ignoring
Ah yes, I see what you're talking about now, but I can see from the
alerts.log file that it does contain the whole output current and
previous. Seems like email isnt getting the whole thing in the body.
On Dec 20, 11:09 am, "dan (ddp)" wrote:
> On Tue, Dec 20, 2011 at 1:57 PM, BP9906 wrote:
> >
On Tue, Dec 20, 2011 at 1:57 PM, BP9906 wrote:
> So what does logall do? How does that relate to the email getting
> chopped off?
>
The idea was to see if the output is chopped off before it gets to the
manager or after.
http://www.ossec.net/doc/syntax/head_ossec_config.global.html#element-logal
It does sound like a bug to me.
On Tue, Dec 20, 2011 at 2:02 PM, Kat wrote:
> Something to ponder however -- I thought it was in there - instead
> there was an unmatched on a line within the command
> definition - and no error was generated, that is how I missed it.
>
> A bug perhaps?
>
> On Dec
So what does logall do? How does that relate to the email getting
chopped off?
On Dec 20, 9:01 am, "dan (ddp)" wrote:
> On Tue, Dec 20, 2011 at 11:52 AM, BP9906 wrote:
> > The alerts.log contains both the output and previous output. The email
> > does not.
>
> > Whats the log_all option you refe
We had to do that also, since we found it difficult to make sure
machines were communicating correctly. Like the server looking for
ossec agent errors in its own log, and also when an agent fails to
look at a log file it's supposed to, we would trigger an agent restart
command (agent_control) from
Something to ponder however -- I thought it was in there - instead
there was an unmatched on a line within the command
definition - and no error was generated, that is how I missed it.
A bug perhaps?
On Dec 20, 10:21 am, Kat wrote:
> A! ... um, No. :-(
>
> On Dec 20, 10:14 am, "dan (ddp)"
On 12/20/2011 09:07 AM, alsdks wrote:
> Hello,
Hello,
>
>
> Is there a way to have reportd to not "cutt" long paths , it seems to
> have a max character limitation.
I was working on this last week, I had to modify the source code for
monitord, I think the file is: src/shared/report_op.c.
You can
On Tue, Dec 20, 2011 at 11:52 AM, BP9906 wrote:
> The alerts.log contains both the output and previous output. The email
> does not.
>
> Whats the log_all option you refer to? I couldnt find any reference to
> it online.
>
I meant logall. I apparently get those mixed up.
> On Dec 19, 4:36 pm, "d
The alerts.log contains both the output and previous output. The email
does not.
Whats the log_all option you refer to? I couldnt find any reference to
it online.
On Dec 19, 4:36 pm, "dan (ddp)" wrote:
> On Mon, Dec 19, 2011 at 6:46 PM, BP9906 wrote:
> > When I get email alerts for mine, I only
A! ... um, No. :-(
On Dec 20, 10:14 am, "dan (ddp)" wrote:
> Is srcip set in the command definition?
Is srcip set in the command definition?
On Tue, Dec 20, 2011 at 11:01 AM, Kat wrote:
> I am baffled --
>
> Below is an alert - which triggered an active response. It should have
> executed a block on my pix, but for some reason the IP was lost in
> translation so to speak. The Src IP shows up cor
I am baffled --
Below is an alert - which triggered an active response. It should have
executed a block on my pix, but for some reason the IP was lost in
translation so to speak. The Src IP shows up correctly in the alert,
and in the script, it is set via $3, but if I output the string with a
simp
Hello,
Is there a way to have reportd to not "cutt" long paths , it seems to
have a max character limitation.
For example output of "zcat logs/alerts/2011/Dec/*.gz | bin/ossec-
reportd -n "Month Summary" 2>" is showing like :
Top entries for 'Filenames':
---
It's on a long-range TODO list. Along with a million other things :P
On Tue, Dec 20, 2011 at 9:24 AM, alsdks wrote:
> Hi Dan,
>
> That's what I thought it would need.
>
> So basically to achieve this, removing general /etc monitoring is the
> only option.
>
> Pity though, it would be nice to have
Hi Dan,
That's what I thought it would need.
So basically to achieve this, removing general /etc monitoring is the
only option.
Pity though, it would be nice to have those more granular settings
override the check_all option, or something like that .
Thank you very much !
On Dec 20, 3:56 pm, "
On Tue, Dec 20, 2011 at 8:31 AM, alsdks wrote:
> Hello list,
>
> I want to be able to report on what changed for specific files under /
> etc .
> ossec.conf monitors /etc recursively for check_all but I would like
> for example to be able to see what changed in hosts, passwd etc .
>
> So I have se
Hello list,
I want to be able to report on what changed for specific files under /
etc .
ossec.conf monitors /etc recursively for check_all but I would like
for example to be able to see what changed in hosts, passwd etc .
So I have set up an extra entry that looks like this :
/etc/
hosts,/etc/p
Hello Dan ,
Sorry it took some time .For the command I specified I get in
archives.log about 95 lines (copy paste the output to a text editor).
It looks like this
c:\WINDOWS\system32\cliconfg.exe NT SERVICE\TrustedInstaller:(F)
BUILTIN\Administrators:(RX)
20 matches
Mail list logo
