Summary: | Guardian fails to generate blocked hosts since core update 126 | ||
---|---|---|---|
Product: | IPFire | Reporter: | Wayne <mentalic> |
Component: | --- | Assignee: | Stefan Schantl <stefan.schantl> |
Status: | CLOSED CANTFIX | QA Contact: | |
Severity: | Security | ||
Priority: | Will affect an average number of users | CC: | filthyest, michael.tremer, oli, peter.mueller, suitably_stupid |
Version: | 2 | Keywords: | Security |
Hardware: | all | ||
OS: | All |
Description
Wayne
2019-01-02 15:15:24 UTC
The intrusion detection interface bugs originally described also occur if Guardian was never installed. 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. 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... 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). 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. 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. Testing volunteer here! Please make sure you are subscribed to the development mailing list. We will post an update on there very soon. 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. 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 } 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. |