No snort alerts for months. Is this normal?

pzanga

I've had snort configured on my LAN interface for the past year or so, set up to alert but not block. I was using the connectivity IPS policy and slowly but surely going through alerts and weeding out the false positives (which essentially seemed to be most of them, mainly http_inspect rules). I last saw any alerts on 11-23-2022 - again false positives which I suppressed. After not seeing any alerts for a few weeks I changed the IPS policy to balanced. Since then I have still not seen any alerts fire and wondering if that is normal/expected behavior. From what little I could find here and elsewhere it does sound like this may be normal, but just want to check.
Not sure what specific details may be helpful here, but I will note that other than the IPS policy change I have not made any other configuration changes. I do not see anything in the logs that seems off to me and rules appear to be updating normally. I am happy to provide any other details that may be useful.
Thanks ahead of time for any input.

bmeeks

Running Snort on your LAN with a tuned ruleset could certainly lead to no alerts. And that's actually the desired state. No alerts mean nothing suspicious is happening on your network.

If you are curious about whether Snort is still functional, you can simply download a copy of the nmap utility and from a machine on your LAN scan the firewall's LAN IP address. If you tailor your nmap scan to some of the rules you have enabled, then you should see alerts. You will not see blocks because the firewall interface IPs and hosts within your LAN subnet will be covered by the automatic pass list, but you will see alerts.

My favorite quick "functional test" is to enable the ET-Open Scan rules category and then run this nmap command from a separate host:

nmap -sS <firewall_lan_ip>

This should trigger a number of scan alerts in Snort. If you have a virtual machine host in your LAN, then spin up a Kali Linux VM there and you will have all kinds of pen-testing tools to play with and fling attacks at the firewall's LAN interface IP.

pzanga

Well first of all, thanks for the extremely prompt reply.

@bmeeks said in No snort alerts for months. Is this normal?:

Running Snort on your LAN with a tuned ruleset could certainly lead to no alerts. And that's actually the desired state. No alerts mean nothing suspicious is happening on your network.

This is what I had gathered from the one or two posts I could find that seemed related. I believe you were the respondent there as well.
I will check out the nmap utility like you suggest. I can reassure myself that things are working fine and learn something at the same time.

Thanks again.

bmeeks

@pzanga said in No snort alerts for months. Is this normal?:

Well first of all, thanks for the extremely prompt reply.

@bmeeks said in No snort alerts for months. Is this normal?:

Running Snort on your LAN with a tuned ruleset could certainly lead to no alerts. And that's actually the desired state. No alerts mean nothing suspicious is happening on your network.

This is what I had gathered from the one or two posts I could find that seemed related. I believe you were the respondent there as well.
I will check out the nmap utility like you suggest. I can reassure myself that things are working fine and learn something at the same time.

Thanks again.

Kali Linux is an extremely useful tool for IDS/IPS admins to own and play with. I run my copy in a VM under VMware Workstation on my Windows PC. Here is a link to the Kali distro: https://www.kali.org/.

bmeeks

It occurred to me that I need to qualify my statement about scanning on the LAN.

One issue you could hit is that most rules have conditions like this in them:

$EXTERNAL_NET any -> $HOME_NET any

So what that condition means is when an IP address that is within EXTERNAL_NET targets an IP address within HOME_NET, then Snort pays attention. Otherwise it ignores the traffic.

When you test from your LAN and target your LAN interface, the above condition will not be satisfied because your LAN is NOT in EXTERNAL_NET, it is in HOME_NET. When traffic from HOME_NET is directed towards another host in HOME_NET, the rule will not trigger because the condition is not satisfied. So, to make the rule trigger you want to create a custom rule by removing the $EXTERNAL_NET restriction and making the conditional like so:

any any -> $HOME_NET any

You can do this by copying and pasting one of the scan rules from the ET-Open Scan category into a new Custom Rule and then editing the conditional as I illustrated above. Give me a minute and I can see if I can locate a suitable rule for you.

bmeeks

Here are a few suitable test rules you can paste into a new Custom Rule set in Snort.

alert tcp any any -> $HOME_NET 5800:5820 (msg:"ET SCAN Potential VNC Scan 5800-5820"; flow:to_server; flags:S,12; threshold: type both, track by_src, count 5, seconds 60; reference:url,doc.emergingthreats.net/2002910; classtype:attempted-recon; sid:2002910; rev:6; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

alert tcp any any -> $HOME_NET 5900:5920 (msg:"ET SCAN Potential VNC Scan 5900-5920"; flow:to_server; flags:S,12; threshold: type both, track by_src, count 5, seconds 60; reference:url,doc.emergingthreats.net/2002911; classtype:attempted-recon; sid:2002911; rev:6; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

alert tcp any any -> $HOME_NET 1433 (msg:"ET SCAN Suspicious inbound to MSSQL port 1433"; flow:to_server; flags:S; threshold: type limit, count 5, seconds 60, track by_src; metadata: former_category POLICY; reference:url,doc.emergingthreats.net/2010935; classtype:bad-unknown; sid:2010935; rev:3; metadata:created_at 2010_07_30, updated_at 2018_03_27;)

What I changed in these rules from the ET-Open Scan category is $EXTERNAL_NET was changed to any. For example, here is the MSSQL rule before I edited it:

alert tcp $EXTERNAL_NET any -> $HOME_NET 1433 (msg:"ET SCAN Suspicious inbound to MSSQL port 1433"; flow:to_server; flags:S; threshold: type limit, count 5, seconds 60, track by_src; metadata: former_category POLICY; reference:url,doc.emergingthreats.net/2010935; classtype:bad-unknown; sid:2010935; rev:3; metadata:created_at 2010_07_30, updated_at 2018_03_27;)

pzanga

@bmeeks

Once again, thank you. I will take a look at this this weekend when it's safe to mess around with the firewall i.e. non-work hours. Plus I need to address some issues with pfblockerng since I updated to 23.01.

SteveITS

@pzanga As Bill (the package maintainer) has pointed out elsewhere :), Snort can't inspect encrypted traffic which is most of it nowadays. So if you don't have inbound ports/forwards for a server, Snort will depend on you using HTTP, POP, etc. unencrypted.

pzanga

@bmeeks

Finally have some time this weekend to test this and have a question. I noted in an older forum post you mention custom rules needing a unique SID. Does that apply in this case, where I would just be editing the conditional of some current rules vs. creating a truly custom rule?

Thanks again.

bmeeks

@pzanga said in No snort alerts for months. Is this normal?:

@bmeeks

Finally have some time this weekend to test this and have a question. I noted in an older forum post you mention custom rules needing a unique SID. Does that apply in this case, where I would just be editing the conditional of some current rules vs. creating a truly custom rule?

Thanks again.

If you alter the rule text by copying it into the Custom Rules section on the RULES tab, then yes, you must create a new and unique SID. Or else you will need to be sure the original SID is disabled and not being loaded if you elect to keep the existing SID for a rule you are editing. You do not want the IDS/IPS package to encounter a duplicate SID when loading rules. When you create custom rules, they are written to a separate file that is loaded by the IDS/IPS during startup. After loading the normal rules file, the custom rules file is then loaded and processed. You cannot have duplicate SIDs in those files.

The cardinal rule is that you can never have a SID value used more than once in an existing loaded rule set.