jpvlsmv/moloch

This is a small fork that focuses on building Moloch packages automatically

moloch's Issues

TLS-howto

FAQ entry for how to TLS-ize moloch and ES comms, plus possible configscript additions

Would LMAX-Exchange disruptor help?

https://github.com/LMAX-Exchange/disruptor

Java high-speed inter-thread queuing lib.

How much replumbing would it take to tpacketv3 -> queue -> processing/extraction -> queue -> writer if the queues are in Java/JNI?

Otherwise, consider concept of ringbuffers of pointers passing along the pipeline.

db.pl autoconfig

db.pl [global options] <eshost:esport|-a|-c configfile> .... ? if -a or -c specified, requires (and asks nicely for) config::simple as libconfig-simple-perl (debian) or perl-Config-Simple (rpm), available in default repos since 2010

cf: feature/dbpl-guess-url

Elasticsearch node on localhost

Take the centralized ES cluster, and do the ingest (parse+scatter, not ingest-node pipelines) on the capture nodes. They'd need to talk back to central, but over ES TransportClient instead of REST client.

+Option2: allow index data to be "cached" for a short time locally, but replicate to central also.

Next, expose viewer.js (stripped down) via https://github.com/apigee/trireme as an elasticsearch plugin, now the centralized viewer.js pulls packet data from the cluster nodes on 9200/REST -> JVM -> node.js -> pcap and we don't have a separate process.

moloch-capture points to non-exposed localhost:9200, ES autodiscovers the rest of the cluster and the data-scatter mappings.

-=> 1 container per interface for single-proc moloch-capture
-=> 1 container per sensor for single-proc ES run
Does not solve for suricata...