Good point Dan. So here's a thought that maybe getting into the realms of silliness - how about mounting (read-only) the entire filesystem of the "untrusted" machine (via SSHFS) onto a a "trusted" machine, and run OSSEC locally on the trusted machine?
On Monday, April 11, 2016 at 6:23:09 PM UTC+1, dan (ddpbsd) wrote: > > On Mon, Apr 11, 2016 at 1:07 PM, John Jenkins <jenkins...@gmail.com > <javascript:>> wrote: > > 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 :) > > > > The agentless support will probably have the same problems, because I > believe it uses the system's hashing programs. > > > 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 <jenkins...@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+...@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+...@googlegroups.com <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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
