after I activated some of the rules from the Emerging Threats Community Ruleset the web interface is no longer accessible. However, IPFire continues to run because I can still access the Internet. I now sit with a monitor on the device, can I turn off the rulest again via the terminal?
I suspect that you would need to find the problem line in
This will have lines such as
I believe that deleting the problem line or lines should then clear that rule from being enabled.
I just did a quick test on my vm testbed system.
I can confirm that deleting a line from that file makes that rule unchecked on the wui page.
Also tested that you can just remove the enabled and get the same result.
Which rule gave you this problem. None of them should end up causing the wui page to no longer work. I would like to test this out to see if I can duplicate it, in which case there is a bug in the code somewhere.
Which Core Update are you using?
What error message do you see if you look in
I have now deleted all the rules. The wui is unfortunately still not accessible. I’m on 2.27. Enclosed a picture from the log.
Your problem was nothing to do with the IPS.
That log is showing at least a couple of problems.
The speed.cgi code is failing to open
Is this file existing on your system? If it is it should contain “red0” and should have the following permissions and ownership
-rw-r--r-- 1 root root 4 Dec 1 05:00 /var/ipfire/red/iface
There is also an error about not finding
-rw-r--r-- 1 root root 903 Dec 22 01:06 /opt/pakfire/db/lists/core-list.db
Is this file present on your system and matching the permissions and ownerships.
If the above two files are not present or have incorrect permissions and/or ownerships then something major has gone wrong with your system.
Are there any other different messages in that error_log file?
both files exist on the system. However, the permissions were not correct. After I corrected them, the wui was there again. The IPS log was full of entries, but the log contained just my login attempts from my notebook. Are you sure that this has nothing to do with the IPS? I tried again to activate Emerging Threats Community Ruleset. The WUI goes down again as soon as I activate them and permissions changed again.
Edit: I have now done this three times in a row. The behavior is always the same. After the holidays I’ll try one by one and see if I can identify which rule it is.
If you can say which rules you enabled then I can test that out with my vm testbed IPFire system to see if I can duplicate the problem.
When the permissions were incorrect, what value did they have?
I have just checked the ids.cgi and ids-functions.pl files that do all the suricata based work and there are no chmod commands in that code.
I also then did a search in the IPFire git repository for chmod commands. Most of those are in the LFS files which are used for the building of IPFire. None of those were related to Suricata and I didn’t find any commands that would be expected to change the permissions on iface or core-list.db.
So nothing obvious found that would be expected to cause the problem you are experiencing.
Key step will be seeing if the problem you are experiencing can be duplicated on other IPFire systems.
I though that the simplest way for me to see if I can duplicate your problem is to just select every ruleset in the Emerging Threads provider list. That way I am bound to cover the ones that you have selected.
I did that with my vm testbed and it accepted the selections without any problems. IPFire WUI working as normal.
Checked the two files that you are finding with changed permissions and nothing has changed on them on my system.
So currently I can not duplicate the problem you are experiencing.
Another thing I don’t understand is if the core-list.db is being changed, why are the two other files in that same directory, server-list.db and packages_list.db, not also being changed.
Why are core-list.db and iface, two totally different files, in two different locations, used by two significantly different parts of IPFire the only two files to be changed and in a consistent manner.
Maybe check the b2sum hash of the following two files to make sure they have not been corrupted or modified in some way.
b2sum /srv/web/ipfire/cgi-bin/ids.cgi e55c1e52493d11bc60a9e439465fd907034c0569cde42bd62dc09be2fb55679dae3d6a81638de5d62c8828aa0e7381e09a2dfb43043ff2ce27cdad0768b837ae b2sum /var/ipfire/ids-functions.pl 6cea6314b3b41a2cb5b93d0f38e2c65d0109120aa479872beb08b32a16c1cdc7506c413e4cd1301ddeab0903696efe00aeebb51203f5219cefd71965c996fb79
I have tested a bit more. But somehow the problem only gets more confusing. As described the problem occurs at Emergingthreats community ruleset. But it doesn’t seem to matter if I select one rule, all or a block. As soon as I select one, completely random which from the Emergingthreats community ruleset. As soon as I click on apply the wui goes down. I have the same problem with the Travis Green Hunting Rules, but not with OISF Traffic ID Rules, Abuse.ch SSLBL Blacklist Rules, Etnetera Aggressive Blacklist Rules, PT Attack Detection Team Rules. I then reinstalled Ipfire, but this time I chose xfs as the filesystem. Here the problem did not occur. I then installed ext4 again just as a joke and had the problem again.
I will check the b2sum tomorrow.
If it occurs after a re-install then you should also check the sha256 hash sum for the iso versus what is specified on the IPFire download site.
I also am using ext4 and don’t have the problem so ext4 is not the root cause of the problem.
If the sha256 hash sum of your iso does not match the one on the IPFire download site then dispose of that incorrect/corrupted iso and download a new version. Check the sha256 hash sum to confirm that the download occurred without any problems and then do a fresh install from that using ext4.