I am having difficulty with the functionality of “Whitelisted Hosts” in the IPS. For example, IPS rules are triggered for ICMP *NIX and show 2 IP addresses. If I enter these IP addresses as Whitelisted Hosts, the rule still triggers and the traffic is dropped/blocked - I would have expected this traffic to now be allowed. To allow the traffic I have to disable the rule. Has anyone else had issues like this or can offer any suggestions? Note that one of the addresses is the Green interface of IPFire itself ie I’m trying to ping IPFire from a linux box.
Hi @briand
I seem to recall a similar issue on core 161 which was blocking Covid-19 related traffic. I had set up a whitelist of ip addresses the official sites that i needed to connect to, and appeared to not work at first.
However, if i recall correctly (memory not so good 
, I believe that after doing a Apply Change to the firewall rules (not full sure about that step), i did do a reboot and the changes appear to have worked.
Hi,
that was probably due to some hunting rules - I remember those triggering on some of my installations as well… 
It looks like we should really clarify in the documentation if the whitelist refers to the source of a connection, the destination, or both. To be honest, I am not sure about that myself currently… 
Will check and report back.
Thanks, and best regards,
Peter Müller
Thanks guys - I have tried source, destination and both. Will investigate further and try a reboot. If it is a host do I simply enter the ip address or do I need a /32 at the end ?
Not sure about the subnet masking (eg /32).
In my case i was just entering the IP addresses of the websites my browser was trying to access (aka destinations).
Hi,
first, sorry for my tardy reply on this.
Adding /32 is not necessary for whitelisting a single IP address.
Generally speaking, it is currently not possible to ignore a certain IPS rule for certain IP addresses. We discussed implementing this in February, but it’s not an easy job to do, and resources are currently needed elsewhere.
Therefore, I am afraid you will either have to disable the IPS rule completely, or whitelist the client triggering it for the entire IPS.
Sorry to disappoint, and best regards,
Peter Müller
Therefore, I am afraid you will either have to disable the IPS rule completely, or whitelist the client triggering it for the entire IPS.
For clarification, does this mean a DESTINATION address may not be whitelisted currently?
That would explain some behaviour I’m currently troubleshooting.
Hi,
unfortunately, yes.
A fix is already available but requires some more QA, so it will be included in Core Update 168 (Core Update 167 is scheduled for release tomorrow).
Sorry for all the inconvenience, and best regards,
Peter Müller
Hi @pmueller, I would like to close the loop on this topic.
It appears now on Core 169 that a whitelisted IP address (in my case a public destination IP address on the internet) is indeed bypassing all Suricata scanning, which would be expected yes?
Hi Josh, no not a public IP,
I think a whitelisted IP address is your local IP address, example 192.168.1.2 or 10.0.2.2 etc…
Basicaly, if Suricata is blocking your PC or device you can just bypass ALL Suricata rules for that PC, device, client etc
If you are familiar with firewalls, it is sort of like putting a local IP in a “DMZ”
Appreciate the response trish. What I’m seeing that led to my post, is that right now if I have a connection that is not ‘allow listed’ I see Suricata consuming a reasonable % of CPU when I stress that connection.
After allow listing, the CPU load to that connection goes away.
This is all positive from my perspective as it’s the desired behaviour.