Yeah I did read up on samhain but I prefer the simplicity of OSSEC. For me, the main goal is to have integrity checking on a FreeBSD based firewall/router.
I'm thinking the best option is to use rkhunter and/or chkrootkit on the router, and then use a remote OSSEC in agentless mode to verify file integrity of the entire system - unless there is a simpler way to do this :) On Monday, April 11, 2016 at 5:26:28 PM UTC+1, Darin Perusich wrote: > > One mechanism would be to recreated what samhain, another OSSEC type > tool, does and add a compiled-in key that is used to verify the > integrity of the binary. In the case where it was being packaged by an > outside source, i.e. some distribution repo, you could add additional > key material to verify the integrity for a sites deployment. > > http://www.la-samhna.de/samhain/manual/keypad.html > -- > Later, > Darin > > > On Mon, Apr 11, 2016 at 10:47 AM, John Jenkins <[email protected] > <javascript:>> wrote: > > .. I forgot to mention that if anyone did go down this route of static > > linking it would have disadvantages as well such as not getting any > security > > updates in the libraries until the next time you re-compile. > > > > > > On Monday, April 11, 2016 at 3:15:36 PM UTC+1, John Jenkins wrote: > >> > >> Thanks for the info. > >> > >> I did think one way round this would be to verify the integrity of the > >> ossec binaries before the check is run. This could be done remotely by > >> comparing the hashes of some locally stashed known good binaries > against > >> what is on the agent machine. > >> > >> However, just checking some of the binaries on FreeBSD from the > >> osssec-client pkg and a lot of them are dynamically linked for some > reason. > >> > >> This would mean if you wanted to be absolutely sure you'd need to > compare > >> the hashes of all the linked libraries as well. It starts to become a > >> headache. > >> > >> On Monday, April 11, 2016 at 9:58:54 AM UTC+1, John Jenkins wrote: > >>> > >>> Apologies if this has been answered before but I couldn't find any > >>> information about this. I'm also new to OSSEC. > >>> > >>> How does an agent based install of OSSEC detect or prevent the > >>> modification of the agent itself? > >>> > >>> For example, what's to stop someone replacing the agent with their own > >>> custom binary to do god-knows what? > >>> > >>> Are there any best practices to prevent this? > >>> > >>> I'm aware that an agentless install can help mitigate this however the > >>> sshd binary would possibly be a weak point there. Also you lose some > >>> of the nicer features of the agent based install. > >>> > >>> Also am I right in thinking the file integrity database is also stored > >>> locally and open to modification in a local only install? > >>> > >>> John. > > > > -- > > > > --- > > 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 [email protected] <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > -- --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
