Security Onion not detecting traffic

4,099 views
Skip to first unread message

Robert Moss

unread,
Apr 11, 2018, 8:15:12 AM4/11/18
to security-onion
Hi all just discovered this google group so thought someone could help me with a problem I'm having.

I am using GNS3 with VMWare machines to simulate a small network to test Security Onion IDS. Below is a link to a picture of my setup.

https://imgur.com/a/QhRHK

As you can see I have the Security Onion machine connected within the internal network to a hub. The reason I have a hub and not a switch is so that all traffic is forwarded to every device connected to it so security onion can see the traffic sent from the attacking kali linux machine, to the windows machines. I know in real life a switch would be used with port forwarding but this cannot be done within GNS3 as far as I know.

I have configured 2 interfaces on security onion, one for management and the other for sniffing, these are eth0 and eth1 respectively. The problem I am having is that when viewing the traffic within Sguil after pinging from every machine to every other machine the only traffic that shows in sguil is the traffic sent to and from the security onion machine. When running wireshark and using tcpdump on the machine to view the traffic I can verify that both the interfaces on securty onion can indeed see all traffic sent to any machine within the network, however sguil is not detecting it. Below is a picture of the sguil window after performing pings and attacks using kali linux on the windows server machine.

https://imgur.com/a/UMrhV

Sorry for the walls of text I was just wondering if anyone has had this problem before or if I am doing something wrong in either my topology layout or configurations. Thanks for any replies!

Wes Lambert

unread,
Apr 11, 2018, 9:24:42 AM4/11/18
to securit...@googlegroups.com
Hi Robert,

Please provide the output of sostat-redacted, attaching as a plain text file, or using a service like Pastebin.com.

Thanks,
Wes

Robert Moss

unread,
Apr 12, 2018, 10:30:27 AM4/12/18
to security-onion
Hi Wes

Thanks for your reply again and sorry for my late one.

Have re-installed SO VM into my network and performed setup, configuration, and the same tests as I detailed in my original post and I get the same results, wireshark can see the traffic but when I perform any kind of attack it doesn't register the traffic or even an alert. Below is a link to a paste bin from the output of the command you specified -

https://pastebin.com/mXAa5Bwb

The only thing I can think of that would be hampering this project is that I am using a hub and not a switch, but again I do not know how to perform port forwarding in GNS3. Any help is appreciated!

Wes Lambert

unread,
Apr 12, 2018, 11:46:19 AM4/12/18
to securit...@googlegroups.com
Robert,

You'll first want to make sure you are running with the minimum hardware recommendations for the Elastic Stack:


Thanks,
Wes


--
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.
For more options, visit https://groups.google.com/d/optout.



--

alab...@nextgi.com

unread,
Apr 12, 2018, 12:28:15 PM4/12/18
to security-onion

I may be off point here, because I am not familiar with GNS3, but I believe you need to set up port-mirroring or a span port on the switch you have the SO machine connected to. There are a few articles on the web, and some videos on YouTube that demonstrate setting up port-mirroring in GNS3.

In my physical environment, I have both a physical network tap (for my public IP's on my Cloud stack) and a port-mirror on my internal network switch, which allows me to monitor my internal network.

Robert Moss

unread,
Apr 12, 2018, 1:08:01 PM4/12/18
to security-onion
Hi thanks for both of your replies. I have tried configuring the SO VM with the recommended and updated hardware requirements and the IDS is still not detecting the traffic. I have again confirmed through wireshark that the sniffing interface can indeed see this traffic so I just do not understand why the IDS isn't seeing it. This leads me to the second answer from Alabarge, I do not have a switch configured in my topology it is a generic hub, so in a real network I would need a switch with either a tap or port forwarding/mirroring, as you said, to get the traffic to the IDS however since I am using a hub the traffic is being sent to the IDS without further configuration, again this is verified by wireshark ran on the sniffing interface on the SO VM, thanks for both of your replies.

Wes Lambert

unread,
Apr 12, 2018, 3:44:47 PM4/12/18
to securit...@googlegroups.com
Robert,

Have you tried switching to Suricata to see if you get different results?


Have you tried taking a look at Bro logs, etc to see if they are getting written to disk, etc.

Thanks,
Wes

On Thu, Apr 12, 2018 at 1:08 PM, Robert Moss <robert.j...@gmail.com> wrote:
Hi thanks for both of your replies. I have tried configuring the SO VM with the recommended and updated hardware requirements and the IDS is still not detecting the traffic. I have again confirmed through wireshark that the sniffing interface can indeed see this traffic so I just do not understand why the IDS isn't seeing it. This leads me to the second answer from Alabarge, I do not have a switch configured in my topology it is a generic hub, so in a real network I would need a switch with either a tap or port forwarding/mirroring, as you said, to get the traffic to the IDS however since I am using a hub the traffic is being sent to the IDS without further configuration, again this is verified by wireshark ran on the sniffing interface on the SO VM, thanks for both of your replies.
--
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.
For more options, visit https://groups.google.com/d/optout.

Robert Moss

unread,
Apr 12, 2018, 4:08:11 PM4/12/18
to securit...@googlegroups.com
Hi Wes,

After switching from snort to suricata it does register pings from 2 separate machines, in my topology from the kali machine to the windows server machine, in the sguil window, but it still does not show logs of the attack I am performing. However when viewing the bro logs the attack is showing in the nsm/current/weird.log directory, this is verified by timestamps and the IP addresses shown in the logs match the ones in wireshark capture during the process. Thanks for helping me with this, now that you have shown me that bro is detecting the attack and registering it as 'weird' activity, can you help me understand and solve why it isn't showing in the sguil program? Thanks again for all your help and answers.

On 12 April 2018 at 20:44, Wes Lambert <wlamb...@gmail.com> wrote:
Robert,

Have you tried switching to Suricata to see if you get different results?


Have you tried taking a look at Bro logs, etc to see if they are getting written to disk, etc.

Thanks,
Wes
On Thu, Apr 12, 2018 at 1:08 PM, Robert Moss <robert.j...@gmail.com> wrote:
Hi thanks for both of your replies. I have tried configuring the SO VM with the recommended and updated hardware requirements and the IDS is still not detecting the traffic. I have again confirmed through wireshark that the sniffing interface can indeed see this traffic so I just do not understand why the IDS isn't seeing it. This leads me to the second answer from Alabarge, I do not have a switch configured in my topology it is a generic hub, so in a real network I would need a switch with either a tap or port forwarding/mirroring, as you said, to get the traffic to the IDS however since I am using a hub the traffic is being sent to the IDS without further configuration, again this is verified by wireshark ran on the sniffing interface on the SO VM, thanks for both of your replies.

--
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 securit...@googlegroups.com.

Wes Lambert

unread,
Apr 12, 2018, 5:15:25 PM4/12/18
to securit...@googlegroups.com
Robert,

Are there any specific rules/signatures that you should be triggering?  You can view all of the enabled rules in /etc/nsm/rules/downloaded.rules.  However, please do not enable rules here, as they will get overwritten when rule-update is run.

Thanks,
Wes


Robert Moss

unread,
Apr 13, 2018, 7:31:44 AM4/13/18
to security-onion
On Thursday, April 12, 2018 at 10:15:25 PM UTC+1, Wes wrote:
> Robert,
>
> Are there any specific rules/signatures that you should be triggering?  You can view all of the enabled rules in /etc/nsm/rules/downloaded.rules.  However, please do not enable rules here, as they will get overwritten when rule-update is run.
>
>
> Thanks,
> Wes
>
>
>
>
>
>
>
> On Thu, Apr 12, 2018 at 4:08 PM, Robert Moss <robert.j...@gmail.com> wrote:
>
> Hi Wes,
>
>
> After switching from snort to suricata it does register pings from 2 separate machines, in my topology from the kali machine to the windows server machine, in the sguil window, but it still does not show logs of the attack I am performing. However when viewing the bro logs the attack is showing in the nsm/current/weird.log directory, this is verified by timestamps and the IP addresses shown in the logs match the ones in wireshark capture during the process. Thanks for helping me with this, now that you have shown me that bro is detecting the attack and registering it as 'weird' activity, can you help me understand and solve why it isn't showing in the sguil program? Thanks again for all your help and answers.
>
>
>
>
> On 12 April 2018 at 20:44, Wes Lambert <wlamb...@gmail.com> wrote:
>
> Robert,
>
>
> Have you tried switching to Suricata to see if you get different results?
>
>
> https://github.com/Security-Onion-Solutions/security-onion/wiki/FAQ#im-currently-running-snort--how-do-i-switch-to-suricata
>
>
>
> Have you tried taking a look at Bro logs, etc to see if they are getting written to disk, etc.
>
>
> Thanks,
> Wes
>
>
>
>
> On Thu, Apr 12, 2018 at 1:08 PM, Robert Moss <robert.j...@gmail.com> wrote:
> Hi thanks for both of your replies. I have tried configuring the SO VM with the recommended and updated hardware requirements and the IDS is still not detecting the traffic. I have again confirmed through wireshark that the sniffing interface can indeed see this traffic so I just do not understand why the IDS isn't seeing it. This leads me to the second answer from Alabarge, I do not have a switch configured in my topology it is a generic hub, so in a real network I would need a switch with either a tap or port forwarding/mirroring, as you said, to get the traffic to the IDS however since I am using a hub the traffic is being sent to the IDS without further configuration, again this is verified by wireshark ran on the sniffing interface on the SO VM, thanks for both of your replies.
>
>
>
>
>
> --
>
> 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.
>
>
>
>
>
> --
>
>
> https://twitter.com/therealwlambert
>
> https://securityonion.net/
>
>
>
>
>
>
>
>
> --
>
> 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.
>
>
>
>
>
>
>
> --
>
> 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.
>
>
>
>
>
> --
>
>
> https://twitter.com/therealwlambert
>
> https://securityonion.net/

Hi Wes,

After looking in the specified downloaded rules files I cannot locate which alert I should be triggering. I am performing a simple DoS attack using msfconsole within kali linux using the following exploit -

use auxiliary/dos/tcp/synflood

However as I understand it bro logs can be viewed in Kibana however they are not showing up for me even though bro has logged the attack as 'weird.log'.

Wes Lambert

unread,
Apr 13, 2018, 8:02:16 AM4/13/18
to securit...@googlegroups.com
Hi Robert,

If you do not have any rules that would detect the above mentioned activity, then you will not receive any alerts.  In regard to the Bro logs, have you ensured Logstash is running and there are no errors in the log?

sudo docker ps
sudo tail -f /var/log/logstash/logstash.log

Thanks,
Wes

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.

Robert Moss

unread,
Apr 13, 2018, 8:20:14 AM4/13/18
to security-onion
Hi Wes thanks for your prompt replies.

This is a link to a pastebin containing the output from the second command you have listed there.

https://pastebin.com/nSmhi94A

If I have the latest rules downloaded how would I add a rule for the attack I specified, I would have thought a simple DoS attack would already have a rule for it enabled, sorry for my ignorance in regards to how SO works.

Wes Lambert

unread,
Apr 13, 2018, 12:00:52 PM4/13/18
to securit...@googlegroups.com
You could try testing a rule like the one described here in /etc/nsm/rules/local.rules (and then run rule-update) to see if it works for you (checking /var/log/nsm/hostname-interface/snortu-x.log for synatx/other errors).  


It looks like you've run into an OOM (Out of Memory) error with Logstash.  You''ll likely want to increase the heap size for LS in /etc/logstash/jvm.options and restart it to see if logs start flowing in for you.

Thanks,
Wes 

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.

Robert Moss

unread,
Apr 13, 2018, 1:03:22 PM4/13/18
to security-onion
Will pick this up again tomorrow and get back to you, thanks for all your help again Wes.

Thanks
Robert

Robert Moss

unread,
Apr 16, 2018, 6:03:13 AM4/16/18
to security-onion
Hi Wes,

I have added the rule "alert tcp any any -> $HOME_NET 80 (flags: S; msg:"Possible TCP DoS"; flow: stateless; detection_filter: track by_dst, count 70, seconds 10;)" to my local.rules file and the output from the snortu-1.log is below

https://pastebin.com/0BqYX2gp

It seems like this rule should work for me as I have removed the attacking machine subnet from the $HOME_NET variable within the snort.conf file but the IDS is still not registering any alerts for this attack.

However, I have performed scans on the workstations subnet using the armitage tool within kali linux and the IDS is alerting to these scans so it's confirmed to me that it isn't a sensor or traffic problem. I read on another forum post within this group that DoS attacks are hard to write rules for within SO as there are so many ways of performing this type of attack, is this true?

Thanks again for all the help,
Robert

Wes Lambert

unread,
Apr 16, 2018, 6:59:30 AM4/16/18
to securit...@googlegroups.com
Did you make sure to run rule-update after adding your rule to local.rules?

Is your rule enabled in /etc/nsm/rules/downloaded.rules?

Thanks,
Wes

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.
Reply all
Reply to author
Forward
0 new messages