Use of temporary variables in v3

[willyamcts]

In tests to make temporary blocks with setvar and expirevar I noticed that the time and the increment of the variable seem to be failing. Rules used in the test below:

SecAction "phase:1,log,initcol:ip=%{REMOTE_ADDR},id:20"

SecRule IP:BLOCK "@ge 3" "id:21,phase:1,\
  deny, log,\
  status:408,\
  msg:'Block temp: %{REMOTE_ADDR}  --> ip.block=%{IP.BLOCK}'"

SecRule RESPONSE_STATUS "@streq 404" "id:27,phase:5,\
	setvar:ip.block=+1,expirevar:ip.block=10,log,\
	msg:'Return 403 | ip.block= %{IP.BLOCK} | IP:%{REMOTE_ADDR}'"

When reaching the limit configured of 404 response (3 times == rule id:21) the variable resumes counting, the behavior does not always occur in the same way, sometimes the variable is reset to 3 times until the block is made (return 408 configured), sometimes works correctly.

The time configured in expirevar don't is respectly, this common comportment the all tests

The same rules were used successfully in version 2.

[airween]

Fyi: expirevar doesn't supported in libmodsecurity v3, it's a known issue.

[willyamcts]

Excusme, for lack attention. Very thanks

Is an equivalent directive foreseen?

[airween]

Excusme, for lack attention. Very thanks

no prob :)

Is an equivalent directive foreseen?

you may have to check this solution.

[willyamcts]

The workaround with TIME_EPOCH works, but it seems not 100%.

Using TIME_EPOCH sometimes receives a different value in the middle of the execution. See below:

Rules:

SecAction "phase:1,log,initcol:ip=%{REMOTE_ADDR},id:10"

SecRule &IP:TIME "@eq 1" \
 "id:19, phase:1, auditlog, pass, \
  msg:' NIL vars .....', \
  chain"
     SecRule IP:TIME "@lt %{TIME_EPOCH}" \
	"setvar:'!ip.block', \
	 setvar:'!ip.time'"

SecRule IP:TIME "@gt %{TIME_EPOCH}" \
 "id:20, phase:1, log, deny, status:408, \
  chain"
     SecRule IP:BLOCK "@ge 3" 
      msg:'Block temp: %{REMOTE_ADDR} -> IP.BLOCK=%{IP.BLOCK} | timestamp=%{TIME_EPOCH} | IP:TIME=%{ip.time}'"

SecRule RESPONSE_STATUS "@streq 404" "id:27,phase:5,log, \
  setvar:ip.block=+1, \
setvar:ip.time=%{TIME_EPOCH},setvar:ip.time=+30, \
  msg:'Return 404 | IP.BLOCK= %{IP.BLOCK} | IP:%{REMOTE_ADDR} | timestamp=%{TIME_EPOCH} | IP:TIME=%{ip.time}'"

audit.log:

---9T5WRNCE---A--
[26/Apr/2021:10:27:16 -0300] 1619443636 10.1.1.100 39826 test.internal 0
---9T5WRNCE---B--
GET /fail HTTP/1.1
---9T5WRNCE---F--
HTTP/1.1 408

---9T5WRNCE---H--
ModSecurity: Access denied with code 408 (phase 1). Matched "Operator `Ge' with parameter `3' against variable 
`IP:10.1.1.100::::BLOCK' (Value: `3' ) [file "/usr/local/modsecurity/custom/test.conf"] [line "11"] [id "20"] 
[rev ""] [msg "Block temp: 10.1.1.100 -> IP.BLOCK=3 | timestamp=1619443636 | IP:TIME=1619443653"] 
[data ""] [severity "0"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "test.internal"] [uri "/fail"]
[unique_id "1619443636"] [ref ""]

---9T5WRNCE---I--

---9T5WRNCE---J--

---9T5WRNCE---Z--

---9ClZx7p8---A--
[26/Apr/2021:10:27:17 -0300] 1619443637 10.1.1.100 39828 test.internal 0
---9ClZx7p8---B--
GET /fail HTTP/1.1

[....]

---9ClZx7p8---F--
HTTP/1.1 404

---9ClZx7p8---H--
ModSecurity: Warning. Matched "Operator `Lt' with parameter `1619443637' against variable `IP:10.1.1.100::::TIME' (Value: 
`1619443526' ) [file "/usr/local/modsecurity/custom/test.conf"] [line "4"] [id "19"] [rev ""] [msg " NIL vars ....."] 
[data ""] [severity "0"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "test.internal"] [uri "/fail"] 
[unique_id "1619443637"] [ref ""]
ModSecurity: Warning. Matched "Operator `StrEq' with parameter `404' against variable `RESPONSE_STATUS' (Value: `404' ) 
[file "/usr/local/modsecurity/custom/test.conf"] [line "18"] [id "27"] [rev ""] [msg "Return 404 | IP.BLOCK= 1 | IP:10.1.1.100 | 
timestamp=1619443637 | IP:TIME=1619443667"] [data ""] [severity "0"] [ver ""] [maturity "0"] [accuracy "0"] [hostname 
"test.internal"] [uri "/fail"] [unique_id "1619443637"] [ref "v362,3"]

Note that in first request IP.TIME '1619443653' was assigned with the current timestamp: 1619443636, 1 second later another request is made and the variable IP.TIME is set to '1619443526' (2 minutes less than the correct time) and enters the rule id:19. I also noticed that making multiple requests followed in a short period of time sometimes IP.TIME alternates, with about 5 seconds of difference from the true value.

[airween]

@zimmerle are you sure you wanted to assign this for me?

[zimmerle]

@zimmerle are you sure you wanted to assign this for me?

Since you have commented on the issue, I assumed that you are interested in providing a solution.

[martinhsv]

This appears to be a duplicate of #1803 .

Closing ...