#298. Каскадное размножение пакетов в сетях.

[Nag]

#298. Каскадное размножение пакетов в сетях.

[GateKeeper]

Одно интересует: как люди, вроде логикой довольно доходчиво всё могущие объяснить, совершенно плавают в терминологии. При первом упоминании неких "ASK"-пакетов подумалось, что опечатка. Ан нет, терминологии не знаем... В целом, конечно же - огромное спасибо.

[msavio]

ну, и кто какие сделал выводы? можна как то с этим бороться или как?

[GateKeeper]

Можно.

root@gw3-net5-bone3#arp -da

[umike]

если даже на маршрутизаторе нет статической записи в arp-таблице, маршрутизатор будет посылать arp-запросы на поиск физического адреса этого хоста, которые точно также будут распространяться по сегменту, создавая ethernet-трафик. Пусть он в несколько раз меньший, но характер его такой-же. На фоне NETBIOS-broadcast трафика или трафика завирусованных машин, генерирующих ACK, а лучше UDP-пакеты тысячами/десятками/сотнями тысяч в секунду - это капля в море.

 

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

[sol]

если даже на маршрутизаторе нет статической записи в arp-таблице, маршрутизатор будет посылать arp-запросы на поиск физического адреса этого хоста

Так-то оно так, но маршрутизатор (как правило) имеет некоторое ограничение на поток ARP запросов. Поарпал броадкастиком раз другой и умолк.

На фоне NETBIOS-broadcast трафика или трафика завирусованных машин, генерирующих ACK, а лучше UDP-пакеты тысячами/десятками/сотнями тысяч в секунду

Вот тут-то и зарыта собака. При статических таблицах ARP весь этот бред не превратится в 2-3 ARP запроса в сегменте назначения и целиком будет вылит в него. Всем потоком. Больше того, это не будет проблемой отдельного хоста, ведь он выключен. А это будет проблемой всего сегмента. Прикольно в сети на свитчах запустить tcpdump и вместо привычных широковещательных ARP запросов увидеть там трафик хостов. Которые даже не из этого сегмента. Крышку сдвигает по первой.

 

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

Не совсем так. Типовой пример сегмента: Гиг из центра/бекбона, районный коммутатор на этом гиге и соточные линки к домам. С редкими включениями в виде xDSL модемов и клиентов на 10мбит. Вот первым делом вымрут xDSL. Следом - клиенты на десятке. А в жестких случаях - помрут и сотни на дома. Наблюдал такое один раз глазами. А 10-ки мрут регулярно. Даже можно вид атаки придумать. Выясняем, что некий хост в целевом сегменте - мертв и начинаем флудить в этот сегмент сколько сможем. И все, хана сегменту. Edited February 12, 2007 by sol

[umike]

любой флуд это нештатный режим. Точно также можно устроить arp-шторм в сегмент и тупые коммутаторы сбрендят. Не вижу глобального отличия приводимого Вами флуда от любого другого при котором "хана сегменту". Например встречались случаи атак на MSSQL, и UDP/icmp-флуд "в мир" (не так давно все это на себе ощутили - соответствующий топик был), под которыми прекрасно прогибались и всеми любимые 2950, выливая то, что они успели просвитчить на магистраль, откуда оно лилось к аплинкам, доставляя им много-много радости.

 

Просто так трафик возникнуть не может - если он возник, значит он порожден чем-то. В tcp предусмотрена процедура установления соединения и заложена посылка регламентированного кол-ва ACK-пакетов, после которого становится ясно, что с той стороны никто не отвечает, на чем попытка инициирование соединения и трафик благополучно заканчивается. Если-же по какой-то причине трафик не заканчивается и возникает флуд из сегмента в сегмент - первопричина его не в статик-arp записях, а в "консерватории", генерирующей флуд.

 

Предположим сегмент по xDSL. Сколько - 2,4,8 Мбит? Чтобы в данный сегмент был отроучен и выплюнут трафик из ACK-запросов, способный его задушить я вижу только две причины: 1) вирусный/намеренный флуд из другого сегмента, с target ip в этом сегменте. Это явно нештатный режим работы, который при умении можно сравнительно быстро отмониторить и отсечь. Была бы там сотка - при интенсивном флуде придушило бы и её. 2) По этому узкому xDSL подключен сегмент в котором пользователей не менее несколько сотен - соотв-но на маршрутизаторе столько-же статик-записей и всё летящее в направлении сегмента благополучно выплевывается маршрутизатором в сегмент. Согласен, можно уменьшить этот бесполезный трафик в сегмент удалив статик записи, но при этом у меня возникает другой вопрос - помоему в этом случае можно вообще не говорить о качестве работы данного сегмента, поскольку xDSL на такое кол-во пользователей это хуже чем dialup.

 

В общем информация о зле статик-записей как одной из причин распространения флуда к сведению принята, практической ценности не вижу и надеюсь не увижу :))).

[Прохожий]

Просто так трафик возникнуть не может - если он возник, значит он порожден чем-то.

Зачооот!

Если-же по какой-то причине трафик не заканчивается и возникает флуд из сегмента в сегмент - первопричина его не в статик-arp записях, а в "консерватории", генерирующей флуд.

Эт точно. А как бороться?

[user_anonymous]

А вот ситуация, когда статик записи не только на роутере, но и на коммутаторах - мне кажется, что в данном случае ситуация будет совершенно иной. Автор говорит, что когда запрос приходит на коммутатор, который не знает, куда его послать, то коммутатор рассылает его по всем портам. И это правильно. А что если коммутатор знает, что на порту таком-то находится МАК такой-то (статическая запись привязки). Какова будет ситуация в этом случае, если клиент выключен? Пакет будет тихо убит или отправлен на выключенный порт?

[umike]

функционал привязки на коммутаторе даёт только то, что фреймы имеющие src/dst MAC находящиеся в access-list порта проходят, остальное рубится. "Каскад" коммутаторов между этим коммутатором и роутером ничего не знает об этом процессе и о мак-адресе. Если только на всех коммутаторах сегмента ручками пропишете таблицу коммутации :))))

[user_anonymous]

функционал привязки на коммутаторе даёт только то, что фреймы имеющие src/dst MAC находящиеся в access-list порта проходят, остальное рубится. "Каскад" коммутаторов между этим коммутатором и роутером ничего не знает об этом процессе и о мак-адресе. Если только на всех коммутаторах сегмента ручками пропишете таблицу коммутации :))))

А точно ли это реализуется в виде access-листов? И если да - добавляет ли подобное правило статическую запись в таблицу коммутации?

 

Давайте рассмотрим гипотетическое развитие событий:

 

Роутер -- промежуточный коммутатор --- конечный коммутатор --- отключенный хост

 

На роутере статические записи МАК-ИП

первоначально промежуточный коммутатор не знает про МАК хоста

Конечный коммутатор знает про то, что МАК такой-то есть на таком-то порту. Этот порт не активен, так как хост выключен.

 

Первый пакет

1. Пришел на роутер и был передан в сегмент

2. Приеш на промежуточный коммутатор и был разослан по сегменту броадкастом.

3. Промежуточный коммутатор получил от конечного коммутатора инфу, что МАК надо слать на него. Запомнил ее.

4. Конечный коммутатор получил пакет и так как порт, на который он указывает, отключен, убил его.

 

Второй пакет

1. Пришел на роутер и был передан в сегмент

2. Приеш на промежуточный коммутатор и был передан на конечный коммутатор.

3. Конечный коммутатор получил пакет и так как порт, на который он указывает, отключен, убил его.

 

Меня вообще в этой схеме несколько смущает пункт 3 для первого пакета, так как я не уверен, что конечный коммутатор самостоятельно будет что-либо отправлять промежуточному.

 

Я правильно понимаю ситуацию или где-то не прав? Если правильно - то выходит, что статические МАКи на конечных коммутаторах существенно снизят нагрузку от броадкастов.

Edited February 14, 2007 by user_anonymous

[Прохожий]

Конечный коммутатор знает про то, что МАК такой-то есть на таком-то порту.

C точки зрения коммутации-не знает. Запись в таблице фильтров и запись в таблице МАС - не одно и то же. Портдаун автоматически приводит к очистке таблицы МАС для этого порта, а эта таблица обычно формируется чипсетом совершенно независимо от управляющего процессора, хотя можно сделать и так, что каждое обновление МАС будет идти через обращение к управляющему процу. Теоретически, ты можешь вносить статические записи в МАС таблицу, но на практике, АФАИК, совершенно бессмысленное мероприятие.

 

Вообще-то АФАИК, коммутаторы вообще не отвечают на ARP запросы, за исключением стека IP управляющего процесса, которая отвечает "про себя"

Edited February 14, 2007 by Прохожий

[user_anonymous]

Нда :( Я думал, что все устроено немного иначе.

Ну значит моя гипотеза оказалась не верной. Спасибо за избавление меня от заблуждения.

[umike]

3. Промежуточный коммутатор получил от конечного коммутатора инфу, что МАК надо слать на него. Запомнил ее.

 

неверно. Коммутаторы не распространяют таблицы коммутации по сети (а как и зачем?). Таблица коммутации каждого коммутатора строится посредством изучения заголовков входящих в порты фреймов. Ну и статик-записи можно.

[user_anonymous]

И вам спасибо. Век живи, век учись :)

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

[sol]

Теоретически, ты можешь вносить статические записи в МАС таблицу, но на практике, АФАИК, совершенно бессмысленное мероприятие.

Это верно, если на порту включено "обучение" (learning). На некоторых коммутаторах его можно отключить и тогда внесение записей руками приобретает хоть какой-то смысл. А вообще, в реальной сети с виланами и массой сложно соединенных меж собой коммутаторов - внесение записей руками напоминает восход солнца в ручную.

[KD]

Каскадное размножение пакетов.

......

3. Маршрутизатор маршрутизирует этот пакет и, поскольку запись в таблице ARP протокола для Хоста 2 имеется (она занесена туда статически и не устаревает) посылает данный пакет в сегмент #2 с MAC адресом получателя AA:BB:CC:DD:EE:FF.

......

5. Маршрутизатор маршрутизирует этот пакет и, поскольку запись в таблице ARP протокола для Хоста 1 имеется (она занесена туда статически и не устаревает) посылает данный пакет в сегмент #1 с MAC адресом получателя 11:22:33:44:55:66.

Если у маршрутизатора статическая запись ARP для хоста А то с какого перепугу он будет пересылать пакет SYN пришедший с другим маком? Edited February 15, 2007 by KD

[sol]

Если у маршрутизатора статическая запись ARP для хоста А то с какого перепугу он будет пересылать пакет SYN пришедший с другим маком?

Добро пожаловать в реальный мир. (с) Дело в том, что в 99% платформ, являющихся (програмные роутеры) или выдающих себя за маршрутизаторы (L3 свитчи), ARP таблица используется только при ПЕРЕДАЧЕ пакета.

[Mechanic]

вообщем получается ситуация, что нужны свичи с порт секюрити для борьбы со сменой адресов и только такой способ реально будет работать

[GateKeeper]

вообщем получается ситуация, что нужны свичи с порт секюрити для борьбы со сменой адресов и только такой способ реально будет работать

И при этом прописанная в договоре обязательность предоставления пользователем информации о замене сетевого оборудования (сетевой карты, маршрутизаторов-мыльниц и т.д...), плюс полная отмена arp-привязки на маршрутизаторах.

[KD]

Если у маршрутизатора статическая запись ARP для хоста А то с какого перепугу он будет пересылать пакет SYN пришедший с другим маком?

Добро пожаловать в реальный мир. (с) Дело в том, что в 99% платформ, являющихся (програмные роутеры) или выдающих себя за маршрутизаторы (L3 свитчи), ARP таблица используется только при ПЕРЕДАЧЕ пакета.

как-то раньше даже не задавался таким вопросом...

тогда все совсем плохо получается

[user_anonymous]

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

Эффекта привязки можно добиться если вместо статической записи в ARP-таблице использовать фильтрацию по МАК-адресу в файерволе. В конце-концов какая разница, что убъет пакет с неверным маком?

[umike]

Дело в том, что в 99% платформ, являющихся (програмные роутеры) или выдающих себя за маршрутизаторы (L3 свитчи), ARP таблица используется только при ПЕРЕДАЧЕ пакета.

а это извините зачем использовать ARP-таблицу при приеме? Кроме как для построения её самой, и если ручками сделать то фильтрации по MAC.

[altazar]

Хотел бы возобновить тему поскольку на практике столкнулся с слудующей проблемой:

 

Сначала напомню в чём смысл: Если посылать на адрес в сети который прописан статично в АРП таблице, а хост в тот момент не работает, то пакеты валятся на все порты(идут бродкастом)

* этого не происходит если арп таблица не статична и рефрешится.(поправьте если нада)

 

Так вот, ситуация наклёвывается следующая.. В связи с тем что Битторент сети всё больше и больше распространяются, а работают они на UDP пакетах(не контролируют факт доставки), то получается, что если клиенту идёт трафик в 2-5мбита и клиент вырубает компьютер, то этот трафик распространяется по всем портам. Поскольку Битторент сети завязаны на Тракерах(сайтах) и таблицу рабочих IP они обнавлют весьма редко, то получается этот флуд может идти довольно продолжительно. Это абсолютно реальный пример. Господа администраторы, если вы используете статичную привязку и у вас на локалке весит до 200 человек, то подключите часов в 21:00 ноутбук к сети и включите снифер. Вы, наверняка, увидете порядка 200-700 увесестых левых пакетов.

 

Наверное я бы и не переживал за эти временные явления если бы не Wirless AP и Wireless routers, так как они реагируют на весь этот трафик в отличии от стационарного компьютера(видимо из-за promiscouse mode). И можете не удевляться если на AP ваша пердоставляемая скорость падает в несколко раз.

 

Варианты решения?:

 

- не держать АРП таблицу : как же тогда авторизировать клиента? PPPoE? не геморойно ли?

- реализовывать прикрытие фаирволом: как тогда на нагрузочке отразится ? есть практика у кого либо ?

- фантастика: переписать систему хранения таблиц. Статичные маки не являются статичными, а просто сверяют возможность добавления в АРП таблицу. Уменьшается время рефреша АРПов, когда АРП вылетает из таблицы и рутор отсылать пакеты не будет.

- выяснить какие роутеры не реагируют на левый трафик и смотрят пакеты только со своим мак адресом. есть идеи?

 

Жду ваших коментариев.

Спасибо.

Edited March 21, 2007 by altazar

[vIv]

- не держать АРП таблицу : как же тогда авторизировать клиента? PPPoE? не геморойно ли?

 

http://nag.ru/2006/0920/0920.shtml

http://nag.ru/2006/1001/1001.shtml

 

// а вообще - "авторизация по ARP" звучит и внушаеть! :-D