MAC-адрес (Media Access Control, управление доступом к среде, или физ.адрес) прошивается вендором в постоянную память ROM сетевого адаптера. Основное назначение - идентифицировать конкретный адаптер в сети, в отличие от IP-адреса, который олицетворяет весь компьютер целиком. Поскольку на одном узле сетевых адаптеров может быть несколько (проводной Ethernet, беспроводной Wi-Fi или Bluetooth, и у каждого свой МАС), то помимо основного предназначения, МАС определяет и интерфейс связи в сети.
Будь-то на входе или выходе, каждый пакет данных содержит MAC как отправителя, так и получателя, чтобы устройство на другом конце связи могло понять, что эти данные адресованы именно ему. Таким образом, если мы изменим физ.адрес своего сеть-адаптера, то сможем отправлять данные от имени другого лица в сети, а в некоторых случаях и перехватывать чужой трафик.
Авансом отметим, что модифицировать МАС в структуре передаваемых пакетов бессмысленно - драйвер всё-равно обнаружит неладное и рипнет утку, отправив сам пакет к праотцам. Поэтому нужно спуститься на уровень ниже и менять МАС непосредственно в самом адаптере. О том, как это дело организовать прямо под юзером, вы узнаете из данной статьи.
1. Введение
2. Таблица ARP и её кэш
3. Типы МАС-адресов: Unicast, Multicast, Broadcast
4. Практическая часть - пишем софт
5. Заключение
1. Вводная часть
Размер МАС-адреса равен 6 байт или 48-бит, поэтому в доках он числится как EUI-48 (Extended Unique Id). В старших 3-байтах (24-бит) кодируется id производителя т.н. "OUI", при этом 2-бита резерв для флага "Multicast", так-что остаётся 22-бита. А вот младшие 3 байта целиком и полностью отводятся под порядковый номер продукта на производстве. Таким образом в МАС-адресе можно закодировать
2^22=4.17 млн вендоров, и каждый из них способен породить на свет 2^24=16.7 млн сетевых адаптеров.Вся эта кухня находится под колпаком организации IEEE, и если вендор исчерпает свой запас, то может обратиться к шефу с просьбой выделить ему ещё один доп.код OUI, что даст возможность наштамповать очередные 16 млн девайсов. Согласно подсчётам IEEE, запаса этих адресов хватит по меньшей мере до 2100 года (а там гори оно всё огнём), а на данный момент используются всего 0.8% от общего числа.
MAC формирует основу сетей на канальном уровне(2) модели OSI, которую используют протоколы более высокого/сетевого уровня(3). Он позволяет распознавать каждый узел, и доставлять данные только ему. По мере продвижения данных по сетевому стеку ниже, каждый из уровней от 2 по 4 последовательно добавляет в них свои заголовки Header, что обеспечивает правильную маршрутизацию, доставку и контроль целостности информации. Описание этих хидеров можете глянуть к примеру на Хабре здесь.
• TCP-заголовок уровня(4) содержит порты источника и назначения для идентификации приложений, номер пакета TCP, и CRC данных.
• IP-заголовок на уровне(3) хранит IP источника и назначения, время жизни пакета TTL, и тип протокола верхнего уровня.
• Ethernet-Header на уровне(2) содержит уже MAC источника и назначения, тип протокола и трейлер FCS для обнаружения ошибок.
В контексте данной темы нас будет интересовать только канальный уровень(2), который решает проблему адресации в лок.сети. На этом уровне работает коммутатор (см.рис.ниже). Его задача - формировать кадры, и отсылать их от одного устройства к другому, используя в качестве адресов физические MAC (прописываются в заголовке Ethernet-кадра). В программировании уровень(2) представляет драйвер сетевой карты, а в ОС имеется интерфейс NDIS (Network Driver Interface Specification) для связи канального уровня с сетевым, а так-же TDI (Transport Driver Interface) на границе транспортного уровня(4) и сеансового(5), для взаимодействия сетевых протоколов типа TCP/IP, с клиентским софтом.
MAC обеспечивает связь в пределах лишь одного сегмента сети, тогда как логический IP упрощает связь между несколькими лок.сетями и Интернетом. Когда адаптер передаёт данные за периметр сети, для определения пункта назначения роутеры используют публичные IP, а для лок.доставки коммутаторы внутри сегмента оперируют уже только MAC-адресами. Таким образом, физ.адрес МАС оправдывает своё громкое имя исключительно в лок.сети LAN (домашняя, офисная, корпоративная, Ethernel или Wi-Fi), и не имеет никакого смысла за её пределами.
Коммутаторы поддерживают несколько ключевых таблиц для управления трафиком, основной из которых является таблица портов CAM, и адресов ARP. Управляемые свичи создают и таблицы маршрутизации для уровня(3), плюс списки контроля доступа ACL:
• СAМ (Content Addressable Memory) каждому MAC-адресу коммутатор назначает индивидуальный свой порт.
• ARP (Address Resolve Protocol) используется на сетевом уровне(3), для сопоставления IP-адресов с MAC адаптеров.
• RT (Routine Table) используется роутерами на уровне(3), для пересылки пакетов между разными подсетями.
• ACL (Access Control List) хранит правила, фильтрующие трафик на основе портов, IP или МАС-адресов.
В свою очередь маршрутизаторы тоже поддерживает несколько своих таблиц:
• Routing: IP назначения, маски, шлюзы и метрики, определяющие, куда отправлять данные.
• Address Resolution: кэш ARP, связывает IP-адреса с MAC в локальной сети LAN.
• Network Address Translation: NAT, преобразование частных IP-адресов лок.сети, в публичный IP при выходе в интернет.
• Таблица топологии (динам.маршрутизация): используется для обмена инфой с соседними маршрутизаторами, при построении карты сети.
2. Таблица ARP и её кэш
Организовать правильную маршрутизацию трафика конкретным узлам довольно сложно, особенно в больших сетях с кол-вом клиентов овер 255. Поэтому в архитектуру сети был добавлен протокол ARP, суть которого - создать перекличку всех абонентов, и сохранить в кэше пару МАС+IP каждого из них. Это в теории, а на практике таблица ARP заполняется динамически по мере поступления трафика.
Посмотрим ещё раз на сетевой стек выше (модель OSI). Протокол ARP функционирует на канальном уровне(2), а потому когда он получает пакет с данными с сетевого уровня(3), в этом пакете уже имеется IP-заголовок с адресом получателя, но в нём нет его МАС-адреса. Здесь и вступает в дело ARP, который отправляет широковещательный запрос всем узлам в сети, а отвечает на этот запрос только тот узел, чей IP указан в ARP-запросе. Теперь коммутатор сохраняет принятую пару МАС+IP узла в своём кэше, чтобы в сл.раз не повторять все эти операции вновь. На рис.ниже представлен данный процесс.
Для управления таблицей разрешения адресов ARP, система предоставляет нам набор функций в рамках либы IpHelpApi.dll. Они позволяют получать, изменять и удалять записи в ARP-кэше лок.узла. Кроме того в системе имеется одноимённая утилита ком.строки, которая на запрос
arp -a -v сдампит на консоль сведения из кэша в формате IP+MAC каждого узла в сети. Этот отчёт может понадобиться нам в сл.части статьи, когда на практике будем менять МАС своего адаптера.
3. Формат и типы физ.адресов
В дефолте, девственному адаптеру вендор назначает одноадресный MAC "Unicast". Здесь в каждый момент времени между собой могут общаться лишь 2 узла. Но имеются случаи, когда один пакет данных требуется отправить выборочно, например, трём узлам из 20-ти. Такая схема известна как "Multicast", и используется она при создании видео-конференций, общения в чатах типа Zoom/Discord, при трансляции IP-телевидения, и далее в том-же духе.
Узел, который хочет принять участие в таком "шабаше", должен подписаться на специальную "Группу многоадресной рассылки". Регистрация осуществляется на маршрутизаторах динамически, через протокол IGMP (Internet Group Management Protocol) в сетях IPv4, или MLD (Multicast Listener Discovery) в IPv6. В практическом плане, для этого мы просто должны настроить свой сокет функцией
setsockopt() с параметром IP_ADD_MEMBERSHIP.Посмотрим на формат физ.адреса ниже. Здесь видно, что 2 мл.бита в первом байте зарезервированы под флаги Unicast & Multicast адреса, а так-же Vendor/Admin. Это объясняет, почему для Multicast-групп был выбран постоянный МАС-адрес
01-00-5Е-хх-хх-хх, в котором бит(0) в первом байте взведён в единицу (оставшиеся 00-5Е просто идентификатор).
Группа многоадресной рассылки - это специальный IP на маршрутизаторе. Регистрация работает в диапазоне IP-адресов от
224.0.0.0 до 239.255.255.255. Если глянуть на лист организации управления IP-адресами IANA, то можно обнаружить, что данный диапазон выделен именно под класс(D) группы Multicast.
Когда хост желает зарегаться в этой группе, он отправляет запрос "IGMP_Query" маршрутизатору. При этом коммутатор на уровне(2) вставляет свой Ethernet-заголовок, где должен указать текущий МАС+IP как отправителя запроса, а вот в качестве получателя выставить IP равным
224.0.0.х, и МАС 01-00-5Е-хх-хх-хх. Здесь в младшие 3-байта (xx-xx-xx) копируются значение 24-младших бит из IP-адреса отправителя, со сброшенным старшим битом в нуль. В общем схема мутная, поэтому надеюсь скрин ниже немного прояснит ситуацию (168=A8h, сбрасываем старший бит =28h).
Если сейчас запустить утилиту
arp -a -v, то увидим указанные выше адреса MAC+IP. Правда у меня в топологии сети только Wi-Fi роутер, к которому я подключаю свой стационар витой парой Ethernet. Поэтому и лог такой немощный, хотя в реальной сети, например офиса, он будет намного информативней.
4. Практическая часть
Столь длинная пред-история нужна была лишь для того, чтобы определить, какие МАС-адреса можно назначать своему адаптеру, а какие находятся под запретом. От этого зависит поведение драйвера сетевой карты, и всех остальных участников в архитектуре вашей лок.сети. Нельзя присваивать произвольные МАС от фонаря, иначе рискуете оказаться на скамейке запасных. По сути это касается только первого слева байта в МАС-адресе, младший бит(0) в котором обязательно должен быть сброшен в нуль, что выставит адрес в дефолтном (одноадресном) формате вендора "Unicast".
Ну и собственно, что касается правки МАС под юзером.
В Win узнать свой текущий МАС можно двумя способами - это консольные команды
getmac, и ipconfig /all. Но с модификаций вырисовывается довольно интересная картина. Поскольку мы находимся в клетке юзера, то доступ к постоянной памяти ROM адаптера нам конечно-же закрыт, так-что правку физ.адреса прямо в прошивке можно даже не рассматривать.Однако канальным уровнем(2) в модели OSI управляет драйвер сетевой карты, а значит можно подсунуть левый МАС именно ему. Для этого достаточно найти сл.раздел реестра, и прописать в него ключ "NetworkAddress" со-строковым значением нового физ.адреса адаптера.
HKLM\System\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}Указанный выше раздел содержит множество подразделов с именами типа: 0000, 0001, 0002 и т.д. Каждый из этих разделов имеет ключ "DriverDesc" с именем сетевой карты. Нам нужно просмотреть каждый из этих подразделов, пока не найдём тот, в котором лежит описание нашего сетевого адаптера. Как только обнаружим, просто добавляем в него ключ в таком формате (новый мас указывается как НЕХ-строка без пробелов, например).
NetworkAddress REG_SZ 002Е13F58049После правки нужно ребутнуть карту выкл/вкл, чтобы изменения вступили в силу. Теперь можно проверить результат командой
getmac или ipconfig /all. Чтобы вернуть адаптеру дефолтный адрес вендора, просто удаляем указанное выше значение из реестра.Для автоматизации этого процесса, я написал небольшую утилиту. Поскольку в ней работа с реестром, то запускать правой клавишей мыши от имени админа. Из функций понадобятся такие API:
1.
GetAdaptersInfo() - возвращает сведения об активном адаптере сети (имя, guid интерфейса, мас и ip).2.
RegOpenKeyEx() - открывает раздел реестра, RegEnumKeyEx() в цикле перебирает подразделы 0000,0001,0002 и т.д.3.
RegQueryValueEx() читает ключ "DriverDesc" с именем адаптера, а lstrcmpi() сравнивает имя с тем, что получили на этапе(1).4. Если нашли, то
RegSetValueEx() для записи в подраздел ключа "NetworkAddress" с новым МАС, который запрашивается у юзера через элемент "Edit" в окне приложения.5. Для сброса физ.адреса в дефолт используем
RegDeleteValue().Как результат получим такую картину:
5. Заключение
Как показал данный эксперимент, сменить МАС можно и прямо под юзером с правами админа. Скажу честно - практика плохая, т.к. если админ не лопух, то сразу вычислит вас и может настучать по кумполу, ..или что ещё хуже вообще заблокировать по IP, отправив в чёрный список. С другой стороны, если есть такая возможность, то почему-бы не держать её про запас - глядишь когда-нибудь да понадобится. В скрепке найдёте полный исходник кода, с готовым приложением для тестов. Всем удачи, пока!
Последнее редактирование модератором:
