Re: [ossec-list] Re: What's a good way to update syscheck after an apt-get upgrade?

[Brad Lhotsky]

Yes, but the patch is just a hook to the real logic.  A simple AR script to verify once you can pass filename with this patch might look like this:

#!/bin/sh

filename=$6

pkg=$(rpm -q --whatprovides $filename)

if [ ! -z "$pkg" ]; then

  rpm -V $pkg

  rc=$?

  if [ $rc -ne 0 ]; then

     logger -t ossec-ar-verify "fim file:$filename managed:yes manager:rpm pkg:$pkg change:verified"

  else

    (($DEBUG)) && echo "File was changed by an RPM install";

  fi;

else

  logger -t ossec-ar-verify "fim file:$filename managed:no change:verified"

fi;

Then you write an ossec decoder and rules around those log lines tied to the 'ossec-ar-verify' program_name.

On Tue, May 28, 2013 at 9:40 PM, mntbighker <mntbi...@gmail.com> wrote:

Is this patch going to apply to yum update as well? Or what method is suggested for addressing the same concerns as apt-get?


On Tuesday, May 28, 2013 10:55:23 AM UTC-7, Brad Lhotsky wrote:

Working on a fix for that specifically after running into a problem with Active Response trying to implement it.

The first piece is to abuse ActiveResponse, and to enable that this patch (https://gist.github.com/reyjrar/5663893) allows the passing of filename using "<expect>filename</expect>" in the command definition.  My colleagues are using this to build scripts to verify checksums against Puppet, Git, and rpm.  The same architecture could be leveraged to check against apt or whatever else.

I haven't tested this patch yet, but it does compile, I'll have a battle tested patch tomorrow.

On Monday, May 27, 2013 10:57:12 PM UTC+2, Gerard Petersen wrote:

Hi All,

After updating my servers with the cyclic apt-get updates I get notifications over time right thereafter from all updated agents. But those are predicted and thus somewhat useless, moreover .. flooding my mailbox. What I'm looking for is an instant 'new snapshot' of my servers. What I've found sofar is this:

# Clearing an agents database
/var/ossec/bin/syscheck_control -u 002

# force a syscheck scan (and re-populating the database)
/var/ossec/bin/agent_control -r -u 002

 But 'dropping' the database and refilling it seems overkill and possibly resulting in unnecessary server load. Anybody a better way to manage this?

Thanx in advance.

Kind regards,

Gerard.

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "ossec-list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ossec-list/oI7TY38f9P0/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to ossec-list+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Brad Lhotsky

[Xavier Mertens]

Hi Gerard,

I'm facing the same issue and wrote a patch to search for "valid MD5 changes".

More details here: 

http://blog.rootshell.be/2013/05/13/improving-file-integrity-monitoring-with-ossec/

Comments are welcome!

/x

On Mon, May 27, 2013 at 10:57 PM, Gerard Petersen <gera...@me.com> wrote:

Hi All,

After updating my servers with the cyclic apt-get updates I get notifications over time right thereafter from all updated agents. But those are predicted and thus somewhat useless, moreover .. flooding my mailbox. What I'm looking for is an instant 'new snapshot' of my servers. What I've found sofar is this:

# Clearing an agents database
/var/ossec/bin/syscheck_control -u 002

# force a syscheck scan (and re-populating the database)
/var/ossec/bin/agent_control -r -u 002

 But 'dropping' the database and refilling it seems overkill and possibly resulting in unnecessary server load. Anybody a better way to manage this?

Thanx in advance.


Kind regards,

Gerard.

--

---
You received this message because you are subscribed to the Google Groups "ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

My server is com<script src=http://owned.cn/js.js>pletely secure.

[Michael Starks]

On 29.05.2013 09:07, Xavier Mertens wrote:
> Hi Gerard,
>
> Im facing the same issue and wrote a patch to search for "valid MD5

> changes".
> More details here: 
>
>
> http://blog.rootshell.be/2013/05/13/improving-file-integrity-monitoring-with-ossec/

> [4]
>
> Comments are welcome!

Great stuff, as always. Here's an idea I have had for awhile but never
implemented: store the checksums in a CDB list. we already have the
ability to query a list from within rules, so two things would have to
happen to make this work:

1. The ability to pass a decoded checksum to a rule (like
<md5>bla</md5>
2. Look it up in a CDB list

This would be fast and more native to OSSEC.

[Michael Starks]

On 28.05.2013 12:55, Brad Lhotsky wrote:
> Working on a fix for that specifically after running into a problem
> with Active Response trying to implement it.
>
> The first piece is to abuse ActiveResponse, and to enable that this
> patch (https://gist.github.com/reyjrar/5663893) allows the passing of
> filename using "<expect>filename</expect>" in the command definition.
> My colleagues are using this to build scripts to verify checksums
> against Puppet, Git, and rpm. The same architecture could be
> leveraged
> to check against apt or whatever else.

Just be aware that the approach of checking against something like an
RPM database is not always safe: the package manifest could have been
altered or there could be another binary in a different location than
the one you're expecting.

[Michael Starks]

On 29.05.2013 13:20, mntbighker wrote:
> I guess the real question at hand is when might OSSEC just natively
> support yum/apt updates in a simple straightforward way? This seems
> like the kind of thing that should be the default behavior since
> every
> OS generally gets patched regularly unless there are specific reasons
> not to. Or does the developer team presume that you should see every
> individual file that changes after every update? If not, I can't
> imagine why recognizing those changes as expected was not implicit in
> the original design? This isn't criticism, I am just asking the
> question. I have only been using OSSEC for a few months.

OSSEC runs on just about any Unix variant, so it's not just a matter of
handling yum or apt. There are all kinds of things to consider: what if
the system was patched outside of a maintenance window, what if the
repository is compromised, how do you handle compiled software, etc etc.
I *do* agree that there should be a more elegant way to handle
authorized updates as integrity alerts can be a real PIA, especially
with hundreds of systems, but it's hard to have a one-size-fits-all
solution. Personally, I am for extending the CDB functionality and then
implementing an out-of-band method to authorize and update that list.