If you're primary concern is ensuring the integrity of a firewall, or any system for that matter, perhaps the more simple approach of limiting local access to the system and further limiting who elevated privileges to install/patch/update the system, in addition to file level integrity checking, would be a place to start to ensure a strong security posture.
In addition to OSSEC, you can also use AIDE to check file integrity, and you can layer FreeBSDs TrustedBSD MAC framework on top of that. While auditd(8) is the Linux Audit Daemon, I'm sure there's an equivalent in FreeBSD, which you can use to audit any file access, and bring the system to a grinding halt w/the amount of logs generated, and alert locally with SEC, and ship those logs off to splunk/greylog2/syslog to ensure they're not fiddled with in the event of local compromise. Since this is a FreeBSD I'd also run ZFS for the file systems and use a snapper(8) like tool to create a file system snapshot for roleback purposes after updates. I'm not trying to be an ass, I'm simply pointing out that one needs to have a layered and methodical approach to securing ones systems and there is no silver bullet. At some point you need to trust whoever is managing said systems, the vendors you're getting your software from, which is easier when they're based on open source code and you can review the sources code. -- Later, Darin On Tue, Apr 12, 2016 at 7:33 AM, dan (ddp) <[email protected]> wrote: > 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. -- --- 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.
