Вы отсутствовали в чате в течении 10 минут. В результате Вы были удалены из списка посетителей чата. Для возврата в чат, нажмите кнопку Вернуться в чат.
(21 Май 2012 - 11:15 )
Да, у Роббена было много шансов забить гол.... да ладно «продули так продули» ничего не поделаешь. Это всё Абрамович виноват ! всех подкупил? ШуЧу
(18 Май 2012 - 07:58 )
А вот этого я боюсь аж дрожь просекает, вспомнить то где я был, и что я делал. Зачем это всё и почему?? Иногда снится и просыпаюсь в поту лица. Да, поздно, всё поздно, вся эта жизнь поздно, нет дороги назад.
(18 Май 2012 - 06:21 )
Эх заглянул в мои старые фотографии, 80-е где я на моцике рассикал да вот ещё одна Ява вишнёвка классная была . Куда годы только летят а?
(18 Май 2012 - 04:54 )
Да самые лучшие мотоциклы на мой взгляд это амереканские Харли, но они сильно дорогие, за такие деньги которые стоют Харли можно купить приличную машину. Макс, что я тебе сказать хотел, я где то читал что если нарвать свежую крапиву и отварить её, пить этот настой очень помогает, попробуй может к лучшему будет.
NAT (Network Address Translation — преобразование сетевых адресов) представляет собой стандарт IETF (Internet Engineering Task Force — рабочая группа разработки технологий интернета), с помощью которого несколько компьютеров частной сети (с частными адресами из таких диапазонов, как 10.0.x.x, 192.168.x.x, 172.x.x.x) могут совместно пользоваться одним адресом IPv4, обеспечивающим выход в глобальную сеть. Основная причина растущей популярности NAT связана со все более обостряющимся дефицитом адресов протокола IPv4. Средство общего доступа к подключению интернета в операционных системах Windows XP и Windows Me, а также многие шлюзы интернета активно используют NAT, особенно для подключения к широкополосным сетям, например, через DSL или кабельные модемы.
NAT дает немедленное, но временное решение проблемы дефицита адресов IPv4, которая рано или поздно отпадет сама собой с появлением протокола IPv6. Сейчас эта проблема особенно актуальна в Азии и некоторых других регионах; вскоре она заявит о себе и в Северной Америке. Поэтому понятен интерес к использованию IPv6 в качестве более долговременного решения проблемы дефицита адресов.
NAT не только позволяет сократить число необходимых адресов IPv4, но и образует дополнительную защиту частной сети, поскольку с точки зрения любого узла, находящегося вне сети, связь с ней осуществляется лишь через один, совместно используемый IP-адрес. NAT — это не то же самое, что брандмауэр или прокси-сервер, но это, тем не менее, важный элемент безопасности.
Рис. 1. Пример сети, использующей устройство NAT для доступа в интернет. Устройством NAT может служить компьютер, а также надежный кабельный модем или модем DSL.
Общие принципы работы NAT
Клиентам сети, находящимся с внутренней стороны устройства NAT, назначаются частные IP-адреса; обычно это делается через службу DHCP (Dynamic Host Configuration Protocol — протокол динамической настройки узлов) или путем статической настройки, выполняемой администратором. В ходе сеанса связи с узлом, находящимся снаружи этой частной сети, обычно происходит следующее.
На стороне клиента
Приложение, собирающееся установить связь с сервером, открывает сокет, определяемый IP-адресом источника, портом источника, IP-адресом назначения, портом назначения и сетевым протоколом. Эти параметры идентифицируют обе конечные точки, между которыми будет происходить сеанс связи. Когда приложение передает данные через сокет, частный IP-адрес клиента (IP-адрес источника) и клиентский порт (порт источника) вставляются в пакет в поля параметров источника. Поля параметров пункта назначения будут содержать IP-адрес сервера (IP-адрес назначения — удаленный узел) и порт сервера. Поскольку пункт назначения пакета находится вне частной сети, клиент направляет его в основной шлюз. В данном сценарии роль основного шлюза играет устройство NAT.
Исходящий пакет в устройстве NAT
Устройство NAT перехватывает исходящий пакет и производит сопоставление порта, используя IP-адрес назначения (адрес сервера), порт назначения, внешний IP-адрес устройства NAT, внешний порт, сетевой протокол, а также внутренние IP-адрес и порт клиента.
Устройство NAT ведет таблицу сопоставлений портов и сохраняет созданное сопоставление в этой таблице. Внешние IP-адрес и порт — это общие IP-адрес и порт, которые будут использоваться в текущем сеансе передачи данных вместо внутренних IP-адреса и порта клиента.
Затем устройство NAT «транслирует» пакет, преобразуя в пакете поля источника: частные, внутренние IP-адрес и порт клиента заменяются общими, внешними IP-адресом и портом устройства NAT.
Преобразованный пакет пересылается по внешней сети и в итоге попадает на заданный сервер.
Рис. 2. Пример преобразования исходящего пакета.
На стороне сервера
Получив пакет, сервер полагает, что имеет дело с каким-то одним компьютером, IP-адрес которого допускает глобальную маршрутизацию. Сервер будет направлять ответные пакеты на внешние IP-адрес и порт устройства NAT, указывая в полях источника свои собственные IP-адрес и порт.
Входящий пакет в устройстве NAT
NAT принимает эти пакеты от сервера и анализирует их содержимое на основе своей таблицы сопоставления портов. Если в таблице будет найдено сопоставление порта, для которого IP-адрес источника, порт источника, порт назначения и сетевой протокол из входящего пакета совпадают с IP-адресом удаленного узла, удаленным портом и сетевым протоколом, указанным в сопоставлении портов, NAT выполнит обратное преобразование. NAT заменяет внешний IP-адрес и внешний порт в полях назначения пакета на частный IP-адрес и внутренний порт клиента.
Затем NAT отправляет пакет клиенту по внутренней сети. Однако если NAT не находит подходящего сопоставления портов, входящий пакет отвергается и соединение разрывается.
Благодаря устройству NAT клиент получает возможность передавать данные в глобальной среде интернета, используя лишь частный IP-адрес; ни от приложения, ни от клиента не требуется никаких дополнительных усилий. Приложению не приходится обращаться к каким-либо специальным API-интерфейсам, а клиенту не нужно выполнять дополнительную настройку. В данном случае механизм NAT оказывается прозрачным по отношению к клиенту и к серверному приложению — все работает просто и четко.
Однако не все сетевые приложения пользуются протоколами, способными взаимодействовать с NAT. В этом-то и заключается проблема.
Проблемы взаимодействия NAT и приложений
Средство NAT успешно обеспечивает совместное использование единого глобального IP-адреса, когда клиент инициирует контакт и принимает ответ через один и тот же порт. Однако многие приложения используют стратегии, основанные на предположениях, которые становятся неверными, если для доступа в интернет применяется устройство NAT. Некоторые из подобных проблем обсуждаются ниже.
Службы во внутренней сети
Многие сетевые службы и серверы исходят из того, что если они установили прослушивающий сокет, то любой клиент в интернете сможет инициировать с ними контакт. Если на периферии сети размещено устройство NAT, то для прохождения входящего трафика к службам внутренней сети потребуется наличие соответствующего сопоставления портов. Поэтому такая служба будет доступна только клиентам частной сети, но не остальным узлам интернета.
Чаще всего эту проблему обходят, вручную настраивая сопоставление портов, которое позволяет устройству NAT передавать трафик, адресованный в NAT с указанием неких внешних IP-адреса и порта, на внутренние IP-адрес и порт, используемые службой.
Когда такое сопоставление установлено, служба может получать входящие пакеты и становится доступной для клиентов, внешних по отношению к частной сети. Пока сопоставление портов не выполнено, связь с сетью не поддерживается.
Настроить сопоставление портов вручную, как правило, довольно сложно; это требует определенного опыта. Поэтому многие индивидуально работающие пользователи и сотрудники небольших офисов не могут работать с нужными им приложениями и службами без посторонней помощи и вынуждены в поисках решения проблемы обращаться в службу технической поддержки своего интернет-провайдера, производителя компьютера, торговой фирмы или производителя шлюза интернета. К тому же такое сопоставление накладывает меньше ограничений — любой внешний клиент сможет воспользоваться им для инициирования контакта с сервером.
Вложенные адреса и порты
Некоторые сетевые приложения предполагают, что IP-адрес и порт, назначенные клиенту, всегда будут доступны для глобальной маршрутизации и смогут непосредственно использоваться в интернете. Во многих случаях эти адреса являются частными IP-адресами из диапазонов, зарезервированных группой IETF. Приложение включает такой частный IP-адрес или порт в содержащую полезные данные часть пакета, посылаемого на сервер. Сервер может использовать этот вложенный адрес для связи с клиентом.
Если сервер попытается ответить, используя вложенные IP-адрес и порт вместо сопоставленных значений адреса и порта, предоставленных средством NAT, то пакет будет отброшен при передаче. Это происходит потому, что вложенный IP-адрес нельзя маршрутизировать. Если сетевое приложение обнаружило бы устройство NAT и получило у него внешний IP-адрес и внешний порт, оно смогло бы поместить в пакет правильные данные.
Приложения, использующие различные сокеты
Некоторые сетевые приложения отправляют трафик на сервер или в другой узел, используя сокет в одном порте “X”, а ожидают ответа с сервера на другом, прослушивающем сокете в порте “Y”. NAT изучает исходящий трафик и производит сопоставление порта “X”, но не знает о том, что нужно еще выполнить сопоставление портов для возвращающихся пакетов, адресованных в порт “Y”. Входящие пакеты, адресованные в порт “Y”, отбрасываются.
Ожидание доступа к портам
Некоторые сетевые протоколы исходят из того, что нужный им порт, широко известный и допускающий глобальную маршрутизацию, всегда будет для них доступен. Когда несколько клиентов сообща используют один IP-адрес, в каждый момент времени только один клиент имеет доступ к стандартному порту. Например, только одна веб-служба может в каждый момент времени пользоваться внешним портом 80 в локальной сети. Если бы это было не так, устройство NAT не смогло бы определить, к какому клиенту относится внешний запрос. Необходимо, помимо настройки пользователем сопоставления портов, принять специальные меры к тому, чтобы разные клиенты могли быть распознаны извне локальной сети.
Использование нескольких устройств NAT
Если клиент находится с внутренней стороны устройства NAT, которое, в свою очередь, защищено еще одним устройством NAT, возникают новые проблемы, суть которых выходит за рамки настоящего документа.
Последствия для пользователей и для отрасли
Выше описывались технические аспекты проблем прохождения NAT. По отношению к пользователю эти проблемы проявляются очень просто: применяя NAT, он не сможет работать с нужными ему службами или приложениями.
Большинство пользователей сегодня и не подозревают, что становятся «жертвами» NAT. Они знают одно: когда они пытаются сыграть в коллективную игру или воспользоваться приложениями одноранговой связи (например, средствами общения в режиме реального времени), им это не удается. На экране появляется сообщение об ошибке (что-нибудь вроде «Невозможно установить связь») или приложение, пытавшееся запуститься, завершается аварийно.
В некоторых случаях пользователь, подключающийся к интернету через обычный модем удаленного доступа, не будет сталкиваться с подобными неполадками. Но если он станет абонентом службы широкополосного доступа и перейдет на модем DSL или кабельный модем, проблемы станут неизбежны. Пользователи, рассчитывавшие на более эффективную связь через интернет, будут озадачены внезапно появившимися помехами, не дающими им играть в игры и применять другие службы.
Это может привести к росту недовольства среди пользователей, которое будет направлено на изготовителей компьютеров, интернет-провайдеров, производителей шлюзов интернета и др. Клиент часто не знает, в чем причина неполадок, и сотрудникам службы технической поддержки не всегда удается помочь ему по телефону.
Но это проблема касается не только пользователя. Это также проблема производителей, предоставляющих пользователю продукты и услуги. Обращения в службу поддержки, вызванные проблемами NAT, означают повышение расходов и могут неблагоприятно отразиться на прибылях производителя или продавца продукта. В итоге какая-то часть пользователей может утратить интерес к новым службам и приложениям, испытывая неудовлетворенность из-за неудачных попыток доступа к старым службам, так что NAT превращается в тормоз на пути создания и распространения новейших продуктов и служб.
Учитывая все эти факторы, следует признать, что решение проблемы NAT становится важнейшей задачей для всей отрасли.
Что такое NAT Traversal?
NAT Traversal (прохождение NAT) — это набор возможностей, позволяющих сетевым приложениям определять, что они находятся «под защитой» устройства NAT, узнавать внешний IP-адрес и выполнять сопоставление портов для пересылки пакетов из внешнего порта NAT во внутренний порт, используемый приложением; все это выполняется автоматически, так что пользователю не приходится вручную настраивать сопоставления портов или какие-либо другие параметры.
Данная технология представляет собой более целостное решение проблем связи, обусловленных применением устройств NAT, по сравнению с использовавшимися раньше методами, ориентированными на конкретные приложения. До сих пор подобные специализированные решения требовали либо наличия у пользователя технических знаний, либо специальной доработки со стороны создателя приложения или производителя шлюза интернета, либо всего этого вместе.
Хотя средство прохождения NAT направлено на решение некоторых проблем, связанных с NAT, оно не являются панацеей и не способно разрешить ВСЕ проблемы. Тем не менее его воплощение в автоматизированном виде представляет собой существенный шаг вперед в деле более полного удовлетворения пользователей, снижения нагрузки на службу технической поддержки и продвижения новейших служб и приложений, особенно в среде домашней сети.
Технологию NAT Traversal следует рассматривать как подручный механизм, который должен использоваться в случае необходимости, а не во всех ситуациях подряд. Потребность в NAT и, следовательно, в технологии NAT Traversal отпадет с появлением IPv6, когда каждый клиент получит IP-адрес, допускающий глобальную маршрутизацию. Существуют различные прогнозы относительно того, как скоро завершится повсеместное развертывание IPv6. Компании отрасли, включая Microsoft, вкладывают значительные средства в продвижение IPv6, однако решение NAT Traversal, описываемое ниже, принесет немало пользы сейчас и в ближайшие несколько лет всем, кто работает дома и в небольших офисах и испытывает трудности с использованием NAT.
Принципы работы NAT Traversal
NAT Traversal в своей работе опирается на протоколы обнаружения и управления, входящие в спецификации, установленные Форумом UPnP (Universal Plug and Play). В составе Форума UPnP имеется рабочий комитет, занимающийся составлением протокола управления шлюзовыми устройствами интернета (Internet Gateway Device, IGD) и определением служб для этих устройств.
Шлюзы интернета, поддерживающие обязательные элементы протокола управления устройствами IGD, будут объявлять о своем присутствии и публиковать XML-документы с описаниями для пунктов управления своих локальных сетей. Из этих документов пункты управления смогут узнать, какие операции UPnP требуется вызвать для того, чтобы определить, включена ли поддержка NAT в шлюзе, и выполнить сопоставление портов.
API-интерфейс NAT Traversal в составе Windows позволяет избежать необходимости доступа к UPnP напрямую; он включает функции обнаружения, управления и настройки устройства NAT.
NAT Traversal API
Когда сетевому приложению нужно обнаружить устройство NAT и отрегулировать параметры его работы, приложение может воспользоваться интерфейсом NAT Traversal API, входящим в комплект Windows (и полностью описанным в материалах пакета Platform SDK), и выполнить следующие функции:
определить, присутствует ли устройство NAT;
получить внешний IP-адрес NAT;
получить данные о статическом сопоставлении конкретного внешнего порта, если таковое существует;
добавить статическое сопоставление портов, если внешний порт не был ранее назначен;
включить или отключить конкретное сопоставление портов, не удаляя его;
изменить описание статического сопоставление портов, понятное для пользователя;
удалить статическое сопоставление портов;
получить список статических сопоставлений портов для локальной сети.
С помощью этих функций приложения могут обходить многие проблемы, вызываемые наличием NAT. Следует учесть, что API-интерфейсы NAT Traversal в составе Windows на сегодняшний день поддерживают сопоставления портов только неограниченного срока действия — так называемые статические сопоставления портов.
API-интерфейсы NAT Traversal в составе Windows XP
API-интерфейсы NAT Traversal устанавливаются в Windows XP по умолчанию. Их также можно устанавливать на компьютерах, работающих под управлением Windows Me и Windows 98; для этого используется специальная программа, имеющаяся на компакт-диске Windows XP, — мастер настройки сети (Network Setup Wizard). Для доступа к API-интерфейсам NAT Traversal пользователи также должны установить обозреватель Internet Explorer версии 6.0, обеспечивающий дополнительную поддержку средства синтаксического разбора XML.
NAT Traversal в Windows 2000 на данный момент не поддерживается.
Поддержка NAT Traversal в шлюзах интернета
Поддержка NAT Traversal в шлюзах интернета реализована в виде поддержки спецификации IGD (Internet Gateway Device), определенной Рабочим комитетом по шлюзам интернета в рамках Форума UPnP. Производители шлюзов должны иметь в виду, что API-интерфейсы NAT Traversal, включенные в Windows, исходят из следующих предположений о работе устройств IGD.
Устройства IGD объявляют в каждый момент времени только один внешний интерфейс. Хотя с технической точки зрения допустимо объявление нескольких внешних интерфейсов, API-функции NAT Traversal будут использовать только первый из них.
IGD поддерживают сопоставления портов, обеспечивающие пересылку пакетов с любого удаленного IP-адреса внутренним клиентам.
IGD поддерживают сопоставления портов, в которых в качестве клиента указан широковещательный адрес.
IGD поддерживают различные номера для внешнего порта NAT и внутреннего порта клиента.
IGD генерируют объявления с номером версии 1.
Статические сопоставления портов действуют неограниченно долго, невзирая на перезагрузки, изменения IP-адресов и присутствие клиента на сервере.
На момент написания данного документа уже несколько ведущих производителей объявили о планах начать в 2001 г. поставки поддерживающих эти спецификации UPnP шлюзовых устройств интернета, совместимых с API-интерфейсами Windows NAT Traversal. Это важное событие как для пользователей, так и для отрасли в целом.
Чем больше производителей шлюзов интернета осознают преимущества технологии UPnP как средства обхода проблем NAT и чем больше пользователей знакомятся с этими средствами, тем выше шансы на то, что решение NAT Traversal на базе UPnP станет непременным атрибутом устройств данной категории.
Производителям шлюзов интернета следует вступать в ряды Форума UPnP — так они смогут быстрее узнать о том, как добиться совместимости своих устройств со стандартами UPnP.
Следует заметить, что средство общего доступа к подключению интернета в Windows XP поддерживает версию 0.9 стандарта UPnP IGD. Ожидается, что версия 1.0 будет совместима с версией 0.9.
Как приложения используют NAT Traversal
Способ использования NAT Traversal приложением зависит от ряда факторов, например, от того, каким должен быть срок действия сопоставления портов и сколько клиентов или служб используют данный порт. Очень важно, чтобы приложения в конце уничтожали («очищали») создаваемые ими статические сопоставления портов, чтобы освобождать порты для других приложений.
Если приложение представляет собой сетевую службу (например, веб-сервер), которой требуется какой-либо широко известный порт на всем протяжении ее существования, программа установки такого приложения может настроить статическое сопоставление порта с помощью API-интерфейсов NAT Traversal. Если сетевая топология остается постоянной и механизмы очистки не затрагивают это сопоставление, внешние клиенты смогут контактировать со службой в течение всего периода ее работы. Удалить сопоставление должна будет программа удаления приложения. После аварийного сбоя статические сопоставления портов останутся, несмотря на отсутствие службы. Изменение внешнего IP-адреса будет автоматически учтено статическим сопоставлением портов.
Если приложение не будет работать постоянно или нет гарантии, что его статические сопоставления портов будут все время поддерживаться сетью, оно может резервировать какой-либо известный порт при каждом запуске и возвращать его при каждом завершении работы. Это можно делать с помощью параллельно активизируемого сценария. Возможен и иной вариант: вместо добавления и удаления сопоставления портов приложение будет каждый раз включать и выключать его. Можно также оставить статическое сопоставление портов постоянно действующим и просто обновлять его при запуске приложения.
И в этом случае изменение внешнего IP-адреса автоматически учитывается статическим сопоставлением портов.
Если один и тот же внутренний номер порта используется сразу несколькими приложениями разных клиентов частной сети, эти приложения придется немного изменить, чтобы обеспечить работу нескольких клиентов. В каждый момент времени только один клиент может сопоставлять внешнему порту этот внутренний номер порта. Рекомендуется такой режим: право на использование порта получает первый клиент. Остальные клиенты должны запрашивать асимметричные сопоставления, в которых внутренний порт отличался бы от внешнего.
Следует рассмотреть такой особый случай: несколько клиентов могут прослушивать один и тот же внешний порт с единственной целью — быть обнаруженными удаленными узлами. Входящие пакеты могут преобразовываться так, чтобы в качестве внутреннего IP-адреса клиента указывался широковещательный адрес, а не адрес конкретного клиента. Клиенты, прослушивающие сеть через этот порт, смогут ответить, инициируя свое собственное подключение к удаленному узлу. Такой метод не рекомендуется для общего пользования, поскольку входящие пакеты с этим адресом назначения будут приниматься каждым клиентом сети, создавая для них дополнительную нагрузку.
Если службе необходимо прослушивать произвольный порт в течение короткого промежутка времени, она должна запросить статическое сопоставление порта в приложении, а не в сценарии. Закончив работу, служба должна сразу же выполнить очистку (удалить сопоставление). В приложении следует вести учет собственных действующих сопоставлений портов. В итоге если произойдет сбой приложения и оно не успеет закрыть сопоставления портов, при следующем запуске приложения оно сможет получить все данные, необходимые для очистки.
Если приложение должно выйти из сети без очистки своих сопоставлений портов, они будут сохранены, и ответственность за очистку перекладывается на пользователя. В настоящее время в Windows механизм очистки отсутствует, поскольку трудно определить, когда приложение заканчивает пользоваться сопоставлением.
Недостатки NAT Traversal
Хотя NAT Traversal позволяет решить ряд проблем, связанных с подключением через устройства NAT, некоторые проблемы все же остаются. Они перечислены ниже.
NAT Traversal использует модель открытых доверительных отношений. Это означает, что все приложения в частной сети имеют доступ ко всем сопоставлениям портов, установленным в NAT. В результате значительно повышается гибкость администрирования (точек управления становится больше), однако приложения лишаются прав монопольного владения своими сопоставлениями.
Разрешение конфликтов является обязанностью приложений. Если приложение пытается сопоставить порт, уже сопоставленный другому клиенту, следует либо найти другой порт, либо соответственно изменить программный код.
NAT Traversal не решает проблемы интернет-провайдеров, которые сами распределяют частные адреса и используют NAT для подключения клиентов. В этом случае NAT оказывается снаружи шлюза интернета, фактически в сети провайдера. Средство NAT Traversal в домашней или небольшой офисной сети не сможет работать, если устройство NAT в клиентской сети защищено еще одним таким же устройством NAT. Поэтому интернет-провайдерам не рекомендуется развертывать NAT в своих сетях.
Изначально приложение не имеет доступа к NAT Traversal — его необходимо изменить, чтобы можно было вызывать функции API, или сопроводить соответствующим сценарием. Впрочем, это вполне осуществимая задача для разработчика, особенно учитывая тот факт, что как только механизмы NAT Traversal интегрированы в приложение, оно приобретает способность работать с множеством различных шлюзов интернета.
Приложения, закончив работу с сопоставлениями портов, должны выполнить после себя очистку. Статические сопоставления сохраняются неопределенно долго и наиболее всего подходят для служб, которые собираются прослушивать широко известные порты на протяжении всего существования приложения.
Шлюз интернета, на котором установлены средства NAT, должен поддерживать спецификацию Universal Plug and Play Internet Gateway Device версии 0.9 или более поздней.
Заключение
NAT представляет собой одобренное группой IETF решение проблемы исчерпания пространства имен IPv4. Шлюзы интернета, использующие NAT, часто устанавливаются дома и в небольших офисах. Они применяются потому, что дешевы, легко управляемы и не требуют установки специального программного обеспечения.
Недостатком использования NAT является то, что оно препятствует применению коллективных игр, служб общения в режиме реального времени и приложений одноранговой связи. Это объясняется тем, что сетевые протоколы действуют исходя из предположений об архитектуре сети, которые с появлением NAT перестают выполнятся.
Технология NAT Traversal позволяет приложениям обнаружить устройство NAT, определить совместно используемый IP-адрес, допускающий глобальную маршрутизацию, и настроить статические сопоставления портов с целью устранения некоторых проблем связи. Решение NAT Traversal не избавляет от всех проблем, связанных с NAT, но предотвращает некоторые из них.
Основные тезисы данного документа:
Производители шлюзов интернета должны реализовывать технологию UPnP в своих устройствах, чтобы обеспечить поддержку NAT Traversal.
Разработчики сетевых приложений должны использовать API-интерфейсы Windows NAT Traversal для обнаружения NAT и предусмотреть в своих приложениях возможность прохождения NAT в случае необходимости.
Пользователи, желающие добиться наиболее эффективной работы приложений, должны выбирать для себя шлюзы интернета, поддерживающие технологии UPnP и NAT Traversal.
Провайдеры широкополосного доступа (через DSL и кабельные модемы) должны организовать продажу и аренду шлюзов интернета, поддерживающих UPnP NAT Traversal.
NAT Traversal будет существовать в той или иной форме до тех пор, пока с появлением IPv6 не отпадет необходимость в NAT.
В основном нарушения сетевых соединений кратковременны и связаны с работами администратора по перезапуску, переустановке и изменению настроек устройств, отвечающих за доставку запросов и сообщений.
Есть всего несколько условий, нарушение которых не позволяет соединиться с сервером почты, Web-сервером или сервером, установленным в виртуальной частной сети, через Internet или корпоративную сеть: компьютер должен уметь разрешать имя DNS (определять IP-адрес по имени компьютера); сервер должен нормально функционировать; должен существовать путь между двумя компьютерами; необходимо иметь соответствующие права доступа.
Для указания целевого компьютера многие используют имена. Т.е. мы посещаем или , получаем почту с pop3.denver.qwest.com. Однако эти имена являются просто псевдонимами, которые необходимо перевести в реально зарегистрированные TCP/IP-адреса, точно определяющие получателя. Когда сообщения попадают в сеть, они содержат информацию об источнике и приемнике в виде TCP/IP адресов, а не соответствующих имен. Windows использует либо DNS, либо WINS для перевода имен в адреса. DNS - это стандартное средство разрешения имен в сетях TCP/IP для корпоративных сетей и Internet. WINS – патентованный стандарт Microsoft, используемый для трансляции имен вида \printserverprinter_A или \server_xshare_2 в адреса TCP/IP. После успешного преобразования имени в адрес путь запроса или сообщения к получателю должен быть открыт.
Чтобы отыскать причину неполадок, необходимо: во-первых, проверить конфигурацию протокола TCP/IP на компьютере; во-вторых, убедиться, что имя удаленного компьютера верно и имеет корректный адрес TCP/IP; в третьих, убедиться, что доступ к удаленному компьютеру возможен. Для выполнения этих проверок я составила список утилит командной строки. Если в результате подтверждает правильность перевода имени DNS в адрес TCP/IP, работоспособность удаленного компьютера и наличие открытого пути между двумя системами, то проблемы, скорее всего, связаны с идентификацией и правами доступа.
Утилиты командной строки для проверки соединений
· Команда Ipconfig /all показывает настройки протокола TCP/IP на компьютере. Два важных параметра протокола - Default Gateway (шлюз по умолчанию) и сервер DNS.
· Команда Nslookup переводит TCP/IP-имя сервера в TCP/IP-адрес. Эта команда аналогична использованию он-лайновой телефонной книжки для поиска индивидуального имени (TCP/IP-имя) и телефонного номера (TCP/IP-адрес). По умолчанию, если набрать Nslookup в командной строке, система отправляет запрос к серверу DNS, указанному в установках протокола TCP/IP на компьютере. Если сервер DNS не работает, появляется сообщение об ошибке: DNS request timed out. Если все в порядке, сервер DNS отвечает символом «больше» (>) и ожидает ввода имени сервера, который необходимо найти. Когда сервер DNS возвращает имя и адрес искомого сервера, в их корректности можно не сомневаться.
· Команда Ping “компьютер” дает информацию о доступности и состоянии удаленного компьютера. Команда Ping работает и по имени, и по адресу. Если при выполнении команды Ping для компьютера www.google.com пришел ответ на запрос, значит, для имени найден правильный TCP/IP-адрес, и компьютер Google функционирует нормально. Неработающий компьютер не отвечает на запрос Ping и появляется сообщение об ошибке: Request timed out. Возможны три причины ошибки: неверное имя; сервер DNS не может определить адрес TCP/IP; необходимые службы или сам компьютер не работают. Кроме того, операционная система может не отвечать на запросы Ping, если администратор специально заблокировал эту возможность, например, из соображений безопасности.
· Команда Tracert показывает все промежуточные узлы между источником и приемником. Tracert, как и Ping, работает и по имени, и по TCP/IP-адресу. Использование Tracert – это простой способ проверить, есть ли для запроса открытый путь к получателю. Tracert отвечает списком узлов, одна строка – один узел, который необходимо пройти при маршрутизации запроса. Если один из узлов на пути запроса недоступен, команда возвращает временные параметры и имя узла, отмеченные символом звездочка (*), и сообщение об ошибке Request timed out. Если проложить маршрут до получателя невозможно, необходимо подождать, пока отсутствующая часть не заработает, либо не появится альтернативный путь. Первым узлом, который покажет Tracert, должен быть Default Gateway (шлюз по умолчанию), установленный в настройках протокола TCP/IP компьютера.
· Утилита Netmon является анализатором сетевых пакетов, предоставляющим большие возможности. Netmon позволяет получить подробную информацию обо всех отправленных и полученных системой сетевых пакетах. Если все ранее указанные команды показывают, что сетевое соединение есть, но, тем не менее, проблемы остались, Netmon – последнее средство спасения. Несмотря на то, что чтение сетевых пакетов – процесс очень трудоемкий, причины сбоев можно определить практически всегда.
Принятие стандарта безопасности 802.11i и постепенное распространение сетей на основе WPA-сертифицированных устройств придало многим уверенность в высокой степени защищенности их беспроводной инфраструктуры. И действительно, при продуманной и тщательной настройке безопасности WPA-защищенной сети, её взлом "в лоб" практически невозможен, если не считать взломом атаки по отказу в обслуживании (DoS) на первом и втором уровнях OSI модели. Тем не менее, расслабляться не следует. Даже если ИТ инфраструктура регулярно проверяется на предмет установки несанкционированных устройств, ключ к закрытой с помощью WPA-PSK 802.11 сети невозможно подобрать атакой по словарю, либо же применена конфигурация WPA-802.1х (WPA-Industry) с использовнием безопасных типов EAP (например, EAP-TLS или EAP-FAST) и частой сменой ключей, всё равно остается возможность успешных "латеральных" беспроводных атак. И наиболее угрожающим типом подобных "атак в обход" являются атаки против неассоциированных клиентских хостов.
Общая идея данного подхода очень проста и заключается в следующем:
1. Находим неассоциированное клиентское устройство, либо используем затопление сети фреймами деассоциации или деаутентификации для его получения.
2. Эмулируем точку доступа специфически для подсоединения этого хоста.
3. Выдаем ему IP адрес, а также IP адреса фальшивых шлюза и DNS сервера через DHCP.
4. Атакуем устройство (возможные вектора атак описаны далее во второй части статьи).
5. Если это необходимо, и удаленный доступ к устройству был успешно получен, "отпускаем" хост обратно на "родную" беспроводную сеть, предварительно запустив на нем трояна.
В 2007-ом году все выпускаемые лаптопы и ноутбуки будут иметь встроенную поддержку Wi-Fi. Та же судьба вскоре ждет большинство, если не все наладонники и смартфоны. Да и сейчас очень многие клиентские устройства (вспомним Интел Центрино) имеют такую поддержку включенной и постоянно ищущей сеть для ассоциации, часто - без ведома их владельцев. Данный факт игнорируем большинством системных администраторов организаций и компаний, и даже профессионалы в сфере ИТ безопасности подчастую ищут исключительно несанкционированные точки доступа и ад-хок сети, не уделяя достаточное внимание этим "скучным" Probe Request фреймам от "потерянных" клиентов. Казалось бы, "отлов" таких клиентских хостов атакующими до невероятности прост. Но есть ряд практических ньюансов, которые необходимо знать кракеру или пентестеру для успешного осуществления подобного рода атак. Именно рассмотрению этих ньюансов и посвящена данная статья.
Для начала нам необходимо знать, согласно какому алгоритму клиентские устройства автоматически ищут сети для подсоединения. Будут ли они ассоциироваться с любой обнаруженной 802.11 сетью с достаточно мощным сигналом ? А если таких сетей несколько ? На чем будет основан их выбор ? Kaк насчет сетей с "закрытым" ESSID и сетей, защищенных с помощью WEP или WPA ? Ответы на эти вопросы зависят как от операционной системы клиентского хоста, так и от испольуемой им беспроводной аппаратной части, её драйверов и пользовательских настроек. Здесь мы рассмотрим две самые распространенные операционные системы под которыми работает большинство подобных устройств - Майкрософт Windows и MacOS X.
"Алгоритм беспроводной самонастройки" (АБС, Wireless Auto Configuration Algorithm) в Windows XP и Windows Server 2003.
Данный алгоритм оперирует с двумя списками 802.11 сетей - Списком Доступных Сетей (СДС) и Списком Предпочитаемых Сетей (СПС). СДС представляет из себя список сетей, ответивших на широковещательные Probe Request фреймы при последнем активном скане. СПС есть список сетей, к которым было установлено полноценное соединение в прошлом. Последние сети, с которыми было ассоциировано устройство, идут в данном списке первыми. Описание сети в обоих списках содержит её ESSID, канал и метод шифрования - "открытый текст", WEP или WPA. Итак, как же используются эти списки в процессе работы АБС ?
1. Клиентское устройство составляет СДС путем посылки широковещательных Probe Request фреймов с пустым полем ESSID по одному на каждый из используемых 802.11 каналов и параллельной обработки ответов на эти фреймы.
2. Если обнаруживаются сети, находящиеся в СПС, то происходит ассоциация с такими сетями в порядке их расположения в этом списке. То есть клиентское устройство ассоциируется с самой верхней сетью СПС, которая присутствует в СДС.
3. Если таких сетей не обнаруживается, или же успешной ассоциации с ними не произошло по причине различия в 802.11 стандартах или проблем аутентификации, АБС "заходит на второй круг", посылая Probe Request фреймы специфически для поиска сетей, перечисленных в СПС. На практике это означает, что данные фреймы посылаются на каналы СПС сетей и содержат их ESSID. При этом, отсылка этих фреймов от содержания СДС абсолютно не зависит. Смысл наличия "второго круга" АБС заключается в поиске сетей с "закрытым" ESSID.
4. Предположим, что подходящих Infrastructure сетей всё равно не найдено. Следующим этапом поиска является нахождение ад-хок сетей. Для этого проводится сопоставление ад-хок сетей СДС и СПС.
5. Если в СПС имеется хотя бы одна ад-хок сеть, но в СДС она не найдена, АБС устанавливает клиентское устройство в режим ад-хок и присваивает беспроводному интерфейсу IP адрес, принадлежащий к 169.254.0.0/16 диапазону (RFC 3330). Таким образом, хост становится первым узлом потенциальной новой ад-хок сети и алгоритм заканчивает свою работу.
6. Если же ад-хок сетей в СПС нет, то АБС проверяет флаг "Подсоединиться к Непредпочитаемым Сетям" ("Connect To Nonpreferred Networks"). Если этот флаг равен единице, то клиентское устройство будет пытаться ассоциироваться с каждой сетью СДС в порядке их очередности в списке. К сожалению для атакующих, по умолчанию данный флаг равен нулю.
7. Если вышеупомянутый флаг не включен пользователем, то беспроводная карточка "запарковывается" как клиент с установленным псевдослучайным 32-хзначным ESSID. В таком состоянии она функционирует 60 секунд, после чего алгоритм поиска сетей перезапускается. Те из читателей, кто занимался вардрайвингом, не раз встречали и без труда узнают такие "странные и длинные" Probe Request ESSID значения, время от времени обнаруживаемые Кисметом или другим пассивным 802.11 сканнером.
Таким образом, установка атакующим программной точки доступа с произвольным ESSID имеет мало шансов на успех даже при большой мощности её сигнала. "Мы пойдем другим путем."(С)
Атаки против АБС в Windows XP и Windows Server 2003.
В первую очередь рассмотрим очевидные слабости данного алгоритма. В первую очередь, во время "второго раунда" АБС (пункт 3 выше), клиентское устройство фактически раскрывает содержание СПС. Представим себе ситуацию, когда такой хост находится вне досягаемости его "родной" сети. Например, корпоративный лаптоп взят сотрудником на дом или в коммандировку (и используется в аэропорту, самолете, гостинице и так далее). Для обнаружившего такой лаптоп атакующего не составит особого труда определить первую сеть в СПС по ESSID посылаемых устройством Probe Request фреймов, и установить именно это значение ESSID на своей точке доступа. То же самое относится и к поиску ад-хок сетей СПС. Если первая сеть СПС защищена и требует WEP или WPA ключ для подключения, идем далее по списку и ищем в нем открытую сеть, включая ад-хок WLANы. Вероятность нахождения такой сети достаточно велика. К примеру, большинство Wi-Fi хотспотов используют методы защиты беспроводной передачи данных на более высоких уровнях OSI модели, обычно на седьмом (можно также вспомнить и NoCat шлюз, иногда используемый в сообществах любителей Wi-Fi). Подключение к таким сетям оставит описание "незащищенной" (на 2-ом уровне) сети в СПС, которым без проблем может воспользоваться атакующий. Или, ещё один пример. Два пользователя устанавливают ад-хок соединение на несколько минут для передачи единственного файла. Вероятность того, что они будут защищать подобное соединение используя WEP или WPA-PSK достаточно низка. И действительно, кто обнаружит и успеет атаковать это соединение в течении двух - трех минут, особенно если передаваемый файл не имеет никакой конфиденциальности? Однако, в СПС обоих устройств останется описание незащищенной ад-хок сети!
Подобное описание ведет ко второй слабости. При отсутствии такой ад-хок сети поблизости (крайне вероятный сценарий, учитывая то, что ад-хок соединения обычно ставятся на короткие промежутки времени и часто - с новым ESSID каждый раз), Windows клиент установится в постоянном режиме работы как ад-хок узел, ожидающий других клиентов (пункт 5 выше). Так почему бы не стать таким клиентом, взяв себе один из RFC 3330 адресов, и не провести широковещательный пинг или послать ARP запросы (или же просто "посниффать" эфир на предмет NetBIOS пакетов) для обнаружения IP адреса жертвы и проведения дальнейших атак ? Причём, для подобного подключения не требуется никакого взаимодействия со стороны пользователя. Оно является полностью автоматическим.
Наконец, при отсутствии незащищенных и ад-хок сетей в СПС, и включенного флага "Подсоединиться к Непредпочитаемым Сетям", наш алгоритм достигнет установки клиентской карточки в "режим ожидания" с посылкой Probe Request фреймов с длинным псевдослучайным ESSID (пункт 7 выше). Проблема в том, что эти "загадочные" ESSID значения являются вполне "рабочими". То есть, достаточно установить по соседству точку доступа с таким ESSID, и клиент благополучно на нее "клюнет", чтобы получить IP адрес через DHCP и подвергнуться дальнейшим атакам. Следует сказать, что данная проблема уже устранена в Longhorn, но до тотального перехода на эту операционную систему ещё далеко. А теперь самое интересное: так как сеть с длинным псевдослучайным ESSID отсутствует в СПС, подсоединение к такой сети не только не требует никакого взаимодействия со стороны атакуемого пользователя, но даже и не будет показано как существующее индикатором беспроводной связи Windows XP. Данный индикатор будет говорить, что устройство не ассоциировано с какой-либо Wi-Fi сетью, и только контрольная панель установки сетевых опций Windows покажет наличие соединения и присвоенного IP адреса. Чтобы охладить пыл беспроводных кракеров, следует упомянуть, что последние версии драйверов 802.11a/b/g карточек с Atheros чипсетом хоть и отсылают Probe Request фреймы с псевдослучайными ESSID, но не поддерживают автоматическое соединение с точками доступа, настроенными с такими ESSID значениями.
Что же делать атакующему если, как было сейчас упомянуто, автоматическая ассоциация используя псевдослучайные ESSID невозможна, а СПС не содержит незащищенных на втором уровне сетей ? Если сети, к которым подсоединялось атакуемое устройство, защищены с помощью неподбираемого по словарю WPA-PSK либо WPA-802.1х с использованием EAP-TLS, то на данный момент перспектив успешного взлома не видно. Если по крайней мере одна такая сеть была защищена с помощью WPA-802.1х с использованием EAP-TТLS или EAP-PEAP, то существует возможность проведения атак на данные протоколы согласно алгоритмам, описанным в презентации небезызвестной хак-группы Shmoo "Тhe Radical Realm of Radius, 802.1x, and You" (вы можете загрузить эту замечательную презентацию с . В то время как в задачу данной статьи не входит описание атак против EAP-TТLS и EAP-PEAP, предложенных в данной презентации, следует отметить, что рассматриваемый нами случай охоты (а вернее "рыбалки") на клиентские устройства идеален для проведения таких Shmoo атак, как PAP-PULL и PAP-PEEK. Почему? В первую очередь из-за того, что атакующему не мешает легитимная точка доступа и нет никакой нужды в проведении постоянных затоплений фреймами деассоциации или деаутентификации, поскольку атакуемое клиентское устройство по определению ни с чем не ассоциированно! Последний момент значительно облегчает проведение этих атак с Windows платформ. Впридачу, подобного рода атаки весьма "шумные", а в нашем случае атакуемые клиентские устройства находятся вне пределов досягаемости корпоративной системы обнаружения несанкционированного беспроводного доступа (wIDS). А везучий кракер может напороться и на клиентский хост, содержащий в СПС сеть, защищенную устаревшим EAP-MD5. Для успешного присоединения такого устройства достаточно поднять hostapd демон, приходящий с HostAP драйвером Jouni Malinen'a для карточек с Prism 2 - 3 чипсетом, при этом включив его ограниченную RADIUS-функциональность с автоматической аутентификацией суппликантов вне зависимости от присылаемых ими пакетов квитирования. Эта классическая атака против EAP-MD5 была детально описана нами в "Wi-Фу".
Говоря об устаревших механизмах защиты 802.11 сетей, невозможно не упомянуть избитый всеми WEP. И атаки на него могут быть применены и против отдельных клиентских устройств, сети в СПС которых "защищены" с помощью WEPа. Если все ад-хок сети в СПС имеют WEP в своих установках, то и произвольная ад-хок конфигурация с RFC 3330 адресом, как описано в пункте 5 выше, будет использовать WEP. Проблема в том, что такой ад-хок узел не будет "соблюдать тишину" - достаточно вспомнить хотя бы отсылку NetBIOS HELLO пакетов каждые 2 секунды. Соответственно, подобного рода трафик может быть успешно утилизирован для взлома WEP ключа различными методами, от простого перебора по словарю с помощью WepAttack до акселерации взлома путем иньекции пакетов используя Christopher Devine's aireplay (модифицированная атака ложной аутентификации либо интерактивная реиньекция пакетов, с помощью которых можно заставить одиночный ад-хок клиент послать зашифрованный ARP пакет для последующей ARP реиньекции).
Ещё более интересный пример - клиенты с псевдослучайным ESSID (пункт 7) и WEPом, которые "возникают" в тех случаях, когда все сети, перечисленные в СПС, являются защищенными. Сам факт того, что при наличии в этом списке и WPA-защищенных сетей, всё равно используется WEP - это уже уязвимость. Но, более того, так как установки подобной сети нигде не определены и "самоконфигурируются" без участия пользователя, атакующая точка доступа способна навязать таким клиентам небезопасный метод 802.11 аутентификации с использованием распределенного WEP ключа. Навязывая этот метод, кракер может послать клиентскому устройству challenge строку с известным текстом и получить обратно её же, заXORенную с частью RC4 потока. Таким образом, заXORив полученное с первоначальным текстом, атакующий узнает 144 байта RC4 потока для заданного вектора инициализации (IV). У этой атаки много возможных применений. В частности:
* можно посылать всё новые и новые challenge запросы, пока не откроется поток RC4 шифра для всех векторов инициализации 24-битного WEP IV пространства. Это громоздко и может занять значительное количество времени
* можно атаковать полученный ответ перебором по словарю испольуя WepAttack и сходные утилиты
* можно использовать известные 144 байта потока для реиньекции пакетов к клиентскому устройству с помощью старого доброго WepWedgie Антона Рэйджера. Удачная реиньекция заставит атакуемый хост послать зашифрованный ARP пакет, который легко перехватить и использовать с aireplay.
В любом из вышеперечисленных случаев, одиночное клиентское устройство требующее соединение, защищенное WEPом, трудно назвать неуязвимым.
В следующей части статьи мы обсудим атаки на клиентские Wi-Fi устройства, работающие под МacOS Х, а также имеющиеся Linux - имплементации, дальнейшие возможности и методы защиты от подобных атак.
Пришло время поставить точку над "i" и рассмотреть оставшиеся аспекты атак на клиентские 802.11 устройства. Но сначала - два небольших лирических отступления. Первое: в оригинале действительно "нормальные герои", Акелла промахнулся, но название статьи менять уже поздно И второе: в промежутке между статьями работал я в другом городе, и попался мне под руку клиентский Acer'овский лаптоп под Windows XP Professional SP2, который надо было настроить и подчистить от разного spyware. Поглядел я на настройки его встроенной miniPCI 802.11 карточки и ужаснулся: было выставлен флаг "Подсоединиться к Непредпочитаемым Сетям", и дополнительно добавлено "Подсоединиться к Сети с Наибольшей Силой Сигнала". При этом владелица лаптопа, работающая в отделе по продажам, даже и не подозревала о наличии встроенной беспроводной карточки и клялась, что в данные настройки не лазила и ничего там не меняла (чему я охотно верю). Wi-Fi сети не используются ни в офисе, ни дома у данной сотрудницы. Кто мог поменять настройки по умолчанию для Wi-Fi карточки упомянутого лаптопа - неизвестно (возможно, продавшая его компания), да и не суть важно. Важно то, что подобные случаи и устройства - существуют. И большинство консультантов по безопасности, не говоря уже о системных администраторах, скорее всего проглядели бы эту очень серьезную проблему конфигурации, которую не обнаружит ни один существующий на данный момент сканер проверки уязвимостей и уровня "запатченности".
Вернемся же к описанию алгоритмов выбора точки доступа неассоциированными клиентскими устройствами. Как было справедливо замечено в комментариях к первой части статьи, Линукс - клиенты весьма неразборчивы в соединениях с точками доступа и в большинстве случаев готовы ассоциироваться с любой близлежащей точкой с максимальной силой сигнала. При этом, как было замечено нами еще года три назад, даже со старыми Hermes II чипсет карточками нет никакой необходимости прописывать номер канала с помощью команды iwconfig. С ESSID несколько сложнее, и многое зависит от установок файлов конфигурации беспроводного клиента. В некоторых случаях, при подьеме 802.11 интерфейса с помощью команды iwconfig [interface] up, ESSID оптимальной точки доступа будет приниматься автоматически, но расчитывать на это атакующему в целом не стоит. Более рационально прослушать эфир на предмет посылаемых Probe Request фреймов и принять ESSID, указанное в них. Probe Request фреймы отправляются всеми клиентскими устройствами под Линукс, к примеру Cisco Aironet карточки посылали их даже в режиме мониторинга (RFMON) под старыми ядрами до 2.4.14 версии. Данный баг в настоящее время устранен. Запущенная пользователем или автоматической утилитой (например, APhunter или APradar) команда iwlist [interface] scanning под Линукс форсирует посылку Probe Requests. В то время как "сассоциировать" клиентское устройство под Линукс несложно, на более высоких уровнях OSI модели атакующего могут ждать сюрпризы. А именно, конфигурация беспроводного интерфейса под Линукс глубоко индивидуальна и зависит от дистрибутива системы, его версии и настройки опций файлов конфигурации интерфейса пользователем. В отличие от Windows, наличие DHCP клиента на таком интерфейсе маловероятно, и даже статический IP адрес может быть неустановлен в расчете на его прописывание пользователем при подключении к беспроводной сети используя команду iwconfig. Безусловно, можно нарваться на устройство, на котором пользователем запущена какая-нибудь утилита для автоматического нахождения и подключения к Wi-Fi сетям, скажем APHopper . Однако вероятность такого случая мягко скажем невелика. Если на беспроводном интерфейсе прописан статический IP адрес, атакующий может использовать перебор адресов с помощью ARP запросов для его нахождения, используя Ettercap, THC-wardrive и прочие подобные утилиты. Разумеется, 192.168.0.0./16 - хороший выбор диапазона адресов для начального перебора. Следует также принимать во внимание, что беспроводное устройство под Линуксом может быть изначально настроено не как клиент, а как точка доступа, к примеру при использовании драйверов HostAP (ESSID по умолчанию - "test"), madwifi или Prism54g. Данные случаи только упрощают задачу атакующего, так как ему не требуется обладать возможностями точки доступа на устройстве, которое он пытается подсоединить.
Несмотря на непрерывное распространение Линукса как операционной системы мобильных устройств, второй по частоте встречаемости после Windows операционкой беспроводных клиентов всё же является MacOS X. Рассмотрим же, как ведут себя эти клиенты в неассоциированном состоянии, и чем их поведение отличается от поведения устройств под Майкрософт Windows, рассмотренного в первой части статьи.
Алгоритм выбора беспроводных сетей в MacOS X и атаки против него
Несмотря на непрерывное распространение Линукса как операционной системы мобильных устройств, второй по частоте встречаемости после Windows операционкой беспроводных клиентов всё же является MacOS X. Рассмотрим же, как ведут себя эти клиенты в неассоциированном состоянии, и чем их поведение отличается от поведения устройств под Майкрософт Windows, рассмотренного в первой части статьи. Для начала нам необходимо знать, где хранится список предпочитаемых Wi-Fi сетей под MacOS X. Данный список представляет собой XML файл, обычно /localhost/System/Library/DTDs/PropertyList.dtd. До версии MacOS X 10.3.3, списка предпочитаемых/доверяемых сетей не существовало, однако после открытия в 2003-ем году серьезной клиентской уязвимости, данный список был создан для её устранения. Сама по себе, эта уязвимость достаточно знаменательна и сводится к тому, что подсоединившийся к точке доступа атакующего MacOS X клиент принимает через DHCP не только IP адреса себя, шлюза и DNS сервера, но и параметры полностью доверяемого фальшивого LDAP или NetInfo сервера, после чего становится возможным залогиниться на атакуемое устройство с uid 0 и любым именем пользователя. Следует отметить, что конфигурация беспроводных MacOS X хостов позволяет больший выбор опций по сравнению с Windows, а именно "всегда ассоциироваться с указанной сетью", "соединяться с последней ассоциированной сетью" и "соединяться с незащищенной сетью с наиболее сильным сигналом". Несмотря на кажущуюся относительную безопасность первых двух опций, они легко обходятся атакующим.
Итак, как же работает сам алгоритм выбора? В отличии от Windows, он задействуется не каждые 60 секунд, а только когда логинится пользователь или "просыпается" клиентский хост. Поиск начинается с посылки Probe Request фрейма с ESSID последней ассоциированной сети и идет далее вниз по списку доверяемых сетей. Если ни одной из доверямых/предпочитаемых сетей не найдено, то перед пользователем автоматически открывается диалог, сообщающий об этом и предлагающий подсоединиться к сети с максимальной силой сигнала, опционально запоминая эту сетку как предпочитаемую. Если пользователь отказывается, то клиентские устройства AirPort, но не более новые AirPort Ехtreme, "запарковываются" сo статическим или динамическим псевдослучайным значением ESSID и установленным WEPом. AirPort Ехtreme карточки не генерируют никакого 802.11 трафика, если скан на наличие доступных сетей не запрошен пользователем. Выбор между статическим и динамическим ESSID у AirPort зависит от того, чем был вызван изначальный скан на наличие предпочитаемых сетей. Если скан происходит после загрузки или "просыпания" устройства - значение ESSID статическое (ака "dummy"). Если скан инициирован логином пользователя - значение ESSID динамическое.
Слабости данного алгоритма очевидны. Во первых, также как и алгоритм беспроводной самонастройки Windows, Probe Request фреймы выдают список доверяемых сетей, каждая из которых может быть легко эмулирована атакующим. Во вторых, атакующий может принять значение ESSID "запаркованной" AirPort карточки и ассоциировать клиента к себе. Устанавливаемый автоматически WEP такой карточки не создает никаких проблем для беспроводных кракеров, так как всегда используется аппаратно прошитое 40-битное значение WEP ключа, равное 0x0102030405. Интересно, что даже при использовании (а вернее навязывании атакующим) аутентификации по общему WEP ключу (Shared Key Authentication), соединение с клиентом происходит без каких-либо препятствий и уведомления об этом пользователя. Тем не менее, индикатор меню AirPort всё-таки загорается, и при щелчке на него мышью показывает соединение с 802.11 сетью. Кроме того, так как сканирование не происходит через регулярные интервалы, для эмуляции сетей из заветного XML списка атакующий должен поймать удачный момент времени. Таким образом, атаковать MacOS X клиенты сложнее, чем их "беспроводных собратьев" под Windows. Тем не менее, подобные успешные атаки весьма и весьма возможны, особенно в случае использования старых 802.11b AirPort устройств.
Атаки против специфических уязвимостей клиентских 802.11 устройств.
Пришло время перейти от атак на общие алгоритмы поиска сетей для ассоциации к атакам на отдельно взятые имплементации данных алгоритмов, а вернее - их баги. Для начала мы рассмотрим так называемый "перехват ассоциации". Речь идет о том, что "прошивка" (firmware) ряда точек доступа и клиенстких карточек имеет логическую ошибку в дизайне, ведущую к предпочтительной ассоциации "дефективной" карточки с "дефективной" точкой доступа вне зависимости от выставленных на клиентской карточке значений ESSID и 802.11 канала. Сама ошибка сводится к некорректно выставленному значению единственного регистра в прошивке для беспроводных чипсетов Marvell Libertas и ADMtek ADM8638 для точек доступа, а также Hermes I/II, равно как и Prism 2/2.5 чипсетов для клиентских карточек. В результате получается следующая "летальная комбинация":
- "перехватывающая" точка доступа посылает Probe Response фреймы в ответ на любые Probe Requests от клиентов, даже если они (Probe Requests) не содержат широковещательное (ANY) или установленное на точке доступа значение ESSID. Такое поведение точки доступа ненормально.
- ассоциация уязвимого клиентского устройства инициируется первым полученным Probe Response фреймом от любой точки доступа, вне зависимости от соответствия значений ESSID в изначально посланном устройством Probe Request'е и полученном в ответ Probe Response. Такое поведение клиентской карточки ещё более абнормально и, очевидно, объясняется тем, что клиентское устройство смотрит только на MAC адрес хоста назначения в получаемом Probe Response фрейме и, удостоверившись в том, что это его MAC, начинает ассоциацию. Поле ESSID в Probe Response при этом не проверяется.
Таким образом, используя описанную уязвимость, атакующий может ассоциировать хосты к своей точке доступа даже в присутствии легитимной беспроводной сети (не забывайте про DoS через затопление фреймами деассоциации/деаутентикации!). Достаточно, чтобы первый полученный уязвимым клиентским устройством Probe Responsе фрейм был послан именно атакующим. Высокую вероятность этого можно достичь с помощью большей мощности сигнала точки доступа кракера по сравнению с точкой доступа атакуемой сети. Добиться этого несложно: в то время, как легально установленные точки доступа ограничены по мощности выходящего сигнала законодательными регуляциями (100 мВ для сетей топологии "точка-многоточка" в России), кракер ограничен только мощностью своего "железа", так как всё равно нарушает закон. Здесь можно вспомнить и дешевые в изготовлении самодельные "кантенны" с большим коэффициентом усиления выходящего сигнала (даже и не говоря о промышленных антеннах и усилителях в продаже), и коммерчески доступные беспроводные карточки значительной мощности, работающие под HostAP или madwifi Линукс драйверами. Примерами последних могут являться reliawave карточки, предлагаемые Демарктехом, скажем
Разумеется, для использования уязвимости "перехвата ассоциации", атакующему нет нужды обладать одной из "дефективных" точек доступа - достаточно всего лишь быть способным посылать Probe Response фреймы с MAC адресом уязвимого клиентского устройства (ESSID не имеет значения!). Далее в статье будут рассмотрены утилиты, позволяющие это делать без особого труда. Что же касается "дефективных" устройств, к таковым относятся например "Netgear WGR614 v4 wireless router", точка доступа "Linksys WAP11 v2.8", некоторые точки доступа производства D-Link и многие клиентские карточки с Hermes I/II и Prism 2/2.5 чипсетами и старыми, необновленными версиями прошивки. Говоря же об атаках на неассоциированные клиентские устройства в отсутствии легитимных сетей, вышеописанная уязвимость устраняет необходимость эмуляции сетей из списка доверяемых - любой ESSID на любом канале сделает свое темное дело, и не надо дожидаться посылки клиентом Probe Request фреймов и смотреть на их содержание.
Безусловно, этой уязвимости "перехвата ассоциации" уже два года, и многие из тогда уязвимых устройств сейчас работают под обновленной прошивкой. Тем не менее, её не стоит сбрасывать со счетов. Во первых, как часто пользователи меняют прошивку беспроводных карточек? "Если работает, зачем обновлять?"(С) Это не операционная система и не видимое для пользователя популярное сетевое приложение или сервис. Во вторых, не все обязательно пользуются 802.11g стандартом и клиентскими устройствами с более новыми чипсетами, такими как Atheros, Realtek и Рrism54g. Да и Hermes I/II и Prism 2/2.5 карточки в связи с новыми стандартами и чипсетами сейчас значительно подешевели и более доступны. Популярна ли до сих пор Lucent ORiNOCO Silver PCMCIA карточка ? Да. Уязвима ? Аналогично. В третьих, само наличие данной уязвимости даже и не рассматривалось как проблема безопасности. Она была обнаружена как сбой на 802.11 сетях работниками беспроводного провайдера, и именно в этом качестве доложена на ISP-Wireless и broadbandreports.com форумы, но не на Bugtraq, Packetstorm, в CERT и так далее. Таким образом, сообществу специалистов по сетевой безопасности данная проблема весьма малоизвестна. Но есть и другая подобная, и ещё менее известная дыра.
Данные о ней были опубликованы только на Sourceforge orinoco-devel форуме ещё в 2003-ем году, тем не менее они не получили огласки, не были восприняты как уязвимость, и для многих Ориноко карточек (Hermes I/II чипсет) "воз и ныне там". А использовать этот вариант "перехвата ассоциации" предельно просто. Если атакующий поднимает ад-хок сеть с таким же ESSID как и у легитимной точки доступа, клиентские устройства предпочитают ассоциироваться не с этой точкой доступа, а с хостом атакующего. Впервые эта уязвимость была обнаружена как раз на небезызвестной Lucent ORiNOCO Silver карточке (версия прошивки 8.72) под Линуксом (драйвер orinoco_cs 0.13b). Однако, так как та же самая проблема существует с подобными клиентскими карточками и под Windows, логично было бы предположить что её источником, как и в предыдущем случае, является ошибка производителя в установках прошивки устройства. Интересно, что последующая попытка заставить клиентскую карточку присоединиться именно к точке доступа (iwconfig eth1 mode managed) не вела к полноценному соединиению, то есть помимо "перехвата ассоциации" имеется ещё и потенциальная атака по отказу в обслуживании. Так как данную проблему никто детально не изучал, не исключено, что есть и другие типы клиентских 802.11 устройств, уязвимых к данной элементарной атаке. Мало того, учитывая общие корни происхождения 802.11 чипсетов Hermes I/II, Prism 2-2.5, Symbol и Cisco Aironet, это было бы весьма неудивительным и требует скорейшего тестирования.
Вы можете конечно сказать, что всё вышесказанное имеет отношение только к устаревшим устройствам и старым версиям их прошивки. Давайте же посмотрим на набирающее огромную популярность современное клиентское устройство, а именно - Intel Centrino. Вернее - Intel Pro Wireless 2200B/G чипсет и его прошивку. Начнем с того, что вместо выставления описанных в прошлой части статьи длинных псевдослучайных значений ESSID, Intel Centrino использует свое краткое значение по умолчанию, a именно "WXYZ" (также "Sony 802.11 Default SSID" для Sony Intel Centrino). Centrino в данном случае не одинок, к примеру Netgear WG511 выставляет ESSID "Netgear". Это безусловно облегчает задачу атакующего, но само по себе не наврядли является уязвимостью в полном смысле этого слова. А реальная уязвимость была опубликована на Bugtraq в прошлом месяце и заключается в том, что при выставленном на клиентском устройстве WEPe, кракер может заставить уязвимый хост соединиться с атакующей точкой доступа без испольсования WEP. Делается это следующим образом:
1. Устанавливается фальшивая точка доступа без WEPа с ESSID, посылаемом в Probe Request фреймах Intel Centrino устройства.
2. После получения Probe Response фрейма, указывающего, что WEP не используется, уязвимое устройство тем не менее продолжает процесс аутентификации.
3. Несмотря на то, что клиентское устройство по прежнему требует использовать WEP в посылаемых фреймах запроса аутентикации и ассоциации, точка доступа атакующего "заставляет" клиента "отказаться" от использования WEP просто посылая ему фреймы ответа аутентикации и ассоциации, говорящие о том, что WEP точкой доступа не используется.
Вуаля, атакуемое устройство игнорирует прописанный на нем WEP и соединение с точкой доступа атакующего благополучно установлено. Данная уязвимость получила название "WEP-Client-Communication-Dumbdown", что можно литературно перевести как "сброс WEPа при коммуникации с клиентом". В третьей и последней части статьи мы рассмотрим утилиты для проведения описанных в статье атак а также методы защиты ваших клиентских устройств от подобных нападений.
В заключительной части данной статьи мы рассмотрим имеющиеся утилиты для атак на клиентские 802.11 устройства, их особенности, преимущества и недостатки. В первую очередь, хотелось бы принести извинения читателям за задержку с выходом третьей части статьи, связанную с деловыми разъездами. С другой стороны, была возможность дополнительно оттестировать описываемые программы в полевых условиях. В процессе тестирования был отловлен мелкий, но назойливый баг в Karma tools, который, соответственно, будет упомянут ниже.
Итак, начнем с требований к утилитам для атак на 802.11 клиенты. Знание этих требований полезно не только для правильного выбора и понимания работы подобных программ, но и для их совершенствования и переделки заинтересованными энтузиастами. В первую очередь, утилиты для таких атак должны проводить детальную диссекцию и сортировку Probe Request фреймов для того, чтобы узнать к каким сетям хотят подсоединиться обнаруженные клиентские устройства. Под сортировкой фреймов прежде всего подразумевается отражение утилитой последовательности расположения желаемых сетей в СПС клиента. Ответом на полученные Probe Requests должна служить генерация произвольных Probe Response фреймов, содержащих в себе значения ESSID, востребованные атакуемыми клиентами. Фактически, речь идет о преднамеренной эмуляции поведения "дефективных" точек доступа с Marvell Libertas и ADMtek ADM8638 чипсетами, упомянутыx в предыдущей части статьи при обсуждении атак перехвата соединения. Однако, Probe Request фреймы не предоставляют атакующему информацию о мерах защиты, используемых сетями в СПС. Следовательно, наша утилита также должна анализировать фреймы запроса аутентификации, отправляемые клиентскими устройствами после получения ими Probe Response фреймов от точки доступа (в нашем случае - эмулируемой атакующим для присоединения к себе клиента).
Что если клиент, посылающий Probe Request фреймы, уже ассоциирован к беспроводной сети ? Подобного рода поведение не противоречит 802.11 стандарту и может быть легко воспроизведено пользователем посредством запуска поиска доступных сетей в конфигурации беспроводного устройства под Windows или команды iwlist [interface] scanning под Линуксом будучи уже подсоединенным к сети. Мало того, некоторые клиентские устройства продолжают автоматически посылать регулярные Probe Requests и после ассоциации. Такое поведение типично для PCMCIA Cisco Aironet карточек, отправляющих Probe Requests не только в ассоциированном состоянии, но и сразу же после распознания карточки системой без предварительного поднятия беспроводного интерфейса с помощью таких команд, как ip или ifconfig. Интересно отметить, что в старых версиях Линукс ядра до 2.4.14, клиентские устройства Cisco Aironet посылали регулярные Probe Request фреймы даже в режиме мониторинга (RFMON), предоставляя тем самым уникальную возможность обнаружения атакующих, пассивно прослушивающих 802.11 сети. Помимо Cisco Aironet, отправление Probe Requests в ассоциированном состоянии было замечено за клиентскими устройствами на базе чипов Центрино, работающими под Windows, но не под Линуксом. Таким образом, наша утилита для беспроводных атак против клиентов должна быть способна к распознанию существующих ассоциаций клиент <=> 802.11 сеть. Тогда, при обнаружении ассоциации, атакующий сможет ее оборвать посредством атаки по отказу в обслуживании для последующего "перетаскивания" клиента на себя. Классическими примерами подобных DoS атак являются посылка фреймов деаутентификации, деассоциации или некорректных фреймов аутентификации а ля fata_jack.
Предположим, вы просканировали эфир на предмет ищущих ассоциации устройств и обнаружили сразу несколько подобных клиентов, "желающих" различные ESSID для присоединения. Учитывая особенности работы алгоритма поиска беспроводных сетей, это наиболее часто встречающаяся на практике ситуация. Разные клиентские устройства присоединялись к различным сетям в прошлом, какие-то из устройств образовали ад-хок узлы и какие-то - запарковались с длинным псевдослучайным значением ESSID. Можно ли "подцепить" множество подобных клиентов одновременно ? Безусловно, если создать такое же множество виртуальных точек доступа по ходу обнаружения ESSID, требуемых этими клиентами. А для тех клиентов, которые отправляют Probe Request фреймы с широковещательным ESSID (ANY), должна быть виртуальная точка доступа, предоставляющая им свой ESSID. Таким образом, атакующий может установить единовременное соединение с большим количеством уязвимых клиентов для проведения массовых сканов на порты и уязвимости, а также массового фишинга паролей.
Говоря о последнем, эффективная утилита для атак на клиентские устройства должна предоставлять разнообразные фальшивые сервисы для "пойманных" клиентов. В первую очередь, речь идет о фальшивых DHCP и DNS серверах для выдачи IP адреса жертве и перенаправления её трафика через хост хакера. Идеальным будет являться "подсаживание" всех клиентов на один диапазон IP адресов. Не лишними также будут являться такие сервисы, как веб (с фальшивой страничкой для входа, например, на mail.ru, или же размещенным на такой страничке зловредным скриптом для атаки на уязвимые браузеры), SMTP, POP3, IMAP, FTP... здесь возможности атакующего ограничены только его воображением. Разумеется, атакующая утилита должна предоставлять возможность наблюдения за пакетами, посылаемыми жертвами, и записи обнаруженных в этих пакетах паролей и другой полезной информации. Теперь же, вооружившись вышеперечисленным как базой для дальнейших экспериментов, посмотрим на то, что имеется на практике для общественного пользования.
Безусловно, все описанные в цикле статей атаки на клиентские устройства можно осуществлять и вручную, путем поимки посылаемых Probe Request фреймов и настраивания программной точки доступа с подходящим ESSID для подсоединения клиента. Для рассмотрения характеристик присутствующих в зоне приема клиентов достаточно использовать Kismet, Aircrack airodump либо же просто Ethereal/tcpdump. Если клиент успешно не ассоциируется, смотрим на фреймы запроса аутентификации в Ethereal/tcpdump и определяем, какой метод аутентификации необходим данному клиенту. Далее переходим на следующую в СПС сеть не требующую аутентификации вне открытого метода (по ESSID) либо, за неимением таковой, ломаем запрашиваемый клиентом способ аутентификации (если возможно). Потом поднимаем заранее подготовленные фальшивые DHCP, DNS и прочие сервисы и, при необходимости, включаем IP forwarding на атакующем хосте. Однако, такой подход громоздок, и явно требует автоматизации. Кроме того, он ограничен возможностью единовременной атаки только на одно клиентское устройство.
Исторически, первой утилитой, предоставляющей возможность автоконфигурации програмной точки доступа для присоединения обнаруженных клиентских устройств был Hotspotter от Макса Мозера, известного также как автора 802.11 сниффера Wellenreiter, до сих пор популярного у владельцев КПК с установленным Линуксом из-за прекрасного графического интерфейса. Принцип работы Hotspotterа очень прост - он сравнивает желаемые клиентами ESSID со списком под названием HOTSPOTLIST, в котором находятся ESSID распространенных хотспотов. Разумеется, вы можете дополнить этот список своими значениями распространенных ESSID. Если ESSID клиента найден в списке, то беспроводной интерфейс конфигурируется как точка доступа с этим ESSID значением. Hotspotter имеет флаги -е и -r для запуска команд перед и после входа интерфейса в режим точки доступа, и работает с карточками чипсетов Prism 2-2.5 (драйвер HostAP) и Connexant (драйвер Prism54g). В связи с наличием более продвинутых утилит для атак на клиентские устройства, в настоящее время Hotspotter представляет главным образом исторический интерес. Кроме того, он пока является единственной утилитой подобного рода, входящей в популярный, собранный уже упомянутым Максом Мозером, Security Auditor Линукс дистрибутив на живом CD для не имеющих под рукой эту операционную систему и не желающих её инсталлировать.
Затем группа Shmoo (спасибо им за Airsnort и RFMON заплату для Orinoco драйверов!) выпустила небезызвестный Airsnarf (http://airsnarf.shmoo.com/). Airsnarf - это всего лишь шеллскрипт, конфигурируемый посредством файла ./cfg/airsnarf.cfg и автоматизирующий запуск фальшивых сервисов для пиратской точки доступа под HostAP на Prism 2-2.5 карточках. Для его работы необходимо иметь проинсталлированные Apache, iptables, DHCP сервер, sendmail и Net::DNS Perl модуль. Соответственно, отконфигурированный и запущенный Airsnarf будет выставлять атакующую станцию как шлюз для отловленных клиентских устройств с sendmail в качестве прокси для сбора отправляемой почты и веб прокси со страничкой для фишинга паролей. Разумеется, атакующему прийдется поработать над своим HTML кодом для того, чтобы сделать эту страничку приемлемой для условий конкретной атаки. Также как и Hotspotter, Airsnarf входит в Security Auditor и, в совокупности, они уже предоставляют из себя определенную угрозу для незащищенных клиентских устройств (не забудьте про -е флаг!). Тем не менее, подобного рода комбинации не способны "отлавливать" клиенты с длинными псевдослучайными ESSID (в особенности при наличии непечатных символов в их значениях), равно как и клиенты в ад-хок режиме. Кроме того, хакер, вооруженный комбинацией Hotspotter/Airsnarf не может создавать виртуальных точек доступа для одномоментного подсоединения клиентов, требующих различные ESSID значения.
По сравнению с Hotspotter, ProbeMapper от ThinkSECURE представляет значительный шаг вперед. ProbeMapper проводит детальный анализ статуса обнаруживаемых клиентов, включая диссекцию фреймов запроса аутентификации:
Как видим, данный клиент неассоциирован и в прошлом подключался к двум сетям, одна из которых (t-mobile) - сеть распространенных коммерческих хотспотов, которая на нижних уровнях OSI ничем не защищена. Для переманивания к себе этого конкретного клиента запусакем probemapper -i eth1 -t . Probemapper спрашивает "Would you like to act as an AP for ssid t-mobile [y|N]:". Это именно то, что нам нужно, поэтому отвечаем "y". Вуаля, клиент подсоединен. Если же нам не подходит первый по списку ESSID, отвечаем N и движемся далее, покуда не найдем подходящий. К сожалению, Probemapper не запускает каких-либо фальшивых сервисов, посему атакующий должен использовать -е флаг для запуска заранее отконфигурированного аirsnarf после выхода в режим точки доступа для достижения максимального эффекта от подсоединения клиентского устройства.
В то время как Probemapper очень прост и удобен в использовании, у него есть два недостатка. Во первых, он не создает множества виртуальных точек доступа для подсоединения клиентов с разными ESSID. Во вторых, в настоящий момент Probemapper работает только под карточками с Connexant (Prism54g) чипсетом, и число таких PCMCIA устройств достаточно ограничено. Из распространенных Connexant PCMCIA карточек, мы можем назвать разве что 32-bit Cardbus Senao NL-3054CB, Netgear WG511, Zyxel G-100 и G-110, Zcom XG-300/302 и Sitecom WL-100. Гораздо более Connexant чипсет распространен среди клиентских 802.11b/g USB устройств, но у нас не было физической возможности протестировать совместимость таких клиентов с Probemapper. А вышеуказанный пример был получен используя PCMCIA карточку Senao NL-3054CB.
Но не стоит переживать! Karma tools не только работают под наиболее распространенным и весьма удобным для атакующего Atheros чипсетом, но и наиболее близки к удовлетворению перечисленных в начале статьи критериев для утилит, предназначенных для атак на 802.11 клиенты. В настоящий момент Karma tools работают под madwifi, но не более новыми madwifi-ng драйверами. Для создания виртуальных точек доступа на каждый обнаруженный "бесхозный" клиент, драйвера надо пропатчить, для чего лучше использовать использованную создателями программы версию madwifi:
arhontus# svn checkout -r '{20060124}' madwifi
arhontus# patch -p0 < madwifi-KARMA-20060124.diff
arhontus# cd madwifi && make && make install
Базовая конфигурация Karma tools осуществляется при помощи файла еtc/karma.xml, по умолчанию содержащего следующее:
Атакующий скорее всего изменит ESSID с кarma на нечто менее подозрительное. По перечисленным модулям видно, какие фальшивые сервисы автоматически запускает Karma tools. EXAMPLE-WEB-EXPLOIT - это всего лишь пустая веб-страничка, которая может быть заменена страничкой с логином для фишинга или страничкой со зловредным скриптом для атаки на клиентские браузеры. Безусловно, вы всегда можете захашить ненужный модуль, или же использовать заплату для Samba сервера (samba.patch) чтобы создать фальшивый совместно используемый ресурс на своем хосте, на который будут автоматически направляться жертвы. Сгенерируем же немного негативной кармы:
1. ставим интерфейс в RFMON: bin/monitor-mode.sh ath0
2. запускаем бинарник в src для нахождения клиентских устройств: src/karma ath0 (честно говоря, в этом плане нам гораздо больше нравится airodump ath0 дающий более четкое описание найденных клиентов, равно как и сетей)
3. убедившись, что место рыбное, запускаем и саму атакующую утилиту из bin: bin/karma etc/karma.xml. В идеале должно произойти примерно следующее:
Starting KARMA...
Loading config file etc/karma.xml
ACCESS-POINT is running
DNS-SERVER is running
DHCP-SERVER is running
AccessPoint: 00:04:e2:80:8c:ca associated with SSID arhont-test
POP3-SERVER is running
FTP-SERVER is running
[2006-03-29 21:25:37] INFO WEBrick 1.3.1
[2006-03-29 21:25:37] INFO ruby 1.8.4 (2005-12-24) [i686-linux]
[2006-03-29 21:25:37] INFO WEBrick::HTTPServer#start: pid=26149 port=80
HTTP-SERVER is running
CONTROLLER-SERVLET is running
EXAMPLE-WEB-EXPLOIT is running
Delivering judicious KARMA, hit Control-C to quit.
DNS: 169.254.0.254.32776: 9720 IN::A www.google.com
DNS: 169.254.0.254.32776: 64608 IN::PTR 7.133.254.169.in-addr.arpa
DNS: 169.254.0.254.32776: 3513 IN::AAAA www.arhont.com
DNS: 169.254.0.254.32776: 6277 IN::AAAA www.arhont.com.dmz.arhont.com
DNS: 169.254.0.254.32776: 58987 IN::AAAA www.arhont.com.arhont.com
DNS: 169.254.0.254.32776: 48417 IN::A www.arhont.com
169.254.0.254 - - [29/Mar/2006:21:27:07 BST] "GET /example HTTP/1.0"
301 48 - -> /example
DNS: 169.254.0.254.32776: 18218 IN::AAAA www.arhont.com
DNS: 169.254.0.254.32776: 26478 IN::AAAA www.arhont.com.dmz.arhont.com
DNS: 169.254.0.254.32776: 27220 IN::AAAA www.arhont.com.arhont.com
DNS: 169.254.0.254.32776: 14906 IN::A www.arhont.com
169.254.0.254 - - [29/Mar/2006:21:28:01 BST] "GET / HTTP/1.0" 301 30
FTP: 169.254.0.254 test/password
AccessPoint: 00:04:e2:80:9а:23 associated with SSID t-mobile
AccessPoint: 00:04:e2:74:22:c5 associated with SSID аll your base
В консоли, в которой была запущена утилита, мы видим MAC адреса пойманных клиентов (e.g. "AccessPoint: 00:04:e2:74:22:c5 associated with SSID аll your base"), их запросы на Google и наш вебсайт (не удивляйтесь - это не популярность, а тестовая лаборатория :-) перенаправляемые на вебсервер атакующего, а также зафиксированный логин на FTP (test/password). Kaк видите, клиенты с запущенным dhcpcd автоматически получают IP адреса из RFC 3033 диапазона, и атакующий интерфейс (по умолчанию IP 169.254.133.7) в качестве шлюза.
Однако на практике всё может быть не так гладко. Karma tools пока ещё достаточно "сырые", и не удивляйтесь, если при запуске утилиты вы получите ошибки типа "Broken pipe" или "undefined method" - просто перезапустите кarma несколько раз, пока всё не заработает без подобного рода ошибок. Но есть упомянутый в самом начале статьи баг, от которого не избавиться перезапуском. Дело в том, что Karma tools писались и тестировались на b/g, а не a/b/g карточках, в то время как многие из вас безусловно обладают клиентскими устройствами, поддерживающими все 3 стандарта. Так вот, на подобных устройствах при запуске Karma tools выдается следующая ошибка:
ACCESS-POINT is running
Error for wireless request "Set Frequency" (8B04) :
SET failed on device ath0 ; Invalid argument.
Она свидетельствует о том, что ваша точка доступа встала на 802.11а частоту (при этом все фальшивые сервисы могу быть вполне благополучно запущены и утилита ожидает жертв). И действительно,
Стандартные команды iwconfig freq и iwconfig channel здесь не помогут, взамен используйте iwpriv mode 2. Убедитесь в том, что точка доступа вернулась на 802.11b/g частоту:
Затем установите максимальные мощность и чувствительность с помощью iwconfig txpower ХХХmW и iwconfig sens Х/Х (обычно 3/3) и перезапускайте bin/karma etc/karma.xml пока утилита не запустится без ошибок. Убедитесь, что все нужные фальшивые сервисы запущены:
Следует сказать, что Karma tools можно использовать и под HostAP драйверами на карточках с Prism 2-2.5 чипсетом (не забудьте сменить ath0 на wlan0 в karma.xml). Но тогда функциональность утилиты будет неполной в связи с невозможностью создавать виртуальные точки доступа на таких карточках и подключать клиенты с разными ESSID одновременно. Дело в том, что более старые 16-ти битные клиентские устройства обрабатывают Probe Request фреймы в прошивке устройства, а не на уровне его драйверов. И мы не можем заставить их параллельно использовать множественные значения ESSID из получаемых Probe Request фреймов так, как мы делаем это на более современных Atheros чипсет карточках при помощи madwifi.patch. Таким образом, использование Prism 2-2.5 устройств и HostAP для запуска Karma tools не рекоммендуется.
И ещё несколько наблюдений. Скидывать клиентские устройства с сети, к которой они подсоединены, на хост с запущенными Karma tools вполне возможно. Для этого, так как мы проводим тестирование на Atheros карточке, легко использовать затопление канала, на котором сидит подключенный клиент, фреймами деаутентификации с помощью запущенного в соседней консоли aireplay из Aircrack (aireplay -a -c -0 <количество фреймов деаутентификации> ath0). Также, с помощью Karma tools нам без проблем удалось "сбить" WEP с Интел Центрино клиента (см. предыдущую часть статьи по поводу атаки "сброс WEPа при коммуникации с клиентом"). К сожалению, Karma tools не поддерживают "отлов" клиентов в режиме ад-хок, но это не беда. Включение iwconfig ath0 mode ad-hoc параллельно с aireplay -0 по атакуемому Orinoco чипсет клиенту из соседней консоли сделали свое темное дело, сбросив клиента с легитимной сети и присоединив его к атакующему хосту. Таким образом, все описываемые в предыдущих частях статьи атаки вполне осуществимы на практике.
В заключении, несколько комментариев и рекоммендаций по защите беспроводных клиентов от атак подобного рода. Технически клиент вне опасности, если с помощью утилиты конфигурации беспроводного устройства удалены все незащищенные профили СПС и оставлены только сети, подсоединение к которым идет под защитой WPA, желательно WPA Industry с использованием 802.1х и двусторонней аутентификации (EAP-TLS), причем клиентский сертификат должен быть защищен сильным паролем. Также нелишними являются установка персональных брандмауэров на клиентские устройства и приличного беспроводного IDS в зоне покрытия корпоративной / организационной сети для обнаружения ад-хок соединений и несанкционированных точек доступа, сманивающих на себя клиентов и скидывающих их с легитимной сети с помощью DoS атак. А ещё не забудьте по возможности использовать последние модели клиентских устройств (32-bit Cardbus, чипсеты с программной, а не прошивочной имплементацией MAC уровня) и последние версии драйверов для этих устройств. Увы, все подобные меры противодействия упираются в значительные проблемы административно-организационного плана, по крайней мере если речь идет об обычных пользователях и достаточно крупной компании / организации. Для системного администратора достаточно сложно проследить, чтобы СПС всех клиентских хостов под его опекой не содержали незащищенных сетей. Особенно, если эти хосты используются сотрудниками вне его домэйна ответственности - дома, в кафе, гостиницах, аэропортах... Таким образом, во многих случаях, несмотря на старания системного администратора, всё равно остается лазейка для беспроводной крысы, предпочитающей клиентские устройства на завтрак.
У беспроводных сетей очень много общего с проводными, но есть и различия. Для того, чтобы проникнуть в проводную сеть, хакеру необходимо физически к ней подключиться. В варианте Wi-Fi ему достаточно установить антенну в ближайшей подворотне в зоне действия сети.
Хотя сегодня в защите Wi-Fi-сетей и применяются сложные алгоритмические математические модели аутентификации, шифрования данных, контроля целостности их передачи, тем не менее на начальных этапах распространения Wi-Fi нередко появлялись сообщения о том, что даже не используя сложного оборудования и специальных программ можно было подключиться к некоторым корпоративным сетям просто проезжая мимо с ноутбуком. Появились даже легенды о разъезжающих по крупным городам хакерах (war driver) с антеннами, сооруженными из консервной банки или упаковки из-под чипсов. Якобы у них даже была своя условная система знаков, которые рисовались на тротуаре и указывали незащищенные должным образом точки доступа. Возможно, так и было, лишь вместо банок из-под чипсов использовались мощные антенны, а условные знаки обозначались на карте, связанной с системой глобального позиционирования (GPS).
Что же теоретически может получить злоумышленник в беспроводной сети, настройке которой не было уделено должного внимания? Вот стандартный список:
доступ к ресурсам и дискам пользователей Wi-Fi-сети, а через неё — и к ресурсам LAN;
подслушивание трафика, извлечение из него конфиденциальной информации;
искажение проходящей в сети информации;
воровство интернет-траффика;
атака на ПК пользователей и серверы сети (например, Denial of Service или даже глушение радиосвязи);
внедрение поддельной точки доступа;
рассылка спама, противоправная деятельность от имени вашей сети.
Развитие защиты Wi-Fi
В 1997 году вышел первый стандарт IEEE 802.11, безопасность которого, как оказалось, далека от идеала. Простой пароль SSID (Server Set ID) для доступа в локальную сеть по современным меркам нельзя считать защитой, особенно, учитывая факт, что к Wi-Fi не нужно физически подключаться.
Главной же защитой долгое время являлось использование цифровых ключей шифрования потоков данных с помощью функции Wired Equivalent Privacy (WEP). Сами ключи представляют из себя обыкновенные пароли с длиной от 5 до 13 символов ASCII, что соответствует 40 или 104-разрядному шифрованию на статическом уровне. Как показало время, WEP оказалась не самой надёжной технологией защиты. И, кстати, все основные атаки хакеров пришлись как раз-таки на эпоху внедрения WEP.
После 2001 года для проводных и беспроводных сетей был внедрён новый стандарт IEEE 802.1X, который использует вариант динамических 128-разрядных ключей шифрования, то есть периодически изменяющихся во времени. Таким образом, пользователи сети работают сеансами, по завершении которых им присылается новый ключ. Например, Windows XP поддерживает данный стандарт, и по умолчанию время одного сеанса равно 30 минутам.
В конце 2003 года был внедрён стандарт Wi-Fi Protected Access (WPA), который совмещает преимущества динамического обновления ключей IEEE 802.1X с кодированием протокола интеграции временного ключа Temporal Key Integrity Protocol (TKIP), протоколом расширенной аутентификации Extensible Authentication Protocol (EAP) и технологией проверки целостности сообщений Message Integrity Check (MIC).
Помимо этого, параллельно развивается множество самостоятельных стандартов безопасности от различных разработчиков, в частности, в данном направлении преуспевают Intel и Cisco. В 2004 году появляется WPA2, или 802.11i, — максимально защищённый стандарт.
Технологии защиты
WEP
Эта технология была разработана специально для шифрования потока передаваемых данных в рамках локальной сети. Данные шифруются ключом с разрядностью от 40 до 104 бит. Но это не целый ключ, а только его статическая составляющая. Для усиления защиты применяется так называемый вектор инициализации Initialization Vector (IV), который предназначен для рандомизации дополнительной части ключа, что обеспечивает различные вариации шифра для разных пакетов данных. Данный вектор является 24-битным. Таким образом, в результате мы получаем общее шифрование с разрядностью от 64 (40+24) до 128 (104+24) бит. Идея очень здравая, поскольку при шифровании мы оперируем и постоянными, и случайно подобранными символами.
Но, как оказалось, взломать такую защиту можно — соответствующие утилиты присутствуют в Интернете (например, AirSnort, WEPcrack). Основное её слабое место — это как раз-таки вектор инициализации. Поскольку мы говорим о 24 битах, это подразумевает около 16 миллионов комбинаций (2 в 24 степени) — после использования этого количества ключ начинает повторяться. Хакеру необходимо найти эти повторы (от 15 минут до часа для ключа 40 бит) и за секунды взломать остальную часть ключа. После этого он может входить в сеть как обычный зарегистрированный пользователь.
802.1X
IEEE 802.1X — это новый стандарт, который оказался ключевым для развития индустрии беспроводных сетей в целом. На данный момент он поддерживается только со стороны ОС Windows XP и анонсирован для Windows Server 2003. За основу взято исправление недостатков технологий безопасности, применяемых в 802.11, в частности, возможность взлома WEP, зависимость от технологий производителя и т. п. 802.1X позволяет подключать в сеть даже PDA-устройства, что позволяет более выгодно использовать саму идею беспроводной связи. С другой стороны, 802.1X и 802.11 являются совместимыми стандартами. В 802.1X применяется тот же алгоритм, что и в WEP, а именно — RC4, но с некоторыми отличиями.
802.1X базируется на протоколе расширенной аутентификации Extensible Authentication Protocol (EAP), протоколе защиты транспортного уровня Transport Layer Security (TLS) и сервере доступа RADIUS (Remote Access Dial-in User Server). Плюс к этому стоит добавить новую организацию работы клиентов сети. После того, как пользователь прошёл этап аутентификации, ему высылается секретный ключ в зашифрованном виде на определённое незначительное время — время действующего на данный момент сеанса. По завершении этого сеанса генерируется новый ключ и опять высылается пользователю. Протокол защиты транспортного уровня TLS обеспечивает взаимную аутентификацию и целостность передачи данных. Все ключи являются 128-разрядными по умолчанию.
WPA
WPA — это временный стандарт, о котором договорились производители оборудования, пока не вступил в силу IEEE 802.11i. По сути, WPA = 802.1X + EAP + TKIP + MIC, где:
WPA — технология защищённого доступа к беспроводным сетям (Wi-Fi Protected Access),
EAP — протокол расширенной аутентификации (Extensible Authentication Protocol),
TKIP — протокол интеграции временного ключа (Temporal Key Integrity Protocol),
MIC — технология проверки целостности сообщений (Message Integrity Check).
Как видим, ключевыми здесь являются новые модули TKIP и MIC. Стандарт TKIP использует автоматически подобранные 128-битные ключи, которые создаются непредсказуемым способом и общее число вариаций которых достигает 500 миллиардов. Сложная иерархическая система алгоритма подбора ключей и динамическая их замена через каждые 10 Кбайт (10 тыс. передаваемых пакетов) делают систему максимально защищённой.
От внешнего проникновения и изменения информации также обороняет технология проверки целостности сообщений (Message Integrity Check). Достаточно сложный математический алгоритм позволяет сверять отправленные в одной точке и полученные в другой данные. Если замечены изменения и результат сравнения не сходится, такие данные считаются ложными и выбрасываются.
Правда, TKIP сейчас не является лучшим в реализации шифрования, поскольку в силу вступают новые алгоритмы, основанные на технологии Advanced Encryption Standard (AES), которая, кстати говоря, уже давно используется в VPN. Что касается WPA, поддержка AES уже реализована в Windows XP, пока только опционально.
VPN
Технология виртуальных частных сетей Virtual Private Network (VPN) была предложена компанией Intel для обеспечения безопасного соединения клиентских систем с серверами по общедоступным интернет-каналам. VPN очень хорошо себя зарекомендовали с точки зрения шифрования и надёжности аутентификации. Плюс технологии состоит и в том, что на протяжении более трёх лет практического использования в индустрии данный протокол не получил никаких нареканий со стороны пользователей. Информации о его взломах не было.
Технологий шифрования в VPN применяется несколько, наиболее популярные из них описаны протоколами PPTP, L2TP и IPSec с алгоритмами шифрования DES, Triple DES, AES и MD5. IP Security (IPSec) используется примерно в 65—70% случаев. С его помощью обеспечивается практически максимальная безопасность линии связи.
И хотя технология VPN не предназначалась изначально именно для Wi-Fi, она может использоваться для любого типа сетей, и идея защитить с её помощью беспроводные их варианты одна из лучших на сегодня.
Для VPN выпущено уже достаточно большое количество программного (ОС Windows NT/2000/XP, Sun Solaris, Linux) и аппаратного обеспечения. Для реализации VPN-защиты в рамках сети необходимо установить специальный VPN-шлюз (программный или аппаратный), в котором создаются туннели, по одному на каждого пользователя. Например, для беспроводных сетей шлюз следует установить непосредственно перед точкой доступа. А пользователям сети необходимо установить специальные клиентские программы, которые в свою очередь также работают за рамками беспроводной сети и расшифровка выносится за её пределы.
Хотя всё это достаточно громоздко, но очень надёжно, главный недостаток такого решения — необходимость в администрировании. Второй существенный минус — уменьшение пропускной способности канала на 30—40%.
Методы защиты
Таким образом, на сегодняшний день у обычных пользователей и администраторов сетей имеются все необходимые средства для надёжной защиты Wi-Fi, и при отсутствии явных ошибок (пресловутый человеческий фактор) всегда можно обеспечить уровень безопасности, соответствующий ценности информации, находящейся в такой сети. Основные же правила при организации и настройке частной Wi-Fi-сети (если нет задачи сделать её общедоступной) таковы:
максимальный уровень безопасности обеспечит применение VPN — используйте эту технологию в корпоративных сетях;
если есть возможность использовать 802.1X (например, точка доступа поддерживает, имеется RADIUS-сервер) — воспользуйтесь ей (впрочем, уязвимости есть и у 802.1X);
перед покупкой сетевых устройств внимательно ознакомьтесь с документацией. Узнайте, какие протоколы или технологии шифрования ими поддерживаются. Проверьте, поддерживает ли эти технологии шифрования ваша ОС. Если нет, то скачайте апдейты на сайте разработчика. Если ряд технологий не поддерживается со стороны ОС, то это должно поддерживаться на уровне драйверов;
обратите внимание на устройства, использующие WPA2 и 802.11i, поскольку в этом стандарте для обеспечения безопасности используется новый Advanced Encryption Standard (AES);
если точка доступа позволяет запрещать доступ к своим настройкам с помощью беспроводного подключения, то используйте эту возможность. Настраивайте AP только по проводам. Не используйте по радио протокол SNMP, web-интерфейс и telnet;
если точка доступа позволяет управлять доступом клиентов по MAC-адресам (Media Access Control, в настройках может называться Access List), используйте эту возможность. Хотя MAC-адрес и можно подменить, тем не менее это дополнительный барьер на пути злоумышленника;
если оборудование позволяет запретить трансляцию в эфир идентификатора SSID, используйте эту возможность (опция может называться “closed network”), но и в этом случае SSID может быть перехвачен при подключении легитимного клиента;
запретите доступ для клиентов с SSID по умолчанию “ANY”, если оборудование позволяет это делать. Не используйте в своих сетях простые SSID — придумайте что-нибудь уникальное, не завязанное на название вашей организации и отсутствующее в словарях. Впрочем, SSID не шифруется и может быть легко перехвачен (или подсмотрен на ПК клиента);
располагайте антенны как можно дальше от окон, внешних стен здания, а также ограничивайте мощность радиоизлучения, чтобы снизить вероятность подключения «с улицы». Используйте направленные антенны, не используйте радиоканал по умолчанию;
если при установке драйверов сетевых устройств предлагается выбор между технологиями шифрования WEP, WEP/WPA (средний вариант), WPA, выбирайте WPA (в малых сетях можно использовать режим Pre-Shared Key (PSK)). Если устройства не поддерживают WPA, то обязательно включайте хотя бы WEP. При выборе устройства никогда не приобретайте то, что не поддерживает даже 128bit WEP.
всегда используйте максимально длинные ключи. 128-бит — это минимум (но если в сети есть карты 40/64 бит, то в этом случае с ними вы не сможете соединиться). Никогда не прописывайте в настройках простые, «дефолтные» или очевидные ключи и пароли (день рождения, 12345), периодически их меняйте (в настройках обычно имеется удобный выбор из четырёх заранее заданных ключей — сообщите клиентам о том, в какой день недели какой ключ используется).
не давайте никому информации о том, каким образом и с какими паролями вы подключаетесь (если используются пароли). Искажение данных или их воровство, а также прослушивание траффика путем внедрения в передаваемый поток — очень трудоемкая задача при условиях, что применяются длинные динамически изменяющиеся ключи. Поэтому хакерам проще использовать человеческий фактор;
если вы используете статические ключи и пароли, позаботьтесь об их частой смене. Делать это лучше одному человеку — администратору;
если в настройках устройства предлагается выбор между методами WEP-аутентификации “Shared Key” и “Open System”, выбирайте “Shared Key”. Если AP не поддерживает фильтрацию по MAC-адресам, то для входа в “Open System” достаточно знать SSID, в случае же “Shared Key” клиент должен знать WEP-ключ (www.proxim.com/ support/ all/ harmony/ technotes/ tn2001-08-10c.html). Впрочем, в случае “Shared Key” возможен перехват ключа, и при этом ключ доступа одинаков для всех клиентов. В связи с этим многие источники рекомендуют “Open System”;
обязательно используйте сложный пароль для доступа к настройкам точки доступа. Если точка доступа не позволяет ограничивать доступ паролем, её место на свалке;
если для генерации ключа предлагается ввести ключевую фразу, то используйте набор букв и цифр без пробелов. При ручном вводе ключа WEP вводите значения для всех полей ключа (при шестнадцатеричной записи вводить можно цифры 0—9 и буквы a—f).
по возможности не используйте в беспроводных сетях протокол TCP/IP для организации папок, файлов и принтеров общего доступа. Организация разделяемых ресурсов средствами NetBEUI в данном случае безопаснее. Не разрешайте гостевой доступ к ресурсам общего доступа, используйте длинные сложные пароли;
по возможности не используйте в беспроводной сети DHCP — вручную распределить статические IP-адреса между легитимными клиентами безопаснее;
на всех ПК внутри беспроводной сети установите файерволлы, старайтесь не устанавливать точку доступа вне брандмауэра, используйте минимум протоколов внутри WLAN (например, только HTTP и SMTP). Дело в том, что в корпоративных сетях файерволл стоит обычно один — на выходе в интернет, взломщик же, получивший доступ через Wi-Fi, может попасть в LAN, минуя корпоративный файерволл;
регулярно исследуйте уязвимости своей сети с помощью специализированных сканеров безопасности (в том числе хакерских типа NetStumbler), обновляйте прошивки и драйвера устройств, устанавливайте заплатки для Windows.
Наконец, просто не отправляйте особо секретные данные через Wi-Fi.
У многих кто впервые сталкивается с проблемой создания локальной локальной сети сразу возникает много вопросов! Один из них - из чего она состоит? Если сеть создается из 2 компьютеров то здесь проблем нет соеденяются через сетевые адаптеры по средством кабеля. Другой вопрос если в той сети 5, 10 и более машин что тогда?
Более подробно я нашел описание в книге "Основы организации сетей Cisco"
Сетевыми устройствами называются аппаратные средства, используемые для объединения сетей По мере увеличения размеров и сложности компьютерных сетей усложняются и сетевые устройства, которые их соединяют Однако все сетевые устройства служат для решения одной или нескольких общих задач
• Увеличивают число узлов, подключаемых к сети. Узлом называется конечная точка сетевого соединения или общая переходная точка двух или более линий в сети. Узлами могут быть процессоры, контроллеры или рабочие станции. Они отличаются способом маршрутизации и другими возможностями; они могут соединяться линиями связи и служат точками управления сети Термин "узел" иногда используется в более широком
смысле для обозначения любого объекта, имеющего доступ к сети, и часто применяется в качестве синонима термина "устройство".
• Увеличивают расстояние, на которое может простираться сеть.
• Локализуют трафик в сети.
• Могут объединять существующие сети.
• Изолируют сетевые проблемы, делая их диагностику более простой.
В локальной сети используются следующие виды сетевых устройств: повторитель, концентратор, мост и маршрутизатор.
повторители относятся к уровню 1. Чтобы понять, как работает повторитель, необходимо учесть, что данные перед отправкой в сеть преобразуются в последовательность электрических или световых импульсов, которые и перемещающихся в среде передачи данных. Эти импульсы называются сигналами. Когда сигналы покидают передающую станцию, они четкие и легко распознаются. Однако чем длиннее кабель, тем сильнее затухает и ухудшается сигнал. В конце концов, это приводит к тому, что сигнал уже не может быть правильно распознан. Например, спецификации для витой пары категории 5 кабеля Ethernet станавливают расстояние 100 метров как максимально допустимое для прохождения сигнала. Если сигнал проходит по сети больше указанного расстояния, то нет гарантии, что сетевой адаптер правильно распознает сигнал. Если такая проблема возникает, ее можно легко решить с помощью повторителя. Повторители позволяют увеличить протяженность сети, гарантируя при этом, что сигнал будет распознан принимающими устройствами. Повторители принимают ослабленный сигнал, очищают его от помех, усиливают и отправляют дальше в сеть, тем самым увеличивая расстояния, на которых сеть может функционировать. При организации сетей общей проблемой является слишком большое количество устройств, подключаемых к сети.
Концентраторы В локальных сетях каждая станция подключается с помощью некоей передающей среды. Как правило, у каждого файл-сервера имеется только один сетевой адаптер. Как результат, непосредственное подключение всех рабочих станций к файл-серверу невозможно. Чтобы решить эту проблему, в сетях используются концентраторы, которые являются наиболее распространенными сетевыми устройствами. Вообще говоря, термин концентратор используется вместо термина повторитель, когда речь идет об устройстве, которое служит центром сети.
особенности концентраторов: усиливают сигналы; распространяют сигналы в сети; не занимаются маршрутизацией и коммутацией; используются как точки концентрации в сети.
Концентратор можно представить себе в виде устройства, которое содержит множество независимых, но связанных между собой модулей сетевого оборудования. В локальных сетях концентраторы ведут себя как мультипортовые повторители. В таких случаях концентраторы используются, чтобы разделить сетевые носители и обеспечить множественное подключение. Недостатком использования концентратора является то, что он не может фильтровать сетевой трафик. Фильтрацией называется процесс, в ходе которого в сетевом трафике контролируются
определенные характеристики, например, адрес источника, адрес получателя или протокол, и на основании установленных критериев принимается решение — пропускать трафик дальше или игнорировать его. В концентраторе данные, поступившие на один порт, передаются дальше на все порты. Следовательно, концентратор передает данные во все участки или сегментам сети, независимо от того, должны они туда направляться или нет. Если имеется только один кабель, связывающий все устройства в сети, или если сегменты сети связаны только нефильтрующими устройствами (например, концентраторами), несколько
пользователей могут попытаться послать данные в один и тот же момент времени. Если одновременно пытаются передавать несколько узлов, то возникает конфликт. В этом случае данные от разных устройств сталкиваются друг с другом и повреждаются. Область сети, в пределах которой сформировался пакет данных и возник конфликт, называют доменом конфликта.
Одним из методов решения проблемы слишком большого трафика и большого числа конфликтов в сети является использование мостов. Мосты работают на уровне 2 (канальном) и не занимаются исследованием информации от верхних уровней. Назначение мостов состоит в том, чтобы устранить ненужный трафик и уменьшить вероятность возникновения конфликтов. Это достигается путем разделения сети на сегменты и за счет фильтрации трафика по пункту назначения или МАС-адресу. Мосты фильтруют трафик только по МАС-адресу, поэтому они могут быстро пропускать трафик, представляющий любой протокол сетевого уровня. Так как мосты проверяют только МАС-адрес, протоколы не имеют для них значения. Как следствие, мосты отвечают только за то, чтобы пропускать или не пропускать пакеты дальше, основываясь при этом на содержащихся в них МАС-адресах. Можно выделить следующие наиболее важные особенности мостов.
• Они более интеллектуальны, чем концентраторы, т.е. могут анализировать приходящие пакеты и пропускать (или не пропускать) их дальше на основании адресной информации.
• Принимают и пропускают пакеты данных между двумя сетевыми сегментами.
• Управляют широковещательными пакетами в сети.
• Имеют и ведут внутренние таблицы адресов.
Чтобы фильтровать и, соответственно, выборочно пропускать сетевой трафик, мосты строят таблицы соответствия всех МАС-адресов, находящихся в сети и других сетях. При поступлении данных на вход моста он сравнивает адрес получателя, содержащийся в пакете данных, с МАС-адресами в своей таблице. Если мост обнаружит, что МАС-адрес пункта назначения данных расположен в том же сегменте сети, что и отправитель, то он не пропустит данные в другой сегмент. Если же мост обнаружит, что МАС-адрес получателя данных не относится к тому же сегменту сети, что и адрес отправителя, то мост пропустит данные во все остальные сегменты сети. Поэтому мосты могут существенно уменьшать трафик между сетевыми сегментами, устранив ненужный трафик.
Другим типом устройств межсетевого взаимодействия являются маршрутизаторы. Как было сказано выше, мосты прежде всего используются для соединения сегментов сети. Маршрутизаторы же используются для объединения отдельных сетей и для доступа к Internet Они обеспечивают сквозную маршрутизацию при прохождении пакетов данных и маршрутизацию трафика между различными сетями на основании информации сетевого протокола или уровня 3 и способны принимать решение о выборе оптимального маршрута движения данных в сети. С помощью маршрутизаторов также может быть решена проблема чрезмерного широковещательного трафика, так как они не переадресовывают дальше широковещательные кадры, если им это не предписано.
Маршрутизаторы и мосты отличаются друг от друга в нескольких аспектах. Во-первых, мостовые соединения осуществляются на канальном уровне, в то время как маршрутизация выполняется на сетевом уровне. Во-вторых, мосты используют физические или МАС-адреса для принятия решения о передаче данных Маршрутизаторы для принятия решения используют различные схемы адресации, существующие на уровне 3. Они используют адреса сетевого уровня, также называемые логическими, или IP-адресами (Internet Protocol). Поскольку IP-адреса реализованы в программном обеспечении и соотносятся с сетью, в которой находится устройство, иногда адреса уровня 3 называют еще протокольными или сетевыми адресами Физические или МАС-адреса обычно устанавливаются производителем сетевого адаптера и зашиваются в адаптере на аппаратном уровне; IP-адреса обычно назначаются сетевым администратором. Чтобы маршрутизация была успешной, необходимо, чтобы каждая сеть имела уникальный номер Этот уникальный номер сети включен в IP-адрес каждого устройства, подключенного к сети.
Вход
Регистрация
Помощь
ВОТ ОЛЕНИ!!!! Мы проиграли 
FC Bayern München против FC Chelsea
Наверх
Цитата