Сегодня компания «Ростелеком» сообщила об отражении атаки ботнета «интернета вещей» на пять крупнейших российских банков. Атака проводилась 5 декабря с использованием TCP SYN Flood. По информации «Ростелекома» пиковая нагрузка составляла 3,2 миллиона пакетов в секунду.
Каких-либо деталей, кроме того, что часть трафика генерировалась с IoT-устройств, провайдер не предоставил. Также была предоставлена общая информация об опасности DDoS-атак и о том, кто уже пострадал от действия злоумышленников, управляющих ботнетами из «интернета вещей». В целом, пресс-релиз «Ростелекома» вызывает больше вопросов, чем ответов.
Первое, компания умолчала об интенсивности атаки. Цифра в 3,2 миллиона пакетов
При атаке SYN-flood с подставных IP-адресов рассылается TCP-запрос на установку соединения. Атакуемый сервер отправляет ответ SYN/ACK и переходит в состояние SYN-RECEIVED, которое без ответа с запрашиваемой стороны снимается только через 75 секунд. При этом максимальный размер пакета SYN составляет 64 Кб, но стандартом является его меньшая версия на 16 Кб. Путем нехитрых подсчетов получаем наиболее вероятную интенсивность атаки в 51,2 Гбайт/с.
При этом в пресс-релизе «Ростелекома» открыто нагнетается ситуация с атаками на европейские структуры и организации мощностью до 1 Тбит/c (125 Гбайт/c).
Атака типа SYN Flood известна давно (еще с начала 2000-х) и используется злоумышленниками с переменным успехом. При этом эффективность подобных методов спустя полтора десятилетия вызывает сомнения.
Известный ботнет Mirai, который положил DNS-провайдера Dyn в октябре этого года (и которому приписываются упомянутые «Ростелекомом» атаки в Европе), использовал UDP-атаку, также известную как DNS retry.
При этом один из специалистов по информационной безопасности на условиях анонимности так прокомментировал пресс-релиз «Ростелекома» и проведенную атаку для Хабра:
После релиза linux 4.7 вышло два патча:
Add SOCK_RCU_FREE socket flag that UDP sockets and TCP listeners can set so that their lookup can use traditional RCU rules, without refcount changes. The UDP stack is instructed to not use SLAB_DESTROY_BY_RCU, in order to speedup rx processing for traffic encapsulated in UDP; performance for a single UDP socket receiving flood traffic from many RX queues/cpus is increased. TCP listeners are changed to use SOCK_RCU_FREE as well to avoid touching sk_refcnt under synflood. Peak performance under SYNFLOOD is increased by ~33%.
Add rate limiting on ACK sent on behalf of SYN_RECV to better resist to SYNFLOOD targeting one or few flows.
Они решают проблему параллельной обработки syn/udp flood, то есть даже для обычного linux server на современном ядре это не представляет никакой проблемы.
Исходя из вышесказанного можно прийти к выводу, что «Ростелеком» пытается выдать победу надуманную за победу реальную и заработать «очков» в глазах корпоративных клиентов как надежный провайдер.
Почему победа надуманная? Одно из двух: либо «Ростелеком» выдает желаемое за действительное и просто зафиксировал попытку SYN Flood-атаки, с которой Linux Server справился без особого труда и посторонней помощи, либо же компания предоставляет своим клиентам (банкам!) устаревшие технологические решения, в том числе и в плане ПО. Из-за чего и пришлось «героически превозмогать» SYN flood, проблема которого была решена на уровне ядра Linux еще полгода назад.
Комментарии (40)
A-Stahl
09.12.2016 15:13Какой странный у них логотип.
Ну пиявка же. Натуральная: https://www.calc.ru/imgs/articles3/13/28/056072576d444ccfbf02.83425552.gifsteam
09.12.2016 16:37больше вот на такую штучку похоже http://www.dhresource.com/albu_413870754_00-1.600x600/gro-handel-mehrere-geschwindigkeiten-weicher.jpg
sbh
10.12.2016 20:38На собесдовании только не говорите им это.
Да — они спрашивают что у нас изображено на логотипе…
P.S.
Вообще это ухо.
nApoBo3
09.12.2016 15:22+2Еще в пятницу нагнетали атмосферу:
«ФСБ сообщила о подготовке иностранными спецслужбами кибератаки на банки
Подробнее на РБК:»
Я просто оставлю это здесь.
День Радио — Эсминец «Композитор Юрий Шостакович»AleXP3
10.12.2016 20:38
gearbox
09.12.2016 15:39+1>можно прийти к выводу, что «Ростелеком» пытается выдать победу надуманную за победу реальную и заработать «очков» в глазах корпоративных клиентов как надежный провайдер.
Там еще принятие доктрины информационной безопасности было после этой атаки. Причем еще на этапе нагнетания истерики вокруг этой атаки было понятно (мне) что явно что то хотят принять. Я правда рассчитывал на очередной пришлепнутый закон. Но теперь на основании доктрины — ждите череду законов и указов.il--ya
09.12.2016 17:30Что бы они ни делали — основная цель всегда одна. Распил.
gearbox
09.12.2016 18:03Если для того что бы пилить дальше им станет мешать моя возможность ходить в интернет — меня больше волновать станет (да в общем то уже) то ЧТО они делают нежели ЗАЧЕМ.
Rampages
09.12.2016 19:26+1Как уже писал один из пользователей хабра (или гт), в России законы имеют даже не «двусмысленное толкование», а «ручное управление». Так что законов наплодят, а применять будут избирательно, чтобы давить «неугодных» для власть имущих.
sinyaya_boroda
09.12.2016 16:35+25 декабря «очень страшная» кибер-атака на отечественные банки
6 декабря Новая доктрина информационной безопасности
drevv
09.12.2016 16:43При этом максимальный размер пакета SYN составляет 64 Кб
Может быть 64 байта?ragequit
09.12.2016 16:44+116 Кб — оптимальный максимальный размер пакета, т.е. реально возможный. А так да, могут быть и по 60 байт.
FeRViD
09.12.2016 16:49«16 Кб — оптимальный максимальный размер пакета, т.е. реально возможный. А так да, могут быть и по 60 байт.»
Александр, это ваше личное открытие?grossws
09.12.2016 16:54Вместе с SYN вполне можно передавать данные: RFC7413: TCP Fast Open.
FeRViD
09.12.2016 17:02Да, но не более размера MTU, который для Ethernet составляет 1500 байт.
grossws
09.12.2016 17:54В rfc есть рекомендация кэшировать mss во избежание ip-фрагментации, но ничего не мешает атакующему игнорировать это и использовать фрагментированные пакеты до 64k, которые будут собираться на dst host и отдаваться дальше в tcp-стек.
Другое дело, что firewall'ы вскоре научатся резать такие вещи, если ещё не. Ну и, кроме того, syn flood удобен тем, что не требует значительных сетевых ресурсов для атаки и использование больших пакетов может стоить атакующему больше, чем профит от этого.
FeRViD
09.12.2016 21:04MSS — это порция байт, которую tcp передает ip уровню, и очевидно, она не может превышать MTU.
В линуксе MSS вычисляет вот такая функция: __tcp_mtu_to_mss().
Ссылка: http://lxr.free-electrons.com/source/net/ipv4/tcp_output.c#L1300vadimr
10.12.2016 18:44Mtu в каком месте сети она не может превышать? На хосте-отправителе, вероятно?
FeRViD
10.12.2016 22:49Именно.
vadimr
10.12.2016 22:52Ну так мне ж никто не мешает выставить на своём интерфейсе mtu 16k и гнать с него здоровые пакеты в интернет? Которые потом будут фрагментироваться транзитным оборудованием.
FeRViD
10.12.2016 23:041. Очевидно, со стороны роутера (который, под управлением оператора) тоже должен быть выставлен такой же mtu, иначе фрагментация до пресловутых 1500 байт.
2. На сетевом оборудовании Jumbo-frame обычно не превшает 9000 байт.
3. Может я отстал от жизни, но, зачем нужен син-флуд большими пакетами?vadimr
10.12.2016 23:07Про это я не в курсе. Я просто отметил, что большие пакеты IP теоретически можно слать, хоть и в фрагментированном виде.
FeRViD
10.12.2016 23:24+2Тогда я вам отвечу.
Чтобы понимать зачем нужен син-флуд и вчем его смысл, нужно понимать что такое listen socket, что такое syn-received socket, что такое established socket.
Системный вызов listen() инициализирует syn_table, accept_queue, переводит сокет в состояние LISTEN и помещает его в хэш таблицу listening сокетов.
Определяется размер accept_queue: sk_max_ack_backlog = min(somaxconn, backlog).
Определяется размер syn_table:
1. nr_table_entries = max(8, min(sysctl_max_syn_backlog, somaxconn, backlog)).
2. Далее значение nr_table_entries округляется до ближайшей степени двойки вверх (даже если оно уже степень двойки), а значение степени для нового значения сохраняется в max_qlen_log.
nr_table_entries = roundup_pow_of_two(nr_table_entries + 1)
7 -> 8 -> 16
8 -> 16
9 -> 16
15 -> 16
16 -> 32
31 -> 32
32 -> 64
99 -> 128
128 -> 256
511 -> 512
512 -> 1024
Когда приходит новый SYN, то ищется соответствующий listening сокет в хэш таблице listening сокетов, после чего проверяется, что текущий
размер syn_table (qlen) не превышает максимальный размер syn_table: 2 ^^max_qlen_log.
Если превышает, то проверяется включены ли tcp_syncookies, если вЫключены, то SYN дропается.
Если НЕ превышает либо tcp_syncookies включены, то текущий размер sk_ack_backlog сравнивается с sk_max_ack_backlog.
Если sk_ack_backlog > sk_max_ack_backlog то проверяется размер qlen_young.
Если qlen_young > 1, то SYN дропается, если qlen_young <= 1, то создается request_sock.
request_sock считается young, пока не был отправлен повторный SYN/ACK и используется для того, чтобы в случае заполнения
accept_queue была возможность принимать новые SYN.
Когда приходит финальный ACK (если для сокета включена опция TCP_DEFER_ACCEPT, то сокет ожидает ACK с данными), то создается
tcp_sock, адрес на него сохраняется в поле sk структуры request_sock и кастится в struct sock, после чего tcp_sock подвязывается в
хэш таблицу для established сокетов (но не подвязывается в VFS), удаляется из syn table и помещается в accept_queue.
Сокеты, находящиеся в accept_queue ожидают пока приложение выполнит системный вызов accept(). После вызова accept(), request
sock удаляется из accept_queue, создается BSD сокет struct socket, к нему подвязывается данный connected сокет после чего BSD
сокет подвязывается в VFS, а приложению возвращается файловый дескриптор.
Когда включены tcp_syncookies, если syn_table не заполнена полностью, то SYN проходит классический путь по стэку, если заполнена,
то SYN не дропается, а обрабатывается и на него отправляется SYN/ACK содержащий специальным образом сформированный ISN, но при
этом request sock не создается: request sock создается после получения финального ACK и валидации acknowledgement number и
сразу помещается в accept_queue.
Если включена опция TCP_DEFER_ACCEPT, то она работает только для сокетов, проходящих классический путь.
Если syn_table заполняется более чем на половину, количество повторных передач для SYN/ACK уменьшается до 1-3 (точный алгоритм в
см. коде), чтобы сокеты в состоянии SYN_RECV как можно быстрее освобождали syn_table.
______________________
CONCLUSION:
Т.о. до появления син-кук либо при выключенных син-кука смысл син-флуда в том, чтобы постоянно держать syn table заполненной. Что позволит уронить сервер атакой в 1 мбит/с даже при наличии канала 10Г (при не оттюненом сервере и tcp/ip стэке).
После появления син-кук задача син-флуда сделать так, чтобы CPU уходил в 100% при расчете куки, но в этом случае должно быть много пакетов. А если отправлять син с данными, то на выходе будет меньше пакетов. В чем смысл?FeRViD
10.12.2016 23:39+2немного сумбурно написал, но source code вам в помощь )
вот примерная схема того, что такое syn table и accept queue:
x893
09.12.2016 16:46+1Да и для Windows TcpMaxConnectResponseRetransmissions/SynAttackProtect никто не отменял.
Но людей можно понять — новая концепция — новые бабки. Все при деле. Не у всех ещё есть домики на берегу далёком.
zeronice
09.12.2016 16:54+5Как имеющий отношение к банкам — могу сказать, что последние два месяца ростелеком очень активно предлагал свои услуги в этой области. Настолько активно, что данная новость только маркетинговым булшитом и выглядит
T0R
09.12.2016 20:53+7Статья и комменты сочатся желчью. Почему-то сразу вспомнили за распил. Возможно конечно сами виноваты, ибо в народе был создан такой образ, но постойте, вроде на хабре мы тут обсуждаем технику, не так ли?
Первое, компания умолчала об интенсивности атаки. Цифра в 3,2 миллиона пакетов из «Пятерочки» выглядит внушительно, тем более, SYN-flood атаки на самом деле измеряются в количестве пакетов.
Не пойму, так умолчала или нет? Вроде нет, зачем тогда писать обратное?
При этом в пресс-релизе «Ростелекома» открыто нагнетается ситуация с атаками на европейские структуры и организации мощностью до 1 Тбит/c (125 Гбайт/c).
Ткните пожалуйста меня носом в то место, где нагнетается.
Исходя из вышесказанного можно прийти к выводу, что «Ростелеком» пытается выдать победу надуманную за победу реальную и заработать «очков» в глазах корпоративных клиентов как надежный провайдер.
Так, вообще-то вы притащили на хабр это. Ростелек написал у себя в блоге (и да, журналисты конечно охотно растащили, но что поделать?)
которое без ответа с запрашиваемой стороны снимается только через 75 секунд.
Время жизни полуоткрытых соединений варьируется. FreeBSD это net.inet.tcp.keepinit, который да, по умолчанию 75 секунд. В Линуксе несколько по другому, там зависит от initial RTO и количества syn_ack ретрансмитов. По дефолту все это выливается в 31 секунду.
При этом максимальный размер пакета SYN составляет 64 Кб, но стандартом является его меньшая версия на 16 Кб.
максимальный размер IP да — 64Кб, но что за стандарт, говорящий о 16Кб syn пакетах я даже близко не могу предположить. По этому
Путем нехитрых подсчетов получаем наиболее вероятную интенсивность атаки в 51,2 Гбайт/с.
вы не правильно посчитали канальную составляющую атаки, к слову которая мерится далеко не в bps.
Атака типа SYN Flood известна давно (еще с начала 2000-х) и используется злоумышленниками с переменным успехом. При этом эффективность подобных методов спустя полтора десятилетия вызывает сомнения.
Использовались, используются и будут использоваться. Более того — они все еще довольно эффективны, если не подумать о защите заранее. И тут имеет место быть ряд векторов.
Во-первых, наличие достаточной канальной емкости. Для получения 3.2 Мппс син флуда нужно чуть больше 2Гб/с (1 Гб/с это 1,488 Мппс, если syn пакеты без опций). Не каждая компания, нуждающаяся в услуге фильтрации, имеет в распоряжении такой объем свободной канальной полосы.
Во-вторых, раз уж тут предложили фильтровать на линуксе, то современный ТСП стек линукса может обработать порядка пары мппс на нормальных камнях. Но нужно же еще и полезную работу выполнять.
Известный ботнет Mirai, который положил DNS-провайдера Dyn в октябре этого года (и которому приписываются упомянутые «Ростелекомом» атаки в Европе), использовал UDP-атаку, также известную как DNS retry.
Mirai умеет много разных типов атак, в том числе и упомянутый в статье synflood.
З.Ы. Хочу посмотреть как умники тут будут фильтровать своими силами 3.2Гб/с честного синфлуда своими силами без наличия специализированных решений.
Ivan_83
09.12.2016 21:57+2Раге, после этого ты журнализд и ламер!
«Атакуемый сервер отправляет ответ SYN/ACK и переходит в состояние SYN-RECEIVED, которое без ответа с запрашиваемой стороны снимается только через 75 секунд.» —
Вовсе не обязательно 75 секунд, вовсе не обязательно вообще у себя что то алокейтить и хранить — есть sys куки, подробнее ниже.
«При этом максимальный размер пакета SYN составляет 64 Кб, но стандартом является его меньшая версия на 16 Кб. Путем нехитрых подсчетов получаем наиболее вероятную интенсивность атаки в 51,2 Гбайт/с.»
«16 Кб — оптимальный максимальный размер пакета» — РУКАЛИЦО!!!
Нету syn пакетов таких размеров и никогда не было!!!
Все TCP пакеты укладываются в MTU которое в инете обычно 1500.
Да и смысл синфлуда не закидать пакетами а заставить жертву обрабатывать пакеты без возможности их отбросить без обработки. Давление не на канал а на проц/память.
Соответственно никаких 50+ гигабит/гигабайт там не было и быть не могло с таким пакетрейтом.
Вот не плохой обзор опенсорсного решения на хипстерском расте, который вроде как эту атаку запросто переварит одним сервером:
https://beget.com/ru/articles/syncookied
Порезанная версия на хубре: https://habrahabr.ru/post/301892/
2 grossws
1. В TCP нет фрагментированных IP пакетов, TCP подбирает mss чтобы пакеты не фрагментировались на IP уровне.
2. Если какой то идиот будет слать по IP пакеты с proto=tcp и выставленным флагом фрагментации то оно у нормальных людей даже до фаервола не дойдёт, они этот мусор порежут на свичах с помощью банальных ACL, а свичу пофик, он такое на скорости порта отрабатывает не напрягаясь.
Кеширование mss вообще не при делах, это совсем для другого.
2 T0R
синкукид (ссылка выше) на линухе может и больше отфильтровать.
jewubinin
10.12.2016 20:38+1В целом, пресс-релиз «Ростелекома» вызывает больше вопросов, чем ответов.
Ростелеком лично вам чем-то обязан или есть закон, требующий разглашать все детали подобных атак?
Почему победа надуманная? Одно из двух: либо «Ростелеком» выдает желаемое за действительное и просто зафиксировал попытку SYN Flood-атаки, с которой Linux Server справился без особого труда и посторонней помощи, либо же компания предоставляет своим клиентам (банкам!) устаревшие технологические решения, в том числе и в плане ПО. Из-за чего и пришлось «героически превозмогать» SYN flood, проблема которого была решена на уровне ядра Linux еще полгода назад.
Ни один банк не допустит РосТелком внутрь к своим серверам Linux.
Это косяки банков.
И, внимание, вопрос: вы сами то в своих подопечных системах уже обновились?
caban
12.12.2016 10:46Из-за чего и пришлось «героически превозмогать» SYN flood, проблема которого была решена на уровне ядра Linux еще полгода назад.
А можно уточнить как-именно решили проблему SYN flood в ядре Linux?
Tto_ogarin
Надеюсь ребята в банках не работают по принципу «Работает — не трожь», и обновляют ПО вовремя. Иначе все становится возможным
Sanes
Именно так и работают. Вообще корпоративный софт обычно так и работает. Стоит в раскорячку подпертый со всех сторон костылями.
ainoneko
Мне помнится, через один-два дня после невозможности расплатиться картой и новости про атаку на пять банков на башорге был диалог:
Подозреваю, это был работник одного из тех банков.
Sanes
Везде так. Никто не хочет своими руками ронять систему. Это как раз к обновлениям относится.