Безопасность CMS систем

При разработке проектов различного масштаба проблема безопасности часто откладывается «на потом», а экспертиза в этом вопросе сводится к накидыванию стереотипов – кто каких нахватался. Мне часто приходится слышать при обсуждении стека проекта аргументацию, что, мол, «Битрикс не безопасен», «Wordpress – решето», «любой Opensource вообще зло, т. к. за него никто не отвечает» и т. п.

Как всегда в «не черно-белом мире», все эти утверждения имеют в своей основе зерно истины, однако не являются столь однозначными. О чем я и хотел бы поговорить в данной статье и помочь взглянуть на проблему более глубоко – тем, кто особо не нырял в детали.

Почему и зачем сайты вообще заражают? Тут может быть несколько общих сценариев:

Рассмотрим сперва первые два случая. Цели у «вирусов широкого профиля» могут быть разные: например, эксплойт попытается модифицировать контент на вашем сайте, отобразить рекламу или перевести пользователя на другой ресурс. А, возможно, ваш сайт ему вовсе не нужен и конечная цель атаки – это посетитель сайта, у которого в браузере запустится вредоносный JavaScript. Либо же наоборот, атака будет направлена «внутрь», на ваш сервер, чтобы, например, использовать его мощности для проведения других атак или банально для майнинга / рассылок и т. п.

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

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

Принципиально подход тут тот же, но «градус паранойи» должен быть на порядок выше. А значит и затрат это потребует бОльших.

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

Про регулярные бэкапы я вообще молчу – это святое. И относится, скорее, к теме восстановления после апокалипсиса, а не к вопросу о предотвращении такового.

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

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

Также, в среде разработчиков есть базовые правила по написанию кода, безопасных SQL-запросов и обработки запросов к серверу. Они настолько базовые, что их несоблюдение – это на сегодняшний день уже на грани профнепригодности, поэтому качество команды тут встаёт на первый план. При этом я не отрицаю возможность привлекать на проект джунов – напротив, порой даже на очень сложных проектах они могут быть полезны. Но важно, чтобы в команде разработки был поставлен на поток процесс код-ревью, был грамотный и ответственный тимлид.

Наконец, слабым местом любой CMS или фреймворка является админка. То есть взломать могут в первую очередь компьютер пользователя, получить логин и пароль в админку, и там уже…. В такой ситуации дополнительно закрывать вход в административную часть с помощью, например, корпоративного VPN или белого списка IP- адресов – мера более чем адекватная.

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

Если вы стали жертвой «вируса широкого профиля», то скорее всего это даст о себе знать одним или несколькими симптомами:

Как разработчики производят поиск вируса? Часто проблема находится вручную. Например, в коде заражённой страницы сайта разработчик находит подозрительный паттерн, после чего запускает сканирование всех исходников проекта на наличие этого паттерна или его фрагмента. Найденные файлы стоит сперва проанализировать, а не вслепую удалять, т. к. возможны ложные срабатывания, особенно если ваш проект использует какие-либо пропиетарные библиотеки с обсфуцированным кодом: этот метод используется как для защиты авторских прав, так и для шифрования содержимого эксплойта, чтобы скрыть механику его работы.

Вот для примера содержимое одного из вирусных файлов:

Маловероятно, что разработчики сайта будут сами писать такой код 😊

Но есть и автоматизированные средства проверки. Правда, скорость их обновления часто не соответствует частоте выхода новых эксплойтов. Например, для Битрикса есть модуль, который не обновлялся уже два года. И хотя сами разработчики Битрикса, начиная с версии 23, включили утилиту «поиск троянов» в свой «проактивный фильтр» – не стоит полностью полагаться на то, что если этот модуль ничего не нашел – значит на сайте точно ничего нет. Всегда отчёты и рекомендации любых автоматизированных инструментов приходится верифицировать вручную и проводить дополнительный поиск.

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

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

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

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

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

Когда получил доступы к «уничтоженному» сайту, выяснилось, что все файлы на месте, но предыдущая команда разработчиков пыталась удалить вирусный код из ядра Битрикс. Для этого они запустили обновление системы, но не уточнили комментарии к новому релизу, а там было указано, что нужно сменить версию PHP. Вообще они её сменили, да не на ту… в итоге обновление завершалось с ошибкой, а сам сайт не работал, потому что частично содержал код, несовместимый с указанной в панели хостинга версией.

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

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

Безопасность и защищённость web-приложения – это, по сути, тоже «фича», на реализацию которой требуется потратить время и деньги. Продукт не может быть безопасным просто «сам по себе», просто потому что сделан «лучше», чем другие продукты. Качество кода, используемые технологии и архитектура — это лишь один из факторов, важный, но не исчерпывающий.

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

Основная же причина, по которой система становится уязвимой, будь это просто сайт или нечто более сложное – это не столько выбор «неправильной» технологии, сколько отпускание процесса «на самотёк», если не на этапе разработки, то на этапе эксплуатации. Ведь так хочется всего только один раз вложиться в написание IT-продукта, а дальше чтобы он работал годами сам!.. Но, фактически, как бы хорошо ни была разработана система – она всё же требует регулярной поддержки и мониторинга, актуализации кодовой базы и сопутствующего софта. В том числе для закрытия возможных уязвимостей.