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" на маршрутизатор. Для отсылки запроса нужен пароль. Если запроса нет, то доступ закрывается. В результате только знающий пароль откроет себе доступ, злоумышленник, изменивший настройки, ничего сделать не сможет. Авторизация защищена качественно. От работы двух станций с одними характеристиками, опять же, ничто не защищает.
Достоверно идентифицировать пользователя в сети - очень важная задача. Если пользователь неверно идентифицирован, он может получить слишком высокие права доступа либо воспользоваться платными ресурсами за чужой счет. Система должна быть защищена не только от сбоя, но и от намеренной попытки пользователя обмануть ее.
Все достаточно просто, если протокол, используемой системой, специально разработан для поддержки авторизации пользователя. В этом случае забота о безопасности лежит на создателе протокола, и рядовому администратору сети не обязательно вникать в детали его реализации. Достаточно лишь знать, что "старые" протоколы (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" на маршрутизатор. Для отсылки запроса нужен пароль. Если запроса нет, то доступ закрывается. В результате только знающий пароль откроет себе доступ, злоумышленник, изменивший настройки, ничего сделать не сможет. Авторизация защищена качественно. От работы двух станций с одними характеристиками, опять же, ничто не защищает.