Обнаружение местоположения хоста в неуправляемой сети

Я хочу продемонстрировать решение задачи, которое большинством «сетевиков» считается невозможной в принципе. Речь идет о вычислении физического местоположения хоста в неуправляемой сети. Под неуправляемой сетью подразумевается сеть на неуправляемых коммутаторах, а под определением местоположения — ответ:

«такой-то хост подключен к свичу, который находится здесь»

Сразу оговорю входные условия:

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

Нарушения топологии сети, а также жульничество со стороны абонентов (обмен ip, смена точки подключения) в некоторой степени уменьшают точность результата. Тем не менее, я регулярно пользуюсь данным алгоритмом в своей сети и он показывает довольно точные данные.

В чем сложность?

Неуправляемая сеть — это черный ящик, любой ethernet фрейм, который приходит к вам, не обладает никакой информацией через какие коммутаторы он прошел. Неуправляемый свич — это прозрачное устройство, оно никак не изменяет фреймы, только лишь направляет их в нужные (на его взгляд) порты.

Таким образом, мы не можем получить информацию о пути прохождения ни из ethernet фреймов ни от свичей.

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

Как известно, каждый неуправляемый коммутатор имеет таблицу соответствий mac-port. Эта таблица обновляется каждым входящим фреймом по очень простому алгоритму: на какой порт пришел фрейм, к тому порту привязывается mac-адрес из поля src-mac текущего фрейма. В дальнейшем любой пришедший фрейм с dst-mac как у текущего, будет направлен строго в порт, ассоциированный с этим mac.

В процессе, таблица mac-адресов может изменяться, если фрейм с точно таким же src-mac войдет в другой порт. В этом случае старая информация «забывается». Обычно такая ситуация возникает, когда вы перекоммутируете кабели. На этой «особенности» основан алгоритм обнаружения.

Не буду затягивать с теорией и приведу его.

Итак. Мы имеем неуправляемую гирлянду свичей (суровая реальность мелких домашних сетей), выбираем одну из веток. На конце этой ветки выбираем любого абонента. Его я называю агентом. Он выполняет ключевую роль — поиск неизвестного хоста (в скриптах я называю его hacker) будет происходить на участке сервер-агент. Таким образом, в качестве агента желательно выбрать наиболее удаленного абонента.

Начинается итерация:

1) Arp-запросами запрашиваются ip агента и ip хакера. Ip могут находится в разных логических подсетях, для нас это неважно. Важно то,
что arp-запросами мы «переводим» сеть в ее нормальное состояние, поскольку в дальнейшем будем немного ее дестабилизировать.

2) Берем из базы любого абонента, местоположение, которого нам известно. Я называю его user. Осуществляем ethernet-спуффинг путем посылки arp-request:

src-mac — hacker mac
src-ip — неважно (можно hacker или фейковый ip)
dst-mac — user mac
dst-ip — user ip (можно фейковый ip)

Цель данного пакета — «перепрограммировать» порты (изменить таблицу MAC-адресов) в цепочке свичей от сервера до user маком hacker-а. Если в сети на «перепрограммированном» участке кто-либо отправит пакет на MAC хакера, он будет получен нашим сервером, а не хакером.

3) На агента посылается arp-request:

src-mac — hacker mac
src-ip — неважно (можно hacker или фейковый ip, важно чтоб в подсети agent-а)
dst-mac — agent mac
dst-ip — agent ip

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

Необходимо отметить очень важный момент: инкапсуляцию протоколов. Дело в том, что arp-запрос имеет свои данные, но он «упаковывается» в ethernet-фрейм, который имеет свои данные. В частности src-mac при стандартном использовании arp-request, что в arp-пакете, что в ethernet-фрейме совпадают. В отличие от предыдущего пакета, нам нужно осуществить именно arp-спуффинг, но не ethernet! Т.е. в ethernet фрейме src-mac должен быть нашего сервера, а в arp пакете src-mac = hacker mac. Если это условие будет соблюдено, то коммутаторы, через которые пройдет фрейм, не изменят свои таблицы MAC-адресов.

4) На сервере переключаемся в promiscuous режим (т.е не отбрасываем пакеты, которые идут к нам, но не на наш адрес) и мониторим arp-reply.
Если:
а) получаем пакет направленный на hacker mac — значит географически hacker находится между user и сервером
б) не получаем — вероятно hacker находится за user

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

На рисунке имеем цепочку из 4х коммутаторов. Красной линией обозначен путь прохождения пакета в пункте 2. В результате произойдет «перепрограммирование» таблицы мак-порт ближайшего к серверу свича так, что он будет думать «хакер подсоединен к порту №1». Никакие другие свичи не изменят своего состояния т.к пакет не пройдет через них.

После запроса server -> agent (пункт 3), последний отсылает ответ на мак хакера т.к. src-mac был подменен. Поскольку на участке Hacker-Agent все свичи не меняли своего состояния, пакет беспрепятственно дойдет до хакера.
hacker за user

В случае, когда User находится на участке Hacker-Agent, ответ агента придет на сервер:
hacker перед user

5) Переходим к пункту 1 и выбираем следующего user

В конце тестирования мы имеем таблицу: user — получен/не получен ответ от агента. Если выложить данные на карту (а мой скрипт так и делает), то администратор мгновенно отсеивает мелкие отклонения (обычно их нет) и получает очень точный результат: хакер находится на стыке блоков получен/не получен ответ.

Все, что я здесь описал, повторюсь, мною реализовано на практике: скрипты написаны на perl (use Net::Packet; use Net::Packet::Dump;).
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 29

    +9
    Скрипт в студию, пожалуйста :)
      0
      Я не вижу смысла приводить простыню кода. Если есть конкретные вопросы по реализации — задавайте, фрагментарно код приведу
        –1
        Делится знаниями плохо?)
          0
          Данный скрипт — это часть моего проекта (биллинговой системы), т.е в нем есть места привязки (я же упоминал про вывод на карту, например). Т.е. изолированно, без небольшой правки, он не заработает. Тем не менее, я его выложу сегодня. Для понимания принципа работы, согласен, код очень помогает
            +1
            Вот скрипт. Напоминаю, что это модуль моего проекта, т.е полноценно он может заработать только в этом проекте. Я его слегка подправил — выкинул не относящийся к делу функционал. Для изучения, уверен подойдет
              +1
              ну так положите его в пост
                0
                Комментарии в cp1251? Вы программируете на перле в Windows?
                  0
                  А сори, это связано с тем, что проект, под который это писалось начал разработку в 2004 году, тогда UTF8 не был таким актуальным как сейчас. Через пару минут залью в UTF8
        0
        Идея любопытная, но для траблшутинга в масштабах провайдера не подойдёт.
          0
          Ну, почему же? Сейчас многие пионернеты пошли в частный сектор и останутся там надолго т.к. крупным провайдерам нерентабельно возиться с 2-3 абонентами на узел. А частный сектор обычно диктует топологию длинных гирлянд. Конечно, есть исключения. Но, поскольку, сохранность оборудования низкая, то вряд ли поставят управляемые свичи.
          Даже, если у провайдера повсеместно используются управляемое оборудование, то все равно находятся цепочки по 2 свича. А данная технология и там годна. Например, гораздо проще послать монтажника отключить хакера в конкретный подъезд, чем в дом с 3 узлами
            0
            Админы пионернетов знают, что на самом деле неуправляемых свитчей практически не существует.
              +1
              Раз уж ветка пошла «не по теме», то тогда замечу еще один интересный момент: зачастую обычные свичи играют роль предохранителей, т.е обычных абонентов рискованно втыкать в управляемый порт, а собирают в один неуправляемый коммутатор, а уже его в порт управляемого
                +1
                Ага и если у кого-то из клиентов в мыльнице образуется петля, то loopdetect сработает на вышестоящей управляхе и без интернета будут сидеть все клиенты из мыльницы. И таких примеров можно привести кучу.
                Поясните, пожалуйста, от кого и каким образом предохранаяют неуправляемые свитчи?
                  0
                  они работают буквально как предохранители. Т.е. защищают от сгорания порты управляемого оборудования. Стоимость тупого свича, купленного оптом, — до 10 баксов. Это на уровне грозозащиты, зато качественней. Управляемый порт стоит гораздо дороже, если учесть, что на неуправляемый можно «повесить» нескольких абонентов.
                  Если же образуется петля — да, это будет проблема для нескольких человек, причем на короткое время т.к. экспериментатор рано или поздно догадается, что сделал что-то не так.
              0
              Стоимость управляемого свича куда меньше стоимости нескольких сотрудников «по вызову»
            0
            Какое счастье, что у нас нет неуправляемых коммутаторов…
              0
              Вопрос: если «хакер» сидит на одном управляемом свиче с пользователем, чей айпишник и мак-адрес этот самый хакер подменяет (могу за 5 минут накатать скриптик, позволяющий получить набор IP + MAC в подсети, если его немного усложнить, т.е. анализировать еще и traceroute, то можно получить данный набор только для пользователей, сидящих на том же свиче; затем другим скриптиком пингуем поочередно пользователей из списка и подменяем себе IP + MAC на свободные; по cron'у это можно делать, скажем, каждые полчаса), сработает ли ваш алгоритм?
              Сдается мне, что в этом случае вы никак не найдете злоумышленника…
                0
                активное противодействие усложнит обнаружение, конечно. Много будет отклонений, но в принципе отловить возможно. Кстати, помню давно вычислил хакера методом исключения: он заспуфил абсолютно все адреса в сети, кроме своего, т.е. на любой arp запрос я получал 2 arp ответа, кроме от одного адреса.
                  0
                  да, если речь идет про управляемые свичи, то подмена мака на существующий даст 2 арп ответа. Даже, если хакер мониторит, что комп не включен, по характеру можно вычислить, например, идет активная загрузка файла и тут 3 арп запроса о своем адресе (когда винда загружается), далее закачка с тех же удаленных адресов, но на другой внутренний. По характеру все можно вычислить, но уже придется моск включать)
                    0
                    > подмена мака на существующий даст 2 арп ответа

                    Я говорю о подмене и IP, и MAC. Но подмену делать лишь на данные отключенного узла.

                    Кстати, заметил на днях интересную штуку: почему-то вендузячий компьютер отказывается менять IP, если такой айпишник в сети уже есть… Я думал, в винде это не настолько запущенно…

                    > По характеру все можно вычислить

                    По-моему, вы просто замучаетесь мониторить сотни мегабайт логов для отслеживания таких прерванных загрузок. Кстати, а ведь можно и загрузку распределять: скажем, один файл повесить на один IP, второй — на второй и т.д. В итоге помимо смены IP, наш скрипт будет запускать wget -c по списочку для данного IP.

                    В общем, фантазии есть где разгуляться. Причем для реализации этого вообще не надо быть хакером — а только лишь самым обычным юзером с базовым знанием работы в командной строке.
                    0
                    > на любой arp запрос я получал 2 arp ответа, кроме от одного адреса

                    Тоже мне, «хакер»: айпишник поменял, а про мак-адрес забыл… Детсадовец, наверное.
                      0
                      нет, там действительно была серьезная программа, которая на лету генерила несуществующие мак-адреса и сеть впадала в анархию. То, что она не эмулировала атаку на свой же комп и подвело ее.
                        0
                        Не понимаю смысла писать такие скрипты. От них же никакой пользы. То ли дело — менять периодически свой IP и MAC, чтобы превратить лимитированный тариф в безлимитный…
                          0
                          Мне удобно аргументировать, потому что я действительно пользуюсь моим модулем. Фишка в том, что проблемы в сети создают в 99% (я, конечно, не мерял точно) НЕ хакеры, а обычные пользователи. Из последних примеров: клиент домашний роутер воткнул портом ЛАН в сеть провайдера и выдавал клиентам по dchp адреса. Вычислил. Созвонились — все поправили. Предыдущий случай — клиент настроил мост на компе и давал неоплаченным клиентам инет. Тут пришлось прийти к нему домой и отключить мост. В общем, название «хакер» я привел условно. Цель — вычислить местоположение проблемного хоста
                            –1
                            Эм, а на каком основании вы потребовали отключить мост? Меня всегда удивляли провайдеры, запрещающие раздавать инет кому-то еще.
                              0
                              На основании договора: ретрансляция услуг третьим лицам абонентом запрещена. Клиент своей подписью соглашается с условиями договора. На самом деле, клиент был рад — скорость у него повысилась, до этого поступали жалобы на нее (пользовались его инетом соседи)
                                0
                                >На основании договора
                                Ясно. Я бы такой договор не подписал, но сути дела это не меняет. Ясно.
                                >На самом деле, клиент был рад — скорость у него повысилась, до этого поступали жалобы на нее (пользовались его инетом соседи)
                                Вы точно о мосту говорите? Чтобы мостом пользовались соседи это чучело(клиент)
                                должно было докупить сетевуху и дать покопаться в настройках системы тем самым соседям. Удивительно, что после того как соседи у него покопались и начались проблемы со скоростью, оно начало жаловаться вам, а не тягать за уши соседей.
                                  0
                                  Все гораздо проще. Windows 7, одна сетевая, соединение с провайдером по pppoe, мост «между» сетевой и pppoe-соединением.
                                  А с договором что не так? Провайдер страхуется от ситуации, когда клиенты подключаются ради того, чтобы не платить вообще ничего, а «ходить в инет» через соседа. Согласен, что такое крайне редко, но бывает. Ведь провайдер предоставляет не только интернет, но и обслуживание: занятый порт в свиче, ремонт/замена свича в случае экспериментов клиента, кабельное хозяйство, лицензии и разрешения на прокладку кабелей/электричество/строительная лицензия. Я не буду перечислять мегатонны проблем, вы просто находитесь по другую сторону барикад. Интернет сейчас крайне дешев (3 бакса за 100 мбит в моем городе), при этом клиенту не нужно качество (вернее оно далеко не на первом месте), он при любой возможности перебежит туда, где на рубль дешевле. В общем, проблем у нас предостаточно, но мы не унываем)
                  +1
                  Мил человек, не сочти за личное. Просто твоя запись последняя, которую я комментировал и мне лень искать куда бы этот совсем последний комент написать.

                  ЗАБАНЬТЕ МЕНЯ НА ЭТОМ ХОМЯЧНИКЕ!

                  Only users with full accounts can post comments. Log in, please.