Что если плагины безопасности CMS не защищают сайт от взлома?
26.09.2014 | Автор: Григорий Земсков, «Ревизиум» (Директор компании, эксперт по информационной безопасности сайтов) 
Для надежной и бесперебойной работы сайту нужно обеспечить комплексную безопасность. В одной связке должны работать WebApplicationFirewall (WAF) или проактивная защита, контроль целостности файловой системы, продвинутая система резервного копирования, многофакторная аутентификация для панели администратора и многие другие технологии, которые выполняют мониторинг и защищают сайт от компрометации, ограничивая доступ к информации и панели управления неавторизованным пользователям. Редкие системы управления сайтами (CMS) могут похвастаться встроенными средствами, обеспечивающими безопасное функционирование и защиту от взлома. В большинстве популярных CMS (Wordpress, Joomla, Drupal и др) в версиях, что называется, «из коробки» весьма скудный набор средств защиты сайта.
Что делать, если система управления сайтом не включает нужные компоненты безопасности? Их недостаток легко компенсируется плагинами, одна часть которых — это узкоспециализированные расширения, например, выполняющие только процесс резервного копирования и восстановления сайта (WordpressDBBackup, AkeebaBackup и др.), а другая — многофункциональные плагины, которые выполняют мониторинг активности, блокировку, фильтрацию и восстановление данных (SucuriSecurity, RSFirewall и др.)
Преследуя цель максимально защитить сайт от взлома, вебмастер устанавливает все доступные securityплагины, следуя принципу «безопасности не бывает слишком много». А для большей надежности подключает сайт к внешним антивирусным сервисам, которые также пытаются защищать сайт от вредоносного кода. Вначале сайт работает стабильно, в штатном режиме, но спустя некоторое время с аккаунта хостинга почему-то начинает рассылаться спам, а при входе на сайт с мобильного устройства некоторых посетителей перебрасывает на «ресурс для взрослых». При тщательной проверке аккаунта хостинга выясняется, что сайт все-таки взломали. Возникает вопрос — как это могло произойти, если сайт все это время был защищен плагинами безопасности и специализированными сервисами?
Правда жизни такова, что ни расширения CMS, ни антивирусные сервисы не могут гарантировать безопасность и защиту сайта.
Альберт Эйнштейн утверждал: «Невозможно решить проблему на том же уровне, на котором она возникла. Нужно стать выше этой проблемы, поднявшись на следующий уровень…». Данное высказывание как нельзя лучше описывает проблему защиты сайта. С той лишь разницей, что понятие «подняться на следующий уровень» фактически означает перейти на уровень системы, которая управляет скриптами сайта и протоколом прикладного уровня HTTP / FTP, то есть уровень операционной системы и сервера. Поскольку плагины являются частью системы управления сайтом, а антивирусные сервисы работают на том же уровне скриптов и HTTP протокола, с помощью них невозможно организовать защиту сайта. Можно лишь выполнять мониторинг и извещать владельца сайта о возникших проблемах. Да и то не всегда.
Для того чтобы обеспечить безопасность сайта и гарантированно защитить его от взлома, нужно знать, как злоумышленник проникает на сайт, как получает доступ к ресурсам и закрепляется в системе. Незнание этих техник приводит к неправильной политике безопасности и, как следствие, взлому сайта. То есть для установки эффективной защиты на сайт нужно в некотором роде думать и действовать как хакер.
Рассмотрим наиболее частные векторы атак на сайт, которые используются хакерами.
1Эксплуатация уязвимостей скриптов плагинов и CMS К популярным уязвимостям из можно отнести ArbitraryFileUpload (загрузка произвольного файла на хостинг), RemoteCodeExecution (удаленное исполнение кода), SQL/ noSQL Injection (иньекции в запрос к базе данных), Remote (Local) FileInclusion (удаленное/локальное подключение файла), XSS (Межсайтовый скриптинг), XSRF (Межсайтовая подделка запросов), XXE (Обработка внешних сущностей XML) и др. Злоумышленник может обнаружить уязвимость, позволяющую получить доступ к данным сайта, загрузить хакерский шелл или подготовить определенным образом сформированный код, с помощью которого можно украсть куки с аутентификационной информацией (например, хэшем пароля). В результате чего информация на сайте оказывается скомпрометированной, а хакер может получить полный контроль над всеми сайтами аккаунта хостинга и использовать их по своему усмотрению.
2Атака на панель администратора (Брутфорс или кража пароля) Подбор пароля (брутфорс), перехват пароля доступа к административной панели или кража хэша из куки сайта также чрезвычайно популярны среди хакеров. Получив доступ в админ-панель сайта, хакер получает возможность манипулировать файлами хостинга или шаблонами сайта, а также получить доступ к конфиденциальной информации, загрузить вредоносный скрипт или разместить вирусный код на страницах сайта.
3Взлом через FTP (Брутфорс пароля, перехват пароля, кража ключей, атака MITM) Перехват или подбор пароля от FTP доступа — не менее популярный вариант взлома сайта. Получив доступ на хостинг, хакер также как и в случае получения доступа в админ-панель, может выполнять множество операций над файлами сайта и загружать вредоносные и хакерские скрипты. Поскольку протокол FTP открыт, а вебмастера не следуют технике безопасности (подключаются к хостингу в открытых wifiсетях, хранят пароли в FTP клиенте), перехватить или украсть FTP аккаунт достаточно просто.
4Взлом через SSH (Брутфорс пароля, перехват пароля, кража ключей, атака MITM) Перехватить SSH доступы к хостингу сложнее, чем FTP, поскольку протокол использует безопасный транспортный уровень с шифрованием трафика, но все же возможно. Современные хакерские приложения (например, Intercepter-NG) могут выполнять туннелинг SSH трафика, тем самым выполнять атаку MiTM («человек посередие»), инжектировать в SSH сессию данные и манипулировать файлами на хостинге. Но возможны и более простые способы, когда SSH сервис работает на стандартном порту 22 и на аккаунте простой для подбора пароль.
5Взлом через «соседей» по хостингу На многих хостингах сайты размещены в общем файловом пространстве, а базы данных работают на том же сервере. Поэтому для получения доступа к целевому сайту, хакер находит другой, менее защищенный ресурс на том же сервере и атакует нужный сайт через «соседа». Например, у атакуемого сайта можно узнать доступы к базе данных в файлах wp-config.php, configurations.php и т.п., инжектировать в базу новый административный аккаунт или загрузить бэкдор с помощью SQL запроса. Современные хакерские инструменты позволяют автоматизировать данный процесс, поэтому вся атака занимает считанные доли секунды. Проведение данной атаки возможно при неграмотном администрировании сервера со стороны хостинга или невежественности веб-мастера, проставляющего права на файлы и папки своего сайта.
6Атака на панель администратора хостинга (Брутфорс пароля, эксплуатация уязвимостей) Программного обеспечение, представляющее собой панель управления хостингом, также может содержать уязвимости. Хакер может воспользоваться базой данных известных уязвимостей или попытаться подобрать пароль, в результате чего получить полный контроль над хостингом.
7Эксплуатация уязвимостей операционной системы и сервисов хостинга Время от времени в сетевых сервисах операционной системы обнаруживаются уязвимости, которые позволяют злоумышленнику выполнять несанкционированные операции и получать неавторизованный доступ к ресурсам. Если системный администратор не следит за критическими обновлениями операционной системы и программного обеспечения, хостинг могут взломать, скомпрометировав все сайты на сервере (подобное было в 2011 году с хостингом InMotion, в результате чего около 70000 сайтов оказались взломанными).
Как мы можем видеть, у хакера есть много возможностей провести атаки на сайт. Попробуем оценить эффективность плагинов и внешних антивирусных сервисов для защиты от этих атак.
Закрытие «дыр» на сайте (пресечь эксплуатацию уязвимостей) Закрыть уязвимости в скриптах с помощью плагинов безопасности можно лишь частично. Многое в данном случае зависит от CMS и полномочий, которые предоставляются расширениям, модулям и компонентам. Если расширения безопасности наделены привилегиями фильтровать входные пользовательские запросы и данные, приходящие от базы данных, то основные уязвимости из списка OWASP они могут закрыть. А что если ошибки или уязвимости присутствуют в самих плагинах безопасности (Например, BulletProof Security CVE-2013–3487, CVE-2012–4268, Better WP Security CVE-2012–4264, CVE-2012–4263) или некоторые скрипты работают в обход жизненного цикла CMS (например, скрипт масштабирования изображений timthumb.php, визуальный редактор fckeditor)? В этом случае брешь остается открытой, и защитить сайт от взлома плагинами не удастся.
Работа внешних антивирусных сервисов также не сильно спасает, так как они в большинстве случаев выполняют функцию мониторинга, а не защиты. Эффективны те сервисы, которые работают как Web Application Firewall, фильтруя HTTPзапросы от клиентов до момента передачи управления скриптам CMS. Если сервис или скрипт выполняет регулярную проверку файлов (обычно, по резервным копиям) или изменений на хостинге, то он не защищает сайт от взлома, а просто информирует об этом, и, порой, ошибочно или несвоевременно. Таким образом, уязвимости на сайте невозможно на 100% закрыть плагинами и внешними сервисами.
Защита панели администратора от несанкционированного доступа В настоящий момент существует большое число плагинов, защищающих панель администратора (LoginLockDown, jSecure, RSFirewallи др). Они отлично справляются со своей задачей, блокируя ботов, подбирающих пароль или пользователей, которые входят с неразрешенных IP адресов. Но в целом не сильно повышают уровень безопасности административной панели, так как остается множество способов получения административного доступа минуя «парадный вход» (например, добавление в базу нового администратора через SQL инъекцию, подделка сессии или использование куки администратора для быстрой авторизации), особенно при целевой атаке на сайт. Поэтому этот вектор, как и предыдущий, не исключается на 100% ни плагинами, ни сервисами.
Защита от других вариантов взлома Как можно догадаться, от взлома сайта через FTP, SSH или панель управления хостингом плагины сайта и антивирусные сервисы не могут защитить физически, так как работают на совершенно другом уровне и в общем случае не связаны с сайтом.
Становится очевидно: securityплагины не являются панацеей от хакерских атак и не могут защитить сайт от взлома, какие бы функции мониторинга и защиты в них ни были реализованы.
Возникает вопрос, есть ли другие варианты повышения уровня безопасности сайта под управлением CMS? Для этого воспользуемся советом Эйнштейна и будем искать решение по защите сайта на более высоком уровне (а применительно к архитектуре сервера — наоборот, на более низком).
Защита от атак по HTTP (через веб) Если мы будем использовать инструментальные средства уровня файловой системы, веб-сервера и PHP интерпретатора, то сможем закрыть возможность эксплуатации уязвимостей через веб. Для этого существует процедура «CMSHardening» (так называемое «цементирование сайта»), которая состоит из следующих элементов:
Изменение прав на файлы и папки
Запрет несанкционированного выполнения скриптов
Аутентификация администратора средствами веб-сервера
Отключение ряда системных функций PHP
Сначала рассмотрим идеальный вариант. Если сделать все файлы и папки сайта «только для чтения», отключить системные функции и chmod, закрыть серверной аутентификацией панель админа и доступ к инструментам (например, phpMyAdmin) и настроить WAF, ни у хакеров, ни у ботов не останется физической возможности что-то загрузить или осуществить изменения на сайте через PHPскрипты, а также провести успешную атаку на базу данных. Вот почему:
Нельзя загрузить веб-шеллы/бэкдоры и другие скрипты на сайт, так как все директории установлены «только для чтения»
Сделать их доступными на запись хакер не сможет, так как отключены все системные функции и chmod
Если на сайте уже был загружен веб-шелл, выполнить им какие-то изменения в файлах и директориях не получится, так как PHP функции, которыми это можно сделать — отключены в php.ini
Вроде бы можно сделать изменения в БД через SQL инъекции, но WebApplicationFirewall блокирует подобные HTTPзапросы
Выполнить изменения на сайте через панель администратора или инструменты по работе с БД не получится, так как мешает аутентификация средствами веб-сервера (например, доступ только с определенных IP, прописанных в .htaccess файле).
В теории звучит заманчиво, на практике некоторые CMS при подобном «затягивании гаек» перестают нормально работать. Поэтому защиту требуется немного ослабить. Часть каталогов должна оставаться доступной на запись (в частности все cache/upload/tmp/backup), но доступ к ним через HTTP должен быть либо закрыт (DenyfromAll в .htaccess файле), либо разрешен только для выгрузки файлов определенных форматов (php_flag engine 0 и разрешить выгрузку только изображений/мультимедиа/документов и .js с .css). Некоторым плагинам требуется загрузка данных с внешних серверов, поэтому придется разрешить allow_url_fopen = 1 и функцию fsockopen в php.ini.
Что касается WAF, настроить его для идеальной фильтрации HTTP запросов — это процесс не одного дня. Скорее всего правила firewallпридется дополнять или исправлять и даже какое-то время его «обучать» легитимным запросам, чтобы он научился отличать их от хакерских.
Стоит также отметить, что атаки могут проводиться не только для получения доступа к информации или выполнения несанкционированный действий на сайте, но и для вывода из строя сервера или операционной системы путем исчерпания ресурсов (так называемый DOS). Против DOS атак (не путать с внешней DDOS) плагины и сервисы также не защищают, поскольку отказ в обслуживании может быть в результате выполнения легальных обращений к сайту.
Обратная сторона медали Следует помнить, что защита не бывает удобной. Чем более защищен сайт (чем более строгая политика безопасности), тем более неудобно администраторам его обслуживать. Например, самый эффективный вариант защиты панели администратора — аутентификация по IP. Но для этого у администратора должен быть статический IP адрес, в противном случае ему придется ежедневно менять его в файле .htaccess, nginx.conf или хостинг-панели.
Если в шаблоны вносятся постоянные коррективы, придется делать их доступными для записи, а затем снова «только для чтения». Для обновления CMS и плагинов также требуется «снятие» подобной защиты. Данная процедура кажется особенно тяжелой для неопытных веб-мастеров, и они, порой, в ущерб безопасности, принимают решение убрать часть защиты, разрешив запись во все файлы и каталоги.
Поэтому в вопросе защиты CMS необходимо найти баланс между удобством обслуживания сайта и тем уровнем безопасности, который устроит его владельца.
Защита от взлома со стороны хостинга До этого мы рассматривали только защиту от веб-атак, но есть масса способов взломать сайт через FTP, SSH, панель управления хостингом и с соседних сайтов. Повысить безопасность этих сервисов и компонент также можно.
Перестать пользоваться небезопасным FTP и перейти на SFTP протокол. Если такой возможности нет — разрешить подключение по FTP только с авторизованных IP адресов.
Устанавливать сложные пароли на FTP и SSH. Не сохранять их в клиенте и чаще менять.
Использовать нестандартные порты для подключения по FTP/SSH.
Максимально изолировать сайты на хостинге: размещать их в разных пользовательских аккаунтах, использовать минимально-возможные права на доступ к файлам и каталогам.
Регулярно обновлять панели управления хостингом.
Устанавливать патчи безопасности на ядро сервера и его сервисы.
(последние два пункта на виртуальных хостингах — это забота системных администраторов).
Чем больше из перечисленного удастся воплотить в жизнь, тем в большей безопасности будет сайт.
Резюме Возникает вопрос — что же делать с плагинами безопасности для CMS. Стоит ли ими пользоваться?
Некоторые из них действительно стоят того, чтобы их установить, так как они выполняют мониторинг, резервное копирование и контроль целостности файловой системы. Но основными элементами защиты все-таки должны быть средства хостинга: грамотная настройка сервера, а также максимальные ограничения и контроль со стороны файловой системы, веб-сервера и php интерпретатора.
Полный текст статьи читайте на CMS Magazine
