Как защитить сайт от вирусов и взлома

Ильдар Сарибжанов | 20.04.2017

Введение

Этот будет пост-рассуждение на тему как защитить сайт от взлома и вирусов, больше просто поговорить и совсем немного кода и ссылок, а может и вообще без кода и ссылок. Как говорит мой отец перед началом любого дела: «как пойдет». Если не хочется читать мои художественные упражнения, то предысторию можно смело пропускать.

Предыстория

Одним прекрасным утром мальчик Ильдар получил от партнера сообщение, примерно следующего содержания: «Ильдар, у нас на mdd опять какая-то фигня, левые посты и с мобильников идет редирект». Говно-вопрос, подумал Ильдар, сейчас посмотри что к чему, не первый раз, скорее всего надо просто базу немного подчистить, и htaccess поправить. Открыл свой любимый FTP-менеджер, сконектился с хостингом, где лежит проблемный сайт, поправил всё что хотел и история закончилась.

Вот и всё! Можете расходиться, продолжения не будет =)

Ладно-ладно. Всё только началось, поскольку о себе в третьем лице писать как-то странно, дальше от первого лица.

Я отписался товарищу, мол так и так, работа выполнена, пароли сменил, должно быть хорошо. В ответ получаю сообщение, что не всё хорошо, потому что редирект продолжается. Лезу смотреть htaccess, а он снова изменен. Пошел смотреть чуть глубже и обнаружил, что где-то в недрах WordPress лежит левая папка и чего-то себе там запускает. Эмм?! К тому моменту я уже был смекалистый, пошел посмотреть какие еще файлы были изменены недавно. Надоело ходить вокруг да около. На хостинге лежало чуть больше двух десятков сайтов на wp, еще несколько на других движках, и все они были заражены, не только файлы но и базы. Помнишь звук сообщений в аське? (Мессенджер такой ICQ, который был куплен mailru. Правда википедия говорит, что это сервис, а не мессенджер, но не суть) «О-оу!» — промчалось в моей голове. Свой инженерский диплом и кандидатскую начинал писать на тему всяких интерполяций и экстраполяций различных функций и сигналов, короче, считать немного умею: на один сайт я потратил примерно полчаса, а на 25? Соответственно 12,5 часов. «Нехорошо», — подумал я…

Не буду рассказывать как героически преодолевал эту проблему, но с того момента ряд полезных выводов сделал.

Как защитить сайт

Никак.

Это самая главная мысль. Если её не усвоить, то всё дальнейшее боль и страдание.

Хотя есть один способ, записывай:

  1. нужна большая флешка.
  2. нужно сайт скачать на эту флешку
  3. Положить флешку в банковскую ячейку.
  4. Profit!

Во всех других случаях, я не настаиваю, можешь попробовать сам пройти весь путь, но (!) Пройдемся по тем пунктам, которые рекомендуют многие ресурсы:

  1. Установите сложный пароль на админку. Сделано. Дыра в движке и сложный пароль никому не нужен, тупо забыл об экранировании символов в форме комментариев и какой-нибудь умник всё доделает за тебя. Допустим у нас нет дыр в движке.
  2. Установите сложный пароль на хостинг-панель. Сделано. «Ой, база паролей утекла в сеть, мы рекомендуем сменить ваш пароль и приносим свои искренние извинения»
  3. Запрети изменение файлов. Если кто-то ломает хостинг или сервер, то уж что-что, а поменять права не проблема.
  4. И еще стотыщмильёнов вариантов защиты

Все они так или иначе ломаются. Если нельзя сделать защиту на 100%, что делать?

Профилактика и своевременное обнаружение

Нужно обновлять свой сайт, не очень понимаю людей, которые установили 3 года назад движок и не обновляли его. Дыры находятся и закрываются. Это профилактика. Все сайты на поддержке и внутренние мы обновляем. По крайней мере, стараемся.

И самое главное — нужно вовремя увидеть проблему. Лично я, после того случая с сервером mdd, написал небольшой скриптик на php, который положил в cron, и каждые 2 часа он проверяет дату последнего изменения файлов на хостинге, в случае обнаружения изменений мне приходит сообщение со списком измененных элементов. Сначала я придерживался политики белых списков, т.е. проверял только те файлы, которые меня интересовали, но потом решил, что это слишком халявно и перешел на политику черных списков, проверяю всё кроме картинок. Если кому интересно, скрипт, конечно же, выложил на гитхаб.

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

Бэкапы

Наше всё. Во-первых, это в принципе очень хорошая практика, а во-вторых, если заражение фатально, то поднять не очень старый бэкап может быть единственным способом быстро восстановить работоспособность сервиса или сайта. Про бэкапы уже много написано и без меня,но на почве последних падений хостинга, где размещается наш сайт, еще раз напомню, что хранить бэкапы очень желательно на отдельном носителе, само правило звучит так: не храни бэкапы там же где лежит основной сайт — это бессмысленно, сыпется жесткий, умирает SSD и доступы пропадают ко всему и к боевой версии и к бэкапам. Заведи для себя правило, раз в месяц забирай полный бэкап куда-нибудь себе, например в облака. Думаю, что копия месячной давности лучше, чем вообще без копии. Я понимаю, что сайтов много и все их бэкапить вручную долго, но тыжпрограммист, придумай способ автоматизировать процесс. Если придумаешь, напиши мне, я еще не придумал =)

Выводы

Нужно принять мысль, что абсолютной защиты не бывает. После принятия нужно подготовиться к наступлению задницы, она обязательно придет, и это случится именно в тот момент, когда будет неудобно. Такие вещи не случаются вовремя.

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

Всем рок!