FreeBSD и syn-flood

[SaveTheRbtz]

Есть сервер на FreeBSD 7.2

Есть задача - выжать максимальный pps. Аттака производится TCP syn пакетами по 74 байта (20tcp+20tcp.options+20ip+14ethernet+8b/10b = 100 байт).

Сетевухи em всякие разные.

 

Что посоветуете крутить, господа профессионалы?

 

ПС. по завершению внутренних тестов результаты будут выложнены в этот топик.

 

[s.lobanov]

Не понятно, сервер маршрутизирует этот syn flood или принимает его и должен как-то отбиться от него?

[SaveTheRbtz]

Сервер HTTP балансер. Должен принимать HTTP запросы и проксировать дальше.

[s.lobanov]

Стандартный механизм tcp_syncookies не помогает?

[SaveTheRbtz]

Это понятно. Да и оно по дефолту включено. Кроме етого нечего не посоветуете?

 

ПС. В принципе можно абстрагироваться от syn-flood'а и просто сосредоточиться на максимальном pps сервера на маленьких ~74байтовых пакетах. Какие могут быть рекомендации по настройке сервера?

[Ivan_83]

Сервер HTTP балансер. Должен принимать HTTP запросы и проксировать дальше.

Не понятно как оно проксирует:

либо это типа haproxy которое в юзерспейс крутится, либо это pf + source hash или типа того, когда в юзерспейс ничего не приходит.

 

Ещё в PF есть synproxy как раз для таких случаев.

[SaveTheRbtz]

Прокси в юзерленде. Сложнаая логика. Pf научить так балансить будет довольно нетривиально.

[s.lobanov]

Тогда в чём вопрос? О том, как ограничить кол-во tcp-соединений с одного IP адреса на 80 ый порт? Нет соединения, значит пришёл мусорный пакет(если это не syn) - дропаем его.

[Ivan_83]

Тогда добавляйте тазик на вход, который будет делать synproxy до хттп балансера.

 

synproxy - это когда PF сам устанавливает соединение, если оно установилось то он подключается к конечной точке и гоняет трафик.

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

Придётся таймауты подкрутить, чтобы таблица быстрее очищалась.

[SaveTheRbtz]

Тогда в чём вопрос? О том, как ограничить кол-во tcp-соединений с одного IP адреса на 80 ый порт? Нет соединения, значит пришёл мусорный пакет(если это не syn) - дропаем его.

Вопрос в том как заставить FreeBSD принять как можно больше мусорного syn-flood трафика не влияя на работу "хороших" клиентов. Желательная пропускная способность ~1M pps на 1Gb link на вход (что близко к теоретическому максимуму в 1.25M 74х байтных пакетов)

 

Тогда добавляйте тазик на вход, который будет делать synproxy до хттп балансера.

В чём смысл отдельной сущности перед балансером, в чём сложность организации той же функциональности прямо на балансере? В прочем ладно. Как бы вы оптимизировали pps на этом самом тазике который стоит перед балансером? Edited October 17, 2010 by SaveTheRbtz

[Ivan_83]

Смысл в том, что:

- на вход тазиков можно поставить не один

- распределение нагрузки проца

 

"Оптимизировать ппс" на тазике на входе не получится, если только отключить его. В такой постановке вопроса.

 

А сам сервер тюнить драйвера сетевух, лучше чтобы em от интела, тюнить количество mbuf, колличество стейтов в pf, таймауты в pf.

Под pf лучше двух ядерные процы, по заверениям местных практиков, типа е8500 с разгоном.

Включить fastforward, в некоторых случаях может помочь, но основной тюнинг всё равно в pf, ибо он фактически будет все соединения держать сам - соответственно никакого scrub, правил как можно меньше, те что будут лучше с quick делать.

 

Один сервер вряд ли прожуёт такой объём по ппс.

[SaveTheRbtz]

Смысл в том, что:

- на вход тазиков можно поставить не один

- распределение нагрузки проца

Ну мы также можем просто доставить ещё балансеров.

 

А сам сервер тюнить драйвера сетевух, лучше чтобы em от интела, тюнить количество mbuf, колличество стейтов в pf, таймауты в pf.

pf-отключён, ибо является в нашем случае боттлнеком.

Нагрузка на mbuf при синфлуде минимальна

 

 

Включить fastforward

Сервер на L3 нечего не форвардит.

 

Один сервер вряд ли прожуёт такой объём по ппс.

Пока выжали 2M pps(1 на вход + 1 на выход) на wawa'вских дровах, но на 2х линках в LACP