IPS prevents backup with VEEAM

Hello all,

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.

Router: 10.10.1.1
PC: 10.10.1.10

Regards Paul

I see a few nice hints (see your yellow highlights)!

Go into the IPS screen under Ruleset (date and time). Look for the ET Exploit ruleset and click Show:

Now look for the highlighted Name is the long list

ET EXPLOIT Possible OpenSSL HeartBleed Large HeartBeat Response (Server Init Vuln Client).

And then uncheck it and Save it.

EDIT: This is up to you if you want to disable this ruleset…

1 Like

FWIW - I just looked at my IPS log and I see the same errors. All of them are internal-to-internal connection. And all of them are Macs.

Date: 11/29 12:11:22
Name: ET EXPLOIT Possible OpenSSL HeartBleed Large HeartBeat Response (Client Init Vuln Server)
Priority: 2
Type: Potentially Bad Traffic
IP Info: 192.168.60.20:445 -> 192.168.65.111:56823
SID: 2018377
Refs: 

Date: 11/29 12:10:50
Name: ET EXPLOIT Possible OpenSSL HeartBleed Large HeartBeat Response (Server Init Vuln Client)
Priority: 2
Type: Potentially Bad Traffic
IP Info: 192.168.65.111:56823 -> 192.168.60.20:445
SID: 2018378
Refs: 

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.

  1. ET EXPLOIT Possible OpenSSL HeartBleed Large HeartBeat Response (Server Init Vuln Client)
  2. ET EXPLOIT Malformed HeartBeat Request
  3. GPL ATTACK_RESPONSE id check returned root
  4. ET CURRENT_EVENTS [Fireeye] POSSIBLE HackTool.TCP.Rubeus.[User32LogonProcesss]
  5. ET EXPLOIT Possible OpenSSL HeartBleed Large HeartBeat Response (Client Init Vuln Server)
  6. ET SCAN DCERPC rpcmgmt ifids Unauthenticated BIND
  7. GPL WEB_SERVER 403 Forbidden
  8. 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?

this is over my head! Hopefully someone will add their comments!

Hi all,

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.

Thanks, and best regards,
Peter Müller

1 Like