Добрый день, проводил ли кто-нибудь тестирование snort на предмет производительности? Какая нужна конфигурация, для мониторинга ~200-300 мегабит траффика и порядка 200 rules? Предполагается Solaris/Sparc. Может есть какие-то ссылки на такие тесты? -- Pavel Narozhniy, IT manager, Miratech Ltd. 41 Nauki Ave, 03028 Kiev, Ukraine, tel:+38 044 265 5850 fax: +380 44 265 5860, http://www.miratech.ua mailto:PNarozhniy@miratech.ua =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, Jul 18, 2003 at 03:40:30PM +0300, Pavel Narozhniy wrote:
проводил ли кто-нибудь тестирование snort на предмет производительности? Какая нужна конфигурация, для мониторинга ~200-300 мегабит траффика
скорее всего никакая - он даже wire speed (100mbit) не потянет на самой быстрой машине; расчитывается через скорость PCI шины (66MHz*32bit) и частоту процессора (ну пусть 2Ghz) это конечно в случае пиковой нагрузки - если пакеты маленькие (скажем, 100 байт - тогда 100mbit = 120K packets/s) и допустим мы анализируем только его половину - нам нужно пропустить через процессор 6.25M байт, получается 160 тактов на байт, или 640 на слово (dword). для 200 rules явно не хватает. и порядка 200 rules? Предполагается Solaris/Sparc. Может есть какие-то ссылки на такие тесты? ой, не заметил solaris/sparc... опыта snort на нем нет, но предполагаю, что на streams-based стеке производительность будет еще хуже и даже быстрая шина и SMP не поможет. а вообще - надо ставить эксперимент... ;) я помню выступление автора snort и CTO компании, которая сейчас продает rackmountable snort в коробке - у них еле-еле был wire speed для 100mbit год назад. вот нашел название конторы - sourcefire. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sat, Jul 19, 2003 at 01:44:19AM -0700, Dmitry Kohmanyuk Дмитрий Кохманюк wrote:
On Fri, Jul 18, 2003 at 03:40:30PM +0300, Pavel Narozhniy wrote:
проводил ли кто-нибудь тестирование snort на предмет производительности? Какая нужна конфигурация, для мониторинга ~200-300 мегабит траффика
скорее всего никакая - он даже wire speed (100mbit) не потянет на самой быстрой машине; расчитывается через скорость PCI шины (66MHz*32bit) и частоту процессора (ну пусть 2Ghz)
это конечно в случае пиковой нагрузки - если пакеты маленькие (скажем, 100 байт - тогда 100mbit = 120K packets/s) и допустим мы анализируем только его половину - нам нужно пропустить через процессор 6.25M байт, получается 160 тактов на байт, или 640 на слово (dword).
хмм. тогда без zero-copy 2Ghz даже пакеты бы форвардить не очень успевал, что не факт ;-) тактов получается 320/байт (если на каждый); на самом деле байты тут не причем, нужно действительно считать на пакет, потому как поглядев на source/dest/port ты часто больше ничего не хочешь; на пакет имеем 16k+ тактов.
для 200 rules явно не хватает.
при правильной приоритизации правил (их, как cisco ACLи, можно по количеству хитов сортировать) должно хватать на заметно больше, чем 100Mbps/200 rules. проблемы обычно со следующим уровнем - покладанием eventов в базу и их обработкой/приоритизацией/корреляцией; не справляются event correlatorы ;-) а если бы действовать a-la smarts.com и ложить все-все-все события в базу для составления матрицы - то сразу опаньки ;-) правила на сенсоре - те самые фильтрующие эвристики.
и порядка 200 rules? Предполагается Solaris/Sparc. Может есть какие-то ссылки на такие тесты?
я года полтора гонял Snort на Netra T1 (кажется 440Mhz) на внутреннем T3 в classmates.com; проблем с performance не было; канал изредка был полностью загружен - правда большими пакетами, db replication.
ой, не заметил solaris/sparc... опыта snort на нем нет, но предполагаю, что на streams-based стеке производительность будет еще хуже и даже быстрая шина и SMP не поможет.
ну тогда нужно купить toplayer ids load balancer ;-) и поставить стойку сенсоров.
я помню выступление автора snort и CTO компании, которая сейчас продает rackmountable snort в коробке - у них еле-еле был wire speed для 100mbit год назад.
вот нашел название конторы - sourcefire.
они нам недавно рекламировали GigE сенсор... www.sourcefire.com --igor =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sat, Jul 19, 2003 at 01:44:19AM -0700, Dmitry Kohmanyuk Дмитрий Кохманюк wrote:
On Fri, Jul 18, 2003 at 03:40:30PM +0300, Pavel Narozhniy wrote:
проводил ли кто-нибудь тестирование snort на предмет производительности? Какая нужна конфигурация, для мониторинга ~200-300 мегабит траффика
скорее всего никакая - он даже wire speed (100mbit) не потянет на самой быстрой машине; расчитывается через скорость PCI шины (66MHz*32bit) и частоту процессора (ну пусть 2Ghz)
Не знаю, как там мониторинг - но вот когда я на P4-1.7GHz/1GB DDR,FreeBSD-4.7, ~3000 tcp sessions внутри lo0 (загоняется в кучу ssh -C и распаковывается на ~4 тазиках с 10-100 MBit connection) пущаю trafshow -n -p -i lo0 - то оно начинает тормозить, и вообще я ни разу не видел даже 6K p/s. То есть - если ipfw counters взять - то где-то 11-12Kp/s и 1MByte/s, но "интерактивно поглядеть" - никак не получается. включен fastforwarding, в ipfw аж несколько правил count, пара pipes, в которые ничего не попадает, и allow from any to any. Вобщем - "device bpf для такого не предназначен" - общий вывод после тугугленья. "пишите свой netgraph node". Короче - для подобной задачи нужен какой-то хитрожопый делитель трафика, ну и далее уже распаралелить анализ.
это конечно в случае пиковой нагрузки - если пакеты маленькие (скажем, 100 байт - тогда 100mbit = 120K packets/s) Это - и что из PC такое хоть просто из одного в другой интерфейс перебросит, пропустив через десяток-сотню правил в ipfw? Именно применительно к большой куче пакетов.
я помню выступление автора snort и CTO компании, которая сейчас продает rackmountable snort в коробке - у них еле-еле был wire speed для 100mbit год назад. И что ж в той коробке было?
"Чудовi супер-сумо - товстозадi добряки" - ну и мультики в телевизоре ;). Какие-то подвинутые на заднице ;))). -- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Mon, Jul 21, 2003 at 04:10:56PM +0300, unisol@cs.kiev.ua wrote:
On Sat, Jul 19, 2003 at 01:44:19AM -0700, Dmitry Kohmanyuk Дмитрий Кохманюк wrote:
On Fri, Jul 18, 2003 at 03:40:30PM +0300, Pavel Narozhniy wrote:
проводил ли кто-нибудь тестирование snort на предмет производительности? Какая нужна конфигурация, для мониторинга ~200-300 мегабит траффика
скорее всего никакая - он даже wire speed (100mbit) не потянет на самой быстрой машине; расчитывается через скорость PCI шины (66MHz*32bit) и частоту процессора (ну пусть 2Ghz)
Не знаю, как там мониторинг - но вот когда я на P4-1.7GHz/1GB DDR,FreeBSD-4.7, ~3000 tcp sessions внутри lo0 (загоняется в кучу ssh -C и распаковывается на ~4 тазиках с 10-100 MBit connection) пущаю trafshow -n -p -i lo0 - то оно начинает тормозить, и вообще я ни разу не видел даже 6K p/s.
вообще то попробуй вместо lo0 использовать алиасы на ether-е - проблемы с performance на lo я припоминаю; кроме того, trafshow - не дюже оптимальная тулза.
То есть - если ipfw counters взять - то где-то 11-12Kp/s и 1MByte/s, но "интерактивно поглядеть" - никак не получается. включен fastforwarding, в ipfw аж несколько правил count, пара pipes, в которые ничего не попадает, и allow from any to any. Вобщем - "device bpf для такого не предназначен" - общий вывод после тугугленья. "пишите свой netgraph node".
вывод верный ;-) для Snort нам пакеты форвардить не приходится, только слушаем; я помню там была еще засада если есть список разных блоков в HOME_NET - дешевле было отдельные процессы пускать на каждый ;-)
Короче - для подобной задачи нужен какой-то хитрожопый делитель трафика, ну и далее уже распаралелить анализ.
http://www.toplayer.com/content/products/intrusion_detection/ids_balancer.js... у Radware есть похожий продукт; около 5K$
это конечно в случае пиковой нагрузки - если пакеты маленькие (скажем, 100 байт - тогда 100mbit = 120K packets/s) Это - и что из PC такое хоть просто из одного в другой интерфейс перебросит, пропустив через десяток-сотню правил в ipfw? Именно применительно к большой куче пакетов.
fortunately обычный mix более тяготеет к 1500 bytes/packet; да и перебрасывать не нужно.
я помню выступление автора snort и CTO компании, которая сейчас продает rackmountable snort в коробке - у них еле-еле был wire speed для 100mbit год назад. И что ж в той коробке было?
как обычно - linux, pc, приличный ether ;-) --igor =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Mon, Jul 21, 2003 at 12:12:06PM -0700, Igor Sviridov wrote:
Не знаю, как там мониторинг - но вот когда я на P4-1.7GHz/1GB DDR,FreeBSD-4.7, ~3000 tcp sessions внутри lo0 (загоняется в кучу ssh -C и распаковывается на ~4 тазиках с 10-100 MBit connection) пущаю trafshow -n -p -i lo0 - то оно начинает тормозить, и вообще я ни разу не видел даже 6K p/s.
вообще то попробуй вместо lo0 использовать алиасы на ether-е - Тоже идея... Повесить на fxp0 127.0.0.1 в качестве алиаса - вроде ж не страшно... проблемы с performance на lo я припоминаю; кроме того, trafshow - не дюже оптимальная тулза. Так а чем так чтоб "красиво и в realtime" ? вроде как особо ничего... Хотя скрипт из ipfw show/sleep/bc - вполне удовлетворит любопытство...
это конечно в случае пиковой нагрузки - если пакеты маленькие (скажем, 100 байт - тогда 100mbit = 120K packets/s) Это - и что из PC такое хоть просто из одного в другой интерфейс перебросит, пропустив через десяток-сотню правил в ipfw? Именно применительно к большой куче пакетов.
fortunately обычный mix более тяготеет к 1500 bytes/packet; да и перебрасывать не нужно. Ну, тогда заменить в задаче 100mbit на 1gbit:) - количество пакетов вырастет.
я помню выступление автора snort и CTO компании, которая сейчас продает rackmountable snort в коробке - у них еле-еле был wire speed для 100mbit год назад. И что ж в той коробке было?
как обычно - linux, pc, приличный ether ;-) И почему на всяких хостингах в какой-нить P4-2GHz всё норовят втыкнуть realtek8139 по 5$/ведро...
-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (5)
-
Dmitry Kohmanyuk Дмитрий Кохманюк -
Igor Sviridov -
Paul Arakelyan -
Pavel Narozhniy -
unisol＠cs.kiev.ua