[Snort-devel] Re: [Snort-users] Distributed Snort
paul at ...1481...
Thu Nov 14 08:59:05 EST 2002
I had email to the list in July about a new output plugin that I was
planning to write. I've actually just finished the first pass about two
weeks or so ago. It works fine for my needs and it's been tested in my
environment (ie Linux on x86 only).
The plugin does what you described. The data format is based on the
existing unified snort format. It does use SSL as the transport so
OpenSSL is required.
Are you interested in collaborating on this? The one thing that I did
not write is a client for the output-plugin. We use a proprietary
database interface and schema so I don't have client that I can release.
I keep meaning to submit diffs but I was waiting for the 1.9.1 of snort
to be released first. I will provide diffs to the list in in a few days
against 1.9.0 if that's okay. One problem is that I also made changes to
snort to reduce it's disk footprint. I submitted some diffs for those
changes a while back. If you don't mind those other changes, then I
would like to submit a single diff.
Frank Knobbe wrote:
> 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
> 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,
> 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
More information about the Snort-devel