форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[Проследить за развитием треда]

"OpenNews: Предотвращение DoS атак в FreeBSD"

Сообщение от opennews (??) on 04-Ноя-04, 09:24

Опубликован  перевод (http://www.bsdportal.ru/viewtopic.php?t=3322)  руководства по уменьшению вредного воздействия от  атак вида "отказ в обслуживании" (DoS) и диагностике источника проблем. Рекомендации применимы как для 4-ой, так и для 5-ой ветки FreeBSD. Кратко: -  "sysctl -w net.inet.tcp.msl=7500" - максимальное количество времени ожидания ACK в ответ на SYN-ACK или FIN-ACK в миллисекундах; -   "sysctl -w net.inet.tcp.blackhole=2" -  все пакеты на закрытый порт отбрасываются без отсылки RST; -   "sysctl -w net.inet.udp.blackhole=1" - отбрасывать пакеты для  закрытых портов; -   "sysctl -w net.inet.icmp.icmplim=50" - защита от генерирование потока ответных пакетов, максимальное количество  ICMP Unreachable и TCP RST пакетов в секунду; -   "sysctl -w kern.ipc.somaxconn=32768" - увеличение числа одновременно открытых сокетов; -  Сборка ядра с опцией DEVICE_POLLING. URL: http://www.bsdportal.ru/viewtopic.php?t=3322 Новость: http://www.opennet.ru/opennews/art.shtml?num=4600

Cообщить модератору | Наверх | ^

Сообщения по теме

[Сортировка по времени, UBB]

1. "Предотвращение DoS атак в FreeBSD"

Сообщение от toor99 (??) on 04-Ноя-04, 09:24

> Сборка ядра с опцией DEVICE_POLLING Спорная рекомендация. Поллинг начинает оправдывать себя при перманентно высокой нагрузке на сеть. Если это высокоскоростной маршрутизатор, к примеру. А так... ну, не знаю. Cомневаюсь, что это оправдано.

Cообщить модератору | Наверх | ^

2. "Предотвращение DoS атак в FreeBSD"

Сообщение от jbond (??) on 04-Ноя-04, 10:08

Очень даже оправданно, переменноя sysctl kern.polling.user_frac задает процент загрузки сети при котором карта переключается в polling (по умолчанию 50), другое дело, что по умолчанию subj деактивирован и нужно задавать kern.polling.enable=1 иначе проку от сборки его в ядре 0

Cообщить модератору | Наверх | ^

3. "Предотвращение DoS атак в FreeBSD"

Сообщение от jbond (??) on 04-Ноя-04, 10:10

Дополнение: и options HZ= рекомендуется от 1000 и выше

Cообщить модератору | Наверх | ^

4. "Предотвращение DoS атак в FreeBSD"

Сообщение от Аноним on 04-Ноя-04, 10:10

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

Cообщить модератору | Наверх | ^

5. "Предотвращение DoS атак в FreeBSD"

Сообщение от jbond (??) on 04-Ноя-04, 10:13

Поэтому в статье fxp и рекомендуют :-)

Cообщить модератору | Наверх | ^

6. "Предотвращение DoS атак в FreeBSD"

Сообщение от okijan on 04-Ноя-04, 10:50

Проверял кто это дело на SMP??? The DEVICE_POLLING option by default does not work with SMP enabled kernels. When the author of the DEVICE_POLLING code initially commited it he admits he was unsure of the benefits of the feature in a multiple-CPU environment, as only one CPU would be doing the polling. Since that time many administrators have found that there is a significant advantage to DEVICE_POLLING even in SMP enabled kernels and that it works with no problems at all. If you are compiling an SMP kernel with DEVICE_POLLING, edit the file: /usr/src/sys/kern/kern_poll.c and remove the following lines:         #ifdef SMP         #include "opt_lint.h"         #ifndef COMPILING_LINT         #error DEVICE_POLLING is not compatible with SMP         #endif         #endif Чтука реальная, проверял на fxp и dc, жалко что xl не поддерживается :(

Cообщить модератору | Наверх | ^

7. "Предотвращение DoS атак в FreeBSD"

Сообщение от necrophagophobiac on 04-Ноя-04, 11:00

А не знаете почему всё застряло на считанных единицах карт? В мане говорится, что поддержка железом не требуется и достаточно в драйвере... Жду не дождусь xl и bge... :-(

Cообщить модератору | Наверх | ^

	8. "Предотвращение DoS атак в FreeBSD"
	Сообщение от pppp on 04-Ноя-04, 11:34
	Поддержка железом ещё и как требуется -- у карты должен быть аппаратный буфер, в котором она будет хранить пришедшие пакеты до тех пор пока *_poll() из драйвера их заберёт. Соответственно, поллинг возможен даже не в каждой fxp (только в серверных версиях, которые способны хранить до 64 пакетов). В bge ещё никто и не начинал ничего делать (документации не хватает?) Кстати, лично я не в восторге от этих карт.
	Cообщить модератору | Наверх | ^

	11. "Предотвращение DoS атак в FreeBSD"
	Сообщение от anononymous on 04-Ноя-04, 12:11
	всё, с первой до последней строчки - не правда и глупости. если вы сами не разбираетесь в вопросе, то будте так добры - не вводите других в заблуждение. пришедшие пакеты не хранятся в памяти карточки. они хранятся в оперативной памяти хоста. поллинг возможет в каждой fxp. оперативная память хоста может хранить 64 и больше принятых пакетов до того, как они будут переданы на уровень выше. но нужен ли всем версиям fxp поллинг ? (иногда может хватить простого link0) bge сама по себе не нуждается в поллинге. на гигабитных скоростях задержки до 1000 микросекунд на интерфейсах - не есть good. тем более, что bge сами прекрасно представляют, что такое interrupt moderation. предлагаю вам начать изучать мат-часть.
	Cообщить модератору | Наверх | ^

	13. "Предотвращение DoS атак в FreeBSD"
	Сообщение от toor99 (??) on 04-Ноя-04, 14:45
	Не пакетов, а кадров, уважаемый. Изучите терминологию. Не хватало еще для полного счастья, чтобы сетевые карты начали сами IP/IPX пакеты обрабатывать. В оперативной памяти хоста хранятся *пакеты*. А *кадры* (фреймы) хранятся в буфере сетевой карты, если он есть.
	Cообщить модератору | Наверх | ^

	21. "Предотвращение DoS атак в FreeBSD"
	Сообщение от anononymous on 05-Ноя-04, 03:18
	> Не пакетов, а кадров, уважаемый. да вы просто прикопались. > Изучите терминологию. Не хватало еще для полного счастья, чтобы сетевые карты > начали сами IP/IPX пакеты обрабатывать. такие слова, как TSO, TOE, вам что-нибудь говорят ? (я молчу про самостоятельное выставление и валидирование ip4/ip6/tcp/udp чек-сумм) > В оперативной памяти хоста хранятся *пакеты*. > А *кадры* (фреймы) хранятся в буфере сетевой карты, если он есть. буфер сетевой карты, как правило, не очень большой. всего на пару-тройку пакетов в том же fxp...
	Cообщить модератору | Наверх | ^

	27. "Предотвращение DoS атак в FreeBSD"
	Сообщение от toor99 (ok) on 05-Ноя-04, 20:00
	Чего-чего? Сссылочку мне сюда. С описанием сетевого адаптер, который сам считает чексуммы L3.
	Cообщить модератору | Наверх | ^

	28. "Предотвращение DoS атак в FreeBSD"
	Сообщение от toor99 (ok) on 05-Ноя-04, 20:08
	Да, по поводу TCP segmentation offload - то же самое. К *сетевому адаптеру* это имеет удаленное отношение. Всего лишь прослойка между адаптером и стеком. И не пакетов, а фреймов, еще раз вам повторяю.
	Cообщить модератору | Наверх | ^

	29. "Предотвращение DoS атак в FreeBSD"
	Сообщение от anononymous on 06-Ноя-04, 06:28
	> Чего-чего? > Сссылочку мне сюда. в следующий раз пойдёте в google сами. > С описанием сетевого адаптер, который сам считает чексуммы L3. The industry's first fully offloaded TCP/IP Offload NIC: http://www.adaptec.com/worldwide/product/prodtechindex.html?sess=no&language=English+US&cat=%2fTechnology%2fNAC TSO и checksumming offload: http://www.3com.ru/products/server_nics/3c996b-t/properties/ (специально для pppp - глянь, в твоём нелюбимом bge(4) целых 96Kb буферной памяти !) > Да, по поводу TCP segmentation offload - то же самое. > К *сетевому адаптеру* это имеет удаленное отношение. :) > Всего лишь прослойка между адаптером и стеком. И не пакетов, а > фреймов, еще раз вам повторяю. продолжайте изучать терминологию
	Cообщить модератору | Наверх | ^

	14. "Предотвращение DoS атак в FreeBSD"
	Сообщение от pppp on 04-Ноя-04, 15:34
	С каждым годом всё хуже и хуже... Медитируем над функцией fxp_poll() в /sys/dev/fxp/if_fxp.c Далее выясняем чем занимается макрос CSR_READ_1 (ответ: вызывает bus_space_read_1() из /sys/i386/include/bus_at386.h, а в ней всё довольно очевидно) ЗЫЖ Пора новый тред по поллингу открывать... ЗЗЫЖ С терминологией я действительно зарапортовался; конечно, имелись в виду фреймы
	Cообщить модератору | Наверх | ^

	15. "Предотвращение DoS атак в FreeBSD"
	Сообщение от Barsuk (??) on 04-Ноя-04, 16:42
	Так любая сетевая от Intel поддерживает поллинг? и еще по поводу xl, карточки 3кома поллинг не пддерживают или дрова xl для FreeBSD эту функцию не поддерживают? как с этим у Linux например? PILA 8460BI INTEL EtherExpress Pro 100+ PCI (chip 82559) будет держать Device polling ? и подойдет ли она для конфиуграции и вопроса: http://www.opennet.ru/openforum/vsluhforumID1/49717.html
	Cообщить модератору | Наверх | ^

	17. "Предотвращение DoS атак в FreeBSD"
	Сообщение от pppp on 04-Ноя-04, 20:21
	>Так любая сетевая от Intel поддерживает поллинг? Нет, не любая; а только та, у которой есть аппаратный буфер. Поддерживают те карты, которые позиционируются как серверные (список, возможно, не полный) 82546 -- 64 КБ (64 кадра) 82545 -- 64 КБ (64 кадра) 82540 -- 64 КБ (64 кадра) 82557 82558 82559 Эти точно поддерживают. По идее должны поддерживать все карты серии 8254x и 8255x, но у некоторых из них аппаратный буфер может быть значительно меньше -- ftp://download.intel.com/design/network/applnots/ap453.pdf >и еще по поводу xl, карточки 3кома поллинг не пддерживают или дрова >xl для FreeBSD эту функцию не поддерживают? как с этим у >Linux например? Во всяком случае 3Com Gigabit Server поддерживает (но это не xl, а bge); а 905-е, похоже нет. Я не очень хорошо ориентируюсь в Linux, но идеи device polling там присутствуют. Правда, почему-то разработчики смотрят только в сторону символьных драйверов (/me shrugs). Под Linux все люди используют не нативный драйвер, а поставляемый Intel в бинарниках (в основном из-за корректной поддержки 802.1q; а также из-за аналога уже упомянутой опции типа link0). В драйверах Intel (бинарных) есть аппаратная поддержка device polling (link0 в FreeBSD), которая работает максимум для 6 кадров, но не требует никакой поддержки от ОС. >PILA 8460BI INTEL EtherExpress Pro 100+ PCI (chip 82559) будет держать Device >polling ? и подойдет ли она для конфиуграции и вопроса: См выше. Подойдёт > http://www.opennet.ru/openforum/vsluhforumID1/49717.html Согласен с большинством :) Intel + device polling
	Cообщить модератору | Наверх | ^

	19. "Предотвращение DoS атак в FreeBSD"
	Сообщение от Barsuk (??) on 04-Ноя-04, 22:53
	Спасибо за такой подробный овтвет! Еще небольшое уточнение: 1. т.е. выходит просто карты серии 3Ком905 не имеют аппаратного буфера? т.е. и под линухом они хуже себя покажут? и FreeBSD здесь не виновата? 2. Будет ли роутер: пень1, озу порядка 32-64Мб, сетевые Intel + device polling, (2 сетки на 100Мбит) показывать работу на уровне аппаратного решения или нужна более серьезная конфигурация? пентиму2 или п3... Т.е. хватит ли такой конфигурации или при больших нагрузках будут провалы по скорости?
	Cообщить модератору | Наверх | ^

	25. "Предотвращение DoS атак в FreeBSD"
	Сообщение от pppp on 05-Ноя-04, 14:27
	>Спасибо за такой подробный овтвет! Еще небольшое уточнение: >1. т.е. выходит просто карты серии 3Ком905 не имеют аппаратного буфера? т.е. >и под линухом они хуже себя покажут? и FreeBSD здесь не >виновата? Повторю ещё раз: мне кажется, что поллинг там не реализован; хотя всякое может быть. В любом случае мне не удалось обнаружить драйвера для 905 с его поддержкой. >2. Будет ли роутер: пень1, озу порядка 32-64Мб, сетевые Intel + device >polling, (2 сетки на 100Мбит) показывать работу на уровне аппаратного решения >или нужна более серьезная конфигурация? пентиму2 или п3... >Т.е. хватит ли такой конфигурации или при больших нагрузках будут провалы по >скорости? Когда-то работал P-MMX + 64MB RAM  с 3 сетевыми картами (кстати, 905-ми 3com ;)) без поллинга. На нём же и v35 сидел (128Кбит/с в Интернет). Здесь многое зависит от задач/настроек, а особенно от структуры трафика. С аппаратным решением никакой pc на больших нагрузках не сравнится. Здесь дело не в вычислительной мощности (в данном случае можно говорить о кошке 26 серии, у которой центральный процессор вполне даже сопоставим с Pentium I), а в архитектуре -- у pc всё в результате упирается в загруженную под завязку шину, которая используется абсолютно для всего.
	Cообщить модератору | Наверх | ^

	26. "Предотвращение DoS атак в FreeBSD"
	Сообщение от Barsuk (??) on 05-Ноя-04, 19:34
	Циска для домашней сети, с практически нулевым бюджетом, что находишь из того и собираешь роутер :) , не подходит. Поэтому и ищутся способы добитсья насколько возможной скорости и стабильности на простых конфигурациях.  Первая покупка уже наметилась: NTEL EtherExpress Pro 100+ (chip 82559). "Чего только не придумают русские, что бы не покупать циску". Щас попробую девайс поллинг поднять и проверить на картах rl... по манам там поддержка есть :)
	Cообщить модератору | Наверх | ^

9. "Предотвращение DoS атак в FreeBSD"

Сообщение от Аноним on 04-Ноя-04, 12:00

Вообще в статье так и написано: "Наконец, если у вас есть одна из следующих сетевых карточек, то вы можете включить в ядро опцию DEVICE_POLLING" это, видать, автор новости случайно приравнял "опцию" к "основным" советам ;)

Cообщить модератору | Наверх | ^

10. "Предотвращение DoS атак в FreeBSD"

Сообщение от Аноним on 04-Ноя-04, 12:05

Из man polling SUPPORTED DEVICES      Device polling requires explicit modifications to the device drivers.  As      of this writing, the dc(4), em(4), fwe(4), fxp(4), ixgb(4), nge(4),      re(4), rl(4), sis(4), ste(4), vge(4), and vr(4) devices are supported,      with others in the works.

Cообщить модератору | Наверх | ^

12. "Предотвращение DoS атак в FreeBSD"

Сообщение от Аноним on 04-Ноя-04, 12:15

xl нет :( а будет ли?

Cообщить модератору | Наверх | ^

16. "Предотвращение DoS атак в FreeBSD"

Сообщение от Дмитрий Ю. Карпов on 04-Ноя-04, 20:10

Интересно, а может ли сетевая карточка через DMA скидывать кадры в оперативку, имея тем самым буферы, ограниченные только размером оперативки? Или DMA только для IDE?

Cообщить модератору | Наверх | ^

	18. "Предотвращение DoS атак в FreeBSD"
	Сообщение от pppp on 04-Ноя-04, 20:45
	>Интересно, а может ли сетевая карточка через DMA скидывать кадры в оперативку, >имея тем самым буферы, ограниченные только размером оперативки? Или DMA только >для IDE? Может, а некоторые так и делают. 1) У DMA существуют свои ограничения на максимальный размер используемой памяти; 2) Кроме того, что скинуть, надо ещё и следить за тем, кто и когда их будет забирать... Поэтому те кто могут -- скидывают, но как копию своих аппаратных буферов. А зачем -- чтобы разгрузить локальную шину. 3) Вообще-то DMA изначально разрабатывался для звуковых карт и флоповодов...
	Cообщить модератору | Наверх | ^

	20. "Предотвращение DoS атак в FreeBSD"
	Сообщение от Алексей (??) on 04-Ноя-04, 22:54
	1)Ограничение ISA DMA - 64К за пересылку - достаточный размер даже для гигабита, в PCI bus master.... нуууу сколько памяти хватит, и сколько тебе позволят шину держать. 2) Для тех девайсов которые умеют DMA/Bus mastering и дрова соответствующие. При скидывании используется механизм похожий на страничную работу памяти. Одна страница передается, вторая заполняется данными. После заполнения, странцы меняются местами. 3) Говорить что DMA разрабатывалось для флопов, а тем более музыкальных карт  это мягко скажем бред...  тут стоит подучить архитектуру 8080 и хронологию появлению устройств.
	Cообщить модератору | Наверх | ^

	24. "Предотвращение DoS атак в FreeBSD"
	Сообщение от pppp on 05-Ноя-04, 14:19
	>2) Для тех девайсов которые умеют DMA/Bus mastering и дрова соответствующие. >При скидывании используется механизм похожий на страничную работу памяти. Одна страница передается, >вторая заполняется данными. После заполнения, странцы меняются местами. Загвоздка в том, что сетевую карту никто не просит складывать данные в память; она это делает сама, причём в абсолютно непредсказуемые моменты времени... >3) Говорить что DMA разрабатывалось для флопов, а тем более музыкальных карт > это мягко скажем бред...  тут стоит подучить архитектуру 8080 >и хронологию появлению устройств. Я тогда ещё и в школу не ходил; и разве что S390 видел. Поэтому и не рассуждаю о том, чего никогда не видел (я о вычислительных устройствах на базе i8080)
	Cообщить модератору | Наверх | ^

23. "Предотвращение DoS атак в FreeBSD"

Сообщение от Аноним on 05-Ноя-04, 09:02

глюк?! выставил параметры как указано в статье, т.е. поставил net.inet.tcp.msl=7500 kern.ipc.somaxconn=32768 после этого перестали работать unix sockets, и, соответственно, приложения их использующие..., а также перестал работать kavdaemon :( после того как откатил на свои прежние настройки net.inet.tcp.msl=30000 kern.ipc.somaxconn=1024 все заработало...

Cообщить модератору | Наверх | ^

	30. "Предотвращение DoS атак в FreeBSD"
	Сообщение от Center on 14-Дек-04, 03:18
	>глюк?! > >выставил параметры как указано в статье, т.е. поставил >net.inet.tcp.msl=7500 >kern.ipc.somaxconn=32768 > >после этого перестали работать >unix sockets, и, соответственно, приложения их использующие..., а также перестал работать kavdaemon >:( после того как откатил на свои прежние настройки >net.inet.tcp.msl=30000 >kern.ipc.somaxconn=1024 > >все заработало... Были аналогиные симптомы на 5.3 после сборки ядра с предустановленным kern.ipc.somaxconn=32768. Ничего откатывать не стал, а используемые drwebd и drweb-sendmail вылечил пересборкой и установкой последних версий из портов (4.32.2 и 4.32.1 соотв.)
	Cообщить модератору | Наверх | ^

	31. "Предотвращение DoS атак в FreeBSD"
	Сообщение от dyer on 24-Мрт-05, 19:43
	вот это: kern.ipc.somaxconn=32768 - диверсия для FreeBSD 4.x максимум 32767
	Cообщить модератору | Наверх | ^

Удалить

Индекс форумов | Темы | Пред. тема | След. тема