Snort mailing list archives

Re: Ignoring Backups - TCP Stateful?


From: Doug Burks <doug.burks () gmail com>
Date: Fri, 5 Dec 2014 19:29:11 -0500

Replies inline.

On Fri, Dec 5, 2014 at 6:15 PM, Colony.Three <Colony.Three () protonmail ch> wrote:

<snip>

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:
https://docs.google.com/uc?export=download&id=0BzQ65xrcMwNEVnhYZ0pOeXB4ejA

Slide 5 contains an architectural diagram that may help.  You can also
find some other architectural diagrams here:
http://nsmwiki.org/Sguil

Also see:
http://taosecurity.blogspot.com/2009/10/nsm-in-products.html

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:
http://groups.google.com/group/security-onion

You may also be interested in Richard Bejtlich's book, "The Practice
of Network Security Monitoring":
http://www.nostarch.com/nsm


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:
https://github.com/snorby/snorby

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.


<snip>

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 192.168.1.4 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?
http://securityonionsolutions.com
Last day to register for 3-Day Training Class in Augusta GA is 12/11!

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!


Current thread: