Nag Опубликовано 10 февраля, 2007 · Жалоба #298. Каскадное размножение пакетов в сетях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GateKeeper Опубликовано 11 февраля, 2007 · Жалоба Одно интересует: как люди, вроде логикой довольно доходчиво всё могущие объяснить, совершенно плавают в терминологии. При первом упоминании неких "ASK"-пакетов подумалось, что опечатка. Ан нет, терминологии не знаем... В целом, конечно же - огромное спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
msavio Опубликовано 11 февраля, 2007 · Жалоба ну, и кто какие сделал выводы? можна как то с этим бороться или как? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GateKeeper Опубликовано 12 февраля, 2007 · Жалоба Можно. root@gw3-net5-bone3#arp -da Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 12 февраля, 2007 · Жалоба если даже на маршрутизаторе нет статической записи в arp-таблице, маршрутизатор будет посылать arp-запросы на поиск физического адреса этого хоста, которые точно также будут распространяться по сегменту, создавая ethernet-трафик. Пусть он в несколько раз меньший, но характер его такой-же. На фоне NETBIOS-broadcast трафика или трафика завирусованных машин, генерирующих ACK, а лучше UDP-пакеты тысячами/десятками/сотнями тысяч в секунду - это капля в море. На мой взгляд над мыслью, изложенной в статье, стоит задумываться только в случае очень больших сегментов, построенных на малопроизводительных Ethernet-коммутаторах. А также в радиосегментах вида точка-многоточка с большим кол-вом клиентов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 12 февраля, 2007 (изменено) · Жалоба если даже на маршрутизаторе нет статической записи в arp-таблице, маршрутизатор будет посылать arp-запросы на поиск физического адреса этого хоста Так-то оно так, но маршрутизатор (как правило) имеет некоторое ограничение на поток ARP запросов. Поарпал броадкастиком раз другой и умолк. На фоне NETBIOS-broadcast трафика или трафика завирусованных машин, генерирующих ACK, а лучше UDP-пакеты тысячами/десятками/сотнями тысяч в секунду Вот тут-то и зарыта собака. При статических таблицах ARP весь этот бред не превратится в 2-3 ARP запроса в сегменте назначения и целиком будет вылит в него. Всем потоком. Больше того, это не будет проблемой отдельного хоста, ведь он выключен. А это будет проблемой всего сегмента. Прикольно в сети на свитчах запустить tcpdump и вместо привычных широковещательных ARP запросов увидеть там трафик хостов. Которые даже не из этого сегмента. Крышку сдвигает по первой. На мой взгляд над мыслью, изложенной в статье, стоит задумываться только в случае очень больших сегментов, построенных на малопроизводительных Ethernet-коммутаторах. Не совсем так. Типовой пример сегмента: Гиг из центра/бекбона, районный коммутатор на этом гиге и соточные линки к домам. С редкими включениями в виде xDSL модемов и клиентов на 10мбит. Вот первым делом вымрут xDSL. Следом - клиенты на десятке. А в жестких случаях - помрут и сотни на дома. Наблюдал такое один раз глазами. А 10-ки мрут регулярно. Даже можно вид атаки придумать. Выясняем, что некий хост в целевом сегменте - мертв и начинаем флудить в этот сегмент сколько сможем. И все, хана сегменту. Изменено 12 февраля, 2007 пользователем sol Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 12 февраля, 2007 · Жалоба любой флуд это нештатный режим. Точно также можно устроить arp-шторм в сегмент и тупые коммутаторы сбрендят. Не вижу глобального отличия приводимого Вами флуда от любого другого при котором "хана сегменту". Например встречались случаи атак на MSSQL, и UDP/icmp-флуд "в мир" (не так давно все это на себе ощутили - соответствующий топик был), под которыми прекрасно прогибались и всеми любимые 2950, выливая то, что они успели просвитчить на магистраль, откуда оно лилось к аплинкам, доставляя им много-много радости. Просто так трафик возникнуть не может - если он возник, значит он порожден чем-то. В tcp предусмотрена процедура установления соединения и заложена посылка регламентированного кол-ва ACK-пакетов, после которого становится ясно, что с той стороны никто не отвечает, на чем попытка инициирование соединения и трафик благополучно заканчивается. Если-же по какой-то причине трафик не заканчивается и возникает флуд из сегмента в сегмент - первопричина его не в статик-arp записях, а в "консерватории", генерирующей флуд. Предположим сегмент по xDSL. Сколько - 2,4,8 Мбит? Чтобы в данный сегмент был отроучен и выплюнут трафик из ACK-запросов, способный его задушить я вижу только две причины: 1) вирусный/намеренный флуд из другого сегмента, с target ip в этом сегменте. Это явно нештатный режим работы, который при умении можно сравнительно быстро отмониторить и отсечь. Была бы там сотка - при интенсивном флуде придушило бы и её. 2) По этому узкому xDSL подключен сегмент в котором пользователей не менее несколько сотен - соотв-но на маршрутизаторе столько-же статик-записей и всё летящее в направлении сегмента благополучно выплевывается маршрутизатором в сегмент. Согласен, можно уменьшить этот бесполезный трафик в сегмент удалив статик записи, но при этом у меня возникает другой вопрос - помоему в этом случае можно вообще не говорить о качестве работы данного сегмента, поскольку xDSL на такое кол-во пользователей это хуже чем dialup. В общем информация о зле статик-записей как одной из причин распространения флуда к сведению принята, практической ценности не вижу и надеюсь не увижу :))). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Прохожий Опубликовано 12 февраля, 2007 · Жалоба Просто так трафик возникнуть не может - если он возник, значит он порожден чем-то.Зачооот! Если-же по какой-то причине трафик не заканчивается и возникает флуд из сегмента в сегмент - первопричина его не в статик-arp записях, а в "консерватории", генерирующей флуд.Эт точно. А как бороться? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
user_anonymous Опубликовано 14 февраля, 2007 · Жалоба А вот ситуация, когда статик записи не только на роутере, но и на коммутаторах - мне кажется, что в данном случае ситуация будет совершенно иной. Автор говорит, что когда запрос приходит на коммутатор, который не знает, куда его послать, то коммутатор рассылает его по всем портам. И это правильно. А что если коммутатор знает, что на порту таком-то находится МАК такой-то (статическая запись привязки). Какова будет ситуация в этом случае, если клиент выключен? Пакет будет тихо убит или отправлен на выключенный порт? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 14 февраля, 2007 · Жалоба функционал привязки на коммутаторе даёт только то, что фреймы имеющие src/dst MAC находящиеся в access-list порта проходят, остальное рубится. "Каскад" коммутаторов между этим коммутатором и роутером ничего не знает об этом процессе и о мак-адресе. Если только на всех коммутаторах сегмента ручками пропишете таблицу коммутации :)))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
user_anonymous Опубликовано 14 февраля, 2007 (изменено) · Жалоба функционал привязки на коммутаторе даёт только то, что фреймы имеющие src/dst MAC находящиеся в access-list порта проходят, остальное рубится. "Каскад" коммутаторов между этим коммутатором и роутером ничего не знает об этом процессе и о мак-адресе. Если только на всех коммутаторах сегмента ручками пропишете таблицу коммутации :)))) А точно ли это реализуется в виде access-листов? И если да - добавляет ли подобное правило статическую запись в таблицу коммутации? Давайте рассмотрим гипотетическое развитие событий: Роутер -- промежуточный коммутатор --- конечный коммутатор --- отключенный хост На роутере статические записи МАК-ИП первоначально промежуточный коммутатор не знает про МАК хоста Конечный коммутатор знает про то, что МАК такой-то есть на таком-то порту. Этот порт не активен, так как хост выключен. Первый пакет 1. Пришел на роутер и был передан в сегмент 2. Приеш на промежуточный коммутатор и был разослан по сегменту броадкастом. 3. Промежуточный коммутатор получил от конечного коммутатора инфу, что МАК надо слать на него. Запомнил ее. 4. Конечный коммутатор получил пакет и так как порт, на который он указывает, отключен, убил его. Второй пакет 1. Пришел на роутер и был передан в сегмент 2. Приеш на промежуточный коммутатор и был передан на конечный коммутатор. 3. Конечный коммутатор получил пакет и так как порт, на который он указывает, отключен, убил его. Меня вообще в этой схеме несколько смущает пункт 3 для первого пакета, так как я не уверен, что конечный коммутатор самостоятельно будет что-либо отправлять промежуточному. Я правильно понимаю ситуацию или где-то не прав? Если правильно - то выходит, что статические МАКи на конечных коммутаторах существенно снизят нагрузку от броадкастов. Изменено 14 февраля, 2007 пользователем user_anonymous Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Прохожий Опубликовано 14 февраля, 2007 (изменено) · Жалоба Конечный коммутатор знает про то, что МАК такой-то есть на таком-то порту.C точки зрения коммутации-не знает. Запись в таблице фильтров и запись в таблице МАС - не одно и то же. Портдаун автоматически приводит к очистке таблицы МАС для этого порта, а эта таблица обычно формируется чипсетом совершенно независимо от управляющего процессора, хотя можно сделать и так, что каждое обновление МАС будет идти через обращение к управляющему процу. Теоретически, ты можешь вносить статические записи в МАС таблицу, но на практике, АФАИК, совершенно бессмысленное мероприятие. Вообще-то АФАИК, коммутаторы вообще не отвечают на ARP запросы, за исключением стека IP управляющего процесса, которая отвечает "про себя" Изменено 14 февраля, 2007 пользователем Прохожий Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
user_anonymous Опубликовано 14 февраля, 2007 · Жалоба Нда :( Я думал, что все устроено немного иначе. Ну значит моя гипотеза оказалась не верной. Спасибо за избавление меня от заблуждения. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 14 февраля, 2007 · Жалоба 3. Промежуточный коммутатор получил от конечного коммутатора инфу, что МАК надо слать на него. Запомнил ее. неверно. Коммутаторы не распространяют таблицы коммутации по сети (а как и зачем?). Таблица коммутации каждого коммутатора строится посредством изучения заголовков входящих в порты фреймов. Ну и статик-записи можно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
user_anonymous Опубликовано 14 февраля, 2007 · Жалоба И вам спасибо. Век живи, век учись :) А ведь я читал про механизм обучения, но, видать, не до конца разобрался - впрочем обычно в доках описывают случай, когда в коммутатор воткнут хост, а никак не другой коммутатор. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 14 февраля, 2007 · Жалоба Теоретически, ты можешь вносить статические записи в МАС таблицу, но на практике, АФАИК, совершенно бессмысленное мероприятие. Это верно, если на порту включено "обучение" (learning). На некоторых коммутаторах его можно отключить и тогда внесение записей руками приобретает хоть какой-то смысл. А вообще, в реальной сети с виланами и массой сложно соединенных меж собой коммутаторов - внесение записей руками напоминает восход солнца в ручную. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
KD Опубликовано 15 февраля, 2007 (изменено) · Жалоба Каскадное размножение пакетов....... 3. Маршрутизатор маршрутизирует этот пакет и, поскольку запись в таблице ARP протокола для Хоста 2 имеется (она занесена туда статически и не устаревает) посылает данный пакет в сегмент #2 с MAC адресом получателя AA:BB:CC:DD:EE:FF. ...... 5. Маршрутизатор маршрутизирует этот пакет и, поскольку запись в таблице ARP протокола для Хоста 1 имеется (она занесена туда статически и не устаревает) посылает данный пакет в сегмент #1 с MAC адресом получателя 11:22:33:44:55:66. Если у маршрутизатора статическая запись ARP для хоста А то с какого перепугу он будет пересылать пакет SYN пришедший с другим маком? Изменено 15 февраля, 2007 пользователем KD Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 15 февраля, 2007 · Жалоба Если у маршрутизатора статическая запись ARP для хоста А то с какого перепугу он будет пересылать пакет SYN пришедший с другим маком? Добро пожаловать в реальный мир. (с) Дело в том, что в 99% платформ, являющихся (програмные роутеры) или выдающих себя за маршрутизаторы (L3 свитчи), ARP таблица используется только при ПЕРЕДАЧЕ пакета. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 15 февраля, 2007 · Жалоба вообщем получается ситуация, что нужны свичи с порт секюрити для борьбы со сменой адресов и только такой способ реально будет работать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GateKeeper Опубликовано 16 февраля, 2007 · Жалоба вообщем получается ситуация, что нужны свичи с порт секюрити для борьбы со сменой адресов и только такой способ реально будет работать И при этом прописанная в договоре обязательность предоставления пользователем информации о замене сетевого оборудования (сетевой карты, маршрутизаторов-мыльниц и т.д...), плюс полная отмена arp-привязки на маршрутизаторах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
KD Опубликовано 16 февраля, 2007 · Жалоба Если у маршрутизатора статическая запись ARP для хоста А то с какого перепугу он будет пересылать пакет SYN пришедший с другим маком? Добро пожаловать в реальный мир. (с) Дело в том, что в 99% платформ, являющихся (програмные роутеры) или выдающих себя за маршрутизаторы (L3 свитчи), ARP таблица используется только при ПЕРЕДАЧЕ пакета. как-то раньше даже не задавался таким вопросом... тогда все совсем плохо получается Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
user_anonymous Опубликовано 16 февраля, 2007 · Жалоба после обдумывания проблемы я пришел к выводу, что делать статическую привязку маков нужно осторожно и, по возможности, в небольших сегментах. Эффекта привязки можно добиться если вместо статической записи в ARP-таблице использовать фильтрацию по МАК-адресу в файерволе. В конце-концов какая разница, что убъет пакет с неверным маком? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 16 февраля, 2007 · Жалоба Дело в том, что в 99% платформ, являющихся (програмные роутеры) или выдающих себя за маршрутизаторы (L3 свитчи), ARP таблица используется только при ПЕРЕДАЧЕ пакета. а это извините зачем использовать ARP-таблицу при приеме? Кроме как для построения её самой, и если ручками сделать то фильтрации по MAC. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
altazar Опубликовано 21 марта, 2007 (изменено) · Жалоба Хотел бы возобновить тему поскольку на практике столкнулся с слудующей проблемой: Сначала напомню в чём смысл: Если посылать на адрес в сети который прописан статично в АРП таблице, а хост в тот момент не работает, то пакеты валятся на все порты(идут бродкастом) * этого не происходит если арп таблица не статична и рефрешится.(поправьте если нада) Так вот, ситуация наклёвывается следующая.. В связи с тем что Битторент сети всё больше и больше распространяются, а работают они на UDP пакетах(не контролируют факт доставки), то получается, что если клиенту идёт трафик в 2-5мбита и клиент вырубает компьютер, то этот трафик распространяется по всем портам. Поскольку Битторент сети завязаны на Тракерах(сайтах) и таблицу рабочих IP они обнавлют весьма редко, то получается этот флуд может идти довольно продолжительно. Это абсолютно реальный пример. Господа администраторы, если вы используете статичную привязку и у вас на локалке весит до 200 человек, то подключите часов в 21:00 ноутбук к сети и включите снифер. Вы, наверняка, увидете порядка 200-700 увесестых левых пакетов. Наверное я бы и не переживал за эти временные явления если бы не Wirless AP и Wireless routers, так как они реагируют на весь этот трафик в отличии от стационарного компьютера(видимо из-за promiscouse mode). И можете не удевляться если на AP ваша пердоставляемая скорость падает в несколко раз. Варианты решения?: - не держать АРП таблицу : как же тогда авторизировать клиента? PPPoE? не геморойно ли? - реализовывать прикрытие фаирволом: как тогда на нагрузочке отразится ? есть практика у кого либо ? - фантастика: переписать систему хранения таблиц. Статичные маки не являются статичными, а просто сверяют возможность добавления в АРП таблицу. Уменьшается время рефреша АРПов, когда АРП вылетает из таблицы и рутор отсылать пакеты не будет. - выяснить какие роутеры не реагируют на левый трафик и смотрят пакеты только со своим мак адресом. есть идеи? Жду ваших коментариев. Спасибо. Изменено 21 марта, 2007 пользователем altazar Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vIv Опубликовано 21 марта, 2007 · Жалоба - не держать АРП таблицу : как же тогда авторизировать клиента? PPPoE? не геморойно ли? http://nag.ru/2006/0920/0920.shtml http://nag.ru/2006/1001/1001.shtml // а вообще - "авторизация по ARP" звучит и внушаеть! :-D Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...