Как организованы DDoS-атаки на банки. И не только. На пальцах
В течение последней недели от массированных DDoS-атак пострадал сразу ряд российских финансовых организаций: в том числе РСХБ, Райффайзенбанк, Газпромбанк и Росбанк. До этого атакам подвергались Национальная система платежных карт (НСПК) и Московская биржа. Это привело к сбоям в работе платежных систем, недоступности приложений банков для пользователей и сложностям при совершении некоторых операций.
Мы также фиксируем атаки на финтех и готовы поделиться наблюдениями, раскрыть особенности подхода атакующих и способы борьбы с ними. На удивление, многие не полностью понимают, что вообще происходит, кроме осознания самого факта DDoS-атаки на ресурс — как именно это устроено организационно, даже без технических тонкостей и подробностей (которые как всегда, относятся для многих к категории «ничего не понял, но очень интересно»).
Несмотря на то, что мы все больше говорим о возвращении на первый план коммерческих атак (DDoS-for-hire), здесь совершенно очевидно, что волна вредоносного трафика в адрес финансовых сервисов спланирована и политически мотивирована.
Что именно происходит с банками
При взгляде со стороны может создаваться впечатление, будто атакующие переходят от одного банка к другому, когда достигают нужного результата. Однако это не совсем так: тут скорее происходит параллельный удар сразу по всей сфере, иногда «цепляющий» смежные сферы.
Делается это для большего ущерба, медийности и заметности. Информация о будущих жертвах собирается заранее, затем в час X под атакой оказываются сразу все они.
Нестабильно работающие сайты и приложения сразу нескольких банков в течение 2–3 дней — гораздо более заметное явление, чем полностью выведенный из строя вчера банк «А», сегодня банк «Б», а завтра банк «В».
Специальной техники проведения атак именно для финтеха нет — инструментарий общий для жертв всех видов. Тем он и опасен. Таким же образом под удар попадают, например, СМИ и логистические компании. Злоумышленники бьют по заранее разведанным уязвимым точкам смешанными видами атак: из нашего опыта видно, что, как правило, используется не какой-то один вид атаки, а сразу их комплекс.
Погружаемся в контекст
Куда же без контекста? Вечно он ходит следом за всем подряд. Но без него все можно будет свести к описанию вида «А хотите, я его стукну? Он станет фиолетовый, в крапинку». Ну то есть жертва DDoS-атаки такой вид иметь и будет. Возможно, даже поначалу не осознавая, что происходит.
Как же мы оказались в таком положении? Отмотаем время на пару лет назад, вспомним, кого мы видели под атаками за этот период. В числе атакованных были государственные, муниципальные органы, СМИ, интернет-провайдеров, промышленные и IT-компании, финансовые учреждения (МФО, банки), веб-ресурсы образовательной и развлекательной сферы, сервисы логистики и другие. А еще — службы доставки пиццы и суши, небольшие местные кинотеатры, местные же магазины автозапчастей и т.д.
Целями являются как крупные широко известные организации, так и небольшие региональные компании, известные в определенной географической области. И вот тут и выясняется, что не только. Не только банки переживают атаки. Просто, когда у клиента нет возможности провести оплату/переводы — это сильно заметнее, чем заказанные на день позже запчасти для любимого авто, или непрочитанные за утренним кофе новости.
Для выведения из строя маленького регионального СМИ, например, достаточно небольшой атаки. Ну просто потому, что сайту, на который заходит всего 20 человек в секунду, большой атаки и не надо. Что происходит? Сперва злоумышленником проводится первичная оценка — насколько веб-ресурс популярен — и, уже исходя из этого, делается предположение о его предельной производительности. В последние два года с высокой долей вероятности, в качестве цели для атаки подбирают сразу несколько десятков подобных СМИ, атакуют их также разом. Как результат — они одновременно становятся недоступны. СМИ может и небольшие, но когда оказывается, что в соседних 10 областях местные СМИ не работают, то это уже становится медийно заметно.
То же самое происходит с локальными интернет-провайдерами, сообщения о чем нередко мелькают в социальных сетях. Разница здесь только в том, что объектом атаки выступает не сайт, а инфраструктура. Потому что у небольшого провайдера с несколькими десятками тысяч абонентов инфраструктура не то чтобы имела какие-то избыточные мощности в принципе. Тут и легитимные абоненты порой жалуются, что интернет-провайдер не всегда выдерживает заявленные показатели качества и скорости (автор сей статьи сам неоднократно сталкивался, когда потери пакетов в 3–4% на сети таких провайдеров в течение нескольких недель — грустный вариант нормы, зато дешево), а уж если сверху залить такому провайдеру гигабит 200 трафика, ну или, хотя бы, положить DNS-серверы (которых обычно оба два), то тут вся работа и остановится.
Никаких изысков — достаточно знать, что цель маленькая, и что она просто не устоит под атакой небольшой мощности. Дальше организаторы атаки оценивают соотношение своей атакующей мощности и того, на сколько целей ее хватит. На некоторые типы атак по таким целям в принципе никогда и не требовалось каких-то супер-организованных групп.
Для выведения из строя крупной цели атакующие действуют иначе. Сначала точно так же проводится оценка цели, исходя из известности/популярности ресурса. Вот здесь и начинается раздел «на пальцах». После атаки у многих встает закономерный вопрос «Как же так? Вы же большие! Как такое вообще возможно, что так долго не работает услуга N?».
А если вдруг видно, что будущая жертва атаки — организация, у которой достаточно развитая собственная инфраструктура, то проводится дополнительная разведка, потому что за пределами видимого всем сайта можно найти много чего интересного, и все это по открытым данным:
есть ли у будущей жертвы собственная АS (автономная система), блоки ip-адресов — пару whois запросов (в терминале или на любом сайте, типа RIPE), несколько секунд времени, и вот уже известны все принадлежащие компании сети и AS;
в каких ЦОДах может находиться инфраструктура — здесь как раз могут пригодиться данные из предыдущего пункта;
есть ли филиалы, взаимодействуют ли эти филиалы с головным филиалом;
есть ли какие-то публикации с техническими подробностями, вида «мы обновили наш вычислительный кластер, теперь перешли на сервера X поколения M», «мы запустили наше новое облако в ЦОДе города N-ска»;
проводится исследование DNS записей — что есть сейчас, и что сохранилось в DNS history;
наличие механизмов геоблокировок (например, с использованием добропорядочных сайтов-чекеров, проверяющих доступность сайтов из различных регионов мира, либо с использованием собственных ресурсов);
наличие защиты от каких-либо провайдеров защиты;
информация, атаковалась ли жертва ранее, каков был результат в прошлый раз, и были ли с тех пор изменения в инфраструктуре.
Находятся потенциально уязвимые к атакам элементы инфраструктуры (может быть сайт, слабое/уязвимое сетевое оборудование, каналы связи, провайдеры, ЦОДы). Это все — достаточно ценный массив данных на этапе подготовки, и их достаточно, чтобы ядро организованной группы атакующих могло задать в качестве целей уязвимые элементы организаций для уже тысяч прочих участников этих организованных групп.
Далее, пока идет атака, «исследователи» продолжают анализ будущих целей. Это, по сути, стало непрерывным процессом. Для сбора и анализа таких данных достаточно всего лишь до нескольких десятков человек. Примечательно, что атаки нередко оканчиваются в момент, когда атакуемый ресурс становится под защиту. И больше не происходят. Сам факт наличия защиты является фактором того, что злоумышленники пойдут искать более легкую цель. Зачем биться в специально закрытую дверь, когда рядом десять открытых, в которые можно зайти?
Как это организовано
И как же это работает на потоке?
Чтобы такое заработало, нужно вовлечение большого количества участников в атакующие группы, для чего требуется некая координация. Да и вообще, чем меньше требования к технической подкованности конкретного участника атаки, тем больше шансов вовлечь людей в работу подобных групп. В случае сложных схем читатель видит что-то вроде:
иди на сервер тот, установи там pip,
потом опять в консоль, теперь вот snap,
подсыпь еще скриптов-пакетов,
обойди вокруг горы, станцуй ламбаду,
стукни в бубен, этот скрипт пусти,
останови тот скрипт, пинги ткни,
а сюда вот списки подгрузи,
а потом опять иди водить хоровод вокруг горы
Бред же? Или нет? Да. Бред. Читающий хактивист скажет «Китайская грамота. Ничего не понял, но очень интересно! Я морально с вами!». И совершенно другие шансы вовлечь человека в участие, где из инструкций надо выполнить «купи VDS за 5 баксов в месяц вот тут, скопируй и выполни вот эти две команды, и ты с нами в деле!». Совершенно очевидно, что человек, который хотел бы вовлечься, во втором случае вольется более просто в группу атакующих.
Отдельно стоит упомянуть, что в таких группах также создан инструментарий для совершения атак и документация по его настройке. Раньше это были разрозненные группы хактивистов, постящие в каких-то каналах и пабликах сообщения вида «Давайте сегодня атакуем компании А, Б, В, Г и Д?! — А давайте, я в деле!» И начиналось, кто во что горазд. Кто-то запускал свои скрипты, кто-то делал простенькие сайты, куда хактивистам надо было зайти (как всегда: не заходите по незнакомым ссылкам, не открывайте непонятное содержимое в письмах), а дальше начинал работу какой-нибудь js-скрипт, который начинал атаку с пользовательского устройства.
Теперь это выглядит иначе. Это не десятки и сотни разрозненных групп, а вполне себе организованная деятельность. Теперь никаких «А давайте …?! — А давайте …!» Теперь это автоматически загружаемые списки в заранее подготовленный инструментарий. От участников групп требуется лишь предоставить мощности для атаки и настроить по простой инструкции инструментарий на этих мощностях. А сообщения в пабликах мы теперь видим в качестве отчетов об удачно совершенных атаках (результаты которых иногда бывают и приукрашены, конечно).
Но что может такое ядро в несколько человек? А на самом деле очень много. Фактически, одного человека достаточно, чтобы минут за 10–20 максимум просмотреть, что есть интересного у потенциальной жертвы, и насколько она вообще подходит на роль жертвы. Отмести явно огородившихся потенциальных жертв, понять, что — вот эти конкретно ребята не очень-то следят за порядком в принадлежащей им инфраструктуре. И что вот эти последние — отличный кандидат на роль той самой жертвы.
Итого. Инструментарий работает 24/7. Ядро атакующей группы на потоке ищет жертв, на потоке же производит целеуказание. Цели разъезжаются автоматически, без участия людей — нет проблемы, что условные 2 тысячи участников из условных же 5 тысяч забыли что-то обновить, и мощность атакующей сети упала. Как результат — разрушительные атаки, с непредсказуемо меняющимся вектором, с резко меняющимися целями. И все это без перерыва на обед.
Что делать?
Ну, помимо очевидного «обзавестись какой-нибудь защитой».
Заняться подготовкой защиты заранее. До того, как атака случится. В случае беды сильно сократит зоны поражения и сбережет нервы/силы/деньги.
Как можно попытаться защититься? Быть самостоятельным, сильным и устойчивым. Плюсы — вы самостоятельны, сильны и устойчивы. Минусы — дорого. Очень.
Если чуть более серьезно, то можно рассмотреть следующие меры, которые могут быть реализованы собственными силами.
Просмотреть свои DNS-записи. Самая очевидная, простая и бюджетная мера. Сама суть DNS — эдакий публичный справочник по вашим сервисам и ресурсам. Многие ленятся разделять записи внутренних и внешних сервисов, отчего DNS превращается просто в карту того, что где лежит. Вот тут у нас таск трекер, вот здесь NTP-серверы, рядом у нас корпоративное облако в виде Nextcloud. А вот тут наша гордость — офисные точки доступа, купленные на распродаже 10 лет назад за шапку сухарей. Выгодная сделка была! По факту, выставление «карты» внутренней инфраструктуры вовне ни к чему хорошему не приведет. Если есть потребность в тех же NTP, DNS резолверу на внешних адресах, то оградите их на уровне фаерволов списком IP, откуда будут приходить запросы именно от ваших собственных сервисов. Вряд ли вам нужно обслуживать эти запросы из чужих сетей. Ну и не забывайте про такую штуку, как DNS history. На данный момент лишние сервисы не светятся, но возможно это было в прошлом — дополнительный повод перепроверить такие сервисы. Если в общем случае злоумышленнику надо будет потратить время на сканирование всей сети, чтобы понять, есть ли сервис, то выставление внутренних сервисов просто экономит ему время.
Доступы на базе геопризнаков. Они же геоблокировки. Это работает. До определенной степени. С одной стороны, мощность атаки, которую приходится обрабатывать сервисами, можно таким образом значительно снизить. Да и незачем принимать запросы от пингвинов из Антарктиды, если там у вас нет клиентской базы. С другой стороны — не работает. Потому что клиенты могут быть со значительной части мира. И блокировать их нельзя. Также бывают false positive срабатывания, в зависимости от используемых баз. А еще атакующие на стадии исследования могут увидеть факт блокировок по геопризнаку, после чего специально под эту атаку попытаются задействовать мощности с «правильным» геопризнаком. Как уже было сказано ранее — работает, но не панацея.
Разделить внутреннюю и внешнюю инфраструктуры. Данный пункт чуть-чуть пересекается с историей про DNS. Если инфраструктура нужна для работы сотрудников (внутри офиса/сети, удаленщики через корпоративный VPN), то нет никакой необходимости завязывать все на один и тот же DNS-сервер, например, или на один веб-сервер, которые обслуживают и внешние, и внутренние сервисы. В худшем случае — падение под атакой — упадут и внутренние сервисы. Лежит снаружи, лежит внутри. Работа стоит и для клиентов, и для сотрудников. А технический персонал мечется в попытках помочь и внутренним, и внешним пользователям.
Разделить ресурсы по функционалу для сокращения площади поражения на случай, если что-то идет не так. Разнести на разные домены по функционалу, либо по признаку «браузер/мобильный клиент». Классический пример. Какой-нибудь API, живущий в корне сайта. Получается ядерная смесь трафика браузеров (живых людей) и автоматизированных запросов (мобильные приложения), а еще и просто походы каких-нибудь легитимных и не очень роботов к этому API. И просто попытка как-то разделить данные категории усложняется. При разнесении ресурсов, обрабатывающих разные категории трафика на разные домена (а еще и на разные сервера), может сильно упростить выработку мер противодействия. Потому что все, что приходит на сервер — однотипно, и вот на это вот API мы точно не ждем никакого трафика, отличного от трафика мобильного приложения.
Обзавестись соответствующей вычислительной мощностью. И серверов, и каналов связи. Чтобы меры защиты работали, нужно выстоять в принципе. А если сервер рассчитан на обработку в норме одной тысячи запросов, а в максимуме — на 60% больше, то говорить о самостоятельном противодействии атаке, в общем-то, бессмысленно. Равно как и бесполезно полагаться на какие-то тонкие настройки и системы защиты в конечных системах в случае, когда у вас канал 3 Гбит/сек, а атака 5. Канал просто зальет. Можно купить тогда 5 Гбит/сек, чтобы все влезло? Да. Можно и 10. И 20. Только на фоне современных объемов атак это незначительно, а атака, скорее всего, всегда будет больше величины пропускной способности вашего канала. А вот купить 100–400 Гбит/сек — это уже дороговато для обычной, пусть даже и крупной, компании.
Канал связи. Один из самых значительных факторов. Причем и тут надо смотреть на тонкости. Потому что если трафика в норме условных 0,5 Гбит/сек, а максимальная емкость — 2–3 Гбит/сек, то это еще не гарантия, что этого задела хватит даже при наличии специализированных средств защиты. Чтобы ваши меры защиты начали работать, вы этот трафик должны получить в свои системы. Весь. Еще и чуть-чуть емкости канала должно остаться, чтобы сервис не деградировал. И при канале в 5, 10 и даже 20 Гбит/сек получить поток трафика условные 700 Гбит/сек невозможно. Физически. С другой стороны, даже при наличии средств защиты что-то может проходить. Ну потому что из тех же 700 Гбит/сек что-то да проскочит. И вот этого чего-то может набраться пару-тройку гигабит. В реальности это немного. В процентах это вообще мизер. 0,2–0,4%. Но при емкости канала в те самые 2–3 Гбит/сек — эта пара десятых процента может быть приговором. Качество работы сервисов просто начинает деградировать из-за переполнения канала, хотя конечные серверы такие остатки мусора могли бы вполне и переварить, даже не очень напрягаясь. Тем более с дополнительными тонкими настройками, сделанными до. Как всегда, для инженеров в полный рост возникает задача по поиску примерного баланса в системах. Ну и немного предварительных затрат в связи с этим может последовать, да.
Составить план действий на случай наступления часа X. Вплоть до списка команд и операций, которые надо выполнить в той или иной системе. Ну то есть что вообще может помочь устоять с технической точки зрения — массовые баны замеченных в атаке ip на уровне фаерволов, включение блокировок по геопризнаку/AS (иногда только с одной AS атака и идет в рамках какой-нибудь страны). А что это за список такой атакующих IP? А тут тоже надо заранее продумать, из каких его логов брать. Например, то, что прошло через условный fail2ban (который, конечно же, тоже должен быть в системах сильно до атаки). И как это быстро делать. Также в этот план можно включить перечень действий для службы техподдержки, чтобы максимально помочь клиентам, которые страдают вместе с вами.
Как более частный случай плана — присмотреть решения профессиональной защиты заранее, если час X придет. Просто на всякий случай. Просто чтобы было хотя бы примерное понимание, что надо будет сделать, если час X наступит, и будет принято решение разворачивать взрослую защиту. Непонимание, что надо сделать, чтобы защитить себя, когда у вас уже есть средство защиты — такое тоже случается.
Теперь можно толпой бежать с аргументами наперевес к местным сисадминам и потрясать ультимативным планом решения проблем? Ну нет, не надо, пощадите людей. Их работа все-таки несколько иная. Базовые механизмы безопасности они обеспечить могут. Но сражаться с бульдозером с одним лишь пожарным ведром в руках — не очень эффективно.
А что если атака уже пошла?
Не паниковать.
Не паниковать.
Не паниковать.
Идти по заранее намеченному плану противодействия.
Смотреть, где защита не справляется, или вообще обнажаются уязвимые места. Если не поможет сейчас, то хотя бы на будущее. Если к вам пришли сейчас, то незваные гости заглянут и в следующий раз.
Если что-то все равно идет не так, предпринятые меры дают мало эффекта, а защиты заранее не было развернуто, то стоит задуматься, а может пора обратиться к тем, кто на специализируется на мерах защиты? Ведь в борьбе со всяким вредоносным кодом мы давно полагаемся на антивирусы. Новая реальность DDoS-атак такова, что не стыдно рассмотреть и специализированные средства противостояния этой угрозе.
