Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти
 
Страницы: 1 2 След.
RSS
Отказ в обслуживании в Cisco при обработке ICMP сообщений
 
Обсуждение статьи Отказ в обслуживании в Cisco при обработке ICMP сообщений
 
неужели кто-то использует MTU Discovery? [IMG]http://www.securitylab.ru/forum/smileys/smiley3.gif[/IMG]
 
Цитата
GetFind пишет:
неужели кто-то использует MTU Discovery?

По умолчанию, все версии Windows и Linux (про остальных не знаю)
 
а я бы выразился сильнее. тот кто не использует
PMTU discovery и препятствует другим его
использовать (путем фильтрации ICMP param.problem) -
полный [censored].
 
да не. я говорю о кошках.
 
Цитата
Онанимус пишет:
а я бы выразился сильнее. тот кто не использует
PMTU discovery и препятствует другим его
использовать (путем фильтрации ICMP param.problem) -
полный [censored].
и правильно! так и надо делать!
 
Цитата
GetFind пишет:
и правильно! так и надо делать!

Обосновать можешь?
 
Цитата
Guest пишет:
Обосновать можешь?
я конечно понимаю что при блокировании mtu disc. ошибки фрагментации больших пакетов не дойдут до их источника, и он никогда об ошибках не узнает и будет дальше тупо отправлять все новые и новые пакеты, окторые на самом деле будут просто "прибиты" (например на моем маршруте).
НО!
это может делаться специально и использоваться для атаки.
и так как требуется отдельный адрес для каждого маршрутизатора, как быть с локальными пространствами (10.0.0.0,192.168.0.0,172.16...)? ведь и будут отправляться пакеты icmp используя такие адреса, что сильно нагрузит сетевое окружение. и не в каждой системе может быть изменена фильтрация этого типа данных.

в 90-х годах начали активно вводить mtu-d, и сейчас почти все используют его...
все поотключали фрагментирование и теперь только и ждут повышения производительности. это конечно вопрос спорный, но уж больше проблем с этим mtu... и теперь все чаще ДоС на его основе...

единственно с чем я согласен - так это с правильной настройкой мту для определенного канала.
 
> и правильно! так и надо делать!

только в самых примитивых средах.

например, если ты не выходишь за пределы своей
поганой локалки на 10 компов, и не пользуешься
чужими каналами с левым оборудованием на уровне 2.
 
Цитата
Онанимус пишет:

только в самых примитивых средах.

например, если ты не выходишь за пределы своей
поганой локалки на 10 компов, и не пользуешься
чужими каналами с левым оборудованием на уровне 2.
ну тогда извини! просто пользуются моими линиями, а не я чьими-то! (пиринг и фрейминг оговаривается отдельно)
а насчет примитивных сред должен тебя огорчить, сеть слишком большая чтобы подстраиваться под внешних пользователей.
 
я разрешаю только time-exceeded, unreachable, echo-reply, echo
все остальное режу.
 
например это счетчики за месяц работы access-lista - других пакетов не приходит.. хотя у меня 4 сетки класса C

    90 deny icmp any any fragments (715 matches)
    510 permit icmp any X.X.X.0 0.0.1.255 time-exceeded (189350 matches)
    520 permit icmp any X.X.X.0 0.0.1.255 unreachable (1466288 matches)
    530 permit icmp any X.X.X.0 0.0.1.255 echo-reply (104486 matches)
    540 permit icmp any X.X.X.0 0.0.1.255 echo (258 matches)
    550 permit icmp any X.X.X.0 0.0.1.255 time-exceeded (199106 matches)
    560 permit icmp any X.X.X.0 0.0.1.255 unreachable (2589544 matches)
    570 permit icmp any X.X.X.0 0.0.1.255 echo-reply (2449798 matches)
    580 permit icmp any X.X.X.0 0.0.1.255 echo (1705256 matches)
    600 deny icmp any any (18 matches)
 
Вообще-то можно резать не все ICMP-пакеты, а только выборочно (если уж так руки чешутся). Во-вторых запрет ICMP ни как не мешает проводить атаки по другим протоколам с использованием локальных пространств.
Если не понятно как работает PMTUD то чтаем тут.

Фильтрация ICMP - есть полнейший бред с точки зрения безопасности и это есть нарушение стандартов, что есть криворукость со всеми вытекающими... Сейчас, когда начинает стремительно расти популярность PPPoE можно получить массу проблем со связью с такими серверами.
 
уважаемый юнихоид,

во-первых, никто здесь не считает что главная защита системы - это запрет icmp (что может понять человек все же прочитавший этот топик). и естественно что никто не забыл о других протоколах.
если вкратце рассказать что здесь обсуждается - так это работа других протоколов (в частности tcp/ip) при поддержке icmp.

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

в третих, кроме Point-to-Point Protocol over Ethernet есть еще столько разных проектов... и способов обьединения оборудования в сети. я не против pppoe, я просто говорю что никто не будет на него равняться.
 
> Point-to-Point Protocol over Ethernet есть еще столько
> разных проектов... и способов обьединения оборудования
> в сети

я именно об этом и писал !

> никто не будет на него равняться

говори за себя.

лично мне один раз проезжали по мозгам насчет
PMTU discovery и его связи с ICMP лет 5 назад,
и я двум "провайдерам" вправлял мозги года 2 назад -
вполне успешно.

гг. GetFind и ksiva, когда с вами будут
совершать подобную операцию по вправке мозгов -
не говорите что вас не предупреждали :-)
 
> не говорите что вас не предупреждали :-)
не боись! не забудем, и укажем на тебя [IMG]http://www.securitylab.ru/forum/smileys/smiley36.gif[/IMG]
а вот пакетики от твоей сети я и не собираюсь вообще принимать [IMG]http://www.securitylab.ru/forum/smileys/smiley1.gif[/IMG]
 
Ну вот и тр.....я тогда сам с собой! (q) анекдот [IMG]http://www.securitylab.ru/forum/smileys/smiley36.gif[/IMG]
 
Цитата
GetFind пишет:
но уж больше проблем с этим mtu... и теперь все чаще ДоС на его основе...

единственно с чем я согласен - так это с правильной настройкой мту для определенного канала.

Следуя твоей логике, надо всю автоматику повыключать. Только руками! На кой хрен нам сдались протоколы динамической маршрутизации? Даешь все роуты статикой!
 
Цитата
Гость пишет:
Следуя твоей логике, надо всю автоматику повыключать. Только руками! На кой хрен нам сдались протоколы динамической маршрутизации? Даешь все роуты статикой!
тюты блин... приехали :) как горохом об стену
 
Уязвимости не в реализациях а в проектировании протокола. Поэтому и RFC выходит. Обрезая функции мы нарушаем RFC и это может сказаться на работе.
Помниться техподдержка одного производителя кприптошлюза на букву К, в ответ на сообщение, что их шлюз работает как blackhole на pmtud (или вообще на фрагментацию) говорил - это в FreeBSD и Windows стек TCP кривой :-)) Ну-ну.
Если у тебя за спиной только своя сеть - проблем особых нет. MTU можно и занизить например на граничном шлюзе или клиентах (но лучше на граничном). А вот если ты транзитник....

2 GetFind
А как с IPv6 будем поступать?
Страницы: 1 2 След.
Читают тему (гостей: 1)