this is a misunderstanding then: “Activated rules” refers to triggered rules (sometimes also called “rule hits”) here. You can check whether your IPS is actually working by trying to trigger rules manually (such as conducting a portscan), or executing this command on a machine behind IPFire:
curl http://testmyids.com/
If you enabled the emerging-attack_response.rules category, you should see a hit afterwards. Should your IPFire be connected to the internet directly, you should see tons of IPS rules triggered within a short time (usually less than a minute).
The IPFire is locate behind a Telekom router. And I never had any activities at all in the log. Tried the following from a PC behind the IPFire but also nothing in the log:
Anyhow not all rules under ‘emerging-attack_response.rules’ are activated by default when I check it.
oh, so you either have a very clean network, or the IPS did not detect anything.
Ah yes, apparently, this service moved to HTTPS now, which the IPS cannot intercept. This is why the string you get in return does not trigger anything anymore.
To provoke an IDS hit, could you try a portscan instead?
nmap -v -A [destination]
should be sufficient if the emerging-scan.rules category is enabled.
Yes, this is intended. Not all rules are enabled by default. IPFire does not interfere here, the provider of IPS rules chooses whether they come enabled or disabled.
If you activate the DMZ Host on the Router so that all internet requests are sent to the WAN interface of the IPFire, you will see the amount that reaches you.