Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I've noticed on my server log that I receive unexpected requests from an IP in San Antonio. Is this spam ?

They visit phpMyAdmin, admin.. etc is this spam ?

184.106.130.137 184.106.149.110 - [21/Nov/2010:16:56:36 +0000] "GET //phpMyAdmin/ HTTP/1.1" 404 345 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro"

130.137 184.106.149.110 - [21/Nov/2010:16:56:36 +0000] "GET //pma/ HTTP/1.1" 404 345 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro"

184.106.130.137 184.106.149.110 - [21/Nov/2010:16:56:36 +0000] "GET //admin/ HTTP/1.1" 404 345 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro"

184.106.130.137 184.106.149.110 - [21/Nov/2010:16:56:36 +0000] "GET / HTTP/1.1" 200 146 "-" "Made by ZmEu @ WhiteHat Team - www.whitehat.ro"

thanks

share|improve this question

4 Answers 4

up vote 5 down vote accepted

Looks like people looking for unsecured common scripts on your webserver.

Should you worry? Depends if you have any unsecured common scripts on your webserver...

share|improve this answer
    
mhm ok. Well, I haven't change any script, just installed regular stuff. Is there something I can do to be sure everything is safe ? thanks –  Patrick Nov 21 '10 at 20:27
1  
I think how to setup a secure web server is a very broad topic. Obviously in general remove stuff you don't need, minimum access and strong passwords for anything you do need combined with keeping on top of patches for OS/installed applications and so on. Then there's IPS/IDS etc. You'd do worse than download and run nessus against your website. –  Hutch Nov 21 '10 at 20:48
    
I'd specifically block that IP with the firewall and then do a thorough check to ensure it's secure. –  Matt Nov 21 '10 at 20:53
3  
@matt cat and mouse IP blocking is just a bad idea all around. If the web server is locked down (the way any web server should be) script kiddie scanning is not worth the time to manage IP blocks and NAT just makes problems for everyone with IP blocks. THE ONLY TIME TO BLACK LIST an IP is during a successful attack. –  Liam Nov 21 '10 at 21:14
    
@Patrick, @joe, @Matt, See this question on IT Security SE. –  AviD Nov 22 '10 at 7:53

Most likely someone scanning your site to find common tools they can use, and possibly common vulnerabilities.

This happens all th time. This doesn't mean somebody is targeting your site specifically. You should not be worried if you have secured your site:

  • all versions are up to date: server, application, etc.
  • all admin tools (phpmyadmin, custom, etc.) are accessible from 127.0.0.1 only (use an SSH tunnel to access it from your client)
  • no SQL injection, default password, log file accessible to the world, etc.

There are scan going on all the time to find vulnerable servers.

UPDATE: Make any admin tool, and /admin, available to 127.0.0.1 only (in your Apache configuration file for example)

Then, create an SSH tunnel to redirect the remote 127.0.0.1:80 to your local machine (port 8000 for example):

ssh user@server.com -L8000:localhost:80

If you use Windows, Putty lets you do the same thing.

Then, you can access /phpmyadmin with http://localhost:8000/phpmyadmin

This ensure than /phpmyadmin is not available to any IP unless they can also SSH to your box.

share|improve this answer
    
my phpmyadmin is actually accessible from any ip. The point is that I'm using a remote VPS, I cannot make it accessible from phpmyadmin only. –  Patrick Nov 21 '10 at 21:01
    
If you have reasons to believe that you're of heightened vulnerability (if your site is notable enough that someone might put manual effort into an exploit, or if you have publicly published your site infrastructure details), then it may be worthwhile to IP lock your tools. I believe that by your comment you mean "accessible from local only". You're right. The point of phpmyadmin is to be able to use it remotely. But that doesn't mean you necessarily have to allow access from "everywhere". SSH into your box and set up an IP filter for phpmyadmin and put your new IP up on as as needed basis. –  Steven Xu Nov 21 '10 at 21:12
    
@Steven Xu Ok thanks.. I just have a quick question about phpmyadmin link in my var/www directory. Is this line (permissions) fine ? lrwxrwxrwx 1 root root 21 Nov 22 09:04 phpmyadmin -> /usr/share/phpmyadmin –  Patrick Nov 22 '10 at 9:06
    
It shouldn't be a big deal (although I've never seen that particular phpmyadmin configuration before - using a symlink). Phpmyadmin is relatively powerless since it doesn't store your access credentials. However, it is a potential avenue of attack. If your SQL server is accessible globally, then it makes no difference whether an attacker goes though phpmyadmin or your SQL process. A potential point of caution is that a publicly accessible phpmyadmin may flag your site as one with "weaker" security measures. I can't tell if this is the case since the only request was for a camelcased version. –  Steven Xu Nov 22 '10 at 16:01

From what you posted, they didn't find interesting things on your web server (most lines are 404). They only hit successfully http://yourip/ (200) which is a small page with less than 146 bytes (default page of your distribution).

If you only need local access, put a firewall. If you only need few people to access it, change the default port to something less obvious. Even better, crypt the connection (https) and put a password protection (don't put password without encryption).

share|improve this answer

This happens often enough that it's worth putting a CGI or similar in a few of the common places (or using aliasing to make it respond as if it were in those places), and have it trigger something to block them at your firewall.

When something like this happens, it's worth looking to see if they found something:

grep [connecting ip address] /path/to/access_log | grep -v '" 404 '

(try to find what they requested that wasn't a 404 error)

... and if it's a stock PHP, CGI, etc, check to see if there are any reported vulnerabilities against it). If they seemed to focus on one script in particular, focus there, and also look to see if there's anything abnormal on the machine, such as files with modification times near when they were trying to get in.

Often, they can't get in with just one step -- they use some vulnerable program to upload a file to somewhere it'll get executed, and then issue a second command to get it to execute ... if you're lucky, it'll all come from the same IP, and you can easily find what got executed, and either find the file if it didn't delete immediately after running, or use the filename to search the internet for clues on what they might've done.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.