Help request about Log4j attack attempts and NGINX logs meaning
lists at lazygranch.com
Thu Dec 30 09:20:27 UTC 2021
This is the list of effected programs.
From: maxim at nginx.com
Sent: December 29, 2021 11:21 PM
To: mauro.tridici at cmcc.it
Reply-to: nginx at nginx.org
Cc: nginx at nginx.org
Subject: Re: Help request about Log4j attack attempts and NGINX logs meaning
Unless you use somewhere in your stack log4j vulnerable software (nginx
is not) I don't see anything significant to worry about.
On 29.12.2021 21:34, Mauro Tridici wrote:
> 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,
>> On 29 Dec 2021, at 19:29, Maxim Dounin <mdounin at mdounin.ru> wrote:
>> 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”
>>> Rule: 100205 fired (level 12) -> "Log4j RCE attack attempt
>>> Src IP: 184.108.40.206
>>> Portion of the log(s):
>>> 220.127.116.11 - - [28/Dec/2021:21:45:58 +0100] "GET
>>> 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
>> nginx mailing list
>> nginx at nginx.org
> nginx mailing list
> nginx at nginx.org
nginx mailing list
nginx at nginx.org
More information about the nginx