Re: Is this an attack or a normal request?
I've seen the rest of this thread, and there are many good ideas, fail2ban is great, i actually use it with wazuh. The best security measure i ever made with wordpress is changing the name of the /admin/login.php and disabling or at least access listing the api. If no one needs api access, shut it off. With fail2ban with wazuh, perhaps fail2band handles this on its own, you can set up volume rules which will create FW rules. Also, i like to put in a snippit into nginx config for to many responses. limit_req_zone $limit_key zone=req_limit:10m rate=10r/s; limit_req_log_level warn; # don't use 503 as we have specific logic for that status limit_req_status 420; As the comment says we handle 503's and other status codes differently, so i adopted Twitters Ease You Calm status code. Change the limits to your environment. On Mon, Aug 24, 2020 at 7:23 AM Anderson dos Santos Donda < andersondo...@gmail.com> wrote: > Hello everyone, > > I’m new in the webserver world, and I have a very basic knowledge about > Nginx, so I want apologize in advance if I'm making a stupid question. > > I have a very basic webserver hosting a WordPress webpage and in the past > 3 days I have receiving thousands of below request: > > 5.122.236.249 - - [24/Aug/2020:12:30:41 +0200] > "\x1E\x80\xEBol\xDF\x86z\x84\xA4A^\xAF;\xA1\x98\x1B\x0E\xB7\x88\xD3h\x8FyW\xE4\x0F=.\x15\xF7f:9\xF7\xC3\xBB\xB1}n\xA5\x88\x8B\xE7\xF4\x5C\x80\x98=\xE2X\xC8\xD4\x1Bv/\xDC3yAI\xEE\xE6\xFA\xB1\xF3\x90]\x9EG\xFD\x9B\xAB\x9B:\xA7q\x82*\xE1:\x1A > 5.122.236.249 - - [24/Aug/2020:12:30:41 +0200] "P\xCE > \x9C\xA9\xB6pS\xD6#1\x84\x22\xB0s\xB8\xAA\x09\x06Ex\xDD\x88\x11\xFC\x0E\xDB\x04\x18~*\xE7h\xD2H\xD422\x83,\xB3u\xDF|\xED\x8BP\x9Box\xA4\x042\xFBz\xAAh\xF9\x14^\x96\xDD\x1D\xF6\xDD*\xF4" > 400 173 "-" "-” > > This comes from a hundred of different IPs and in many requests at same > time. > > Is this kind of DDOS attack or a legitimate request(which my server > returns 400 for them)? > > If is an attack, has a specific name that I can search and try to > understand it better and mitigate it? > > Thank so much for the help. > > Best Regards, > Donda > > > -- > Att. > Anderson Donda > > *" **Mar calmo não cria bom marinheiro, muito menos bom capitão.**"* > > > ___ > 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
Re: Cache Volume utilized at around 50 % with proxy_cache_min_uses
> Given the above, I see two possible reasons why the cache volume > is only filled at 50%: > > 1. You've run out of keys_zone size. > > 2. You've run out of resources requested frequent enough to be > cached with proxy_cache_min_uses set to 2. > > It should be easy enough to find out what happens in your case. > It seems possible reason is keys_zone size. Will look into by increasing the same and trying different permutations. As in general 1M stores around 8000 Keys, what could be probable formula for keys_zone size with proxy_cache_min_uses. Since it keeps information of all requested resource so it would highly depend upon number of requested resources. In my case number of request per sec is around 1000 i.e. 36 Lakhs per hour during peak hours Posted at Nginx Forum: https://forum.nginx.org/read.php?2,289185,289189#msg-289189 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Cache Volume utilized at around 50 % with proxy_cache_min_uses
Hello! On Tue, Aug 25, 2020 at 07:41:43AM -0400, anish10dec wrote: > With use of proxy_cache_min_uses volume of cache is getting settled up at > around 50% utilization. > No matter what is the volume allocated in max_size its not filling up > further beyond 50%. > If the proxy_cache_min_uses is removed the cache gets filled up with > max_size allocated volume. > > No of files in cache directory is far less beyond the size allocated in key > zone. Its getting capped up near 20 Lakhs whereas allocated key zone could > have accommodate around 80 L files with below configuration It is important to understand that number of files in the cache directory is not directly related to the keys zone size when using proxy_cache_min_uses. Instead, when using proxy_cache_min_uses, keys zone needs to keep information about all resources requested, to correctly trac usage numbers, and this usually much higher than the number of files saved to disk. This is what proxy_cache_min_uses does: it saves disk space and disk bandwidth by tracking information only in the keys zone. Given the above, I see two possible reasons why the cache volume is only filled at 50%: 1. You've run out of keys_zone size. 2. You've run out of resources requested frequent enough to be cached with proxy_cache_min_uses set to 2. It should be easy enough to find out what happens in your case. -- Maxim Dounin http://mdounin.ru/ ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
[njs] Fixed function "constructor" property handler while setting.
details: https://hg.nginx.org/njs/rev/85bfd770a3da
branches:
changeset: 1501:85bfd770a3da
user: Dmitry Volyntsev
date: Mon Aug 24 11:28:21 2020 +
description:
Fixed function "constructor" property handler while setting.
diffstat:
src/njs_function.c | 3 +--
src/njs_object.c | 38 +-
src/njs_object.h | 2 +-
3 files changed, 27 insertions(+), 16 deletions(-)
diffs (93 lines):
diff -r 775c81dcbe61 -r 85bfd770a3da src/njs_function.c
--- a/src/njs_function.cFri Aug 21 13:07:54 2020 +
+++ b/src/njs_function.cMon Aug 24 11:28:21 2020 +
@@ -853,8 +853,7 @@ njs_function_prototype_create(njs_vm_t *
if (setval == _value && njs_is_object(proto)) {
/* Only in getter context. */
-cons = njs_property_constructor_create(vm, njs_object_hash(proto),
- value);
+cons = njs_property_constructor_set(vm, njs_object_hash(proto), value);
if (njs_slow_path(cons == NULL)) {
return NJS_ERROR;
}
diff -r 775c81dcbe61 -r 85bfd770a3da src/njs_object.c
--- a/src/njs_object.c Fri Aug 21 13:07:54 2020 +
+++ b/src/njs_object.c Mon Aug 24 11:28:21 2020 +
@@ -2216,6 +2216,22 @@ njs_object_prototype_create_constructor(
njs_object_t*object;
njs_object_prototype_t *prototype;
+if (setval != NULL) {
+if (!njs_is_object(value)) {
+njs_type_error(vm, "Cannot create propery \"constructor\" on %s",
+ njs_type_string(value->type));
+return NJS_ERROR;
+}
+
+cons = njs_property_constructor_set(vm, njs_object_hash(value),
setval);
+if (njs_slow_path(cons == NULL)) {
+return NJS_ERROR;
+}
+
+*retval = *cons;
+return NJS_OK;
+}
+
if (njs_is_object(value)) {
object = njs_object(value);
@@ -2231,8 +2247,6 @@ njs_object_prototype_create_constructor(
} while (object != NULL);
-njs_thread_log_alert("prototype not found");
-
return NJS_ERROR;
} else {
@@ -2242,23 +2256,21 @@ njs_object_prototype_create_constructor(
found:
-if (setval == NULL) {
-njs_set_function(, >constructors[index]);
-setval =
+njs_set_function(, >constructors[index]);
+setval =
+
+cons = njs_property_constructor_set(vm, >object.hash, setval);
+if (njs_slow_path(cons == NULL)) {
+return NJS_ERROR;
}
-cons = njs_property_constructor_create(vm, >object.hash,
setval);
-if (njs_fast_path(cons != NULL)) {
-*retval = *cons;
-return NJS_OK;
-}
-
-return NJS_ERROR;
+*retval = *cons;
+return NJS_OK;
}
njs_value_t *
-njs_property_constructor_create(njs_vm_t *vm, njs_lvlhsh_t *hash,
+njs_property_constructor_set(njs_vm_t *vm, njs_lvlhsh_t *hash,
njs_value_t *constructor)
{
njs_int_t ret;
diff -r 775c81dcbe61 -r 85bfd770a3da src/njs_object.h
--- a/src/njs_object.h Fri Aug 21 13:07:54 2020 +
+++ b/src/njs_object.h Mon Aug 24 11:28:21 2020 +
@@ -63,7 +63,7 @@ njs_int_t njs_object_prototype_proto(njs
njs_int_t njs_object_prototype_create_constructor(njs_vm_t *vm,
njs_object_prop_t *prop, njs_value_t *value, njs_value_t *setval,
njs_value_t *retval);
-njs_value_t *njs_property_constructor_create(njs_vm_t *vm, njs_lvlhsh_t *hash,
+njs_value_t *njs_property_constructor_set(njs_vm_t *vm, njs_lvlhsh_t *hash,
njs_value_t *constructor);
njs_int_t njs_object_prototype_to_string(njs_vm_t *vm, njs_value_t *args,
njs_uint_t nargs, njs_index_t unused);
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Connection timeout on SSL with shared hosting
Turned out there was an INPUT DROP rule in iptables (but not in ip6tables), although I am using ufw as a firewall. Now https works and my nginx redirects are functioning as expected! Posted at Nginx Forum: https://forum.nginx.org/read.php?2,289099,289186#msg-289186 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Cache Volume utilized at around 50 % with proxy_cache_min_uses
With use of proxy_cache_min_uses volume of cache is getting settled up at around 50% utilization. No matter what is the volume allocated in max_size its not filling up further beyond 50%. If the proxy_cache_min_uses is removed the cache gets filled up with max_size allocated volume. No of files in cache directory is far less beyond the size allocated in key zone. Its getting capped up near 20 Lakhs whereas allocated key zone could have accommodate around 80 L files with below configuration proxy_cache_path/cache/contentcache keys_zone=content:1000m levels=1:2 max_size=1000g inactive=7d use_temp_path=off; proxy_cache_min_uses 2; Cache volume is utilized with above configuration is around 550 GB which is not growing beyond and as inactive is set to 7d so this would have been effective only after 7 days when content should have got deleted if not accessed within 7 days time period. Writing all the objects on disk is causing high i/o so using proxy_cache_min_uses would have been beneficial with utilizing cache optimally and high cache hit ratio Posted at Nginx Forum: https://forum.nginx.org/read.php?2,289185,289185#msg-289185 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Connection timeout on SSL with shared hosting
Thanks so much, Francis Daly! This is a huge help in isolating the problem. Based on the nginx access log, IPv6 requests to port 443 are getting to nginx but IPv4 requests to port 443 are not. But they are getting to tcpdump. All I see there is a bunch of packets with the tcpflag [S]. I take it this means the handshake is not completing. It was easy to confirm this by turning off IPv6 in my browser, at which point https stopped resolving for the site in the browser but I could see the packets coming in on tcpdump. So presumably some sort of firewall on the local server machine--probably one I didn't configure or know about! I'll try to figure out how to find that blockage. In any case, apparently not an nginx issue, as you rightly perceived. Thanks again for the help! Nathan Posted at Nginx Forum: https://forum.nginx.org/read.php?2,289099,289184#msg-289184 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Is this an attack or a normal request?
You don't need fail2ban to limit html verbs. I only allow "get" and "head" on mine. Inside the Nginx server block:if ($request_method !~ ^(GET|HEAD) $) {return 444;GET and HEAD is all you need for a read only site. I have a map set up for bad user agents. There is a search engine called Majestic that will download your website on a daily basis. It does not obey robots.txt.https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/blob/master/_generator_lists/bad-user-agents.listSince Nginx will be using regular expressions, some of these are redundant. If you look for majestic then you don't need to look for majestic12. You really should study maps since that is the most efficient means to implement these pattern searches. From: andersondo...@gmail.comSent: August 24, 2020 10:53 PMTo: nginx@nginx.orgReply-to: nginx@nginx.orgSubject: Re: Is this an attack or a normal request? Thank you very much. Everyone!I will try to implement all the insithgts given.With desperate times come desperate measures, and I implemented a fail2ban that block any IP that doesn't have any GET or POST in the request.It is not efficient, I know. My firewall list is growing abruptly but, at least, it buys me some time to improve the all counter-measure that you guys meantionated.BR,DondaOn Mon, Aug 24, 2020 at 9:18 PM Peter Booth wrote:I agree with the advice already given
It can also be useful to track the User-Agent header of web requests - both to understand who is trying to do what to your website,
and then to start blocking on the basis of user agent.
There may be some bots and spiders that are helpful or even necessary for your business.
Peter
> On Aug 24, 2020, at 2:54 PM, lists wrote:
>
> I can't find it, but someone wrote a script to decode that style of hacking. For the hacks I was decoding, they were RDP hack attempts. The hackers just "spray" their attacks. Often they are not meaningful to your server.
>
> I have Nginx maps set up to match requests that are not relevant to my server. For instance I don't run WordPress, so anything WordPress related gets a 444 response. On a weekly basis I pull all the IP addresses that generated a 400 or 444 and run them through a IP lookup website. If they come back to a hosting company, VPS, or basically anything not an ISP, I block the associated IP space via my firewall. The only reason I can do this weekly is I have blocked so much IP space already that I don't get many hackers.
>
> At a minimum I suggest blocking all Amazon AWS. No eyeballs there, just hackers. Also block all of OVH. You can block any of the hosting companies since there are no eyeballs there. This blocks many VPNs as well but nobody says you have to accept traffic from VPNs.
>
> Firewalls are very CPU efficient though they do use a lot of memory. In the long run blocking all those hackers improves system efficiency since nginx does have to parse all that nonsense.
>
> I have scripts to pull the hacker IP out of the log file but a have a nonstandard log format. If you can create a file of IPs, this site will return the domains:
>
> https://www.bulkseotools.com/bulk-ip-to-location.php
>
> If you see a domain that is obviously not an ISP, you can find their entire IP space using bgp.he.net
>
> This sounds more complicate than it is. I have it down to about 20 minutes a week.
>
> You can also block countries in the firewall. Some people block all of China. I don't but that does cut down on hackers.
>
>
>
> Original Message
>
>
> From: themadbea...@gmail.com
> Sent: August 24, 2020 11:06 AM
> To: nginx@nginx.org
> Reply-to: nginx@nginx.org
> Subject: Re: Is this an attack or a normal request?
>
>
>> Is this kind of DDOS attack or a legitimate request(which my server returns
>> 400 for them)?
>
> That's typically how various unicode characters are hex encoded. If
> you aren't expecting that kind of input, then yes it is likely an
> attack (probably trying to exploit an unknown specific piece of
> software). Welcome to the internet where everything connected is
> bombarded 24/7 from everything else with random attacks.
>
> That's why it's important to keep your server (and wordpress) up to date.
> ___
> 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
-- Att.Anderson Donda" Mar calmo
