Re: Apache web server being attacked
On Wed, May 19, 2010 at 6:36 PM, Aiza wrote: > Nothing is worse than someone insinuating the original poster don't know > what they are talking about. I find your remarks totally un-necessary. Your > telling the poster they don't know what their doing when it's you who don't > know what options are offered by their register. How can you say something > is not available when you are not the one using or providing the register > service. For you information port forwarding is common function when the > domain name is specified to a dynamic ip address. Check out No you are wrong. Matthew is correct. Perhaps you are confusing URL forwarding/redirect with port forwarding, but they are completely different. Domains on dynamic ip address REQUIRE some method of intervention to update the DNS record when it changes eg dns/ipcheck. The only way a registrar could avoid doing such thing would be if they controlled address assignment and since registrar and ISP are rarely if ever the same organization you are forced to use the Internet in Matthew's reality. As far as URL forwarding goes, there are several different methods to accomplish it. The safest way is to simply host the vhost and http 301 it to the correct place. Other methods are hackish and may not be able to be tracked if so desired as well as other limitations. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Apache web server being attacked
Matthew Seaman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/05/2010 04:55:26, Aiza wrote: I take a totally different approach to this problem for my production web sites. This is the result of people running scripts that roll through a large block of ip address scanning each ip address for open [STANDARD\] ports, and when they find port 80 open, they then attack the web server. The simple solution is not to have your web server use the standard port 80. Your web site is not know by it's ip address but by it's url (ie; www.domain-name.com.). My domain name register has option to associate my "www.domain-name.com" with any port number I want to use at the specified ip address. This way my web site has total access by anyone who knows it's URl, the URL is scanned by yahoo and google indexing bot and becomes know to the public. Nobody knows or cares that the web site is not using port 80. I then close inbound port 80 in my firewall thus locking out all the script kiddies who run the port scan on standard ports. This method has worked for me the last 10 years without ever having my production web servers attacked. Sure some nay sayers will counter by saying all the scanners have to do is scan all the ports. Yah sure that can be done, but in 10 years it has never occurred. If the URL for your site is http://www.domain-name.com/ then any client that attempts to access it will try to connect to port 80. That's the point of having well known ports. Now, you can explicitly state a different port in the URL: http://www.domain-name.com:8080/ but this is generally only useful amongst a closed group of users: the general public will on the whole just get confused, so it's not often encountered on general access websites. Your domain registrar can't control anything to do with port numbers. For some unknown reason this is a common misconception, particularly among management types. The DNS only associates hostnames with ip numbers and vice versa[*]. Now, it may be the case that your server is behind some sort of NAT/PAT gateway or HTTP reverse proxy, and that locally you are running apache bound to some arbitrary port numbers. Which is fine, but unless you are specifically telling people to use a different port in your URLs, then the world at large is accessing your site through port 80. Which means that port scanners can certainly find it and attempt to attack it. Guess what? Because the attacks are in the form of valid HTTP queries, they'd go straight through any sort of port address translation just like your normal traffic. What I think you're actually doing is that all your web sites use name based virtual hosts. So a query to the IP number of your server gets directed to a different bit of the apache config (and probably rejected) compared to a query to a site by name. That's actually a pretty good design, and if you combine it with a reverse proxy which knows about what hosts and URLs should be behind it, you can filter out a lot of bad traffic very effectively before it gets anywhere near your real web server. Cheers, Matthew Matthew Nothing is worse than someone insinuating the original poster don't know what they are talking about. I find your remarks totally un-necessary. Your telling the poster they don't know what their doing when it's you who don't know what options are offered by their register. How can you say something is not available when you are not the one using or providing the register service. For you information port forwarding is common function when the domain name is specified to a dynamic ip address. Check out http://www.zoneedit.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Apache web server being attacked
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/05/2010 04:55:26, Aiza wrote: > I take a totally different approach to this problem for my production > web sites. This is the result of people running scripts that roll > through a large block of ip address scanning each ip address for open > [STANDARD\] ports, and when they find port 80 open, they then attack the > web server. The simple solution is not to have your web server use the > standard port 80. Your web site is not know by it's ip address but by > it's url (ie; www.domain-name.com.). My domain name register has option > to associate my "www.domain-name.com" with any port number I want to use > at the specified ip address. This way my web site has total access by > anyone who knows it's URl, the URL is scanned by yahoo and google > indexing bot and becomes know to the public. Nobody knows or cares that > the web site is not using port 80. I then close inbound port 80 in my > firewall thus locking out all the script kiddies who run the port scan > on standard ports. This method has worked for me the last 10 years > without ever having my production web servers attacked. Sure some nay > sayers will counter by saying all the scanners have to do is scan all > the ports. Yah sure that can be done, but in 10 years it has never > occurred. If the URL for your site is http://www.domain-name.com/ then any client that attempts to access it will try to connect to port 80. That's the point of having well known ports. Now, you can explicitly state a different port in the URL: http://www.domain-name.com:8080/ but this is generally only useful amongst a closed group of users: the general public will on the whole just get confused, so it's not often encountered on general access websites. Your domain registrar can't control anything to do with port numbers. For some unknown reason this is a common misconception, particularly among management types. The DNS only associates hostnames with ip numbers and vice versa[*]. Now, it may be the case that your server is behind some sort of NAT/PAT gateway or HTTP reverse proxy, and that locally you are running apache bound to some arbitrary port numbers. Which is fine, but unless you are specifically telling people to use a different port in your URLs, then the world at large is accessing your site through port 80. Which means that port scanners can certainly find it and attempt to attack it. Guess what? Because the attacks are in the form of valid HTTP queries, they'd go straight through any sort of port address translation just like your normal traffic. What I think you're actually doing is that all your web sites use name based virtual hosts. So a query to the IP number of your server gets directed to a different bit of the apache config (and probably rejected) compared to a query to a site by name. That's actually a pretty good design, and if you combine it with a reverse proxy which knows about what hosts and URLs should be behind it, you can filter out a lot of bad traffic very effectively before it gets anywhere near your real web server. Cheers, Matthew [*] I speak loosely. That's the way it works for the HTTP(S) protocol used by websites. For some more recently specified protocols like XMPP the situation is different. - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvzrt8ACgkQ8Mjk52CukIwnyACdFFVhVuGjxebfZXpHG1zfGUaY 0HYAnAiqXjsT2XowGUNpYdjfDZg2UhPT =2Drn -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Apache web server being attacked
Hi, Am 19.05.10 05:00, schrieb Aiza: Where do I find documentation on how to enable and use apache mods rewrite and redirect? have you tried the apache.org website? There is a lot of information and examples available: http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html Also google helps a lot answering this questions or find examples. Bye, Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Apache web server being attacked
Matthew Seaman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/05/2010 11:00:16, Aiza wrote: I put apache13 in a jail and left inbound port 80 open in my firewall. There is no domain name pointing to my web server. The content there is a small apache web application that fools web email address harvest programs into harvesting bogus email address from web page. http://www.monkeys.com/wpoison This is what I am doing. Since setting this up I have not had any bots scan the site for email address. But have had port 80 attacks that did not work. MY Apache access and error logs follow. [lots of logfile traces elided] Yes. Unfortunately this sort of thing is the norm on the web nowadays. It's all automated: first they program their botnets to scan for a web server listening on port 80. Then they use them to attempt to compromise whatever they find -- in your case, most of what you're seeing is an attempt to gather information on what PHP capabilities your web server might have. What they are doing is trying in turn a lot of the popular locations for installing apps like phpmyadmin or phppgadmin. Yes, they are doing this in a particularly clueless fashion -- what exactly did you expect of the sort of people that think creating botnets is a good idea? They'll probably grow out of it when they hit puberty. In the mean time, as you don't have phpmyadmin or anything similar installed, this is just an annoyance for you -- it clutters up your log files but does nothing else. If you did want to install phpmyadmin on that server, you should take care to 1) Keep it up to date -- there haven't been any PMA security advisories for some months, but at one point they were coming out about one a week. PMA does have some very active developers though, and new versions appear every month or two. 2) Be sure to use access controls in your apache config to limit where PMA can be accessed from. Ideally, run it over HTTPS as well -- by its nature, you will tend to send DB passwords etc. to this application, and you want to avoid having them snooped. 3) If you use the on-line phpmyadmin configurator, be sure to clean up after yourself once you've generated a config file. To use the on-line configurator you have to create a directory /usr/local/www/phpMyAdmin/config which you make read/write by the user the webserver runs as. Once you've created the config.inc.php in that directory, you need to move it up one level in the directory heirarchy, and then delete the config directory you created. (That's what your attacker is so desperate to find -- because the directory is read-write by the webserver process, they can use it to upload malware to your system.) Cheers, Matthew - -- I take a totally different approach to this problem for my production web sites. This is the result of people running scripts that roll through a large block of ip address scanning each ip address for open [STANDARD\] ports, and when they find port 80 open, they then attack the web server. The simple solution is not to have your web server use the standard port 80. Your web site is not know by it's ip address but by it's url (ie; www.domain-name.com.). My domain name register has option to associate my "www.domain-name.com" with any port number I want to use at the specified ip address. This way my web site has total access by anyone who knows it's URl, the URL is scanned by yahoo and google indexing bot and becomes know to the public. Nobody knows or cares that the web site is not using port 80. I then close inbound port 80 in my firewall thus locking out all the script kiddies who run the port scan on standard ports. This method has worked for me the last 10 years without ever having my production web servers attacked. Sure some nay sayers will counter by saying all the scanners have to do is scan all the ports. Yah sure that can be done, but in 10 years it has never occurred. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Apache web server being attacked
Michael Powell wrote:
Aiza wrote:
I put apache13 in a jail and left inbound port 80 open in my firewall.
There is no domain name pointing to my web server. The content there is
a small apache web application that fools web
email address harvest programs into harvesting bogus email address from
web page. http://www.monkeys.com/wpoison This is what I am doing.
Since setting this up I have not had any bots scan the site for email
address. But have had port 80 attacks that did not work. MY Apache
access and error logs follow.
[snip log content]
As you can see looks like a script kiddy is running something they dont
understand. "/usr/local/www/data//phpmyadmin2/config.inc.php"
there should only be a single / between data/phpmyadmin2.
But beside that looks like php config.inc.php file is a target and
phpmyadmin also is a target. The apache return code 404 means not found
so no effect to me.
Has anyone seen this junk hitting their apache web servers or have any
different explanation of what this means?
Sorry to tell you this, but this kind of thing goes on all the time. You can
fine tune mod_security for some control for SQL injection techniques, as
well as many other generic forms of locking down the web server in general.
Generally speaking, the bulk of this does nothing more than filling the logs
- BUT - all it takes is for one app to let the attacker "leak" onto your
hard drive and they're in. I see a lot of scans for roundcube and
phpMyAdmin. Have also seen a lot of phpBB in the past.
The attackers spew lots of requests but the needle in the haystack they are
looking for is that one app that has a known vulnerability. In addition to
securing the web server itself you should monitor any app running on it for
reported security flaws and keep them updated to the latest "safe" versions.
You can also add to the hardening of your web server (if Apache) with
various .htaccess + mod_rewrite tricks. Examples include:
# block all smarty templates (no reason to have these exposed)
RedirectMatch gone ^/.*\.tpl$
# block all .log (log files), .sql (sql dump/export) and .conf (config
files) files in case some day these files move to another directory
RedirectMatch gone ^.*\.(sql|log|conf)$
# block access to the 'Smarty-*' directory
RedirectMatch gone ^.*Smarty.*$
# block common files present that you don't want served
RedirectMatch gone CHANGELOG.*
RedirectMatch gone COPYRIGHT.*
RedirectMatch gone INSTALL.*
RedirectMatch gone NEW.*
RedirectMatch gone README.*
RedirectMatch gone UPGRADE.*
RedirectMatch gone VERSION.*
# block access to directories
Redirect gone /upgrade
Redirect gone /tmp
Redirect gone /var
Redirect gone /sql
#Redirect pesky stuff based on referrer
Options -MultiViews -Indexes
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^Twiceler [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Morfeus [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Toata [NC]
RewriteRule .* - [F,L]
There is much and many more, just a couple of examples for ideas. :-)
-Mike
Where do I find documentation on how to enable and use apache mods
rewrite and redirect?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Apache web server being attacked
--On Tuesday, May 18, 2010 18:00:16 +0800 Aiza wrote: Has anyone seen this junk hitting their apache web servers or have any different explanation of what this means? Any webserver on the internet will see that crap. Generally it's preceded by a syn scan to identify hosts listening on port 80, then everything but the kitchen sink shows up. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Apache web server being attacked
Aiza wrote:
> I put apache13 in a jail and left inbound port 80 open in my firewall.
> There is no domain name pointing to my web server. The content there is
> a small apache web application that fools web
> email address harvest programs into harvesting bogus email address from
> web page. http://www.monkeys.com/wpoison This is what I am doing.
>
> Since setting this up I have not had any bots scan the site for email
> address. But have had port 80 attacks that did not work. MY Apache
> access and error logs follow.
>
[snip log content]
> As you can see looks like a script kiddy is running something they dont
> understand. "/usr/local/www/data//phpmyadmin2/config.inc.php"
> there should only be a single / between data/phpmyadmin2.
>
> But beside that looks like php config.inc.php file is a target and
> phpmyadmin also is a target. The apache return code 404 means not found
> so no effect to me.
>
> Has anyone seen this junk hitting their apache web servers or have any
> different explanation of what this means?
Sorry to tell you this, but this kind of thing goes on all the time. You can
fine tune mod_security for some control for SQL injection techniques, as
well as many other generic forms of locking down the web server in general.
Generally speaking, the bulk of this does nothing more than filling the logs
- BUT - all it takes is for one app to let the attacker "leak" onto your
hard drive and they're in. I see a lot of scans for roundcube and
phpMyAdmin. Have also seen a lot of phpBB in the past.
The attackers spew lots of requests but the needle in the haystack they are
looking for is that one app that has a known vulnerability. In addition to
securing the web server itself you should monitor any app running on it for
reported security flaws and keep them updated to the latest "safe" versions.
You can also add to the hardening of your web server (if Apache) with
various .htaccess + mod_rewrite tricks. Examples include:
# block all smarty templates (no reason to have these exposed)
RedirectMatch gone ^/.*\.tpl$
# block all .log (log files), .sql (sql dump/export) and .conf (config
files) files in case some day these files move to another directory
RedirectMatch gone ^.*\.(sql|log|conf)$
# block access to the 'Smarty-*' directory
RedirectMatch gone ^.*Smarty.*$
# block common files present that you don't want served
RedirectMatch gone CHANGELOG.*
RedirectMatch gone COPYRIGHT.*
RedirectMatch gone INSTALL.*
RedirectMatch gone NEW.*
RedirectMatch gone README.*
RedirectMatch gone UPGRADE.*
RedirectMatch gone VERSION.*
# block access to directories
Redirect gone /upgrade
Redirect gone /tmp
Redirect gone /var
Redirect gone /sql
#Redirect pesky stuff based on referrer
Options -MultiViews -Indexes
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^Twiceler [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Morfeus [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Toata [NC]
RewriteRule .* - [F,L]
There is much and many more, just a couple of examples for ideas. :-)
-Mike
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Apache web server being attacked
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/05/2010 11:00:16, Aiza wrote: > I put apache13 in a jail and left inbound port 80 open in my firewall. > There is no domain name pointing to my web server. The content there is > a small apache web application that fools web > email address harvest programs into harvesting bogus email address from > web page. http://www.monkeys.com/wpoison This is what I am doing. > > Since setting this up I have not had any bots scan the site for email > address. But have had port 80 attacks that did not work. MY Apache > access and error logs follow. [lots of logfile traces elided] Yes. Unfortunately this sort of thing is the norm on the web nowadays. It's all automated: first they program their botnets to scan for a web server listening on port 80. Then they use them to attempt to compromise whatever they find -- in your case, most of what you're seeing is an attempt to gather information on what PHP capabilities your web server might have. What they are doing is trying in turn a lot of the popular locations for installing apps like phpmyadmin or phppgadmin. Yes, they are doing this in a particularly clueless fashion -- what exactly did you expect of the sort of people that think creating botnets is a good idea? They'll probably grow out of it when they hit puberty. In the mean time, as you don't have phpmyadmin or anything similar installed, this is just an annoyance for you -- it clutters up your log files but does nothing else. If you did want to install phpmyadmin on that server, you should take care to 1) Keep it up to date -- there haven't been any PMA security advisories for some months, but at one point they were coming out about one a week. PMA does have some very active developers though, and new versions appear every month or two. 2) Be sure to use access controls in your apache config to limit where PMA can be accessed from. Ideally, run it over HTTPS as well -- by its nature, you will tend to send DB passwords etc. to this application, and you want to avoid having them snooped. 3) If you use the on-line phpmyadmin configurator, be sure to clean up after yourself once you've generated a config file. To use the on-line configurator you have to create a directory /usr/local/www/phpMyAdmin/config which you make read/write by the user the webserver runs as. Once you've created the config.inc.php in that directory, you need to move it up one level in the directory heirarchy, and then delete the config directory you created. (That's what your attacker is so desperate to find -- because the directory is read-write by the webserver process, they can use it to upload malware to your system.) Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAkvybzsACgkQ8Mjk52CukIylCQCWJdEPLjihb2bSWUjUz5XcJ7eA eQCeLm59yL859kW9S9UkK7y1bjsZtTg= =tj/p -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Apache web server being attacked
I put apache13 in a jail and left inbound port 80 open in my firewall. There is no domain name pointing to my web server. The content there is a small apache web application that fools web email address harvest programs into harvesting bogus email address from web page. http://www.monkeys.com/wpoison This is what I am doing. Since setting this up I have not had any bots scan the site for email address. But have had port 80 attacks that did not work. MY Apache access and error logs follow. access log i97-173.shosting.systech.hu - - [06/May/2010:12:28:34 +0800] "GET //phpmyadmin/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 239 "-" i97-173.shosting.systech.hu - - [06/May/2010:12:28:35 +0800] "GET //phpMyAdmin/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 239 "-" i97-173.shosting.systech.hu - - [06/May/2010:12:28:36 +0800] "GET //PMA/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 232 "-" i97-173.shosting.systech.hu - - [06/May/2010:12:28:36 +0800] "GET //pma/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 232 "-" 53.163.158.61.ha.cnc - - [10/May/2010:16:05:42 +0800] "GET http://www.baidu.com/ HTTP/1.1" 404 206 "-" 60.190.59.240 - - [11/May/2010:03:50:54 +0800] "GET http://www.sina.com.cn/ HTTP/1.1" 404 206 "-" 91.212.127.100 - - [13/May/2010:10:09:08 +0800] "GET http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043SRQHP__FEG%5CUFT HTTP/1.1" 404 206 "-" scanner-4.hacktory.cs.columbia.edu - - [15/May/2010:14:10:28 +0800] "GET / HTTP/1.1" 404 206 "-" "-" 118.100.82.70 - - [15/May/2010:15:07:58 +0800] "|\xab\x1a\x06\xf5\xdd\x8a|\xfd\xde\xf9V\xf7\xf5\xaf\xe1\x8f\x0eF\xef\x18\xc8" 501 - "-" "-" 110.rmaxonline.com - - [16/May/2010:11:07:21 +0800] "GET //phpmyadmin/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 239 "-" 110.rmaxonline.com - - [16/May/2010:11:07:21 +0800] "GET //phpMyAdmin/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 239 "-" 110.rmaxonline.com - - [16/May/2010:11:07:22 +0800] "GET //PMA/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 232 "-" 110.rmaxonline.com - - [16/May/2010:11:07:22 +0800] "GET //pma/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 232 "-" 110.rmaxonline.com - - [16/May/2010:11:07:23 +0800] "GET //phpmyadmin2/config.inc.php?p=phpinfo(); HTTP/1.1" 404 233 "-" 110.rmaxonline.com - - [16/May/2010:11:07:23 +0800] "GET //phpMyAdmin2/config.inc.php?p=phpinfo(); HTTP/1.1" 404 233 "-" 110.rmaxonline.com - - [16/May/2010:11:07:23 +0800] "GET //mysqladmin/config.inc.php?p=phpinfo(); HTTP/1.1" 404 232 "-" 110.rmaxonline.com - - [16/May/2010:11:07:24 +0800] "GET //myadmin/config.inc.php?p=phpinfo(); HTTP/1.1" 404 229 "-" 110.rmaxonline.com - - [16/May/2010:11:07:24 +0800] "GET //MyAdmin/config.inc.php?p=phpinfo(); HTTP/1.1" 404 229 "-" 110.rmaxonline.com - - [16/May/2010:11:07:25 +0800] "GET //myAdmin/config.inc.php?p=phpinfo(); HTTP/1.1" 404 229 "-" 110.rmaxonline.com - - [16/May/2010:11:07:25 +0800] "GET //phpAdmin/config.inc.php?p=phpinfo(); HTTP/1.1" 404 230 "-" 110.rmaxonline.com - - [16/May/2010:11:07:26 +0800] "GET //mysql/config.inc.php?p=phpinfo(); HTTP/1.1" 404 227 "-" 110.rmaxonline.com - - [16/May/2010:11:07:26 +0800] "GET //phpAdmin/config.inc.php?p=phpinfo(); HTTP/1.1" 404 230 "-" net151.255.92-61.perm.ertelecom.ru - - [16/May/2010:13:43:05 +0800] "GET http://icqnums.freehostia.com/azenv.php HTTP/1.1" 404 215 "-" " 211.100.28.240 - - [17/May/2010:08:38:45 +0800] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 335 "-" "-" sd-17275.dedibox.fr - - [17/May/2010:11:27:02 +0800] "GET /roundcubemail/README HTTP/1.1" 404 226 "-" "Morfeus strikes again." sd-17275.dedibox.fr - - [17/May/2010:11:27:03 +0800] "GET /rc/README HTTP/1.1" 404 215 "-" "Morfeus strikes again." sd-17275.dedibox.fr - - [17/May/2010:11:27:04 +0800] "GET /webmail/README HTTP/1.1" 404 220 "-" "Morfeus strikes again." sd-17275.dedibox.fr - - [17/May/2010:11:27:05 +0800] "GET /roundcube/README HTTP/1.1" 404 222 "-" "Morfeus strikes again." sd-17275.dedibox.fr - - [17/May/2010:11:27:05 +0800] "GET /mail/README HTTP/1.1" 404 217 "-" "Morfeus strikes again." sd-17275.dedibox.fr - - [17/May/2010:11:27:06 +0800] "GET /README HTTP/1.1" 404 212 "-" "Morfeus strikes again." net151.255.92-61.perm.ertelecom.ru - - [17/May/2010:17:52:03 +0800] "GET http://icqnums.freehostia.com/azenv.php HTTP/1.1" 404 215 "-" ec2-79-125-7-31.eu-west-1.compute.amazonaws.com - - [18/May/2010:06:35:22 +0800] "GET //phpmyadmin/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 239 "-" ec2-79-125-7-31.eu-west-1.compute.amazonaws.com - - [18/May/2010:06:35:23 +0800] "GET //pma/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 232 "-" ec2-79-125-7-31.eu-west-1.compute.amazonaws.com - - [18/May/2010:06:35:23 +0800] "GET //admin/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 234 "-" ec2-79-125-7-31.eu-west-1.compute.amazonaws.com - - [18/May/2010:06:35:24 +0800] "GET //dbadmin/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 236 "-" ec2-79-125-7-31.eu-west-1.compute.a
