Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
If it is an attack, it looks like a pretty stupid one. But I would really like a second opinion.
The situtation: I have an HTTP Proxy Server set up running Apache under Ubuntu 9.10 (desktop) running behind my home firewall, secured with Digest Authentication. But about once a day, I get lines in the error log that look like this:
Code:
[Thu Dec 17 09:19:26 2009] [error] [client 85.17.154.200] client denied by server configuration: /var/www/phpmyadmin
[Thu Dec 17 09:19:26 2009] [error] [client 85.17.154.200] client denied by server configuration: /var/www/pma
[Thu Dec 17 09:19:26 2009] [error] [client 85.17.154.200] client denied by server configuration: /var/www/admin
[Thu Dec 17 09:19:27 2009] [error] [client 85.17.154.200] client denied by server configuration: /var/www/dbadmin
[Thu Dec 17 09:19:27 2009] [error] [client 85.17.154.200] client denied by server configuration: /var/www/mysql
[Thu Dec 17 09:19:27 2009] [error] [client 85.17.154.200] client denied by server configuration: /var/www/php-my-admin
[Thu Dec 17 09:19:28 2009] [error] [client 85.17.154.200] client denied by server configuration: /var/www/myadmin
[Thu Dec 17 09:19:29 2009] [error] [client 85.17.154.200] client denied by server configuration: /var/www/PHPMYADMIN
[Thu Dec 17 09:19:29 2009] [error] [client 85.17.154.200] client denied by server configuration: /var/www/phpMyAdmin
[Thu Dec 17 09:19:29 2009] [error] [client 85.17.154.200] client denied by server configuration: /var/www/p
The IP address is different each time: sometimes Japan, sometimes not. I haven't even bothered running geolocate on the one above.
I do know, however, that neither of the two authorized users of the proxy did these requests. It looks to me like the culprit doesn't even know that it is a proxy server, not an origin server.
The corresponding lines in access.log are a little more informative, but I still cannot figure out how he even got that far, since I have the following lines in the Main section of my Apache config:
Code:
<Location />
Order deny,allow
Deny from all
</Location>
Before I put in these lines, he was getting "404 not found" on the GETs, now he gets "403 forbidden".
Another reason I am surprised he gets this far: there is no Listen directive on port 80, only on 8080, which is for the proxy.
So here are the above-mentioned corresponding lines in access.log:
1) how was he even able to do these GETs in the first place?
2) is this an attack, or just a very poor robot?
3) how concerned should I be about this? Is it ignorable? I find it hard to take seriously anyone still using Win98
Last edited by mejohnsn; 12-17-2009 at 12:39 PM.
Reason: forgot to say what Linux version
@mejohnsn: Whether it's a targeted attack by a human or a random attack by a bot isn't too important (at least not yet). What you have is someone looking for low hanging fruit. They're hoping to get lucky by landing on a phpMyAdmin installation with poor / improper file permissions so that they can get your data.
FWIW, I see log entries like this daily on many hosts. The best advice I can give is:
Run a secure httpd.conf configuration
Keep Apache httpd up to date with security fixes
If you're running phpMyAdmin, be sure that you have secured it properly
every webserver in the world is "attacked" in that way, believe me, i'm seeing this everyday. i mean every, having white (internet) IP.
these attacks won't get far if you don't install phpmyadmin(in this case, there are also buggy apps like roundcube that are also being searched) in default or predictable locations on hostname=your_IP or on default hostname. in fact i don't remember seeing same attacks with specified known hostname. if there are, then someone knows it is you and purposefully trying to get your serv.
@mejohnsn: Whether it's a targeted attack by a human or a random attack by a bot isn't too important (at least not yet). What you have is someone looking for low hanging fruit. They're hoping to get lucky by landing on a phpMyAdmin installation with poor / improper file permissions so that they can get your data.
FWIW, I see log entries like this daily on many hosts. The best advice I can give is:
Run a secure httpd.conf configuration
Keep Apache httpd up to date with security fixes
If you're running phpMyAdmin, be sure that you have secured it properly
Thanks for the advice and feedback. But this only pushes back the question: what is a 'secure' httpd.conf? I have seen only a few examples on the net, or in books on Apache, there are lots of differences between them; some people seem to think it is 'secure' if it has the "Order allow deny, deny from all" directives I already have.
Why, one Apache tutorial I read incredibly implies that it is secure just for that reason.
As you can tell, I am not convinced. But I also have Digest Authentication, so I would have supposed mine is already pretty secure -- except I thought it should not be responding to those GETs at all, that it should only respond to Proxy requests.
How many realistic attackes does fail2ban protect from? Since you suggested it, I Googled it, and found that all it does is ban a given IP address when it shows up in the logs with failed login attempts.
But there ARE no failed login attempts from this attack -- and it keeps coming in from different IP addresses, so it would have no effect at all.
Now perhaps this suggests something else I should do: I have the Digest password authentication only on the Proxy. I thought I didn't need it on the main server, since 1) There is no Listen directive except for the Proxy and 2) there is nothing to serve back, since I have "Order deny, allow...Deny from all" in the <Location /> context.
Many of the suggestions are inspired by the book Apache Security by Ivan Ristic (which I heartily recommend). If fact, I implement several of those as part of a standard Apache deployment. (However, I generally do not mess around with mod_security nor chroot. In your case, mod_security in particular might be worth some further research.)
-------
In any event, are you running a normal proxy (i.e. allowing your internal clients to reach the 'net) or a reverse proxy (which would allow 'net hosts to access one of your internal web servers)? If the former case, you should not be accepting any connections from the outside world at all. That should be locked down at the IP level using a firewall. If the latter case, these sorts of bogus requests are simply going to be a fact of life. Your server is doing the correct thing by replying with an HTTP 403.
Many of the suggestions are inspired by the book Apache Security by Ivan Ristic (which I heartily recommend). If fact, I implement several of those as part of a standard Apache deployment. (However, I generally do not mess around with mod_security nor chroot. In your case, mod_security in particular might be worth some further research.)
-------
In any event, are you running a normal proxy (i.e. allowing your internal clients to reach the 'net) or a reverse proxy (which would allow 'net hosts to access one of your internal web servers)? If the former case, you should not be accepting any connections from the outside world at all. That should be locked down at the IP level using a firewall. If the latter case, these sorts of bogus requests are simply going to be a fact of life. Your server is doing the correct thing by replying with an HTTP 403.
Thanks for the recommendation of the freitag site. It looks pretty good.
As for what kind of proxy, it is definitely abnormal I want it to allow an authenticated user anywhere to access the outside net, and inside the firewall, allow any user from a range of IP addresses -- again accessing outside net.
But thanks for confirming that 403 is the right response. Although today I got a 400 and a 407, the former one from the "toata dragostea mea pentru diavola" spider.
And oh, yes: the passwords for the authenticated users are quite strong.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
