«Ростелеком» отчитался об отражении атаки «интернета вещей» на крупнейшие российские банки

    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 еще полгода назад.
    Support the author
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 40

      0
      Надеюсь ребята в банках не работают по принципу «Работает — не трожь», и обновляют ПО вовремя. Иначе все становится возможным
        +8
        Именно так и работают. Вообще корпоративный софт обычно так и работает. Стоит в раскорячку подпертый со всех сторон костылями.
          0
          Мне помнится, через один-два дня после невозможности расплатиться картой и новости про атаку на пять банков на башорге был диалог:
          XXX: у нас сайт с утра ддосили
          YYY: конечно же ничего не вышло, потому что у нас настроен фронтенд с умным nginx?
          XXX: конечно же не настроен) и щас начали этим заниматься
          YYY: зашибииись… боюсь того дня, когда мы решим купить огнетушитель

          Подозреваю, это был работник одного из тех банков.
            0
            Везде так. Никто не хочет своими руками ронять систему. Это как раз к обновлениям относится.
        0
        Какой странный у них логотип.
        Ну пиявка же. Натуральная: https://www.calc.ru/imgs/articles3/13/28/056072576d444ccfbf02.83425552.gif
          0
          больше вот на такую штучку похоже http://www.dhresource.com/albu_413870754_00-1.600x600/gro-handel-mehrere-geschwindigkeiten-weicher.jpg
            0
            если это пиявка, то это не странно
              0
              На собесдовании только не говорите им это.
              Да — они спрашивают что у нас изображено на логотипе…

              P.S.
              Вообще это ухо.
              • UFO just landed and posted this here
                +1
                >можно прийти к выводу, что «Ростелеком» пытается выдать победу надуманную за победу реальную и заработать «очков» в глазах корпоративных клиентов как надежный провайдер.

                Там еще принятие доктрины информационной безопасности было после этой атаки. Причем еще на этапе нагнетания истерики вокруг этой атаки было понятно (мне) что явно что то хотят принять. Я правда рассчитывал на очередной пришлепнутый закон. Но теперь на основании доктрины — ждите череду законов и указов.
                  0
                  Что бы они ни делали — основная цель всегда одна. Распил.
                    0
                    Если для того что бы пилить дальше им станет мешать моя возможность ходить в интернет — меня больше волновать станет (да в общем то уже) то ЧТО они делают нежели ЗАЧЕМ.
                      +1
                      Как уже писал один из пользователей хабра (или гт), в России законы имеют даже не «двусмысленное толкование», а «ручное управление». Так что законов наплодят, а применять будут избирательно, чтобы давить «неугодных» для власть имущих.
                  +2
                  5 декабря «очень страшная» кибер-атака на отечественные банки
                  6 декабря Новая доктрина информационной безопасности
                    0
                    При этом максимальный размер пакета SYN составляет 64 Кб

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

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

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

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

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


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

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

                                Ссылка: http://lxr.free-electrons.com/source/net/ipv4/tcp_output.c#L1300
                                  0
                                  Mtu в каком месте сети она не может превышать? На хосте-отправителе, вероятно?
                                    0
                                    Именно.
                                      0
                                      Ну так мне ж никто не мешает выставить на своём интерфейсе mtu 16k и гнать с него здоровые пакеты в интернет? Которые потом будут фрагментироваться транзитным оборудованием.
                                        0
                                        1. Очевидно, со стороны роутера (который, под управлением оператора) тоже должен быть выставлен такой же mtu, иначе фрагментация до пресловутых 1500 байт.
                                        2. На сетевом оборудовании Jumbo-frame обычно не превшает 9000 байт.
                                        3. Может я отстал от жизни, но, зачем нужен син-флуд большими пакетами?
                                          0
                                          Про это я не в курсе. Я просто отметил, что большие пакеты IP теоретически можно слать, хоть и в фрагментированном виде.
                                            +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% при расчете куки, но в этом случае должно быть много пакетов. А если отправлять син с данными, то на выходе будет меньше пакетов. В чем смысл?
                                              +2
                                              немного сумбурно написал, но source code вам в помощь )
                                              вот примерная схема того, что такое syn table и accept queue:

                          0
                          Не нужно забывать про MTU и фрагментацию.
                            0
                            А меня заинтересовало, как из пакета syn стало понятно, что большинство запросов с IoT устройств. Как это может быть?
                        +1
                        Да и для Windows TcpMaxConnectResponseRetransmissions/SynAttackProtect никто не отменял.
                        Но людей можно понять — новая концепция — новые бабки. Все при деле. Не у всех ещё есть домики на берегу далёком.
                          +5
                          Как имеющий отношение к банкам — могу сказать, что последние два месяца ростелеком очень активно предлагал свои услуги в этой области. Настолько активно, что данная новость только маркетинговым булшитом и выглядит
                            +6
                            IT-крышу?
                              +1
                              в связи с этой новостью оно так и выглядит
                            +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Гб/с честного синфлуда своими силами без наличия специализированных решений.
                            • UFO just landed and posted this here
                                0
                                2 T0R
                                синкукид (ссылка выше) на линухе может и больше отфильтровать.

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

                                А так, есть вот например purifier, который будет на порядок быстрее упомянутого выше решения.
                                +1
                                В целом, пресс-релиз «Ростелекома» вызывает больше вопросов, чем ответов.


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

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


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

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

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

                                  Only users with full accounts can post comments. Log in, please.