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:
- Re: Ignoring Backups - TCP Stateful?, (continued)
- Re: Ignoring Backups - TCP Stateful? Colony.Three (Dec 04)
- Re: Ignoring Backups - TCP Stateful? Colony.Three (Dec 05)
- Re: Ignoring Backups - TCP Stateful? Doug Burks (Dec 05)
- Re: Ignoring Backups - TCP Stateful? Colony.Three (Dec 05)
- Re: Ignoring Backups - TCP Stateful? Doug Burks (Dec 05)
- Re: Ignoring Backups - TCP Stateful? Colony.Three (Dec 05)
- Re: Ignoring Backups - TCP Stateful? Doug Burks (Dec 05)
- Re: Ignoring Backups - TCP Stateful? Colony.Three (Dec 05)
- Re: Ignoring Backups - TCP Stateful? Doug Burks (Dec 05)
- Re: Ignoring Backups - TCP Stateful? Colony.Three (Dec 05)
- Re: Ignoring Backups - TCP Stateful? Doug Burks (Dec 05)