Suricata blocking Alexa
-
I turned on Suricata and several hours later my Alexa and other smart home devices stopped working. If I stop Suricata and delete the blocked list it works, but once I start it again, they start being reblocked. I am not sure which of the ET open rules is blocking me. I am not that familiar with Suricata to troubleshoot this either. Could someone tell me which rule should I turn off, or preferable explain to me how to troubleshoot this myself so that I can learn.
-
In Suricata, the Alerts tab shows what it is flagging. The right hand column shows the rule name. Blocked tab shows active blocks (which presumably you've told to expire after a time). It will likely take some tuning...the I believe I've seen the package maintainer suggest not blocking at first to see what would have been blocked, and adjusting. You can disable a rule from the Alerts tab, or Suppress the alert for a specific IP address.
-
You could try putting Suricata in timeout over in the corner for say 15 minutes until it learns to get along better with Alexa ...
.Okay, I've had my silly fun for the morning (it's still sort of early where I am) ...
User @teamits is correct. Find the blocking rule and see if it looks like a false positive. If so, you can disable the rule or suppress it using options on the ALERTS tab with various icons there.
On a bigger picture scale, you mentioned something that is a red flag for me --
I am not that familiar with Suricata
You should never install one of the IDS/IPS packages and immediately put it in blocking mode when you are not an experienced IDS/IPS admin. Instead, let the package run in non-blocking mode for several weeks and you keep watching all the received alerts. Determine from the alerts which are false positives and proceed from that data to disable those rules. This is the "tuning phase" of IDS/IPS operation.
The tuning step is always required because all networks are different and have different traffic. So rules that may be appropriate for one user's network may not be so good for yours, and vice-versa.
-
I'm so glad I finally found this post!
I had a mature multi Echo system which has been working fine for the longest time...... and then developed issues.... not complete system killers, but things which were puzzling on the face of it..
The main issue being the inability (of two Gen2 devices) to play radio stations.... They would aknowledge the request.... tell you "here's radio xxx..." and then silence.... nothing..... Everything else was fine......
My Gen1 device would just plain flat refuse to rejoin the same network that it's been on for years....
Anyway, found this post...... turned off Suricata..... and all is well in the Echo world again!
To my noob brain, I can't explain why it has taken so long for Suricata to become a problem... it's been days or weeks since I installed it as an addon package...?
I've looked at the alert entries, and I can't see anything that explicitly references Amazon or Echo devices.
I've looked at the reverse DNS lookup for those alerts, and again, nothing blindingly obvious....
Examples of the alerts;
ET CINS Active Threat Intelligence Poor Reputation IP group 36
SURICATA IKEv2 weak cryptographic parameters (Auth)
SURICATA STREAM Packet with invalid timestamp
ET USER_AGENTS Microsoft Device Metadata Retrieval Client User-AgentAny comments/advice gratefully received.
Paul
-
Generally when it is activated Suricata will update the rules as configured so rule updates may flag traffic that wasn't flagged before.
I would duplicate the problem then look at the Alerts to see what matches the time stamp of the block.
I would also only enable rulesets that you need/want and not everything (e.g. web server rules don't apply for a home).
We always do two things:
- check "Disable hardware checksum offload" in pfSense (System->Advanced->Networking)
- disable ALL stream-events.rules or it will block lots of traffic on false positives
-
Thanks for your insight Steve.
-
Could someone explain to me how to match the rule name to what I see in the "Wan Categories?
If I look a the alert tab I am getting "ET CINS Active Threat Intelligence Poor Reputation IP group 16" According to the Wan categories I am not seeing anything remotely similar to the rule name. What am I missing?
-
@mrjoli021 said in Suricata blocking Alexa:
Could someone explain to me how to match the rule name to what I see in the "Wan Categories?
If I look a the alert tab I am getting "ET CINS Active Threat Intelligence Poor Reputation IP group 16" According to the Wan categories I am not seeing anything remotely similar to the rule name. What am I missing?
It's not always super easy to make that connection. In this case of this particular rule, it is coming from the ET CINS list of possible bad (or blacklisted) IP addresses. Here is a link to the source of this data: http://www.cinsscore.com/.
So on the CATEGORIES tab there is an Emerging Threats rule set with ET CINS and I think there is also one called ET CIARMY or something similar. These are what I would characterize as "dumb" rules. I don't mean dumb as in useless, but rather "dumb" as in it is simply a list of IP addresses, and if the source or destination IP in a packet is in the list you get an alert.
One problem with rules of this type is that the owners of IP blocks changes. And that is happening a bit more frequently now since the IPv4 address space has been exhausted, and therefore there is a lot swapping and trading going on for money among owners. So an IP block that might have been used by a spammer last month may, this month, be use by a CDN network that is distributing Amazon Prime, Hulu or Netflix streams. So these lists have to be taken with a grain of salt.
