Are these log messages in my nginx server evidence of an attempted attack?

Question

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"

Answer 1

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.