(RESOLVED!!!) WARNING!! Emerging Threats Dshield rule set is now empty inside Snort and on Emerging Threats official website
-
Suricata offers GeoIP rules support. It can download and use the GeoLite2 geo-location database from MaxMind (the same DB used by pfBlockerNG-devel).
However, in Suricata, you must create your own GeoIP rules unless you happen to find a packaged set online someplace. I've never seen one, though. But Suricata does have full support for GeoIP. Here is a link to the documentation: https://suricata.readthedocs.io/en/suricata-6.0.0/rules/header-keywords.html#geoip.
Snort does not have a GeoIP option.
-
@bmeeks said in (RESOLVED NEXT RELEASE) WARNING!! Emerging Threats Dshield rule set is now empty inside Snort and on Emerging Threats official website:
And if you do MITM SSL termination, then an IDS/IPS can be very useful for payload inspection. But there is quite a bit of extra work involved with MITM setup.
I have a MITM configureation in play right now. Just confused as to which point the IPS engine(suricata in my case) can see the payload. What i mean is this, when i perform a pcap on pfsense itself in the GUI, i still see traffic with TLS encryption. So clearly the pcap engine happens before the TLS decryption process. But does Suricata see the decrypted payload?
-
@michmoor said in (RESOLVED NEXT RELEASE) WARNING!! Emerging Threats Dshield rule set is now empty inside Snort and on Emerging Threats official website:
@bmeeks said in (RESOLVED NEXT RELEASE) WARNING!! Emerging Threats Dshield rule set is now empty inside Snort and on Emerging Threats official website:
And if you do MITM SSL termination, then an IDS/IPS can be very useful for payload inspection. But there is quite a bit of extra work involved with MITM setup.
I have a MITM configureation in play right now. Just confused as to which point the IPS engine(suricata in my case) can see the payload. What i mean is this, when i perform a pcap on pfsense itself in the GUI, i still see traffic with TLS encryption. So clearly the pcap engine happens before the TLS decryption process. But does Suricata see the decrypted payload?
No, the default network plumbing of FreeBSD and pfSense puts Suricata immediately after the NIC driver. So, that means it sees the traffic before the MITM interception occurs. Same as you see with PCAP. Using Suricata with MITM on pfSense requires you to do special custom network routing/plumbing on the host. It is not something that is available out of the box for now.
-
@bmeeks Gotcha. Thanks for that tidbit as one of the primary reasons i went down the MITM track was to test the IPS functionality.
I would assume this is probably the case for other packages like ntopng where it can do app identification but most likely not involving Squid or Suricata in the mix so for apps it cant identify..it cant identify. -
@michmoor I am running an ARM processor on a 2100 MAX I have always wondered about it's usage of multithreading within its DNA. If your using SSL intercept the firewall itself runs the certificates, again you can also issue the SSL certs from inside of the Squid software and import them back into the Pfsense software. To my understanding Snort uses only one thread inside of the Pfsense software package; however Snort has multithreading functionality within some versions. Anyway Snort has appID options like Palo Alto does and they function but it eats memory. I can only "speculate" APP ID uses the certificates stored on the firewall.
it's stateful inspection too.
-
@michmoor Snort is not even listed within the sockets when it runs.
-
@jonathanlee I would caution that OpenAppID is not really like PaloAlto so don’t assume you’re getting those feature like quality for free.
-
Snort's OpenAppID is NOT seeing decrypted data. It simply analyzes the unencrypted SNI header in certain traffic types to guess at the application. Once encrypted SNI (ESNI) becomes a regular thing, OpenAppID is going to have some issues identifying applications.
And today neither Snort nor Suricata, by default, will see unencrypted SSL traffic on pfSense even when MITM is present with something like HA-Proxy. The network plumbing on FreeBSD by default puts the IDS/IPS immediately after the NIC driver, so all traffic seen there is still encrypted. You would have to utilize multiple NIC ports and set up custom routing outside of the package GUI for either Snort or Suricata in order to have them see the unencrypted traffic available with MITM.
-
@michmoor Noted: My firewall is not a enterprise class system like some PaloAlto's mine is just a home system, my streaming services never skip a beat now with pfSense running :) a smaller system is all I need. We went over so many PaloAlto options during class it can make your head spin they have so many options. I wonder with all the new whitebox software being installed right on the network cards if maybe something like a large Ciena router could also manage security options right on the router itself. Cisco started doing a firewall and router all in some years ago, it was cutting edge at the time to combine them.
-
@bmeeks but what about the sockets inside pfsense software, it lists nothing for snort? Is that separate from the software? I love this stuff it is so impressive what pfsense can do. The packages the firewall software all of it, it's a work of software art.
-
@jonathanlee said in (RESOLVED NEXT RELEASE) WARNING!! Emerging Threats Dshield rule set is now empty inside Snort and on Emerging Threats official website:
@bmeeks but what about the sockets inside pfsense software, it lists nothing for snort? Is that separate from the software?
Totally unrelated and not used by either package. Suricata offers an optional socket connection for control purposes (starting, stopping, reloading rules, etc.), but not for inspection purposes. But that optional control socket is not used on pfSense.
Sockets in the context you seem to be talking about are generally used for inter-process communications where applications swap limited amounts of data or control information with each other.
-
@bmeeks Have no fear Pfsense firewall software teams will always find a way to protect systems, HSM security modules today still need management software just like TPK attestation software. Firewall software teams work diligently to keep systems protected. A couple months ago I thought HTTPS/3 UDP QUIC was invincible and now wireshark can spot it, I even saw someone posted a video where they blocked specific QUIC website traffic. Without direct government protocol approval how can experimental traffic even get around a backbone internet router like a monster Ciena system? I personally think the wildwest days of dotcom are over, because more and more protocols and rules are taking hold, hence government compliance servers now just going to block it out if they want. It truly is mirrored analytics.
-
@bmeeks look at what Russia wants to do with ESNI
https://www.privateinternetaccess.com/blog/russia-wants-to-outlaw-tls-1-3-esni-dns-over-https-and-dns-over-tls/
They are going to force state issued certificates. WOW!!
-
@bmeeks curious are there any development projects to have the IDS sit after the proxy in order to scan packets or would that require a rework within FreeBSD?
-
@michmoor said in (RESOLVED NEXT RELEASE) WARNING!! Emerging Threats Dshield rule set is now empty inside Snort and on Emerging Threats official website:
@bmeeks curious are there any development projects to have the IDS sit after the proxy in order to scan packets or would that require a rework within FreeBSD?
Nothing in progress that I am aware of.
-
Brandon and others from emerging threats support has helped bring resolve to this issue.
Update your lists and they should populate again for all the items.
-
Jonathan, thanks for reporting! This disruption was due to an internal automation failing - we've fixed that problem and added some further alerting around failure points. We pushed the rules after the fixes were made on Saturday morning.
I'm glad we caught this post, and I'd also like to invite everyone to interact with us on twitter @et_labs and to join our Discourse.
Thanks again!