'[security-onion] Re: Suricata won't start on newly installed Security Onion'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       security-onion
Subject:    [security-onion] Re: Suricata won't start on newly installed Security Onion
From:       Yuval Khalifa <iyuvalk () gmail ! com>
Date:       2019-05-27 6:47:20
Message-ID: 97419aa8-f6f3-41d9-a61c-2553ff8e3e26 () googlegroups ! com
[Download RAW message or body]


On Sunday, May 26, 2019 at 6:17:12 PM UTC+3, Yuval Khalifa wrote:
> On Wednesday, May 22, 2019 at 4:25:07 PM UTC+3, Yuval Khalifa wrote:
> > On Tuesday, May 21, 2019 at 7:39:28 PM UTC+3, Yuval Khalifa wrote:
> > > Hi,
> > > 
> > > I'm trying to install a new Security Onion on a laptop here at the office for \
> > > testing purposes. I think that it won't have to handle lots of traffic so I \
> > > think that the hardware would be sufficient. 
> > > I'm using a Lenovo ThinkPad X1 Carbon with a NIC that is connected via USB (the \
> > > internal one needs an extension cable that I don't have) and right after the \
> > > installation and configuration I noticed few peculiar things: 1. When I run \
> > > sostat -H I always see that suricata has failed to start. When I looked at the \
> > > log file, I saw a line that reads "pf_ring open error" which to me it seemed \
> > > weird since that from what I read in the documentation, I understood that \
> > > Security Onion now uses AF-PACKET instead... 2. When I load Kibana I see no \
> > > data from snort/suricata/bro-* which is also weird since that in sostat -H it \
> > > seems that bro is running... 3. When I decided to test if everything was OK, I \
> > > started Wireshark and noticed that if I set a capture filter (for example \
> > > "icmp" or "tcp") it captures no packets at all but if I don't set a capture \
> > > filter at all and instead use a display filter like "icmp" or "tcp" or "http" \
> > > it works. If I try to capture packets using tcpdump -nnvvXX on the capturing \
> > > interface I see only (or perhaps almost only) UDP packets... what is happening \
> > > here? 
> > > I attached the following files to help you help me:
> > > 1. lsusb.log (the output of lsusb)
> > > 2. modprobe.log (the output of sudo modprobe pf_ring -v)
> > > 3. sostat-H.log (the output of sostat -H)
> > > 4. suricata.log (the logfile from /var/log/nsm/onion-<nic_name (starts with \
> > > enx)>/suricata.log) 
> > > 
> > > Any ideas what is happening?
> > > Thanks,
> > > Yuval.
> > 
> > 
> > Hi, 
> > 
> > I tried the configuration you recommended for suricata and it seems that it's \
> > still not working properly. 
> > I attached the following files:
> > 1. A fresh sostat -H
> > 2. /etc/nsm/onion-enx00e04c680a22/sensor.conf
> > 3. /opt/bro/etc/node.cfg
> > 4. /etc/nsm/securityonion.conf
> > 
> > 
> > Tnx,
> > Yuval
> 
> Hi everyone...
> 
> A quick update, since that I couldn't find a way to resolve this, I decided to take \
> a different approach to this problem and format the entire system and install a new \
> Ubuntu Gnome 16.04 on the machine and then install VirtualBox and run SecurityOnion \
> within a VirtualBox VM and I think that it did solve some of the problems I had but \
> not all of them... 
> Here's an updated status:
> 1. Snort now starts automatically without any problem (or at least so it seems) 
> 2. I still see no data from snort/bro-* in Kibana even though that now everything \
> seems to be running smoothly in sostat-H (at least to me...) 3. The same happens \
> again - When I use Wireshark to capture traffic I'm able to filter it ONLY by using \
> display filters, every BPF filter (even the simple ones like "tcp") that I use \
> results in no packets at all. 
> I have attached to this message the following files:
> 1. A sostat-H ouptut
> 2. The securityonion.conf file
> 3. The sensor config file (for both interfaces)
> 4. Bro's node.cfg file
> 5. A sample of packets collected using tcpdump -w

Hi,

Just to show a quick example of my capturing issue, this is what happens when I try \
to run tshark and capture on the sniffing interface, once with a capture filter (-f) \
and then with the same filter as a display filter. As you can see, when I use the \
capture filter no packets are being captured and with the display filter it does \
capture packets. I think that perhaps that can explain why I don't see anything \
coming from bro-ids and snort on my Kibana:

[so@so ~] 2019-05-27 06:35:23$ 
[so@so ~] 2019-05-27 06:35:24$ 
[so@so ~] 2019-05-27 06:35:24$ 
[so@so ~] 2019-05-27 06:35:24$ tshark -i enp0s8 -f "tcp"
Capturing on 'enp0s8'
^C0 packets captured
[so@so ~] 2019-05-27 06:36:18$ tshark -i enp0s8 -Y "tcp"
Capturing on 'enp0s8'
    1 0.000000000 192.168.33.4 → 193.16.147.22 TLSv1.2 809 Application Data
    2 0.003967095 192.168.33.4 → 193.16.147.22 TLSv1.2 809 Application Data
    3 0.009832961  52.95.20.79 → 192.168.33.1 TCP 120 443 → 64033 [ACK] Seq=1 \
Ack=1 Win=32721 Len=0  4 0.015014023  52.95.20.79 → 192.168.33.1 TLSv1.2 493 \
Application Data  5 0.015024734  52.95.20.79 → 192.168.33.1 TLSv1.2 205 Application \
Data  6 0.016712775 192.168.33.1 → 52.95.20.79  TCP 128 64033 → 443 [ACK] Seq=1 \
Ack=374 Win=4090 Len=0  7 0.016722534 192.168.33.1 → 52.95.20.79  TCP 128 64033 → \
443 [ACK] Seq=1 Ack=459 Win=4088 Len=0  8 0.017341680 193.16.147.22 → 192.168.33.4 \
TCP 132 443 → 54236 [ACK] Seq=1 Ack=670 Win=170 Len=0 TSval=721463110 \
TSecr=558943885  9 0.019991836 193.16.147.22 → 192.168.33.4 TLSv1.2 481 Application \
Data  10 0.021620455 192.168.33.4 → 193.16.147.22 TCP 140 54236 → 443 [ACK] \
Seq=1339 Ack=350 Win=30245 Len=0 TSval=558943907 TSecr=721463110  11 0.022147733 \
192.168.33.4 → 193.16.147.22 TLSv1.2 229 Application Data  12 0.024383856 \
193.16.147.22 → 192.168.33.4 TLSv1.2 481 Application Data  13 0.026094896 \
192.168.33.4 → 193.16.147.22 TLSv1.2 229 Application Data  14 0.045805456 \
193.16.147.22 → 192.168.33.4 TCP 132 443 → 54236 [ACK] Seq=699 Ack=1517 Win=170 \
Len=0 TSval=721463112 TSecr=558943908  15 0.061713052 192.168.33.4 → 193.16.147.22 \
TLSv1.2 817 Application Data  20 0.086869468 193.16.147.22 → 192.168.33.4 TLSv1.2 \
481 Application Data  21 0.133253226 192.168.33.4 → 193.16.147.22 TCP 140 54236 → \
443 [ACK] Seq=2194 Ack=1048 Win=30245 Len=0 TSval=558944018 TSecr=721463116  22 \
0.133633720 192.168.33.4 → 193.16.147.22 TLSv1.2 229 Application Data  23 \
0.192775599 193.16.147.22 → 192.168.33.4 TCP 132 443 → 54236 [ACK] Seq=1048 \
Ack=2283 Win=170 Len=0 TSval=721463127 TSecr=558944019 ^C   24 0.664661531 \
192.168.33.7 → 192.168.33.254 TCP 148 60302 → 8013 [SYN] Seq=0 Win=65535 Len=0 \
MSS=1394 SACK_PERM=1 TSval=10349375 TSecr=0 WS=256 20 packets captured
[so@so ~] 2019-05-27 06:36:36$ 


Any thoughts/ideas?

-- 
Follow Security Onion on Twitter!
https://twitter.com/securityonion
--- 
You received this message because you are subscribed to the Google Groups \
"security-onion" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to security-onion+unsubscribe@googlegroups.com. To post to this \
group, send email to security-onion@googlegroups.com. Visit this group at \
https://groups.google.com/group/security-onion. To view this discussion on the web \
visit https://groups.google.com/d/msgid/security-onion/97419aa8-f6f3-41d9-a61c-2553ff8e3e26%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.



[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic