Bug 11954 - Guardian fails to generate blocked hosts since core update 126
Summary: Guardian fails to generate blocked hosts since core update 126
Status: CLOSED CANTFIX
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: Will affect an average number of users Security
Assignee: Stefan Schantl
QA Contact:
URL:
Keywords: Security
Depends on:
Blocks:
 
Reported: 2019-01-02 15:15 UTC by Wayne
Modified: 2019-05-20 18:59 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wayne 2019-01-02 15:15:24 UTC
Initial packfire update from core 125 to 126 guardian was working. Later I did a clean install and guardian would no longer add IDS logged entries to guardian block list. 
Discovered a fix in Guardian Configuration interface, I set "monitor snort alert file" to OFF, then save setting, then set "monitor snort alert file" to ON and save setting. Then Guardian began generating blocked hosts.

While testing this I also experienced several "white screen" crashes in the Intrusion Detection interface when picking filter items or attempting to view description of filter rules. Several times the selected rules check box's cleared themselves but memory loading did not change so I suspect that rules were still active just no longer had checked box's.

System:
IPFire version: 	IPFire 2.21 (x86_64) - core126
Pakfire version: 	2.21-x86_64
Kernel version: 	Linux ipfire.localdomain 4.14.86-ipfire #1 SMP Tue Dec 11 08:36:08 GMT 2018 x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux
Comment 1 Wayne 2019-01-02 19:06:44 UTC
The intrusion detection interface bugs originally described also occur if Guardian was never installed.
Comment 2 qiller 2019-01-09 21:18:36 UTC
I have got the same Problem since Core 126 except the "white screens". Everytime after reboot of ipfire guardian does not block although there are entries in ids-log. You have to do the "monitor snort alert file to OFF, then save setting, then set monitor snort alert file to ON and save setting"-workaround as described by Wayne. After that blocking works like as intended since next reboot.

For me it looks like a race condition at boot-up-process. So not every ipfire-installation has an issue with that.

My ipfire-installation was newly installed with core 125 on a i3-8100-System, 8gb ram, 128GB ssd, Intel server-quadport-nic if this information helps. I also use the ids-update-script from here: https://github.com/timfprogs/ipfidsupdate

my addon list:

libvirt
apcupsd
bwm-ng
guardian
htop
nano
tor
wio

... and dependancies.
Comment 3 Peter Müller 2019-01-22 20:35:25 UTC
I am observing this bug, too.

Since we are currently in process to move to Suricata IDS/IPS, I doubt it makes sense to put major efforts in Guardian...
Comment 4 qiller 2019-01-23 12:20:14 UTC
Upgraded another IPFire-Installation and got the same issue as mentioned before (ids hits got logged but not blocked by guardian after complete system reboot).
Comment 5 Mikael Lavoie 2019-01-27 23:39:12 UTC
I confirm the bug too. I wnet to guardian config file too if it was monitoring the good file. Yes it is. I can also confirm that snort is working properly and the alert file contain the alert that was intercepted. I'm using emergingthreat rules ans it was working properly since last patch. core 126. If i remeber guardian was updated too in that patch so i think it comes from the new guardian code. Maybe not properly reading the info from the alert file? To resume all is working fine except guardian that is not blocking anything so the problem if probably coming from there.
Comment 6 Michael Tremer 2019-01-28 11:42:13 UTC
Guardian has not really been changed much (https://git.ipfire.org/?p=people/stevee/guardian.git;a=summary). It looks like this is snort reporting in a different log file format. It could literally just be a single character that is different.

Would you participate in testing Suricata so that we can move away from snort very quickly? Suricata is a lot faster and powerful and comes with IPS so that guardian is no longer needed here.
Comment 7 Wayne 2019-01-28 14:43:38 UTC
Testing volunteer here!
Comment 8 Michael Tremer 2019-01-31 11:57:53 UTC
Please make sure you are subscribed to the development mailing list. We will post an update on there very soon.
Comment 9 Peter Müller 2019-02-06 17:36:37 UTC
Setting the Snort priority to "1" in Guardian WebUI seems to restore the blocking behaviour, even for IDS alerts with a lower priority than one.

Not a solution, but might be suiteful as a woraround until Suricata is ready.
Comment 10 suitably_stupid 2019-05-09 04:50:51 UTC
This bug likely got introduced here:

https://git.ipfire.org/?p=people/stevee/guardian.git;a=blame;f=modules/Parser.pm;hb=df8eb30562ceedfe3c042b1c124b308e6b317d42https://git.ipfire.org/?p=people/stevee/guardian.git;a=commitdiff;h=df8eb30562ceedfe3c042b1c124b308e6b317d42


Line 169 needs to have its less than changed to a a greater than.


Line 169:


# Skip alerts if the priority is to low.
169						if ($priority < $priority_level) {
170							last;
171						}

Should be:

# Skip alerts if the priority is to low.
169						if ($priority > $priority_level) {
170							last;
171						}
Comment 11 Stefan Schantl 2019-05-20 18:59:56 UTC
IPFire has moved to suricata as IPS/IDS in core update 131 and the snort options from guardian has been removed, because they are not longer required.

The new IPS can do this task in a much faster and better way than guardian ever could do.

Therefore guardian is only required if you want to detect and block any kind of brute-force attacks against the local SSH and the WUI services.