Snort no alerts or blocks
-
Hi!
Snort not working as it should. Since a few weeks there are no blocks or alerts.
I´ve been using the same settings for years.
Settings are default and using;
-legacy mode
-IPS policy, security
-ET Open Rules
-snort paid subscriber rules
-block offenders
-AC-BNFA-NQ
-no supression list
-auto flowbit rulesInstalled Suricata with default settings alongside with Snort and Suricata delivered a bunch of alerts in "balanced mode"
Pfsense+ 24.03
Snort 4.1.6_17Any ideas much appreciated
Jonna -
I have run into to this very same issue. I have run this setup with snort for years and all of the sudden I see alerts in the alert log but get no blocks.
Pretty much the same setup only thing that changed is where this box is in the network. It was directly connected to the ISP modem and is now behind another router which is connected tot he ISP modem.
Have entries like this:
05/25/24-19:24:24.447582 ,1,2402000,7015,"ET DROP Dshield Block Listed Source group 1",TCP,162.216.150.99,51215,192.168.1.147,443,54321,Misc Attack,2,alert,AllowBut looking in the Blocked list there is no IP's listed.
-
@jonna99 said in Snort no alerts or blocks:
Hi!
Snort not working as it should. Since a few weeks there are no blocks or alerts.
I´ve been using the same settings for years.
Settings are default and using;
-legacy mode
-IPS policy, security
-ET Open Rules
-snort paid subscriber rules
-block offenders
-AC-BNFA-NQ
-no supression list
-auto flowbit rulesInstalled Suricata with default settings alongside with Snort and Suricata delivered a bunch of alerts in "balanced mode"
Pfsense+ 24.03
Snort 4.1.6_17Any ideas much appreciated
JonnaStill no alerts. Something that affects this changed from 23.09 to 24.03. Started in connection with upgrading.
Or can it have something to do with Kea-dhcp instead of ISC ?Enabling WAN interface (in addition to the other 5 interfaces) with same settings I do get some alerts but only from Emerging Threats and nothing from Flowbit-rules, security-mode.
Jonna
-
@jonna99 said in Snort no alerts or blocks:
nothing from Flowbit-rules, security-mode
Flowbit rules do not alert in the traditional sense. They are bit flags that are set when particular conditions are true and let the IDS maintain a sort of "state" across multiple sessions. Almost every flowbit rule will have the
noalert
keyword in the rule's text thus inhibiting actual alerts.The number one reason for not seeing alerts would be the HOME_NET and/or EXTERNAL_NET variables not set correctly.
-
@bmeeks
Hi!
Thanks for answering.
I"Home net"," External net", "Passlist". and "Alert suppression and filtering" are all set to default.Thanks
Jonna -
@jonna99
Hi!
Sorry if I wasn´t clear in my answer.
The settings are all in default and have been for the last few years. Haven´t changed anything. I have 3 Pfsense boxes and none of them have generated any alerts for weeks now.Any ideas plz
Jonna
-
@jonna99 said in Snort no alerts or blocks:
@jonna99
Hi!
Sorry if I wasn´t clear in my answer.
The settings are all in default and have been for the last few years. Haven´t changed anything. I have 3 Pfsense boxes and none of them have generated any alerts for weeks now.Any ideas plz
Jonna
I just tested a Snort-4.1.6_17 install on a virtual machine by scanning it with
nmap
. I saw alerts and blocks as expected. For this particular VM I run Snort on the WAN so that I can easily scan it with nmap from another VM running Kali Linux.Are you sure the Snort daemon is actually running on your firewalls? When you run this command from the CLI, do you see output indicating running Snort processes:
ps -ax | grep snort
Are you running Snort on the WAN or LAN interface? If LAN, realize that the default drop rules likely in place on your WAN are going to drop pretty much all traffic that would otherwise generate Snort alerts.
When you installed Suricarta, which specific rules were alerting? Suricata's built-in Events rules will trigger on a lot of "noise" and generate alerts. Snort does not have those same built-in Events rules and thus won't alert on them. Post screenshots if you have them of the specific alerts you were seeing with Suricata installed (from the ALERTS tab).
In summary, my test just now with a freshly installed Snort package shows no issues whatsoever. I get alerts and blocks when scanning with Kali Linux as expected.
-
Hi!
-I´ve tried fresh install with same poor result.
-
I paste one line from the command "ps -ax | grep snort" ;
"36783 - SNs 0:01.15 /usr/local/bin/snort -R _41880 -M -D -q --suppress-config-log --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_igb1.6041880 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 41880 -c /usr/local/etc/snort/snort_41880_igb1.60/snort.conf -i igb1.60"
the other lines look the same as above. -
I´m running seven interfaces on one of the boxes but no WAN. Tried enabling WAN for a few days and there I do get alerts from "ET Open rules". A bunch of alerts from scan- and torrules but nothing else.
-
Concerning my test with Suricata, I don´t remember which rules specifically but I tried to set the same as I have in Snort.
Jonna
-
-
@jonna99 said in Snort no alerts or blocks:
I paste one line from the command "ps -ax | grep snort" ;
"36783 - SNs 0:01.15 /usr/local/bin/snort -R _41880 -M -D -q --suppress-config-log --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_igb1.6041880 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 41880 -c /usr/local/etc/snort/snort_41880_igb1.60/snort.conf -i igb1.60"
the other lines look the same as above.I see you are running Snort on a VLAN interface. That can be dodgy. I do not have a mechanism for testing with VLANs in my development setup.
@jonna99 said in Snort no alerts or blocks:
I´m running seven interfaces on one of the boxes but no WAN. Tried enabling WAN for a few days and there I do get alerts from "ET Open rules". A bunch of alerts from scan- and torrules but nothing else.
When running on the LAN or any other internal interface, you are likely not going to see many (if any alerts) because the WAN-side firewall rules are dropping traffic that otherwise Snort would see. Check out this diagram that shows where Snort sits in the traffic flow path --
Notice in the above diagram how the traffic goes directly from the NIC to the IDS/IPS BEFORE it gets to the
pf
firewall engine. So, looking at this diagram, if Snort is on the WAN it sees all the normal Internet noise before thepf
firewall engine has filtered it and thus generates alerts. But those alerts are worthless really since thepf
firewall is already going to be dropping that traffic due to the default "deny" rule.But if Snort is on the LAN, then you can see that the WAN firewall rules will effectively "filter" the traffic and thus reduce the number of alerts seen (and quite possibly reduce them to zero).
If you want to see whether Snort is working, install
nmap
on an internal machine on one of your LAN-side networks and use it to scan the firewall interface IP. Enable the Emerging Threats Scan rules (ET-Scan), restart Snort, then run annmap
Syn scan targeted to the firewall's interface IP on the network where thenmap
machine is located. You should get alerts. You won't get blocks because of the automatic default passlist, but you should see alerts. -
@bmeeks
Yes of course, you are right. I did the Nmap scan and sure enough, alerts showed up.
Reading your answer I think I made a mistake enabling the VLANS, The LAN should be enough since the VLANs are just "sub interfaces" to LAN? I don´t really need to see where and which part of the network someone/something tried an intrusion as long as it´s stopped. Enabling only LAN would, I guess, also use less CPU -power.Jonna
-
@jonna99 said in Snort no alerts or blocks:
The LAN should be enough since the VLANs are just "sub interfaces" to LAN? I don´t really need to see where and which part of the network someone/something tried an intrusion as long as it´s stopped. Enabling only LAN would, I guess, also use less CPU -power.
Correct. Snort, by default, puts the monitored interface in promiscuous mode. That means it sees all traffic traversing the physical interface no matter what VLAN it may be associated with.
-
@bmeeks
Not too old to learn something new ,thanks to you.Many thanks
Jonna