Как бороться со спуфом в сети?

[gorec2005]

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

время от времени происходит следующее (лог tcpdump):

 

17:36:49.050064 00:00:1e:04:3e:91 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.16.16 tell 172.16.16.124

17:36:49.050072 00:00:1e:04:3e:91 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.16.16 tell 172.16.16.124

17:36:49.050623 00:00:1e:04:3e:91 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.16.16 tell 172.16.16.124

17:36:49.050631 00:00:1e:04:3e:91 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.16.16 tell 172.16.16.124

 

всю сеть это не умерщвляет, но жить мешает неслабо - как это избежать?

1. сделать на каждый неуправляемый сегмент по vlan дотащить их до центра и тут отмаршрутизировать?

вопрос - при глюках железа/замыканиях кабеля/арпспуфах неупр.свитчей это наверно не спасет?

2. сделать физически несколько независимых сегментов, тогда чем их объединять?

3. переводить все на оптику - слишком дорого :-(

4. есть еще какие-нибудь красивые решения о которых я не знаю...

 

 

Помогите пожалуйста - не дайте погибнуть под гнетом спуфа...

Edited July 4, 2008 by gorec2005

[ginodman]

обычные арп пакеты теперь спуфом зовут?! будем знать

[Jovanotti]

Улыбнуло ). Я так и не понял чем эти бродкасты мешают жит ь ? :-)

 

[kww]

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

время от времени происходит следующее (лог tcpdump):

 

17:36:49.050064 00:00:1e:04:3e:91 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.16.16 tell 172.16.16.124

17:36:49.050072 00:00:1e:04:3e:91 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.16.16 tell 172.16.16.124

17:36:49.050623 00:00:1e:04:3e:91 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.16.16 tell 172.16.16.124

17:36:49.050631 00:00:1e:04:3e:91 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.16.16 tell 172.16.16.124

Судя по временным меткам машинка 172.16.16.16 действительно флудит.

Поставьте в развязки оборудование способное - broadcast shtorm control . Любой управляемый L2 сейчас это умеет.

Из минусов - будет отпадать сегмент в котором флуд, из плюсов - ложиться не вся сеть.

От замыкания кабеля спасет - loop detection - минусы те-же, хлопает целый сегмент.

Edited July 5, 2008 by kww

[gorec2005]

обычные арп пакеты теперь спуфом зовут?! будем знать

Если мне не изменяет память - время выкидывания из таблицы свитча по дефолту 300 сек или 30 сек, а тут за 6 десятитысячных секунды несколько одинаковых запросов... - вариантов не много - или запрашивающая сторона не получает ответа (что не верно - потому как пинги ходят) или запрашивающая стороно запрашивает несколько раз подряд (это абсурд) - или пакет дублируется где-то по дороге такой результат легко получить соеденив между собою порты неуправляемого свитча вот это, если я конечно правильно понимаю, называется спуф...

[gorec2005]

Улыбнуло ). Я так и не понял чем эти бродкасты мешают жит ь ? :-)

Если бы можно было обойтись совсем без броадкастов - было бы здорово!, но насколько я понимаю чтобы обойтись совсем без броадкастов - надо везде делать статик арп- а это не удобно :-(

А по делу - броадкасты, насколько я успел заметить на мешают пока их кол-во меньше 20% полезного трафика, но растут они как снежный ком при любой проблемме железа в сети.

А кто-нибудь в деталях знает как это место сделано в "МЕТРО ethernet" ?

 

[gorec2005]

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

время от времени происходит следующее (лог tcpdump):

 

17:36:49.050064 00:00:1e:04:3e:91 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.16.16 tell 172.16.16.124

17:36:49.050072 00:00:1e:04:3e:91 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.16.16 tell 172.16.16.124

17:36:49.050623 00:00:1e:04:3e:91 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.16.16 tell 172.16.16.124

17:36:49.050631 00:00:1e:04:3e:91 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.16.16 tell 172.16.16.124

Судя по временным меткам машинка 172.16.16.16 действительно флудит.

Поставьте в развязки оборудование способное - broadcast shtorm control . Любой управляемый L2 сейчас это умеет.

Из минусов - будет отпадать сегмент в котором флуд, из плюсов - ложиться не вся сеть.

От замыкания кабеля спасет - loop detection - минусы те-же, хлопает целый сегмент.

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

Поставьте в развязки оборудование способное - broadcast shtorm control . Любой управляемый L2 сейчас это умеет.

тут возникает несколько вопросов

- если в цепочке несколько L2 свитчей с включенным "broadcast shtorm control" при проблемме отключится первый или сразу несколько?

- как вычислить уровень для включения "broadcast shtorm control"?

- включится ли порт назад после исправления ситуации, или порт надо будет включать в ручную?

От замыкания кабеля спасет - loop detection - минусы те-же, хлопает целый сегмент.

я не нашел такой фичи в свитчах которые у меня используются (planet wgsd-1022 и wgsw2840)

каким образом это работает?

 

[Jovanotti]

Для начала немешало бы определится насколько много "паразитного" трафика.

Для этого можно использовать любой из сетевых анализаторов (ntop, OmniPeek ... )

 

Да, и если можно поправь название темы ). Спуф - это другая тема.

Edited July 6, 2008 by Jovanotti