[Snort-users] Ignoring Backups - TCP Stateful?
doug.burks at ...11827...
Fri Dec 5 17:31:02 EST 2014
On Fri, Dec 5, 2014 at 5:01 PM, Colony.Three <Colony.Three at ...17037...> wrote:
> From your sostat output:
> netsniff-ng and snort are failed, most likely due to a bad BPF. I
> didn't notice the "tcp host" in your BPF previously, loading it into
> tcpdump causes an error. Changing it to the following works:
> not(host 192.168.1.4 and tcp port 8027)
> Your sensor only has 2GB RAM and is using lots of swap:
> Mem: 2049604k total, 1891388k used, 158216k free, 6808k buffers
> Swap: 3119900k total, 1579156k used, 1540744k free, 108720k cached
> Please consider increasing your RAM:
> I've set bpf.conf like that now.
> It's a vbox VM on my main server. I've increased the RAM for it to 3GB, but
> the whole server has gotten by with 8GB, for my home theater, TOR gateway
> VM, Bittorrent server VM, Squid, CUPS, and so on, using no swap. 3GB is all
> the SO VM can have, and if that's not enough something needs to be pared
Disabling the services listed below will help some, but 3GB RAM may
still cause swapping if you're planning on running snort, netsniff-ng,
Bro, Snorby, and ELSA. Disable any unneeded services as shown here:
OR re-run Setup, choose Advanced Setup, Standalone, and then choose to
disable the processes there.
> 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'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?
What is the output of the following?
ls -alh /usr/local/lib/snort_dynamicrules/
> 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 ]
> 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.
> 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:
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
>>> Either my rules modifications were perfect, or nothing's
>>> being captured.
>>> I infer that ELSA would be the best way to see recent actual basic packet
>>> traffic, but Firefox will not let me in. "localhost:3154 uses an invalid
>>> security certificate"
>> Have you tried to configure Firefox to accept the self-signed certificate?
>> Of course. Firefox, when it comes upon a private cert, gives the option of
>> getting out, or going into Technical Details. I click the latter, and it
>> immediately gives the "localhost:3154 uses an invalid security
>> with nothing to click nor any path forward. I've never seen it do this.
>> Chromium is by G**gle and I can't use that.
> I'm not a Firefox user, but there must be a way to configure it to
> accept the self-signed cert.
>>> ... much less do I know how to determine whether my backups are excluded
>>> from packet capture. I can't do backups until I'm sure the packets are
>>> -not- being captured. It's been almost a week now since my last backups.
>> Have you tried my previous BPF suggestion? Would it help to simplify
>> the BPF by removing "src"? So something like this?
>> not(tcp host 192.168.1.4 and tcp port 8027)
>> You could test your BPF using tcpdump in real time while running a test
>> It's not clear to me whether tcpdump -causes- the traffic monitor, or
>> depends on some socket to listen for and print packets.
> You can use tcpdump to sniff traffic in real time as follows:
> sudo tcpdump -nnvvi eth0 'not(host 192.168.1.4 and tcp port 8027)'
> It sounds like tcpdump picks up traffic from the interface, independent of
> But netsniff is picking up that traffic too.
> What matters in
> this case is whether netsniff is in fact -ignoring- the backups traffic.
> I'm sure tcpdump would always see the backups traffic regardless, but I need
> to know if SO is ignoring the whole stateful TCP backups connexion as I'm
> trying to set, not just the initial transaction. I want it to ignore all
> the backups traffic on the LAN, regardless of src or dest ports which are
> likely to be different for every packet in the stateful connexion.
I'm suggesting that tcpdump can help you with this in the following ways:
First, you need a way to test the BPF syntax to ensure that the syntax
is correct and it won't prevent Snort/netsniff-ng from starting.
tcpdump can do that as shown below.
Once you have a syntactically valid BPF, you then need to test to see
if the BPF actually filters the way that you want it to. One way to
do this is with tcpdump watching traffic in real time. Start tcpdump
sniffing on your monitoring interface with the BPF and see if any
backup traffic appears. If so, then tweak the BPF and try again. Do
this iteratively until all backup traffic is filtered from tcpdump
properly. Then deploy the BPF to netsniff-ng and/or any other
services that should ignore the backup traffic.
If you don't want to use tcpdump for this step, then you could go
ahead and deploy the syntactically valid BPF to netsniff-ng and then
examine the pcap files that it writes out to see if there is any
evidence of backup traffic. The pcaps are stored in
> Maybe this is beyond me.
> You can also use tcpdump's -d option to verify/troubleshoot BPF:
> sudo tcpdump -d 'not(tcp host 192.168.1.4 and tcp port 8027)'
> tcpdump: 'tcp' modifier applied to host
> sudo tcpdump -d 'not(host 192.168.1.4 and tcp port 8027)'
> (000) ldh 
> (001) jeq #0x800 jt 2 jf 16
> (002) ld 
> (003) jeq #0xc0a80104 jt 6 jf 4
> (004) ld 
> (005) jeq #0xc0a80104 jt 6 jf 16
> (006) ldb 
> (007) jeq #0x6 jt 8 jf 16
> (008) ldh 
> (009) jset #0x1fff jt 16 jf 10
> (010) ldxb 4*(&0xf)
> (011) ldh [x + 14]
> (012) jeq #0x1f5b jt 15 jf 13
> (013) ldh [x + 16]
> (014) jeq #0x1f5b jt 15 jf 16
> (015) ret #0
> (016) ret #65535
> Doug Burks
> Need Security Onion Training or Commercial Support?
> Last day to register for 3-Day Training Class in Augusta GA is 12/11!
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