Snort keep blocking IPs on suppress list!

heliop100

Hi everyone.
pfsense 2.4.4, snort 3.2.9.8_4

IPs/sigs on suppress list are still been blocked.

ET SCAN MS Terminal Server Traffic on Non-standard Port

suppress gen_id 1, sig_id 2023753, track by_src, ip xxx.xxx.xxx.xxx

Ideas?

Thanks

bmeeks

Is the suppress list actually assigned to the interface? Just adding an IP to a list does not automatically assign that list. You need to go to the INTERFACE SETTINGS tab for the interface and be sure the correct Pass List is selected in the Pass List selection drop-down on that page. This is the most common cause for "... Snort keeps blocking IPs on suppress list".

Same thing for Suppress Lists. They must actually be assigned to the interface. That is also checked on the INTERFACE SETTINGS tab.

If you make any changes on that tab, save the change and then restart Snort on the interface so it will see the change.

heliop100

Hi bmeeks,

Yes, suppress list are assigned to the interface, and on the alerts tab, shows the IP with the note that the IP are on the suppress list.

bmeeks

Let's make sure you don't have a runaway Snort process running on the interface. That can happen sometimes. Execute this command from a shell prompt on the firewall:

ps -ax | grep snort

You should see only a single snort process running on each configured interface. If you see any duplicate lines, then you have a runaway/duplicate Snort instance on that interface. The extra instance will ignore any changes made to configuration files.

If you see multiple instances, then either reboot the firewall to clear them all out, or you can execute this series of commands.

From within the Snort GUI on the INTERFACES tab, stop all the running Snort instances.
Next, from a shell prompt on the firewall run this sequence of commands:

ps -ax | grep snort

For each listed snort process id, kill that process with this command:

kill -9 <pid>

where <pid> is the process ID listed in the previous process list command.

Repeat step #2 for each snort process you see listed.
Now return to the GUI and on the INTERFACES tab start each configured Snort instance.

Let's see if that corrects your problem.

heliop100

@bmeeks said in Snort keep blocking IPs on suppress list!:

ps -ax | grep snort

Hi,

Only one process.
This problem, usually happens when I update the IP (dynamic) on the suppress list.
After 3 or 4 hours the IP are no longer been blocked, until it change again (usually once a week)

bmeeks

@heliop100 said in Snort keep blocking IPs on suppress list!:

@bmeeks said in Snort keep blocking IPs on suppress list!:

ps -ax | grep snort

Hi,

Only one process.
This problem, usually happens when I update the IP (dynamic) on the suppress list.
After 3 or 4 hours the IP are no longer been blocked, until it change again (usually once a week)

That is a rather key piece of information that you omitted from your original post. Snort does not understand when a dynamic IP changes. It works with static IP addresses only. It does put firewall interface IP addresses on an automatic internal pass list, and it will watch for firewall interface IP updates and adjust the internal pass list accordingly. But it won't do anything if any other IP address changes unless you, as the admin, make the change manually and then restart the Snort process so it will re-read the configuration.

If you are actually running Microsoft Terminal Services on a non-standard port, I would suggest disabling that rule entirely as it going to cause you grief.

heliop100

@bmeeks said in Snort keep blocking IPs on suppress list!:

ther key piece of information that you omitted from your original pos

The dynamic IP are the external one, and when it changes, I manually update the suppress list. these works well for years, but after the last update, it took same time to snort stop blocking, even the IP are updated on the suppress list.

The next time the IP changes, I will restart snort after the edition of the suppress list.

bmeeks

@heliop100 said in Snort keep blocking IPs on suppress list!:

@bmeeks said in Snort keep blocking IPs on suppress list!:

ther key piece of information that you omitted from your original pos

The dynamic IP are the external one, and when it changes, I manually update the suppress list. these works well for years, but after the last update, it took same time to snort stop blocking, even the IP are updated on the suppress list.

The next time the IP changes, I will restart snort after the edition of the suppress list.

Well, as I mentioned earlier, if you really are running Microsoft Terminal Services on a non-standard port (which is what the alert suggests), then why not disable that rule? Don't suppress it, just disable it. If you are not running Terminal Services on a non-standard port, then I would certainly be investigating why that rule is triggering. I assume you have external clients connecting back to something inside your LAN. Also, if this is Terminal Services and it's not running over a VPN, you really need to rethink that setup.

fartypants

Just wanted to say thanks to BMeeks for suggestion re- run-away snorts above.

Been smacking my head against a similar-but-different problem for days, and that's what it was.

Whodathunkit?

Si.

bmeeks

@fartypants said in Snort keep blocking IPs on suppress list!:

Just wanted to say thanks to BMeeks for suggestion re- run-away snorts above.

Been smacking my head against a similar-but-different problem for days, and that's what it was.

Whodathunkit?

Si.

Multiple, but duplicate, Snort (and Suricata) processes can happen from either of these things:

Something causes the WAN IP to change rapidly or the WAN interface cycles down and back up repeatedly. This causes a built in pfSense script to fire that restarts all packages. Because Snort and Suricata both can take a while to start, rapid back-to-back execution of "restart all packages" can result in multiple instances of Snort or Suricata running on the same interface.
Configuring the Service Watchdog package to monitor Snort or Suricata. Service Watchdog does not understand how the Snort and Suricata packages work, thus it cannot properly monitor them. It also does not understand that both packages will stop and restart themselves when doing rule updates. Service Watchdog simply sees the Snort or Suricata daemon stop, so it immediately restarts it. Service Watchdog does not know that Snort (or Suricata) are in the process of restarting themselves from a rules update, so when it issues its own "start" command you can wind up with two or more processes running on the same physical interface. Service Watchdog should never be configured to monitor either of the two IDS/IPS packages!