No alerts on tls, http rules

160 views
Skip to first unread message

mtn...@gmail.com

unread,
Feb 17, 2017, 2:14:03 PM2/17/17
to security-onion
Just checking in to find out if anyone else is having this trouble.

I have two standalone security onion boxes, on two different networks, different hardware, different switches feeding the span ports. Both boxes have the exact same problem.

Both boxes are freshly installed fully default security onion configurations using suricata (emerging threats open rules), bro, and elsa. I have downloaded, wiped and reloaded with every ISO version of security onion from 14.04.4.2 through the 14.04.5.2 test, with the exact same results.

The problem is that none of the rules that use tls or http (alert tls..... or alert http.....) will fire.

I have verified and re-verified that the span/sniff ports are correct and the traffic exists on the wire.

I have replayed pcaps with known traffic with no results.

I have spoofed my own user agent to test.

I have created custom rules that should match any tls or http traffic, in any direction, with no thresholds.

I have created custom rules that match ip or tcp in the same manner as the test tls and http and get spammed like crazy with alerts (as I expect the tls and http rules to fire).

I have quadruple checked all of my config files - despite them being 100% default out of the box after a fresh install.

I even reconfigured security onion to use Snort instead of Suricata.

Nothing works. I can't get any tls or http rules to fire. I checked sguil, ELSA, squert and fast.log. No alerts when they should be firing.

I'm at a loss. Do I have to do something special to get suricata/snort to look at tls and http?

Thanks,
J


Here are my custom test rules. All rules beginning with "alert ip" or "alert tcp" fire. All rules beginning with "alert tls" or "alert http" do not fire. This is regardless of whether they're all enabled at once or one at a time.

alert tcp any any -> any any (msg:"TEST Concrete in tcp"; content:"concrete"; classtype:misc-activity; sid:3; rev:2;)
alert ip any any -> any any (msg:"TEST Concrete in ip"; content:"concrete"; classtype:misc-activity; sid:4; rev:2;)
alert http any any -> any any (msg:"TEST Concrete in http"; content:"concrete"; classtype:misc-activity; sid:6; rev:2;)
alert http any any -> any any (msg:"TEST http"; classtype:misc-activity; sid:5; rev:2;)
alert tls any any -> any any (msg:"TEST tls"; classtype:misc-activity; sid:7; rev:2;)
alert ip any any -> any any (msg:"TEST ip"; classtype:misc-activity; sid:8; rev:2;)
alert tcp any any -> any any (msg:"TEST tcp"; classtype:misc-activity; sid:9; rev:2;)


mtn...@gmail.com

unread,
Feb 17, 2017, 5:35:33 PM2/17/17
to security-onion
So, after much hair-pulling the problem is solved on one of the systems by changing:

vlan:
use-for-tracking: false

Apparently there was a vlan tag problem.

The second system still has problems despite this change. :(

Wes

unread,
Feb 17, 2017, 8:44:05 PM2/17/17
to security-onion
J,

Are you experiencing the exact same issue(s) on the second machine?

In your response, please include the output of sostat-redacted, attaching as a text file, or using a service like Pastebin.com.

Thanks,
Wes

mtn...@gmail.com

unread,
Feb 17, 2017, 10:04:40 PM2/17/17
to security-onion
Yes, it's the exact issue on the second machine. If the vlan tracking setting fixed the first machine I'm leaning towards a network problem at the second machine's location as well.

If it helps, I have a Ubiquiti Edgerouter Lite doing the port mirroring to the still-broken Security Onion system. I have the vlan user-for-tracking set to false in suricata.yaml, and on the Ubiquiti side I disabled hardware offloading and verified I'm at the most current firmware.

I can see the traffic that suricata should be alerting on by using tcpdump on the security onion box as well. This was the same on the first machine before I disabled the vlan tracking as well.

I've attached the sostat output as requested. :)

sostat-redacted.txt

Wes

unread,
Feb 18, 2017, 11:49:42 AM2/18/17
to security-onion

J,

I would try checking /var/log/nsm/HOSTNAME-INTERFACE/suricata.log for clues.

Thanks,
Wes

mtn...@gmail.com

unread,
Feb 22, 2017, 6:09:16 PM2/22/17
to security-onion
Ok, so I "solved" the problem and Suricata can recognize https and tls traffic now. However the solution was to buy a cheap TPLink smart switch and move the port mirroring config from the Ubiquiti EdgeRouter Lite onto the switch instead.

There seems to be a problem with the way the EdgeRouter Lite mirrors traffic. I could see all of the traffic - including the http and tls traffic - using tcpdump on my Security Onion when the EdgeRouter Lite was sending the traffic, so it looked like the port mirror was working. But Suricata just couldn't seem to recognize it as http or tls traffic in that mirrored traffic even though the packets are there.

My test rules started firing immediately after I installed the cheap smart switch and enabled the port mirror there. I did not make any configuration changes at all on the Security Onion side in order to see traffic.

I did change the vlan-tracking: false config back to true after I verified it was working, and it still works.

I also have Ubiquiti EdgeRouter X devices that DO NOT have this problem, so it seems to be just the Lite version causing problems. Not sure why but at least it's working again.

Thanks for the help!
J

Reply all
Reply to author
Forward
0 new messages