Полный Кузнец, или как мы отразили DDoS-атаку и нашли дыру в WordPress

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

Также мы хотим обратиться к тем, чей сайт работает на WordPress, потому что принцип атаки был построен на уязвимости этой CMS. Мы считаем, что наша история дополняет карточки «Медузы» о том, что могут сделать хакеры с вашим интернет-ресурсом. Если после прочтения вы примените все новые знания, то в час Х обойдётесь без паники и траты времени. Мы вот не обошлись.

Всё началось с того, что нашей коллеге, ответственной за работу с клиентами, пришло вот такое сообщение в Telegram:

За этим удалённым аккаунтом стоял некто под ником Кузнец, и он не врал: нас действительно атаковали. Прежде мы не считали нужным обезопасить себя от DDoS-атак — зачем, если у нас обычный корпоративный сайт, а не сервис с высокой посещаемостью?

О Кузнеце нужно было узнать хоть что-нибудь. Для этого наш PHP-разработчик, интересующийся разного рода атаками и уязвимостями, покопался в логах сервера, на котором находится сайт livetyping.com. За пару-тройку дней набрался 800-мегабайтный архив, скрывавший в себе 11 гигабайт данных о том, кто, когда и откуда заходил на наш сайт.

Самым интересным в них оказалось то, что превалирующими были запросы через UserAgent WordPress; иначе говоря, наш сайт валил трафик с сайтов, построенных на WordPress. Их оказалось примерно три тысячи.

В результате мы обнаружили нечто более интересное, чем просто взлом.

У каждого из сайтов был включен интерфейс для удалённого управления платформой через POST-запросы по протоколу XML-RPC. Протокол включен по умолчанию и в обычной жизни используется, допустим, для размещения и удаления постов на WordPress-сайте, когда админ-панель недоступна. Но исследования публикаций на эту тему показали, что уже несколько лет злоумышленники используют XML-RPC для DDoS-атак.

Кузнец поступил так же. Из собранных WordPress-сайтов с включенным протоколом он сделал ботнет, чтобы отправлять запросы нашему сайту. Механика такая: атакующий обращался к этим сайтам, посылая в запросе .XML-строчку с адресом livetyping.com, и после рассылки все WordPress-сайты начинали его пинговать.

Если проще, то три тысячи WP-сайтов разом посылали запросы сайту livetyping.com, сервер не выдержал постоянной активности, перестал отвечать на все приходящие запросы, и сайт оказался недоступен.

Чтобы отразить эту атаку, мы включили на сервере фильтр по UserAgent WordPress. Кузнец это понял и сменил тактику.

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

CloudFlare пропускает трафик с сайта через свои центры данных, которые фильтруют запросы, похожие на DDoS-атаки. Под защитой у сервиса находятся данные таких компаний, как Uber, 1Password и Avito.

Атака была нарастающей — сначала из одной страны, потом из других. Фронтенд-разработчик вручную банил все подозрительные страны с большим количеством запросов, кроме России (Румыния, Бразилия, Албания, Индия, Индонезия и т.д.). Бан срабатывал по правилам, заданным в JavaScript Challenge. Это опция CloudFlare, с помощью математических операций проверяющая, кто пытается зайти на сайт — живой человек или вредный бот.

Во время проверки сайт на пять секунд блокируется такой вот заглушкой:

Через пять секунд CloudFlare делает редирект запроса на сайт при условии, что IP-адрес удачно прошёл JavaScript Challenge и признан безопасным.

В настройках JavaScript Challenge разработчик вносит подозрительные страны, запросы из которых считаются нелегитимными.

Когда радостей бесплатного CloudFlare нам стало не хватать, мы купили тариф Pro стоимостью $20 в месяц. К защите от DDoS, пропуску трафика через CDN-сеть и бесплатному SSL-сертификату добавилась система защиты Web Application Firewall, спасающая от SQL-инъекций и прочих атак, несущих сайту неприятности.

До подключения CloudFlare мы боролись с Кузнецом своими силами, но увы, сервер просто проседал от кучи запросов. DigitalOcean, на котором находится наш сайт, из коробки ничего для защиты не предоставляет; максимум, что мы могли бы сделать — это размазать нагрузку по нескольким серверам, но в любом случае это лишь помогло бы принять такой объём запросов, а не добавить защиты. Поэтому понадобился сервис узкого назначения, чья миссия — фильтровать трафик. Им и стал CloudFlare.

Но вместе с избавлением от Кузнеца CloudFlare создал нам несколько проблем:

Фильтрация CloudFlare из коробки довольно примитивна и для нас это скорее компромисс. Если вы хотите сервис, который постоянно отслеживал бы вредоносные страницы, подключите QRator, который позиционирует себя как главного по борьбе с DDoS у нас в стране.

Посчитаем траты с нашей стороны:

Итого: 14 317 рублей.

$500, которые с нас запросил Кузнец — это 32 934 рубля. Отказав ему, мы сэкономили 18 617 рублей, получили новый профессиональный опыт и поделились им с вами. Сохранённое чувство собственного достоинства оценке не поддаётся.

Сайт работает, злоумышленник остался ни с чем, а через базу WordPress-сайтов с работающим скриптом мы теперь диктуем свою непреклонную волю остальному мировому сообществу (в смысле, можем сами ддосить всех направо и налево).

Но вместо этого лучше предупредим: если ваш сайт работает на WordPress, его могут использовать во вред другим, а после он окажется заблокированным. Поэтому либо воспользуйтесь руководством о том, как отключить XML-RPC, либо делайте статичные сайты на конструкторах вроде Tilda.

Следите за собой, будьте осторожны.