Suricata IDS and IPS

DaddyGo

always pay attention for bmeeks descriptions, he is the maintainer of the Suricata and Snort packages under pfSense

it doesn't matter, if you use paid or not paid version
the difference is that the paid is updated several times and is more current

this can even come in handy if you also use ET rules
a slightly older list, but compiled by knowledgeable man:

https://raw.githubusercontent.com/jflsakfja/suricata-rules/master/list.txt

and edit: https://forum.netgate.com/topic/128480/how-automatic-sid-management-and-user-rule-overrides-work-in-snort-and-suricata

bmeeks

@anx said in Suricata IDS and IPS:

@DaddyGo Hi DaddyGo,

That's great I am just reading it. thank you!

I have only IDS enabled at the moment. However, i am confuse with the
"Enable Automatic SID State Management " Should I still enable it even if I have Paid Snort Subscription ?

Snort Paid Subscriber Rules are more current than the Registered User Free Rules. When a new threat comes along and a new rule is created to detect that threat, the new rule is immediately added to the Paid Subscriber Rules. However, that new rule won't go into the Registered User Free Rules until a minimum of 30 days after it was added to the paid rules. So the Registered User Free Rules are at least 30 days older than the Paid Subscriber Rules. Since a paid subscription for personal use is only $29.99 USD per year, it is well worth subscribing.

Automatic SID Management is a more advanced IPS/IDS task, and really should only be used after you have gained some experience with administering an IDS. Since you are asking the question, that leads me to suspect you are a newbie to IDS/IPS administration. If that is the case, do this for an easy setup.

Obtain a Snort Rules Oinkcode (either paid or registered user free; I suggest paid).
Go to the GLOBAL SETTINGS tab in Snort and paste in your Oinkcode in the box provided after checking to enable Snort Rules. Paste in just the numeric Oinkcode. ~~Do not put in any kind of URL!~~. If using Suricata, you need to also put in the name of the current Snort rules archive filename. As of today that name is snortrules-snapshot-29160.tar.gz. If running Snort, there is no need to enter a filename (in fact there is no textbox for that in the Snort package). Save the changes.
Go to the UPDATES tab and click the Update button to force a rules download/update. This will take several seconds to maybe even a few minutes to complete, so be patient. When the pop-up dialog self-closes, the update is complete.
Configure a Snort interface if you have not already. I strongly suggest creating the Snort instance on your LAN and not the WAN. Putting Snort on the LAN makes it easier to figure out which local hosts are impacted by rules. And on the WAN, pfSense is going to drop all unsolicited inbound traffic anyway. So Snort would serve no real purpose on the WAN since it would be alerting and blocking what the firewall was going to block already.
Now edit the configured Snort interface and go to the CATEGORIES tab. On that tab click the option to "Enable IPS Policy", and in the drop-down selector choose "IPS Policy Connectivity". An IPS Policy is a pre-made set of rules created by the Snort team. "Connectivity" is a great starter policy. Once you gain some experience and get your system tuned, you can switch to "Balanced" if desired. But resist the urge to go straight to "Balanced". You need to learn to crawl before you walk, and walk before you run ... .
Save the change.
Return to the INTERFACES tab and start Snort on the interface (or restart it if already running).

Now sit back and watch the ALERTS tab for at least a week, and preferably up to a month, running in IDS (alerts only) mode. Review the received alerts and evaluate them for being potential false positives. Likely there will be several of those. You will need to either disable or suppress the false positive prone rules. Each user's network is different in terms of which rules false positive. Thus you will need to evaluate your own traffic. Google can be your best resource for figuring out what an alerting rule really means.

Remember that each alert that shows up represents potentially blocked traffic once you enable blocking, so you want to be sure that only malicious or potentially malicious traffic is blocked; but stuff like streaming, most web traffic, etc., is allowed. You will likely have to suppress or disable several of the HTTP_INSPECT preprocessor rules as they will fire frequently on traffic that is not malicious but that just fails to dot every "i" and cross every "t" of the applicable RFCs for web traffic.

anx

@bmeeks said in Suricata IDS and IPS:

$29.99 USD per year, it is well worth subscribing.

Yes it is worth it! and its only 30$.

thank you for your valuable tips. I only use IDS at the moment.

thanks again.

anx

@bmeeks Point 2. I do not need to put any info in Snort Rules Filename? thanks
Point 4. I will remove WAN completely from Suricata, however, if I will start to use Open VPN or any kind of VPN services on pfsense, should I enable it again ?

bmeeks

@anx said in Suricata IDS and IPS:

@bmeeks Point 2. I do not need to put any info in Snort Rules Filename? thanks
Point 4. I will remove WAN completely from Suricata, however, if I will start to use Open VPN or any kind of VPN services on pfsense, should I enable it again ?

I'm sorry, yes you do need to put in the Snort Rules filename. When I was writing my original reply I thought you were using Snort. The name of the required file is snortrules-snapshot-29160.tar.gz.

Also, since you are running Suricata, you will find a number of Snort rules that will throw errors and fail to load during startup. This is normal as Suricata does not understand all of the same rules syntax as Snort.

Unless you are really bent on using Suricata, I kind of suggest starting with Snort as the use of IPS Policy is a bit better there as no rules will fail to load. The packages have identical GUI setups.

anx

@bmeeks Ok, thank you, But I read that suricata uses multithreading ?

bmeeks

@anx said in Suricata IDS and IPS:

@bmeeks Ok, thank you, But I read that suricata uses multithreading ?

Yes, but it has no practical effect on performance unless you are pushing more than 1 Gigabits/second sustained traffic. No home user ever does that, and neither do most Small Offices.

There are portions of the Suricata detection model where traffic still gets funneled through a bottleneck. Lots of tests have been done between Snort and Suricata with realworld traffic, and the results are mostly a toss-up in terms of which is faster.

anx

@bmeeks this is fantastic information. I will remove Suricata and install Snort . 1Gb not a chance here :)

anx

It seems that there is an issue with Server ?
The process will require 80 MiB more space.
2 MiB to be downloaded.
[1/4] Fetching pfSense-pkg-snort-3.2.9.11.txz: .......... done
[2/4] Fetching snort-2.9.16.txz: . done
pkg-static: https://pkg.pfsense.org/pfSense_v2_4_5_amd64-pfSense_v2_4_5/All/snort-2.9.16.txz: Operation timed out
Failed

bmeeks

@anx said in Suricata IDS and IPS:

It seems that there is an issue with Server ?
The process will require 80 MiB more space.
2 MiB to be downloaded.
[1/4] Fetching pfSense-pkg-snort-3.2.9.11.txz: .......... done
[2/4] Fetching snort-2.9.16.txz: . done
pkg-static: https://pkg.pfsense.org/pfSense_v2_4_5_amd64-pfSense_v2_4_5/All/snort-2.9.16.txz: Operation timed out
Failed

Yes, it does seem to be an issue with the package repo server. Give it a few minutes and retry.

DaddyGo

@bmeeks I don’t like to write (cringe text) therefore I only need to tell how good other person is

your style is frenetic, especially as you steer the beginner OP onto the right way
maybe you also worked as a teacher at some point?

anx

@DaddyGo said in Suricata IDS and IPS:

etic, especially as you steer the beginner OP onto the right way
maybe you also worked as a teacher at some point?

It's true, it's very rare to find such an approach to other people

DaddyGo

I told you to listen to him and follow (I also learned many - many new things from IPS / IDS from his descriptions and from him "jflsakfja", but unfortunately he is no longer with us

in this confusing world such a mentality, huhuhuh .... rare

you are also a good guy, others right away they are demanding and think they "shiting" out IT

anx

I enabled the IPS Policy to check it. However, still is showing that the blocking is disabled on LAN.

am I doing something wrong? thanks

Also, noticed that only these alerts I can see.

bmeeks

@DaddyGo said in Suricata IDS and IPS:

@bmeeks I don’t like to write (cringe text) therefore I only need to tell how good other person is

your style is frenetic, especially as you steer the beginner OP onto the right way
maybe you also worked as a teacher at some point?

In fact I was a technical instructor for a number of years in my career. I first worked on, and then later taught others how to work on, nuclear power plant control systems. Later I moved over to the Information Technology side of things and worked in cyber security for a number of years before retiring early to enjoy life before I get too old to do so ... .

bmeeks

@anx said in Suricata IDS and IPS:

I enabled the IPS Policy to check it. However, still is showing that the blocking is disabled on LAN.

am I doing something wrong? thanks

Also, noticed that only these alerts I can see.

Enabling a policy will not automatically turn on blocking in either Suricata or Snort. For Snort, you will need to manually enable blocking on the INTERFACE SETTINGS page for the interface. If I recall the setting is called Block Offenders. However, don't rush to enable that until you learn more about tuning your rules.

Those HTTP_INSPECT alerts are the false positives I was talking about. There are several of those rules which alert these days on web traffic that is actually not malicious. Look through those alerts and click the red X beside the GID:SID (Generator ID and Signature ID) column on the ALERTS tab to disable those false positive rules. I personally have a number of those rules disabled in my setup.

Here is a link to an older and long thread with posts from various users showing which rules they enable and disable and why: https://forum.netgate.com/topic/50708/suricata-snort-master-sid-disablesid-conf. It's a good place to start learning about alert suppression and rule disabling.

anx

Hi guys,

How to check if actually IDS is working? I have installed PfBlockerNG to block Adds only.

Since then, I dont see any IDS alerts. Hmm

DaddyGo

Hi,

if you have the ability to run a KaliLinux virtual machine (or nativ), you will find all the tools for the different tests.
I hope you meant pfBlockerNG -devel

anx

@DaddyGo said in Suricata IDS and IPS:

pfBlockerNG -devel

Yes, Devel version.

Ok, will try with Kali. thanks

bmeeks

@anx said in Suricata IDS and IPS:

@DaddyGo said in Suricata IDS and IPS:

pfBlockerNG -devel

Yes, Devel version.

Ok, will try with Kali. thanks

If you have put Snort or Suricata on your LAN, you will need to direct your Kali machine towards that interface.

With a properly tuned IDS you actually don't want to see any alerts as a normal thing. A few alerts now and then is what you would expect. For example, on my LAN my most recent Snort alerts are from April 30th of this year. And those were two HTTP_INSPECT preprocessor rules that mine and my wife's iPhones triggered. I run the IPS Balanced policy on my LAN along with a handful of the ET Open categories.

Because I frequently need data to test with, I also run a Snort instance on my WAN and use a pair of ET Open "known bad IP address" categories enabled there purely to generate alerts for research. I run the Emerging CIARMY and Emerging DSHIELD categories on my WAN to generate that testing data. These two categories are actually just lists of IP addresses from known bad actors. They generate several hundred alerts per day on my WAN from the random Internet "noise" that is always there due to bots scanning for open ports and such.