[airman]

Возжможно ли на каком либо серверном ( например 2х16core Opteron), используя карты i350, сделать защиту от синуфлуда с подстановкой обратного IP?

Характеристики потока- до 1-2MPPS. Linux, FreeBSD - роли не играет. Железные защиты не предлагать, денег на них сейчас нет.

[NiTr0]

Скорее всего придется ваять свой модуль ядра для этого (эдакий прокси-имитатор открытого tcp порта, который, в случае успешного соединения клиента, устанавливает уже сессию с целевым сервисом). Мне готовые решения вроде не попадались на глаза. Ресурсов скорее всего это много не займет, 1-2 мппс флуда думается даже какой-то i5 скушает.

P.S. syn cookies - не спасают?

[nuclearcat]

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

[airman]

Скорее всего придется ваять свой модуль ядра для этого (эдакий прокси-имитатор открытого tcp порта, который, в случае успешного соединения клиента, устанавливает уже сессию с целевым сервисом). Мне готовые решения вроде не попадались на глаза. Ресурсов скорее всего это много не займет, 1-2 мппс флуда думается даже какой-то i5 скушает.

P.S. syn cookies - не спасают?

Как оказалось не кушает. Прерываниями забиваются все ядра и пиши пропало. Может я не так настраивал конечно. пробовал на линуксе. Правда слышал что во фре есть SYNPROXY в PF. но еще не пробовал.

[NiTr0]

Главная проблема в том, что эти процедуры сейчас не раскидываются по ядрам.

Работают в контексте прерываний очередей? Для 8-ядерной машины это еще не критично, т.к. у сетевушки до 8 очередей...

 

Как оказалось не кушает. Прерываниями забиваются все ядра и пиши пропало.

Попробуйте подтюнить немного сетевую подсистему, драйвер (interrupt throttling задать), пересмотрите правила иптейблса...

[airman]

собственно пробовал вот так

ipset -N ddos hash:ip maxelem 4294967295 hashsize 100000 timeout 120

iptables -A INPUT -m set --match-set ddos src -d 91.212.124.50 -p tcp --dport 7778 --syn -j ACCEPT

iptables -A INPUT -s 0/0 -d 91.212.124.50 -p tcp --dport 7778 --syn -j SET --add-set ddos src

iptables -A INPUT -s 0/0 -d 91.212.124.50 -p tcp --dport 7778 --syn -j DROP

 

две пары по гигабиту собраны в LACP (по 16 прерываний на каждую сторону) прерывания распределены каждое на свое ядро.

без правил файрвола при генерации потока в 600-700 кппс загрузка на процов приблизительно 15-20% на каждое ядро. при включении файрвола получаем мгновенную загрузку всех ядер под 100%

Изменено 12 августа, 2012 пользователем airman

[NiTr0]

Увеличьте хэш (скажем 256к-512к-1М-2М, поэкспериментируйте), попробуйте утсановить хэш кратный степени 2. Сделайте профайлинг, посмотрите, кто именно кушает. И 20% загрузки при 600 кппс на голом форвардинге - как-то многовато пожалуй будет.

Хотя толку от приведенных правил при условии абсолютно рандомного src ip у источника(ов) флуда - примерно ноль.

[airman]

Для начала давайте разберемся с нагрузкой при голом форвардинге. могу предоставить тестовый сервер. и показать настройки. Но меньше 15-20% на ядро у меня не получилось.

а что по поводу правил- получается следующее при первом обращении адрес заносится в таблиц у и дропается. при втором ( если это таки клиент а не гератор пакетов), пакеты пропускаются. время жизни адресов в таблице 120 секунд.

Изменено 12 августа, 2012 пользователем airman

[nuclearcat]

Работают в контексте прерываний очередей? Для 8-ядерной машины это еще не критично, т.к. у сетевушки до 8 очередей...

 

Если вкратце, все процессоры блокируются на одном спинлоке.

http://comments.gmane.org/gmane.linux.network/231827

[NiTr0]

Для начала давайте разберемся с нагрузкой при голом форвардинге. могу предоставить тестовый сервер. и показать настройки. Но меньше 15-20% на ядро у меня не получилось.

Запустите oprofile, посмотрите, кто ресурсы кушает. К слову, какое ядро?

 

а что по поводу правил- получается следующее при первом обращении адрес заносится в таблиц у и дропается. при втором ( если это таки клиент а не гератор пакетов), пакеты пропускаются. время жизни адресов в таблице 120 секунд.

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

 

Если вкратце, все процессоры блокируются на одном спинлоке.

Понял. Но это вроде касается не форвардинга, а непосредственно tcp сокета.

[airman]

последняя убунта 3.2 какое то, в данный момент гялнуть не могу.

90% синфлудовых атак генерится при помощи hping3, а там чистый рандом

[snark]

Посмотрите это:

http://www.ntop.org/products/pf_ring/hardware-packet-filtering/

Может поможет.

[alibek]

Я бы попробовал сделать на pf (для FreeBSD).

[photon]

Я бы попробовал сделать на pf (для FreeBSD).

В pf уже убрали giant lock и он обрабатывает пакеты параллельно на нескольких процессорах?

[Telesis]

 

В pf уже убрали giant lock и он обрабатывает пакеты параллельно на нескольких процессорах?

вроде как NetBSD собирались сделать npf для этого.

[Сильвер]

Я бы попробовал сделать на pf (для FreeBSD).

В pf уже убрали giant lock и он обрабатывает пакеты параллельно на нескольких процессорах?

 

@glebius активно пилит эту тему. http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html

[photon]

Кто и что там пилит -- это вопрос весьма отдаленной перспективы. Через несколько лет, возможно, это взлетит и будет использоваться. Я тоже не вижу иного решения, кроме специализированного модуля ядра. Имеющиеся файрволы не слишком эффективны и не пропустят такой трафик.

 

С другой стороны, можно просто воспользоваться tc ingress policing для пакетов с установленным syn-флагом. Есть пример: http://lartc.org/howto/lartc.cookbook.synflood-protect.html, но он мне не нравится, потому что там используется iptables для маркировки syn-пакетов. Оптимальнее сделать фильтр с помощью классификатора u32, а iptables вообще не подгружать.

Изменено 24 августа, 2012 пользователем photon

[Сильвер]

Кто и что там пилит -- это вопрос весьма отдаленной перспективы. Через несколько лет, возможно, это взлетит и будет использоваться.

Это уже реально работает - http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006662.html

 

Я тоже не вижу иного решения, кроме специализированного модуля ядра. Имеющиеся файрволы не слишком эффективны и не пропустят такой трафик.

 

@luigi так не думает.

[photon]

Кто и что там пилит -- это вопрос весьма отдаленной перспективы. Через несколько лет, возможно, это взлетит и будет использоваться.

Это уже реально работает - http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006662.html

Вам не боязно ставить настолько свежий код в production? Но если получится с помощью pf и synproxy обработать 2 Mpps, то я буду только рад.

 

Я тоже не вижу иного решения, кроме специализированного модуля ядра. Имеющиеся файрволы не слишком эффективны и не пропустят такой трафик.

 

@luigi так не думает.

netmap -- это не что иное, как реализация DMA для обработки трафика в юзерлэнде, т.е. альтернатива bpf и сокетам. Для Linux такая штука тоже есть: http://www.ntop.org/products/pf_ring/dna/ . Все равно придется городить какой-то прокси-сервер, который будет обрабатывать TCP-соединения до веб-сервера, но благодаря netmap он может быть реализован как пользовательский процесс, а не как модуль ядра.

Изменено 25 августа, 2012 пользователем photon

[jab]

Вам не боязно ставить настолько свежий код в production? Но если получится с помощью pf и synproxy обработать 2 Mpps, то я буду только рад.

 

Это не вопрос боязни, это вопрос предварительного нагрузочного тестирования в условиях, приближенных к боевым. :-)

[NiTr0]

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

Угу. Хотя профит от этого сомнителен - не думаю, что трудозатраты будут сильно отличаться. Разве что при падении юзерленд процесса, возможно, ничего страшного не случится (хотя смотря как netmap/иже с ним переживет смерть процесса-приемника без деинициализации подсистемы - я с ходу не скажу). Зато налицо - дополнительная сущность, снижающая общую производительность системы.

[airman]

Тоесть на текущий момент защиты от synflood генерируемого при помощи hping3 с рандомным соурсоми размером в 1-2-3mpps, кроме решений от того же джуника стоимость в боинг нет??

[bifit]

Есть несколько вариантов хардварных. Например, Radware DefensePro 8412 с двумя парами портов 10G честно держит 10Mpps syn flood'а (сделан на сетевых процессорах EZChip NP-3).

[x86]

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

1. hashsize нужно ставить максимальное, кратное степени двойки, лишь-бы памяти под него хватало - попробуйте 16777216 для начала.

2. iptables -t raw -A PREROUTING -j NOTRACK

3. Поставить максимальные TX/RX дескрипторы для сетевых.

4. Немного потимизировать правила iptables

iptables -N our

iptables -A our -m set --match-set ddos src -j ACCEPT

iptables -A our -j SET --add-set ddos src

iptables -A our -j DROP

iptables -A INPUT -p tcp -d 91.212.124.50 --dport 7778 --syn -g our

5. Ну и посмотреть oprofile, что-же кушает процессор.

6. В старом( v4.5 ) ipset был iptreemap - может он будет эффективнее.

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

Изменено 23 сентября, 2012 пользователем x86

[Alex/AT]

Несколько рекомендаций:

1. Машина - чистый роутер, сервис уже за ней, а не на ней. Linux 3.x x86_64

2. Очереди развешивать через irqbalance

3. conntrack hashsize = conntrack_max или даже conntrack_max * 2 (да, памяти сожрёт прилично, но зато выборка будет максимально быстрой)

4. Список IPSet ни в коем случае не hash:net. hash:ip нормально. Размер хеша = предполагаемому числу записей, можно с запасом

5. Аппаратные TX/RX queue на максимум

6. txqueuelen = TX queue

7. dev_weight = 16, netdev_budget = 256, netdev_max_backlog = 16000 (для начала)

8. RPS/RFS/XPS - включить, несмотря на аппаратную раскидку по ядрам

 

На 2x16C Opteron железо (навскидку) должно пропускать с указанными карточками до 8-10 Mpps (а то и больше - 2x6C Xeon пропускает ~2Mpps PPPoE с шейперами) чистого роутинга, если шины позволят. С conntrack будет сильно меньше, но тем не менее. Если есть желание возиться - попутно рекомендую сразу поставить oprofile, и уже под нагрузкой смотреть, куда упирается.

Изменено 23 сентября, 2012 пользователем Alex/AT