Distributed Snort

[Frank Knobbe <fknobbe () knobbeits com>]

While planning a large Snort roll-out with centralized logging, I'm
starting to see some problem withs having the sensors log directly to a
database. My main gripe is performance and reliability. Barnyard can
help in the performance area, but one seems to be limited to to MySQL on
the back end. Also, the database plugins doesn't seem to check for and
handle error conditions very well. What does a sensor do when the link
to the database is temporarily down?

I'm considering writing an output and input plugin for Snort that could
alleviate these problems. I'm posting here a) for a sanity check, and b)
if there is an interest in this setup (in which case I will program so
that the code can be easily shared and integrated in other setups).

My plans is this: A custom output plugin in Snort (decoupled in a
thread, or a socket), and also in Barnyard, will send event and packet
data via TCP to a remote Snort sensor (instead of a database). The
decoupled output plugin would realize a lost connection and reconnect
after a short waiting period. At the same time, Snort is still running,
catching alerts, and queueing alert and logging data to this plugin.
[This Snort box sniffs packets from the network, runs it through the
preprocessors and detection engine, and then queues and transmits the
alert and log output].

On the receiving end I envision a normal Snort installation, except that
it is started with a new command line parameter which will cause Snort
not to read packets from the network as it usually does, but instead
accept the TCP connection from the remote Snort sensor. It will then use
the received information to call its output plugins as usual. [This
Snort box reads the event and otn data from the TCP session, and only
calls the log and alert plugins, bypassing preprocessors and detection
engine].

With this setup it should be possible to have several sensors do the
detection, pass the data to a central Snort instance which will make use
of the already existing plugins, including Postgres, tcpdump, ascii,
etc.

In addition, the receiving Snort box can in turn forward the data to yet
another Snort instance, mainly for redundancy. The remote sensor can
connect to the receiving pair in a round robin fashion, the the
receiving box can log to it's database, forward it to its Snort mirror
which will log it into another database. Or forward to a final tcpdump
archival sensor.


Unless you can convince me that this is a bad idea, I will start coding.
If there is an interest in such a distributed Snort setup, please let me
know and I plan accordingly, although the addins shouldn't be very
invasive.


Regards,
Frank

Attachment: signature.asc
Description: This is a digitally signed message part