| Summary: | Whitelisted Host Stops Getting White Listed | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | Charles Brown <jneb1980> |
| Component: | --- | Assignee: | Stefan Schantl <stefan.schantl> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | Major Usability | ||
| Priority: | - Unknown - | CC: | horace.michael, michael.tremer, peter.mueller |
| Version: | 2 | ||
| Hardware: | all | ||
| OS: | Unspecified | ||
| See Also: | https://bugzilla.ipfire.org/show_bug.cgi?id=12078 | ||
| Bug Depends on: | |||
| Bug Blocks: | 12052 | ||
I don't know if this is a legit test but it looks like it demonstrates the problem: 1) Add whitelist entries and verify there presence in: /var/lib/suricata/whitelist.rules root@ipfire suricata]# cat whitelist.rules # Autogenerated file. # All user modifications will be overwritten. pass ip 13.64.186.251 any -> any any (msg:"pass all traffic from/to 13.64.186.251"; sid:1500000;) pass ip 208.80.154.15 any -> any any (msg:"pass all traffic from/to 208.80.154.15"; sid:1500001;) pass ip 172.217.131.166 any -> any any (msg:"pass all traffic from/to 172.217.131.166"; sid:1500002;) pass ip 151.101.180.204 any -> any any (msg:"pass all traffic from/to 151.101.180.204"; sid:1500003;) pass ip 13.64.186.225 any -> any any (msg:"pass all traffic from/to 13.64.186.225"; sid:1500004;) pass ip 151.101.48.204 any -> any any (msg:"pass all traffic from/to 151.101.48.204"; sid:1500005;) pass ip 74.125.3.119 any -> any any (msg:"pass all traffic from/to 74.125.3.119"; sid:1500006;) pass ip 64.50.233.100 any -> any any (msg:"pass all traffic from/to 64.50.233.100"; sid:1500007;) pass ip 208.70.186.167 any -> any any (msg:"pass all traffic from/to 208.70.186.167"; sid:1500008;) pass ip 13.93.227.150 any -> any any (msg:"pass all traffic from/to 13.93.227.150"; sid:1500009;) pass ip 128.61.240.89 any -> any any (msg:"pass all traffic from/to 128.61.240.89"; sid:1500010;) pass ip 64.50.236.52 any -> any any (msg:"pass all traffic from/to 64.50.236.52"; sid:1500011;) 2) Delete /var/tmp//var/tmp/idsrules.tar.gz and update rules [root@ipfire suricata]# rm -f /var/tmp/idsrules.tar.gz [root@ipfire suricata]# update-ids-ruleset 3) Check content of /var/lib/suricata/whitelist.rules [root@ipfire suricata]# cat whitelist.rules cat: whitelist.rules: No such file or directory After suricata rule reload complete, there is no whitelist.rules file. The whitelist.rules file is recreated by unchecking / rechecking the box for enabling whitelist entries Simply clicking the Save button in the Settings section or the Apply button the Ruleset section on Intrusion Prevention System page causes the /var/lib/suricata/whitelist.rules to be deleted. However the whitelist entries remain on the page. and the whitelist.rules file can be recreated as per previous comment -- clicking the check box to disable / enable a whitelist entry I was incorrect in the previous comment: 1) The Save button did not cause the whitelist.rules to be deleted. 2) However the Apply button does cause the whitelist.rules file to be deleted and then recreated as an empty (zero byte) files. Fix has been sent to the development mailing list: https://patchwork.ipfire.org/patch/2262/ The patch seems to have done the trick. Hello Charles, a big thanks for reporting the issue and your test feedback. @Michael or Arne - please merge this fix to get rid of this issue as fast as possible. |
It seems that at least one of the entries I have in "Intrusion Prevention System->Whitelisted Hosts" stops getting whitelisted after some period of time. Over the course of several hours of running without issue, the rule that blocks this address starts blocking it again. The specific whitelisted item is the repository for “The CINS Army List” used by the timfprogs/ipfblocklist feature. So, the traffic getting blocked is coming from my IPFire box going to the whitelisted host. Again, this seems to work fine for several hours – with the whitelisted site being successfully checked for updates on hourly basis. Then, several hours later, the rule alert starts showing in “IPS Log Viewer” and the traffic is blocked. Once it starts blocking, it continues blocking each hour as the target site is tested for updates. The rule that fires is: ET POLICY libwww-perl User-Agent Attempted Information Leak When I had things in a normal properly working state, I did a manual rule update with 'update-ids-ruleset' then checked 'System Logs->Intrusion Prevention'. The log showed: [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/surica ta/whitelist.rules I then ran a manual update for timfprogs/ipfblocklist. The blocklist update failed for CIARMY and the rule blocking access to the whitelisted site fired and is showed in'IPS Log Viewer'. It seems that when the rules get updated, the whitelisted hosts stops getting proper whitelist processing - at least for some whitelisted hosts, sometimes. To get things back into a working state, I deleted the target from whitelist, re-added it, and then clicked the save button on 'Intrusion Prevention System'.