medvedv

Ну на первый взгляд вот: >могут передаваться дополнительные опции TCP для согласования параметров соединения: mss, wscale, timestamp, sack_permitted, window, sack window - не является опцией sack - на самом деле в SYN передается только TCPOPT_SACK_PERM, TCPOPT_SACK - в ack пакетах >Номера последовательностей — это, фактически, номера пакетов На самом деле номера байт в байтовом потоке >сетевая карта (NIC) генерирует прерывание (не на группу пакетов, как обычно, а именно на каждый) Современные сетевые уже давно умеют в interrupt moderation, а ядра умеют NAPI/poll >Кука записывается в значения TCP опций Timestamp кука записывается в syn-ack, в таймстампе кодируются дополнительные опции >метка времени, которая также участвует в процессе валидации пакета (в среднем обновляется раз в 2 минуты) если имеется ввиду count, то там же в коментах написано "increases every minute by 1." >В значении 1 Syncookie включается только при переполнении таблицы тракинга соединений. На самом деле - при переполнении syn_backlog, было бы печально, если бы синкуки зависели от nf_conntrack > Фаервол при получении SYN пакета (через первый интерфейс) отправляет в сеть SYN-ACK пакет (через второй интерфейс) судя по картинке у фаервола 2 интерфейса - 10G и 1G, скорее всего syn приходят через 10G, и, судя по описанию, syn-ack должны выходить через узкое 1G место. Скорее всего тут ошибка в описании, потому как обратное по моему мнению не имеет смысла. А вообще, в условиях отсутствия симметрии трафика это является чуть ли не единственным решением, и уж точно единственным решением с открытым исходным кодом. Закрытые аналоги - arbor TMS и его клон "Периметр", которые имеют 2 контрмеры с несколько похожим принципом работы и что самое главное для ISP - возможностью работы с отсутствием симметрии трафика.

Алексей, прежде всего спасибо что поделились кодом. https://github.com/medvedv/purifier В лабе на E51660v3 делаю ~9Мппс на ядро, горизонтально скалится идеально. Я бы не советовал, довольно тривиально узнать секрет. Если я правильно понял, то зная src пользователя можно удобно рвать ему сессии резетами (src порт брутфорсить либо CVE-2016-5696). О, а вот этому как раз помешает purifier, либо другой стейтфул фаерволл. Паш, ты забываешь про опции. И да, НА 64 байтах - 14.88 Мппс - в простонародье один зигапакет/с. =) Сборщик мусора может охренеть от такой заботы.

http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP

На данный момент совместимо с линуксом. Тут собственно ограничение в том, что пока код написан под DPDK 1.7.1, скоро надеюсь перепишу под последний стабильный релиз, и по идее должно будет запуститься под фрибсд. У меня работает на убунте 14.04 LTS. Тут возможно будет ограничение в выборе железа в связи с плотной работой с fpga сетевки. Это точно работает на ixgbe, с другими картами пока не заморачивался. Штука в принципе работает даже без настройки. Управление через cli, сохранение/лоад конфига пока не прикрутил, есть в планах. Поясни что значит софт наложит кирпичей? Способно ли приложение обработать 60мппс? Да, приложение скалится практически линейно, только ядра добавляй. Однако 60мппс тебе не даст прогнать сетевушка (если имеется ввиду XL710), упрется в pci.

Да, есть такое, я вообще считаю что я довольно хреновый сетевик, да и как программист я - быдло. Ну что есть, то есть. =) Что же касается описания, тоже ваша правда, надо бы попробовать найти время описать что же это такое, а то модули ядра всякие, тьфу, пройденный этап. Кратко в двух словах. Приложение написано на С, использует фреймворк DPDK. С точки зрения эксплуатации представляет собой отдельный апплайнс на сети ДЦ, на который динамически заруливается трафик, котрый необходимо пофильтровать. Скалится линейно, добавляешь ядер - больше лопатишь трафика. Весь не тсп трафик проходит без обработки (в моих реалиях UDP/ICMP должны фильтроваться выше тупорылыми стейтлес фильтрами, тем же флоуспеком). Стейтлес механизм реализовывал под впечатлением от выкуривания исходников PF, netfilter, ipfw, и самое главное - статьи Гвидо Ван Ройа. В итоге родил можно сказать свое. Стейт таблица защищена механизмом синпрокси с генерацией синкук. Врубается автоматически, в зависимости от кол-ва полуоткрытых соединений (трешолд настраивается). Работает вроде как довольно быстро, на одном тсп ядре intel xeon 1660v3 фильрую 9мппс син флуда, с сотней правил в талице фаерволла (описывается как 5tuple, только вместо точечных портов - их диапазоны, и да, правила правилам - рознь) производительность на ядро падает до 7.5 мппс, думаю вполне ок, так как с двух ядер имею лайн рейт (и да, конкурентных соединений в момент тестирования - сотни тысяч). Так же есть такая штука, как соурс трекинг (аналог PF), могу лимитировать пер срц как колличество конкурентных стейтов, так и рейт установки новых.

Всем привет! Тут в интернетах появилась вот какая фигня https://github.com/medvedv/purifier Представляет собой вроде как быстрый (по современным меркам) прозрачный стейтфул фаерволл, который вроде как должен помочь с ддос атаками на транспортный уровень. Господа, тестируйте, набрасывайте на венти оставляйте фидбек.

Только DPDK, только хардкор =) Такие вещи надо обсуждать под пиво и в Skype :) Мой - energy_true. Ну мой скайп ты знаешь )

Только DPDK, только хардкор =)

Да, моя ошибка, посыпаю голову пеплом. В даташите про qinq в отношении rss ничего не сказано, собрал лабу, проверил, RSS считается для фреймов с двумя влан тегами.

RSS работает не в драйвере, а в железе. Не было и не будет.

Никакой я не гуру :) show firewall filter __flowspec_default_inet__

orlik, flowspec фильтруется нормально, не забывайте про valdation. Но да, специальным образом сформированный флоу на определенном софте может вызвать глобальные проблемы, что мы видели на примере cloudflare. rdntw, cloudflare лег из-за бага в junos, на сколько я помню они анонсировали флоу с матчингом по длине пакета больше 65535 байт, что привело к падению. Кстати, в junos есть(возможно уже пофиксили) еще один баг, приводящий к крашу dfwd процесса. pavel.odintsov, у джуниперов имплементация flowspec фильтров не отличается от фаервольных фильтров. У циски, на сколько я помню, flowspec реализован так же как и PBR, со всеми его ограничениями. Вот пост на НАНОГе http://mailman.nanog.org/pipermail/nanog/2011-January/030051.html , правда там речь идет о DPC с старым I-chip, не знаю как дела обстоят на trio. SyJet, sup720 не умеет в flowspec, у циски на данный момент только ASR9k поддерживает. И да, наверно было бы интересно комьюнити узнать кто из операторов, присутствующих в РФ готов обмениваться flowspec с пирами, либо предоставляет кастомерам на коммерческой основе.