Begginner needs help with Suricata
-
Greetings all,
First off let me apologize I am super new to this forum, I have been teaching myself pfSense on my own. I got everything working properly and my network is functional and running at the speeds it should be. Now please don't make fun of me. I had snort and suricata both installed because I had no idea what I was doing. I since then deleted Snort and am using Suricata. I have the snort subscriber list enabled with emerging threats. I did not know this until today that I was not actively blocking threats it was just monitoring my networking. So I enabled everything and I want to make sure it is working properly. I originally used In-line mode, but was not getting any block notices or anything. And then I tried Legacy and I am still not getting block alerts. I want to make sure it is working properly and that my network is being protected. I'm not sure which error messages you need or anything, so please inform me of what you guys need to assist and I will be more than happy to do so. Thank you so much for bearing with me, I am trying to learn and just need some guidance. I do support this community and product any chance I get. I love it!!
-
Hi,
You are aware of the fact that most traffic is TLS/SSL these days ?
So you're asking Suricata to scan data it can't see ....
And no, even experts can't and won't consider MITM.
We're all back to square one : protecting the network starts by forming the end users. A (LAN) non-trusted network ? Then isolate them all. -
What do you mean exactly? The TLS/SSL part makes sense to me, and Suricata trying to scan data it can't see. What should I do? And I noticed since I enabled blocking Suricata won't even pick up anything anymore, no alerts or anything.
-
@DrinkyT said in Begginner needs help with Suricata:
no alerts or anything.
Good news then : the traffic it (still) can see is clean. But you can test it : download into your browser - over a http connection - an Eicar file ( see https://en.wikipedia.org/wiki/EICAR . Suricata should kick in right away. Do the same download over https and Suricata won't notice anything.
Knowing that most traffic is SSL/TLS these days, you might start to wonder why you would actually use tools like Suricata on a firewall.You can't do nothing. Even if you worked for the CIA or NSA, you probably still couldn't do nothing ^^
-
@Gertjan Okay I will try this, thank you so much for your time. But I'm going to ask the question...why use Suricata at all??? ;)
-
@DrinkyT said in Begginner needs help with Suricata:
why use Suricata at all???
When you use a front-end web server proxy (like HAProxy) that terminates the TLS connection, the data stream becomes visible. Snort or Suricata can then be used to inspect the data received from the visiting-clients before the web requests are send over to an internal web server farm.
IMHO : in such a case, I would run a proxy on a dedicated device, on a dedicated LAN segment.Suricata (I use ClamAV) can also be used to inspect incoming mail on a mail server : before the mail is placed in the inbox - or send to another mail server, it can be scanned for info that doesn't belong in a mail.
In the past, the early days, when all was "trust and happiness", the http days, Suricata could actually really inspect the data. These days are over now.
Btw, this is just my idea of how I think it works. I actually hope to be proven wrong.
-
@Gertjan said in Begginner needs help with Suricata:
@DrinkyT said in Begginner needs help with Suricata:
why use Suricata at all???
When you use a front-end web server proxy (like HAProxy) that terminates the TLS connection, the data stream becomes visible. Snort or Suricata can then be used to inspect the data received from the visiting-clients before the web requests are send over to an internal web server farm.
IMHO : in such a case, I would run a proxy on a dedicated device, on a dedicated LAN segment.Suricata (I use ClamAV) can also be used to inspect incoming mail on a mail server : before the mail is placed in the inbox - or send to another mail server, it can be scanned for info that doesn't belong in a mail.
In the past, the early days, when all was "trust and happiness", the http days, Suricata could actually really inspect the data. These days are over now.
Btw, this is just my idea of how I think it works. I actually hope to be proven wrong.
@Gertjan You sure you're not mixing up suricata with squid (proxy)? What you're describing is exactly the reason I got rid of my squid + clamAV setup. It was only able to perform a virus scan on about 1% of my traffic (non https) and was therefore useless. I don't think that applies to suricata or snort. I am definitely getting alerts when a rule is triggered and it of course depends on which rules you have set. I'm sure the experts like @bmeeks can chime in though.
I don't think snort or suricata will stop a virus download unless you have a rule which happens to stop that by chance. I would not recommend trying the eicar link. It shouldn't cause any issues since your desktop AV should stop them anyway, but highlighly doubt suricata will stop them. I think there is a misunderstanding here.
Edit,
FYI, here is a snip of my suricata alerts tab. You can see that the destination port is 443 (https) so yea suricata is able to work just fine with that type of traffic without any special MITM configuration or certificates required. I think clamAV does require MITM dissection since it has to scan the file contained within packets.
-
@DrinkyT said in Begginner needs help with Suricata:
Greetings all,
First off let me apologize I am super new to this forum, I have been teaching myself pfSense on my own. I got everything working properly and my network is functional and running at the speeds it should be. Now please don't make fun of me. I had snort and suricata both installed because I had no idea what I was doing. I since then deleted Snort and am using Suricata. I have the snort subscriber list enabled with emerging threats. I did not know this until today that I was not actively blocking threats it was just monitoring my networking. So I enabled everything and I want to make sure it is working properly. I originally used In-line mode, but was not getting any block notices or anything. And then I tried Legacy and I am still not getting block alerts. I want to make sure it is working properly and that my network is being protected. I'm not sure which error messages you need or anything, so please inform me of what you guys need to assist and I will be more than happy to do so. Thank you so much for bearing with me, I am trying to learn and just need some guidance. I do support this community and product any chance I get. I love it!!
I would suggest using the legacy mode for now. I would also suggest setting it up on your LAN interface and not WAN. It will work either way, but if it's set to LAN at least you'll be able to identify the local client which triggered that alert.
You may not see alerts/blocks even if everything is configured right. That may just mean none of your rules have triggered an alert. I'm not sure of a good way to test that it's working. One way might be to use the Snort Maximum Detection IPS policy and then hit save. I would suspect this is going to be overly protective and actually break perfectly legitimate traffic. You might get a ton of alerts so keep an eye out and you probably want to back off on that once you confirm you are getting alerts/blocks. My IPS Policy Selection is set to Balanced just in case you're interested.
Edit,
Oh and I forgot to mention, if you do try the max detection policy and it starts going off and blocking a ton of traffic that may break legitimate web functions, after you back off on it and set it to Balanced, don't forget to go back to the blocks tab and clear all blocks. Otherwise those connection will remain blocked. -
An IDS/IPS can't inspect encrypted payloads. So the content of SSL packets can't be inspected. That does not mean that irregularities in the header can't be detected. Depending on the threat, certain bit patterns might trigger alerts even though technically the payload might be encrypted. For instance, if a malware coder is dumb enough to always encrypt the same data with the same key, then the encrypted result will always be the same bit pattern. An IDS/IPS rule could see and trigger on that. Unfortunately most malware authors are not that incompetent ... .
There are some ways to position an IDS/IPS so it can see cleartext traffic decrypted from an SSL session, but it is difficult and usually requires some version of MITM.
So as the use of encryption (SSL, TLS, etc.) spreads, the usefulness of IDS/IPS tools will naturally diminish. At least with respect to being able to inspect actual packet payloads. They will still be able to look at the headers and basic protocol info. In the alerts @Raffi_ posted, the alerts are actually from protocol anomalies in the packet header and are not related to the actual packet payload content. The rule is simply alerting on problems with the SYN, ACK or RST flags. It is not alerting on something in the SSL packet payload.