Am I being hacked? - apache

Question

Here are just a few lines from my Apache 2.0 error_log:
[Sun Nov 25 08:22:04 2012] [error] [client 64.34.195.190] File does not exist: /var/www/vhosts/default/htdocs/admin
[Sun Nov 25 14:14:32 2012] [error] [client 96.254.171.2] File does not exist: /var/www/vhosts/default/htdocs/azenv.php
[Wed Nov 28 03:02:01 2012] [error] [client 91.205.189.15] File does not exist: /var/www/vhosts/default/htdocs/user
[Wed Nov 28 03:44:35 2012] [error] [client 66.193.171.223] File does not exist: /var/www/vhosts/default/htdocs/vtigercrm
[Mon Dec 03 00:09:16 2012] [error] [client 82.223.239.68] File does not exist: /var/www/vhosts/default/htdocs/jmx-console
[Mon Dec 03 20:48:44 2012] [error] [client 221.2.209.46] File does not exist: /var/www/vhosts/default/htdocs/manager
[Thu Dec 06 07:37:04 2012] [error] [client 116.254.203.24] File does not exist: /var/www/vhosts/default/htdocs/w00tw00t.at.blackhats.romanian.anti-sec:)
[Thu Dec 06 07:37:05 2012] [error] [client 116.254.203.24] File does not exist: /var/www/vhosts/default/htdocs/phpMyAdmin
[Thu Dec 06 07:37:05 2012] [error] [client 116.254.203.24] File does not exist: /var/www/vhosts/default/htdocs/phpmyadmin
[Thu Dec 06 07:37:06 2012] [error] [client 116.254.203.24] File does not exist: /var/www/vhosts/default/htdocs/pma
[Thu Dec 06 07:37:06 2012] [error] [client 116.254.203.24] File does not exist: /var/www/vhosts/default/htdocs/myadmin
[Thu Dec 06 07:37:07 2012] [error] [client 116.254.203.24] File does not exist: /var/www/vhosts/default/htdocs/MyAdmin
[Thu Dec 13 02:19:53 2012] [error] [client 96.254.171.2] File does not exist: /var/www/vhosts/default/htdocs/judge.php
The most common errors are requests for the "phpMyAdmin" file, and "w00tw00t.at.blackhats.romanian.anti-sec:)".
I can see the IP address that the requests are coming from. But who is "client"?
Thanks,
Shane.

Answer 1

This is just an automatic script deployed by many Script Kiddies looking for a security breach in your apache version/configuration. The signature w00tw00t is usually left by DFind.
Just use a program like fail2ban configured such as this example explains to avoid being flooded by these requests :
https://web.archive.org/web/20160617020600/http://www.userdel.com/post/18618537324/block-w00tw00t-scans-with-fail2ban
This does not necessarily mean you've been hacked, but the server has been scanned for vulnerabilities. However, if you use any of the software that you saw in those logs and it is an older version having known vulnerabilities, you should check your server for unusual files and login activities.

Answer 2

Requests for this are usually sent without a server header. Just create a default virtual host for requests that don't have a server header you expect and blackhole it. Also fun to log broken traffic and do reverse DNS to see if it's coming from another webserver (compromised?) and contact the owner based on whois database. You never know who's running silly scripts from a publicly identifiable server to scan for vulnerabilities and later exploit them over ToR tunnel. Use burner contact information if you don't want to bring attention to yourself.

Answer 3

To follow up on the answer given by #user823629, here is a default virtual host configuration I use on Apache 2.4:
<VirtualHost *:80>
# Default vhost for requests not matching IP or Host of other vhosts
ServerName blackhole
ErrorLog logs/error_log_default
CustomLog logs/access_log_default combined
Redirect 404 /
</VirtualHost>
<VirtualHost *:443>
# Default vhost for requests not matching IP or Host of other vhosts
ServerName blackhole
ErrorLog logs/ssl_error_log_default
CustomLog logs/ssl_access_log_default combined
CustomLog logs/ssl_request_log_default "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
Redirect 404 /
</VirtualHost>
It redirects all requests to the default 404 page. SSL requests that do not match any other site will end up at the second VirtualHost definition, and will of course result in a certificate error, but this is expected and fine.
I put this in conf.d and give it a name of conf.d/0_default.conf so that it comes before other vhosts definitions and it is the default virtual host. This can be verified via:
apachectl -t -D DUMP_VHOSTS
or on Redhat/Fedora/CentOS distros:
httpd -t -D DUMP_VHOSTS
Other virtual hosts will match before this default vhost if:
Their IP address and port matches the VirtualHost definition more explicitly (IP-based virtual host), or
The request contains a Host header that matches the request (name-based virtual host). Otherwise, the request will fall back to the default blackhole virtual host defined above.
Be careful with VirtualHost definitions with IP addresses specified. Since these match before the blackhole, the wrong configuration can become the default for that IP. List the specific IPs in the blackhole if necessary.
See http://httpd.apache.org/docs/current/vhosts/details.html for more details on virtual host matching.

Answer 4

Unless you actually use /var/www/vhosts/default/ for hosting a website, this means you have requests going to the default host that are not being caught by your virtualhosts setup.
Disregard for a moment that these are malicious requests, because the underlying reason for these vhosts/default/ errors is you probably have SSL disabled for a virtualhost, & these are HTTPS requests caught up in the default server config.
You can add %v %V %p to your Apache access logging parameters in httpd.conf to see more info on what these requests are & what virtualhost/servername is handling them (%v %V) & on what port (%p) the requests are being made through (typically port 443 if it's HTTPS).
To fix the HTTPS aspect, I'd enable SSL & then put in a RewriteRule to send HTTPS requests to HTTP (if that's the intended behavior). More info about how to do that here.
Otherwise to help with script kiddies, the blackhole mentioned above is the way to go. Just make sure you aren't mistakenly sending legitimate web crawler/spiders requesting HTTPS to the same galactic death -- for instance Googlebot tests legitimate pages via HTTPS since that's the direction Google wants the web to head in.