Ваша Система Мониторинга Кричит При Изменении Маршрутизации?

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

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

Об ошибке под катом, а пока, если вы знаете, как работает маршрутизация, внимательно проанализируйте и ответьте на вопрос на рисунке.



Ваша система мониторинга кричит при изменении маршрутизации?

Правильный ответ на вопрос - через роутер 3.3.3.3, просто потому что приставка через этот роутер длиннее.

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

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

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



Как была обнаружена ошибка.

Все началось с того, что мне нужно было настроить IDS фыркать .

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

Поэтому зеркалирование портов было настроено на коммутаторе, в который входил провайдер.

Внутренний интерфейс snort-сервера находился в локальной сети, а внешний интерфейс перехватывал зеркальный трафик от demark. Естественно, в таких случаях при настройке всегда запускается tcpdump или что-то подобное.

Когда я начал анализировать полученное с помощью tcpdump, обнаружилась интересная вещь — роутер провайдера периодически присылал мне сообщения EIGRP Многоадресные пакеты HELLO.

Насколько вы можете ошибаться?

Сначала мне было интересно, как такое могло произойти.

Раньше я не работал с EIGRP, но быстро усвоил, что когда EIGRP настроен по умолчанию, все интерфейсы переходят в активный режим и маршрутизаторы сразу начинают искать соседей по маршрутизации, используя для этого multicast. Вы можете глобально перевести все интерфейсы в пассивный режим и сделать активными только определенные.

Можно оставить все интерфейсы активными, а те, которые не нужны (те, что смотрят на клиентов), перевести в пассивный режим.

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

Стало понятно, как такое могло произойти.

Допустим, вы настраиваете, в этот момент вас отвлекает минут на 5 телефонный звонок, вы возвращаетесь на работу и понимаете, что уже все настроили и все работает. Вы сохранили конфигурацию, но забыли, что не перевели интерфейс в пассивный режим.



Варианты эксплуатации ошибки.

Оказалось, что я могу настроить EIGRP под себя и подключиться к маршрутизации провайдера.

Естественно, мне было интересно, как это можно использовать.

Чем больше я об этом думал, тем интереснее становилось.

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

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

Все люди совершают ошибки.

Их бесплатно тестируют на проникновение, и у нас есть классный полигон.

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

Если они увидят, что я делаю, пусть прикроют меня.

На самом деле мне было интересно, будет ли обнаружено мое вмешательство в маршрутизацию или нет. Не найдено.

Но давайте разберемся, что можно сделать в этом случае.



Украсть трафик.

Это банально.

Установив EIGRP, я сразу взял в руки их таблицу маршрутизации.

Имея его в наличии, легко узнать, какая подсеть свободна, зарегистрировать ее на своем роутере и получить канал, не ограниченный ни по трафику, ни по скорости.

Я использовал это немного.



Захватите любую из используемых клиентских подсетей.

Вы можете зарегистрировать любую из подсетей, присутствующих в таблице маршрутизации на вашем роутере.

Если разбить эту подсеть на несколько, с более длинным префиксом, то трафик пойдет к вам, а не к клиенту провайдера.

Здесь может быть много вариантов использования.

Например, вы сможете эффективно скрыть следы своей незаконной деятельности.

В качестве доказательства концепции я фактически записал IP-адреса клиентов коммутируемого доступа.

Вам их не жаль; если что-нибудь случится, они смогут переподключиться и получить другой IP. Другой пример — временно захватить IP-адреса DNS-серверов провайдера и заменить DNS-сервер провайдера на свой для клиентов-клиентов.

В этом случае вы даже можете (о, ужас!!!) украсть пароли у одноклассников.

Конечно, сделать это незамеченным сложно, но мы сейчас не об этом.

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

Чтобы проверить, я расширил ГНС3 .

Вот сеть.



Ваша система мониторинга кричит при изменении маршрутизации?

Но что происходит, когда на R1 прописан маршрут с более длинным префиксом к подсети, прописанным на его интерфейсе — 192.168.0.0/24, и в случае, когда его там нет.

Ваша система мониторинга кричит при изменении маршрутизации?

Клиент просто не видит свой шлюз по умолчанию на третьем уровне.

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

Знаете ли вы, что «истинные админы» провайдера любят сидеть в белой подсети, за надежным фаерволом, который они сами и настроили? При этом доступ для управления сетевыми устройствами возможен только из этой подсети.

Конечно, не всегда, но делают это часто.

Для проведения атаки необходимо узнать, в какой подсети они находятся.

Для этого вы можете отправить администратору сети провайдера ссылку на классную картинку на вашем сервере.

А когда в ответ придет несколько смайлов, посмотрите IP-адрес в логах сервера.

Вы можете использовать другие подобные методы; социальную инженерию еще никто не отменял.

Далее разделите эту подсеть на несколько подсетей и зарегистрируйте их на своем роутере.

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

То есть его MAC виден, но он не пингуется и недоступен по портам управления (telnet, ssh, www).

Можно, возможно, подключиться через консоль.

Трудно даже догадаться, что на тебя нападают; это больше похоже на аппаратный сбой или сбой операционной системы маршрутизатора.

Жестоко, но красиво, правда?

Заключение.

Мониторинг изменений в маршрутизации не зря считается лучшей практикой.

Конечно, не стоит подавать громкое оповещение при изменении маршрутов в сети, но ИМХО, стоит настроить оповещение о том, что в сети появился новый роутер, участвующий в динамической маршрутизации.

P.S. Береги свою маршрутную руку, Сеня.

Теги: #маршрутизация #Системное администрирование #сети

Вместе с данным постом часто просматривают: