Допустим вы интернет провайдер или у вас своя сеть с динамической маршрутизацией, тогда собственно сабж…
Резонный вопрос, а зачем? Причин вести логи изменения много, а орать система мониторинга должна по той простой причине, что никто не застрахован от ошибки. Об ошибке под катом, а пока, если вы знаете, как работает маршрутизация, внимательно проанализируйте и ответьте себе на вопрос на рисунке.
Правильный ответ на вопрос – через маршрутизатор 3.3.3.3, просто потому, что префикс через этот маршрутизатор длиннее. Когда принимается решение, какой из двух маршрутов победит, всегда, прежде всего, проверяется префикс. Если до хоста есть два маршрута с одинаковым префиксом, то тогда победит маршрут с более приоритетным протоколом маршрутизации, если и протоколы маршрутизации одинаковы, то тогда будут браться во внимание внутренние метрики протокола маршрутизации.
Но мы немного отвлеклись, на самом деле, я хотел рассказать давнюю историю, примерно 2006 года о том, как я случайно получил возможность вмешиваться в маршрутизацию своего провайдера, и что в подобном случае можно сделать.
Все началось с того, что мне надо было настроить IDS snort. Пакеты ловить надо было на demark-е с провайдером. Поэтому было настроено зеркалирование порта на свитче, в который включался провайдер. Внутренним интерфейсом сервер snort был в локальной сети, внешним – нюхал зеркальный трафик с demark-a. Естественно, в подобных случаях при настройке всегда запускается tcpdump или что-либо подобное. Когда я начал анализировать, что получил tcpdump-ом, обнаружилась интересная вещь – маршрутизатор провайдера периодически отсылал на меня EIGRP HELLO multicast пакеты.
Сначала меня заинтересовало, как такое могло произойти. Я не работал до этого с EIGRP, однако быстро выяснил, что при настройке EIGRP по умолчанию все интерфейсы переводятся в активный режим и маршрутизаторы сразу же начинают искать соседей по маршрутизации, используя для этого multicast. Можно глобально перевести все интерфейсы в пассивный режим и делать активными только определенные из них. Можно оставить все интерфейсы активными и переводить не нужные (те которые смотрят на клиентов) в пассивный режим. Провайдер использовал второй подход. Скорее всего, кто-то из сетевых администраторов провайдера ошибся и не перевел интерфейс, который смотрел на меня, в пассивный режим.
Стало понятно, как такое могло получиться. Допустим, вы конфигурируете, в этот момент вас отвлекает минут на 5 телефонный звонок, вы возвращаетесь к работе и понимаете, что все уже сконфигурировали и все работает. Сохраняете конфигурацию, но забыли, что не перевели интерфейс в пассивный режим.
Получалось, что я могу настроить у себя EIGRP, и включиться в маршрутизацию провайдера. Естественно, меня заинтересовало, как это можно использовать. Чем больше я над этим думал, тем интересней становилось.
Надо сказать, что у меня были отличные отношения с провайдером. Сотрудники провайдера донесли до нас, что они, в принципе, не против того, что мы попытаемся их взломать и жаловаться не будут. Главное ничего не сломать, и в случае если что-то обнаружим, сказать им. Все люди – все ошибаются. Их бесплатно тестируют на проникновение, а у нас прикольный полигон.
Поэтому я позвонил провайдеру, сказал, что кое-что обнаружил, что именно, скажу на следующий день, а пока поэкспериментирую. Если увидят, что я делаю, пускай прикроют. На самом деле было интересно, обнаружат мое вмешательство в маршрутизацию или нет. Не обнаружили. Но давайте разберемся, что можно в этом случае сделать.
Это банально. Подняв у себя EIGRP, я тут же подхватил их таблицу маршрутизации. Имея ее в наличии, легко узнать, какая подсеть свободна, прописать ее на своем маршрутизаторе и получить не лимитированный по трафику или скорости канал. Этим я немного попользовался.
Можно прописать на своем маршрутизаторе любую из присутствующих в таблице маршрутизации подсетей. Если разбить эту подсеть на несколько, с более длинным префиксом, тогда трафик пойдет на вас, а не на клиента провайдера.
Тут может быть много вариантов использования. К примеру, можно эффективно скрывать следы своей нелегальной деятельности. Для проверки концепции я реально захватывал IP адреса dialup клиентов. Их не жалко, если что, они могут заново подключиться и получить другой IP.
Другой пример – захватить на время IP адреса DNS серверов провайдера и подменить клиентам провайдера DNS сервер на свой. В этом случае можно даже (о, ужас!!!) красть пароли от одноклассников. Конечно, это сложно сделать так, чтобы вас не вычислили, но сейчас разговор не об этом.
А давайте задумаемся, какие симптомы сбоя видит клиент, чью сеть захватывают. Для проверки я развернул GNS3. Вот сеть.
А вот, что происходит при наличии на R1 маршрута с более длинным префиксом до прописанной на его интерфейсе подсети — 192.168.0.0/24, и в случае, когда его нет.
Клиент просто не видит свой default gateway на третьем уровне.
Поэтому, если вы очень злой, то, к примеру, можно устроить красивый, наглый и изощренный DoS сетевым администраторам провайдера, лишив их возможности управлять своей же сетью.
Знаете ли вы, что “true одмины” провайдера любят сидеть в белой подсети, за надежным firewall-ом, который сами же сконфигурировали? При этом возможность доступа на управление устройствами сети есть только из этой подсети. Конечно, не всегда, но так часто делают.
Чтобы осуществить атаку, надо узнать в какой подсети они сидят. Для этого можно отправить сетевому администратору провайдера ссылку на прикольную картинку на вашем сервере. А когда в ответ придет несколько смайлов, посмотреть IP адрес по логам сервера. Можно использовать и другие подобные методы, социальную инженерию еще никто не отменял.
Дальше разбить эту подсеть несколько подсетей и прописать их на своем маршрутизаторе. Все, ахтунг обеспечен, у сетевых администраторов провайдера пропал интернет. Со стороны администраторов провайдера покажется, что упал их default gateway. То есть, MAC его виден, но он не пингуется и не доступен на портах управления (telnet, ssh, www). Можно, разве что, подключиться по консоли. Сложно вычислить даже то, что вас атакуют, это больше похоже на аппаратный сбой, или сбой операционной системы на маршрутизаторе. Жестоко, но красиво, правда?
Мониторинг изменения в маршрутизации не зря считается лучшей практикой. Конечно, не следует давать громкое оповещение, когда в сети меняются маршруты, но IMHO, стоит настроить оповещение о том, что в сети появился новый, участвующий в динамической маршрутизации, маршрутизатор.
P.S. Берегируку маршрутизацию, Сеня.
Резонный вопрос, а зачем? Причин вести логи изменения много, а орать система мониторинга должна по той простой причине, что никто не застрахован от ошибки. Об ошибке под катом, а пока, если вы знаете, как работает маршрутизация, внимательно проанализируйте и ответьте себе на вопрос на рисунке.
Правильный ответ на вопрос – через маршрутизатор 3.3.3.3, просто потому, что префикс через этот маршрутизатор длиннее. Когда принимается решение, какой из двух маршрутов победит, всегда, прежде всего, проверяется префикс. Если до хоста есть два маршрута с одинаковым префиксом, то тогда победит маршрут с более приоритетным протоколом маршрутизации, если и протоколы маршрутизации одинаковы, то тогда будут браться во внимание внутренние метрики протокола маршрутизации.
Но мы немного отвлеклись, на самом деле, я хотел рассказать давнюю историю, примерно 2006 года о том, как я случайно получил возможность вмешиваться в маршрутизацию своего провайдера, и что в подобном случае можно сделать.
Как обнаружилась ошибка.
Все началось с того, что мне надо было настроить IDS snort. Пакеты ловить надо было на demark-е с провайдером. Поэтому было настроено зеркалирование порта на свитче, в который включался провайдер. Внутренним интерфейсом сервер snort был в локальной сети, внешним – нюхал зеркальный трафик с demark-a. Естественно, в подобных случаях при настройке всегда запускается tcpdump или что-либо подобное. Когда я начал анализировать, что получил tcpdump-ом, обнаружилась интересная вещь – маршрутизатор провайдера периодически отсылал на меня EIGRP HELLO multicast пакеты.
Как можно ошибиться.
Сначала меня заинтересовало, как такое могло произойти. Я не работал до этого с EIGRP, однако быстро выяснил, что при настройке EIGRP по умолчанию все интерфейсы переводятся в активный режим и маршрутизаторы сразу же начинают искать соседей по маршрутизации, используя для этого multicast. Можно глобально перевести все интерфейсы в пассивный режим и делать активными только определенные из них. Можно оставить все интерфейсы активными и переводить не нужные (те которые смотрят на клиентов) в пассивный режим. Провайдер использовал второй подход. Скорее всего, кто-то из сетевых администраторов провайдера ошибся и не перевел интерфейс, который смотрел на меня, в пассивный режим.
Стало понятно, как такое могло получиться. Допустим, вы конфигурируете, в этот момент вас отвлекает минут на 5 телефонный звонок, вы возвращаетесь к работе и понимаете, что все уже сконфигурировали и все работает. Сохраняете конфигурацию, но забыли, что не перевели интерфейс в пассивный режим.
Варианты эксплуатации ошибки.
Получалось, что я могу настроить у себя EIGRP, и включиться в маршрутизацию провайдера. Естественно, меня заинтересовало, как это можно использовать. Чем больше я над этим думал, тем интересней становилось.
Надо сказать, что у меня были отличные отношения с провайдером. Сотрудники провайдера донесли до нас, что они, в принципе, не против того, что мы попытаемся их взломать и жаловаться не будут. Главное ничего не сломать, и в случае если что-то обнаружим, сказать им. Все люди – все ошибаются. Их бесплатно тестируют на проникновение, а у нас прикольный полигон.
Поэтому я позвонил провайдеру, сказал, что кое-что обнаружил, что именно, скажу на следующий день, а пока поэкспериментирую. Если увидят, что я делаю, пускай прикроют. На самом деле было интересно, обнаружат мое вмешательство в маршрутизацию или нет. Не обнаружили. Но давайте разберемся, что можно в этом случае сделать.
Украсть трафик.
Это банально. Подняв у себя EIGRP, я тут же подхватил их таблицу маршрутизации. Имея ее в наличии, легко узнать, какая подсеть свободна, прописать ее на своем маршрутизаторе и получить не лимитированный по трафику или скорости канал. Этим я немного попользовался.
Захватить любую из используемых подсетей клиентов.
Можно прописать на своем маршрутизаторе любую из присутствующих в таблице маршрутизации подсетей. Если разбить эту подсеть на несколько, с более длинным префиксом, тогда трафик пойдет на вас, а не на клиента провайдера.
Тут может быть много вариантов использования. К примеру, можно эффективно скрывать следы своей нелегальной деятельности. Для проверки концепции я реально захватывал IP адреса dialup клиентов. Их не жалко, если что, они могут заново подключиться и получить другой IP.
Другой пример – захватить на время IP адреса DNS серверов провайдера и подменить клиентам провайдера DNS сервер на свой. В этом случае можно даже (о, ужас!!!) красть пароли от одноклассников. Конечно, это сложно сделать так, чтобы вас не вычислили, но сейчас разговор не об этом.
А давайте задумаемся, какие симптомы сбоя видит клиент, чью сеть захватывают. Для проверки я развернул GNS3. Вот сеть.
А вот, что происходит при наличии на R1 маршрута с более длинным префиксом до прописанной на его интерфейсе подсети — 192.168.0.0/24, и в случае, когда его нет.
Клиент просто не видит свой default gateway на третьем уровне.
Поэтому, если вы очень злой, то, к примеру, можно устроить красивый, наглый и изощренный DoS сетевым администраторам провайдера, лишив их возможности управлять своей же сетью.
Знаете ли вы, что “true одмины” провайдера любят сидеть в белой подсети, за надежным firewall-ом, который сами же сконфигурировали? При этом возможность доступа на управление устройствами сети есть только из этой подсети. Конечно, не всегда, но так часто делают.
Чтобы осуществить атаку, надо узнать в какой подсети они сидят. Для этого можно отправить сетевому администратору провайдера ссылку на прикольную картинку на вашем сервере. А когда в ответ придет несколько смайлов, посмотреть IP адрес по логам сервера. Можно использовать и другие подобные методы, социальную инженерию еще никто не отменял.
Дальше разбить эту подсеть несколько подсетей и прописать их на своем маршрутизаторе. Все, ахтунг обеспечен, у сетевых администраторов провайдера пропал интернет. Со стороны администраторов провайдера покажется, что упал их default gateway. То есть, MAC его виден, но он не пингуется и не доступен на портах управления (telnet, ssh, www). Можно, разве что, подключиться по консоли. Сложно вычислить даже то, что вас атакуют, это больше похоже на аппаратный сбой, или сбой операционной системы на маршрутизаторе. Жестоко, но красиво, правда?
Заключение.
Мониторинг изменения в маршрутизации не зря считается лучшей практикой. Конечно, не следует давать громкое оповещение, когда в сети меняются маршруты, но IMHO, стоит настроить оповещение о том, что в сети появился новый, участвующий в динамической маршрутизации, маршрутизатор.
P.S. Береги