Hak
1 отговора
97 прегледа
Hak
Сниффер в switched enviroment.
Многие системные администраторы полагают, что подключение сервера к аплинку через свитч является панацеей от перехвата сетевого трафика на системе, пусть даже и подключённой в порт того же свитча, но формально не находящейся в одном сегменте коллизий с объектом. Так же многие системные администраторы уверены в том, что MAC-адрес является чудесной величиной, которая "намертво" связана со значением, прошитым в EEPROM сетевой карточки, и его невозможно изменить в эмитируемых интерфейсом пакетах. Однако это не так, и прежде чем мы расскажем непосредственно о способах перехвата трафика в таких условиях, мы рассмотрим принцип работы самого устройства, называемого switch.
Switch или же switching hub является прозрачным мультипортовым мостом между портами, который "переключает" трафик. Такое устройство имеет небольшой интервал задержки и без особых проблем/перегрузок обрабатывает большие потоки трафика. Данное устройство способно разбивать входящий на него трафик по портам в зависимости от условий фильтрации (к примеру, по mac-адресам) в целях минимизации трафика и безопасности. Такое устройство мы будем называть в дальнейшем свитч.
В ходе работы свитч строит таблицы соответствия IP- и MAC-адресов, которые используются им в дальнейшем при распределении пакетов по портам. Данная таблица пополняется динамически в ходе работы устройства, и имеет финитный размер. При получении большого количества пакетов со spoofed ARP-адресом, таблица соответствий в конце концов переполнится и свитч станет действовать, как обычный репитер, то есть каждый пакет, полученный на любой порт, будет повторён по всем портам устройства, а не будет направлен на нужный.
После такой "обработки" свитча возможно использовать обычный сниффер, чтобы осуществлять мониторинг интерфейсов в соседних портах устройства.
Теперь мы рассмотрим пару программ, демонстрирующих алгоритм и технические детали генерации пакетов со spoofed arp, которые позволят переполнить таблицу соответсвий свитча и переключить его в вышеописаный режим.
Первая из них называется angst, и её можно скачать с …………. Данный сниффер способен работать в двух режимах; первый из них назван авторами man-in-the-middle. Смысл данного режима в том, что после старта программа начинает мониторить адреса arp-запросов, и после этого включает arp forwanding на станции, где она запущена, посылая в ответ на arp-запрос ответ, что mac-адрес псевдофорвардера соответствует всем ip-адресам в данной сети.
Второй метод мы довольно подробно рассмотрели выше; программа флудит локальную сеть случайными mac-адресами в результате чего switch перестаёт делать то, что ему положено.
Вторая программа, на примере которой рекомендуется изучать геренацию пакетов с любым обратным arp-адресом, называется arptool, и её можно скачать ……... Программу написала команда team teso, которая в своё время написала объёмный материал по системным вызовам и модулям ядра в среде FreeBSD (в русском варианте она опубликована ……….).
Данная утилита имеет размер всего 3 килобайта и использует библиотечку libnet. Функция, которая строит пакет, готорый к эмиссии, называется libnet_build_arp, и в качестве входных параметров, помимо прочих, берёт значения исходного ip и mac адреса. Функция, которая передаёт полученную структуру драйверу сетевого интерфейса, то есть посылает пакет, называется libnet_write_link_layer.
Таким образом, ни установление жёстких привязок IP-адресов к MAC-адресам, ни организация switched enviroment не является панацеей от перехвата сетевого трафика.
Многие системные администраторы полагают, что подключение сервера к аплинку через свитч является панацеей от перехвата сетевого трафика на системе, пусть даже и подключённой в порт того же свитча, но формально не находящейся в одном сегменте коллизий с объектом. Так же многие системные администраторы уверены в том, что MAC-адрес является чудесной величиной, которая "намертво" связана со значением, прошитым в EEPROM сетевой карточки, и его невозможно изменить в эмитируемых интерфейсом пакетах. Однако это не так, и прежде чем мы расскажем непосредственно о способах перехвата трафика в таких условиях, мы рассмотрим принцип работы самого устройства, называемого switch.
Switch или же switching hub является прозрачным мультипортовым мостом между портами, который "переключает" трафик. Такое устройство имеет небольшой интервал задержки и без особых проблем/перегрузок обрабатывает большие потоки трафика. Данное устройство способно разбивать входящий на него трафик по портам в зависимости от условий фильтрации (к примеру, по mac-адресам) в целях минимизации трафика и безопасности. Такое устройство мы будем называть в дальнейшем свитч.
В ходе работы свитч строит таблицы соответствия IP- и MAC-адресов, которые используются им в дальнейшем при распределении пакетов по портам. Данная таблица пополняется динамически в ходе работы устройства, и имеет финитный размер. При получении большого количества пакетов со spoofed ARP-адресом, таблица соответствий в конце концов переполнится и свитч станет действовать, как обычный репитер, то есть каждый пакет, полученный на любой порт, будет повторён по всем портам устройства, а не будет направлен на нужный.
После такой "обработки" свитча возможно использовать обычный сниффер, чтобы осуществлять мониторинг интерфейсов в соседних портах устройства.
Теперь мы рассмотрим пару программ, демонстрирующих алгоритм и технические детали генерации пакетов со spoofed arp, которые позволят переполнить таблицу соответсвий свитча и переключить его в вышеописаный режим.
Первая из них называется angst, и её можно скачать с …………. Данный сниффер способен работать в двух режимах; первый из них назван авторами man-in-the-middle. Смысл данного режима в том, что после старта программа начинает мониторить адреса arp-запросов, и после этого включает arp forwanding на станции, где она запущена, посылая в ответ на arp-запрос ответ, что mac-адрес псевдофорвардера соответствует всем ip-адресам в данной сети.
Второй метод мы довольно подробно рассмотрели выше; программа флудит локальную сеть случайными mac-адресами в результате чего switch перестаёт делать то, что ему положено.
Вторая программа, на примере которой рекомендуется изучать геренацию пакетов с любым обратным arp-адресом, называется arptool, и её можно скачать ……... Программу написала команда team teso, которая в своё время написала объёмный материал по системным вызовам и модулям ядра в среде FreeBSD (в русском варианте она опубликована ……….).
Данная утилита имеет размер всего 3 килобайта и использует библиотечку libnet. Функция, которая строит пакет, готорый к эмиссии, называется libnet_build_arp, и в качестве входных параметров, помимо прочих, берёт значения исходного ip и mac адреса. Функция, которая передаёт полученную структуру драйверу сетевого интерфейса, то есть посылает пакет, называется libnet_write_link_layer.
Таким образом, ни установление жёстких привязок IP-адресов к MAC-адресам, ни организация switched enviroment не является панацеей от перехвата сетевого трафика.
Re: Hak
Но война "щита и меча" далеко не закончилась. Пока будут потенциальные "дыры" в безопасности - успокаиваться рано.
Да еще как рано... Вот, например, достоверная информация о том, что в одной локальной сети, построенной на неуправляемых коммутаторах, одновременно, и особо не мешая друг, могут работать два узла с одинаковыми IP и MAC адресами.
Сильно колебался, стоит ли публиковать подобную информацию (вообще говоря, думал об этом более полугода). Знания можно реально использовать во вред, но... Политика страуса не даст результатов. Тем более, тема недавно стала достоянием известных в Рунете сетевых форумов. В любом случае, джинн вышел из бутылки.
С теоретической точки зрения, работа двух машин в одном хабе была понятна и без проверки. Но эксперимент был поставлен, и подтвердил справедливость: dns (udp) & icmp работает, tcp - нет.
Условия испытаний:
1 машина - Win2000 - IP/MASK, MAC
2 машина - FreeBSD.
На FreeBSD пишем: ifconfig rl0 IP/MASK lladdr MAC
И никаких проблем.
Кажется, только при инициализации TCP/IP стека винда кидает arp-request на наличие машин с таким же IP, и если получает ответ, то ругается и ничего не выставляет.
Наиболее важно объяснение работы TCP. Предположим, первая машина посылает TCP SYN на сервер, соответственно, оттуда приходит TCP SYN ACK. Этот пакет приходит в хаб, и все машины его видят.
По условиям, MAC & IP совпадают, и каждая машина пересылает пакет на 4-й уровень (т.е. на TCP layer) для дальнейшей обработки. Первая посылает в ответ TCP ACK, а вторая, естественно, TCP RST, т.к. считает этот пакет ошибочным (нет такой сессии). Как только на сервер приходит RST, тот сразу закрывает соединение. И пакеты, которые придут с первой машины, уже в свою очередь получат RST от сервера.
С DNS свои заморочки: там запрос и ответ в 1 пакет укладываются, И, когда приходит ответ, пассивная машина посылает icmp udp port unreachable. Но серверу уже все равно, на функциональности это не отразится.
Теперь работа с коммутатором. Те же компьютеры, но хаб меняется на switch Compex 2208A.
На одной машине запускаем сниффер, и слушаем. Со второй машины лезем в интернет. На первую ничего не приходит (понятно, коммутатор посылает все пакеты на вторую машину, т.к. помнит ее MAC в САМ-таблице).
Потом лезем с первой машины: тоже работает, причем вторая не видит ничего. Что будет, если сразу устанавливать 2 tcp сессии с двух машин, не проверял, можно будет проверить, если интересно.
PS. На второй машине видел tcpdump'ом broadcast'ы NetBIOS'а, но никакой ругани это не вызывало.
Тюкачев Андрей
Что же это означает в реальности? Да просто широчайшую возможность воровства трафика. Сети, с которых это можно было делать просто подставив IP, уже в прошлом. Привязка IP к МАС кое-где используется, но все понимают эфемерность такой защиты. Однако, авторизация на основе управления шлюзом весьма распространена, и считается достаточно надежной.
И вот проблема. Пользователей с одинаковыми IP и MAC, в сети из неуправляемых коммутаторов, невозможно отличить друг от друга на сервере. Просто никак. В какой-то степени спасет сеть, сделанная на хабах (или смешанная). Тогда одновременно смогут работать компьютеры только на разных ветках вышестоящего свитча (если он есть).
Более того, PPPoE не гарантирует безопастности. Конечно, жизнь сетевого "вора" он осложнит (организовать параллельный туннель не так-то просто). Но все зависит от цены вопроса, и рано или поздно какая-нибудь светлая голова напишет программу, делающую этот процесс доступным даже "продвинутому" подростку.
Шифрование трафика, конечно, решит ситуацию. Но потребует взамен совсем не игрушечных вычислительных мощностей от провайдеров. Не всякий сервер справится с такой задачей для нескольких десятков абонентов, даже при простейшем алгоритме.
Почему совместная работа узлов с одинаковыми IP и МАС стала возможна на дешевых коммутаторах? Вопрос не слишком простой, внятного описания алгоритма работы неуправляемого свитча мне найти не удалось.
Можно предположить, что САМ-таблица (content-addressable memory) на самом деле одна, общая для всех портов. И может содержать в каждый момент времени только одну запись для каждого МАС-адреса. Это вполне логично - просто упорядочена эта таблица по адресу, использует его в качестве индекса при поиске. :-) Пришел адрес с другого узла - эффект равнозначен перетыканию разъема одного и того же компьютера в другой порт.
Соответственно, дубликат МАС в таблице автоматически прибивается (он просто не может существовать идеологически). И получается вполне себе поочередная работа (броадкасы хотят отдельно, и никому особо не мешают, как показано выше). Соответственно, соседи и шлюз никак не смогут отличить одного пользователя от другого. На IP уровне все спокойно, а TCP-сессии через локальную сеть проходят "в поле данных".
"Вредителю" нужно найти IP и MAC "жертвы" (задача более чем простая), и аккуратно их заменить. При активной совместной работе может быть заметно "притормаживание" - сессии все же рвутся. Но для малоактивного серфинга, и тем более ICQ, скорости более чем достаточно. А если "жертва" не проявляет особой активности, можно развернуться "по полной".
Такая вот невеселая история получается... А вот и последняя соломинка - письмо с форума iXBT, из-за которого немного пришлось задержать выпуск обзора.
Протестировал только что 2 рабочие станции. Windows 2000 Prof на каждой, IP & MAC совпадают, воткнуты в один свитч Compex 2208A, думаю на Catalist'е картина будет примерно такая же. (надо полагать, без настройки дополнительных фильтров. Прим. Nag)
Если сессии не пересекаются, то работает все просто замечательно. Ходишь по Inet'у и радуешься.
Когда обе машины начинают шариться по сети, то начинаются проблемы, как будто сидишь на плохом линке. Страница может не докачаться полностью. Если начинаешь скачивать файл, то коннект может обрываться в любой момент, стоит второй машине послать что-нибудь...
Если смотреть по netstat -s, то большое количество оборванных сессий (сниффер на роутере показывает проскакивающие TCP RST, когда пакет из TCP сессии на другую машинку попадает ), много Segments Retransmitted, Failed Connection Attempts и Reset Connections. Такая вот картинка.
Но в принципе, очень даже не плохо, если выделенка хорошая и сайт типа iXBT загружается за 2-3 секунды, то можно в инете почти на халяву сидеть.
Какие можно из этого сделать выводы? Применять для отслеживания "злодеев" эвристический анализ можно, но не слишком просто. Да и не эффективно для сколь-нибудь большой сети.
Есть, правда, один "крючочек". Если подделывать адреса "в лоб", без небольшой подготовки, это легко (и главное, удаленно) может определить администратор сети (или даже специальный робот).
Но об этом, думаю, писать подробно никак не стоит. Хоть какая-то небольшая защита должна остаться (тем более, это вроде бы нельзя сделать стандартными средствами windows).
Остается вернуться к тому, с чего начинался обзор. К смыслу применения управляемых коммутаторов. Фильтрация по МАС-адресу, или мониторинг через агента SNMP, эту дыру в защите полностью ликвидируют. Впрочем, защита от "воровства" трафика - не единственное применение этих устройств. Но об этом в следующих обзорах...
Да еще как рано... Вот, например, достоверная информация о том, что в одной локальной сети, построенной на неуправляемых коммутаторах, одновременно, и особо не мешая друг, могут работать два узла с одинаковыми IP и MAC адресами.
Сильно колебался, стоит ли публиковать подобную информацию (вообще говоря, думал об этом более полугода). Знания можно реально использовать во вред, но... Политика страуса не даст результатов. Тем более, тема недавно стала достоянием известных в Рунете сетевых форумов. В любом случае, джинн вышел из бутылки.
С теоретической точки зрения, работа двух машин в одном хабе была понятна и без проверки. Но эксперимент был поставлен, и подтвердил справедливость: dns (udp) & icmp работает, tcp - нет.
Условия испытаний:
1 машина - Win2000 - IP/MASK, MAC
2 машина - FreeBSD.
На FreeBSD пишем: ifconfig rl0 IP/MASK lladdr MAC
И никаких проблем.
Кажется, только при инициализации TCP/IP стека винда кидает arp-request на наличие машин с таким же IP, и если получает ответ, то ругается и ничего не выставляет.
Наиболее важно объяснение работы TCP. Предположим, первая машина посылает TCP SYN на сервер, соответственно, оттуда приходит TCP SYN ACK. Этот пакет приходит в хаб, и все машины его видят.
По условиям, MAC & IP совпадают, и каждая машина пересылает пакет на 4-й уровень (т.е. на TCP layer) для дальнейшей обработки. Первая посылает в ответ TCP ACK, а вторая, естественно, TCP RST, т.к. считает этот пакет ошибочным (нет такой сессии). Как только на сервер приходит RST, тот сразу закрывает соединение. И пакеты, которые придут с первой машины, уже в свою очередь получат RST от сервера.
С DNS свои заморочки: там запрос и ответ в 1 пакет укладываются, И, когда приходит ответ, пассивная машина посылает icmp udp port unreachable. Но серверу уже все равно, на функциональности это не отразится.
Теперь работа с коммутатором. Те же компьютеры, но хаб меняется на switch Compex 2208A.
На одной машине запускаем сниффер, и слушаем. Со второй машины лезем в интернет. На первую ничего не приходит (понятно, коммутатор посылает все пакеты на вторую машину, т.к. помнит ее MAC в САМ-таблице).
Потом лезем с первой машины: тоже работает, причем вторая не видит ничего. Что будет, если сразу устанавливать 2 tcp сессии с двух машин, не проверял, можно будет проверить, если интересно.
PS. На второй машине видел tcpdump'ом broadcast'ы NetBIOS'а, но никакой ругани это не вызывало.
Тюкачев Андрей
Что же это означает в реальности? Да просто широчайшую возможность воровства трафика. Сети, с которых это можно было делать просто подставив IP, уже в прошлом. Привязка IP к МАС кое-где используется, но все понимают эфемерность такой защиты. Однако, авторизация на основе управления шлюзом весьма распространена, и считается достаточно надежной.
И вот проблема. Пользователей с одинаковыми IP и MAC, в сети из неуправляемых коммутаторов, невозможно отличить друг от друга на сервере. Просто никак. В какой-то степени спасет сеть, сделанная на хабах (или смешанная). Тогда одновременно смогут работать компьютеры только на разных ветках вышестоящего свитча (если он есть).
Более того, PPPoE не гарантирует безопастности. Конечно, жизнь сетевого "вора" он осложнит (организовать параллельный туннель не так-то просто). Но все зависит от цены вопроса, и рано или поздно какая-нибудь светлая голова напишет программу, делающую этот процесс доступным даже "продвинутому" подростку.
Шифрование трафика, конечно, решит ситуацию. Но потребует взамен совсем не игрушечных вычислительных мощностей от провайдеров. Не всякий сервер справится с такой задачей для нескольких десятков абонентов, даже при простейшем алгоритме.
Почему совместная работа узлов с одинаковыми IP и МАС стала возможна на дешевых коммутаторах? Вопрос не слишком простой, внятного описания алгоритма работы неуправляемого свитча мне найти не удалось.
Можно предположить, что САМ-таблица (content-addressable memory) на самом деле одна, общая для всех портов. И может содержать в каждый момент времени только одну запись для каждого МАС-адреса. Это вполне логично - просто упорядочена эта таблица по адресу, использует его в качестве индекса при поиске. :-) Пришел адрес с другого узла - эффект равнозначен перетыканию разъема одного и того же компьютера в другой порт.
Соответственно, дубликат МАС в таблице автоматически прибивается (он просто не может существовать идеологически). И получается вполне себе поочередная работа (броадкасы хотят отдельно, и никому особо не мешают, как показано выше). Соответственно, соседи и шлюз никак не смогут отличить одного пользователя от другого. На IP уровне все спокойно, а TCP-сессии через локальную сеть проходят "в поле данных".
"Вредителю" нужно найти IP и MAC "жертвы" (задача более чем простая), и аккуратно их заменить. При активной совместной работе может быть заметно "притормаживание" - сессии все же рвутся. Но для малоактивного серфинга, и тем более ICQ, скорости более чем достаточно. А если "жертва" не проявляет особой активности, можно развернуться "по полной".
Такая вот невеселая история получается... А вот и последняя соломинка - письмо с форума iXBT, из-за которого немного пришлось задержать выпуск обзора.
Протестировал только что 2 рабочие станции. Windows 2000 Prof на каждой, IP & MAC совпадают, воткнуты в один свитч Compex 2208A, думаю на Catalist'е картина будет примерно такая же. (надо полагать, без настройки дополнительных фильтров. Прим. Nag)
Если сессии не пересекаются, то работает все просто замечательно. Ходишь по Inet'у и радуешься.
Когда обе машины начинают шариться по сети, то начинаются проблемы, как будто сидишь на плохом линке. Страница может не докачаться полностью. Если начинаешь скачивать файл, то коннект может обрываться в любой момент, стоит второй машине послать что-нибудь...
Если смотреть по netstat -s, то большое количество оборванных сессий (сниффер на роутере показывает проскакивающие TCP RST, когда пакет из TCP сессии на другую машинку попадает ), много Segments Retransmitted, Failed Connection Attempts и Reset Connections. Такая вот картинка.
Но в принципе, очень даже не плохо, если выделенка хорошая и сайт типа iXBT загружается за 2-3 секунды, то можно в инете почти на халяву сидеть.
Какие можно из этого сделать выводы? Применять для отслеживания "злодеев" эвристический анализ можно, но не слишком просто. Да и не эффективно для сколь-нибудь большой сети.
Есть, правда, один "крючочек". Если подделывать адреса "в лоб", без небольшой подготовки, это легко (и главное, удаленно) может определить администратор сети (или даже специальный робот).
Но об этом, думаю, писать подробно никак не стоит. Хоть какая-то небольшая защита должна остаться (тем более, это вроде бы нельзя сделать стандартными средствами windows).
Остается вернуться к тому, с чего начинался обзор. К смыслу применения управляемых коммутаторов. Фильтрация по МАС-адресу, или мониторинг через агента SNMP, эту дыру в защите полностью ликвидируют. Впрочем, защита от "воровства" трафика - не единственное применение этих устройств. Но об этом в следующих обзорах...