Выбираем протокол для vpn. сравнение openvpn, pptp, l2tp/ipsec и ipsec ikev2

Введение

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

1. Настроить прокси сервер с разбором всего трафика в том числе с помощью MITM для расшифровки https соединений.
2. Сделать ограничения доступа к сайтам на основе готовых списков от Минюста, Госнаркоконтроля и т.д.
3. Использовать списки пользователей и групп для централизованного ограничения и управления доступом и отчетами.
4. Настроить свои VPN туннели или подключиться к существующим на базе стороннего оборудования.
5. Запустить базовый функционал следующих сервисов — почта, файловый сервер, ip телефония, jabber.

При всем при этом интернет шлюз ИКС умеет:

• Настраиваться полностью через web интерфейс. В консоль ходить не надо вообще.
• Интеграцию с AD с помощью Kerberos и NTLM.
• Строить красивые графики и отчеты, которые не стыдно показать.
• Мульти WAN и отказоустойчивость на базе CARP.

Ну и до кучи он имеет сертификацию ФСТЭК (как я понял, сейчас она в стадии продления) и включен в единый реестр российского ПО, что в некоторых случаях очень важно. Бесплатно можно использовать шлюз для работы с ним до 9-ти пользователей, либо получить 35-ти дневную бесплатную версию без ограничения числа пользователей для теста

В обоих случаях это будут полнофункциональные варианты работы шлюза.

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

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

AH и ESP

Три основных компонента безопасности — доступность, аутентичность и конфиденциальность. IPsec может обеспечивать аутентичность, при этом ничего не делая для конфиденциальности.

Протокол AH (Authentication Header) добавляет в пакет специальный заголовок с контрольной суммой. На практике он используется редко, поскольку никак не способствует конфиденциальности.

Тем не менее его можно встретить в приложениях, где важна только аутентичность. К примеру, протокол маршрутизации OSPFv2 использовал пароли и суммы MD5 для защиты от поддельных анонсов, а его наследник OSPFv3 не включает никакой функциональности для защиты — вместо этого предлагается использовать IPsec в транспортном (прозрачном) режиме и с одной подписью AH без шифрования.

ESP (Encapsulated Security Payload) шифрует содержимое пакета и добавляет хеши. Его можно использовать в двух режимах — транспортном и туннельном. Это сейчас в сетях IPv4 любой VPN немыслим без маршрутизации частных (серых) адресов через туннель, поскольку со внешним миром хосты общаются через NAT. Но IPsec старше NAT и изначально шифровал только полезную нагрузку пакетов, не трогая заголовки, — это и есть транспортный режим.

В туннельном режиме ESP шифрует весь пакет и передает его как полезную нагрузку, на другой стороне он извлекается, расшифровывается и маршрутизируется дальше.

Что интересно, оба они не работают поверх TCP или UDP, а используют отдельные номера протоколов IP. Во всяком случае, по умолчанию — ESP может быть инкапсулирован в UDP для работы через NAT, но об этом позже.

Настройка IPSEC при конфигурации «сеть-сеть»

С помощью IPsec подключаются целые сети к другим сетевым сегментам, организовывая межсетевое взаимодействие. Для этого нужно установить маршрутизаторы IPsec в каждой сети так, чтобы трафик узла одной сети прозрачно обрабатывался и достигал узла другой сети. В таких сетях должны работать маршрутизаторы IPsec, проверяющие подлинность и соединяющие эти сети через безопасный туннель трафиком, проходящим через Интернет или любую другую сеть. Если пакеты будут перехвачены во время передачи, для взлома защищающего их шифра потребуется применение метода перебора, что довольно растянуто по времени и к окончанию процедуры может стать уже не актуальным.

Для настройки межсетевого соединения понадобится следующая информация:

• публичные IP-адреса выделенных маршрутизаторов IPsec;
• IP-адреса интерфейсов шлюзов, маршрутизирующих трафик узлов сети в Интернет;
• уникальное имя соединения IPsec (например, );
• созданный с помощью ключ шифрования;
• предварительный общий ключ проверки подлинности.

Для примера рассмотрим туннель IPsec между сетью my_net1.com и сетью my_net2.com. Первая сеть имеет адрес 192.168.1.0/24, а вторая — 192.168.2.0/24. IP-адрес шлюза в первой сети — 192.168.1.254, а во второй — 192.168.2.254. Маршрутизаторы IPsec реализованы отдельно от шлюзов и используют два сетевых интерфейса: eth0 имеет статический публичный IP-адрес, обращённый к Интернету, а eth1 принимает и обрабатывает пакеты из локальной сети.

Соединение IPSEC между сетями использует предварительный общий ключ , Ниже приведёно содержимое файла , созданного для межсетевого соединения IPSEC в первой сети. В примере это соединение имеет уникальное имя ipsec1.

TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
SRCGW=192.168.1.254
DSTGW=192.168.2.254
SRCNET=192.168.1.0/24
DSTNET=192.168.2.0/24
DST=X.X.X.X

Соединение устанавливается при загрузке () и использует метод проверки подлинности с общим ключом ().

Ниже приведено содержимое файла с предварительным общим ключом (названного , где X равен 0 для первой сети и 1 — для второй).

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

Содержимое файла конфигурации :

# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.

path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

sainfo anonymous
{
	pfs_group 2;
	lifetime time 1 hour ;
	encryption_algorithm 3des, blowfish 448, rijndael ;
	authentication_algorithm hmac_sha1, hmac_md5 ;
	compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"

Ниже приведена конфигурация конкретного соединения с удалённой сетью. Этот файл называется (где X.X.X.X IP-адрес удалённого маршрутизатора IPsec).

;
remote X.X.X.X
{
        exchange_mode aggressive, main;
        my_identifier address;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2 ;
        }
}

До запуска соединения IPSEC маршрутизация IP в ядре должна быть включена. Для этого можно отредактировать файл /etc/sysctl.conf и задать net.ipv4.ip_forward равным 1.

Чтобы изменение вступило в силу нужно выполнить команду: .

Установить соединение можно, либо перезагрузкой маршрутизаторов, либо выполнив на маршрутизаторах от имени root следующую команду: .

Маршруты автоматически создаёт сценарий инициализации, вызываемый командой при активизации соединения IPsec.

Для просмотра списка сетевых маршрутов можно выполнить команду: .

Проверить IPsec-соединение можно запуском утилиты tcpdump, например так: .

Пакет должен содержать заголовок AH и данные ESP. При этом наличие ESP будет означать, что шифрование работает. Ниже показан пример просмотра такого пакета из установленного соединения:

12:24:26.155529 my_net2.com > my_net1.com: AH(spi=0x021c9834,seq=0x358): \
my_net2.com > my_net1.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \
(ipip-proto-4)

История

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

И в 1994 году Совет по архитектуре Интернет (IAB) выпустил отчёт «Безопасность архитектуры Интернет». Он посвящался в основном способам защиты от несанкционированного мониторинга, подмены пакетов и управлению потоками данных. Требовалась разработка некоторого стандарта или концепции, способной решить эту проблему. В результате, появились стандарты защищённых протоколов, в числе которых и IPsec. Первоначально он включал в себя три базовые спецификации, описанные в документах (RFC1825, 1826 и 1827), однако впоследствии рабочая группа IP Security Protocol IETF пересмотрела их и предложила новые стандарты (RFC2401 — RFC2412), используемые и в настоящее время.

Согласование настроек шифрования

В IKE есть возможность предложить второй стороне несколько вариантов на выбор, и соединение будет установлено, если у обеих сторон найдется хотя бы один совпадающий вариант. Это общий принцип работы протоколов обмена ключами, TLS работает так же, но в TLS периодически удаляют поддержку устаревших алгоритмов. В IKE безопасность выбора алгоритмов остается на совести пользователя. Заведомо уязвимые DES и MD5 из протокола официально не исключены и до сих пор поддерживаются многими реализациями.

С каждым туннелем ассоциировано одно или несколько «предложений» (proposals). Предложения обрабатываются до первого совпадения. Отсюда следствие: вполне возможна ситуация, когда зловредный (или безответственно настроенный) сервер предложит клиенту устаревшие алгоритмы, а неаккуратно настроенный клиент согласится. У некоторых клиентов вообще может не быть возможности выбрать алгоритмы вручную, а особо ленивые админы любят делать для всех клиентов один большой proposal со всеми мыслимыми алгоритмами. Сортировать алгоритмы по надежности стандарт не обязывает, и стороны вполне могут договориться на шифр полувековой давности.

Более того, официально поддерживается null cipher — опция не шифровать трафик вообще.

Чтобы убедиться в безопасности настроек, в идеале нужно немного понимать принципы криптографии и следить за новостями. Тем не менее можно привести ряд рецептов.

В IKE вполне можно использовать разные наборы алгоритмов для Phase 1 и Phase 2. Смысла в этом немного, но возможность имеется.

Политики IPSec

Общий набор параметров безопасности IPSec называется политикой IPSec. Политика состоит из набора правил, определяющих обработку сетевого трафика. Каждое правило содержит относящиеся к нему набор фильтров и действия, которые данное правило будет производить с пакетом, соответствующим условиям фильтра. В качестве параметров фильтров могут быть заданы IP-адреса, адреса сети или полное доменное имя отправителя и получателя пакета, тип IP-протокола (ICMP, TCP, UDP и т. д.), номера TCP и UDP портов отправителя и получателя.

Правило также определяет, какие методы аутентификации потребуются для обмена данными между хостами. В качестве действия задается один из следующих параметров — пакет блокируется (Block), передается без применения IPSec (Permit) и передается с применением IPSec (Negotiate Security, согласование безопасности).

Протокол IKE позволяет установить доверительные отношения между хостами, согласовать параметры безопасности и динамического создания общего ключа. Соглашение о параметрах безопасности, под управлением которых создается ключ, называют сопоставлением безопасности (SA, security association).

Обмен данными между двумя хостами с применением IPSec происходит приблизительно так:

При получении пакета драйвер IPSec на изображенном слева компьютере обращается к своему списку фильтров, и определяет, что пакет должен передаваться безопасно. Служба IKE на нем, используя UDP-порт 500, выполняет сопоставление безопасности с другим компьютером, при этом пакеты IKE не обрабатываются с помощью IPSec. Если согласование в основном режиме установлено, оба хоста считают, что между ними установлены доверительные отношения и переходят в быстрый режим. Далее инициировавший соединение хост передает параметры безопасности и фильтр быстрого режима. Второй хост принимает набор параметров и завершает на своей стороне их обработку, чтобы создать пару SA-сопоставлений — для исходящего и входящего трафика. Отправляющая сторона использует исходящее сопоставление для подписи (а если задано параметрами, то и шифрования) исходящих пакетов. Принимающий компьютер при помощи входящего сопоставления осуществляет проверку принимаемых пакетов (и, если необходимо, выполняет их расшифровку). Драйвер IPSec принимающей стороны выполняет «перевод» пакетов в обычный IP-формат.

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

Следует учесть, что существующие в сети межсетевые экраны, прокси или NAT-устройства могут накладывать ограничения на применение IPSec или даже сделать невозможным его использование. Это может произойти, например, в том случае, когда в подписанном пакете подобное устройство перепишет IP-заголовок. Тогда на принимающей стороне он просто будет отброшен, так как не пройдет проверку. На таких устройствах необходимо будет разрешить передачу пакетов IKE и IPSec.

• IKE использует порт UDP 500
• IKE/IPsec NAT-T использует порт UDP 4500
• ESP использует IP-протокол 50
• AH использует IP-протокол 51

Впрочем, в Windows Server 2003 реализована новая спецификация IPSec, которая позволяет преобразовывать пакеты устройствам NAT.

Использование

IPsec_VPN

Протокол IPsec используется, в основном, для организации VPN-туннелей. В этом случае протоколы ESP и AH работают в режиме туннелирования. Кроме того, настраивая политики безопасности определенным образом, протокол можно использовать для создания межсетевого экрана. Смысл межсетевого экрана заключается в том, что он контролирует и фильтрует проходящие через него пакеты в соответствии с заданными правилами. Устанавливается набор правил, и экран просматривает все проходящие через него пакеты. Если передаваемые пакеты попадают под действие этих правил, межсетевой экран обрабатывает их соответствующим образом. Например, он может отклонять определенные пакеты, тем самым прерывая небезопасные соединения. Настроив политику безопасности соответствующим образом, можно, например, запретить веб-трафик. Для этого достаточно запретить отсылку пакетов, в которые вкладываются сообщения протоколов HTTP и HTTPS. IPsec можно применять и для защиты серверов — для этого отбрасываются все пакеты, кроме пакетов, необходимых для корректного выполнения функций сервера. Например, для Web-сервера можно блокировать весь трафик, за исключением соединений через 80-й порт протокола TCP, или через порт TCP 443 в случаях, когда применяется HTTPS. Пример:

С помощью IPsec здесь обеспечивается безопасный доступ пользователей к серверу. При использовании протокола ESP все обращения к серверу и его ответы шифруются. Однако за VPN-шлюзом (в домене шифрования) передаются открытые сообщения.
Другие примеры использования IPsec:

• шифрование трафика между файловым сервером и компьютерами в локальной сети, используя IPsec в транспортном режиме.
• соединение двух офисов с использованием IPsec в туннельном режиме.

Encapsulating Security Payload

Security Parameters Index (32 bits)

Индекс параметров безопасности (аналогичен соответствующему полю AH). Значение этого поля вместе с IP-адресом получателя и протоколом безопасности (ESP-протокол), однозначно определяет защищённое виртуальное соединение (SA) для данного пакета. Диапазон значений SPI 1…255 зарезервирован IANA для последующего использования.

Sequence Number (32 bits)

Последовательный номер (аналогичен соответствующему полю AH). Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может и отказаться от услуги по защите от повторной передачи пакетов, оно всегда присутствует в ESP-заголовке. Отправитель (передающий IPsec-модуль) должен всегда использовать это поле, но получатель может и не нуждаться в его обработке.

Payload data (variable)

Это поле содержит данные (в зависимости от выбора режима — туннельного или транспортного, здесь может находиться либо весь исходный инкапсулированный пакет, либо лишь его данные) в соответствии с полем «Next Header». Это поле является обязательным и состоит из целого числа байтов. Если алгоритм, который используется для шифрования этого поля, требует данных для синхронизации криптопроцессов (например, вектор инициализации — «Initialization Vector»), то это поле может содержать эти данные в явном виде.

Padding (0-255 octets)

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

Pad Length (8 bits)

Размер дополнения (в байтах).

Next Header (8 bits)

Это поле определяет тип данных, содержащихся в поле «Payload data».

Integrity Check Value

Контрольная сумма. Служит для аутентификации и проверки целостности пакета. Должна быть кратна 8-байтам для IPv6, и 4-байтам для IPv4.

Обработка входных IPsec-пакетов

После получения пакета, содержащего сообщение ESP-протокола, приёмный IPsec-модуль ищет соответствующее защищённое виртуальное соединение (SA) в SAD, используя IP-адрес получателя, протокол безопасности (ESP) и индекс SPI. Если соответствующее SA не найдено, пакет уничтожается. Найденное защищённое виртуальное соединение (SA) указывает на то, используется ли услуга по предотвращению повторной передачи пакетов, то есть на необходимость проверки поля Sequence Number. Если услуга используется, то поле проверяется. Для этого, так же как и в AH, используется метод скользящего окна. Приёмный IPsec-модуль формирует окно с шириной W. Левый край окна соответствует минимальному последовательному номеру (Sequence Number) N правильно принятого пакета. Пакет с полем Sequence Number, в котором содержится значение, начиная от N+1 и заканчивая N+W, принимается корректно. Если полученный пакет оказывается по левую границу окна- он уничтожается. Затем, если используется услуга аутентификации, приёмный IPsec-модуль вычисляет ICV по соответствующим полям принятого пакета, используя алгоритм аутентификации, который он узнает из записи об SA, и сравнивает полученный результат со значением ICV, расположенным в поле «Integrity Check Value». Если вычисленное значение ICV совпало с принятым, то пришедший пакет считается действительным. Если проверка дала отрицательный результат, то приёмный пакет уничтожается. Далее производится расшифрование пакета. Приёмный IPsec-модуль узнает из записи об SA, какой алгоритм шифрования используется и секретный ключ. Надо заметить, что проверка контрольной суммы и процедура расшифрования могут проводиться не только последовательно, но и параллельно. В последнем случае процедура проверки контрольной суммы должна закончиться раньше процедуры расшифрования, и если проверка ICV провалилась, процедура расшифрования также должна прекратиться. Это позволяет быстрее выявлять испорченные пакеты, что, в свою очередь, повышает уровень защиты от атак типа «отказ в обслуживании»(DOS-атаки). Далее расшифрованное сообщение в соответствии с полем Next Header передается для дальнейшей обработки.