Standalone Security Onion not getting network traffic

809 views
Skip to first unread message

Jake Mauney

unread,
Mar 17, 2016, 7:01:27 PM3/17/16
to security-onion
Hey there
I followed the instructions found on the wiki and tried to google as much as I could, however I'm running into a huge problem. It seems that for some reason squert is not loading alerts. I went and I did a tcpdump for my interface and it turns out the only traffic it is getting is the traffic intended for Security Onion. It's a VM on an ESXI server. I have all virtual switches set to promiscuous and I have the netflow setup on the switch to send the traffic to Secutity Onion. All services are up according to "service nsm status" and ufw says that all default firewall rules are up. Am I missing anything? Can provide additional information if necessary.

Wes Lambert

unread,
Mar 17, 2016, 7:04:16 PM3/17/16
to securit...@googlegroups.com

Are you using Chrome or a Chromium-based browser to access Squert?  Have you tried looking in Sguil?

Please provide the output of "sudo sostat-redacted" and attach it as a text file.

Thanks,
Wes

On Mar 17, 2016 7:01 PM, "Jake Mauney" <jmau...@gmail.com> wrote:
Hey there
I followed the instructions found on the wiki and tried to google as much as I could, however I'm running into a huge problem. It seems that for some reason squert is not loading alerts. I went and I did a tcpdump for my interface and it turns out the only traffic it is getting is the traffic intended for Security Onion. It's a VM on an ESXI server. I have all virtual switches set to promiscuous and I have the netflow setup on the switch to send the traffic to Secutity Onion. All services are up according to "service nsm status" and ufw says that all default firewall rules are up. Am I missing anything? Can provide additional information if necessary.

--
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-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.
Message has been deleted

Shane Castle

unread,
Mar 18, 2016, 7:34:35 AM3/18/16
to securit...@googlegroups.com
This seems to be a common beginner's problem when running in a VM. The sniffing
virtual interface for the SO VM must be bridged to the physical host interface
receiving the traffic. Also see comment below.

On 17.03.2016 23:46, Jake Mauney wrote:
> I have all virtual
> switches set to promiscuous and I have the netflow setup on the switch to
> send the traffic to Secutity Onion.

How, exactly? Which type of switch? Do you mean "virtual NIC" instead of
"virtual switch"? Are you using a physical switch setup routing the traffic? And
has already been mentioned, you should give us the output of "sudo sostat-redacted".

Running a production SO can be done in a VM but owing to the physical and
virtual configurations it can be difficult to migrate the SO VM across an ESXI
host farm, or to have the hosts it is sniffing traffic for to migrate.

--
Mit besten Grüßen
Shane Castle

Marco

unread,
Mar 18, 2016, 9:45:04 AM3/18/16
to security-onion
On Friday, March 18, 2016 at 12:01:27 AM UTC+1, Jake Mauney wrote:
> Hey there
> I followed the instructions found on the wiki and tried to google as much as I could, however I'm running into a huge problem. It seems that for some reason squert is not loading alerts. I went and I did a tcpdump for my interface and it turns out the only traffic it is getting is the traffic intended for Security Onion. It's a VM on an ESXI server. I have all virtual switches set to promiscuous and I have the netflow setup on the switch to send the traffic to Secutity Onion. All services are up according to "service nsm status" and ufw says that all default firewall rules are up. Am I missing anything? Can provide additional information if necessary.

The only other thing I could think of is the NIC not being in promiscuous mode.

Reply all
Reply to author
Forward
0 new messages