SaveTheRbtz Опубликовано 15 октября, 2010 · Жалоба Есть сервер на FreeBSD 7.2 Есть задача - выжать максимальный pps. Аттака производится TCP syn пакетами по 74 байта (20tcp+20tcp.options+20ip+14ethernet+8b/10b = 100 байт). Сетевухи em всякие разные. Что посоветуете крутить, господа профессионалы? ПС. по завершению внутренних тестов результаты будут выложнены в этот топик. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 15 октября, 2010 · Жалоба Не понятно, сервер маршрутизирует этот syn flood или принимает его и должен как-то отбиться от него? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SaveTheRbtz Опубликовано 16 октября, 2010 · Жалоба Сервер HTTP балансер. Должен принимать HTTP запросы и проксировать дальше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 16 октября, 2010 · Жалоба Стандартный механизм tcp_syncookies не помогает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SaveTheRbtz Опубликовано 16 октября, 2010 · Жалоба Это понятно. Да и оно по дефолту включено. Кроме етого нечего не посоветуете? ПС. В принципе можно абстрагироваться от syn-flood'а и просто сосредоточиться на максимальном pps сервера на маленьких ~74байтовых пакетах. Какие могут быть рекомендации по настройке сервера? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 17 октября, 2010 · Жалоба Сервер HTTP балансер. Должен принимать HTTP запросы и проксировать дальше.Не понятно как оно проксирует:либо это типа haproxy которое в юзерспейс крутится, либо это pf + source hash или типа того, когда в юзерспейс ничего не приходит. Ещё в PF есть synproxy как раз для таких случаев. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SaveTheRbtz Опубликовано 17 октября, 2010 · Жалоба Прокси в юзерленде. Сложнаая логика. Pf научить так балансить будет довольно нетривиально. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 17 октября, 2010 · Жалоба Тогда в чём вопрос? О том, как ограничить кол-во tcp-соединений с одного IP адреса на 80 ый порт? Нет соединения, значит пришёл мусорный пакет(если это не syn) - дропаем его. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 17 октября, 2010 · Жалоба Тогда добавляйте тазик на вход, который будет делать synproxy до хттп балансера. synproxy - это когда PF сам устанавливает соединение, если оно установилось то он подключается к конечной точке и гоняет трафик. Только в таком случае в таблице его состояний в два раза больше записей получается. Придётся таймауты подкрутить, чтобы таблица быстрее очищалась. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SaveTheRbtz Опубликовано 17 октября, 2010 (изменено) · Жалоба Тогда в чём вопрос? О том, как ограничить кол-во tcp-соединений с одного IP адреса на 80 ый порт? Нет соединения, значит пришёл мусорный пакет(если это не syn) - дропаем его.Вопрос в том как заставить FreeBSD принять как можно больше мусорного syn-flood трафика не влияя на работу "хороших" клиентов. Желательная пропускная способность ~1M pps на 1Gb link на вход (что близко к теоретическому максимуму в 1.25M 74х байтных пакетов) Тогда добавляйте тазик на вход, который будет делать synproxy до хттп балансера.В чём смысл отдельной сущности перед балансером, в чём сложность организации той же функциональности прямо на балансере? В прочем ладно. Как бы вы оптимизировали pps на этом самом тазике который стоит перед балансером? Изменено 17 октября, 2010 пользователем SaveTheRbtz Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 17 октября, 2010 · Жалоба Смысл в том, что: - на вход тазиков можно поставить не один - распределение нагрузки проца "Оптимизировать ппс" на тазике на входе не получится, если только отключить его. В такой постановке вопроса. А сам сервер тюнить драйвера сетевух, лучше чтобы em от интела, тюнить количество mbuf, колличество стейтов в pf, таймауты в pf. Под pf лучше двух ядерные процы, по заверениям местных практиков, типа е8500 с разгоном. Включить fastforward, в некоторых случаях может помочь, но основной тюнинг всё равно в pf, ибо он фактически будет все соединения держать сам - соответственно никакого scrub, правил как можно меньше, те что будут лучше с quick делать. Один сервер вряд ли прожуёт такой объём по ппс. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SaveTheRbtz Опубликовано 18 октября, 2010 · Жалоба Смысл в том, что:- на вход тазиков можно поставить не один - распределение нагрузки проца Ну мы также можем просто доставить ещё балансеров. А сам сервер тюнить драйвера сетевух, лучше чтобы em от интела, тюнить количество mbuf, колличество стейтов в pf, таймауты в pf.pf-отключён, ибо является в нашем случае боттлнеком. Нагрузка на mbuf при синфлуде минимальна Включить fastforwardСервер на L3 нечего не форвардит. Один сервер вряд ли прожуёт такой объём по ппс.Пока выжали 2M pps(1 на вход + 1 на выход) на wawa'вских дровах, но на 2х линках в LACP Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...