Изучаем и выявляем уязвимости протокола IPsec — «Хакер»

.

Как работает ipSec

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

  • Шаг 1.Начало процесса IPSec. Трафик, которому требуется шифрование в соответствии с политикой защиты IPSec, согласованной сторонами IPSec, начинает IКЕ-процесс.

  • Шаг 2.Первая фаза IKE. IKE-процесс выполняет аутентификацию сторон IPSec и ведет переговоры о параметрах ассоциаций защиты IKE, в результате чего создается защищенный канал для ведения переговоров о параметрах ассоциаций защиты IPSec в ходе второй фазы IKE.

  • Шаг 3.Вторая фаза IKE. IKE-процесс ведет переговоры о параметрах ассоциации защиты IPSec и устанавливает соответствующие ассоциации защиты IPSec для устройств сообщающихся сторон.

  • Шаг 4.Передача данных. Происходит обмен данными между сообщающимися сторонами IPSec, который основывается на параметрах IPSec и ключах, хранимых в базе данных ассоциаций защиты.

  • Шаг 5.Завершение работы туннеля IPSec. Ассоциации защиты IPSec завершают свою работу либо в результате их удаления, либо по причине превышения предельного времени их существования.

Режимы работы ipSec

Существует два режима работы IPSec: транспортный и туннельный.

В транспортном режиме шифруется только информативная часть IP-пакета. Маршрутизация не затрагивается, так как заголовок IP-пакета не изменяется. Транспортный режим, как правило, используется для установления соединения между хостами.

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

Согласование преобразований IPSec

В ходе работы протокола IKE ведутся переговоры о преобразованиях IPSec (алгоритмах защиты IPSec).

IPSec — протокол защиты сетевого трафика на IP-уровне

Преобразования IPSec и связанные с ними алгоритмы шифрования являются следующими:

  • Протокол АН (Authentication Header — заголовок аутентификации). Протокол зашиты, обеспечивающий аутентификацию и (в качестве опции) сервис выявления воспроизведения. Протокол АН действует как цифровая подпись и гарантирует, что данные в пакете IP не будут несанкционированно изменены. Протокол АН не обеспечивает сервис шифрования и дешифрования данных. Данный протокол может использоваться или самостоятельно, или совместно с протоколом ESP.

  • Протокол ESP (Encapsulating Security Payload — включающий защиту полезный груз). Протокол защиты, обеспечивающий конфиденциальность и защиту данных, а также (в качестве опции) сервис аутентификации и выявления воспроизведения. Поддерживающие IPSec продукты Cisco используют ESP для шифрования полезного груза IP-пакетов. Протокол ESP может использоваться самостоятельно или совместно с АН.

  • Стандарт DES (Data Encription Standard — стандарт шифрования данных). Алгоритм шифрования и дешифрования данных пакетов. Алгоритм DES используется как в рамках IPSec, так и IKE. Для алгоритма DES используется 56-битовый ключ, что означает не только более высокое потребление вычислительных ресурсов, но и более надежное шифрование. Алгоритм DES является симметричным алгоритмом шифрования, для которого требуются идентичные секретные ключи шифрования в устройствах каждой из сообщающихся сторон IPSec. Для создания симметричных ключей применяется алгоритм Диффи-Хеллмана. IKE и IPSec используют алгоритм DES для шифрования сообщений.

  • «Тройной» DES (3DES). Вариант DES, основанный на использовании трех итераций стандартного DES с тремя разными ключами, что практически утраивает стойкость DES. Алгоритм 3DES используется в рамках IPSec для шифрования и дешифрования потока данных. Данный алгоритм использует 168-битовый ключ, что гарантирует высокую надежность шифрования. IKE и IPSec используют алгоритм 3DES для шифрования сообщений.

  • AES (advanced encryption standard). Протокол AES использует алгоритм шифрования Rine Dale4, который обеспечивает существенно более надежное шифрование. Многие криптографы считают, что AES вообще невозможно взломать. Сейчас AES яв­ляется федеральным стандартом обработки информации. Он определен как алгоритм шифрования для использования правительственными организациями США для защи­ты важных, но несекретных сведений. Проблема, связанная с AES, состоит в том, что для его реализации требуется большая вычислительная мощность по сравнению с аналогичными протоколами.

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

  • Алгоритм MD5 (Message Digest 5). Алгоритм хэширования, применяемый для аутентификации пакетов данных. В продуктах Cisco используется вычисляемый с помощью MD5 код НМАС (Hashed Message Authentication Code — хэшированный код аутентичности сообщения)- вариант кода аутентичности сообщения, которому обеспечивается дополнительная защита с помощью хэширования. Хэширование представляет собой процесс одностороннего (т.е. необратимого) шифрования, в результате которого для поступающего на вход сообщения произвольной длины получается вывод фиксированной длины. IKE, АН и ESP используют MD5 для аутентификации данных.

  • Алгоритм SHA-1 (Secure Hash Algorithm-1 — защищенный алгоритм хэширования 1). Алгоритм хэширования, используемый для аутентификации пакетов данных. В продуктах Cisco применяется вариант кода НМАС, вычисляемый с помощью SHA-1. IKЕ, АН и ESP используют SHA-1 для аутентификации данных.

В рамках протокола IKE симметричные ключи создаются с помощью алгоритма Диффи-Хеллмана, использующего DES, 3DES, MD5 и SHA. Протокол Диффи-Хеллмана является криптографическим протоколом, основанным на применении открытых ключей. Он позволяет двум сторонам согласовать общий секретный ключ, не имея достаточно надежного канала связи.

Общие секретные ключи требуются для алгоритмов DES и НМАС. Алгоритм Диффи-Хеллмана используется в рамках IKE для создания сеансовых ключей. Группы Diffie-Hellman (DH) – определяют «силу» ключа шифрования, который используется в процедуре обмена ключами. Чем выше номер группы, тем «сильнее» и безопаснее ключ. Однако следует учитывать тот факт, что при увеличении номер группы DH увеличивается «сила» и уровень безопасности ключа, однако одновременно увеличивается нагрузка на центральный процессор, так как для генерации более «сильного» ключа необходимо больше времени и ресурсов.

Устройства WatchGuard поддерживают DH группы 1, 2 и 5:

  • DH group 1: 768-bit key

  • DH group 2: 1024-bit key

  • DH group 5: 1536-bit key

Оба устройства, которые обмениваются данными через VPN должны использовать одну и ту же группу DH. Группа DH, которая будет использоваться устройствами, выбирается во время IPSec Phase 1 процедуры.

Протоколы защищенных каналов. часть 4. IPSec

краткая историческая справка появления протокола

В 1994 году Совет по архитектуре Интернет (IAB) выпустил отчет «Безопасность архитектуры Интернет». В этом документе описывались основные области применения дополнительных средств безопасности в сети Интернет, а именно защита от несанкционированного мониторинга, подмены пакетов и управления потоками данных. В числе первоочередных и наиболее важных защитных мер указывалась необходимость разработки концепции и основных механизмов обеспечения целостности и конфиденциальности потоков данных. Поскольку изменение базовых протоколов семейства TCP/IP вызвало бы полную перестройку сети Интернет, была поставлена задача обеспечения безопасности информационного обмена в открытых телекоммуникационных сетях на базе существующих протоколов. Таким образом, начала создаваться спецификация Secure IP, дополнительная по отношению к протоколам IPv4 и IPv6.

архитектура IPSec

IP Security — это комплект протоколов, касающихся вопросов шифрования, аутентификации и обеспечения защиты при транспортировке IP-пакетов; в его состав сейчас входят почти 20 предложений по стандартам и 18 RFC.
Спецификация IP Security (известная сегодня как IPsec) разрабатывается рабочей группой IP Security Protocol IETF. Первоначально IPsec включал в себя 3 алгоритмо-независимые базовые спецификации, опубликованные в качестве RFC-документов «Архитектура безопасности IP», «Аутентифицирующий заголовок (AH)», «Инкапсуляция зашифрованных данных (ESP)» (RFC1825, 1826 и 1827). Необходимо заметить, что в ноябре 1998 года Рабочая группа IP Security Protocol предложила новые версии этих спецификаций, имеющие в настоящее время статус предварительных стандартов, это RFC2401 — RFC2412. Отметим, что RFC1825-27 на протяжении уже нескольких лет считаются устаревшими и реально не используются. Кроме этого, существуют несколько алгоритмо-зависимых спецификаций, использующих протоколы MD5, SHA, DES.

Рис.1. Архитектура IPSec

Рабочая группа IP Security Protocol разрабатывает также и протоколы управления ключевой информацией. В задачу этой группы входит разработка Internet Key Management Protocol (IKMP), протокола управления ключами прикладного уровня, не зависящего от используемых протоколов обеспечения безопасности. В настоящее время рассматриваются концепции управления ключами с использованием спецификации Internet Security Association and Key Management Protocol (ISAKMP) и протокола Oakley Key Determination Protocol. Спецификация ISAKMP описывает механизмы согласования атрибутов используемых протоколов, в то время как протокол Oakley позволяет устанавливать сессионные ключи на компьютеры сети Интернет. Ранее рассматривались также возможности использования механизмов управления ключами протокола SKIP, однако сейчас такие возможности реально практически нигде не используются. Создаваемые стандарты управления ключевой информацией, возможно, будут поддерживать Центры распределения ключей, аналогичные используемым в системе Kerberos. Протоколами ключевого управления для IPSec на основе Kerberos сейчас занимается относительно новая рабочая группа KINK (Kerberized Internet Negotiation of Keys).
Гарантии целостности и конфиденциальности данных в спецификации IPsec обеспечиваются за счет использования механизмов аутентификации и шифрования соответственно. Последние, в свою очередь, основаны на предварительном согласовании сторонами информационного обмена т.н.

«контекста безопасности» — применяемых криптографических алгоритмов, алгоритмов управления ключевой информацией и их параметров. Спецификация IPsec предусматривает возможность поддержки сторонами информационного обмена различных протоколов и параметров аутентификации и шифрования пакетов данных, а также различных схем распределения ключей. При этом результатом согласования контекста безопасности является установление индекса параметров безопасности (SPI), представляющего собой указатель на определенный элемент внутренней структуры стороны информационного обмена, описывающей возможные наборы параметров безопасности.
По сути, IPSec, который станет составной частью IPv6, работает на третьем уровне, т. е. на сетевом уровне. В результате передаваемые IP-пакеты будут защищены прозрачным для сетевых приложений и инфраструктуры образом. В отличие от SSL (Secure Socket Layer), который работает на четвертом (т. е. транспортном) уровне и теснее связан с более высокими уровнями модели OSI, IPSec призван обеспечить низкоуровневую защиту.

Рис.2. Модель OSI/ISO

К IP-данным, готовым к передаче по виртуальной частной сети, IPSec добавляет заголовок для идентификации защищенных пакетов. Перед передачей по Internet эти пакеты инкапсулируются в другие IP-пакеты. IPSec поддерживает несколько типов шифрования, в том числе Data Encryption Standard (DES) и Message Digest 5 (MD5).
Чтобы установить защищенное соединение, оба участника сеанса должны иметь возможность быстро согласовать параметры защиты, такие как алгоритмы аутентификации и ключи.

IPSec поддерживает два типа схем управления ключами, с помощью которых участники могут согласовать параметры сеанса. Эта двойная поддержка в свое время вызвала определенные трения в IETF Working Group.
С текущей версией IP, IPv4, могут быть использованы или Internet Secure Association Key Management Protocol (ISAKMP), или Simple Key Management for Internet Protocol.

Как работает ipSec

С новой версией IP, IPv6, придется использовать ISAKMP, известный сейчас как IKE, хотя не исключается возможность использования SKIP. Однако, следует иметь в виду, что SKIP уже давно не рассматривается как кандидат управления ключами, и был исключен из списка возможных кандидатов еще в 1997 г.

заголовки AH и ESP

аутентифицирующий заголовок AH

Аутентифицирующий заголовок (AH) является обычным опциональным заголовком и, как правило, располагается между основным заголовком пакета IP и полем данных. Наличие AH никак не влияет на процесс передачи информации транспортного и более высокого уровней. Основным и единственным назначением AH является обеспечение защиты от атак, связанных с несанкционированным изменением содержимого пакета, и в том числе от подмены исходного адреса сетевого уровня. Протоколы более высокого уровня должны быть модифицированы в целях осуществления проверки аутентичности полученных данных.
Формат AH достаточно прост и состоит из 96-битового заголовка и данных переменной длины, состоящих из 32-битовых слов. Названия полей достаточно ясно отражают их содержимое: Next Header указывает на следующий заголовок, Payload Len представляет длину пакета, SPI является указателем на контекст безопасности и Sequence Number Field содержит последовательный номер пакета.

Рис.3. Формат заголовка AH

Последовательный номер пакета был введен в AH в 1997 году в ходе процесса пересмотра спецификации IPsec. Значение этого поля формируется отправителем и служит для защиты от атак, связанных с повторным использованием данных процесса аутентификации. Поскольку сеть Интернет не гарантирует порядок доставки пакетов, получатель должен хранить информацию о максимальном последовательном номере пакета, прошедшего успешную аутентификацию, и о получении некоторого числа пакетов, содержащих предыдущие последовательные номера (обычно это число равно 64).
В отличие от алгоритмов вычисления контрольной суммы, применяемых в протоколах передачи информации по коммутируемым линиям связи или по каналам локальных сетей и ориентированных на исправление случайных ошибок среды передачи, механизмы обеспечения целостности данных в открытых телекоммуникационных сетях должны иметь средства защиты от внесения целенаправленных изменений. Одним из таких механизмов является специальное применение алгоритма MD5: в процессе формирования AH последовательно вычисляется хэш-функция от объединения самого пакета и некоторого предварительно согласованного ключа, а затем от объединения полученного результата и преобразованного ключа. Данный механизм применяется по умолчанию в целях обеспечения всех реализаций IPv6, по крайней мере, одним общим алгоритмом, не подверженным экспортным ограничениям.

инкапсуляция зашифрованных данных ESP

В случае использования инкапсуляции зашифрованных данных заголовок ESP является последним в ряду опциональных заголовков, «видимых» в пакете. Поскольку основной целью ESP является обеспечение конфиденциальности данных, разные виды информации могут требовать применения существенно различных алгоритмов шифрования. Следовательно, формат ESP может претерпевать значительные изменения в зависимости от используемых криптографических алгоритмов. Тем не менее, можно выделить следующие обязательные поля: SPI, указывающее на контекст безопасности и Sequence Number Field, содержащее последовательный номер пакета. Поле «ESP Authentication Data» (контрольная сумма), не является обязательным в заголовке ESP. Получатель пакета ESP расшифровывает ESP заголовок и использует параметры и данные применяемого алгоритма шифрования для декодирования информации транспортного уровня.

Рис.4. Формат заголовка ESP

Различают два режима применения ESP и AH (а также их комбинации) — транспортный и туннельный:
Транспортный режим используется для шифрования поля данных IP пакета, содержащего протоколы транспортного уровня (TCP, UDP, ICMP), которое, в свою очередь, содержит информацию прикладных служб.

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

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

Security Associations

Security Association (SA) — это соединение, которое предоставляет службы обеспечения безопасности трафика, который передается через него. Два компьютера на каждой стороне SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется только в одном направлении. Для двунаправленной связи требуется два SA. Каждый SA реализует один режим и протокол; таким образом, если для одного пакета необходимо использовать два протокола (как например AH и ESP), то требуется два SA.

политика безопасности

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

протокол ISAKMP/Oakley

Протокол ISAKMP определяет общую структуру протоколов, которые используются для установления SA и для выполнения других функций управления ключами. ISAKMP поддерживает несколько Областей Интерпретации (DOI), одной из которых является IPSec-DOI. ISAKMP не определяет законченный протокол, а предоставляет «строительные блоки» для различных DOI и протоколов обмена ключами.
Протокол Oakley — это протокол определения ключа, использующий алгоритм замены ключа Диффи-Хеллмана. Протокол Oakley поддерживает идеальную прямую безопасность (Perfect Forward Secrecy, PFS). Наличие PFS означает невозможность расшифровки всего траффика при компрометации любого ключа в системе.

протокол IKE

IKE — протокол обмена ключами по умолчанию для ISAKMP, на данный момент являющийся единственным. IKE находится на вершине ISAKMP и выполняет, собственно, установление как ISAKMP SA, так и IPSec SA. IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF).
Хэш-функция — это функция, устойчивая к коллизиям. Под устойчивостью к коллизиям понимается тот факт, что невозможно найти два разных сообщения m1 и m2, таких, что H(m1)=H(m2), где H — хэш функция.
Что касается псеводслучайных функций, то в настоящее время вместо специальных PRF используется хэш функция в конструкции HMAC (HMAC — механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC нам понадобится криптографическая хэш функция (обозначим ее как H) и секретный ключ K. Мы предполагаем, что H является хэш функцией, где данные хэшируются с помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Мы обозначим за B длину таких блоков в байтах, а длину блоков, полученных в результате хэширования — как L (L<B). Ключ K может иметь длину, меньшую или равную B. Если приложение использует ключи большей длины, сначала мы должны хэшировать сам ключ с использованием H, и только после этого использовать полученную строку длиной L байт, как ключ в HMAC. В обоих случаях рекомендуемая минимальная длина для K составляет L байт. Определим две следующие различные строки фиксированной длины:

ipad = байт 0x36, повторенный B раз;
opad = байт 0x5C, повторенный B раз.

Для вычисления HMAC от данных ‘text’ необходимо выполнить следующую операцию:

H(K XOR opad, H(K XOR ipad, text))

Из описания следует, что IKE использует для аутентификации сторон HASH величины. Отметим, что под HASH в данном случае подразумевается исключительно название Payload в ISAKMP, и это название не имеет ничего общего со своим содержимым.

атаки на AH, ESP и IKE

Все виды атак на компоненты IPSec можно разделить на следующие группы: атаки, эксплуатирующие конечность ресурсов системы (типичный пример — атака «Отказ в обслуживании», Denial-of-service или DOS-атака), атаки, использующие особенности и ошибки конкретной реализации IPSec и, наконец, атаки, основанные на слабостях самих протоколов AH и ESP. Чисто криптографические атаки можно не рассматривать — оба протокола определяют понятие «трансформ», куда скрывают всю криптографию. Если используемый криптоалгоритм стоек, а определенный с ним трансформ не вносит дополнительных слабостей (это не всегда так, поэтому правильнее рассматривать стойкость всей системы — Протокол-Трансформ-Алгоритм), то с этой стороны все нормально. Что остается? Replay Attack — нивелируется за счет использования Sequence Number (в одном единственном случае это не работает — при использовании ESP без аутентификации и без AH). Далее, порядок выполнения действий (сначала шифрация, потом аутентификация) гарантирует быструю отбраковку «плохих» пакетов (более того, согласно последним исследованиям в мире криптографии, именно такой порядок действий наиболее безопасен, обратный порядок в некоторых, правда очень частных случаях, может привести к потенциальным дырам в безопасности; к счастью, ни SSL, ни IKE, ни другие распространенные протоколы с порядком действий «сначала аутентифицировать, потом зашифровать», к этим частным случаям не относятся, и, стало быть, этих дыр не имеют). Остается Denial-Of-Service атака.

Как известно, это атака, от которой не существует полной защиты. Тем не менее, быстрая отбраковка плохих пакетов и отсутствие какой-либо внешней реакции на них (согласно RFC) позволяют более-менее хорошо справляться с этой атакой. В принципе, большинству (если не всем) известным сетевым атакам (sniffing, spoofing, hijacking и т.п.) AH и ESP при правильном их применении успешно противостоят.

С IKE несколько сложнее. Протокол очень сложный, тяжел для анализа. Кроме того, в силу опечаток (в формуле вычисления HASH_R) при его написании и не совсем удачных решений (тот же HASH_R и HASH_I) он содержит несколько потенциальных «дыр» (в частности, в первой фазе не все Payload в сообщении аутентифицируются), впрочем, они не очень серьезные и ведут, максимум, к отказу в установлении соединения.От атак типа replay, spoofing, sniffing, hijacking IKE более-менее успешно защищается. С криптографией несколько сложнее, — она не вынесена, как в AH и ESP, отдельно, а реализована в самом протоколе. Тем не менее, при использовании стойких алгоритмов и примитивов (PRF), проблем быть не должно. В какой-то степени можно рассматривать как слабость IPsec то, что в качестве единственного обязательного к реализации криптоалгоритма в нынешних спецификациях указывается DES (это справедливо и для ESP, и для IKE), 56 бит ключа которого уже не считаются достаточными. Тем не менее, это чисто формальная слабость — сами спецификации являются алгоритмо-независимыми, и практически все известные вендоры давно реализовали 3DES (а некоторые уже и AES).Таким образом, при правильной реализации, наиболее «опасной» атакой остается Denial-Of-Service.

оценка протокола IPSec

Протокол IPSec получил неоднозначную оценку со стороны специалистов. С одной стороны, отмечается, что протокол IPSec является лучшим среди всех других протоколов защиты передаваемых по сети данных, разработанных ранее (включая разработанный Microsoft PPTP). По мнению другой стороны, присутствует чрезмерная сложность и избыточность протокола. Так, Niels Ferguson и Bruce Schneier в своей работе «A Cryptographic Evaluation of IPsec» отмечают, что они обнаружили серьезные проблемы безопасности практически во всех главных компонентах IPsec. Эти авторы также отмечают, что набор протоколов требует серьезной доработки для того, чтобы он обеспечивал хороший уровень безопасности.

Реферат слушателя 4 курса ИКСИ, научный руководитель — Сергей Кунегин.

© Сетевые решения

Как ускорить работу операционной системы Windows 7. Отключение служб Windows.

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

Итак, в меню Пуск в строке поиска вводим services.msc и открываем утилиту управления.

Перед вами список всех служб.

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

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

  • Удаленный реестр дает возможность сторонним пользователям (не исключено, что и недоброжелателям) удаленно вносить разнообразные изменения в реестр системы. В целях сохранения безопасности выключить эту службу следует не задумываясь.
  • Автономные файлы несут ответственность за реализацию API автономных файлов. Большей части пользователей эта служба не нужна. Рекомендуется выключить.
  • Служба ввода планшетного ПК нужна для работы пера и похожих устройств ввода на планшетах. Рекомендуется отключить.
  • Служба регистрации ошибок Windows отвечает за ведение статистики разных ошибок системы. В случае отсутствия необходимости вести журнал для выявления причин возникновения тех или иных ошибок, службу можно выключить.
  • Модули ключей IPsec для обмена ключами — служба дает возможность работать с ключами IKE. Рекомендуется отключить.
  • Клиент отслеживания изменившихся связей. Отвечает за поддержку связи тех NTFS-файлов, которые перенаправляются в пределах системы или между компьютерами в сети.

    Изучаем и выявляем уязвимости протокола IPsec

    Рекомендуется отключить.

  • Parental Control. Пришла из операционной системы Vista и необходима только для совместимости с ней. Рекомендуется отключить.

Компьютеры, которые не входят в состав локальной сети, также не нуждаются в некоторых службах:

  • Агент политики IPSec. В большинстве случаев не используется. Рекомендуется отключить.
  • KtmRm для координатора распределенных транзакций. В большинстве случаев не нужна. Рекомендуется отключить.
  • Вспомогательная служба IP. Данная служба не используется на домашних компьютерах. Рекомендуется отключить.
  • Диспетчер печати. Можно выключить службу, если у вас нет принтера, и вы не планируете им пользоваться.
  • Вторичный вход в систему нужен при запуске различных процессов от другого имени, стороннего. Безопасность в большем приоритете, поэтому выключаем службу.
  • Факс. Служба нужна только при наличии такового.
  • Защитник Windows. Если вы используете полноценный антивирус, то в службе нет необходимости.
  • Брандмауэр Windows. Если ваш антивирус оснащен брандмауэром, то в службе нет необходимости.
  • Политика удаления смарт-карт. Соответственно, если нет смарт-карты, то служба следует выключить.
  • Служба инициатора Майкрософт iSCSI. Рекомендуется установить тип запуска Вручную.
  • Обнаружение SSDP. Если нет устройств, которые используют данный протокол, то рекомендуется выключить.
  • Адаптивная регулировка яркости. Если ваш компьютер не подключен к устройству обнаружения света, то в службе нет необходимости.
  • Браузер компьютеров нужен только для обнаружения сторонних систем в локальной сети.

    Рекомендуется отключить.

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

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

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

Статьи по теме:

Новости по теме:

Вернуться к статьям


 Опубликовано на ONLamp.com (http://www.onlamp.com/)
 http://www.onlamp.com/pub/a/bsd/2002/12/12/FreeBSD_Basics.html
 При проблемах с печатью примеров см. эту страницу

VPN и IPSec на пальцах

by Dru Lavigne
12/12/2002
перевод by techtonik

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

VPN, или Virtual Private Network, что в переводе означает Виртуальная Частная Сеть — это криптосистема, позволяющая защитить данные при передаче их по незащищенной сети, такой как Интернет. Несмотря на то, что данное описание подходит и для криптосистемы SSH, VPN имеет другое предназначение. SSH разрабатывался как средство, позволяющее пользователю безопасно зайти и удалённо управлять другим компьютером. Цель VPN — прозрачный доступ к ресурсам сети, где пользователь может делать всё то, что он делает обычно независимо от того, насколько он удалён. По этой причине VPN приобрёл популярность среди дистанционных работников и офисов, которые нуждаются в совместном использовании ресурсов территориально разделённых сетей.

VPN Туннели

Прежде чем приступить к настройке VPN, необходимо познакомится с общепринятой терминологией и с некоторыми проблемами настройки. Начнём с терминологии. VPN соединение всегда состоит из канала типа точка-точка, также известного под названием туннель. Туннель создаётся в незащищённой сети, в качестве которой чаще всего выступает Интернет. Соединение точка-точка подразумевает, что оно всегда устанавливается между двумя компьютерами, которые называются узлами или peers. Каждый peer отвечает за шифрование данных до того, как они попадут в туннель и расшифровке этих данных после того, как они туннель покинут.

Хотя VPN туннель всегда устанавливается между двумя точками, каждый peer может устанавливать дополнительные туннели с другими узлами. Для примера, когда трём удалённым станциям необходимо связаться с одним и тем же офисом, будет создано три отдельных VPN туннеля к этому офису. Для всех туннелей peer на стороне офиса может быть одним и тем же. Это возможно благодаря тому, что узел может шифровать и расшифровывать данные от имени всей сети, как это показано на рисунке 1:


Рисунок 1 — VPN шлюз к сети

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

Интересно отметить, что внутри домена шифрования самого шифрования не происходит. Причина в том, что эта часть сети считается безопасной и находящейся под непосредственным контролем в противоположность Интернет. Это справедливо и при соединении офисов с помощью VPN шлюзов. Таким образом гарантируется шифрование только той информации, которая передаётся по небезопасному каналу между офисами. Рисунок 2 показывает VPN соединяющую два офиса:


Рисунок 2 — защищённая сеть на основе незащищённой сети

Сеть A считается доменом шифрования VPN шлюза A, а сеть B доменом шифрования VPN шлюза B, соответственно. Когда пользователь сети A изъявляет желание отправить данные в сеть B, VPN шлюз A зашифрует их и отошлёт через VPN туннель. VPN шлюз B расшифрует информацию и передаст получателю в сети B.

Помните режим транспорта и режим туннеля в Терминологии Криптографии 101? Всякий раз, когда соединение сетей обслуживают два VPN шлюза, они используют режим туннеля. Это означает, что шифруется весь пакет IP, после чего к нему добавляется новый IP заголовок. Новый заголовок содержит IP адреса двух VPN шлюзов, которые и увидит пакетный сниффер при перехвате.

Невозможно определить компьютер-источник в первом домене шифрования и компьютер-получатель во втором домене.

Посмотрите на рисунок 1, иллюстрирующий типичное использование VPN, которая позволяет удалённым пользователям с переносыми компьютерами и пользователям, работающим из дома, иметь доступ к офисной сети. Чтобы эта схема заработала, пользователь должен иметь установленное ПО — VPN клиент, который обеспечит создание VPN туннеля к удалённому VPN шлюзу. По сценарию используется режим туннеля, т.к. пользователь хочет получить доступ к ресурсам домена, а не самого шлюза. Единственной случай, когда включается режим транспорта — это если одному компьютеру нужно получить доступ к другому непосредственно.

Существует много вариантов VPN шлюзов и VPN клиентов. Это может быть аппаратное VPN устройство или программное VPN обеспечение, которое устанавливается на маршрутизаторах или на ПК. ОС FreeBSD поставляется вместе с ПО для создания VPN шлюза и для настройки VPN клиента. В коллекции портов существуют и другие приложения, позволяющие соединяться со станциями под управлением других ОС.

К счастью, в Интернет есть много источников информации о VPN, FAQ и варианты настроек. Я могу порекомендовать Tina Bird’s VPN Information, VPN Labs, и Virtual Private Network Consortium (VPNC).

Назависимо от используемого ПО, все VPN работают по следующим принципам:

  1. Каждый из узлов идентифицирует друг друга перед созданием туннеля, чтобы удостовериться, что шифрованные данные будут отправлены на нужный узел
  2. Оба узла требуют заранее настроеной политики, указывающей какие протоколы могут использоваться для шифрования и обеспечения целостности данных
  3. Узлы сверяют политики, чтобы договориться об используемых алгоритмах; если это не получается, то туннель не устанавливается
  4. Как только достигнуто соглашение по алгоритмам, создаётся ключ, который будет использован в симметричном алгоритме для шифрования/расшифровки данных

Есть несколько стандартов регламентирующих вышеописанное взаимодействие. Вы, должно быть, слышали о некоторых из них: L2TP, PPTP, и IPSec. Т.к. IPSec — наиболее широко поддерживаемый стандарт, который имеет в арсенале наибольшее количество сокращений, оставшуюся часть статьи стоит посвятить именно ему.

IPSec

Стандарт IPSec был разработан для повышения безопасности IP протокола. Это достигается за счёт дополнительных протоколов, добавляющих к IP пакету собственные заголовки, которые называются инкапсуляциями. Т.к. IPSec — стандарт Интернет, то для него существуют RFC (Requests For Comments). Если есть интерес покопаться во внутренностях IPSec, то следующие RFC с http://www.rfc-editor.org/ могут оказаться полезными:

Приведём краткое описание каждого, чтобы получить необходимую информацию для понимания следующей статьи, посвящённой настройке IPSec VPN на FreeBSD системе. Начнём с сокращений, а затем посмотрим как они укладываются в общую картину создания виртуальной частной сети.

AH (Authentication Header) — протокол заголовка идентификации. Обеспечивает целостность путём проверки того, что ни один бит в защищаемой части пакета не был изменён во время передачи. Не будем вдаваться в подробности, какая часть пакета защищается и где находятся данные AH заголовка, т.к. это зависит от используемого типа шифрования и в деталях, с диаграммами описывается в соответствующем RFC. Отметим лишь, что использование AH может вызвать проблемы, например, при прохождении пакета через NAT устройство. NAT меняет IP адрес пакета, чтобы разрешить доступ в Интернет с закрытого локального адреса. Т.к. пакет в таком случае изменится, то контрольная сумма AH станет неверной. Также стоит отметить, что AH разрабатывался только для обеспечения целостности. Он не гарантирует конфиденциальности путём шифрования содержимого пакета.

ESP (Encapsulating Security Protocol) — инкапсулирующий протокол безопасности, который обеспечивает и целостность и конфиденциальность. В режиме транспорта ESP заголовок находится между оригинальным IP заголовком и заголовком TCP или UDP. В режиме туннеля заголовок ESP размещается между новым IP заголовком и полностью зашифрованным оригинальным IP пакетом.

Т.к. оба протокола — AH и ESP добавляют собственные заголовки, они имеют свой ID протокола, по которому можно определить что последует за заголовком IP. Если вспомнить статью TCP Protocol Layers Explained, то в ней сказано, что каждый тип заголовка имеет собственный номер. Например, для TCP это 6, а для UDP — 17. При работе через firewall важно не забыть настроить фильтры, чтобы пропускать пакеты с ID AH и/или ESP протокола. Для AH номер ID — 51, а ESP имеет ID протокола равный 50. При создании правила не забывайте, что ID протокола не то же самое, что номер порта.

Третий протокол, используемый IPSec — это IKE или Internet Key Exchange protocol. Как следует из названия, он предназначен для обмена ключами между двумя узлами VPN. Насмотря на то, что генерировать ключи можно вручную, лучшим и более масштабируемым вариантом будет автоматизация этого процесса с помощью IKE. Помните, что ключи должны часто меняться, и вам наверняка не хочется полагаться на свою память, чтобы найти время для совершения этой операции вручную. Главное — не забудьте настроить правило на файрволе для UPD порта с номером 500, т.к. именно этот порт используется IKE.

SA (Security Association), что можно приближённо перевести как «связь или ассоциация безопасности» — это термин IPSec для обозначения соединения. При настроенном VPN, для каждого используемого протокола создаётся одна SA пара (т.е. одна для AH и одна для ESP). SA создаются парами, т.к. каждая SA — это однонаправленное соединение, а данные необходимо передавать в двух направлениях. Полученные SA пары хранятся на каждом узле. Если ваш узел имеет SA, значит VPN туннель был установлен успешно.

Т.к. каждый узел способен устанавливать несколько туннелей с другими узлами, каждый SA имеет уникальный номер, позволяющий определить к какому узлу он относится.

Это номер называется SPI (Security Parameter Index) или индекс параметра безопасности.

SA храняться в базе данных c названием, кто бы подумал — SAD (Security Association Database) или БД ассоциаций безопасности. Мы встретимся с ней ещё раз при настройке IPSec VPN.

Каждый узел IPSec также имеет вторую БД — SPD или Security Policy Database (БД политики безопасности). Она содержит настроенную вами политику узла. Большинство VPN решений разрешают создание нескольких политик с комбинациями подходящих алгоритмов для каждого узла, с которым нужно установить соединение.

Какие настройки включает в себя политика?

  1. Симметричные алгоритмы для шифрования/расшифровки данных
  2. Криптографические контрольные суммы для проверки целостности данных
  3. Способ идентификации узла. Самые распространнённые способы — это предустановленные ключи (pre-shared secrets) или RSA сертификаты.
  4. Использовать ли режим туннеля или режим транспорта
  5. Какую использовать группу Diffie Hellman
  6. Как часто проводить переидентификацию узла
  7. Как часто менять ключ для шифрования данных
  8. Использовать ли PFS
  9. Использовать ли AH, ESP, или оба вместе

При создании политики, как правило, возможно создание упорядоченного списка алгоритмов и Diffie Hellman групп. В таком случае будет использована первая совпавшая на обоих узлах позиция.

Запомните, очень важно, чтобы всё в политике безопасности позволяло добиться этого совпадения. Если за исключением одной части политики всё остальное совпадает, узлы всё равно не смогут установить VPN соединение. При настройе VPN между различными системами уделите время изучению того, какие алгоритмы поддерживаются каждой стороной, чтобы иметь выбор наиболее безопасной политики из возможных.

Фаза Один и Фаза Два

Теперь давайте посмотрим как всё это работает вместе. Установка и поддержка VPN туннеля происходит в два этапа. На первом этапе (фазе) два узла договариваются о методе идентификации, алгоритме шифрования, хэш алгоритме и группе Diffie Hellman. Они также идентифицируют друг друга. Всё это может пройти в результате обмена тремя нешифрованными пакетами (т.н. агрессивный режим) или через обмен шестью нешифрованными пакетами (стандартный режим — main mode). Предполагая, что операция завершилась успешно, создаётся SA первой Фазы — Phase 1 SA (также называемый IKE SA) и процесс переходит к Фазе Два.

На втором этапе генерируются данные ключей, узлы договариваются насчёт используемой политики. Этот режим, также называемый быстрым режимом (quick mode), отличается от первой фазы тем, что может установиться только после первого этапа, когда все пакеты второй фазы шифруются. Такое положение дел усложняет решение проблем в случае неполадок на второй фазе при успешном завершении первой. Правильное завершение второй фазы приводит к появлению Phase 2 SA или IPSec SA, и на этом установка туннеля считается завершённой.

Когда же это всё происходит? Сначала на узел прибывает пакет с адресом назначения в другом домене шифрования, и узел инициирует Фазу Один с тем узлом, который отвечает за другой домен. Допустим, туннель между узлами был успешно установлен и ожидает пакетов. Однако, узлам необходимо переидентифицировать друг друга и сравнить политику через определённое время. Это время известно как время жизни Phase One или IKE SA lifetime.

Узлы также должны сменить ключ для шифрования данных через другой отрезок времени, который называется временем жизни Phase Two или IPSec SA lifetime. Phase Two lifetime короче, чем у первой фазы, т.к. ключ необходимо менять чаще. Типичное время жизни Phase Two — 60 минут. Для Phase One оно равно 24 часам.

Ваша задача заключается в том, чтобы сконфигурировать оба узла с одинаковыми параметрами времени жизни. Если этого не произойдёт, то возможен вариант, когда изначально туннель будет установлен успешно, но по истечении первого несогласованного промежутка времени жизни связь прервётся. Странные проблемы могут возникнуть и в том случае, когда время жизни Фазы Один меньше аналогичного параметра Фазы Два. Если настроенный ранее туннель виснет, то первая вещь, которая нуждается в проверке — это время жизни на обоих узлах. В заключение стоит упомянуть, что при смене политики на одном из узлов, изменения вступят в силу только при следующем наступлении Фазы Один. Чтобы изменения вступили в силу немедленно, надо убрать SA для этого туннеля из SAD. Это вызовёт пересмотр соглашения между узлами с новыми настройками политики безопасности.

Теперь у нас есть достаточно информации для создания IPSec VPN на вашей FreeBSD машине. Демонстрация необходимых настроек — тема следующей статьи.

Dru Lavigne — инструктор Marketbridge Technologies в Оттаве и администратор Open Protocol Resource.


Copyright ╘ 2005 O’Reilly Media, Inc.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *