3

My AWS Elastic Beanstalk server is often reporting Environment health has transitioned from Ok to Severe. 100.0 % of the requests are erroring with HTTP 4xx. This happens almost daily for a few minutes at a time. I also found the logs below in my ngnix error logs. What are these? Are they some kind of DOS attack? I looked up the ip addresses of a few of them and found that they're coming from an Amazon data center. If this is something I'd rather prevent, is there a way to do so without blocking traffic to legitimate users?

The server health and the timestamps on these errors do not seem to correspond.

> 2019/07/31 16:53:51 [error] 26340#0: *242697 client intended to send
> too large body: 4294967295 bytes, client: 172.31.12.183, server: ,
> request: "GET /msdn.cpp HTTP/1.1", host: "35.183.225.3" 2019/08/01
> 01:45:12 [error] 26340#0: *250681 client intended to send too large
> body: 4294967295 bytes, client: 172.31.30.80, server: , request: "GET
> /msdn.cpp HTTP/1.1", host: "35.182.179.84" 2019/08/08 13:18:17 [error]
> 26340#0: *414178 client intended to send too large body: 4294967295
> bytes, client: 172.31.12.183, server: , request: "GET /msdn.cpp
> HTTP/1.1", host: "35.183.225.3" 2019/08/08 16:12:57 [error] 26340#0:
> *416902 client intended to send too large body: 4294967295 bytes, client: 172.31.30.80, server: , request: "GET /msdn.cpp HTTP/1.1",
> host: "35.182.179.84" 2019/08/19 20:38:21 [error] 26340#0: *662525
> client intended to send too large body: 4294967295 bytes, client:
> 172.31.12.183, server: , request: "GET /msdn.cpp HTTP/1.1", host: "35.183.225.3" 2019/08/20 04:01:45 [error] 26340#0: *669529 client
> intended to send too large body: 4294967295 bytes, client:
> 172.31.30.80, server: , request: "GET /msdn.cpp HTTP/1.1", host: "35.182.179.84" 2019/09/17 08:16:14 [error] 26340#0: *1282762 client
> intended to send too large body: 4294967295 bytes, client:
> 172.31.12.183, server: , request: "GET /msdn.cpp HTTP/1.1", host: "35.183.225.3" 2019/09/17 11:22:36 [error] 26340#0: *1285562 client
> intended to send too large body: 4294967295 bytes, client:
> 172.31.30.80, server: , request: "GET /msdn.cpp HTTP/1.1", host: "35.182.179.84" 2019/09/24 16:37:53 [error] 26340#0: *1442933 client
> intended to send too large body: 4294967295 bytes, client:
> 172.31.12.183, server: , request: "GET /msdn.cpp HTTP/1.1", host: "35.183.225.3" 2019/09/24 23:22:03 [error] 26340#0: *1449079 client
> intended to send too large body: 4294967295 bytes, client:
> 172.31.30.80, server: , request: "GET /msdn.cpp HTTP/1.1", host: "35.182.179.84"
  • More likely to be a misconfigured server trying to request a resource from a hardcoded IP that is now attacked to your server. – schroeder Nov 14 '19 at 15:49
  • The two things are probably unrelated. That is a 4Gigabyte file, but it was rejected by Nginx, and based on the error message it was probably rejected before the file was sent. It could be that you have your max upload size set to a very large but slightly smaller number, in which case these requests might have eaten up a lot of network bandwidth before being killed, but probably they were killed at the beginning without causing much trouble. – Conor Mancone Nov 14 '19 at 16:32
3

AFAICS don't worry.


This seems to be an Attack which does not affect NginX. Also I do not think this is a targeted attack, as I can see similar requests on my webservers, too. Hence it looks like some of those automated vulnerability scans to exploit something somewhere.

GET requests do not have a body, so a content-length of -1 is for representation selection. So this were just some small GET requests and not the indication, that somebody tried to upload 4 GB to your site.


For GET this type of request does not mean "I want to send you a 4294967295 bytes body", instead it is the request for "please answer me with 4294967295 bytes", which your server apparently declined.

Also 4294967295 is 0xffffffff or -1 for 32-bit signed integer, so on 32 bit it might trigger some DoS or any sort of NULL pointer trouble in the attacked script. Even on 64 bit it might be that msdn.cpp mis-behaves when it interprets the content-length.


Please note that with a quick glimpse I did not find any source for some possible file named msdn.cpp on the web. So it is unlikely that it is widely deployed.

Hence such requests might be a way to try to locate some already installed backdoor which obfuscates as msdn.cpp. If it resides on some NAS/IoT device which is behind a dialup line, it might change the IP address daily, so perhaps somebody wants to search for it by scanning the whole web.

There are only roughly 3 billion IPv4 addresses to scan. So just 50 machines with a query rate of 1000 requests per second can scan the entire IPv4 space in just one day, and 1000 req/s (of 1 KB each) only need a moderate uplink of around 1 MiB/s per machine.

There is no need for a BotNet to do this. 10 VMs cost you around $1 per day. Easy.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.