2

I've put up a small proof of concept web api on AWS infrastructure (elastic beanstalk) using their free tier. My app is working fine, but I'm seeing a lot of this in the access logs:

172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "149.100.171.172"
172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "2.227.202.134"
172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "93.44.33.132"
172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "93.37.77.196"
172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "151.62.133.102"
172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "95.249.219.42"
172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "2.34.37.138"

I'm seeing about 7 hits per second, and it's always a POST to /device/enabler/linear. The URL is not part my app at all. I've reverse DNS'ed some of the IP's, and they all seem to be from Italian ISPs (not sure if that is relevant).

It's not a massive issue at the moment as it's not preventing my app working (so not really sure if it counts as a ddos?), but it is a nuisance, and it has caused me to take the service down (so arguably has succeeded). And it will start to cost me money at some point because the access logs are being written to much faster than I anticipated so I will exceed the S3 puts that are in the free plan.

I'm in the process of working out how to configure the AWS EC2 firewall stuff (I think that's what I need to configure to allow access access from my client)

Has anyone seen this type of thing before? Could it be a ddos? has anyone seen hits to this url like this (I've googled for it and drawn a blank)

Appreciate any advice anyone can offer;

  • What's the payload of those requests? – CodesInChaos Jun 19 '17 at 11:23
2

It's not a massive issue at the moment as it's not preventing my app working (so not really sure if it counts as a ddos?)

let's state some definitions

Denial of service : If service has not been denied by the attack, It's not DoS nor DDoS. It might be abusive, but that wouldn't be quite the same stuff.

Assumption

  • 93.44.33.132, 2.227.202.134, 93.37.77.196, 151.62.133.102, 95.249.219.42 and 2.34.37.138 have a negative reputation, says symantec.

  • Regarding a DDoS attack, 7 requests per second are not a lot. The post request size might be a hint. For instance if the size is greater than 1 Mo, yes, it can be a DDoS attempt.

  • The numbers 403 and 362. Assuming those numbers is a response code, it looks like your app is denying the access with a 403 Forbidden, 362 may state why the access is forbidden. <- i might be wrong with this point.

  • So what do we have ? We know that some low reputation IP are making 7 POST request / sec. On a URL that doesn't exist. From my experience, we do not have enough info to determine if this pattern is a DDoS attack. We have to go deeper.

Going deeper

For further investigation, i will start by fetching three entire post requests and their responses (with different source IP).

the goal is to:

  • Know the size of the 3 requests/responses.
  • Find any payload in the request's header or content.
  • what data those requests are posting.
  • what are the responses and how your app handle those requests.

Not in the question range

Knowing if a reverse proxy is present between the client and the app might be interesting too. For instance, those requests might target the proxy and not the app, for cache poisoning purpose.

  • 1
    Good points, except symantec rep system has a bad rep. :D – Overmind Jun 19 '17 at 12:23
  • Technically, since the OP had to disable service due to the issue, it's strictly speaking a Denial of Service. What it might not have been though, is that it's most likely not an intentional DoS. From the look of it, this could have been a misconfigured load balancer/appliance/IoT device looking up a service that was previously hosted in the domain name or IP address that the OP currently owns. The OP might want to check historical record of their Domain name and IP address. You might also want to check the Host header of these requests. – Lie Ryan Jun 19 '17 at 15:22
  • 1
    Symantec's reputation determination appears to be based on the same source as Spamhaus Database. All the IP addresses that Symantec claims to have "negative" reputation are in Spamhaus PBL (Policy Block List), but are not in SBL nor XBL. Being in PBL does not indicate that the IP address have ever misbehaved. An IP address is usually in the PBL because the IP range is allocated for residential uses, so by default it's assumed to not be permitted to send mail without authentication. – Lie Ryan Jun 19 '17 at 15:48
  • @LieRyan Thanks for sharing, didn't know about that. Any IP reputation lookup suggestion ? – Baptiste Jun 19 '17 at 15:55
  • 1
    In the standard webserver log format, the "362" is the size, in bytes, of the response sent by the server. – Mark Jun 19 '17 at 22:05

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.