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"

Reply via email to