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.
