I recently went live with my drupal site. Now that I have the ability to monitor the site through watchdog more regularly, I am surprised at how many scans I get looking for vulnerabilities. Here is a tiny sampling of the 404 errors just this last week:
roundcubemail/README
roundcubemail-0.1/README
roundcubemail-0.2/README
phpmyadmin/main.php
phpmyadmin/setup/config.php
_vti_bin/owssvr.dll
MSOffice/cltreq.asp
google-analytics.com/ga.js
content/google-analytics.com/ga.js
/about/\" + gaJsHost + \"google-analytics.com/ga.js HTTP/1.1
pma/config/config.inc.php
b2b/admin/includes/stylesheet.css
phpmyfaq/admin
mspgmysql
xampp/phpmyadmin
typo3/phpmyadmin
blackhat.php/mysqladmin/config/config.inc.php
phpmanager/config.inc.php
pma2005/config.inc.php
These are clearly random scans looking for security vulnerabilities in popular products like typo3, phpmyadmin, and others, as well as just probing to find out information about my site (like whether I use roundcube mail).
I'm beginning to get paranoid... You would be paranoid too if several times a day thieves came up to your house and rattled the doors and windows to see if you left any unlocked.
Of course, the first line of defence is to keep Drupal and contrib modules up to date, which I do religiously. However, many of the attacks above seem to be simple attempts to glean information about the system (e.g. "roundcubemail/README"). So I think the best strategy is to reveal as little as possible.
To achieve this, I have done the following:
- Delete *.txt from the drupal root directory. -- There's no need for them to probe determine that I'm running drupal by reading "INSTALL.mysql.txt"
- Replace robots.txt with a more generic one that isn't clearly a Drupal robots.txt
I would also like to rename update.php to something else that only I know.
Is that a good idea, or does Drupal depend on update.php being named "update.php"?
What do the security gurus out there think? Might this strategy keep my site off hackers' lists of "sites that use Drupal", so that the next time they find a security vulnerability in Drupal, they won't all come running to my site?
Comments
I understand your paranoia. A
I understand your paranoia. A third of my job encompasses IT security and being paranoid comes with the trade. I've spent a number of nights eating popcorn while watching system logs for a number of personal owned sites. It's amazing how much effort hackers and bots spend trying to break into a system.
While you may get by renaming update.php, I personally think it is unnecessary. If someone really wants to know if you are running a Drupal site, all they really need to do is view the source code of your pages. Personally, I don't think preventing someone from finding out you're running a Drupal site really makes you that much more secure. If you really want to make sure your site stays secure the secret is making sure you update everything with the latest patches and updates. I'm not just talking about just making sure you update Drupal to the latest version, but also making sure you apply the patches and updates for your server's operating system, Web server, and even the version of PHP you are using. Doing this will get you a lot further than just renaming your update.php file. IMHO.
-Bryan
If you can rename update.php,
If you can rename update.php, it won't help obscure your site in any case... it's easy to identify a Drupal site by a very wide variety of methods, so you would have to waste an immense amount of time plugging every possible leak, and maintaining that with every upgrade as well. Every single module that has a readme or other text file is a clue even... and even more so, any module with a specific image file name or other characteristics would be very hard to obscure. Not worth it. Heck, Drupal is among the very most popular CMS's... all they have to do is blindly try a hack that applies to Drupal and if it works it works (e.g. if you have an outdated core/module, or if it is an as-yet-unknown insecurity that someone discovered).
Think about this - there are quite a few high profile sites running Drupal (for instance, a tantalizing target for a hacker might be... whitehouse.gov). But those sites do not make an effort to hide the fact they use Drupal (in fact many brag quite proudly hehe). They stay safe by keeping their core and modules upgraded, and by using safe practices when they add their own code (see the book Cracking Drupal). Also never use your admin (UID 1) account on a regular basis (only for development and maintenance... then set it aside). Use SFTP instead of FTP for accessing your site files, and make sure your host or server is up to date on security patches as well.
Hope this helps.
What about auto-disable
I understand your points. I guess I just need to make sure to keep my site as robust as possible using other means.
In the meantime, I'm on a shared host that throttles my CPU usage, making the site unbearably slow if it is engaged. When a hacker starts hitting my site multiple times in the span of a few seconds, it usually triggers my host's CPU throttling.
For example, 1 hour ago, I was hit with the following 404 errors all within a few seconds.
Obviously if someone has *phpmyadmin*, *.inc, *.php (except for index.php) or \" in their URL they are up to no good. Is there anyway to automatically ban an IP address that starts getting multiple hits for those "no-no" URLs? That way, the attacks at least won't slow down the rest of the site?
I wonder
This discussion led me yo wonder if anyone has developed a module to lock these people out. I mean, couldn't something be written to lock out the ip of any device that makes multiple calls to these urls that are outside the CMS?
Fight the evil bots!
A list of some of the Drupal sites I have designed and/or developed can be viewed at motioncity.com