Regarding sensor-sensor communcation, I recommend using OpenVPN for all communication since it's free, cross-platform, provides built-in compression, has easy configuration, it's PKI infrastructure based, and makes debugging much easier since you can sniff your tun0 socket.  It also makes your host firewall rules much more simple.<br>
<br>--Martin<br><br><div class="gmail_quote">On Tue, Jan 6, 2009 at 6:56 PM, Matt Jonkman <span dir="ltr"><<a href="mailto:jonkman@jonkmans.com">jonkman@jonkmans.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">John Pritchard wrote:<br>
> I'd like to suggest that we take very large deployments into<br>
> consideration when designing our solution. The kind of problems you<br>
> encounter when managing an infrastructure with a handful or even a<br>
> dozen different IDS sensors is very different than trying to<br>
> efficiently and consistently manage infrastructures with larger<br>
> footprints (e.g. > 100+ sensors).<br>
<br>
</div>Agreed, absolutely. I'm really envisioning a framework where we do away<br>
with the idea of individual sensors. Get rid of the idea of a bunch of<br>
independent points and more toward a meshed look. Where all sensors are<br>
aware of each other and the data in each, maybe even the state of each.<br>
How to do that I dunno. Maybe using the database as a communication medium?<br>
<div class="Ih2E3d"><br>
><br>
> A couple of suggestions to help our design address these potential<br>
> deployment and management scenarios:<br>
><br>
> 1) Centralized sensor and policy management platform (or framework)<br>
> --> Such a solution may be restricted to a single centralized server<br>
> or multiple servers.<br>
> --> Might be a parent -> child relationship among configuration<br>
> servers to segregate business units, or simply replication among<br>
> servers for disaster recovery / business continuity purposes<br>
<br>
</div>Ya, that's what I was going for above. I like the parent<br>
child/department idea. Have a central db of course, and maybe<br>
sub-sensors and sub parents. Then state and information can be shared<br>
more readily among related senors, like by location, or by perimeter vs<br>
internal, user nets vs servers, etc.<br>
<div class="Ih2E3d"><br>
<br>
> --> efficient, repeatable, and audit-able methodology for making<br>
> changes to both individual sensors as well as pre-defined groups of<br>
> sensors (e.g. dmz sensors, dns sensors, development lab sensors,<br>
> etc...)<br>
<br>
</div>I want a db based config for all sensors. The whole config file approach<br>
to it is a pain. It might be easier to run a db loaded config and<br>
provide a basic web page or config tool to load these into the db. Then<br>
it'd be pretty easy to maintain change tracking and give permissions for<br>
changes, etc.<br>
<div class="Ih2E3d"><br>
> --> My experience to date has been performing these kind of tasks with<br>
> home-grown scripts, ssh, scp, audit logs, etc... However, it would be<br>
> nice to find something a little more mature for this project.<br>
><br>
> I have not used it, but there is a project called "Puppet" that looks<br>
> like it might be a good candidate for trying to develop a framework<br>
> along these lines:<br>
> <a href="http://reductivelabs.com/trac/puppet/wiki/PuppetIntroduction" target="_blank">http://reductivelabs.com/trac/puppet/wiki/PuppetIntroduction</a><br>
><br>
<br>
</div>Very interesting, anyone have experience with it?<br>
<div class="Ih2E3d"><br>
><br>
> 2) Centralized sensor and policy monitoring platform (or framework)<br>
> --> This is similar to the "management framework" concept, but the<br>
> focus is more on device health monitoring... and possibly policy<br>
> integrity monitoring...<br>
> --> For this piece, I'm thinking of something that provides functions<br>
> such as looking at memory utilization, cpu utilization, hard-drive<br>
> space, network interface stats... and other "bits" such as dates and<br>
> checksums for critical configuration files changed (e.g. detection<br>
> policies, tuning policies, variable definitions, etc)...<br>
><br>
<br>
</div>Absolutely, great idea! I think that could even be db based as well.<br>
insert stats every x seconds. Makes the sensors more disposable as well<br>
as all data is in the db. Just plug in a new box and tell it where to<br>
get/store it's stuff via db.<br>
<div class="Ih2E3d"><br>
<br>
><br>
> 3) Distributed Data Repositories<br>
> I know we briefly touched on the database stuff when talking about<br>
> schema design. I just wanted to add a plug for a couple of things<br>
> here:<br>
> --> encrypted communication channels (sensor -> DB or sensor -> sensor)<br>
> --> ability to simultaneously log to 2 or more data repositories<br>
<br>
</div>Definitely on both. We know we'll need to support postgress, mysql and<br>
oracle. Anything else?<br>
<br>
I believe all three have an ssl or otherwise based encryption option.<br>
Should be look to make our own vpn or rely on these?<br>
<font color="#888888"><br>
Matt<br>
</font><div class="Ih2E3d"><br>
><br>
> I strongly agree with the concept of designing modular solutions. So,<br>
> these kind of features can be "bolted on" if they were required.<br>
><br>
> Look forward to everyone's thoughts on how we can most effectively<br>
> tackle problems of scale for large deployments.<br>
><br>
> Cheers, John<br>
> _______________________________________________<br>
> Discussion mailing list<br>
> <a href="mailto:Discussion@openinfosecfoundation.org">Discussion@openinfosecfoundation.org</a><br>
> <a href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a><br>
<br>
</div>--<br>
<div class="Ih2E3d">--------------------------------------------<br>
Matthew Jonkman<br>
Emerging Threats<br>
Phone 765-429-0398<br>
Fax 312-264-0205<br>
<a href="http://www.emergingthreats.net" target="_blank">http://www.emergingthreats.net</a><br>
--------------------------------------------<br>
<br>
PGP: <a href="http://www.jonkmans.com/mattjonkman.asc" target="_blank">http://www.jonkmans.com/mattjonkman.asc</a><br>
<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="Wj3C7c">Discussion mailing list<br>
<a href="mailto:Discussion@openinfosecfoundation.org">Discussion@openinfosecfoundation.org</a><br>
<a href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a><br>
</div></div></blockquote></div><br>