Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Занятно, но людям, знакомым с основами маршрутизации, скучновато.
Возможно. Признаться, я достаточно долго думал, писать об этом или не стоит тратить время, свое и читателей. Но факт остается фактом, провайдер вмешательства в их маршрутизацию не заметил. Это перевесило аргументы против.
Да не, в качестве развлекательного чтива история ОК, по крайней мере я поставил +
Не совсем ясно как у провайдера настроена безопасность. Нормальный провайдер дает инет в VLAN и правильно настроенных аццесах Вы не смогли бы получить IP из другой зоны. А то, что Вы добрались даже до IP диалапщиков мистика… За такой косяк инженерам провайдера надо руки оторвать.
Я его не получал а отбирал. А VLAN тут ни при чем, атака на третьем уровне.
Возможно Вы не прочитали, что я написал. Я владелец провайдера и при правильных аццесах Вы бы ничего не отобрали никакой атакой. Статья про безалаберность инженеров, а то, что они зачастую ленятся вешать аццесы на аплинках я знаю на собственном опыте.
Возможно, я и не понял. Объясните, что по вашему есть правильные аццессы? Вы закрываете multicast на портах коммутатора? Ставите на портах коммутатора access-list-ы?
Мультикаст ходит в выделенном для него влане допустим 666 где также наложены фильтры. По умолчанию все на клиентском порту выключено. Мы ведь говорим, что провайдер дал возможность клиенту менять топологию сети вы могли положить провайдеру все. Имел такой же опыт с STP когда его включили по случайности на клиентских портах. И наши же клиенты указали на ошибку. И в качестве наказания показали, что может произойти. Тоже самое как BGP если бы каждому провайдеру дали анонсировать IP которые им не принадлежат. Получился бы бардак, так что тут вопрос на мой взгляд в первую очередь настройки порта. Хотя Ваш опыт весьма интересный, спасибо за статью она дает повод задуматься.
Спасибо интересно было почитать!
Кстати в такой ситуации, заужение маски приведет к тому, что на часть хостов в верхнем диапазоне изначальной подсети сервера будут доступны…
Кстати в такой ситуации, заужение маски приведет к тому, что на часть хостов в верхнем диапазоне изначальной подсети сервера будут доступны…
Интересно только с помощью какой магии на маршрутизаторах провайдера появятся маршруты, которые вы прописали у себя? Хотя, если провайдер держит динамику с клиентскими рутерами, да еще и дает пользователям их конфигурить и не фильтрует то, что от них получает… ну каждый сам себе буратино в таком случае.
P.S. порадовал пассаж про отправку прикольной картинки и получение смайликов
P.S. порадовал пассаж про отправку прикольной картинки и получение смайликов
То есть провайдер гонял динамический протокол маршрутизации между собой и клиентским рутером? У нормальных провайдеров такое запрещено.
Это тоже нормальный провайдер, у него это тоже запрещено. Но бывают ошибки, от них никто не застрахован. Об этом написано.
Это из разряда не смены дефолных паролей, коммьюнити и так далее. Ребята оставили настройки по умолчанию, вы этим воспользовались. В принципе можно таким способом попортить жизнь, но находится это в течении полминуты. Банальной проверкой маршрута на тот адрес, который сбоит, а потом проверкой таблицы с вопросом «а какого хрена оно идет не туда, куда надо?».
Вы лучше с анонсами BGP поиграйтесь, там не только своего провайдера, там полмира положить можно через некоторых доверчивых аплинков. Проверьте, может ваш провайдер IGP в BGP экспортирует? :)
Вы лучше с анонсами BGP поиграйтесь, там не только своего провайдера, там полмира положить можно через некоторых доверчивых аплинков. Проверьте, может ваш провайдер IGP в BGP экспортирует? :)
получить не лимитированный по трафику или скорости канал
Не совсем понял каким образом вы этого достигли. Скорость и лимит немного по другим принципам выдаются.
Выдаются — да. Наверное Вы имеете в виду PPPoE.
Просто PPPoE не было. Было прямое подключение, и ограничение по скорости с использованием rate-limit. В этом случае, пакеты на меня и от меня матчатся на access-list, к которому привязывается группа rate-limit. Когда я выходил с IP которые себе нагло присвоил, этот траффик не матчился на access-list, и поэтому никак не ограничивался, кроме как физической скоростью на интерфейсе.
Если бы было ограничение по трафику, то его бы учитывал netflow. В таком случае, биллинг считает, что мой траффик — траффик на и с моих IP, а так как IP не мои, то и траффик не мой.
Просто PPPoE не было. Было прямое подключение, и ограничение по скорости с использованием rate-limit. В этом случае, пакеты на меня и от меня матчатся на access-list, к которому привязывается группа rate-limit. Когда я выходил с IP которые себе нагло присвоил, этот траффик не матчился на access-list, и поэтому никак не ограничивался, кроме как физической скоростью на интерфейсе.
Если бы было ограничение по трафику, то его бы учитывал netflow. В таком случае, биллинг считает, что мой траффик — траффик на и с моих IP, а так как IP не мои, то и траффик не мой.
Не увидел, зачем динамическая маршрутизация на таком количестве сетей.
Настроенная аутентификация на EIGRP спасла бы гиганта мысли
А есть в природе готовые средства для мониторинга изменений в динамических протоколах маршрутизации? Навскидку на ум приходят только BGPMon — но он, как и следует из названия, только для BGP, отмониторить изменения в IGP-протоколах с его помощью не выйдет. Нужели остается только ставить кваггу и крутить к ней костыли?
Есть протокол syslog, и если syslog сервер правильный то можно корректно обработать сообщения и дать оповещение.
«Тоже самое как BGP если бы каждому провайдеру дали анонсировать IP которые им не принадлежат» — Вы не поверите, еще вчера Белтелеком в национальном пиринге такое позволял :(
как всегда, занимательно :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
А ваша система мониторинга орёт, когда меняется маршрутизация?