[alexeymanikin]

Так или иначе любой провайдер сталкивается с проблемами DDOS атак на свои ресурсы. Когда в нашей компании BeGet.com встала задача прозрачной фильтрации трафика на конечные сервера, мы написали свое решение Syncookied, которое изначально предполагалось только для защиты от syn, ack, data flood, но потом переросло в достаточно большую и обширную систему по защите от разного типа атак. Данным решением мы бы хотели поделиться со всем сообществом, так как на текущий момент открытых аналогов ему мы не нашли (или мы о них не знаем).

 

Главная посыл описания состоит в:

Фактически 10 ядер процессора Intel Xeon E5-2680v3 могут обрабатывать до 10 гигабит трафика. Один физический сервер способен обрабатывать более 40 гигабит трафика.

 

Ссылка на статью:

https://beget.com/ru/articles/syncookied

 

Ссылка на исходный код:

https://github.com/LTD-Beget/syncookied

[snvoronkov]

Оно-ж не универсально, как я из статьи понял!

 

Защищает linux-сервера - модуль ядра потребен.

[alexeymanikin]

Оно-ж не универсально, как я из статьи понял!

 

Защищает linux-сервера - модуль ядра потребен.

 

Да Вы правы - мы делали решение которое идеально подходит для наших целей. И думаю оно подойдет многим другим организациям со схожей инфраструктурой. У универсального решения есть своим минусы о которых я писал в статье.

 

Это полный мониторинг трафика в оба направления с изменением каждого пакета и разрыв сессий.

[snvoronkov]

Тут же на форуме уже множество решений есть. Например, от Павла Одинцова, как наиболее "универсально продвинутое"

 

http://forum.nag.ru/forum/index.php?showtopic=89703&st=0

 

Хотя, в вашем куча преимуществ при обслуживании чего-то типа серверных стоек.

 

З.Ы.: Я сам что-то в последнее время не уверен, что и далее сервисы будут на линуксе крутиться. Поэксплуатиров свежие Debian 8 & CentOS 7 хочется проблеваться. Это-ж надо такое непредсказуемое ублюдство в систему впилить. (Это я про systemd.) Потому хочется видеть нечто более универсальное, ибо слаку, крукс и генту в продакшн тянуть что-то неохота.

[Ivan_83]

Нет чтобы FreeBSD поставить и заюзать в PS synproxy...

 

По поводу тестов производительности SHA1.

1. В ядре же вроде нельзя юзать FPU, MMX, SSE, AVX ибо это приводит к тому что нужно ещё и эти регистры сохранять в контекст и оно становится ощутимо дольше. Если такое реализовано.

2. Для вашего вырожденного случая полный SHA1 не нужен, можно было версию оптимизированную именно для вашего случая, это как минимум облегчённый инит и выкидывание кучи проверок.

3. Можно было вообще отказаться от SHA1 и найти что то пошустрее.

4. Так https://github.com/polachok/sha-bench/blob/master/sha1_glue.c - тестировать не правильно:

-- 1. gettimeofday(&tval_before, NULL); - это время со всеми переключениями контекста и пр

-- 2. char data[64] = "fdsjflsjfklsjklfjwoieroiwejfslkdjioruwoeirflfjskdjoiwurweirweoiw"; - на входе в ядре данных меньше

-- 3. memset(digest, 0, 256); - тупо потому что хэш меньше, и вообще оно там не надо.

 

 

TCP/IP checksum - нахрена вы её вообще вычисляете?

В ядре для этого всё есть, более того если сетевуха умеет и оно не отключено то она сама в желез это посчитает, главное только правильные флаги в sk_buf (или как оно там в линуксах) выставить.

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

[snvoronkov]

Нет чтобы FreeBSD поставить и заюзать в PS synproxy...

Иван, ну PF-же. ;-)

 

И что-то меня сильно большие сомнения грызут, что он оно на 10-ке и выше прососет. От гиант-локов только-только избавились с грехом попалам. И теперь оно падает периодически.

[aabc]

Вариант с использованием SynCookie нас не устраивал - не на всех серверах есть лишние ресурсы для подсчета SHA1, не на всех стоят подходящие сетевые карты (если на сервере 50 мегабит трафика, встроенная в материнскую плату сетевая карта вполне справляется со своей задачей) и отнюдь не все сервера подключены 10 гигабитным интерфейсом. А генерировать 1,1 гигабит SYN флуда с подменой адреса отправителя не такая уж и сложная задача, с которой может справиться любой школьник, если провайдер не фильтрует исходящий трафик. Поэтому необходимо было решение, работающее не на конечном сервере.

 

Пара вопросов.

 

если на сервере 50 мегабит трафика, встроенная в материнскую плату сетевая карта вполне справляется со своей задачей

 

Если 1гбит, то не справляется?

 

отнюдь не все сервера подключены 10 гигабитным интерфейсом. А генерировать 1,1 гигабит SYN флуда с подменой адреса отправителя не такая уж и сложная задача, с которой может справиться любой ш

 

Перефразирую ваше довод: нет смысла фильтровать SYN-flood на конечном сервере, с 1гбит картой и интерфейсом, так как такой канал легко забить 1.1гбит SYN-floodа.

 

То есть аргумент основывается на ширине канала, который можно забить строго SYN-floodом.

 

Вопрос: что мешает забивать его не SYN-floodом, а любым другим floodом?

 

SYN-flood позволяет небольшими ресурсами положить сервис так как SYN-queue имеет конечную длину. То есть, нет необходимости генерировать 1.1гбит SYN-floodа, чтоб положить конечный сервер в котором нет SYN-cookies, и нет необходимости генерировать 1.1гбит SYN-floodа, чтоб положить конечный сервер в котором есть SYN-cookies, но 1гбит канал. Следовательно, при чём тут SYN-cookies?

[snvoronkov]

Вопрос: что мешает забивать его не SYN-floodом, а любым другим floodом?

Ровно этот-же вопрос выбивает логику у большинства начинающих создателей средств защиты от DDoS. :-)

[pavel.odintsov]

Все крайне просто, все другие варианты заливки КРОМЕ syn можно легко и непринужденно отсечь следующими методами ВНЕ своей инфраструктуры:

- Flow Spec у оператора (RETN, Rascom)

- Static ACL на порту у вышестоящего оператора на амплификации

- BGP коммунити (667), которое отсечет на заданнынй префикс либо весь UDP либо только популярные амлификационные порты

- Статический ACL на своем железе на популярные амплификационные порты.

 

Все эти методы - типовые и не требуют магии, а вот если бьют SYN, то все, кранты, никакой помощью от магистрала не отделаешься. Что ребята и реализовали)

[NiTr0]

все другие варианты заливки КРОМЕ syn можно легко и непринужденно отсечь следующими методами ВНЕ своей инфраструктуры:

ну-ну, как отсечь ddos мусорными tcp пакетами на валидный порт, которые тупо забьют канал? :) а вернее - в чем принципиальная разница между забиванием канала синфлудом и забиванием канала прочим флудом (темы обработки всего этого не касаемся)?

[Ivan_83]

Иван, ну PF-же. ;-)

Очепятался.

PF было самое первое (после ппп клиента) что я освоил в DragonFlyBSD, и тогда же понял что в стрекозе он старее даже чем в доках на фрю :)

 

И что-то меня сильно большие сомнения грызут, что он оно на 10-ке и выше прососет. От гиант-локов только-только избавились с грехом попалам. И теперь оно падает периодически.

У меня скромные нагрузки SOHO практически, иногда всплески до гигабита, проблем не замечал начиная с 10.0 до 10.3 текущей.

[alexeymanikin]

Постараюсь ответить на все вопросы (форум с утра писал, что у меня осталось только одно сообщение =)

 

По поводу тестов производительности SHA1.

1. В ядре же вроде нельзя юзать FPU, MMX, SSE, AVX ибо это приводит к тому что нужно ещё и эти регистры сохранять в контекст и оно становится ощутимо дольше. Если такое реализовано.

Весь код который который считает SHA1 взят из ядра последней версии. Код использующий AVX ощутимо быстрее чем написанный на С. Я думаю это легко проверить. Для примера вот код который мы используем из ядра

http://lxr.free-electrons.com/source/arch/x86/crypto/sha1_avx2_x86_64_asm.S

 

2. Для вашего вырожденного случая полный SHA1 не нужен, можно было версию оптимизированную именно для вашего случая, это как минимум облегчённый инит и выкидывание кучи проверок.

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

3. Можно было вообще отказаться от SHA1 и найти что то пошустрее.

 

В статье я писал - можно использовать технологию SynProxy и в ней можно делать хоть XOR - мы так делали, когда тестировали. Опять же модуль SynProxy у нас так же реализован (правда это ломает все концепцию просмотра трафика только в одну сторону. Например можно ставить защиту при подключении аплинка и уже не важно как и через кого пойдет обратный пакет, SynProxy должен стоять у сервера и смотреть трафик в обе стороны). SynProxy - не тестировали, нормально и на данный момент работает кривовато. Еще раз повторюсь - это решение идеально для нашей инфраструктуры и подомным нам.

 

4. Так https://github.com/p...ter/sha1_glue.c - тестировать не правильно:

-- 1. gettimeofday(&tval_before, NULL); - это время со всеми переключениями контекста и пр

-- 2. char data[64] = "fdsjflsjfklsjklfjwoieroiwejfslkdjioruwoeirflfjskdjoiwurweirweoiw"; - на входе в ядре данных меньше

-- 3. memset(digest, 0, 256); - тупо потому что хэш меньше, и вообще оно там не надо.

 

Возможно Вы правы, но я не думаю, что Ваши результаты будут сильно отличаться от наших.

 

TCP/IP checksum - нахрена вы её вообще вычисляете?

 

Мы умышленно отключаем эту возможность на сетевой карте, уже не вспомню почему - но что-то работало криво. Если критично могу уточнить.

 

Далее

 

Тут же на форуме уже множество решений есть. Например, от Павла Одинцова, как наиболее "универсально продвинутое"

 

Если Вы более детально посмотрите на FastVPSMon, а еще лучше загляните в его код - можно увидеть, что оно не защищает от ДДОС атак, а только сигнализирует о них на основании анализа трафика. Не кто, не мешает на действия при обнаружении атаки поставить syncookied =)

 

Перефразирую ваше довод: нет смысла фильтровать SYN-flood на конечном сервере, с 1гбит картой и интерфейсом, так как такой канал легко забить 1.1гбит SYN-floodа.

 

Давайте говорить откровенно, ставить 10G на каждый сервер, очень накладное занятие, часто на сервере просто нет ресурсов, что бы фильровать трафик. Часто SYN/DATA/ACK флуд, прилетает более одного гигабита. Все атаки с UDP усилением мы фильруем на роутере или syncookied или по средствам flowspec, атаки до 40 гигабит мы не замечаем. Смысл в том, что syncookied ставиться либо до, либо сразу после роутера (бордера) где возможно выделить максимальный канал. И что более важно - нет разницы по какому маршруту пойдет обратный пакет.

 

В данном случае это идеальное решение так как у нас: более 1 бордера, около 20 аплинков, более 700 серверов. Все сервера под нашим администрированием и на всех серверах стоит Linux.

 

Для включения защиты сервера, причем прозрачной (то есть мы ее включили/выключили) и даже сессии не порвались (в отличии от SynProxy). SynCookied может фильтровать любой вид флуда, трафик по любым параметрам - да сервера доходит только валидные пакеты. Да есть еще возможность http флуда - но это лучше делать на стороне сервера, так как он имеет больше информации о запущенном на нем ПО.

 

DATA/ACK флуд отлично фильрует и сервер - но этим флудом можно легко забить канал и его не так просто порезать на сетевом железе.

 

ну-ну, как отсечь ddos мусорными tcp пакетами на валидный порт, которые тупо забьют канал? :) а вернее - в чем принципиальная разница между забиванием канала синфлудом и забиванием канала прочим флудом (темы обработки всего этого не касаемся)?

 

Syncookied ведет тракинг соединений и его можно настроить так, что не валидные пакеты не будут доходить на сервер. (но это требует разрыва существующих соединений). То есть если приходит DATA пакет - и нет открытого соединения - он просто дропается и не передается на сервер. Это одно из преимуществ syncookied, так как бесплатных подобных решений я не нашел. Но этот функционал есть у arbor, f5, Juniper src, он реализован у сервисов по защите от DDOS.

 

Скажем так syncookied позволяет фильтровать весть трафик до L4 по OSI включая: SYN/DATA/ACK/REST и любой другой флуд скажем на скорости 40 гигабит (и более) не за 120000$ как это предлагает F5 или Juniepr, а за 6-8к купив только хороший процессор и сетевую карту. Если посмотреть, что внутри Arbor - просто PC с хорошей сетевой картой. Вся стоимость - это web морда и софт.

 

web морду мы не делали, а софтом делимся.

[NiTr0]

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

кто мешает установить соединение, а потом в него нагадить невалидных пакетов (с левым sequence id и т.п.), забив канал сервера?

 

Это одно из преимуществ syncookied, так как бесплатных подобных решений я не нашел.

iptables -A FORWARD -m state --state INVALID -j DROP

 

и да, насколько деградирует производительность при скажем 1 млн сессий? а 10 млн?

[snvoronkov]

У меня скромные нагрузки SOHO практически, иногда всплески до гигабита, проблем не замечал начиная с 10.0 до 10.3 текущей.

Вобщем, мой опыт - без крэшей, но с дедлоками раз в два месяца, если на pf фряки дать приличную нагрузку по udp сервисам. Жив только терминал, сеть и файлуха стоят раком. Началось где-то с 9.2. Нагрузки - где-то полгига, dns/snmp микса.

 

Потому и считаю вредным совет про pf.

[alexeymanikin]

iptables -A FORWARD -m state --state INVALID -j DROP

скажем так на 500000к SYN пакетов в секунду сервер уже умрет на мертво. Отслеживание соединений в Linux достаточно тяжелая операция.

 

Мы тестировали наше решение на 10 (20) гигабитах и с задачей фильтрации трафика оно справлялось и оно отлично маштабируется на любые объемы. Это не решение для конечного сервер, это инфраструктурное решение.

Сравнивать его с iptables, либо Вам не прилетали мощные DDOS атаки, либо не очень есть понимание что такое syncookied и в каких условиях его можно использовать.

[pavel.odintsov]

все другие варианты заливки КРОМЕ syn можно легко и непринужденно отсечь следующими методами ВНЕ своей инфраструктуры:

ну-ну, как отсечь ddos мусорными tcp пакетами на валидный порт, которые тупо забьют канал? :) а вернее - в чем принципиальная разница между забиванием канала синфлудом и забиванием канала прочим флудом (темы обработки всего этого не касаемся)?

 

В моей практике такая атака встречается 1 раз из 1000 и я склонен пренебрегать такими малыми процентами. Вы забываете, что UDP/TCP SYN - он подделывается и спуфится. Если Вы говорите о валидном TCP, это означет, что он идет без спуфинга, а это в свою очередь означает, что легко найти источник атак и купировать его либо силами магистрала либо дать по голове провайдеру этого злого товарища.

 

Алексей, а как с защитой от ACK флуда?

 

В статье фундаментальная ошибка:

 

Нагрузка, создаваемая фильтрацией трафика 12.755pps (теоретический предел при размере пакета 74 байта + 4 байта заголовок ethernet)

 

Предел это 14 миллионов пакетов секунду если речь про SYN (64 байта он, 64!). И ровно 14 миллионов пакетов секунду можно выжать на 82599. Другой вопрос в том, что netmap не в силах выжать более 12 mpps (у меня не получилось), а Вы используете его. Попробуйте DPDK и без проблем увидите заветные 14 mpps.

 

Как пример хорошей артиллерии предлагаю moongen, он с легкостью заливает порт 14ю mpps ;)

 

Также про 40GE - я бы уточнил, что говеная карта XL710 в лучшем случае выдаст от силы 20-24 mpps (а может и меньше!) из теоретических 56 mpps (которые ddos'еры не преминут залить!). Так что для 40GE решения нужная совершенно иная карта, например MLX CX-4. Про Intel лучше забыть в таком скоростном диапазоне :(

Изменено 27 августа, 2016 пользователем pavel.odintsov

[NiTr0]

скажем так на 500000к SYN пакетов в секунду сервер уже умрет на мертво. Отслеживание соединений в Linux достаточно тяжелая операция.

речь кажется идет о бесплатных подобных решениях, которых вроде как нет?

ну и да, коннтрак можно натюнить на 5-10 сек таймаут, тогда 500кппс это будет всего 2.5-5 млн сессий, что вполне нормально жуется сервером.

 

Мы тестировали наше решение на 10 (20) гигабитах и с задачей фильтрации трафика оно справлялось

сколько кппс син флуда с рандомных src? как при этом чувствуют себя клиенты, пользующиеся сервисом с медленного gprs/sat internet (где пинг в пару секунд норма, т.е. от syn до установки сессии проходит секунды 2)?

[medvedv]

Алексей, прежде всего спасибо что поделились кодом.

 

открытых аналогов ему мы не нашли (или мы о них не знаем).

https://github.com/medvedv/purifier

 

Главная посыл описания состоит в:

Фактически 10 ядер процессора Intel Xeon E5-2680v3 могут обрабатывать до 10 гигабит трафика. Один физический сервер способен обрабатывать более 40 гигабит трафика.

В лабе на E51660v3 делаю ~9Мппс на ядро, горизонтально скалится идеально.

 

можно использовать технологию SynProxy и в ней можно делать хоть XOR

Я бы не советовал, довольно тривиально узнать секрет.

 

Syncookied ведет тракинг соединений и его можно настроить так, что не валидные пакеты не будут доходить на сервер.

Если я правильно понял, то зная src пользователя можно удобно рвать ему сессии резетами (src порт брутфорсить либо CVE-2016-5696).

 

кто мешает установить соединение, а потом в него нагадить невалидных пакетов (с левым sequence id и т.п.), забив канал сервера?

О, а вот этому как раз помешает purifier, либо другой стейтфул фаерволл.

 

если речь про SYN (64 байта он, 64!). И ровно 14 миллионов пакетов

Паш, ты забываешь про опции. И да, НА 64 байтах - 14.88 Мппс - в простонародье один зигапакет/с. =)

 

коннтрак можно натюнить на 5-10 сек таймаут, тогда 500кппс это будет всего 2.5-5 млн сессий

Сборщик мусора может охренеть от такой заботы.

[nuclearcat]

Чем лучше https://lwn.net/Articles/563151/ ?

[alexeymanikin]

 

Предел это 14 миллионов пакетов секунду если речь про SYN (64 байта он, 64!). И ровно 14 миллионов пакетов секунду можно выжать на 82599. Другой вопрос в том, что netmap не в силах выжать более 12 mpps (у меня не получилось), а Вы используете его. Попробуйте DPDK и без проблем увидите заветные 14 mpps.

 

Как пример хорошей артиллерии предлагаю moongen, он с легкостью заливает порт 14ю mpps ;)

 

Павел - это не фундаментальная ошибка =). Просто вопрос в том, что ты работаешь исключительно с входящим трафиком и тебе нет необходимости отвечать на пакеты... Как я уже написал 12.755Mpss - теоретический предел при размере пакета 74 байта + 4 байта заголовок ethernet. Ссылка есть в статье. В статье все таки есть одна неточность в алгоритме работы syncookie, но ее почему-то не кто не замечает и я решил ее не исправлять =).

 

 

Алексей, а как с защитой от ACK флуда?

 

Отлично, все тоже самое, что и с SYN флудом. Невалидные пакеты не проходят на защищаемый сервер. Валидность пакета проверяется дважды на фаерволе и защищаемом сервере.

 

 

Также про 40GE - я бы уточнил, что говеная карта XL710 в лучшем случае выдаст от силы 20-24 mpps (а может и меньше!) из теоретических 56 mpps (которые ddos'еры не преминут залить!). Так что для 40GE решения нужная совершенно иная карта, например MLX CX-4. Про Intel лучше забыть в таком скоростном диапазоне :(

 

Помниться ты и про 10G intel 710 подобное говорил =). Пропатчили - работает отлично. Как это сделать скоро напишу статью на хабр. В любом случае надо тестировать и разбираться что не так работает.

 

сколько кппс син флуда с рандомных src? как при этом чувствуют себя клиенты, пользующиеся сервисом с медленного gprs/sat internet (где пинг в пару секунд норма, т.е. от syn до установки сессии проходит секунды 2)?

 

Мы тестировали 6Mpps SYN флуда с подменой SRC + 6 Mpps ACK флуда с подменой SRC - ssh не тормозит, ping не теряется, видео с сервера стримиться без проблем. На GPRS если честно не тестировали, но не каких проблем быть не должно.

 

 

Просмотр сообщенияalexeymanikin (26 августа 2016 - 01:47) писал:

открытых аналогов ему мы не нашли (или мы о них не знаем).

 

https://github.com/medvedv/purifier

 

Если я правильно понимаю, на момент когда мы с Вами переписывались в чате - Ваше решение не было открытым. А если бы, Вы выложили его тогда в OpenSource - как минимум, мы бы могли использовать часть Ваших наработок и сократить время разработки на порядок. Но в любом случае я рад, что Вы его выложили его в OpenSource =). Так как открытой реализации SynProxy - действительно не было.

 

alexeymanikin (26 августа 2016 - 01:47) писал:

Главная посыл описания состоит в:

Фактически 10 ядер процессора Intel Xeon E5-2680v3 могут обрабатывать до 10 гигабит трафика. Один физический сервер способен обрабатывать более 40 гигабит трафика.

 

В лабе на E51660v3 делаю ~9Мппс на ядро, горизонтально скалится идеально.

 

Просмотр сообщенияalexeymanikin (26 августа 2016 - 23:21) писал:

можно использовать технологию SynProxy и в ней можно делать хоть XOR

 

Я бы не советовал, довольно тривиально узнать секрет.

 

Насколько я понимаю - Ваше решение реализует SynProxy, разницы нет использовать в нем XOR или более легкий алгоритм - любую замену SHA. Ограничение только в фантазии автора, так как используется полное проксирование соединения.

 

 

Просмотр сообщенияalexeymanikin (26 августа 2016 - 23:21) писал:

Syncookied ведет тракинг соединений и его можно настроить так, что не валидные пакеты не будут доходить на сервер.

 

Если я правильно понял, то зная src пользователя можно удобно рвать ему сессии резетами (src порт брутфорсить либо CVE-2016-5696).

 

Хорошее замечание, приеду с отпуска проверю, проверяем мы seq или нет, в любом случае, если нет - добавлю, технически это просто. Стейтфул фаерволл - мы тоже реализовали (в зачаточном виде для тестирования), но как я писал Выше в нем есть недостатки (и определенные достоинства) - он ставиться в разрыв сети (то есть через него нужно пускать как входящий трафик так и исходящий), он рвет соединения при включении (можно избежать) и выключении (гарантированно). Зато может защищать любой сервер. Для нашей структуры сети больше подходит syncookied, если сеть с разными OS и без доступа к ним - однозначно технология SynProxy.

 

 

NiTr0 (26 августа 2016 - 23:35) писал:

кто мешает установить соединение, а потом в него нагадить невалидных пакетов (с левым sequence id и т.п.), забив канал сервера?

 

О, а вот этому как раз помешает purifier, либо другой стейтфул фаерволл.

 

Бессмысленная задача, так как с таким же успехом можно и валидные пакеты слать. Проверять seq достаточно просто. Если есть большой ботнет и ресурсы для его синхронизации проще атаковать http - а это уже уровень приложения.

 

 

Чем лучше https://lwn.net/Articles/563151/ ?

 

SYNPROXY - в iptables

 

1) Работает локально.

2) У нас начинались проблемы уже при 3-4Mpps, возможно надо как-то тюнить, у нас не получилось. Но в любом случае SYNPROXY работает с сетевым стеком ядра, только в обход отслеживания соединений.

 

По факту - syncookied улучшение данной технологии, то есть мы не стали делать SynProxy (и выносить его на отдельный сервер, как это делает тот же Arbor), а вынесли технологию SynCookie на отдельный сервер. У нас не на всех серверах стоят сетевые карты с 10G и есть лишние ресурсы для фильтрации трафика.

[medvedv]

В статье все таки есть одна неточность в алгоритме работы syncookie, но ее почему-то не кто не замечает и я решил ее не исправлять =).

Ну на первый взгляд вот:

 

>могут передаваться дополнительные опции 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 - возможностью работы с отсутствием симметрии трафика.

[pavel.odintsov]

Про ACK - очень круто :)

 

По цифрам 12 mpps, да, с опциями - примерно так и будет. Вопрос в том, что в идеальном флуде он может быть БЕЗ опций и это не должно быть поводом дропнуть трафик такого клиента.

 

Я говорил про XL710 в контексте 40G, потому что это все же в первую очередь 40GE карта. 10GE лайн рейт от чипа рассчитанного на 40GE - вполне ожидаемо. А вот его расчетная производительность в режиме 40GE увы оставляет желать лучшего.

 

В целом, мой вердикт остается прежним. В хостинге и в случае, когда все оборудование принадлежит и управляется компанией оператором - это решение идеально. В случае же неуправляемых услуг, зверинца из платформ (что делать если заливают какой-либо F5, Windows или FreeBSD) решение не подходит.

 

Решение Владимира - не лишено недостатков, но подобным недостатком не обладает, оно может быть внедрено в любую сеть и установлено на границе сети без понимания, что же стоит внутри охраняемого периметра. Также я более тяготею к DPDK, потому что волосы от фишек netmap у меня подчас начинают седеть.

 

По поводу syn proxy - он стал сильно быстрее в 4й ветке ядер и вполне должен давать цифры в районе 8mpps на ванильном ядре.

Изменено 28 августа, 2016 пользователем pavel.odintsov

[Ivan_83]

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

Я про другое.

Вы же внутрь реализаций походу не смотрели, а там много лишнего для случая с одним не полным блоком.

 

Можно немного распотрошить sha1_transform()

	for (t = 16; t < 80; t ++) {
	W[t] = SHA1_ROTL(1, W[(t - 3)] ^ W[(t - 8)] ^ W[(t - 14)] ^ W[(t - 16)]);
}

for (t = 0; t < 20; t ++) {
	temp = SHA1_ROTL(5, A) + SHA1_Ch(B, C, D) + E + W[t] + K[0];
	E = D;
	D = C;
	C = SHA1_ROTL(30, B);
	B = A;
	A = temp;
}

Учитывая что входные данные меняются незначительно тут можно попробовать оптимизировать, sha1_init вообще выкинуть, как и треть sha1_final связанную с паддингом.

При этом хэш останется валидным sha1, но время выполнения можно немного уменьшить.

 

 

Мы умышленно отключаем эту возможность на сетевой карте, уже не вспомню почему - но что-то работало криво. Если критично могу уточнить.

Это рекомендовали для роутеров, особенно с NAT.

А для всяких раздающих серверов оно мастхэв просто.

[alexeymanikin]

>могут передаваться дополнительные опции TCP для согласования параметров соединения: mss, wscale, timestamp, sack_permitted, window, sack

window - не является опцией

sack - на самом деле в SYN передается только TCPOPT_SACK_PERM, TCPOPT_SACK - в ack пакетах

 

>Номера последовательностей — это, фактически, номера пакетов

На самом деле номера байт в байтовом потоке

 

Верно, даже не заметил. Исправлю.

 

>Кука записывается в значения TCP опций Timestamp

кука записывается в syn-ack, в таймстампе кодируются дополнительные опции

 

Да, я имел в виду это. По поводу 1 минуты, к сожалению нет нормального интернета. Отвечу как приеду в Россию.

 

> Фаервол при получении SYN пакета (через первый интерфейс) отправляет в сеть SYN-ACK пакет (через второй интерфейс)

судя по картинке у фаервола 2 интерфейса - 10G и 1G, скорее всего syn приходят через 10G, и, судя по описанию, syn-ack должны выходить через узкое 1G место. Скорее всего тут ошибка в описании, потому как обратное по моему мнению не имеет смысла.

 

Мы подключали двумя 10G интерфейсами один для входящего трафика, другой для исходящего. Не хотелось усложнять схему коммутатором.

 

 

Учитывая что входные данные меняются незначительно тут можно попробовать оптимизировать, sha1_init вообще выкинуть, как и треть sha1_final связанную с паддингом.

При этом хэш останется валидным sha1, но время выполнения можно немного уменьшить.

 

Да спасибо, посмотрим.

 

Это рекомендовали для роутеров, особенно с NAT.

А для всяких раздающих серверов оно мастхэв просто.

 

Сложности возникали с netmap. Уточню какие.

[alexeymanikin]

Это рекомендовали для роутеров, особенно с NAT.

А для всяких раздающих серверов оно мастхэв просто.

 

https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4

 

netmap does not use features such as checksum offloading, TCP

segmentation offloading, encryption, VLAN encapsulation/decapsulation,

etc. . When using netmap to exchange packets with the host stack, make

sure to disable these features.