Подмена MAC: атака и защита, теория и практика. Передается ли мак адрес через роутер


Меняется ли MAC или IP адрес при передачи пакета по сети?

Материал просмотрен 4 212 раз(а)

Вопрос возможно покажется не совсем корректным. Задам его иначе. Мы знаем, что у пакета данных есть такие параметры как MAC SRC (аппаратный адрес источника), MAC DST (аппаратный адрес назначения), IP SRC (сетевой адрес источника) и IP DST (сетевой адрес назначения).

Предположим, что мы посылаем пакет данных из точки A в точку B через ряд коммутаторов/маршрутизаторов. В какой момент и будет ли вообще меняться эти параметры?

Давайте проведём интересный эксперимент. Выберите верный по вашему мнению вариант (это голосование анонимно), а затем читайте дальше. И в конце мы узнаем, были ли у кого-нибудь заблуждения на этот счёт или нет. Только чур, не подсматривайте. Сперва ответ (голосование полностью анонимно!)

Загрузка ... Загрузка ...

Ну чтож, а теперь вперёд к испытаниям! Я создал топологию в CPT следующего вида:

Топология сети

Топология сети

Здесь у нас три хоста, два в одной подсети (192.168.1.0/24), один в другой (10.0.0.0/24), связаны между собой роутером Cisco 1841 (не принципиально), который имеет первые адреса из каждой подсети на своих интерфейсах. На хостах настроены шлюзы по умолчанию на соответствующие порты маршрутизатора.

Два узла первой подсети объединяются в один домен коллизий через коммутатор 2950 (не принципиально).

Все порты, имеющие IP адрес я подписал. Все порты с MAC-адресами подписаны.

Теперь мы посылаем PING-запрос с узла host1 192.168.1.10 на host2 10.0.0.10. Я опущу здесь процедуру определения аппаратных адресов по протоколу ARP, оставлю только ICMP.

Ключевой момент

Ключевой момент

Оказывается, что исходящий пакет будет иметь следующие параметры:

  1. MAC SRC: адрес host1, то есть адрес с которого отправлен пакет;
  2. MAC DST: адрес порта маршрутизатора.
  3. IP SRC: сетевой адрес host1;
  4. IP DST: сетевой адрес host2;

Пройдя коммутатор пакет не изменится вообще. MAC-адреса портов коммутатора не влияют на процесс пересылки пакета. Правда MAC SRC осядет в таблицы коммутации свича:

Switch#show mac-address-tableMac Address Table-------------------------------------------Vlan Mac Address Type Ports---- ----------- -------- -----1 0050.0f54.2222 DYNAMIC Fa0/31 00d0.bc19.0001 DYNAMIC Fa0/1Switch#

Теперь стало понятно, почему MAC DST пакета содержит адрес порта маршрутизатора, а не удалённой станции.

В первоначальный момент времени, когда коммутатор ещё не знал о местоположении станций (его таблица коммутации была пуста), он разослал пришедший пакет на все-все-все узлы. А пришёл ему пакет в другую сеть! То есть хост, не разобравшись с маршрутизацией (не настроена) просто послал неизвестный пакет на роутер.

Роутер, получив пакет для 10.0.0.10 понял, что эта подсеть находится по его другую сторону, послал пакет туда (а там и узел host2). Коммутатор принял ответ от узла 10.0.0.10 (которое переслал ему роутер) и запомнил, что нужный MAC находится со стороны порта Fa0/3.

Проходя коммутатор пакет не изменит ни один из своих параметров (просто перешлётся на соответствующий порт) дальше. А вот проходя маршрутизатор (точнее достигая своей конечной точки), пакет преобразуется. В другую сеть через роутер пойдёт уже другой пакет, со своим адресом источника и назначения, но с исходными IP адресами.

Выводы:

  1. пакет, проходя коммутаторы, не меняет свои MAC SRC, MAC DST, и уж тем более IP адреса;
  2. пакет, проходя маршрутизаторы, меняет свои MAC SRC, MAC DST на адреса соответствующего порта маршрутизатора.

Честно говоря, я до этого эксперимента считал, что пакет будет получать MAC портов коммутатора в качестве источника всякий раз, когда через них проходит. Хорошо, что я развеял сам для себя эту ошибку.

litl-admin.ru

Подмена MAC: атака и защита, теория и практика

1. Теория

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

Все достаточно просто, если протокол, используемой системой, специально разработандля поддержки авторизации пользователя. В этом случае забота о безопасности лежитна создателе протокола, и рядовому администратору сети не обязательно вникать вдетали его реализации. Достаточно лишь знать, что «старые» протоколы (ftp,telnet) являются недостаточно безопасными, так как передают пароль в доступномдля чтения третьей стороной виде. Очевидно, во времена создания этих протоколовзащита информации от злонамеренного перехвата не была достаточно актуальна.Большинство современных протоколов защищены от перехвата пароля средствамикриптографии, хотя и тут есть некоторые нехорошие возможности 🙂

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

Остановимся на ситуации, когда необходимо идентифицировать компьютер в локальнойсети стандарта TCP/IP + Ethernet. Такая необходимость возникает, например,у провайдера в случае подключения клиентов к Internet по выделенной линии — нужнознать, сколько и у кого набежало на счетчике трафика — от этого зависит суммаоплаты. Пример не надуман — это реальная проблема, с которой сталкиваются всепровайдеры, подключающие клиентов по Ethernet.

Системы в сети TCP/IP вольны сами выбирать, какой им будет присвоен адрес. Нитеоретически, ни практически ничто не мешает компьютеру взять себе любойIP-адрес — это может сделать обычный пользователь, изменив настройки сети.

Несколько сложнее притвориться уже работающим компьютером: в сети не должнонаходится несколько систем с одним IP-адресом одновременно, они не смогутработать, кроме того, оператору второй системы ОС может выдать предупреждение:«конфликтующие IP-адреса». В этом случае необходимо подменять стандартноеповедение ОС атакующего, чтобы она не выдавала себя. Такая технологияназывается «ip-spoofing» и здесь рассматриваться не будет(спуфинг на нашем сайте рассматривалсяранее).

Если компьютеры идентифицируются по IP-адресу, то в нашем примере с провайдеромочень просто работать в Internet за чужой счет. Применение ограничено толькофизическими способами отслеживания источника сигнала, на которое способныдовольно «умные» устройства вроде маршрутизаторов или дорогостоящих свитчейс возможностью настройки.

Отслеживание происходит так: у умного устройства есть несколько физическихвходов aka дырок. Например, в случае маршрутизатора это входы сетевых карт.Администратор настраивает устройство так, чтобы с дырки номер Х могла приходитьлишь информация от машин, которые на самом деле подключены к этой дырке. Еслиже информация приходит не оттуда, откуда ей положено, то она блокируется. Крометого, устройство может ругаться администратору на попытку совершитьнесанкционированные действия либо неверную конфигурацию.

Понятно, что устройство, которое невозможно настраивать с учетом структурыданной сети, заведомо неспособно отлавливать попытки работать под чужимIP-адресом. Как правило, компьютеры в локальной сети соединены простейшимиустройствами — хабами, которые не приспособлены ни к чему, кроме собственносоединения нескольких машин в сеть. Так что этот способ идентификации нельзясчитать надежным.

Более надежным считается идентификация по MAC-адресу, якобы аппаратно зашитомув карточке. Это миф. Во-первых, адрес зашит в ППЗУ (программируемом постоянномзапоминающем устройстве), и может быть изменен при помощи специальных программ,которые часто идут в комплекте драйверов карточки.

Более того, зачем вообще он там находится — совершенно непонятно. Дело в том,что адрес берется из ППЗУ лишь однажды — при инициализации драйвера карточки.Далее генерация MAC-адресов в пакетах осуществляется не на уровне «железа», адрайвером сетевого устройства, и ничто не мешает его изменить даже безперепрошивки ППЗУ. Например, это делается командой ifconfig в *никс и иногдадаже в свойствах сетевой карточки в win9x. В общем случае необходимо написатьсвой драйвер сетевого интерфейса, что непростая, но выполнимая задача.Ограничения — аналогично IP-адресу. 

Миф о невозможности изменения MAC-адреса настолько распространен, что многиеосновывают на идентификации по MAC-адресу критически важную идентификацию,например, позволяют выполнение команд без авторизации якобы достоверноидентифицированной машине. Чем это может кончится, я думаю, понятно. Ну иконечно, подавляющее большинство провайдеров «защищаются» от измененияIP-адреса клиента, проверяя соответствие MAC-адреса и IP-адреса.

2. Практика — атака

Как может выглядеть атака с подменой MAC и IP адреса? Рассматривается случайс провайдером.

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

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

Пакеты бывают двух типов: адресованные кому-то конкретно либо «всем».Последние выделяются тем, что у них MAC-адрес получателя равенFF-FF-FF-FF-FF-FF. Если вы получили пакет, в котором MAC-адрес получателяне равен вашему MAC-адресу, то можете быть уверены, что его отправительнаходится в том же сегменте сети. Адрес можно узнать при помощи командыarp -a — она выводит список MAC-адресов, хранящихся в кеше компьютера. Еслиадреса в кеше не оказалось, стоит попробовать сделать ping на этот адрес иодновременно arp -a, если же его там так и не оказалось — скорее всего, жертване в ваше сегменте сети.

Будьте внимательны, в том же сегменте сети находится машина, имеющая полученныйMAC-адрес, а не IP-адрес. IP-адрес может принадлежать системе, находящейся надругом континенте, дело в том, что при передаче через маршрутизаторы MAC-адресотправителя заменяется MAC-адресом маршрутизатора, и увидеть вы сможете толькоего. Узнать MAC-адрес реального отправителя в общем случае невозможно (да инужно ли?).

После проверки, что вы в одном сегменте с жертвой, нужно узнать ее настройкимаршрутизации, конкретнее — шлюз по умолчанию. Шлюзом называется маршрутизатор,обеспечивающий связь с другой сетью, например, с Internet. Для нахождениямаршрутизаторов используется их вышейказанная особенность: от одного MAC-адресаприходят пакеты со многих IP-адресов. 

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

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

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

3. Практика — защита

Как можно достоверно идентифицировать машину в сети? Необходимо использоватьавторизацию и криптографические системы защиты. Доверять компьютеру просто наосновании его IP и MAC — небезопасно.

А как быть провайдерам? Полностью надежной защитой от использования чужоготрафика было бы использование для связи с маршрутизатором протокола,поддерживающего безопасную авторизацию и защиту от перехвата. Таких я невстречал 🙂

Из тех решений, которые я встречал, выделю два. Оба — достаточно надежные,но не защищают от одновременной работы нескольких машин под одним IP. Впрочем,это можно заметить, да и вряд ли программисты, способные реализовать подобнуюатаку, будут баловаться халявным трафиком.

1. Microsoft Winsock proxy client-server. Программа, заменяющая стандартныйwinsock в win9x, NT и win2k у клиента и MS Proxy server. Авторизуется черезnetbios входом в домен NT. Однако, сомневаюсь, что протокол соединенияclient-server защищен от перехвата и подмены отправителя.

2. Самодельный клиент, используемый одним из Екатеринбургских провайдеров.Периодически посылает запрос «откройте доступ такому-то IP» на маршрутизатор.Для отсылки запроса нужен пароль. Если запроса нет, то доступ закрывается. Врезультате только знающий пароль откроет себе доступ, злоумышленник, изменившийнастройки, ничего сделать не сможет. Авторизация защищена качественно. Отработы двух станций с одними характеристиками, опять же, ничто не защищает.

xakep.ru

НОУ ИНТУИТ | Лекция | Функционирование маршрутизаторов

Аннотация: Рассмотрены принципы назначения IP-адресов статически администратором и динамически. Приведены примеры использования физических и логических адресов при передаче данных по сети. Рассмотрен формат пакета сетевого протокола IP.

8.1. Назначение IP-адресов

Назначение IP-адреса может производиться администратором вручную или с помощью DHCP-сервера. Вручную назначаются адреса сетевым принтерам, серверам и интерфейсам маршрутизаторов. Варианты назначения адреса вручную могут иметь незначительные различия в зависимости от используемой в компьютере операционной системы. Обычно в главном меню компьютера необходимо последовательно выбрать следующие опции:

"Пуск", "Настройка", "Панель управления", "Сетевые подключения", "Подключение по локальной сети".

Во всплывшем окне ( рис. 8.1а) выбрать "Свойства". В следующем окне выбрать "Протокол Интернета (TCP/IP)" ( рис. 8.1б), затем "Свойства"

Окна выбора протокола TCP/IP Рис. 8.1. Окна выбора протокола TCP/IP

После этого необходимо назначить IP-адрес, маску подсети и основной шлюз по умолчанию ( рис. 8.2).

Назначение IP-адреса администратором вручную Рис. 8.2. Назначение IP-адреса администратором вручную

Протоколами автоматического назначения IP-адреса устройств (хостов – host) являются Reverse Address Resolution Protocol ( RARP ), протокол начальной загрузки (BOOTstrap Protocol – BOOTP ) и протокол динамического конфигурирования узлов Dynamic Host Configuration Protocol ( DHCP ). В настоящее время главным образом используется протокол DHCP, который позволяет узлу динамически без участия администратора получать IP-адрес. Нужно только определить диапазон IP-адресов на DHCP-сервере.

Для запроса IP-адреса узел посылает в локальную сеть ( рис. 8.3) запрос с широковещательным IP-адресом назначения – 255.255.255.255 и МАС-адресом – FF:FF:FF:FF:FF:FF. В качестве МАС-адреса источника в запросе указывается адрес запрашивающего узла 01:AA:11:AA:11:AA. Такой запрос поступает на все устройства сети, в том числе на сервер DHCP. Все устройства отбрасывают пакет с запросом, за исключением сервера, который опознает запрос.

Передача ответа сервера DHCP Рис. 8.3. Передача ответа сервера DHCP

При получении запроса DHCP-сервер формирует ответ с широковещательным адресом назначения, в ответе указывается выделяемый в аренду узлу IP-адрес. В заголовке ответа в качестве МАС-адреса назначения указывается адрес запрашивающего узла (01:AA:11:AA:11:AA). Поэтому все устройства отбрасывают пакет с ответом, за исключением узла, пославшего запрос. Кроме выделяемого в аренду IP-адреса в ответе DHCP-сервера содержится адрес основного шлюза по умолчанию и другая информация. На рис. 8.3 основной шлюз имеет IP-адрес 192.168.1.1 и MAC-адрес 01:EE:55:ЕЕ:55:EE. Важным свойством DHCP является способность выделять IP-адрес в аренду динамически, т. е. сервер может изымать неиспользуемый адрес, а затем восстанавливать пользователю адрес, который использовался ранее.

8.2. Передача данных в сетях с маршрутизаторами

Процесс передачи данных рассмотрен на примере сети ( рис. 8.4) от узла Host X до узла Host Y через маршрутизаторы A, B, C. Маршрутизаторы соединены между собой через порты Fast Ethernet, номера которых также приведены на рисунке. Интерфейсы Fast Ethernet характеризуются физическими МАС-адресами и логическими IP-адресами. Адреса узлов и интерфейсов маршрутизаторов, задействованных в процессе передачи, приведены в таблице 8.1. Сетевая маска во всех сетях задана одинаковой и равной 255.255.255.0.

Передача данных по сети Рис. 8.4. Передача данных по сети Таблица 8.1. Адреса узлов и интерфейсов маршрутизаторов
Устройство Интерфейс IP-адрес МАС-адрес
Host X F0/0 172.16.10.11 011ABC123456
Router_A F0/1 172.16.10.1 0001AAAA1111
F0/2 198.20.20.5 0002AAAA2222
Router_B F0/1 198.20.20.6 0001BBBB1111
F0/2 199.30.30.9 0002BBBB2222
Router_C F0/1 199.30.30.10 0001CCCC1111
F0/2 200.40.40.1 0002CCCC2222
Host Y F0/0 200.40.40.7 022DEF123456

Сообщение, сформированное протоколами верхних уровней компьютера Host X, поступает на сетевой уровень, где IP-протокол формирует пакет данных. Поскольку адрес назначения 200.40.40.7 не относится к сети 172.16.10.0, в которой находится Host X, необходима маршрутизация.

Заголовок пакета Поле данных Пакет данных
Первые поля заголовка пакета IP-адрес узла назначения 200.40.40.7 IP адрес узла источника 172.16.10.11 Data

На канальном уровне узел Host X инкапсулирует сформированный пакет в кадр соответствующей технологии, например, Fast Ethernet. В заголовке кадра наряду с другой информацией указываются МАС-адреса источника и назначения. МАС-адрес источника в данном примере будет 011ABC123456. Поскольку МАС-адрес узла-получателя Host Y компьютеру Host X неизвестен, узел Host X обращается к таблице ARP. Узел не находит соответствующей записи в таблице ARP, поэтому он посылает в локальную сеть широковещательный ARP-запрос, в котором задает сетевой логический IP-адрес устройства назначения – 200.40.40.7. Адресат назначения находится за пределами локальной сети 172.16.10.0. Поскольку маршрутизаторы не транслируют широковещательные запросы в другие сегменты сети, в этом случае маршрутизатор в ответ на запрос посылает ARP-ответ с MAC-адресом своего входного интерфейса, на который поступил запрос. Входной интерфейс играет роль основного шлюза по умолчанию. ARP-протокол обращается к соответствующей строке таблицы и отвечает МАС-адресом 0001AAAA1111.

IP-адрес МАС-адрес
172.16.10.1 0001AAAA1111

В соответствии с полученным МАС-адресом 0001AAAA1111 формируется кадр, который по физической среде передается в маршрутизатор Router_A:

Заголовок кадра Заголовок пакета Поле данных Кадр данных
МАС-адрес узла назначения 0001AAAA1111 МАС-адрес узла источника 011ABC123456 IP- адрес узла назначения 200.40.40.7 IP-адрес узла источника 172.16.10.11 Data

В маршрутизаторе Router_A из кадра извлекается (декапсулируется) пакет данных. Производится логическое умножение IP-адреса назначения на маску и определяется сеть назначения. Затем происходит обращение к таблице маршрутизации, в соответствии с которой определяется адрес входного порта следующего маршрутизатора Router_В (адрес следующего перехода) и выходной интерфейс маршрутизатора Router_A. При этом формируется новый пакет, который продвигается к выходному Fast Ethernet порту F0/2 маршрутизатора Router_A. В новом пакете изменяются некоторые поля заголовка, но IP-адреса источника и узла назначения остаются неизменными:

Заголовок пакета Поле данных Пакет данных
Первые поля заголовка пакета IP-адрес узла назначения 200.40.40.7 IP адрес узла источника 172.16.10.11 Data

Затем пакет инкапсулируется в новый кадр, в качестве МАС-адреса узла источника будет использоваться физический адрес выходного интерфейса F0/2 – 0002AAAA2222. МАС-адрес узла назначения определяется с помощью ARP-протокола, как было описано выше. МАС-адресом узла назначения будет физический адрес входного интерфейса маршрутизатора Router_В – 0001BBBB1111.

Новый кадр передается на входной порт маршрутизатора Router_В:

Заголовок кадра Заголовок пакета Поле данных Кадр данных
МАС-адрес узла назначения 0001BBBB1111 МАС-адрес узла источника 0002AAAA2222 IP- адрес узла назначения 200.40.40.7 IP-адрес узла источника 172.16.10.11 Data

Приняв кадр, маршрутизатор Router_В извлекает из него пакет данных и с применением маски и таблицы маршрутизации определяет выходной интерфейс. Пакет инкапсулируется в новый кадр, который передается с новыми МАС-адресами источника и назначения в маршрутизатор Router_С:

Заголовок кадра Заголовок пакета Поле данных Кадр данных
МАС-адрес узла назначения 0001CCCC1111 МАС-адрес узла источника 0002BBBB2222 IP- адрес узла назначения 200.40.40.7 IP-адрес узла источника 172.16.10.11 Data

В маршрутизаторе Router_С, так же как в Router_А и Router_В, формируются новый пакет и кадр. Поскольку адресат назначения находится в сети, непосредственно присоединенной к интерфейсу F0/2 маршрутизатора Router_С, кадр передается узлу назначения Host Y:

Заголовок кадра Заголовок пакета Поле данных Кадр данных
МАС-адрес узла назначения 022DEF123456 МАС-адрес узла источника 0002CCCC2222 IP- адрес узла назначения 200.40.40.7 IP-адрес узла источника 172.16.10.11 Data

Протокол сетевого уровня узла Host Y извлекает из кадра пакет данных. Если пакет при передаче был фрагментирован, из фрагментов формируется целый пакет и через соответствующий интерфейс направляется на транспортный уровень, где из пакетов извлекаются сегменты данных, а из сегментов формируется сообщение.

При передаче данных через соединения "точка-точка" (см. например, схемы рис. 6.5) заголовок кадра может быть существенно упрощен, т. к. интерфейсы непосредственно связаны между собой, поэтому отпадает необходимость задания МАС-адресов узла источника и узла назначения. Примером может служить протокол Point-to-Point.

На пути кадра к устройству назначения его заголовок и трейлер изменяются при прохождении через каждое устройство 3-го уровня составной сети, например через маршрутизатор. Это происходит вследствие того, что в кадре используется локальная адресация 2-го уровня, а пакеты адресуются с применением логического адреса 3-го уровня и в пакете задается конечный адрес узла назначения. Таким образом, при передаче данных через составную сеть IP-адреса узла назначения и узла источника остаются неизменными, МАС-адреса назначения и источника меняются при прохождении каждого маршрутизатора.

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

Если пакет необходимо маршрутизировать, IP-адрес сети назначения сравнивается с таблицей маршрутизации. При нахождении соответствующей записи в таблице пакет будет переслан на интерфейс, определенный в строке таблицы маршрутизации. Когда пакет коммутируется на выходной интерфейс, формируется новый кадр с новым заголовком и новым значением CRC в трейлере. Кадр затем передается в новый домен на пути к адресату назначения.

www.intuit.ru


Смотрите также