-1

I started running a flask application on a raspberry pi last night. It was not hiding behind apache or nginx, served the requests by itself. I set up my router to forward http traffic towards it as a proof of concept. Now to show somebody what it is looking like, I left it on overnight. This morning I woke up to a few GET requests that I do not quite understand:

[ip-address] - - [date] "GET http://[ip-address]/proxychecker/check.cgi?action=getinfo HTTP/1.1" 404-

and

[another ip-address] - - [date] "GET /xmlrpc.php HTTP/1.1" 404 -

Is any of this anything I have to worry about? What exactly are they trying to accomplish with these requests? Particularly the first one.

Anders
  • 64,406
  • 24
  • 178
  • 215
CodyJae
  • 3
  • 1
  • 2
    See this http://serverfault.com/questions/70601/strange-centos-5-lighttpd-access-log – Sravan Sep 15 '16 at 12:23
  • 2
    These are automated scans for vulnerabilities. The first is checking if your server is an open proxy. The second is checking if you have a file associated with Wordpress installations that provides an attack mechanism. Your server returned a 404 error for both, so you should be safe. Expect these scans to happen daily, because it's the reality of the Internet. – tlng05 Sep 15 '16 at 12:24

1 Answers1

1

It is an automated scan for vulnerable software. If you connect just anything to the internet, you will be getting requests like these before you can say "information security".

The first one checks if you are an open proxy, e.g. if you allow anyone to use you as a proxy server. Finding these are useful when you are running automated attacks because it means that the attacks can be relayed by them. It would not surprise me if the IP numbers in your logs are from servers with this kind of vulnerability.

The second one tests if you are running WordPress and have the XML-RPC interface on. That can be used to do brute force attacks on the admin password.

It is important to understand that these are not actual exploits, but scans to detect vulnerabilities that can be exploited in the next step. Since you returned 404 in both cases - thereby indicating that you are not a proxy, and not running WordPress - the result was negative for the attacker. They probably moved on, and I would not be very worried if I were you.

Community
  • 1
Anders
  • 64,406
  • 24
  • 178
  • 215