Мир тряхнуло DDoS-атаками: как мы справились и что делать вам

Вчера (28 февраля) вечером с 18:40 до 20:00 несколько раз прерывалось соединение с виртуальными серверами некоторой части наших клиентов.

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

Атака так или иначе затронула ЦОД всего мира. Разумеется, в большей степени оказались затронуты Европа, Азия и Северная Америка. Ниже приводим иллюстрацию из поста в блоге компании CloudFlare, специализирующейся на противодействии DDoS-атакам.

Сам пост доступен по этой ссылке. Он содержит весьма подробное описание механизмов, использованных злоумышленниками, и некоторую статистику.

Что происходило

В 18:40 мы зафиксировали перегрузку каналов передачи данных в одном из сегментов нашей сети. Её вызвали потоки однотипных UDP-пакетов, передаваемых с виртуального сервера одного из наших клиентов на несколько узлов в сети Интернет. Этот трафик пришлось заблокировать, а в течение следующего часа пришлось заблокировать точно такой же трафик ещё от нескольких машин других клиентов.

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

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

Эта уязвимость не позволяет получить доступ к каким-либо данным, но её эксплуатация позволила атакующим использовать некоторые машины клиентов, администраторы которых в своё время установили memcached, но при этом оставили его открытым ко всем запросам из сети Интернет..

Всего в атаке принимало участие менее десятка виртуальных машин, которые были уязвимы. Это менее 1% от общей численности машин в нашем облаке, но эти всплески активности могли создавать значительные помехи в работе для остальных 99% машин. Тем не менее, благодаря распределённой архитектуре нашей сети, проблемы в работе проявлялись только у примерно 15% машин: в течение первого часа было несколько периодов, когда связь с этими машинами была нестабильной, а пользователи констатировали потери пакетов и обрывы соединения.

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

Мы действовали оперативно, и уже к 20:00 все источники были выявлены и заблокированы.

На что следует обратить внимание нашим клиентам

Мы не сторонники того, чтобы как-либо ограничивать трафик, передаваемый и принимаемый виртуальными машинами пользователей, но в этот раз, чтобы предотвратить рецидив, мы были вынуждены предпринять довольно радикальные меры, полностью запретив передачу UDP-пакетов из сети Интернет ко всем виртуальным машинам на порт 11211. Такое решение было принято и реализовано сегодня, 01.03.2017, поэтому, пожалуйста, имейте в виду, что в данный момент передача UDP-пакетов на этот порт заблокирована.

Скорее всего, ни на одной из машин в нашем облаке нет сервисов, которые действительно требовали бы для своего функционирования приём пакетов на порт 11211, но, если вдруг кому-то из пользователей потребуется отключить блокировку, мы будем рады оперативно обработать их обращения, отправленные в нашу службу технической поддержки по адресу support@tucha.ua.

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

Что нужно сделать вам

Итак, рефлекторами выступили машины наших клиентов, где администратор включил службу memcached и оставил её открытой для внешних обращений.

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

Проверить это можно, например, выполнив в системе такую команду:

lsof -i UDP -Pn | grep ':11211[[:space:]]*$'

Если memcached присутствует и действительно “слушает” на каких-либо адресах, кроме 127.0.0.1, то, если у Вас нет полной уверенности в том, что так и должно быть, лучше убедите его так не делать, например, добавив к параметрам запуска службы memcached параметр «-l 127.0.0.1».

Как уже упоминалось, сейчас обращения к memcached извне заблокированы на уровне нашей сетевой инфраструктуры. Но в ближайшее время мы снимем блокировку, поскольку не хотим ограничивать трафик для клиентских серверов. Именно поэтому мы настоятельно рекомендуем Вам устранить уязвимость непосредственно на уровне ОС.

Если вам нужна помощь или остались вопросы обращайтесь к нам в любое время. Мы всегда на связи. И рады вам 24х7.