On Mon, Apr 11, 2016 at 2:57 PM, John Jenkins <[email protected]> wrote: > 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? >
Scale that out to 30,000 hosts of varying architectures, operating systems, and versions. At multiple locations with varying internet connection qualities. > 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 <[email protected]> >> 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 <[email protected]> >> >> 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]. >> >> > 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. > > -- > > --- > 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. -- --- 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.
