Big files transfer failed with IPS (Suricata)

[jfou1987]

Hello,

Sorry if this issue was already discussed, but i didn't found any relative topics.
I activate IPS 2 weeks ago because i discovered some MAP scan on my OPNWAF, and decide to block them.

From them i discovered an issue. Now i'm sure it's relative to IPS, because when i disable it, this issue gone away.

Last week, i started to download a 2,9 Gb video file with SwissTransfer in Chrome (HTTPS) and the transfer stay at 99,9%. Never complete.
I suspected a file issue because i downloaded an other video file minutes before, but only 10Mo.

Yesterday for the second time, an automated FTP download script failed at the end of the download.
I can reproduce the error with the same file in FileZila, on an other computer, but behind the same OPNsense.

After doing some search i can now affirm that IPS is responsible for that. My discoveries told me there is a TCP time session/file size relative to the IPS paquet analyze.

I tried to change the detection profile to high (recommended by IA)
I only monitor WAN interfaces, no Promiscuous mode, i disable all hardware offloading.
Now i cannot find a workaround.

Do you have any idea for me ?

[meyergru]

Patient: "Doctor, it always hurts when I do this..."
Doctor: "Then do not do it."

Any mechanism that is designed to block certain things can also block other things that you did not want it to.  That is why there is a recommendation to start with IDS, not IPS mode.

You can inspect your Suricata logs to find the culprit and maybe disable the offending rule when it pops up. There are plenty to choose from....

[jfou1987]

Hello, thanks for reply. Of course, i started with IDS for few month, only some Zmap alerts, that's why i enable IPS.
There is no alert regarding this particular issue. That's why, it's strange.

The AI told me it need a bypass rule for large files or to adapt Stream Reassembly or depth or memcap.
And also told me this is relative to the engine of Suricata, not to a rule.
But as far as i know, editing the yaml file is not persistent to a reboot.

Do you have any idea ?

[meyergru]

No, as personally I do not believe in such tools and I do not use them, see https://forum.opnsense.org/index.php?topic=42985, point 13. Maybe you can change the pattern matcher or the capture mode.

For starters, it seems to be the wrong approach to monitor the WAN interface. Also, Suricata, when applied to the WAN interface, breaks IPv6, see the same link.

[jfou1987]

Thanks for your reply. Maybe i should specify my intention.
I tried to add an extra level of protection for the external traffic goes into the LAN traffic.
To be clear, i have a business licence for our DEC4240, and i've got an OPNWAF service for an internal tool, working on PHP/laravel.
I now the WAF already achieve a good protection.

I also have 2 others computers (isolated in a DMZ subnet) which can be contacted thru an inbound NAT rule.

I had setup the IDS for some month, and after download some recommanded rules, enable some.
I discovered in the alert tab, there is a Zmap scan alert, about twice a day to the WAF appliance.
I enable IPS, and change the behaviour to block those scans.

That's why i enabled the WAN interface.

To be honest the IDS/IPS is a kind of something complex to me. Maybe i don't need the IDS/IPS.
It's maybe an overkill protection with both firewalling and the IPS on the same inbound way.
Maybe just need the IPS for the inbound to outbound traffic ?

I already read the provided manual, to setup the OPNsense and to understand the particular concepts.
We don't use IPv6, either on WAN or LAN sides

If you have something to clear my mind :-)
Thank you

[sopex8260]

Is Suricata processing encrypted traffic? I mean you are probably exceeding the memory limit of suricata but I have never seen it happen with encrypted traffic.

[jfou1987]

Is Suricata processing encrypted traffic? I mean you are probably exceeding the memory limit of suricata but I have never seen it happen with encrypted traffic.

Maybe ... but i don't know how to handle this.
It happend on a simple HTTPS Swisstransfer, but the issue also happening with a simple FTP passive transfer. Not crypted.