За последние время сделали три сайта на движке Joomla. Все три сайта подхватили заразу в течение месяца. На момент запуска движок был самой последней версии, все расширения тоже. Почему же так происходит и что делать?
До 2015 года в течение 18 лет я не использовать в разработке сайтов бесплатные популярные движки. Практически все делалось на самописном движке на языке perl, которые покрывал, да и сейчас покрывает, все нужды. За этот период из всех сделанных сайтов сломали ровно ноль. Да, ни одного. У движка есть другой недостаток – не очень хорошая масштабируемость и прожорливость памяти, но последние версии бесплатных движков на php его догнали в этом плане, и даже обогнали.
Причины такой непробиваемости две: низкая популярность и принципиально другой подход. Низкая популярность сразу же снимает интерес к сайту со стороны спам-сетей, которые заинтересованно в массовом инфицировании сайтов для целей рассылки спама. Десятки и сотни сайтов на одном движке им не интересны в принципе. Усилия не окупятся. Второй момент это принципиально другая философия программирования, которую исповедуют программисты на perl. Сейчас популярность этого языка сильно снизилась, по сравнению с началом 2000. И причиной тому не его отсталость или еще что-то. Причина в том, что его нормально освоение требует нормального системного программистского подхода, которым большинство «типа» программистов php не обладают. По набору модулей для работы на все случаи жизни php до сих пор далеко позади, как и по набору функций безопасности, которые делают жизнь сложнее, но обеспечивают невозможность инъекции кода.
И дело не в том, что php плох. Дело в подходе. Если программист нормальный, то он и на php будет программировать так, чтобы обеспечить тот же уровень безопасности и изоляции. Это вполне возможно, если немного постараться.
Из-за этого складывается опасная ситуация. Сам движок обычно разрабатывается опытными профессионалами с учетом всех рисков. Там дыры бывают, но редко. Но вот расширения делаются кем попало, их качество зачастую оставляет желать лучшего. Некоторые расширения вообще в принципе опасны и их надо использовать с головой, но как раз головы может не хватить уже разработчику сайта, а потом не хватит администратору сайту, у которого к таким модулям есть доступ.
Отсюда первый вывод: хотите быть в безопасности, надо разрабатывать сайты не на готовых популярных движках, а делать их на framework-ах (т.е. базовых программных библиотеках) или с нуля. Это дорого и долго, но уровень безопасности будет на порядок (или даже на порядки), выше.
Если же используется бесплатный движок, особенно с расширениями, то проблемы рано или поздно найдут этот сайт. Что же делать?
- Отказаться от shared хостинга. Shared хостинг это когда на одном аккаунте находятся несколько сайтов, которые имеют доступ к файлам друг друга. Эта система сейчас очень популярна в тарифах. Выглядит примерно так: 10ГБ места, до 10 сайтов, до 20 баз. Заражение одно сайта из 10 практически со 100% вероятностью приводит к заражению всех 10. Кроме этого вирус получает доступ ко всем базам данных сайтов и может встроить себя и туда. Чистка этого все не стоит никакой экономии на хостинге. Если сайт работает на популярном движке, он должен быть изолирован от всех остальных сайтов.
- Резервное копирование должно осуществляться за очень длительный период. Минимум за 6 месяцев, пусть даже с малой периодичностью. Обязательно должна быть снята копия сайта перед запуском. Это связано с тем, что очень часто о заражении становится известно спустя недели, а то и месяцы. Как выяснить какие файлы были добавлены или изменены? Конечно, можно скачать дистрибутивы и сделать сравнение файлов в них, с тем, что на сайте (команда diff), но не всегда доступны те же версии, что-то могли сами менять. Сравнение таким образом более трудоемкое. Поэтому проще распаковать оригинальную копию сайта и сравнить два дереве той же командой diff, выявив отличающиеся файлы и далее анализировать их глазами.
- Журналировать POST запросы. Все инъекции, которые я видел, всегда использовали POST запросы или на стадии взлома или на стадии вставки кода/рассылки задания. Добавив в главный index.php и в административный index.php следующий код и настроив ротатор лога (хранить минимум 6 месяцев!), вы сможете видеть реальные атаки на сайт и попытки передать задачу. Анализом файлов, к которым идет обращение, можно понять, подхватил ли сайт, что-то или нет.
if ($_SERVER['REQUEST_METHOD'] === 'POST') { $la = localtime(time(), true); $la[tm_mon]++; $la[tm_year]+=1900; file_put_contents("/sitedir/logs/post.log", "\n\n---------------------------------------------------------------\n$la[tm_year]-$la[tm_mon]- $la[tm_mday] $la[tm_hour]:$la[tm_min]:$la[tm_sec]\n",FILE_APPEND|LOCK_EX); file_put_contents("/sitedir/logs/post.log",print_r($_POST,true),FILE_APPEND|LOCK_EX); file_put_contents("/sitedir/logs/post.log",print_r($_SERVER,true),FILE_APPEND|LOCK_EX); } - Запретить изменение файлов и директорий с движком, библиотеками, расширениями и шаблонами.
Например для joomla:
chmod –R o-w,g-w,u-w components language layouts libraries modules plugins templates administrator/components administrator/help administrator/includes administrator/language administrator/manifests administrator/modules administrator/templates administrator/index.php index.php configuration.php
Это довольно неудобно, так как сделает невозможным обновление системы, без возврата права на изменение, но это реально помогает от всех взломов, которые мне встречались. Удивительно, что эта функция не встроена в сам инсталлятор движков и удивительно, почему при заражении код взломщика не догадывается сделать chmod с правом на запись. От последнего можно защитится не только поменяв права, но и сменив владельца файлов на того, под кем не работает веб-сервер. Тогда при взломе не будет никакой возможно сменить права. Проблема в том, что для этого требуется либо VPS хостинг и толковый настройщик веб-сервера и сайта либо хитрый хостинг, который это позволит сделать. - Периодически сканировать сайта на зловреды. Опять же, из опыта, ни один антивирус (dr.web, каперский, clamAV) не ловят вообще ничего. Просто ноль. Реально работающая вещь: https://revisium.com/ai/. Ее надо повесить на крон, и настроить отправлять отчеты еженедельно. Отчеты этого сканера надо воспринимать как информацию к анализу, это не готовые 100% средство. Дает много лишних файлов. Второй вариант, и он просто необходим, это самописный сканер MD5, который будет снимать список файлов с сайта, делать MD5 для каждого, сохранять куда-то и в следующий раз снова сканировать и сравнивать. Это дает 100% гарантия выявления изменений. Только на дату изменения смотреть нельзя, так как при заражении обычно даты файлов устанавливаются в прошлом.
Используя эти 5 советов поиск зараженных файлов, восстановление работы сайта и закрытие дыр займет не более получаса.