566078958
|
Главная » Сети и протоколы
|
|
|
|
Протокол SOCKS 5
Статус данного документа
Этот документ описывает протокол связи по стандартам Интернет, и открыт
для обсуждения и предложений. Пожалуйста обращайтесь к текущей редакции
"Internet Official Protocol Standards" (STD 1) чтобы справится о стадии
стандартизации и статусе этого протокола. Распространение этого документа
не ограничивается.
Благодарности
Этот документ описывает протокол, который является развитием предыдущей
версии протокола 4 [1]. Этот новый протокол основывается на бурных
дискуссиях и прототипах реализаций. Основной вклад внесли:
Marcus Leech: Bell-Northern Research, David Koblas: Independent Consultant,
Ying-Da Lee: NEC Systems Laboratory, LaMont Jones: Hewlett-Packard Company,
Ron Kuris: Unify Corporation, Matt Ganis: International Business Machines.
1. Введение
Использование сетевых файрволов и систем, эффективно скрывающих
организацию внутренней сетевой структуры от внешней сети, такой
как Интернет, становится все более популярным. Эти файрволы обычно
работают как гэйтэвэи прикладного уровня между сетями, предлагая
обычно администрируемый TELNET, FTP, и SMTP доступ. С появлением
более сложных протоколов прикладного уровня предназначенных для
облегчения глобального информационного взаимодействия, появилась
потребность в обеспечении общей основы для прозрачной и безопасной
работы через файрволл для этих протоколов.
Leech, et al Standards Track [Страница 1]
RFC 1928 Протокол SOCKS 5 Март 1996
Существует также необходимость в строгой аутентификации при работе через
файрволл, в некоторой степени похожей на используемые сейчас методы. Это
требование обусловлено тем, что отношения типа клиент-сервер появляются
между сетями различных организаций, и эти отношения должны быть
управляемыми и, зачастую, строго аутентифицированны.
Описываемый здесь протокол разработан чтобы обеспечить основу для
удобного и безопасного использования сервиса сетевых файрволов для
приложений типа клиент-сервер работающих по протоколам TCP и UDP.
Протокол представляет собой "уровень-прокладку" между прикладным
уровнем и транспортным уровнем, и, как таковой, не обеспечивает
сервиса гэйтэвэев сетевого уровня, такого как пересылка пакетов ICMP.
2. Текущее положение дел
Существующий сейчас протокол, SOCKS v4, предназначен для работы через
файрволл без аутентификации для приложений типа клиент-сервер работающих
по протоколу TCP, таких как TELNET, FTP и таких популярных протоколов
обмена информацией, как HTTP, WAIS и GOPHER.
Новый протокол расширяет модель SOCKS v4 добавляя к ней поддержку UDP,
обеспечение универсальных схем строгой аутентификации и расширяет
методы адресации, добавляя поддержку доменных имен и адресов IP v6.
Реализация протокола SOCKS обычно влечет за собой перекомпиляцию или
пересборку клиентских программ, работающих по протоколу TCP, для
использования оответствующх функций SOCKS-библиотеки.
Замечание:
Если не оговорено обратное, десятичные числа в диаграммах формата
пакетов обозначают длинну соответствующего поля в октетах (8-битных
элементах). Если октет должен иметь определенное значение, используется
обозначение X'hh' для определения значения октета в данном поле.
Если используется слово 'Variable', это означает, что соответствующее
поле имеет переменную длинну, определяемую либо связанным (одно- или
двух-октетным) полем длинны, либо типом данных данного поля.
3. Процедура для клиентов работающих по TCP
Когда работающий по TCP клиент хочет соединиться с объектом, доступным
только через файрволл, он должен открыть TCP-соединение c
соответствующим SOCKS-портом SOCKS-сервера. Сервис SOCKS обычно
находится на TCP-порту 1080. Если соединение прошло успешно, клиент
начинает переговоры о методе аутентификации, который будет
Leech, et al Standards Track [Страница 2]
RFC 1928 Протокол SOCKS 5 Март 1996
использоваваться, проходит аутентификацию по выбранному методу и
посылает свой запрос. SOCKS-сервер обрабатывает запрос и либо
пытается установить соответствующее соединение, либо отказывает в нем.
Клиент соединяется с сервером и посылает сообщение с номером версии
и выбором соответствующего метода аутентификации:
+----+----------+----------+
|VER | NMETHODS | METHODS |
+----+----------+----------+
| 1 | 1 | 1 to 255 |
+----+----------+----------+
Значение поля VER равно X'05' для данной версии протокола. Поле
NMETHODS содержит число октетов в идентификаторах методов авторизации
в поле METHODS.
Серевер выбирает один из предложенных методов, перечисленных в METHODS,
и послылает ответ о выбранном методе:
+----+--------+
|VER | METHOD |
+----+--------+
| 1 | 1 |
+----+--------+
Если выбранный метод в METHOD равен X'FF', то ни один из предложенных
клиентом методов не применим и клиент должен закрыть соединение.
Эти значения определены для поля METHOD:
o X'00' аутентификация не требуется
o X'01' GSSAPI
o X'02' USERNAME/PASSWORD (см. RFC1929)
o X'03' до X'7F' зарезервировано IANA
o X'80' до X'FE' преднозначено для частных методов
o X'FF' нет применимых методов
Затем клиент и сервер начинают аутентификацию согласно выбранному методу.
Leech, et al Standards Track [Страница 3]
RFC 1928 Протокол SOCKS 5 Март 1996
Описание методов аутентификации находится в отдельных документах.
Разработчики новых методов аутентификации применимых для этого протокола
должны обращаться в IANA для получения номера метода. Документ с
выделеными номерами должен дополнить текущий список номеров и
соответствущих им методов аутентификации.
Совместимые реализации должны поддерживать GSSAPI и могут поддерживать
аутентификацию USERNAME/PASSWORD.
4. Запросы
После того как аутентификация выполнена, клиент посылает детали запроса.
Если выбранный метод аутентификации требует особое формирование пакетов
с целью проверки целостности и/или конфедициальности, запросы должны
инкапсулироваться в пакет, формат которого определяется выбранным
методом.
SOCKS-запрос формируется следующим образом:
+----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
Где:
o VER версия протокола: X'05'
o CMD
o CONNECT X'01'
o BIND X'02'
o UDP ASSOCIATE X'03'
o RSV зарезервировано
o ATYP тип адреса, следующего вида:
o IP v4 адрес: X'01'
o имя домена: X'03'
o IP v6 адрес: X'04'
o DST.ADDR требуемый адрес
o DST.PORT требуемый порт (в сетевом порядке октетов)
SOCKS-сервер обрабатывает запрос на основании исходного и целевого
адресов и посылает одно или несколько сообщений в ответ, в соответствии
с типом запроса.
Leech, et al Standards Track [Страница 4]
RFC 1928 Протокол SOCKS 5 Март 1996
5. Адресация
Тип адреса содержащегося в адресном поле (DST.ADDR, BND.ADDR),
определяется содержимым поля ATYP:
o X'01'
адрес является адресом IP v4, длинна адреса 4 октета
o X'03'
поле адреса содержит имя домена. Первый октет адресного поля содержит
число октетов в последующем за ним имени, завершающий NUL-октет в конце
строки не применяется.
o X'04'
адрес является адресом IP v6, длинна адреса 16 октет
6. Ответы
SOCKS-запрос посылается клиентом как только он установил соединение с
SOCKS-сервером и выполнил аутентификацию. Сервер обрабатывает запрос и
посылает ответ в следующей форме:
+----+-----+-------+------+----------+----------+
|VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
Где:
o VER версия протокола: X'05'
o REP код ответа:
o X'00' успешный
o X'01' ошибка SOCKS-сервера
o X'02' соединение запрещено набором правил
o X'03' сеть недоступна
o X'04' хост недоступен
o X'05' отказ в соединении
o X'06' истечение TTL
o X'07' команда не поддерживается
o X'08' тип адреса не поддерживается
o X'09' до X'FF' не определены
o RSV зарезервирован
o ATYP тип последующего адреса
Leech, et al Standards Track [Страница 5]
RFC 1928 Протокол SOCKS 5 Март 1996
o IP v4 адрес: X'01'
o имя домена: X'03'
o IP v6 адрес: X'04'
o BND.ADDR выданный сервером адрес
o BND.PORT выданный сервером порт (в сетевом порядке октетов)
Значения зарезервированных (RSV) полей должны быть установлены в X'00'.
Если выбранный метод аутентификации требует особое формирование пакетов
с целью проверки целостности и/или конфедициальности, запросы должны
инкапсулироваться в пакет, формат которого определяется выбранным
методом.
CONNECT
В ответ на CONNECT, BND.PORT содержит номер порта, который сервер
назначает для соединения с указанным хостом, а BND.ADDR содержит
связанный IP-адрес. Выданный BND.ADDR зачастую отличается от
IP-адреса, который клиент использует для доступа к SOCKS-северу,
так как такие сервера часто имеют несколько IP-адресов. Ожидается,
что сервер будет испо... Читать дальше »
|
Скрины:
Дата: 16.01.2010
Добавил: Админ
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
Предисловие
Данный документ устанавливает Internet протокол в стандарте DOD. Он основан на шести предыдущих версиях спецификации протокола ARPA Internet, и из них в значительной степени заимствован его текст.
Вместе с тем в эту работу внесены многие изменения, касающиеся как терминологии, так и собственно изложения материала. Это издание освещает адресацию, обработку ошибок, коды опций, а также безопасность, историю и поддержку свойств протокола Internet.
Джон Постел (Jon Postel)
Редактор
Протокол Internet
Программа DARPA Internet
Спецификация протокола
1. Введение
1.1 Обоснование
Протокол Internet создан для использования в объединенных системах компьютерных коммуникационных сетей с коммутацией пакетов. Такие системы были названы "catenet" [1]. Протокол Internet обеспечивает передачу блоков данных, называемых датаграммами, от отправителя к получателям, где отправители и получатели являются хост-компьютерами, идентифицируемыми адресами фиксированной длины. Протокол Internet обеспечивает при необходимости также фрагментацию и сборку датаграмм для передачи данных через сети с малым размером пакетов.
1.2 Цель
Протокол Internet специально ограничен задачами обеспечения функций, необходимых для передачи битового пакета (датаграммы Internet) от отправителя к получателю через объединенную систему компьютерных сетей. Нет механизмов для увеличения достоверности конечных данных, управления протоколом, синхронизации или других услуг, обычно применяемых в протоколах передачи от хоста к хосту. Протокол Internet может обобщить услуги поддерживающих его сетей с целью предоставления услуг различных типов и качеств.
1.3 Интерфейсы
Данный протокол получил название в соответствии с протоколами передачи информации между хост-компьютерами в межсетевой среде. Протокол вызывает в локальной сети протоколы для передачи датаграммы Internet на следующий шлюз или хост-получатель.
Например, модуль TCP вызывал бы модуль Internet с тем, чтобы получить сегмент TCP (включая заголовок TCP и данные пользователя) как информационную часть Internet пакета. Модуль TCP обеспечил бы адреса и другие параметры в заголовке модуля Internet в качестве параметров рассматриваемого вызова. Модуль Internet в этом случае создал бы датаграмму Internet и прибегнул бы к услугам локальной сети для передачи датаграммы Internet.
Например, в случае сети ARPANET модуль Internet вызывал бы локальный сетевой модуль, который бы добавлял к датаграмме Internet проводник типа 1822 [2], создавая сообщение ARPANET для передачи на IMP. Адрес ARPANET получился бы из адреса Internet с помощью интерфейса локальной сети и относился бы к некоторому хост-компьютеру в сети ARPANET, который мог бы быть шлюзом в другие сети.
1.4 Действие
Протокол Internet выполняет две главные функции: адресацию и фрагментацию.
Модули Internet используют адреса, помещенные в заголовок Internet, для передачи Internet датаграмм их получателям. Выбор пути передачи называется маршрутизацией.
Модули Internet используют поля в заголовке Internet для фрагментации и восстановления датаграмм Internet, когда это необходимо для их передачи через сети с малым размером пакетов.
Сценарий действия состоит в том, что модуль Internet меняет размер на каждом из хостов, задействованных в internet-коммуникации и на каждом из шлюзов, обеспечивающих взаимодействие между сетями. Эти модули придерживаются общих правил для интерпретации полей адресов, для фрагментации и сборки Internet датаграмм. Кроме этого, данные модули (и особенно шлюзы) имеют процедуры для принятия решений о маршрутизации, а также другие функции.
Протокол Internet обрабатывает каждую Internet датаграмму как независимую единицу, не имеющую связи ни с какими другими датаграммами Internet. Протокол не имеет дело ни с соединениями, ни с логическими цепочками (виртуальными или какими-либо другими).
Протокол Internet использует четыре ключевых механизма для формирования своих услуг: задание типа сервиса, времени жизни, опций и контрольной суммы заголовка.
Тип обслуживания используется для обозначения требуемой услуги. Тип обслуживания - это абстрактный или обобщенный набор параметров, который характеризует набор услуг, предоставляемых сетями, и составляющих собственно протокол Internet. Этот способ обозначения услуг должен использоваться шлюзами для выбора рабочих параметров передачи в конкретной сети, для выбора сети, используемой при следующем переходе датаграммы, для выбора следующего шлюза при маршрутизации сетевой Internet датаграммы.
Механизм времени жизни служит для указания верхнего предела времени жизни Internet датаграммы. Этот параметр устанавливается отправителем датаграммы и уменьшается в каждой точке на проходимом датаграммой маршруте. Если параметр времени жизни станет нулевым до того, как Internet датаграмма достигнет получателя, эта датаграмма будет уничтожена. Время жизни можно рассматривать как часовой механизм самоуничтожения.
Механизм опций предоставляет функции управления, которые являются необходимыми или просто полезными при определенных ситуациях, однако он не нужен при обычных коммуникациях. Механизм опций предоставляет такие возможности, как временные штампы, безопасность, специальная маршрутизация.
Контрольная сумма заголовка обеспечивает проверку того, что информация, используемая для обработки датаграмм Internet, передана правильно. Данные могут содержать ошибки. Если контрольная сумма неверна, то Internet датаграмма будет разрушена, как только ошибка будет обнаружена.
Протокол Internet не обеспечивает надежности коммуникации. Не имеется механизма подтверждений ни между отправителем и получателем, ни между хост-компьютерами. Не имеется контроля ошибок для поля данных, только контрольная сумма для заголовка. Не поддерживается повторная передача, нет управления потоком.
Обнаруженные ошибки могут быть оглашены посредством протокола ICMP (Internet Control Message Protocol) [3], который поддерживается модулем Internet протокола.
2. Обзор
2.1 Связь с другими протоколами
Следующая диаграмма иллюстрирует место протокола Internet в иерархии протоколов.
Рис. 1 Взаимодействие протоколов
Протокол Internet взаимодействует с одной стороны с протоколами передачи информации между хост-компьютерами, а с другой - с протоколами локальной компьютерной сети. При этом локальная сеть может являться малой компьютерной сетью, участвующей в создании большой сети, такой как ARPANET.
2.2 Сценарий работы
Схему действий для передачи датаграммы от одной прикладной программы к другой можно проиллюстрировать следующим образом.
Предположим, что перенос будет включать прохождение одного промежуточного шлюза. Отправляющая прикладная программа готовит свои данные и вызывает свой локальный Internet модуль для отправки этих данных в качестве датаграммы, а в качестве аргументов этого вызова передает адрес получателя и другие параметры.
Модуль Internet готовит заголовок датаграммы и стыкует с ним данные. Модуль Internet определяет локальный сетевой адрес, соответствующий данному адресу Internet. В данном случае это адрес шлюза.
Модуль передает данную датаграмму и адрес в локальной сети в распоряжение интерфейса локальной сети.
Интерфейс локальной сети создает соответствующий этой сети заголовок и соединяет с ним датаграмму. Затем он передает по локальной сети полученный таким образом результат.
Датаграмма достигает хост-компьютер, играющий роль шлюза и расположенный в вершине сети. Интерфейс локальной сети отделяет этот заголовок и передает датаграмму на модуль Internet. Модуль Internet определяет из Internet адреса, что датаграмма должна быть направлена на хост-компьютер во второй сети. Модуль Internet определяет адрес хоста-получателя в локальной сети. Он обращается к интерфейсу локальной сети с тем, чтобы она переслала данную датаграмму по назначению.
Интерфейс создает заголовок локальной сети и соединяет с ним датаграмму, а затем результат направляет на хост-получатель. На хосте-получателе интерфейс локальной сети удаляет заголовок локальной сети и передает оставшееся на Internet модуль.
Модуль Internet определяет, что рассматриваемая выше датаграмма предназначена для прикладной программы на этот хосте. Модуль передает данные прикладной программе в ответ на системный вызов. В качестве результата этого вызова передаются адрес получателя и другие параметры.
Рис. 2 Путь передачи датаграммы
2.3 Описание функций
Функция или цель протокола Internet состоит в передаче датаграммы через набор объединенных компьютерных сетей. Это осуществляется посредством передачи датаграмм от одного модуля Internet к другому до тех пор, пока не будет достигнут получатель. Модули Internet находятся на хостах и шлюзах системы Internet. Датаграммы направляются с одного модуля Internet на другой через конкретные компьютерные сети, основанные на интерпретации Internet адресов. Таким образом, одним из важных механизмов протокола Internet является Internet адрес.
При передаче сообщений с одного Internet модуля на другой датаграммы могут нуждаться в прохождении через сети, для которых максимальный размер пакета меньше, чем размер датаграммы. Чтобы преодолеть эту сложность, в протокол Internet включен механизм фрагментации.
Адресация. В протоколе сделано разграничение между именами, адресами и маршрутами [4]. Имя показывает искомый нами объект. Адрес показывает его местонахождение. Internet имеет дело с адресами. Перевод имен в адреса является задачей протоколов более высокого уровня (прикладных программ или протоколов передачи синхронизации с хоста на хост). Собственно модуль Internet осуществляет отображение адресов Internet на адреса локальной сети. Создание карты адресов локальной се... Читать дальше »
|
Скрины:
Дата: 16.01.2010
Добавил: xakep1983
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
Содержание
INTRO----------------------[13]
Обзор UDP---------------[13]
Что лучше?--------------[13]
Атаки на UDP----------[13]
Эксплоиты---------------[13]
Заключение-------------[13]
Ссылки---------------------[13]
[INTRO]
Задача данной статьи - это показать основные возможности протокола
дайтограмм. Я постараюсь рассказать как можно доступнее и понятнее о
недостатках и достоинствах протокола, а так же о его функционировании.
В статье рассмотрены способы атаки на UDP и приведены примеры
эксплоитов. Так же в статье есть сравнение UDP с TCP протоколом т.к.
они оба являются транспортными .
[Обзор UDP]
User Datagram Protocol дословный перевод [протокол дайтограмм
пользователя], он предназначен для передачи данных между прикладными
процессами и
обменом дейтаграммами между компьютерами входящими в единую сеть. Длина
пакета в UDP измеряется в октетах, дейтаграммы пользователя включают
заголовок и данные. Это означает, что минимальная величина длины четыре
байта.
Протокол UDP является транспортным и он не устанавливает логического
соединения, а также не упорядочивает пакеты данных. То есть пакеты
могут
прийти не в том порядке в котором они были отправлены и UDP не
обеспечивает достоверность доставки пакетов. Но данные, отправляемые
через модуль UDP, достигают места назначения как единое целое. Главная
особенность
UDP заключается в том, что он сохраняет границы сообщений и никогда не
объединяет несколько сообщений в одно. Взаимодействие между процессами и модулем UDP осуществляется
через UDP-порты. Адресом назначения является номер порта прикладного
сервиса.
В протоколе так же используется IP который является адресом узла . У
UDP так же как и у TCP существуют зарезервированные порты. Присвоением
сервисам собственных номеров занимается организация IANA (Internet
Assigned Numbers Authority).
Всего в UDP используется от 0 до 65535 портов. При этом от 0 до 1023
главные порты, от 1024 до 49151 порты выделенные под крупные проекты и
частные порты, от 49152 до 65535 предусмотрены для любого программиста
который захочет использовать данный протокол.
Вот список от 1 до 20 портов из списка номеров портов от организации IANA:
Порт Описание
1 TCP Port Service Multiplexer
2 Management Utility
3 Compression Process
4 Unassigned
5 Remote Job Entry
6 Unassigned
7 Echo
8 Unassigned
9 Discard
10 Unassigned
11 Active Users
12 Unassigned
13 Daytime (RFC 867)
14 Unassigned
15 Unassigned
16 Unassigned
17 Quote of the Day
18 Message Send Protocol
19 Character Generator
20 File Transfer [Default Data]
Подробную информацию смотри в RCF IANA
Так же есть возможность локально присвоить номер порта. Для этого
необходимо
приложение связать с доступом и при этом выбрать любое число, но при
этом необходимо помнить о том что существуют уже зарезервированные
порты.
Преимущество протокола UDP состоит в том, что он позволяет
прикладным программам отправлять сообщения другим приложениям используя
минимальное количество параметров протокола.
[Что лучше?]
TCP это такой же транспортный протокол как и UDP, но намного
функциональнее и более востребован чем UDP сейчас объясню почему.
Наверно ты уже обратил внимание на то что UDP может не доставить
сообщение, может доставить его в искаженном виде, а TCP отвечает за
доставку сообщения, при чем в том порядке в котором оно было
отправлено. TCP так же обеспечивает соединение из конца в конец, то
есть от клиента к серверу, а UDP этим свойством не наделена. Из этого
делаем вывод, что UDP не сможет заменить TCP ни в коем случае. Но для
быстрой организации отправки сообщения, без заморочки мозгов лучше
всего использовать UDP. Вот для чего он и служит: для быстрой
организации отправки данных. И поэтому нам необходимы
в использовании оба протокола для реализации прикладных данных.
[Атаки на UDP]
1. Приложения использующие модель запрос-ответ" также можно
нарушить. При запросе клиент будет получать пакеты ICMP Destination
Unreachable. И есть вероятность что все клиенты смогут адекватно
отреагировать на этот поток ложной информации.
2. UDP Storm - необходимо что бы на сервере было открыто как
минимум два порта. Например отправляешь на один из открытых портов UDP
запрос, а в качестве отправителя указываешь адрес второго открытого UDP
порта и тут происходит самое интересное - порты отвечают друг другу
бесконечно. В результате данной атаки снижается производительность
сервера.
3. Системы телефонной связи через Internet организуют соединения"
на уровне инкапсулируемых в дейтаграммы UDP данных (например,
телефонное" соединение между абонентами). Для таких приложений поток
информации о недоступности удаленной стороны может приводить к разрыву
соединения на уровне инкапсулированного в UDP протокола.
4. UDP Package - смысл атаки заключается в отправке некорректного
пакета на сервис UDP. Например UDP пакет с некорректными полями
служебных данных.
5. Для некоторых приложений может играть важную роль целостность сессии . Здесь можно поэкспериментировать.
UDP DoS - тип атаки "отказ в обслуживании" не обошол стороной и
UDP, для реализации данного вида атак необходимо сгенерировать большое
количество UDP-пакетов направленных на определенную машину.
В результате успешной атаки происходит либо зависание либо его
перезагрузка. Осуществить атаку можно из за того что в UDP отсутствует
механизм предотвращения перегрузок.
[Эксплоиты]
GNUnet <= 0.7.0d (Empty UDP Packet) Remote Denial of Service Exploit - Продукт GNUnet версия 0.7.0d ДоС атака
D-Link Wireless Access Point (Fragmented UDP) DoS Exploit - Продукт D-Link ДоС атака
Sentinel LM 7.x UDP License Service Remote Buffer Overflow Exploit - Переполнение буфера
UDP Stress Tester Denial of Service Exploit
[Заключение]
Прочитав данную статью ты должен представлять что из себя
представляет UDP протокол, знать его основные достоинства и недостатки
и понимать
разницу между TCP и UDP. UDP. Протокол нам необходим прежде всего для
организации быстрых соединений, а для других целей использовать данный
протокол просто невозможно из- за отсутствия многих возможностей
присущих TCP.
[Ссылки]
www.iana.com
User Datagram Protocol
Все скопировано и переведено с RFC 768
UDP
4.4.2 Протокол UDP
www.google.com
|
Скрины:
Дата: 16.01.2010
Добавил: xakep1983
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
|
Протокол ARP и установка маршрутов
Содержание:
INTRO-------------------------------------------------[13]
Протокол ARP-------------------------------------[13]
Обзор маршрутов--------------------------------[13]
Перенаправление маршрутов---------------[13]
Значение ARP в установке маршрутов--[13]
Заключение-----------------------------------------[13]
[INTRO]
В этой статье речь пойдет об установке маршрутов между сетями. Ты
узнаешь как взаимодействуют между собой шлюзы и как они поддерживают
между собой связь. Ты поймешь какую роль играет протокол ARP в
установке маршрутов и почему именно
он устанавливает маршруты.
[Протокол ARP]
Протокол Address Resolution Protocol дословный перевод [Протокол Адреса
Резолюции] предназначен для отображения IP адресов в Эфирной сети.
Немного о функциях и принципах работы ARP:
Основной функцией данного протокола является преобразование адресов,
при помощи поиска их в таблице. Таблица состоит из строк для каждого
узла сети,
если например необходимо преобразовать IP адрес в Эфирный то
производится поиск из списка таблицы определенного IP адреса и его
преобразование в
десятичные числа. Необходимо это преобразование из- за того, что IP
адреса и Эфирные выбираются независимо, друг от друга и нет алгоритма
для преобразования одного
в другой. IP адрес тебе присваивает провайдер при подключении к
глобальной сети Internet, а эфирный адрес устанавливается
производителем сетевого оборудования.
[Обзор маршрутов]
Ну вот мы и перешли к основной теме данной статьи "установка маршрутов"
- это формирование таблиц маршрутизации о IP сетях к которым есть
доступ. Из чего собственно состоит таблица маршрутов?
Вот упрощенный вариант такой таблицы:
| IP сеть |
Флаг маршрутизации |
Шлюз |
Интерфейс |
213.1.3
213.1.1.3 |
Напрямую
Через шлюз |
[нет записей]
213.1.4.6 |
ie0
ie1 |
В таблице приведены 2 сети - это 213.1.3 и 213.1.1.3,.Флаг
маршрутизации говорит нам о том, что для доступа к сети 213.1.1.3 нам
необходимо использовать шлюз который берется из таблицы "Шлюз". В
данном случае это 213.1.4.6 и производится соединение с их помощью. А
сеть 213.1.3 - это всего лишь дополнительный номер
подключенный к интерфейсу ie0, интерфейс - это параметр который
называется метрикой. Он показывает, какое количество шлюзов
используются на пути между двумя сетями. Как ты видишь в строке 213.1.3
не используется не один шлюз и в интерфейсе существует об этом запись
ie0.
[Перенаправление маршрутов]
Перенаправление маршрутов - это какие -либо изменения записей таблицы.
Перенаправление маршрута было доверено производить шлюзу, но это было
не удобно потому что если какой то канал связи откажет в работе по
каким- либо причинам
нужно было ждать, пока кто- то заметит изменение работы сети и поправит
конфинги ip сети. Затем было решено, что бы все данные хранились на
одном шлюзе который должен быть установлен как маршрут. Но тут
появилась еще одна проблема, как IP сети найти выгодный для нее шлюз
когда по умолчанию стоит только один? Решение данной проблемы было
отдано протоколу ICMP который отправляет сообщение и в нем содержится
новый шлюз, более выгодный для доступа к определенной сети. Между
шлюзами в сети существует некая связь при помощи которой каждый из них
имеет представление о состоянии сети. Для поддержке связи используется
определенная программа с её помощью происходит корректировка таблицы
маршрутов, которая позволяет посылать IP пакеты по оптимальным
маршрутам .Но и тут существует ряд проблем,: существуют так называемые
бездисковые станции, которые зависят от файл-серверов с их помощью они
осуществляют загрузку программ, где располагается их свопинг. Все шлюзы
широковещательно передают содержимое своих таблиц программы которые
следят за этими передачами и загружены на бездисковые станции, если эта
программа не используется, она отправляется в область свопинга на
файловые сервера, таким образом большее количество времени программы
проводят в свопинге, и когда программы вновь активизируются, то
производится подкачка из свопинга в одно и то же время и представь, что
происходит, если каждая станция в одно и то же время производит
загрузку с файл-сервер,а тут- то и происходит перегрузка сети. Почему я
рассказывал выше о протоколе ARP заинтересуешься ты? Потому что ARP-
это протокол, которому было дано свойство принимать решения о
маршрутизации.
[Значение ARP в установке маршрутов]
Как уже было выше сказано Address Resolution Protocol предназначен для
отображения IP адресов в Эфирной сети, но ему нашли применение и в
установке маршрутов. Протокол ARP не затрагивает таблиц маршрутов, все
делается на уровне Эфирной сети. Для того, чтобы использовать протокол
ARP, нужно настроить его таким образом, как будто все машины сети
подключены к твоей локалке. Взаимодействие происходит очень просто.
Предположим что у нас существует две сети и существует два шлюза, если
в Arp таблице нет доступа от одного узла к другому, то первая сеть
посылает запрос на вторую, но проблема состоит в том, что вторая сеть
самостоятельно ответить не может. Но у нас есть шлюз и есть протокол
ARP который умеет преобразовывать ip адреса в эфирные и таким образом
создается иллюзия, что сети соединены, а на самом деле они работают
через шлюз и преобразованные адреса.
[Заключение]
Прочитав данную статью ты должен усвоить, что в сети не все так просто
как кажется на первый взгляд и даже открывая любимую страницу в сети
происходит огромное количество действий для до того что бы она
отобразилась в окне твоего браузера. Ну вот, все что основное тебе
необходимо знать для того чтобы понимать основные принципы
взаимодействия и связей сети, если ты желаешь углубить свои знания в
данной теме читай RFC. Если у тебя возникли вопросы то пиши
admin@cyberpro13.com с удовольствием отвечу на твои вопросы.
|
Скрины:
Дата: 16.01.2010
Добавил: killer
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
Большая часть трафика приходит в Интернет после исследования, и сетевые
администраторы предпринимают шаги по ограничению трафика своих сетей,
но есть один порт, который никто не хочет закрывать - обычно это порт
80. Пользователи (и администраторы) постоянно просматривают веб сайты,
независимо от того, нужно это для работы или нет. Жизненная основа
присутствия компании в Интернет, так или иначе, требует наличие веб
ресурса, а это требует наличия веб сервера, размещенного у хостинг
провайдера или в сети компании. С каждым новым червем, ошибкой или
уязвимостью обнаруженной в IIS или Apache, сетевые администраторы и
администраторы безопасности пытаются заблокировать эти сервисы на
маршрутизаторе или брандмауэре. Для идентификации атак многие
используют IDS и IPS.
В этой статье мы рассмотрим способы обхода ограничений доступа
маршрутизатора или брандмауэра компании. Эта информация предназначена в
помощь тем, кто законно тестирует безопасность сети (независимо от
того, являются ли они внутренними экспертами или внешними
консультантами). Данная статья ни в коем случае не потворствует
использованию этой информации для неправомерного доступа к сети или
системе. И, наконец, в этой статье будут упомянуты способы защиты от
этой атаки.
Что такое туннелирование HTTP?
Туннелирование не представляет собой ничего нового. IPSec это,
возможно, самый широко известный способ туннелирования, наиболее
близким продолжением которого является SSH туннелирование. Однако, если
атакующий не имеет достаточно высоких шансов на успех, маловероятно,
что он выберет IPSec или SSH в качестве возможного порта проникновения.
Не каждая компания предоставляет удаленный доступ через IPSec или SSH,
но если она делает это, сервер вероятно уже укреплен. В дополнение,
скорее всего в качестве концентратора используется заказное устройство
типа Cisco VPN 3000 и возможно UNIX/Linux система.
Из-за повсеместного распространения вед серверов они являются
превосходной целью для атакующего. Кроме того, при условии, что они
находятся за брандмауэром, веб сервера представляют из себя
единственный, но важный вход в целевую сеть. Это тот случай, где
применяется туннелирование. Так как возросло понимание необходимости
защиты, компании установили дополнительные системы защиты между веб
сервером и Интернет, так же как и непосредственно на самом веб сервере.
Средства обнаружения вторжений (IDS) и Средства предотвращения
вторжений (IPS) используются для идентификации и уведомления
администраторов об обнаружении атаки против системы или сети. Но даже у
них есть свои недостатки, и HTTP туннелирование может использоваться
для обхода этих средств.
HTTP туннелирование использует клиентское приложение, чтобы
инкапсулировать трафик в пределах HTTP заголовка. Затем трафик идет на
сервер на другом конце канала связи, который обрабатывает пакет,
"раздевает" заголовки HTTP пакета и переадресовывает пакет его
заключительному адресату. И UDP и TCP трафик может использоваться для
инкапсулирования. Это возможно из-за самой природы туннелирования,
подобной IPSec туннелю, где реальным пакетом является полезная нагрузка
исходного пакета.
В настоящее время есть только два приложения для туннелирования HTTP.
Одно из них распространяется с открытым исходным кодом, другое
коммерческий продукт. Первое приложение, доступное на сайте
http://www.nocrew.org/software/httptunnel.html, это GNU HTTPtunnel.
Второе - HTTP Tunnel корпорации HTTP-Tunnel. Оба они разработаны для
обеспечения соединения к различным портам, осуществляя связь через 80
TCP порт. Оставшеяся часть статьи посвящена свободно распространяемому
GNU HTTPtunnel и его использованию для тестирования брандмауэров и
других фильтров трафика.
Пример туннелирования HTTP
Туннелирование HTTP может использоваться для доступа к портам, которые
обычно недоступны из сети. Взгляните на Рисунок 1 ниже. Хост атакующего
показан слева, а целевые системы справа. Маршрутизатор имеет следующие
правила:
Рисунок 1: Пример установки HTTP Tunnel
inbound:
permit tcp any host WWW port 80
permit tcp any host WWW port 443
permit tcp any host DNS/SMTP port 25
permit udp any host DNS/SMTP port 53
outbound:
permit ip any any
Политика безопасности брандмауэра:
inbound:
permit ip host DNS/SMTP host SSH eq 22
permit ip host DNS/SMTP host SSH eq 80
permit ip host DNS/SMTP host SSH eq 443
outbound:
permit ip any any
Не смотря на то, что все очень упрощено, этого вполне достаточно для
демонстрационных целей. Атакующий взламывает веб сервер с установленным
IIS. Не важно какой именно эксплойт он использует, важно то, что он
способен эксплойтировать сервер и получить доступ к системе через
командную строку. Как только он получает этот доступ, он загружает
скомпилированную версию сервера HTTP Tunnel, hts. Синтаксис запуска
сервера HTTP Tunnel следующий:
hts.exe -F (SRC PORT) (TARGET):(DST PORT)
(SRC PORT) это порт, который будет переадресован, (TARGET) это IP адрес
целевого хоста, а (DST PORT) это целевой порт, который будет принимать
переадресовываемый трафик. Когда клиент посылает трафик на (SRC PORT)
сервер автоматически переадресовывает его на (DST PORT) хоста (TARGET).
(TARGET) может быть IP адресом системы, на которой запущен hts сервер.
После установки hts сервера атакующий запускает клиент на свой системе
и направляет его трафик на (SRC PORT) системы с установленным hts
сервером. Синтаксис запуска клиента HTTP Tunnel такой же, как и для
сервера:
htc -F <SRC PORT> <TARGET>:<DST PORT>
Клиент принимает трафик с и переадресовывает его на хоста .
Посмотрите на следующий пример атаки на систему с Рисунка 1. На Рисунке
2, ниже, атакующий устанавливает hts на WWW хост (шаг 1) и запускает
htc на своей системе (шаг 2). Процесс hts слушает порт 80 WWW хоста и
может переадресовывать трафик. В этом примере атакующий использует hts,
чтобы переадресовывать трафик на telnet порт (TCP/23) DNS/SMTP сервера,
на котором запущен Solaris 2.6.
Когда атакующий соединяется с портом 1025 на свой системе (шаг 3),
процесс htc инкапсулирует трафик в HTTP заголовки и переадресовывает
его на веб сервер (шаг 4). Этот сервер принимает трафик, "раздевает"
HTTP заголовок и переправляет трафик на 23 порт DNS/SMTP сервера (шаг
5). Таким образом, в то время как порт telnet на DNS/SMTP сервера
напрямую недоступен вне корпоративного маршрутизатора, атакующий имеет
доступ к этому порту, и может попробовать перебором узнать логин и
пароль для доступа к системе.
Рисунок 2: Начальное использование HTTP Tunnel
Другая возможность состоит в том, чтобы установить удаленный конец hts
туннеля на finger port (TCP/79) SMTP/DNS хоста и получить список всех
пользователей системы. Это позволит получить первое представление о
возможных именах учетных записей. Однажды доступ к системе будет
получен, либо перебором, либо с помощью эксплойта, например, через
переполнение буфера в sadmind и атакующий получит доступ к системе,
находящейся за маршрутизатором, к которой в обычных обстоятельствах
доступа нет. Получив доступ к командной строке SMTP/DNS хоста,
находящегося за маршрутизатором, атакующий может установить
дополнительные утилиты для дальнейшего проникновения в сеть. Например,
атакующий может следить за соединениями к SMTP/DNS хосту и получать
информацию о потенциальных сервисах, запущенных на системах, которые
находятся за брандмауэром. Это было бы более скрытным методом разведки,
чем прямое сканирование IP адресов в пределах DMZ. Если атакующий
идентифицирует хост, на котором запущен SSH сервер (находится за
брандмауэром), он может использовать SMTP/DNS хост, чтобы попытаться
подключиться к новой цели и использовать любую предполагаемую или
взломанную информацию об учетных записях для получения доступа, как это
показано на Рисунке 3 ниже.
Рисунок 3: Дальнейшее проникновение в сеть
Туннелирование HTTP в испытании на проникновение
Одно из лучших применений туннелирования HTTP это тестирование
ограничений и возможностей защиты сетевого периметра. В то время как
почти все сети ограничивают входящий трафик, многие из этих сетей не
ограничивают исходящий трафик. Используя туннелирование HTTP во время
испытания на проникновение можно определить дополнительные риски
безопасности, которые не будут заметны при проведении простого
сканирования сети на наличие уязвимостей. Также туннелирование HTTP
может быть полезно для определения возможностей IDS идентифицировать
злонамеренный трафик в пределах канала связи. Туннелирование HTTP может
добавить существенные возможности испытанию на проникновение для
определения скрытых угроз.
|
Скрины:
Дата: 16.01.2010
Добавил: сычь
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
В этой статье мы обсудим VPN систему, которая предоставляет
одновременно грамотные технические решения для администраторов и
простой, привлекательный интерфейс для пользователя. Решение
основывается на использовании нескольких утилит с открытым кодом, таких
как: OpenVPN, OpenVPN GUI, Nullsoft Scriptable Install System (NSIS) и
TightVNC. TightVNC будет использоваться для прозрачного удаленного
управления, а сама по себе программа не использует VPN технологии.
В результате мы получим корпоративный Windows 2000/XP инсталлятор,
который включает не только клиентские настройки VPN и ключевую
информацию, но также содержит интегрированный VNC сервер для удаленного
управления и технической поддержки при подключении к VPN серверу.
Утилиты с Открытым Кодом
OpenVPN – надежное и гибкое решение для VPN, позволяющее большинству
платформам семейства Unix/Linux, Windows 2000/XP, и Mac OSX безопасно
устанавливать зашифрованные каналы связи между собой. Эти каналы могут
быть настроены разными способами, но в этой статье мы остановимся на
сети типа точка-точка (РР), которая будет одним малым или большим хабом.
OpenVPN GUI - очень удобная утилита для управления VPN для Windows
2000/XP. Пожалуй, она является самым удобным решением для конечного
пользователя (например, простая в использовании иконка в панели задач).
OpenVPN GUI предоставляет быстрый и простой доступ к VPN настройкам для
большинства пользователей.
Nullsoft Scriptable Install System (NSIS) – open source-проект,
позволяющий создавать корпоративные пакеты установки клиентского ПО.
Наверняка вы уже знакомы с термином Virtual Network Computing (VNC), а
TightVNC – еще один пакет с открытым кодом, основанный на Real VNC.
Пользуюсь TightVNC уже около 5 лет, и поэтому остановил свой выбор
именно на этом пакете. Он очень надежен и оставил на моей работе
некоторый отпечаток. Такой же результат вы сможете получить, используя
любой другой VNC продукт, если захотите поэкспериментировать после
прочтения этой статьи.
Требования к Центру Данных
В статье главным образом обращается внимание на сторону конечного
пользователя, но она была бы неполной, если бы в ней не определялись
требования к центру данных. Итак, вам понадобится защищенный выделенный
сервер под управлением ОС Unix/Linux. Пожалуйста, обратите внимание на
слова «выделенный» и «защищенный», так как это та машина, которая не
должна быть компрометирована. Любой удаленный узел, требующий доступ к
VPN, передает чувствительные данные, поэтому следует заострить внимание
и здесь. Отключите все сетевые сервисы, кроме SSH и OpenVPN, если
возможно, и определите строгие правила для брандмауэра. За
дополнительной информацией по настройке безопасности сервера можно
обратиться ко многим документам, доступным в Интернет.
Следующие примеры осуществлялись на системе под управлением Red Hat Fedora Core 2.
Чтобы скомпилировать OpenVPN, действуйте стандартным способом:
# gzip -d openvpn-2.0_rc6.tar.gz
# tar xf openvpn-2.0_rc6.tar
# cd openvpn-2.0_rc6
# ./configure
# make
# make install
Если у вас возникли какие-то проблемы с компиляцией, убедитесь, что у
вас установлены библиотеки LZO сжатия. Просмотрите документацию по
OpenVPN, где очень подробно описан процесс компиляции пакета.
Конфигурация OpenVPN Сервера
Для начала, создадим директорию для хранения конфигурационных файлов и VPN ключей:
# cd /etc
# mkdir openvpn
# chmod 700 openvpn
# cd openvpn
Ниже приведен полный конфигурационный файл для первого объекта сервера, который следует назвать port5023.conf:
В этом файле находятся всего несколько настроек, требующих изменения
для каждого объекта, в основном туннельный интерфейс для связи,
слушающий UDP порт, расположение файла с ключом и адресацию точка-точка
для VPN соединения.
### Start Config File Port 5023 ###
# local tun device
dev tun23
# interface addresses
ifconfig 10.23.0.1 10.23.0.2
# key location
secret /etc/openvpn/port5023.key
# port to listen on
port 5023
# user to run as
user nobody
group nobody
# options
comp-lzo
ping 15
verb 1
### End Config File Port 5023 ###
Заметьте, что пример настроек, показанный выше, указывает OpenVPN
переключить пользовательские и групповые ID на учетную запись "nobody".
Это работает, если на вашем VPN сервере запущены только службы OpenVPN
с правами nobody. Если же на этом сервере запущены другие службы под
пользовательским и групповым ID nobody, следует запустить OpenVPN от
других ID.
Чтобы создать статический ключ для этого VPN объекта, запустите следующую команду из /etc/openvpn:
# /usr/local/sbin/openvpn --genkey --secret port5023.key
Не забудьте добавить соответствующее правило, разрешающее UDP трафик на
5023 порт. Отмечу, что следует установить простой Perl скрипт,
запускаемый через cron, для регистрации неудачных попыток соединений на
этот порт в целях аудита безопасности.
Теперь вы можете запустить ваш VPN объект:
# /usr/local/sbin/openvpn --daemon --disable-occ --config
/etc/openvpn/port5023.conf
Настройки, переданные OpenVPN:
--daemon – Запустить как демон.
--disable-occ – Этот параметр позволяет взаимодействовать двум разным
версиям OpenVPN. Это очень удобно в том случае, если вы поддерживаете
удаленных пользователей, которые по каким-либо причинам не получают
обновления ПО.
--conf – Указание расположения конфигурационного файла.
Теперь вы должны получить основной объект VPN сервера, слушающий на
5023 порту. Если у вас возникли какие-то проблемы, читайте документацию
по OpenVPN.
Сборка VPN Installer
VPN клиентам при такой настройке необходимо знать где расположен VPN
сервер, на какой порт соединяться, какой статический ключ использовать
и еще кое-что. Все это требует наличия полного конфигурационного файла
и ключа с корпоративным VPN-установщиком. Конечным пользователям не
потребуется дополнительная помощь в процессе получения удаленного
доступа к ресурсам корпорации при использовании интуитивно понятного
установщика.
В связи с тем, что мы создаем свой установщик для Windows 2000/XP,
существует возможность включить независимые программы в процесс
установки. Вместо простой установки VPN клиента с предопределенным
ключом и конфигурационным файлом, мы также включим программу TightVNC
для клиентского и серверного объекта VNC протокола.
Скачайте и установите пакет NSIS на систему под управлением Windows XP:
http://www.openvpn.se/files/nsis/nsis20b3.exe
С момента релиза этой статьи, стала доступна более новая версия NSIS.
Удостоверьтесь, что вы используете версию, ссылка на которую дана выше
в целях демонстрации, однако каждый шаг, описанный здесь, будет
работать с более поздними версиями. Как бы то ни было, оказалось, что
последняя версия NSIS требует некоторых подстроек со следующим
установочным zip файлом, поэтому вам будет проще использовать версию
NSIS, указанную выше.
Далее скачайте установщик на туже машину под управлением Windows XP:
http://www.openvpn.se/files/install_packages_source/openvpn_install_source-2.0-rc6-gui-1.0-beta26.zip
Этот файл был собран Mathias Sundman и включает все необходимые файлы
конфигурации OpenVPN, OpenVPN GUI, и NSIS для сборки стандартного
Windows installer пакета. Распакуйте этот файл на рабочий стол в папку
"VPN Sources”.
Чтобы предугадать, что мы получим в конечном итоге, откройте папку VPN
Sources, правой кнопкой по файлу openvpn-gui.nsi, левой кнопкой по
пункту меню "Compile NSI". Через пару мгновений вы увидите файл
установщика OpenVPN в той же папке. Если вы попробуете запустить этот
установщик, будет установлена стандартная версия OpenVPN. Если возникли
проблемы с созданием установщика, обратитесь к следующей документации:
http://openvpn.se/files/howto/openvpn-howto_roll_your_own_installation_package.html
или
http://nsis.sourceforge.net
Сборка Корпоративного VPN Installer
В данный момент у нас имеется основной VPN сервер и стандартный Windows
installer для OpenVPN, но нам важно собрать его таким образом, чтобы
его можно было легко установить. Кроме того, мы хотим добавить в него
программу TightVNC для удаленного администрирования и помощи.
Скачайте полный набор запускаемых файлов TightVNC 1.3dev6 без установщика с:
http://www.tightvnc.com/download.html
Теперь распакуйте вложенные файлы на рабочий стол. Нас будут
интересовать следующие файлы: VNCHooks.dll, vncviewer.exe, WinVNC.exe и
LICENCE.txt. Скопируйте эти файлы в папку openvpn, включающую в себя
папку "VPN Sources".
Сохраните следующий пример конфигурационного файла в openvpn/config/VPN.ovpn в папке "VPN Sources":
### BEGIN CLIENT SIDE CONFIGURATION FILE ###
# vpn server to contact
remote 192.168.10.10
# port to establish connection on
port 5023
# local tunnel device
dev tun
# interface addresses
tun-mtu 1500
ifconfig 10.23.0.2 10.23.0.1
route 10.0.0.0 255.0.0.0 10.23.0.1
# key location
secret "c:program filescompany branded vpnconfigkey.txt"
# enable LZO compression
comp-lzo
# moderate verbosity
verb 0
mute 10
;fragment 1300
;mssfix
; ping-restart 60
; ping-timer-rem
; persist-tun
; persist-key
; resolv-retry 86400
# keep-alive ping
ping 10
# enable LZO compression
comp-lzo
# moderate verbosity
verb 4
mute 10
### END CLIENT SIDE CONFIGURATION FILE ###
В этом примере множество параметров, и я советую вам
поэкспериментировать с ра... Читать дальше »
|
Скрины:
Дата: 16.01.2010
Добавил: сычь
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
[Вступление]
В этой статье мы рассмотрим с тобой атаки типа Man-in-the-Middle, а точнее метод
перенапраления SSH- и HTTP- трафика с помощью атаки Man in the Middle. Не будем тянуть кота за хвост, а перейдем к делу.
[Немного "посреднеческой" теории :)]
Итак, Man in the Middle (в кратце MitM, с русского языка просто - "атака посредника" или "человек в центре") - это такой
вид атаки, основанный на перенаправлении трафика между двумя машинами для перехвата информации - дальнейшего ее изучения,
уничтожения или модификации.
Теперь расскажу более подробно. Допустим, мы в локальной сети. Все мы слышали о ARP-спуфинг атаке. Проводится она
следующим образом:
в тот момент, когда атакуемая тачка ловит по ARP'y и резолвит MAC-адрес шлюза, мы можем ей послать свой MAC-адрес как
будто наша машина и есть гейт. Шлюз, как и подобает, ответит на этот запрос. То есть пакеты от атакуемой тачки будут
идти прямо к нам на гейт. Этот метод и называется Man-in-the-Middle. Примерно тоже самое мы сделаем с трафиком HTTP- и
SSH-. Просек фишку? Ну если нет, то смело заканчивай чтение статьи, а тем, кто еще со мной я расскажу какой инструментарий
нам понадобится.
[Подготавливаем инструментарий]
Итак, первое, что нам нужно - пакет dsniff (ссылку на пакет ты увидишь в конце статьи). Почему именно он? Да потому, что
этот пакет имеет в себе все необходимые утилиты, включая sshmitm (перенаправление SSH-трафика) и httpmitm
(перенаправление HTTP-трафика), которые умеют обходить следующую следующую схему безопасности: насколько тебе известно,
протоколы с шифрованием данных довольно-таки "секурны" (шифрация в помощь :)) и не позволяют проводить атаки "поверх"
сетевого уровня. Ключ шифрования хакеру неизвестен - данные расшифровать невозможно и вставить команду тоже. Все бы
вроде ничего, да вот как раз-таки программы MitM-атак (sshmitm и httpmitm) из пакета dsniff способны обойти данную
систему безопасности (обойти можно практически все). Делается это все по следующему принципу:
промежуточный хост получает запрос от клиента, "сказав" ему, что он и есть сервер, затем подключаясь к реальному серверу.
Второе, что нам понадобится - прямые руки, четвертое - самое главное - желание, ну и, конечно, жертва, то есть компьютер,
который будем атаковать.
[Перенаправление SSH-трафика]
После подготовки инструментария, ты понял, что к чему и почему :). Доставай sshmitm - сейчас мы будем
перенаправлять SSH-трафик (все, что не понял с теоретической частью - читай выше)с помощью нее, используя недостатки
сегодняшнего PKI (public key infrastructure — схема управления ключами, основанная наметодах несимметричной
криптографии). Давай рассмотрим синтаксис sshmitm:
o---------[Синтаксис sshmitm]---------o
sshmitm [-d] [-I] [-p port] host [port]
-d
разрешить отладочный вывод (то есть более расширенный режим)
-I
перехват сеансов
-p port
порт для прослушивания
host
адрес удаленного хоста, сеансы которого будут перехватываться
port
порт на удаленном хосте
o---------[Синтаксис sshmitm]---------o
се вроде просто и со вкусом - ничего сложного нет :). Начнем реализовать атаку!
[inf@home ~ ]# sshmitm server.target.gov // указываем свой SSH-сервер
sshmitm: relaying to server server.target.gov
как мы не имеем реального SSH-ключа, то командный интерпретатор атакованного выведет запрос о проверке host-ключа,
все это будет выглядеть примерно так:
clientmachine$ server.target.gov
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
Please contact your system administrator.
И тогда пользователь будет решать - подключаться или нет. Если да - то мы получим полный контроль над
SSH-сеансом. НО! Если юзверь ниразу не подключался к той тачке, может быть выдано следующее сообщение:
The authenticity of host 'server.target.gov' can't be established
RSA key fingerprint is
bla:bla:bla;bla;bla........
Are you sure you want ti continue connecting (yes/no)?
Тут у юзверя тоже есть два выбора - коннектиться или нет. Если да - то мы перехватили сеанс, если нет - то увы... :(.
Вообщем-то, атака прошла успешно, если пользователь приконнектился, а sshmitm в свою очередь запишет все пассы и логины,
причем очень читабельно :) Естественно, это не единственный перехватчик SSH-сеансов, но познакомившись с этим,
ты без проблем освоишь и другой :)
[Перенаправление HTTP-трафика]
Сейчас мы будем перенапрвлять HTTP-трафик. Опять таки, нам понадобится уже раннее подобранный инструмент: httpmitm,
который прослушивает 80- (HTTP -) и 443- (HTTPS -) порты, перехватывает WEB-запросы, потом подключается к серверу и
пересылает запросы компьютеру-клиенту. Также программа генерирует SSL-ключи и SSL-сертификаты с помощью OpenSSL.
Затем, после попытки приконнектиться к сайту (target.gov), браузер проверит SSL-сертификат. Так как сертификаты
совпадать не будут, то браузер юзверя предупредит о неправльном SSL-сертификате. Со стороны взломщика это будет
выглядеть примерно так:
[inf@home ~ ]#webmitm -d
webmitm: relaying transparently
webmitm: new connection from [IP-адрес]
GET [ссылка]/uzerz.php?user=hellknights&password=neskaju1qwerty HTTP/[версия]
Connection: [тип]
Host: www.target.gov
User-Agent: [информация о системе, браузере]
[итд, итд, итд]
Cookie: [кукисы]
Вот так все это выглядит со стороны - перехватывается SSL-коннект, схватив незашифрованные данные.
[Заключение]
В этой статье мы рассмотрели с тобой перенаправление SSH- и HTTP- трафика, с помощью атаки Man in the Middle - четко,
подробно, коротко. Другие программы перенаправления HTTP- и SSH- тафика с помощью MitM ты освоишь быстро, если освоил
и эти :)). Если, что-то было непонятно - то:
- почитай про строение интернет-протоколов
- man и google расскроют тебе глаза :)
Буду очень рад, если этой статьей и я чем-то вам помог и она вам понравилась ;)
[Пост Скриптумы]
[+] http://opennet.ru/man.shtml?topic=sshmitm&category=8&russian=2
man-лист по "sshmitm". Там же есть и ссылки на man ко всему dsniff-пакету.
[+] http://www.monkey.org/~dugsong/dsniff/
тут при желании можно скачать пакет сетевого аудита "dsniff"
[+] http://www.nestor.minsk.by/sr/help/2005/02/160100.html
атаки на SSL, включая MitM-атаку на SSL.
[+] http://protocols.ru/
все о протоколах ;)
[+] http://www.google.com/intl/xx-hacker/
ну и конечно наш хакерский гугл - все на "хакерском языке". Зайти обязательно :))
|
Скрины:
Дата: 16.01.2010
Добавил: Доктор
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
1) Введение, или "что такое SSL"?
SSL или Secure Socket Layer это протокол среднего уровня который разработан
для поддержания безопасности и сохранности обычного TCP/IP соединения. Вообще
SSL накладывается на обычные прикладные протоколы, такие как HTTP, POP, SMTP, итп.
Но его основная черта, это наложение на TCP/IP, более того, именно для последнего
создан популярный API(библиотека) OpenSSL. Вот на примере этой библиотеки, а так
же, без неё, я покажу как происходит процесс соединения.
"Каким боком это будет полезно хаксору?" - скажете вы, ну вы наверное не раз
видели эксплоиты для различных cервисов, вроде Apache/mod_ssl, IIS, и им подобным.
Так вот, для того чтобы хоть как то добраться до ошибки в уязвимой SSL программе,
нужно знать ее работу на самом низком уровне, а именно, представлять себе процесс
"рукопожатия", обмена ключами, сертификатами и тд. Данная статья будет введением
в этот нелегкий процесс.
2) Что же происходит при вводе "https://" в нашем браузере?
Первый этап SSL соединения - рукопожатие. Вот последовательный список
того что происходит при нем:
+----------------------+-----------------+---------------------+
| Клиент | Направление | Сервер |
+----------------------+-----------------+---------------------+
| ClientHello | --------> | ServerHello |
| | | -Certificate |
| | | -ServerKeyExchange |
| | | -CertificateRequest |
| | | ServerHelloDone |
| | <-------- | |
| -Certificate | | |
| ClientKeyExchange | | |
| -CertificateVerify | | |
| [ChangeCipherSpec] | | |
| Finished | --------> | [ChangeCipherSpec] |
| | | Finished |
| | <-------- | Application Data |
| Application Data | <-------> | |
+----------------------+-----------------+---------------------+
Эта таблица была содрана из спецификации SSL*
Поля начинающиеся на символ дефиса являются необязательными. Хотя в большинстве
случаев сертификаты являются обязательным условием для удачного SSL соединения.
Так что же просходит при том же конекте с https сервером? Ты наверное видел
сообщение типа "Принять этот сертификат?" в своем браузере, когда подключался
к подозрительному сайту. Так вот, в наших браузерах существует маленькая база
сертификатов самых авторитетных контор вроде VeriSign. Если сайт, будь то шоп,
будь то багтрак, встречают вас без запроса о принятии сертификата, хоть вы и ввели
https, значит им можно довериться (в большинстве случаев), так как их сертификаты
подписаны одной из авторитетных контор. Если же запрос все таки поступил, значит
сертификат они подписали сами.
Хотелось бы отметить, что в статье я только опишу как послать первый
запрос ClientHello, так как все будет делаться на низшем уровне. Соединение
же на уровне API делается очень просто. Все примеры приводятся в самом пакете
OpenSSL (генерация сертификата, соединение, итд).
3) Уровень 2. Приложение
Чтобы соединиться с любым SSL сервером, достаточно выполнить следующую команду
в шелле:
sslground$ openssl s_client -host i.have.ssl-enabled.com -port
CONNECTED(00000714)
...
Certificate chain
...
Server Certificate
...
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID:
7CED2EE0CBEBF0919523BACE5BCD0051F367E43F73F7ED32F09AFF20
Session-ID-ctx:
Master-Key:
0EC59F73F2479DACD03D38E1D1068995069891174720B76B33ED1AD3
31E97A0E3498120783F542E9E847A7EF
Key-Arg : None
Start Time: 1105080224
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
Cделаем следующие выводы из того что мы увидели
1) Ключ сессии шифруется 2048 битным RSA ключом
2) Соединение шифруется 256 битным ключом сессии алгоритмом AES
3) Aлгоритм SHA играет роль CRC, а именно проверяет, не изменил
ли злой хакс0р данные сессии (например сидит между клиентом/cервером)
4) Версия протокола SSLv3.1 которая теперь имеет название TLSv1
Если вам интересно, можете попытаться соединиться с серваком используя опции
-ssl2/-ssl3/tls1, чтобы проверить, какие версии он поддерживает. Так можно проверить
поддержку уязвимых версий (ssl2). Для полного списка опций наберите man s_client.
А теперь попробуем запустить сервер сами, при помощи следующей команды:
sslground$ openssl s_server -accept 443 -cert /путь/к/cертификату.pem
-HTTP /путь/к/html_файлу.html
Все, теперь к такому вот минисерваку можно подключиться браузером, и вы увидите
html страницу. Все это дело шифруется сильнейшими алгоритмами. Используется порт 443.
4) Уровень 1. API
Не буду тут разглагольствовать (сказанул), сразу перейду к процессу соединения
1) Создаем socket (socket())
2) Коннектимся по обычному TCP/IP (сonnect())
3) Готовим библиотеку (загружаем сертификаты если надо)
4) Будучи соединенными, делаем 2-е соединение (SSL_connect())
5) Обмениваемся инфой (SSL_send(), SSL_recv())
6) Обрываем соединение (SSL_shutdown(), SSL_free())
К статье я приложил пример "pssl.c" всего этого безобразия. Теперь проверим:
sslground$ gcc -o pssl pssl.c -lssl
sslground$ ./pssl
--SSL Connection established
--Getting peer certificate
--Server: Apache/1.3.31 (Unix) mod_ssl/2.8.17 OpenSSL/0.9.7c
--Writing cert to cert.crt
--Shuting down
Прога просто соединяется с сервером и читает название сервиса http.
5) Уровень 0. Следуем спецификации.
Вот мы и добрались до того уровня, где все делается без библиотеки OpenSSL.
По сути, если хорошо разберёшься с этим уровнем, спокойно можешь писать
свою версию API SSL :).
На будущее, если ты хочешь видеть, какие циферки и данные идут между 2мя
SSL приложениями, научись правильно травить на это дело сниффер. Именно так
я сооброжал что же там происходит:
sslground$ tethereal -i lo -VR ssl -x | less
Вот пример того как сниффер ethereal выводит данные SSL. Распишу опции более
подробно:
'-V' - вывести все данные в виде дерева (запустите, поймете)
'-R ssl' - выводить данные только SSL протокола (остальной мусор не нужен)
'-x' - все печатается в виде hex кодов
Если же твоя прога слушает на отличном от 443-го порту, запускай так:
sslground$ tethereal -i lo -d tcp.port==31337,ssl -VR ssl -x | less
5.1) СlientHello
Вот собственно и первый пакет, который отсылается любым SSL клиентом:
unsigned char client_hello[]=
"\x16" /* type - handshake */
"\x03\x00" /* SSLv3 */
"\x00\x37" /* length */
"\x01\x00" /* client hello */
"\x00\x33" /* length */
"\x03\x00" /* SSLv3 */
"\x01\x01\x01\x01" /* random.gmt.unix_time */
/* start random.bytes*/
"\xaa\xaa\xaa\xaa\xbb\xbb\xbb"
"\xbb\xcc\xcc\xcc\xcc\xdd\xaa"
"\xdd\xdd\xee\xee\xee\xee\xff"
"\xff\xff\xff\xaa\xaa\xaa\xbb"
/* end random.bytes*/
"\x00" /* session id length */
"\x00\x0c" /* cipher suites length */
"\x00\x00" /* NULL_WITH_NULL_NULL */
"\x00\x39" /* DHE_RSA_WITH_AES_256_CBC_SHA */
"\x00\x09" /* RSA_WITH_DES_CBC_SHA */
"\x00\x35" /* RSA_WITH_AES_256_CBC_SHA */
"\x00\x05" /* RSA_WITH_RC4_128_SHA */
"\x00\x04" /* RSA_WITH_RC4_128_MD5 */
"\x01\x00"; /* comp methods length / method */
Опишу подробнее:
"\x16" - Тип содержимого, 0x16 для рукопожатия. Там могут быть
0x15 (ошибки), 0x17(данные) и другие.
"\x03\x00" - Используется SSLv3
"\x00\x37" - размер пакета
"\x01\x00" - Тип пакета, 0x01 для ClientHello. Другие варианты могут
быть: Certificate(0x0b), CeritificateVerify(0x0f),
СlientKeyExchange(0x10), Finished(0x20).
"\x01\x01\x01\x01" - дата, нам не важно, пишем как хотим
"\xaa\xaa\x....." - 28 случайных байт. Вообще используется для
генерации ключа сессии. Но опять же, нам это не
важно.
"\х00" - Размер ID сесии (опускаем, поэтому и равно 0). ID сессия
в SSL используется для восстановления оборванных соединений.
"\x00\x0c" - размер следующих данных cipher_suites. А именно 12 байт.
Если посчитаете кол-во байт ниже этой строки, вы заметите
что оно равно 12 (несчитая последней строки).
Далее идут обозначения поддерживаемых клиентом шифров. Их можно посмотреть
в исходниках SSL (как я и делал).
"\x01\x00" - 0х01 для размера методов компрессии, 0х00 для того чтобы
показать, что никаких методов не применять.
Как видите, ClientHello говорит серверу какие желает использовать шифры, а также
даёт данные для генерации ключа сессии (ключ который и шифрует последующие данные).
6) Программа.
К статье приложена еще одна маленькая программа. Она собирает информацию о
поддерживаемых шифрах сервера. Это маленький аналог проги THCSSLCheck, написанной
мембером команды THC johny cyberpunk. Кстати именно он написал популярный эксплоит
для Windows IIS/SSL.
7) Доки
1] SSLv2 specification:
http://www.netscape.com/eng/security/SSL_2.html
2] SSLv3 specification:
http://wp.netscape.com/eng/ssl3/3-SPEC.HTM
3] TLSv1 specification:
ftp://ftp.isi.edu/in-notes/rfc2246.txt
4] OpenSSL API programming intro:
http://www.rtfm.com/openssl-examples
5] Ethereal packet analyzer:
http://www.ethereal.com
(Эксклюзивом для Inattack.ru. 4king)
PS: Для компиляций приложенных прог просто наберите 'make' в папке с ними.
PS2: netri... Читать дальше »
|
Скрины:
Дата: 16.01.2010
Добавил: xakep
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
Введение в локальные сети
Обзор
Семейство сетевых продуктов LANtastic разработано с учетом неопытности пользователей и обеспечивает простоту установки и управления сетью. Однако, без понимания основных аспектов функционирования локальной сети даже эта простота не поможет. При возникновении каких-либо проблем их трудно решить, не зная основ сетевых технологий.
Цели
Целью данного обзора является попытка донести до пользователей основы сетевых концепций. В качестве объекта рассмотрения выбрана наиболее распространенная технология Ethernet. В книге не содержится достаточно полной информации об устройстве и функционировании сетей, это потребовало бы очень значительного объема и времени. Многие концепции рассмотрены лишь мимоходом. Тем не менее мы надеемся, что, прочтя этот краткий обзор, вы узнаете по крайней мере:
- основы организации сети Ethernet на основе коаксиального кабеля и витой пары;
- определения и описания основных типов кабелей;
- роль сетевых адаптеров при организации сети;
- определение и описание основных типов топологии сети;
- определение и описание трех основных классов Ethernet;
- описание разъемов для подключения кабеля UTP;
- описание кабелей UTP;
- правило Ethernet 3-4-5;
- разницу между сервером и рабочей станцией;
- основы распределенных сетей;
- модель OSI и ее применение к LANtastic;
- роль программных модулей LANtastic.
Что такое ЛВС?
Локальная сеть (ЛВС) представляет собой коммуникационную систему, позволяющую совместно использовать ресурсы компьютеров, подключенных к сети, таких как принтеры, плоттеры, диски, модемы, приводы CD-ROM и другие периферийные устройства. Локальная сеть обычно ограничена территориально одним или несколькими близко расположенными зданиями. Каждый компьютер в составе ЛВС должен иметь следующие компоненты:
- сетевой адаптер;
- кабель;
- сетевая операционная система (сетевые программы).
Сетевые адаптеры
Сетевые адаптеры и кабели являются аппаратной основой организации компьютерных сетей, их нормальная работа жизненно важна для сети. С кабелями и адаптерами связано обычно 80% неполадок в сети.
В каждом компьютере должен быть установлен сетевой адаптер, обеспечивающий подключение к выбранному типу кабеля.
Функцией сетевого адаптера является передача и прием сетевых сигналов из кабеля. Адаптер воспринимает команды и данные от сетевой операционной системы (ОС), преобразует эту информацию в один из стандартных форматов и передает ее в сеть через подключенный к адаптеру кабель.
LANtastic не предъявляет к сетевым адаптерам каких-либо специфических требований. Вам достаточно иметь адаптеры одного из следующих типов:
-
Artisoft NodeRunner или NodeRunner Pro
- это 16-битовые адаптеры, полностью соответствующие стандарту 802.3 Ethernet и 100% совместимые с адаптером NE2000 (Eagle Technology). С адаптерами поставляются драйверы NDIS и ODI. Адаптеры существуют в различных модификациях в зависимости от типа используемого кабеля;
-
Рекомендуемые Artisoft адаптеры
- эти адаптеры имеют драйверы, совместимые с Artisoft NetBIOS. Драйверы для таких адаптеров включаются в комплект поставки LANtastic.
-
Адаптеры, поддерживающие спецификацию NDIS
- данная спецификация задает требования к драйверу сетевого адаптера, обеспечивающие независимость от оборудования и протокола.
Конфигурация адаптера
Каждый адаптер, устанавливаемый в компьютер, должен нормально работать с остальной частью ПК. Нужно всегда обращать внимание на два важнейших параметра каждого устройства, устанавливаемого в компьютер.
- I/Obase
- Базовый адрес ввода-вывода является "каналом", по которому адаптер взаимодействует с другими компонентами компьютера. Каждое устройство должно использовать уникальный диапазон адресов ввода-вывода.
- IRQ
- Номер линии запроса прерывания. Запрос прерывания является сигналом, передаваемым устройством для того, чтобы привлечь внимание процессора (прервать его текущую деятельность). Такой сигнал обычно подается при появлении новых данных или завершении той или иной операции. Каждое устройство должно использовать уникальное значение IRQ.
В таблице 1 приведены адреса ввода-вывода и номера IRQ, используемые различными устройствами.
Таблица 1. Адреса ввода-вывода
| Устройство |
IRQ |
IOBase |
Адреса памяти |
Канал ПДП (DMA) |
| Системный таймер |
0 |
|
|
|
| Клавиатура |
1 |
|
|
|
| Коммуникационный порт COM1 |
4 |
3F8-3FF |
|
|
| Коммуникационный порт COM2 |
3 |
2F8-2FF |
|
|
| Параллельный (принтерный) порт LPT1 |
7 |
378-37F |
|
|
| Параллельный (принтерный) порт LPT2 [На компьютерах за исключением XT] |
5 |
278-27F |
|
|
| Дисковый контроллер XT |
5 |
320-32F |
C800-CBFF |
3 |
| Дисковый контроллер AT |
14 |
1F0-1F8 |
|
|
| Контроллер SCSI |
различные |
|
|
1,3 |
| Адаптер VGA |
2,9 или без IRQ |
3C0-3DA |
A0000-BFFFF |
0 |
| VGA BIOS |
|
|
C0000-C7FFF |
|
| Адаптер EGA |
2,9 или без IRQ |
3C0-3CF |
A0000-AFFFF B0000-BFFFF |
0 |
| EGA BIOS |
|
|
C0000-C7FFF |
|
| Адаптер MDA |
|
3B0-3BF |
B0000-B3FFF |
0 |
| Адаптер Hercules |
|
3B4-3BF |
B0000-BfFFF |
|
| Адаптер CGA |
|
3D0-3DF |
B8000-B3FFF |
0 |
| Буфер символов CGA, EGA |
|
|
B8000-BBFFF |
|
| Игровой порт (джойстик) |
|
200-20F |
|
|
Сетевые кабели
Кабель обеспечивает канал связи компьютера с остальными машинами сети. При установке кабелей нужно точно следовать спецификациям. Пренебрежение этим правилом может принести очень много неприятностей. Отметим разницу между кабелем и кабельным сегментом говоря о кабеле, будем всегда иметь в виду отрезок провода, соединяющего два узла сети; сегментом же будем называть весь комплект кабелей от одного конца сети до другого (между терминаторами). Терминаторы представляют собой резисторы, устанавливаемые на обоих концах сегмента для согласования волнового сопротивления кабеля. Сигнал, дошедший до конца сегмента, поглощается терминатором - это позволяет избавиться от паразитных отраженных сигналов в сети. Если терминаторы не устанавливать, отраженный от конца кабеля сигнал снова попадает в кабель - этот отраженный сигнал будет являться в данном случае помехой и может породить множество проблем вплоть до полной неработоспособности сети.
- Кабель на основе скрученных пар (витая пара, TP).
- Кабель содержит две или более пары проводов, скрученных один с другим по всей длине кабеля. Скручивание позволяет повысить поме... Читать дальше »
|
Скрины:
Дата: 16.01.2010
Добавил: xakep
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
|
МИР ПК #12/99
У вас на работе или дома есть два ПК или более,
работающих в среде Windows 9х. Хотя они и находятся в одном помещении,
но без объединения их в сеть «дружбы» между ними не достичь.
Создать сеть — задача не столь уж сложная, как
вы, возможно, полагаете. Кроме того, вы получите преимущества, стоящие
приложенных усилий. Простая одноранговая сеть, в которой каждый ПК
может выступать в качестве сервера, позволяет пользователям совместно
работать с файлами и печатать на принтерах, а при установке
специального ПО — иметь доступ в Internet.
Беспроводные сети, как правило, просты в
установке и работе, но традиционные сети Ethernet работают быстрее
(пропускная способность — 10 или 100 Мбит/с) и их легче расширить.
Чтобы организовать одноранговую сеть, вам понадобятся сетевые платы для
каждого ПК, концентратор (мультипортовое устройство, к которому
подключаются все ПК), сетевые драйверы и ПО, входящее в состав Windows
9х.
Конечно, можно купить все компоненты отдельно,
однако многие производители продают удобные комплекты начального
уровня, включающие все необходимое оборудование и инструкции по
объединению двух-трех ПК.
Точная последовательность действий зависит от производителя, но общий процесс объединения компьютеров в сеть следующий.
Стэн Мястковски
1. Составьте план сети.
Сетевой концентратор выступает в роли
регулировщика движения данных в сети, поэтому необходимо поместить его
в центре (между всеми ПК) и рядом с источником питания. Убедитесь, что
кабели, которыми вы будете подключать компьютеры к портам
концентратора, имеют достаточную длину: не будут путаться под ногами и
их не придется сдвигать.
Установите сетевые платы.
Выключите все ПК и выньте вилки из сетевых розеток.
Чтобы защитить сетевые платы от электрического заряда, способного
вывести их из строя, наденьте антистатический браслет. Найдите в каждом
из ПК свободный разъем (в зависимости от типа сетевой платы может
потребоваться ISA- или PCI-разъем), удалите расположенную напротив него
на задней стенке корпуса металлическую пластину, вставьте плату,
убедитесь, что она плотно установлена в разъеме, и закрепите ее винтами.
Подсоедините кабели.
Подключите к каждому ПК сетевой кабель, протяните
последний от компьютера к концентратору и подсоедините к одному из его
портов. После установки всех соединений, если это необходимо,
подключите концентратор к сети питания и включите его.
Установите сетевое ПО.
Подключите ПК к источнику питания и включите его.
Система Windows 9х должна определить новую сетевую плату и попросить
указать местоположение ПО. В зависимости от установленной версии
Windows порядок действий, которые необходимо выполнить, может несколько
отличаться, поэтому внимательно читайте появляющиеся на экране
инструкции. Большинство сетевых плат или комплектов поставляются вместе
с драйверами на дискете или компакт-диске. Укажите ОС надлежащий
дисковод. Во время установки драйвера на экране будут появляться
сообщения — может также потребоваться вставить компакт-диск с
дистрибутивом Windows 9х. В некоторый момент времени необходимо будет
ввести уникальное имя компьютера (для идентификации его в сети) и имя
рабочей группы (как правило, лучшим выбором обычно является просто
«workgroup»). Для каждого ПК задайте одно и то же имя рабочей группы, в
противном случае компьютеры не смогут распознать друг друга в сети. По
запросу перезагрузите ПК.
Выберите сетевой пароль.
После перезагрузки Windows попросит задать сетевое
имя пользователя и пароль. В качестве имени пользователя выберите свое
имя (или название ПК). Если пароль не требуется, то просто нажмите
клавишу <Enter>.
Совместное использование ресурсов.
Чтобы другие компьютеры в сети имели доступ к
файлам вашего ПК или к подключенному к нему принтеру, необходимо
разрешить совместное использование ресурсов. Сначала щелкните правой
кнопкой мыши на находящемся на Рабочем столе значке «Сетевое окружение»
(Network Neighborhood), выберите пункт меню «Свойства» (Properties),
нажмите кнопку «Доступ к файлам и принтерам» (File and Print Sharing) и
включите необходимую опцию. Дважды нажмите ОК. В этом месте Windows
может вас
попросить еще раз вставить компакт-диск с
дистрибутивом ОС — будут скопированы необходимые файлы, после чего
потребуется еще раз перезагрузить компьютер. Чтобы разрешить доступ с
других ПК, отметьте диски и каталоги, которые вы открываете для
совместного применения. Дважды щелкните мышью на значке «Мой компьютер»
(My Computer), выделите правой кнопкой мыши диск или файл, к которому
необходимо разрешить
доступ, выберите пункт «Доступ» (Sharing),
перейдите к закладке «Доступ» и заполните все необходимые поля. Если вы
планируете использовать в сети подключенный к другому компьютеру
принтер, то сейчас самый подходящий момент для его установки. В
диалоговом окне «Мой компьютер» щелкните мышью сначала на значке
«Принтеры», а затем дважды на значке «Установка принтера» (Add
Printers). Для установки сетевого принтера следуйте далее появляющимся
на экране инструкциям. Если вы не знаете путь к сетевому принтеру, то,
чтобы найти его в сети, используйте кнопку «Обзор» (Browse).
Установите дополнительное ПО.
Большинство сетевых комплектов начального
уровня могут поставляться с дополнительным ПО (например, с программами
для совместного доступа в Internet), которое позволяет двум или более
ПК работать с одним модемом и подключаться к Internet через один из
компьютеров. Вставьте входящий в состав комплекта компакт-диск и
следуйте появляющимся на экране инструкциям. Если при эксплуатации сети
вы столкнулись с какими-либо проблемами, прежде всего проверьте
соединения. Все подключено надлежащим образом, но компьютеры «не видят»
друг друга — проверьте, правильно ли задано совместное использование
ресурсов (пункт 6). Некоторые сетевые платы поставляются вместе с
утилитами диагностики, и если такая программа входит в комплект
поставки вашей платы, то запустите ее. Вам по-прежнему не удалось найти
причину неисправности — позвоните в службу технической поддержки.
|
Скрины:
Дата: 16.01.2010
Добавил: Доктор
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
Введение
Не так давно я купил комплект "Wireless Bundle" состоящий из
беспроводного NAT маршрутизатора и карты PCMCIA 802.11b. Будучи
устройством, рассчитанным на непрофессионального потребителя, мне было
достаточно просто его подключить и настроить для работы с моей домашней
сетью. Трудности начали возникать когда я попробовал защитить это
соединение, а также при попытке защиты всей остальной части локальной
сети от любого вида вторжений.
Для меня был очевиден выбор IPsec по WEP. Поскольку WEP считается слабо
защищенной (секретный ключ очень легко восстановить), моя PCMCIA карта
имела встроенное программное обеспечение, которое отклоняло соединения
при включенном WEP. Проблема была хорошо задокументирована, но
производитель не выпустил никаких обновлений закрывающих эту "дыру".
В Интернет я нашел несколько доступных ресурсов для настройки IPsec
VPN, но в моем случае, ни один из них мне не подходил. Поэтому я хочу
поделиться своим опытом и надеюсь, что это будет полезно для других.
Изолирование беспроводной сети
Моя домашняя сеть имела следующую конфигурацию. Был установлен
двухканальный шлюз с протоколом DHCPD для назначения приватных IP
адресов любым компьютерам, подключенным к сети. Ко мне мог прийти гость
и, подключив свой ноутбук к сети, свободно "бродить" по Интернету. В
общем, вполне типичная конфигурация.
Первым шагом было отделение беспроводной сети от остальной части моей
домашней сети. Это можно сделать, установив еще одну сетевую карту и
назначив ей другой диапазон адресов. К примеру, существующая сеть
использует диапазон 192.168.1.х, а новая карта - 192.168.2.1. При
правильной настройке брандмауэра и IPsec, данный сегмент может быть
изолирован от остальной части домашней сети.
Поскольку мой беспроводной NAT маршрутизатор характеризовался как
маршрутизатор/коммутатор, то его функции как маршрутизатора (DHPCD,
NAT) должны были быть заблокированы. Для изменения настроек
маршрутизатор имеет web-интерфейс. Я также дал название wi-fi сети.
Маршрутизатор имел четыре Ethernet порта, обозначенных "LAN", и один
порт "WAN". Новая Ethernet плата (192.168.2.1) подключена к одному из
"LAN" портов.
Портативной ЭВМ был назначен постоянный IP адрес 192.168.2.10.
Транспортный Режим против Туннельного Режима
Эта часть смутила меня больше всего, т.к. большинство изданий (включая
руководство по FreeBSD) описывают IPsec туннели в терминах VPN - т.е.
два шлюза, соединяющие две подсети по безопасному туннелю, используя
виртуальный интерфейс. Сначала я тоже думал, что это транспортный
туннель, использующий сквозное шифрование пакетов. Но все оказалось не
совсем так. Все пакеты между портативным компьютером (хостом) и шлюзом
(192.168.2.10 <-> 192.168.2.1) действительно были зашифрованы.
Однако пакеты, посылаемые в остальную часть Интернет, не были
зашифрованы. (192.168.2.10-> www.securitylab.ru). Но то, что хотел
я, было зашифрованным туннелем между хостом и шлюзом, которые отсылает
пакеты от хоста до остальной части Интернет.
Любой исходящий из хоста пакет (192.168.2.10-> www.securitylab.ru),
должен быть зашифрован и инкапсулирован в другом пакете, пересылаемом к
шлюзу. При получении шлюзом этого пакета, он должен дешифровать его и
отправить на www.securitylab.ru.
Возвращаемый пакет (www.securitylab.ru -> 192.168.2.10) должен быть
зашифрован и инкапсулирован шлюзом, а затем переслан на хост.
(192.168.2.1-> 192.168.2.10), после чего на хосте этот пакет
дешифруется и читается его содержимое.
Настройка шлюза
Ниже будет показано, как настраивается шлюз.
A. Перекомпиляция ядра для поддержки IPsec происходит при добавлении следующих строк в файл конфигурации ядра:
options IPSEC
options IPSEC_ESP
Проведите перекомпиляцию, переустановку и перезагрузите компьютер с новым ядром. Добавьте следующие строки в файл /etc/rc.conf:
ipsec_enable="YES"
ipsec_file="/etc/ipsec.conf"
B. Настройка защитной политики. Создайте файл /etc/ipsec.conf со
следующим содержимым. В этом примере, 192.168.2.10 - хост, и
192.168.2.1 - шлюз.
flush;
spdflush;
spdadd 192.168.2.10/32 0.0.0.0/0 any -P in ipsec
esp/tunnel/192.168.2.10-192.168.2.1/require;
spdadd 0.0.0.0/0 192.168.2.10/32 any -P out ipsec
esp/tunnel/192.168.2.1-192.168.2.10/require;
Для применения защитной политики запустите 'setkey-f/etc/ipsec.conf.
С. Установка и конфигурирование Racoon.
Racoon находится в /usr/ports/security/racoon. Проводим установку.
После инсталляции, создайте /usr/local/etc/racoon/psk.txt. В этом файле перечислены секретные ключи для ваших хостов. Например:
192.168.2.10 SecretKey
Желательно создавать секретные ключи трудные для подбора. В Интернете существуют различные ресурсы, посвященные этому вопросу.
Теперь, необходимо создать файл /usr/local/etc/racoon/racoon.conf. Я
скопировал файл racoon.conf.dist, после чего изменил и модифицировал
директиву "listen" и значения "life time" в директивах "remote
anonymous" и "sainfo anonymous".
Настройка Windows компьютеров
Windows 2000 и XP имеют достаточно много различных диалогов и мастеров, но конечный результат их действия один и тот же.
Зайдите в меню "Start" и и нажмите "RUN". Наберите mmc и ^lt; ENTER>
Выберите "Console" (или "File")-> Add/Remove Snap In. Выберите "Add"
Выберите "IP Security Policy Management" и нажмите "Add".
Выберите "Local Computer", и нажмите "Finish".
Нажмите "Close" для закрытия диалога "Add standalone Snap-in". Выберите "ОК" для закрытия диалога Add/Remove Snap-in.
Выполнив вышеописанные операции, мы добавили встроенную защитную политику. Теперь необходимо настроить wifi политику.
Выберите "IP Security Policies" на "Local Machine", нажмите правую кнопку мыши и выберите "Create IP Security Policy"
Дайте название защитной политике (в нашем примере 'wifi'). Нажмите "Next".
Снимите отметку с "Activate" и нажмите "Next".
Снимите выделение с "Edit Properties". Нажмите "Finish"
Теперь наряду с "Client", "Secure Server" и "Server" вы должны иметь политику "wifi". После, мы определим правила фильтрации:
Нажмите правую кнопку мыши на вкладке "IP Security Policies" окна
"Console Root" и выберите "Manage IP filter lists and filter actions".
Нажмите "Add"
Назовите этот список фильтров "OutboundIPsec". После, нажмите "Add"
Следуйте за "мастером", и выберите значение "My IP Address" как
"Source", "Any IP Address" как "destination address" и выберите любой
тип протокола. Проверьте окно "Edit Properties" и снимите галочку с
"mirrored".
Теперь в списке OutboundIPsec должен быть один фильтр. Нажмите "Close".
Добавьте второй список, и назовите его InboundIPsec, повторяя
вышеописанные шаги. На этот раз, добавьте фильтр с "Any IP Address" как
"Source", a "My IP Address" как «destination adress».
Теперь, для применения, созданных фильтров, мы создадим в политике следущее:
Сделайте двойной щелчок мышью на "wifi” политике.
Нажмите «add», чтобы добавить новые «IP Security Rules».
Выберите переключатель "The tunnel endpoint is specified" и введите шлюз (кроме, 192.168.2.1). Нажмите «Next».
Выберите «LAN» и нажмите «Next»
Выберите "Use this string to protect the key exchange", и введите секретную фразу. Нажмите «Next».
Выберите созданный вами список фильтров "OutboundIPsec". Нажмите «Next».
Выберите «Require Security». Нажмите «Next».
Снимите выделение с "Edit properties". Нажмите "Next". Повторите все,
описанные выше шаги, только введите хост (кроме, 192.168.2.10) в шаге
3, и "InboundIPsec" списке фильтра в шаге 6. Все остальное то же самое.
Теперь - все. Ниже я подведу итоги того, что мы сделали выше.
"Console root" имеет подразделение, называемое "IP Sec Policies on Local Machine".
"IP Sec Policies" должен иметь большое количество каталогов, один из которых называют "wifi".
Двойное нажатие на "wifi", вызывает его свойства. В них должны быть два
правила, оба из которых проверены и имеют следующие свойства:
Property InboundIPsec OutboundIPsec
------------------------------------------------------------
Filter Action Require Security Require Security
Authentication Preshared Key Preshared Key
Tunnel Setting 192.168.2.10 192.168.2.1
Connection Type LAN LAN
После установки, утилиты ping и tracert работают прекрасно, под tcpdump
все ping пакеты показываются зашифрованными, но при этом никакие сайты
не доступны. Отключите встроенный "IP брандмауэр" в настройках TCP/IP
для wifi интерфейса. В справочных файлах указывается, что он
конфликтует с VPN туннелями.
Команда ping возвращает значение "Negotiating IPsec" в течение
нескольких секунд после сообщения "Request timed out." Продолжайте
пингование с флагом -t. Тем временем, перезапустите службу IPsec
политики. Я не уверен, по каким причинам это происходит, но может
потребоваться от нескольких секунд до нескольких минут, прежде чем
команда ping начнет нормально работать.
Когда соединение некоторое время простаивает, то пропадает возможность
соединения. Тоже самое, происходит и при простое IPsec туннеля. И может
понадобиться некоторое время, чтобы повторно соединиться (см. выше). Я
не знаю способов вынудить туннель оставаться постоянно открытым, кроме
постоянной пересылки сообщений через него. Это можно сделать при
наличии открытого ssh сеанса или часто перезагружаемой web страницы.
Выводы
Теперь вы имеете безопасное wifi подключение между вашей портативной
ЭВМ и вашим шлюзом. Любой, пытающийся сниффить беспроводную точку
доступа, увмдеи пакеты, идущие между хостом и шлюзом и от шлюза, только
в зашифрованном виде.
Я надеюсь, что данная статья оказалась полезной для Вас.
|
Скрины:
Дата: 16.01.2010
Добавил: www
Комментарии: (0)
|
| |
|
|
|
|
|
|
|
/* Вступление */
Участники Defcon 2002 провели небольшое исследование (вообще то
это больше походило на спортивное соревнование) на предмет
проникновения в беспроводные сети. Изучив более 500 точек доступа в
округе, они выявили интересную статистику: только около 30%
беспроводных сетей защищены протоколом WEP; в каждой пятой сетке
значение ESSID было выставлено «по умолчанию»; а еще было выявлено, что
20% беспроводных сетей абсолютно никак не защищены от доступа извне. На
следующем Defcon 2003 эта статистика вновь подтвердилась (исследовались
беспроводные сети Лас-Вегаса и Лос-Анджелеса). Такое положение дел
характерно не только для США, но и для Европы, в том числе и России.
Эксперты в области безопасности беспроводных сетей сходятся во мнении,
что только около десяти процентов беспроводных сетей защищены чем-то
большим, чем протокол WEP и фильтрацией MAC-адресов.
/* Готовимся к атаке */
Интересная статистика, не правда ли? Получается, что, имея ноутбук,
кое-какие программы и немного знаний, можно проникнуть в 90% сетей
802.11. А имея более глубокие знания по беспроводным сетям и обладая
некоторыми хакерскими навыками (социальной инженерией, например),
процент удачных проникновений стремится к 100. Хочу поделиться с тобой
некоторой информацией по этому поводу.
Что нужно для WiFi-хакинга:
- ноутбук;
- WiFi-карта с набором микросхем Prism2 (в принципе, можно работать и с
другими, например, Hermes, но лучше все же Prism, т.к. под такие карты
пишется большинство необходимого нам софта) и с возможностью
подключения внешней антенны;
- антенна, а лучше две: всенаправленная и узконаправленная;
- автомобиль.
Ну, это в идеале, но может пройти и такой вариант: ноутбук со
встроенным модулем wifi, две ноги (еще один вариант – домашний комп +
позаимствованная у друга карта + присоединенная к ней наспех сделанная
своими руками направленная антенна, которую с балкона нацеливаешь на
офис какой-нибудь находящийся неподалеку фирмы ; ). Не стоит также
недооценивать возможности КПК, поэтому если у тебя есть наладонник с
wifi-модулем (желательно iPac или Zaurus, работающие по никсами), то он
может весьма пригодится.
Какую ось выбрать для этого дела? Лучше если не винду. На то есть
несколько причин, но самая главная – это отсутствие нормального софта
под нее. Под словом «нормального» я понимаю качественного и
бесплатного. Больше всего нужных нам прог написано под линукс, но так
же вполне можно найти неплохой софт под фряху. Знаю, многие сейчас
могут мне возразить, утверждая, что под винду есть проги, бесплатные,
которыми можно легко и непринужденно взламывать wifi-сети, имея в виду
NetStumbler, Aircrack для взлома WEP. С их помощью можно взломать те
самые 70% сетей, а никсы – это трата времени и т.п. и пр. Да, конечно,
софтом по винду пользоваться легко и просто, но ты должен знать, что
возможности того же NetStumblera весьма ограничены по сравнению,
например, с Kismet под линукс, нормальный админ легко сможет защитить
сеть от Нетстамблера. Для проникновения в хорошо защищенную сеть винда
уж точно не годится.
/* Выбор цели */
О том, как отыскивать сети, уже написано много раз, поэтому не буду
здесь все это повторять. Вардрайвишь по центру города в поисках
беззащитной, находишь и взламываешь ее, и вот тебе доступен канал в
инет или еще что-нибудь интересненькое. В случае чего быстро сваливаешь…
Но возможен и другой вариант: тебе нужно проникнуть в беспроводную сеть
определенной организации. Ты не знаешь, насколько хорошо она защищена,
с чего же начать? Первое, что необходимо предпринять - провести
интернет-разведку. Нужно узнать как можно больше о том кто занимается
вопросами ИТ в организации, как они этим занимаются, т.е. накопить как
можно больше информации о своем противнике. Зачем это может
пригодиться? Во-первых, можно нарыть кучу полезной для себя информации,
касающейся используемых фирмой технологий защиты. Во-вторых, знание
имен должностных лиц компании может пригодиться при использовании
социнженерии.
Поищи так же информацию на вардрайверских сайтах об интересующей тебя сетке.
Далее следует провести осмотр местности. Нужно выявить наиболее удобное
место для атаки. Бывает так, что сеть никак не защищена, но
присоединится к ней можно только находясь в непосредственной близости
от нее. В этом случае тебе понадобится мощная остронаправленная
антенна. Можно также пойти на более экстремальные действия: под
каким-нибудь предлогом проникнуть внутрь здания и совершить взлом «изнутри», но в этом случае нужно сделать все «по-тихому», т.к. возможно наличие системы IDS.
/* Изучаем трафик */
Рассмотрим несколько прог для обнаружения сетей и анализа их трафика.
Существует два способа обнаружения беспроводных сетей: метод активного
сканирования и метод пассивного сканирования. Активное сканирование
представляет собой посылку пробного запроса. В фрейме-ответе содержится
такая информация как ESSID, канал передачи данных, информация о
включенном или выключенном протоколе WEP, уровень сигнала, скорость
передачи данных. Именно так действуют NetStumbler и MiniStumbler.
Проблема в том, что админ легко может настроить точку доступа так, что
она не будет отвечать на подобные запросы, таким образом, она станет
невидимой для NetStumbler’а. Кроме того, сигнатурные IDS выявляют
сканирование Нетстамблером, так что ты можешь привлечь к себе внимание
используя его. Еще один трюк, который может предпринять админ – это
посылка поддельного фрейма-ответа с заведомо несуществующими данными на
твой фрейм-запрос, чтобы ввести тебя в заблуждение. Это можно
реализовать, например, с помощью проги File2Air написанной Джошуа
Райтом (Joshua Wright). Еще один минус активного сканирования – это
высокий расход заряда аккумулятора.
Пассивное сканирование использует режим мониторинга wifi-карты. Оно
состоит в перехвате трафика проходящего по всем каналам. Т.е. это
сниффинг. Лучшим инструментом для пассивного сканирования, по моему
мнению, является Kismet, созданная Майком Киршоу (Mike Kershaw) . По
сути, эта прога предназначена для анализа трафика wifi и создания
систем IDS. Kismet поддерживает все карты, умеющие работать в режиме
rfmon, ее можно поставить на Linux, в том числе на дистрибутивы для
КПК, FreeBSD и OpenBSD, MacOSX (и даже на винду, с помощью Cygwin’а).
Найти последнюю версию Kismet можно на http://www.kismetwireless.net .
Прежде чем собирать Kismet настоятельно рекомендую тебе обзавестись
(если, вдруг, у тебя его нет) Ethernal’ом, который пригодится для
изучения дампов, сформированных Kismet. Если у тебя есть GPS-приемник,
то тогда неплохо установить еще и GpsDrive, интегрирующий с Kismet c
ним. Компиляция Kismet весьма проста и не должна вызвать каких-либо
сложностей. Если будет что-то непонятно, то прочитай README, там все
очень подробно расписано.
Для настройки Kismet под наши нужды открываем /usr/local/etc/kismet.conf. Здесь нужно сделать несколько вещей:
- отключить фильтрацию MAC-адресов;
- разрешить устанавливать соединения с IP 127.0.0.1;
- выставить maxclient равным 1;
- установить в значение source источник перехватываемых данных;
- настроить интервал между операциями записи;
- параметры noiselog и beaconlog выставь в значение false – сэкономишь место на диске;
- если необходимо, настрой GPS;
- не забудь наделить правами запуска Kismet пользователя, под которым
ты обычно работаешь, если конечно, не собираешься работать под рутом.
Остальные настройки не так важны для нас.
Итак, какими полезными умениями обладает эта прога. Во-первых, она
выводит информацию о том, что точка доступа имеет конфигурацию «по
умолчанию», вылавливает пробные запросы «затерявшихся» хостов, а так же
пробные запросы Нетстамблера, может на лету расшифровывать пакеты, если
задать правильный WEP, а в случае обнаружения IP-адресов, определяет,
какой протокол применяется для их распознания (ARP, TCP, UDP или DHCP).
Во-вторых, она генерирует дампы в формате pcap, что позволяет
просматривать их затем с помощью анализатора сетевых протоколов
Ethernal.
Существует еще множество программ, умеющих обнаруживать беспроводные
сети стандарта 802.11, среди них я бы выделил такие инструменты как
Airfart, консольная тулза WifiScanner тоже, на мой взгляд, весьма
неплоха. Они обе работают только на картах с набором микросхем Prism и
нуждаются в дровах linux-wlan-ng.
/* Обходим барьеры */
Простейшая защита сети wifi от незаконного вторжения может
осуществляться с помощью таких методов как: скрытие ESSID сети от
посторонних глаз, фильтрация MAC-адресов и фильтрация протоколов. Давай
посмотрим, что мы можем противопоставить этому.
Если сеть закрытая, то ее ESSID (Extended Service Set ID – служебный
идентификатор сети) не фигурирует в циркулирующих в ней фреймах. Не
зная ESSID сети, взломщик не может присоединиться к ней. На самом деле
ESSID присутствует в запросах на повторную аутентификацию и повторное
присоединение, а значит можно узнать ESSID, послав поддельный фрейм
деаутентификации хосту от MAC-адреса точки доступа. Затем нужно
перехватить фрейм посылаемый хостом, содержащий интересующий нас ESSID.
Реализовать это легко можно с помощью утилиты essid_jack содержащейся в
комплекте программ AirJack. В своей статье о DoS-атаках в сетях WiFi я
уже писал об AirJack’е, поэтому не буду заострять здесь на нем внимания.
Возможен такой вариант событий, когда точка доступа одна и нет в
настоящий момент взаимодействующих с ней хостов. В этом случае остается
опробовать вариант ESSID характерный для настроек «по умолчанию»
производителя данной точки доступа. Некоторые админы, закрыв сеть, даже
не подумывают изменить их значения.
Фильтрация MAC-адресов вообще обходится проще простого. Нужно изучить
трафик на предмет встречающихся MAC-адресов, и когда какой-нибудь хост
отсоединится от сети, можно присоединится к ней, установив себе такой
же MAC. Если ждать о... Читать дальше »
|
Скрины:
Дата: 16.01.2010
Добавил: us
Комментарии: (0)
|
| |
|
|
|
|
|
|
Рассылка
|