I tried reversing the order of directories to be monitored
/application/progs
/
application
and received this alert
Received From: server4->syscheck
Rule: 550 fired (level 7) -> "Integrity checksum changed."
Portion of the log(s):
Integrity checksum changed for: '/application/progs/progf
Hello Jeremy,
Yes it is a web application server (Jboss/Tomcat/Apache)...
Ok it is a false positive but is it a good idea to modify the rule ?
Thanks in advance,
Bob !
Le 13/10/2010 16:04, Jeremy Rossi a écrit :
Does the server spawn a very large number of new processes? Such as a large
ma
Is there a way of making the restrictions in local rules?
I could monitor from /application downwards with check_all
Then in the local rule I would need to do some kind of match on where
under /application it was.
e.g.
If /application then
if progs then
elseif spool then
fi
I know I can sp
I was more interested in whether using the other check options
(non-overlapping check options) would help.
Still good to know though.
On Thu, Oct 14, 2010 at 4:51 AM, ItsMikeE wrote:
> I tried reversing the order of directories to be monitored
>
> /application/progs
> /
> application
>
> an
I don't see how I could set that up, unless I was sure that there
would not be any new subdirectories under /application in the future.
Thanks all for your responses. Just to be clear: I am not currently
under attack. When my boss found out that I'd enabled something that
could block IP's from our web site, he became anxious. I just wanted
to explore the possibility that Active Response could cause more
problems than it prevents.
On Thu, Oct 14, 2010 at 9:47 AM, ItsMikeE wrote:
> I don't see how I could set that up, unless I was sure that there
> would not be any new subdirectories under /application in the future.
You wanted check_all for certain directories (/application/binaries in
your original email). check_perm, own
Just re-read your original response, which I now realise I had
misunderstood.
Will test this out and report back.
On Oct 14, 3:13 pm, "dan (ddp)" wrote:
>
> If I'm correct, then my original suggestion attempts to do this. I
> still don't know if it will work. Trying to work around crazy rarely
>
I think it may still have issues, but I haven't had a chance to test it yet.
Having duplicate entries in the syscheck db might be the big problem.
Beyond this you could probably turn on the alert on new files option
and create a rule for it. And possibly create a rule to ignore the
syscheck stuff y
Hi Michael,
Can you please let me know where articles/links should be published to. Do
I just announce an article with its link on this list, or is there a wiki
page that I have to update?
Apologies if you've already mentioned this before.
Regards,
Chris
On Sun, Oct 10, 2010 at 9:09 AM, Micha
Hi,
It doesn't seem to work in Windows with this in the ossec.conf:
full_command
netstat -an | find "LISTEN"
Nothing in the ossec.log to say it's going to monitor this "localfile".
I'm running 2.4.1 on server and agent.
What about the registry ignore problem? I've tried to ignore "G
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/14/2010 01:50 PM, Christopher Moraes wrote:
> Hi Michael,
>
> Can you please let me know where articles/links should be published to.
> Do I just announce an article with its link on this list, or is there a
> wiki page that I have to update?
On Thu, Oct 14, 2010 at 3:50 PM, Jason 'XenoPhage' Frisvold
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/14/2010 01:50 PM, Christopher Moraes wrote:
>> Hi Michael,
>>
>> Can you please let me know where articles/links should be published to.
>> Do I just announce an article
I've seen similar OSSEC alerts for netstat before...
In my case, when I compared the md5 hash of the running netstat with that of
the
RPM package, it was different! So, very suspicious... I forced a re-install the
RPM package to the system, and the these alerts went away.
Hard to say if this
It really depends on what your script does. Active Response doesn't
technically "block" anything - it just allows for passing of certain
parameters/variables to scripts so that you can take actionable measures.
Explaining it that way might help... although, it might confuse him even
more! But one e
On Thu, Oct 14, 2010 at 4:02 PM, Jefferson, Shawn
wrote:
> Hi,
>
> It doesn't seem to work in Windows with this in the ossec.conf:
>
>
> full_command
> netstat -an | find "LISTEN"
>
>
> Nothing in the ossec.log to say it's going to monitor this "localfile".
>
> I'm running 2.4.1 on server
16 matches
Mail list logo
