image

Сегодня компания «Ростелеком» сообщила об отражении атаки ботнета «интернета вещей» на пять крупнейших российских банков. Атака проводилась 5 декабря с использованием TCP SYN Flood. По информации «Ростелекома» пиковая нагрузка составляла 3,2 миллиона пакетов в секунду.

Каких-либо деталей, кроме того, что часть трафика генерировалась с IoT-устройств, провайдер не предоставил. Также была предоставлена общая информация об опасности DDoS-атак и о том, кто уже пострадал от действия злоумышленников, управляющих ботнетами из «интернета вещей». В целом, пресс-релиз «Ростелекома» вызывает больше вопросов, чем ответов.

Первое, компания умолчала об интенсивности атаки. Цифра в 3,2 миллиона пакетов из «Пятерочки» выглядит внушительно, тем более, SYN-flood атаки на самом деле измеряются в количестве пакетов.

При атаке 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)


  1. Tto_ogarin
    09.12.2016 15:09

    Надеюсь ребята в банках не работают по принципу «Работает — не трожь», и обновляют ПО вовремя. Иначе все становится возможным


    1. Sanes
      09.12.2016 16:13
      +8

      Именно так и работают. Вообще корпоративный софт обычно так и работает. Стоит в раскорячку подпертый со всех сторон костылями.


      1. ainoneko
        13.12.2016 07:46

        Мне помнится, через один-два дня после невозможности расплатиться картой и новости про атаку на пять банков на башорге был диалог:

        XXX: у нас сайт с утра ддосили
        YYY: конечно же ничего не вышло, потому что у нас настроен фронтенд с умным nginx?
        XXX: конечно же не настроен) и щас начали этим заниматься
        YYY: зашибииись… боюсь того дня, когда мы решим купить огнетушитель

        Подозреваю, это был работник одного из тех банков.


        1. Sanes
          14.12.2016 05:01

          Везде так. Никто не хочет своими руками ронять систему. Это как раз к обновлениям относится.


  1. A-Stahl
    09.12.2016 15:13

    Какой странный у них логотип.
    Ну пиявка же. Натуральная: https://www.calc.ru/imgs/articles3/13/28/056072576d444ccfbf02.83425552.gif


    1. steam
      09.12.2016 16:37

      больше вот на такую штучку похоже http://www.dhresource.com/albu_413870754_00-1.600x600/gro-handel-mehrere-geschwindigkeiten-weicher.jpg


    1. MikeBooker
      10.12.2016 20:38

      если это пиявка, то это не странно


    1. sbh
      10.12.2016 20:38

      На собесдовании только не говорите им это.
      Да — они спрашивают что у нас изображено на логотипе…

      P.S.
      Вообще это ухо.


  1. nApoBo3
    09.12.2016 15:22
    +2


  1. gearbox
    09.12.2016 15:39
    +1

    >можно прийти к выводу, что «Ростелеком» пытается выдать победу надуманную за победу реальную и заработать «очков» в глазах корпоративных клиентов как надежный провайдер.

    Там еще принятие доктрины информационной безопасности было после этой атаки. Причем еще на этапе нагнетания истерики вокруг этой атаки было понятно (мне) что явно что то хотят принять. Я правда рассчитывал на очередной пришлепнутый закон. Но теперь на основании доктрины — ждите череду законов и указов.


    1. il--ya
      09.12.2016 17:30

      Что бы они ни делали — основная цель всегда одна. Распил.


      1. gearbox
        09.12.2016 18:03

        Если для того что бы пилить дальше им станет мешать моя возможность ходить в интернет — меня больше волновать станет (да в общем то уже) то ЧТО они делают нежели ЗАЧЕМ.


        1. Rampages
          09.12.2016 19:26
          +1

          Как уже писал один из пользователей хабра (или гт), в России законы имеют даже не «двусмысленное толкование», а «ручное управление». Так что законов наплодят, а применять будут избирательно, чтобы давить «неугодных» для власть имущих.


  1. sinyaya_boroda
    09.12.2016 16:35
    +2

    5 декабря «очень страшная» кибер-атака на отечественные банки
    6 декабря Новая доктрина информационной безопасности


  1. drevv
    09.12.2016 16:43

    При этом максимальный размер пакета SYN составляет 64 Кб

    Может быть 64 байта?


    1. ragequit
      09.12.2016 16:44
      +1

      16 Кб — оптимальный максимальный размер пакета, т.е. реально возможный. А так да, могут быть и по 60 байт.


      1. FeRViD
        09.12.2016 16:49

        «16 Кб — оптимальный максимальный размер пакета, т.е. реально возможный. А так да, могут быть и по 60 байт.»

        Александр, это ваше личное открытие?


        1. grossws
          09.12.2016 16:54

          Вместе с SYN вполне можно передавать данные: RFC7413: TCP Fast Open.


          1. FeRViD
            09.12.2016 17:02

            Да, но не более размера MTU, который для Ethernet составляет 1500 байт.


            1. grossws
              09.12.2016 17:54

              В rfc есть рекомендация кэшировать mss во избежание ip-фрагментации, но ничего не мешает атакующему игнорировать это и использовать фрагментированные пакеты до 64k, которые будут собираться на dst host и отдаваться дальше в tcp-стек.


              Другое дело, что firewall'ы вскоре научатся резать такие вещи, если ещё не. Ну и, кроме того, syn flood удобен тем, что не требует значительных сетевых ресурсов для атаки и использование больших пакетов может стоить атакующему больше, чем профит от этого.


              1. FeRViD
                09.12.2016 21:04

                MSS — это порция байт, которую tcp передает ip уровню, и очевидно, она не может превышать MTU.
                В линуксе MSS вычисляет вот такая функция: __tcp_mtu_to_mss().

                Ссылка: http://lxr.free-electrons.com/source/net/ipv4/tcp_output.c#L1300


                1. vadimr
                  10.12.2016 18:44

                  Mtu в каком месте сети она не может превышать? На хосте-отправителе, вероятно?


                  1. FeRViD
                    10.12.2016 22:49

                    Именно.


                    1. vadimr
                      10.12.2016 22:52

                      Ну так мне ж никто не мешает выставить на своём интерфейсе mtu 16k и гнать с него здоровые пакеты в интернет? Которые потом будут фрагментироваться транзитным оборудованием.


                      1. FeRViD
                        10.12.2016 23:04

                        1. Очевидно, со стороны роутера (который, под управлением оператора) тоже должен быть выставлен такой же mtu, иначе фрагментация до пресловутых 1500 байт.
                        2. На сетевом оборудовании Jumbo-frame обычно не превшает 9000 байт.
                        3. Может я отстал от жизни, но, зачем нужен син-флуд большими пакетами?


                        1. vadimr
                          10.12.2016 23:07

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


                          1. 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% при расчете куки, но в этом случае должно быть много пакетов. А если отправлять син с данными, то на выходе будет меньше пакетов. В чем смысл?


                            1. FeRViD
                              10.12.2016 23:39
                              +2

                              немного сумбурно написал, но source code вам в помощь )
                              вот примерная схема того, что такое syn table и accept queue:


      1. drevv
        09.12.2016 17:04

        Не нужно забывать про MTU и фрагментацию.


        1. nckma
          10.12.2016 09:09

          А меня заинтересовало, как из пакета syn стало понятно, что большинство запросов с IoT устройств. Как это может быть?


  1. x893
    09.12.2016 16:46
    +1

    Да и для Windows TcpMaxConnectResponseRetransmissions/SynAttackProtect никто не отменял.
    Но людей можно понять — новая концепция — новые бабки. Все при деле. Не у всех ещё есть домики на берегу далёком.


  1. zeronice
    09.12.2016 16:54
    +5

    Как имеющий отношение к банкам — могу сказать, что последние два месяца ростелеком очень активно предлагал свои услуги в этой области. Настолько активно, что данная новость только маркетинговым булшитом и выглядит


    1. Pakos
      09.12.2016 17:05
      +6

      IT-крышу?


      1. zeronice
        09.12.2016 18:06
        +1

        в связи с этой новостью оно так и выглядит


  1. 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Гб/с честного синфлуда своими силами без наличия специализированных решений.


  1. 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
    синкукид (ссылка выше) на линухе может и больше отфильтровать.


    1. T0R
      09.12.2016 22:59

      2 T0R
      синкукид (ссылка выше) на линухе может и больше отфильтровать.

      Да, я в курсе, выше я говорил о
      без наличия специализированных решений

      А так, есть вот например purifier, который будет на порядок быстрее упомянутого выше решения.


  1. jewubinin
    10.12.2016 20:38
    +1

    В целом, пресс-релиз «Ростелекома» вызывает больше вопросов, чем ответов.


    Ростелеком лично вам чем-то обязан или есть закон, требующий разглашать все детали подобных атак?

    Почему победа надуманная? Одно из двух: либо «Ростелеком» выдает желаемое за действительное и просто зафиксировал попытку SYN Flood-атаки, с которой Linux Server справился без особого труда и посторонней помощи, либо же компания предоставляет своим клиентам (банкам!) устаревшие технологические решения, в том числе и в плане ПО. Из-за чего и пришлось «героически превозмогать» SYN flood, проблема которого была решена на уровне ядра Linux еще полгода назад.


    Ни один банк не допустит РосТелком внутрь к своим серверам Linux.
    Это косяки банков.

    И, внимание, вопрос: вы сами то в своих подопечных системах уже обновились?


  1. caban
    12.12.2016 10:46

    Из-за чего и пришлось «героически превозмогать» SYN flood, проблема которого была решена на уровне ядра Linux еще полгода назад.

    А можно уточнить как-именно решили проблему SYN flood в ядре Linux?