Comments 40
Надеюсь ребята в банках не работают по принципу «Работает — не трожь», и обновляют ПО вовремя. Иначе все становится возможным
Именно так и работают. Вообще корпоративный софт обычно так и работает. Стоит в раскорячку подпертый со всех сторон костылями.
Мне помнится, через один-два дня после невозможности расплатиться картой и новости про атаку на пять банков на башорге был диалог:
Подозреваю, это был работник одного из тех банков.
XXX: у нас сайт с утра ддосили
YYY: конечно же ничего не вышло, потому что у нас настроен фронтенд с умным nginx?
XXX: конечно же не настроен) и щас начали этим заниматься
YYY: зашибииись… боюсь того дня, когда мы решим купить огнетушитель
Подозреваю, это был работник одного из тех банков.
UFO just landed and posted this here
Еще в пятницу нагнетали атмосферу:
«ФСБ сообщила о подготовке иностранными спецслужбами кибератаки на банки
Подробнее на РБК:»
Я просто оставлю это здесь.
День Радио — Эсминец «Композитор Юрий Шостакович»
«ФСБ сообщила о подготовке иностранными спецслужбами кибератаки на банки
Подробнее на РБК:»
Я просто оставлю это здесь.
День Радио — Эсминец «Композитор Юрий Шостакович»
>можно прийти к выводу, что «Ростелеком» пытается выдать победу надуманную за победу реальную и заработать «очков» в глазах корпоративных клиентов как надежный провайдер.
Там еще принятие доктрины информационной безопасности было после этой атаки. Причем еще на этапе нагнетания истерики вокруг этой атаки было понятно (мне) что явно что то хотят принять. Я правда рассчитывал на очередной пришлепнутый закон. Но теперь на основании доктрины — ждите череду законов и указов.
Там еще принятие доктрины информационной безопасности было после этой атаки. Причем еще на этапе нагнетания истерики вокруг этой атаки было понятно (мне) что явно что то хотят принять. Я правда рассчитывал на очередной пришлепнутый закон. Но теперь на основании доктрины — ждите череду законов и указов.
5 декабря «очень страшная» кибер-атака на отечественные банки
6 декабря Новая доктрина информационной безопасности
6 декабря Новая доктрина информационной безопасности
При этом максимальный размер пакета SYN составляет 64 Кб
Может быть 64 байта?
16 Кб — оптимальный максимальный размер пакета, т.е. реально возможный. А так да, могут быть и по 60 байт.
«16 Кб — оптимальный максимальный размер пакета, т.е. реально возможный. А так да, могут быть и по 60 байт.»
Александр, это ваше личное открытие?
Александр, это ваше личное открытие?
Вместе с SYN вполне можно передавать данные: RFC7413: TCP Fast Open.
Да, но не более размера MTU, который для Ethernet составляет 1500 байт.
В rfc есть рекомендация кэшировать mss во избежание ip-фрагментации, но ничего не мешает атакующему игнорировать это и использовать фрагментированные пакеты до 64k, которые будут собираться на dst host и отдаваться дальше в tcp-стек.
Другое дело, что firewall'ы вскоре научатся резать такие вещи, если ещё не. Ну и, кроме того, syn flood удобен тем, что не требует значительных сетевых ресурсов для атаки и использование больших пакетов может стоить атакующему больше, чем профит от этого.
MSS — это порция байт, которую tcp передает ip уровню, и очевидно, она не может превышать MTU.
В линуксе MSS вычисляет вот такая функция: __tcp_mtu_to_mss().
Ссылка: http://lxr.free-electrons.com/source/net/ipv4/tcp_output.c#L1300
В линуксе MSS вычисляет вот такая функция: __tcp_mtu_to_mss().
Ссылка: http://lxr.free-electrons.com/source/net/ipv4/tcp_output.c#L1300
Mtu в каком месте сети она не может превышать? На хосте-отправителе, вероятно?
Именно.
Ну так мне ж никто не мешает выставить на своём интерфейсе mtu 16k и гнать с него здоровые пакеты в интернет? Которые потом будут фрагментироваться транзитным оборудованием.
1. Очевидно, со стороны роутера (который, под управлением оператора) тоже должен быть выставлен такой же mtu, иначе фрагментация до пресловутых 1500 байт.
2. На сетевом оборудовании Jumbo-frame обычно не превшает 9000 байт.
3. Может я отстал от жизни, но, зачем нужен син-флуд большими пакетами?
2. На сетевом оборудовании Jumbo-frame обычно не превшает 9000 байт.
3. Может я отстал от жизни, но, зачем нужен син-флуд большими пакетами?
Про это я не в курсе. Я просто отметил, что большие пакеты IP теоретически можно слать, хоть и в фрагментированном виде.
Тогда я вам отвечу.
Чтобы понимать зачем нужен син-флуд и вчем его смысл, нужно понимать что такое 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% при расчете куки, но в этом случае должно быть много пакетов. А если отправлять син с данными, то на выходе будет меньше пакетов. В чем смысл?
Чтобы понимать зачем нужен син-флуд и вчем его смысл, нужно понимать что такое 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% при расчете куки, но в этом случае должно быть много пакетов. А если отправлять син с данными, то на выходе будет меньше пакетов. В чем смысл?
Не нужно забывать про MTU и фрагментацию.
Да и для Windows TcpMaxConnectResponseRetransmissions/SynAttackProtect никто не отменял.
Но людей можно понять — новая концепция — новые бабки. Все при деле. Не у всех ещё есть домики на берегу далёком.
Но людей можно понять — новая концепция — новые бабки. Все при деле. Не у всех ещё есть домики на берегу далёком.
Как имеющий отношение к банкам — могу сказать, что последние два месяца ростелеком очень активно предлагал свои услуги в этой области. Настолько активно, что данная новость только маркетинговым булшитом и выглядит
Статья и комменты сочатся желчью. Почему-то сразу вспомнили за распил. Возможно конечно сами виноваты, ибо в народе был создан такой образ, но постойте, вроде на хабре мы тут обсуждаем технику, не так ли?
Не пойму, так умолчала или нет? Вроде нет, зачем тогда писать обратное?
Ткните пожалуйста меня носом в то место, где нагнетается.
Так, вообще-то вы притащили на хабр это. Ростелек написал у себя в блоге (и да, журналисты конечно охотно растащили, но что поделать?)
Время жизни полуоткрытых соединений варьируется. FreeBSD это net.inet.tcp.keepinit, который да, по умолчанию 75 секунд. В Линуксе несколько по другому, там зависит от initial RTO и количества syn_ack ретрансмитов. По дефолту все это выливается в 31 секунду.
максимальный размер IP да — 64Кб, но что за стандарт, говорящий о 16Кб syn пакетах я даже близко не могу предположить. По этому
вы не правильно посчитали канальную составляющую атаки, к слову которая мерится далеко не в bps.
Использовались, используются и будут использоваться. Более того — они все еще довольно эффективны, если не подумать о защите заранее. И тут имеет место быть ряд векторов.
Во-первых, наличие достаточной канальной емкости. Для получения 3.2 Мппс син флуда нужно чуть больше 2Гб/с (1 Гб/с это 1,488 Мппс, если syn пакеты без опций). Не каждая компания, нуждающаяся в услуге фильтрации, имеет в распоряжении такой объем свободной канальной полосы.
Во-вторых, раз уж тут предложили фильтровать на линуксе, то современный ТСП стек линукса может обработать порядка пары мппс на нормальных камнях. Но нужно же еще и полезную работу выполнять.
Mirai умеет много разных типов атак, в том числе и упомянутый в статье synflood.
З.Ы. Хочу посмотреть как умники тут будут фильтровать своими силами 3.2Гб/с честного синфлуда своими силами без наличия специализированных решений.
Первое, компания умолчала об интенсивности атаки. Цифра в 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Гб/с честного синфлуда своими силами без наличия специализированных решений.
UFO just landed and posted this here
2 T0R
синкукид (ссылка выше) на линухе может и больше отфильтровать.
Да, я в курсе, выше я говорил о
без наличия специализированных решений
А так, есть вот например purifier, который будет на порядок быстрее упомянутого выше решения.
В целом, пресс-релиз «Ростелекома» вызывает больше вопросов, чем ответов.
Ростелеком лично вам чем-то обязан или есть закон, требующий разглашать все детали подобных атак?
Почему победа надуманная? Одно из двух: либо «Ростелеком» выдает желаемое за действительное и просто зафиксировал попытку SYN Flood-атаки, с которой Linux Server справился без особого труда и посторонней помощи, либо же компания предоставляет своим клиентам (банкам!) устаревшие технологические решения, в том числе и в плане ПО. Из-за чего и пришлось «героически превозмогать» SYN flood, проблема которого была решена на уровне ядра Linux еще полгода назад.
Ни один банк не допустит РосТелком внутрь к своим серверам Linux.
Это косяки банков.
И, внимание, вопрос: вы сами то в своих подопечных системах уже обновились?
Из-за чего и пришлось «героически превозмогать» SYN flood, проблема которого была решена на уровне ядра Linux еще полгода назад.
А можно уточнить как-именно решили проблему SYN flood в ядре Linux?
Sign up to leave a comment.
«Ростелеком» отчитался об отражении атаки «интернета вещей» на крупнейшие российские банки