Snort 2.9.6.0 - Alerts not being logged

priller

I normally have both Suricata and Snort running.

I uninstalled Suricata just make sure having both running wasn't somehow related. However, the problem was still there. Did a restart of Snort after Suricata was uninstalled, just to make sure it was 'clean'.

bmeeks

@priller:

I normally have both Suricata and Snort running.

I uninstalled Suricata just make sure having both running wasn't somehow related. However, the problem was still there. Did a restart of Snort after Suricata was uninstalled, just to make sure it was 'clean'.

Just to be sure I am correctly understanding the problem –-

On a given firewall, with a Snort-configured interface, if you enable the IP REP preprocessor for the interface it stops logging new alerts on the ALERTS tab but new blocks show up on the BLOCKED tab. Is that correct? And if you then disable the IP REP preprocessor, new alerts start appearing on the ALERTS tab and also still show up on the BLOCKED tab. Is this last statement also correct?

Bill

priller

@bmeeks:

Just to be sure I am correctly understanding the problem –-

On a given firewall, with a Snort-configured interface, if you enable the IP REP preprocessor for the interface it stops logging new alerts on the ALERTS tab but new blocks show up on the BLOCKED tab. Is that correct? And if you then disable the IP REP preprocessor, new alerts start appearing on the ALERTS tab and also still show up on the BLOCKED tab. Is this last statement also correct?

Correct on all points.

To expand on the 'no alerts', there is also nothing in the system log. So, it's not just a GUI thing.

I did try enabling IP REP on just one interface (out of 3) and alerts stop for all interfaces, not just the one with IP REP enabled.

bmeeks

@priller:

@bmeeks:

Just to be sure I am correctly understanding the problem –-

On a given firewall, with a Snort-configured interface, if you enable the IP REP preprocessor for the interface it stops logging new alerts on the ALERTS tab but new blocks show up on the BLOCKED tab. Is that correct? And if you then disable the IP REP preprocessor, new alerts start appearing on the ALERTS tab and also still show up on the BLOCKED tab. Is this last statement also correct?

Correct on all points.

To expand on the 'no alerts', there is also nothing in the system log. So, it's not just a GUI thing.

I did try enabling IP REP on just one interface (out of 3) and alerts stop for all interfaces, not just the one with IP REP enabled.

Do you have a VMware or other virtual machine environment where you could try a green field install of pfSense and Snort and see if the problem exists there? I have three interfaces on my home network firewall with Snort running on all three. I have the IP REP preprocessor enabled on the WAN side. My alerts logging is working fine.

I'm not doubting your result, but just am totally baffled about what could be the underlying cause.

EDIT: one other quick question – is this a standard pfSense ISO image on a conventional hard disk, or is this a CF install?

Bill

priller

@bmeeks:

Do you have a VMware or other virtual machine environment where you could try a green field install of pfSense and Snort and see if the problem exists there?

I do. I'll see if I can reproduce there.

@bmeeks:

EDIT: one other quick question – is this a standard pfSense ISO image on a conventional hard disk, or is this a CF install?

conventional hard disk (SSD)

Also …. If you are interested in seeing the problem live, I'm happy to create a WebEx so you can poke around. Just PM me.

bmeeks

@priller:

@bmeeks:

Do you have a VMware or other virtual machine environment where you could try a green field install of pfSense and Snort and see if the problem exists there?

I do. I'll see if I can reproduce there.

@bmeeks:

EDIT: one other quick question – is this a standard pfSense ISO image on a conventional hard disk, or is this a CF install?

conventional hard disk (SSD)

Also …. If you are interested in seeing the problem live, I'm happy to create a WebEx so you can poke around. Just PM me.

Sent you a PM.

Bill

priller

As a troubleshooting measure, I rebooted the whole box. Snort is not starting now. Does the following message make sense?

Unable to open rules file "/usr/pbi/snort-amd64/etc/snort/snort_47247_igb1//usr/pbi/snort-amd64/etc/snort/snort_47247_igb1/rules/suricata.rules": No such file or directory.

Should Snort be calling "suricata.rules"?

I have seen this before and the only way to make Snort start is to reinstall it.

–-
Update 1: While Snort was in this FATAL ERROR state (see attached), I uninstalled Suricata and then rebooted again. This time Snort started no problem.

I'm starting to have a bad feeling about having both Snort and Suricata installed at the same time.

Now to see if alerts work while having IP REP enabled.

Update 2: The issue of no alerts when IP REP is enabled is still there.

![snort start.jpg](/public/imported_attachments/1/snort start.jpg)
![snort start.jpg_thumb](/public/imported_attachments/1/snort start.jpg_thumb)

priller

** SOLVED **

Guess I'll take the hit for Operator Error upfront. But, there is some behavior I think is strange.

–

When I enabled IP REP in the interface configuration, I did not go further down and select the IP Blacklist (the only one I had was the emerging-compromised-ips.txt list that was there automatically). While in this configuration, all alerts stopped being written to the alerts file in the interface directories.

Once I assigned the IP Blacklist, alerting started working normally.

I then went back and tried to reproduce the original problem by removing the IP Blacklist while still having IP REP enable. Not only could I not reproduce it, but I kept getting 'packets blacklisted' blocks and alerts without having the blacklist selected (IP REP was still enabled … I did toggle it off/on). Probably gets cached.

--

Another oddity ..... While in the first state of having IP REP enabled and NO blacklist selected, there were still blocks for the IP's in the blacklist, but the Alert Description was blank on the BLOCKED tab.

Now that I've messed around with adding/removing the blacklist, the blocks have the expected "(spp_reputation) packets blacklisted " Alert Description.

Anyway, the root cause was not having an IP Blacklist selected when initially enabling IP REP.

A good feature enhancement would be to have a configuration check to ensure the user has at least one blacklist selected and prompt the user, if there is none.

Still don't understand the FATAL ERROR starting Snort when Suricata was also installed. But, that may be a topic for another thread.

bmeeks

@priller:

** SOLVED **

Guess I'll take the hit for Operator Error upfront. But, there is some behavior I think is strange.

–

When I enabled IP REP in the interface configuration, I did not go further down and select the IP Blacklist (the only one I had was the emerging-compromised-ips.txt list that was there automatically). While in this configuration, all alerts stopped being written to the alerts file in the interface directories.

Once I assigned the IP Blacklist, alerting started working normally.

I then went back and tried to reproduce the original problem by removing the IP Blacklist while still having IP REP enable. Not only could I not reproduce it, but I kept getting 'packets blacklisted' blocks and alerts without having the blacklist selected (IP REP was still enabled … I did toggle it off/on). Probably gets cached.

--

Another oddity ..... While in the first state of having IP REP enabled and NO blacklist selected, there were still blocks for the IP's in the blacklist, but the Alert Description was blank on the BLOCKED tab.

Now that I've messed around with adding/removing the blacklist, the blocks have the expected "(spp_reputation) packets blacklisted " Alert Description.

Anyway, the root cause was not having an IP Blacklist selected when initially enabling IP REP.

A good feature enhancement would be to have a configuration check to ensure the user has at least one blacklist selected and prompt the user, if there is none.

Still don't understand the FATAL ERROR starting Snort when Suricata was also installed. But, that may be a topic for another thread.

Thanks for the detailed write-up. I will review the logic for all the IP REP stuff to be sure the configuration gets written correctly. It should not matter if a blacklist or whitelist is selected or not, but I will test out this condition to see if some problem is in fact lurking there.

Snort and Suricata co-existence should not be a problem. While they use much of the same code base, they store all their files in completely different directories. I'm inclined to believe something unusual happened in your case. I will also test running them both just to be sure.

Bill

priller

@priller:

I then went back and tried to reproduce the original problem by removing the IP Blacklist while still having IP REP enable. Not only could I not reproduce it, but I kept getting 'packets blacklisted' blocks and alerts without having the blacklist selected

Ops, never mind, I was clicking around too fast. Adding the blacklist to the interface 'sticks' without hitting Save, meaning you can leave the interface configuration and when you come back it is still there. You can be 'tricked' into thinking it is doing something.

Only when you hit Save does it trigger the interface config reload.

Same for when you remove a list.

This behavior could have unintended consequences for the user. You continue to see a given blacklist applied (or removed), but it is not doing anything. (Got'a protect dummy users from themselves! :o )

bmeeks

@priller:

@priller:

I then went back and tried to reproduce the original problem by removing the IP Blacklist while still having IP REP enable. Not only could I not reproduce it, but I kept getting 'packets blacklisted' blocks and alerts without having the blacklist selected

Ops, never mind, I was clicking around too fast. Adding the blacklist to the interface 'sticks' without hitting Save, meaning you can leave the interface configuration and when you come back it is still there. You can be 'tricked' into thinking it is doing something.

Only when you hit Save does it trigger the interface config reload.

Same for when you remove a list.

This behavior could have unintended consequences for the user. You continue to see a given blacklist applied (or removed), but it is not doing anything. (Got'a protect dummy users from themselves! :o )

You're right. Did not think about that. I will update it so changing a blacklist or whitelist does the restart.

Bill