Pull to refresh

Comments 31

Занятно, но людям, знакомым с основами маршрутизации, скучновато.
Возможно. Признаться, я достаточно долго думал, писать об этом или не стоит тратить время, свое и читателей. Но факт остается фактом, провайдер вмешательства в их маршрутизацию не заметил. Это перевесило аргументы против.
Да не, в качестве развлекательного чтива история ОК, по крайней мере я поставил +
Не совсем ясно как у провайдера настроена безопасность. Нормальный провайдер дает инет в VLAN и правильно настроенных аццесах Вы не смогли бы получить IP из другой зоны. А то, что Вы добрались даже до IP диалапщиков мистика… За такой косяк инженерам провайдера надо руки оторвать.
Я его не получал а отбирал. А VLAN тут ни при чем, атака на третьем уровне.
Возможно Вы не прочитали, что я написал. Я владелец провайдера и при правильных аццесах Вы бы ничего не отобрали никакой атакой. Статья про безалаберность инженеров, а то, что они зачастую ленятся вешать аццесы на аплинках я знаю на собственном опыте.
Возможно, я и не понял. Объясните, что по вашему есть правильные аццессы? Вы закрываете multicast на портах коммутатора? Ставите на портах коммутатора access-list-ы?
Мультикаст ходит в выделенном для него влане допустим 666 где также наложены фильтры. По умолчанию все на клиентском порту выключено. Мы ведь говорим, что провайдер дал возможность клиенту менять топологию сети вы могли положить провайдеру все. Имел такой же опыт с STP когда его включили по случайности на клиентских портах. И наши же клиенты указали на ошибку. И в качестве наказания показали, что может произойти. Тоже самое как BGP если бы каждому провайдеру дали анонсировать IP которые им не принадлежат. Получился бы бардак, так что тут вопрос на мой взгляд в первую очередь настройки порта. Хотя Ваш опыт весьма интересный, спасибо за статью она дает повод задуматься.
Тогда утром, на свежую голову, смоделируйте ситуацию по моему сценарию, просто для проверки на сколько хорошо защищены. Дизайнов сети может быть куча, не факт, что все учтено.
Дело в том, что перешли мы на Juniper :-) А EIGRP фирменный протокол Cisco, не получится у меня смоделировать чтобы ломануть себя по вашему сценарию. В последнее время вообще смотрю в сторону Extreme, весьма интересное железо.
Спасибо интересно было почитать!

Кстати в такой ситуации, заужение маски приведет к тому, что на часть хостов в верхнем диапазоне изначальной подсети сервера будут доступны…
А что мешает несколько подсетей прописать? Допустим есть одна большая 100.100.100.0/24. Можно всю захватить, прописав у себя 100.100.100.0/25 и 100.100.100.128/25.
Подскажите, а что будет происходить с клиентом, у которого был прописан IP 100.100.100.127 при такой схеме?
Тоже отвалится гейт или что-то другое будет происходить?
Ответы ему не будут приходить.
Интересно только с помощью какой магии на маршрутизаторах провайдера появятся маршруты, которые вы прописали у себя? Хотя, если провайдер держит динамику с клиентскими рутерами, да еще и дает пользователям их конфигурить и не фильтрует то, что от них получает… ну каждый сам себе буратино в таком случае.

P.S. порадовал пассаж про отправку прикольной картинки и получение смайликов
Читайте внимательно, не было никакой магии, была ошибка, которая позволила вклиниться в их маршрутизацию.
То есть провайдер гонял динамический протокол маршрутизации между собой и клиентским рутером? У нормальных провайдеров такое запрещено.
Это тоже нормальный провайдер, у него это тоже запрещено. Но бывают ошибки, от них никто не застрахован. Об этом написано.
Это из разряда не смены дефолных паролей, коммьюнити и так далее. Ребята оставили настройки по умолчанию, вы этим воспользовались. В принципе можно таким способом попортить жизнь, но находится это в течении полминуты. Банальной проверкой маршрута на тот адрес, который сбоит, а потом проверкой таблицы с вопросом «а какого хрена оно идет не туда, куда надо?».

Вы лучше с анонсами BGP поиграйтесь, там не только своего провайдера, там полмира положить можно через некоторых доверчивых аплинков. Проверьте, может ваш провайдер IGP в BGP экспортирует? :)
получить не лимитированный по трафику или скорости канал

Не совсем понял каким образом вы этого достигли. Скорость и лимит немного по другим принципам выдаются.
Выдаются — да. Наверное Вы имеете в виду PPPoE.
Просто PPPoE не было. Было прямое подключение, и ограничение по скорости с использованием rate-limit. В этом случае, пакеты на меня и от меня матчатся на access-list, к которому привязывается группа rate-limit. Когда я выходил с IP которые себе нагло присвоил, этот траффик не матчился на access-list, и поэтому никак не ограничивался, кроме как физической скоростью на интерфейсе.
Если бы было ограничение по трафику, то его бы учитывал netflow. В таком случае, биллинг считает, что мой траффик — траффик на и с моих IP, а так как IP не мои, то и траффик не мой.
Я удивлен. Первый раз вижу схему, где тарифы реализованы рэйт-лимитами на аксесс-листы. По-моему это не очень удобное решение.
Знаете, я у провайдера работал с 1999 по 2004, и уже ничему не удивляюсь :)
Не увидел, зачем динамическая маршрутизация на таком количестве сетей.
Не понял. Это Вы о чем? Разве где-то было сказано сколько подсетей было у провайдера?
Настроенная аутентификация на EIGRP спасла бы гиганта мысли
А есть в природе готовые средства для мониторинга изменений в динамических протоколах маршрутизации? Навскидку на ум приходят только BGPMon — но он, как и следует из названия, только для BGP, отмониторить изменения в IGP-протоколах с его помощью не выйдет. Нужели остается только ставить кваггу и крутить к ней костыли?
Есть протокол syslog, и если syslog сервер правильный то можно корректно обработать сообщения и дать оповещение.
Есть протокол syslog, и если syslog сервер правильный то можно корректно обработать сообщения и дать оповещение.
«Тоже самое как BGP если бы каждому провайдеру дали анонсировать IP которые им не принадлежат» — Вы не поверите, еще вчера Белтелеком в национальном пиринге такое позволял :(
Sign up to leave a comment.

Articles