Apache2 error log says someone is messing with my server > should I take some action?

Question

An example of my /var/log/apache2/error.log:

[Sun Apr 10 23:33:12 2011] [error] [client 173.242.122.8] Invalid URI in request GET /bin/scripts/../../../../winnt/system32/cmd.exe /c+dir?/c+dir%20c:\\ HTTP/1.0
[Sun Apr 10 23:33:13 2011] [error] [client 173.242.122.8] Invalid URI in request GET /bin/scripts/../../../../winnt/system32/cmd.exe?/c+dir HTTP/1.0
[Sun Apr 10 23:33:13 2011] [error] [client 173.242.122.8] Invalid URI in request GET /bin/scripts/../../../../winnt/system32/cmd.exe?/c+dir%20c:\\ HTTP/1.0
[Sun Apr 10 23:33:13 2011] [error] [client 173.242.122.8] File does not exist: /var/www/bin
[Sun Apr 10 23:52:20 2011] [error] [client 173.242.122.8] script not found or unable to stat: /usr/lib/cgi-bin/allmanage
[Sun Apr 10 23:52:30 2011] [error] [client 173.242.122.8] script not found or unable to stat: /usr/lib/cgi-bin/allmanageup.pl
[Sun Apr 10 23:53:02 2011] [error] [client 173.242.122.8] script not found or unable to stat: /usr/lib/cgi-bin/AnyBoard.cgi
[Sun Apr 10 23:53:02 2011] [error] [client 173.242.122.8] script not found or unable to stat: /usr/lib/cgi-bin/anyboard.cgi
[Sun Apr 10 23:53:03 2011] [error] [client 173.242.122.8] script not found or unable to stat: /usr/lib/cgi-bin/AnyForm
[Sun Apr 10 23:53:03 2011] [error] [client 173.242.122.8] script not found or unable to stat: /usr/lib/cgi-bin/AnyForm.cgi
[Sun Apr 10 23:53:05 2011] [error] [client 173.242.122.8] script not found or unable to stat: /usr/lib/cgi-bin/AnyForm2

The list goes on and on, it's huge.

Should I take some action against this? Should I be worried? Should I ban the IP?

Answer 1

This is a program scanning for vulnerabilities.

If your site isn't using a vulnerable framework/blog/CMS, then you probably don't have to be overly worried about it; if they didn't find anything, it's just a waste of resources. If any of the URLs it's tried match URLs on your site, though, then the scanner has done its job -- and the person that was at that IP at the time the scan was taking place now has information on how they can break in. Check your access log for non-4xx responses to that IP during the time of the scan.

Fun part is, the IP may have changed in the past 3 days...so banning the IP at this point probably won't do much good. About the only surefire ways to keep them out are to update and/or disable the vulnerable apps, and/or take the server down.