I enabled all other interfaces on ipFire ( IPFire 2.27 (x86_64) - Core Update 161) in addition to the Red Interface in the “Intrusion Prevention System” section over the weekend.
My problem:
I have set up Samba on the ipFire and on my PC I run a backup using the VEEAM Backupagent for Windows which writes the data to the Samb Share at the router.
Unfortunately, the backup job now always aborts since I enabled IPS and I have this entry in the logs.
I have now adjusted the displayed rule sets of ISP but every time I deactivated one, a new message or rule set came up that struck.
I have now deactivated 8 rulesets and I’m starting to have doubts.
I have also implemented a VM with Nextcloud on the ipFire via QEMU and forward all traffic on port 443 to Nextcloud. I am now concerned that disabling some rulesets will increase the attack surface on my cloud externally.
Here are the rulesets I disabled one by one and still the VEEAM backup does not work.
ET EXPLOIT Possible OpenSSL HeartBleed Large HeartBeat Response (Server Init Vuln Client)
ET EXPLOIT Malformed HeartBeat Request
GPL ATTACK_RESPONSE id check returned root
ET CURRENT_EVENTS [Fireeye] POSSIBLE HackTool.TCP.Rubeus.[User32LogonProcesss]
ET EXPLOIT Possible OpenSSL HeartBleed Large HeartBeat Response (Client Init Vuln Server)
ET SCAN DCERPC rpcmgmt ifids Unauthenticated BIND
GPL WEB_SERVER 403 Forbidden
ET CURRENT_EVENTS [Fireeye] Backdoor.HTTP.GORAT.[Build ID]
I have now re-enabled the rules and set my PC with its IP address as an exception.
Conclusion:
The backup still fails although the IP is stored but no entries are visible in the ISP log.
I had to deactivate ISP to GREEN so that the backup works again and am somehow not happy about this procedure.
Why does the backup still fail and no logs appear even though the IP is set as an exception?
to me, this situation appears to be caused by two factors:
The HeartBleed-related ET rules sometimes cause false positives; I usually observe such on IPFire machines running an OpenVPN server on TCP port 443, but they appear only sporadically. Clients being fault-tolerant to packet loss should not have issues in this case.
The backup application appears to do TLS in a non-optimal fashion, hence triggering rules such as “ET EXPLOIT Malformed HeartBeat Request”. Standard-compliant TLS clients/servers do not cause them - perhaps the vendor uses a proprietary and/or crappy TLS implementation in this product.
The combination of this results in the backup application not being functional.
In addition, it is important to understand not all IDS rules make sense. For example, “GPL WEB_SERVER 403 Forbidden” just triggers on HTTP error code 403 showing up, which is beyond stupid and unusable in productive environments. Just a HTTP 403 error code almost never indicates an ongoing attack.
It is worth mentioning that the “GPL *”-rules are generally of a lower quality - I’d leave them disabled in a first step and in productive environments.
I have now deactivated 8 rulesets and I’m starting to have doubts.
The process you are unwillingly undergoing is called “baselining”, and is unfortunately necessary in almost any scenario where an IDS/IPS is being in place. This might be a bit tedious, but is nothing to worry about.
Why does the backup still fail and no logs appear even though the IP is set as an exception?
@ms recently discovered a bug in Suricata where some connections are not being processed properly (see this commit for technical details). You may or may not be affected by this bug - in case you are, the upcoming Core Update 162 should fix it.
I have tested IPS again today with the Core 166 also on the green network. Unfortunately, despite the exception of the IP of my computer, the backup via VEEAM fails.
Why is the IP address of my PC still blocked by IPS?
