[Snort-users] Ignoring Backups - TCP Stateful?

Doug Burks doug.burks at ...11827...
Fri Dec 5 19:29:11 EST 2014

Replies inline.

On Fri, Dec 5, 2014 at 6:15 PM, Colony.Three <Colony.Three at ...17037...> wrote:


> For example, I don't understand why PADS and PRADS are even in SO and run by
> default, when there's Snort.

PRADS creates session data and asset data.

Snort creates alert data.

Those are three different types of data.

> And why is SANCP there?
> Can Squil not do that
> itself, or is SANCP like a plugin to it?

sancp_agent and pads_agent take the session data and asset data
(respectively) from PRADS and send it to sguild to be stored in the
Sguil database.

> What to disable in what
> circumstances is a mystery.
> No idea of the structure of SO, and G**gle doesn't know either, much less
> ixquick.

Take a look at the Presentation link on our site:

Slide 5 contains an architectural diagram that may help.  You can also
find some other architectural diagrams here:

Also see:

I know you avoid Google, but there's a lot of architecture information
on our public mailing list, which you should be able to browse without
actually joining:

You may also be interested in Richard Bejtlich's book, "The Practice
of Network Security Monitoring":

>> On all my other systems I have a plasmoid in the taskbar which always
>> shows
>> the status of CPU, Mem, and Swap, but there doesn't seem to be such a
>> thing
>> for Xbuntu so I wasn't aware that it was thrashing.
> Xubuntu has a System Load Monitor that you can add to the panel.
> I see now, thank you.
>> I've rebooted but snort-1 still refuses to start. The log is exactly the
>> same as before. I did a soup update first thing this morning.
> Did you see my response to your Snort error?
> https://code.google.com/p/security-onion/wiki/FAQ#I_just_updated_Snort_and_it's_now_saying_'ERROR:_T...
> What is the output of the following?
> ls -alh /usr/local/lib/snort_dynamicrules/
> That is fixed now.  I didn't think to check the FAQ for this.

Glad that helped!

>> I can't believe Snorby can betray me like that. It is astounding that the
>> dev has never thought of this problem.
>> If you're not using the following services, you should disable them:
>> * prads (sessions/assets)[ FAIL ]
>> * sancp_agent (sguil)[ OK ]
>> * pads_agent (sguil)[ OK ]
>> * http_agent (sguil)[ OK ]
>> https://code.google.com/p/security-onion/wiki/DisablingProcesses
>> I'm too new to know the pros and cons of disabling each of these and their
>> interactions with the rest of the system is not documented. I've gathered
>> that PRADS is pretty important.
> PRADS is only necessary if you need session and asset data in Sguil.
> If you don't need that, then you can disable it.
> Seems like Snort would serve this purpose?

No, Snort watches traffic using Snort rules and creates alerts.  This
is separate from the session and asset data created by PRADS.

> And it seems like some kind of heartbeat would be vital to Snorby, to show
> that it is not just ignorantly sitting there like a stump.  Surely there is
> some way to indicate that it is actually functional?  How could the dev not
> see this?  Or do you Earthlings think differently?

Snorby is a web interface that queries the Snort alerts in a database.
The Snort alerts in the database don't contain any information about
the Snort processes that created those alerts.  You can look at the
Sensors tab under Last Event and see if it's been awhile since Snort
recorded an alert, but it's possible that your network is just not
seeing any traffic that matches any Snort rules.  If you'd like for
Snorby to monitor the actual Snort process, then you could always
develop the feature and submit it as a pull request:

If you haven't already, you might want to take a look at the Sguil
client as it will give you some visibility into the agent status.

>> The whole structure of SO is a mystery;
>> the best I've been able to gather is that Sguil uses netsniff-ng to record
>> full packet captures to disk, but whether that netsniff capture is the
>> only
>> packet capture that's done, and whether it is used by any/all the other
>> tools is unknown, and whether they do their own captures or just make
>> their
>> own independent logs from the main archive of packets according to their
>> divergent settings.
> The following processes are currently sniffing traffic on your eth0:
> Bro
> netsniff-ng
> snort
> prads
> They function independently of each other. PRADS can be disabled
> without affecting Bro and vice-versa. Likewise, if you don't need
> full packet capture, you can disable netsniff-ng without affecting the
> other services.
> I -do- want full packet capture.  Just not of backups.  And it should only
> be necessary to capture the packet stream -once-, for evaluation of whatever
> daemons are checking for various conditions.  This is what I originally
> thought SO was -- full packet capture once, for evaluation in different ways
> by different tools.  I don't understand why capture the same raw
> transport-stream several times for different purposes?

Let's make sure we're defining terms the same way.  I define full
packet capture as a daemon that sniffs network traffic and writes all
network traffic to disk in the form of pcap files.  Using that
definition, there is only one full packet capture facility in Security
Onion and that's netsniff-ng.  Other sniffing processes such as Snort,
Bro, and PRADS are all sniffing traffic but they are not writing out
full packet capture to disk like netsniff-ng is.  Snort, Bro, and
PRADS each provide their own types of data.


> You seem to be saying that tcpdump can engage the bpf.conf rule(s) somehow,
> but how can this be when you don't have bpf.conf even in the tcpdump
> command-line?  Is bpf.conf somehow at an even more fundamental level than
> tcpdump?  Is bpf.conf hooked by the kernel packet filter?  There's no man
> page for it.

Please see my previous example of using tcpdump to sniff traffic in
real time using your BPF:

sudo tcpdump -nnvvi eth0 'not(host and tcp port 8027)'

In this case, we're manually specifying the BPF on the command line in
single quotes so that we can test it and see if it works properly
before writing it to bpf.conf.

If you wanted to run tcpdump with your bpf.conf file, you could use
tcpdump's -F option.

Doug Burks
Need Security Onion Training or Commercial Support?
Last day to register for 3-Day Training Class in Augusta GA is 12/11!

More information about the Snort-users mailing list