Ключевые слова:security, ipsec, vpn, freebsd, bsd, auth, tunnel, (найти похожие документы)
From: softerra
Subject: Установка защищенного соединения на FreeBSD через IPSec
Установка защищенного соединения на FreeBSD
Перевод опубликован на http://www.softerra.ru/freeos/15905
Статья является переводом текста Майка ДеГро-Берча (Mike DeGraw-Bertsch),
опубликованного по адресу http://www.onlamp.com/pub/a/bsd/2001/12/10/ipsec.html
Сокращение IPSec происходит от 'IP security'. Это протокол, который
предлагает методы прозрачного шифрования и аутентифицирования всего
интернет-трафика на пакетном уровне. Таким образом, даже потенциально
небезопасные протоколы, такие как SMTP, могут быть надежно защищены.
IPSec является неотъемлемой частью IPv6, для IPv4 он является
необязательным 'прикрученным' дополнением. Однако несмотря на это
IPSec работает, и работает очень хорошо!
IPSec основан на двух ключевых компонентах: аутентификационном
заголовке (Authentication Header (AH) и инкапсуляционном протоколе
безопасности (Encapsulating Security Protocol (ESP). AH предоставляет
аутентификацию, подтверждая, что присланный отправителем пакет
действительно пришел от него, и что этот пакет действительно содержит
те данные, которые были посланы. ESP шифрует данные в пакете и может
так же предоставлять аутентификационные услуги (подробнее об
аутентификации через ESP смотрите на сайте рабочей группы IPSec --
http://www.ietf.org/html.charters/ipsec-charter.html).
ESP и AH могут быть использованы в режиме транспорта и туннеля.
Транспортный режим предоставляет защищенное соединение между двумя
точками, тогда как туннель дает VPN-подобное соединение
(VPN-соединение позволяет пользователям находящимся вне локальной сети
иметь к ней защищенный доступ).
В транспортном режиме данные (а в случае AH, заголовок, например IP
адрес отправителя) пакета подписываются и/или шифруются. Затем пакет
передается по назначению, где он проверяется, дешифруется и далее
обрабатывается как обычный IP пакет. Транспортный режим чаще
используется для передачи данных между двумя узлами. В транспортном
режиме происхождение пакета имеет значение, поэтому шифрованный
трафик не может проходить через сети, в которых используется NAT.
В туннельном режиме AH или ESP (и иногда оба) шифруют весь пакет с
данными и помещают результат внутрь нового пакета. Этот пакет
отправляется на другую сторону туннеля, где данные расшифровываются и
проверяются. После этого восстановленный первоначальный пакет
обрабатывается как обычно, и, если необходимо, пересылается к
необходимой цели.
Туннельный режим лучше всего подходит для обмена трафиком между
двумя маршрутизаторами, или узлом и маршрутизатором. Так как исходный
пакет находится в неприкосновенности, туннельный режим ESP позволяет
пакетам проходить через NAT-сети. Туннельный режим ESP является
отличным способом защитить незащищенные участки сети. К примеру
благодаря беспроводной сети я пишу эту статью на ноутбуке, сидя в
гостиной. Поскольку WEP (Wireless Equivalent Privacy
- протокол шифрования используемый в беспроводных устройствах) крайне
незащищен, весь трафик между ноутбуком и Интернетом шифруется и
туннелируется к моей базе беспроводного доступа (FreeBSD-сервер).
Таким образом никто не может поглядеть мой трафик, когда он
путешествует 'по воздуху'. Это также означает что никто другой не
может использовать мое беспроводное соединение - но об этом в
следующий раз.
Установка IPSec
IKE (не Эйзенхауэр)
Во-первых вы должны сконфигурировать оба компьютера для использования
IKE (Internet Key Exchange). IKE - это протокол который позволяет
IPSec обмениваться шифровальными ключами безопасно и автоматически. В
FreeBSD (и NetBSD), IKE поддерживается демоном racoon. Racoon является
стандартным для FreeBSD 4.0 и выше. Для гарантии совместимости,
однако, неплохой идеей будет убедиться что обе системы оснащены
одинаковыми версиями racoon. Проще всего это сделать установив на
обеих системах racoon из коллекции портов
(/usr/ports/security/racoon).
Конфигурационные файлы racoon по умолчанию находятся в
/usr/local/etc/racoon/ и называются racoon.conf и pke.txt (их следует
создать из файлов .dist, находящихся в этом каталоге). Это то
немногое, что необходимо сделать с .conf файлом, тем не менее вы
можете 'поиграться' с временем жизни ключей (находится в строке
lifetime time xxx <min|sec|hour>). Чем короче время жизни ключа тем
выше защищенность соединения, однако задание излишне короткого времени
жизни ключа может привести к повышенной загрузке процессора, а так же
к паузам в связи, связанными с повторной выдачей ключей.
Самым важным файлом в нашей ситуации является pke.txt. Этот файл
должен иметь права на доступ 600, владельцем должен выступать root,
при несоблюдении этого условия racoon откажется его использовать. Этот
файл содержит предварительно разделенный ключ, т.е. секретную
информацию, которая должна быть известна обоим сторонам для
инициирования соединения.
Итак настало время практического примера. Установим защищенный туннель
между узлом mason (10.0.0.2), он будет сервером туннеля и gluon
(10.0.0.77), который будет туннельным клиентом. Пусть разделенный ключ
будет macplusbsdcool. На mason'е pke.txt должен выглядеть так:
10.0.0.77 macplusbsdcool
Аналогично на gluon'е:
10.0.0.2 macplusbsdcool
Теперь запустим racoon на обеих машинах:
/usr/local/sbin/racoon -f /usr/local/etc/racoon.conf -l
/var/log/racoon.log
Политики
Обе системы готовы к обмену ключами: Но они еще не знают что это
необходимо сделать. Последний шагом является конфигурирование на
каждом узле IPSec-политик - правил, которые описывают как и когда
применять IPSec. Для настройки политик используется программа setkey.
setkey считывает ввод из файла или из командной строки. Поскольку мы
хотим сделать туннель постоянным, нам следует записать политики в файл
и читать их на этапе загрузки командой setkey -f /etc/ipsec.rules
(организацию запуска racoon и setkey при загрузке оставим читателю).
Итак мы хотим что бы все пакеты клиента, шифровались и туннелировались
через сервер mason. На сервере все пакеты к gluon'у также должны
шифроваться. Таким образом ipsec.rules на gluon'е должна выглядеть
следующим образом:
spdadd 10.0.0.77 0.0.0.0/0 any -P out ipsec
esp/tunnel/10.0.0.77-10.0.0.2/require;
spdadd 0.0.0.0/0 10.0.0.77 any -P in ipsec
esp/tunnel/10.0.0.2-10.0.0.77/require;
А на mason'е:
spdadd 0.0.0.0/0 10.0.0.77 any -P out ipsec
esp/tunnel/10.0.0.2-10.0.0.77/require;
spdadd 10.0.0.77 0.0.0.0/0 any -P in ipsec
esp/tunnel/10.0.0.77-10.0.0.2/require;
Эти строки хорошо сами себя объясняют. spdadd указывает, что создается
новая IPSec-политика (как противоположность шифрованию ключа при
ручной настройке IPSec соединения - не беспокойтесь, вам не придется
этого делать). any говорит, что политика применяется к любому
протоколу. out и in указывают направление движения пакетов. И наконец
esp/:/require; указывают что ядро должно использовать IPSec в
туннельном режиме и туннелировать пакеты от одного IP к другому.
Все вышеизложенное полностью применимо к IPv6, для этого необходимо
просто использовать IPv6-адреса.
Применим политики выполнив на обеих машинах команду setkey, описанным
выше образом.
Тестирование
С запущенным на обеих машинах racoon'ом и примененными политиками,
проверим созданный туннель командой ping. Если все настроено
правильно, то после некоторой паузы, вызванной необходимостью
инициировать туннель обменявшись ключами, мы увидим успешные
ICMP-ответы.
Для того что бы увериться в том, что наше соединение действительно
использует IPSec, следует запустить утилиту tcpdump на клиенте и
воспользовавшись утилитой ping обратиться к каким-нибудь машинам в
сети. Вы должны увидеть похожую картину:
13:58:39.045831 gluon > mason: ESP(spi=0x099e806d,seq=0x723)
13:58:39.046566 mason > gluon: ESP(spi=0x0d8d15b6,seq=0x6b2)
13:58:39.187444 gluon > mason: ESP(spi=0x099e806d,seq=0x724) (frag 64877:1480@0+)
Если вы видите не только ESP-трафик, значит что-то не так. Убедитесь,
что адрес назначения на клиенте 0.0.0.0/0. Если вы не видите вообще
никакого ESP-трафика, то это явная ошибка настройки. Проверьте, что
политики согласованы на клиенте и сервере. Убедитесь, что ключи в
файле pke.txt одинаковы на обоих машинах и IP-адреса корректны. Если
все проверено, поглядите лог-файл /var/log/racoon.log на предмет
обнаружения сообщений об ошибках.
Одно слово в качестве предупреждения - если вы перезагрузите одну из
машин и внезапно ощутите проблему с соединением, сбросьте ключи на
обеих машинах запустив команду setkey -F. Вероятно, произошла
рассинхронизация ключей.
Итоги
Сейчас вы должны получить работающий IPSec-туннель между вашим
клиентом и сервером. Пользуйтесь беспроводным подключением,
наслаждаясь тем, что никто не может подсмотреть ваши данные!
Ссылки на дополнительные материалы по теме
1) FreeBSD IPSec mini-HOWTO
http://asherah.dyndns.org/~josh/ipsec-howto.txt
2) FreeBSD Handbook. Chapter 10 Security. 9 IPSec
http://www.freebsd.org/handbook/ipsec.html
3) NetBSD IPSec http://www.netbsd.org/Documentation/network/ipsec/
4) Общие сведения о протоколе IPSec (на русском языке)
http://www.ixbt.com/comm/ipsecure.shtml
