Где это ваше секретное слово (PSK — publicly shared key),

Часть практическая windows’овая, в которой мы ничего не делаем, кроме настройки IPSEC соединения.

Создаем политику безопасности IPSEC

Добавляем правило безопасности в нашу политику.

Добавляем фильтр для трафика, который будем шифровать.

Добавляем фильтр действий (Filter Action).

Заключительная настройка IPSEC.

Часть кульминационная, в которой мы запускаем IPSEC соединение.

Выдержка из message.log

Feb 13 12:49:05 obelisk ipsec_setup: Starting FreeS/WAN IPsec 1.99.
Feb 13 12:49:05 obelisk ipsec_setup: Using /lib/modules/2.4.24/kernel/net/ipsec/ipsec.o
Feb 13 12:49:05 obelisk klips_info:ipsec_init: KLIPS startup, FreeS/WAN IPSec version: 1.99
Feb 13 12:49:05 obelisk ipsec_setup: KLIPS debug `none’
Feb 13 12:49:05 obelisk ipsec_setup: KLIPS ipsec0 on homelan

19:39:03.810739 >

Вывод ipsec look:

ipsec look
obelisk Fri Feb 13 12:56:31 MSK 2004

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

Для начала давайте посмотрим, что сделано и что мы должны были сделать. Мы установили IPSEC соединение, обеспечивающие шифрование между двумя нашими компьютерами. Вроде бы мы добились своей цели, однако все зависит от ситуации. Для уменьшения нештатных ситуаций (это когда все куда-то бегут и отовсюду слышится: «хакают! хакают!», хотя большинство спортсменов-бегунов имеют об этом весьма туманные представления) необходимо обязательно установить защиту от IP спуфинга на интерфейсах с выключенными rp_filter’ми. Потом мы должны быть уверенны, что наши сервера будут взаимодействовать только средствами IPSEC. В windows это может быть обеспечено отключением опции Allow unsecured communication with non-IPSec-aware computer и Accept unsecured communication, but always respond using IPSec в политике безопасности IPSEC. В linux это обеспечивается опцией auto=start, которая автоматически запускает шифрованный туннель и фильтрацией трафика с помощью iptables, разрешая взаимодействие только с помощью IPSEC, отбрасывая нешифрованный трафик:

iptables -A INPUT -p udp -i -s —sport 500 —dport 500 -j ACCEPT
iptables -A OUTPUT -p udp -o -d —sport 500 —dport 500 -j ACCEPT

iptables -A INPUT -p esp -i -s -j ACCEPT
iptables -A OUTPUT -p esp -o -d -j ACCEPT

iptables -A INPUT -i -s -j DROP
iptables -A OUTPUT -o -d -j DROP

Если необходимо, то можно добавить:

iptables -A INPUT -p ah -i -s -j ACCEPT
iptables -A OUTPUT -p ah -o -d -j ACCEPT

Компы и автомобили

Вводная часть

Есть такая клёвая штука, называется Seafile. Это «облачное хранилище», с возможностью развёртывания на своих серверах. Реально функциональная и удобная вещь. Позволяет шарить папки/файлы, как на определённый, так и неопределённый круг пользователей. Позволяет расшарить папку для аплоада, причём содержимое пользователям видно не будет, можно только заливать файлы. Есть клиенты Seafile под винду, линукс и макось. И самое клёвое — серверная часть работает под FreeBSD 🙂 Домашнее облачко перевёл с Owncloud/Netxtcloud на Seafile.

Развернули в конторе для внутренних нужд Seafile, правда, не на фре, а на CentOS. Я начал настраивать авторизацию пользователей Seafile в AD через LDAP, и напоролся на граблю. По LDAP авторизация идёт, а по LDAPS — нет. А это неправильно, когда пароли по сетке ходят в открытом виде — всё-таки у нас тут инфобез, и всё такое, и по локальной сетке наши пентестеры шарятся тоже только в путь. Начал копать, как же дальше жить, в свете открывшихся фактов. Оказалось, я в этой проблеме не одинок, и существует она (применительно к версии Seafile 6 и CentOS 7) ажно с марта месяца. Нашёл на профильном форуме обсуждение. Если резюмировать, то суть там сводится к тому, что «да, LDAPS сломан, потому что несовместимы либы, которые есть в системе, и которыми пользуется Seafile. Можете попробовать закостылить путём переноса части сиафайловских библиотек в отдельный каталожек и перезапуска сервиса, чтобы Seafile стал использовать системные библиотеки». Но в моём случае это не прокатило. И у народа с форума тоже. По итогам вялого обсуждения разработчики обещали пересобрать Seafile под центось. 23-го июня, на вопрос: «чуваки, ну когда же?!» от разработчиков был получен ответ: «Сорян, пацаны, времени ваще нет!».

В общем, стало понятно, что милостей от природы ждать не стоит, и нужно думать, что делать. Основная задача — зашифровать трафик между сервером Seafile и контроллерами домена. Т. е. нужен туннель. Мы же серьёзная контора, поэтому и туннель у нас должен быть серьёзный. Не какой-нибудь жалкий PPTP/L2TP, или OpenVPN, прости-господи, а самый что ни на есть IPsec. Для разнообразия — не в туннельном, а в транспортном режиме. Так как скрывать IP-адреса нам не нужно, и достаточно только шифрования data payload, то транспортный.

Процесс настройки.

Итак, в красном углу ринга у нас CentOS 7. В синем — её соперник, Windows 2012 R2. Если с настройкой IPsec в винде вопросов особо не возникло — там это делается с помощью Windows Firewall, то с линуксом пришлось пое. эээ. поекспериментировать 🙂 И после каких-то жалких 4-х дней непрерывной возни, с помощью гугла, профильных сообществ и такой-то матери удалось поднять IPsec транспорт между CentOS (IP 192.168.100.15) и Windows 2012 R2 (192.168.170.10).

Изначально проблема была в том, что не устанавливалась фаза 1. Несмотря на совпадающие параметры, соединение не поднималось и SA не создавались. В дампе это выглядело так:

Т. е. инициирующий пакет с центоси улетает, винда на него отвечает, но центось больше ничего не предпринимает. И так продолжалось по кругу. В логах при этом было следующее:

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

В процессе чтения мудрых указаний партии документации с сайта Strongswan сниошло озарение, что теперь, оказывается, есть две схемы конфигурации и запуска IPsec. Первый — это по старинке, через демон strongswan и настройками в файле ipsec.conf. Именно этот способ и был изначально использован. Но суровая практическая реальность показала, что при этом как минимум не идёт логирование событий IPsec, настраиваемое в файле /etc/strongswan/strongswand.d/charon-logging.conf.

И есть более стильный-модный-молодёжный способ — это настройка через конфиг /etc/strongswan/swanctl/swanctl.conf и последующий запуск с помощью сервиса strongswan-swanctl. Это два взаимоисключающих способа настройки и использования Strongswan. В итоге после долгих и бесплодных попыток запустить Strongswan с конфигом из ipsec.conf было принято волевое решение перенести настройки в swanctl.conf.

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

Перезапускаем сервис strongswan-swanctl, иии. Ничего. Туннель не поднимается. Начинаем запускать его руками: swanctl —load-all:

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

Есть контакт. Проверяем, создались ли SA-шки (в фоне постоянно висит пинг на соседа по туннелю):

Ответ отрицательный. И пинги уходят по чистому каналу, как показывает tcpdump. Иными словами — соединение загрузилось, но не активировалось. Пробуем запустить руками:

Проверяем, установились ли SA-шки:

Работает. Т. е. руками туннель запускается, а при перезапуске сервиса он не грузится, и не активируется. Начинаем копать, в чём тут дело. Перезапуск сервиса с последующим анализом /var/log/messages приносит следующие новости:

То есть, swanctl, запускаемый с правами рута из-под systemd не получает доступа к каталогам и конфигу swanctl.conf. Лихо, что сказать. Вот за такие вещи я и «люблю» Linux. 🙂

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

Добавил права на чтение swanctl.conf для others. Не помогло — всё равно жалуется, что нет доступа. Полез смотреть логи SELinux. В них тоже чисто. Опять было достал бубен, но потом вспомнил, что есть категории событий, которые блокируются по-тихому, и в /var/log/audit/audit.log не попадают. Включаем логирование всех событий:

После перезапуска сервиса смотрим в логи. Ну точно! Опять проклятый SELinux:

И начинается кропотливый процесс докидывания разрешений в политиках SELinux. Итоговый файл политик получился такой:

Применяем всю эту красоту:

После этого перезапускаем сервис и смотрим в логи: