ModSecurity collection expirevar does not work

[sobigboy]

When I use collection 'IP', the variable in collection never expire even if I restart nginx.
The variable in collecion expired unless I remove the files:modsec-shared-collections modsec-shared-collections-lock in disk,

[ghost]

@sobigboy how do you get the values of modsec-shared-collections modsec-shared-collections-lock in disk, i tried it in dos-attack and dos run well , but i can't get the attack-ip values or timestrap;

[jptosso]

Hello, any update on this? I have been testing and the collection file under /modsec-shared-collections is not being expired according to expirevar nor SecCollectionTimeout.
I'm using --with-lmdb because the standard method would destroy each collection on reload.

[airween]

Not yet - but I'll see that soon.

[theseion]

Meanwhile here's a workaround for everyone who needs DOS protection to work. The hack uses dedicated variables in conjunction with the TIME_EPOCH variable to explicitly expire the DOS variables.

REQUEST-912-DOS-PROTECTION.conf.txt

[Hello-Linux]

The document you provided really works. But if I change the browser I'll have normal access the web server So I think this disabling policy is only for the combination of the browser and the IP address and not for the IP address alone I feel the authorities should fix this problem or adopt your document @theseion

[theseion]

Good to hear that, thanks.
As for switching browsers: that shouldn't make a difference. AFAICT, only the IP is considered for the blocking logic. Are you sure that you don't have a proxy configured in one of those browsers?

[pixelicous]

The solution posted by @theseion above didn't help in my case. Added it to my already existing file, restart the server. Tested on a browser that was available before (which is weird in the first place, one browser got blocked while the other was available), now none of my browsers are available now unless restarting server

Supposed to block remote ips based on getting 404 more than 3 times, for 60secs

SecAction "phase:1,initcol:ip=%{REMOTE_ADDR},id:'123456'"
SecRule RESPONSE_STATUS "@streq 404" "phase:3,pass,setvar:ip.block_script=+1,expirevar:ip.block_script=60,id:'1234567'"
SecRule IP:BLOCK_SCRIPT "@ge 3" "phase:2,deny,status:403,id:'12345678'"

[theseion]

@pixelicous Sorry, this is very late.

You're using expirevar, which does not work (at least it didn't when I wrote the workaround). Make sure to do everything as it's done in the workaround because there are a couple of things that matter (e.g. casing, phase order).

[liusir-ht]

Hello,@pixelicous I met the same problem. Has this problem been solved?

[ccl123456789012]

使用了提供的REQUEST-912-DOS-PROTECTION.conf.txt，发现一个问题某个ip访问被判断为ddos，应该会封禁该ip一个小时但是偶尔还是可以该网站

[tomsommer]

Can we please have this fixed? It's pretty critical as it breaks all collections?

[martinhsv]

There is an implementation for this support here: https://github.com/SpiderLabs/ModSecurity/tree/v3/dev/action_expirevar

There will be at least a short delay before it is merged.

[theseion]

Thanks @martinhsv! It will be a good day when this feature is release.

[sharmashivanand]

@theseion When I implement the workaround, it clashes with inbound anomaly score. (Also can we pls create a separate thread to help with this workaround?)

Matched "Operator Ge' with parameter 10' against variable TX:BLOCKING_INBOUND_ANOMALY_SCORE' (Value: 10' )

I'm using [ver "OWASP_CRS/4.0.0-rc1"] on nginx.

[theseion]

The version I wrote was for CRS 3.0.1. I do not have a working version for 4.0 and seeing as it will (hopefully) be a non-issue soon, the plugin implementation we created for CRS v4 for ModSecurity v2 should work for v3 as well, when expirevar works: https://github.com/coreruleset/dos-protection-plugin-modsecurity-v2.

[martinhsv]

This has now been merged.

[tomsommer]

Thank you for your work 🥇