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 <jenkinsjohn...@gmail.com> 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 ossec-list+unsubscr...@googlegroups.com. > 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
