Пароли в SHA256 в OpenLDAP

Понадобилось нам поднять для определенных целей OpenLDAP. С условием, что пароли, вернее хэши наших пользователей, мы будем брать из уже существующей SQL-базы. Из входящих данных у нас был SQL-запрос, вызвращающий пользователей с хэшами и утверждение нашего DBA, что пароли хешированы в SHA256.

Получаю хэш пользователя из базы, проверяю через

echo -n "test" | sha256sum
9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08  -

Строка совпадает. Быстро ваяем скрипт, который заполняет нужные поля в LDAP, в том числе вставляет эту строку в качестве пароля.

Пробуем авторизоваться:

ldapwhoami -vvv -h 127.0.0.1 -p 389 -D "cn=Иванов Иван,ou=staff,dc=example,dc=com" -W
Enter LDAP Password:                                                                                             
ldap_bind: Invalid credentials (49)

Что-то не работает.

Google подтверждает, что OpenLDAP умеет в SHA256, однако разные статьи говорят, что для этого надо либо использовать сторонний модуль slapd-sha2.so, либо воспользоваться услугами самой операционной системы, ведь пароли в Linux хранятся в SHA256/SHA512.

Выбираю второй вариант. Пишут, что надо добавить префикс {CRYPT}. Чтобы указать, что это хэш sha256, делаю предположение, что надо добавить $5$:

cat ./chpass.ldif 
dn: cn=Иванов Иван,ou=staff,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: {CRYPT}$5$9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

Заливаю изменение, проверяю...

ldap_bind: Invalid credentials (49)

Нахожу в OpenLDAP FAQ:
Just to state the obvious, SHA-256 and SHA-512 based "glibc" crypt algorithms $5$ and $6$ are totally different from plain (or salted) "{SHA256}" algorithms. The libc crypt variants do a lot of nonsensical transpositions to increase the computational load.

Черт, пишут что алгоритмы различаются.

Чтобы удостоверится, вставляем свой хэш из /etc/shadow в качестве пароля с префиксом {CRYPT}$6$.

Работает, конечно.

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

Параллельно в гугле находим, что идентичный команде sha256sum хэш даёт команда:

echo -n "test" | openssl dgst -sha256
(stdin)= 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

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

openssl passwd -5

говорит Unknown.

Ладно, читаем мануалы дальше. Различие в "соли". Passwd в Linux и в openssl делают пароль с солью, а sha256sum, понятное дело, без. И как раз-таки в OpenLDAP это должно работать, при использовании префикса {SHA256}

Видимо надо искать модуль. И находим информацию, что в актуальных версиях OpenLDAP модуль уже присутствует в системе. А файл slapd-sha2.so мы не могли найти потому, что он называется по-другому. Сотни статей по openldap+sha256 уже не актуальны, кто бы мог подумать :)

Для подтверждения этого выкачиваю исходники openldap с гита, нахожу модуль и в его Makefile'е вижу сему подтверждение. Файл на выходе действительно называется pw-sha2.la / pw-sha2.so.

Пробую просто добавить префикс {SHA256}:

cat ./chpass.ldif 
dn: cn=Иванов Иван,ou=staff,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: {SHA256}9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

Заливаю, пробую, не работает.

Может модуль не подгружен?
Конфиг OpenLDAP сейчас хранится в самом OpenLDAP, так что смотрим:

# slapcat -b cn=config -a "(objectClass=olcModuleList)"
...
olcModuleLoad: {1}pw-sha2.la
...

И видим, что модуль загружен.

Кстати, у нас уже есть выкачанные исходники OpenLDAP. Без особой надежды лезу в них поковырятся, мож пойму, что ему надо. В readme модуля sha2 до сих пор сказано, что надо собрать slapd-sha2.so, скопировать его в нужное место и подключить через конфиг slapd.conf (т.е. инструкция в исходниках сама устарела, ведь и библиотека называется по-другому, и конфиг OpanLDAP уж много лет как в самом OpenLDAP).

Но в том же readme ниже нахожу команду для создания хэша для тестирования:

$ echo -n "secret" | openssl dgst -sha256 -binary | openssl enc -base64
K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=

Что ж, мы были близки. Пароль надо завернуть в base64. И это при том, что в LDAP оно еще раз заворачивается в base64. Но не строчное его представление, а "бинарное".

Делаю base64 над своим паролем, вставляю с префиксом {SHA256}:

# echo -n "test" | openssl dgst -sha256 -binary | base64
n4bQgYhMfWWaL+qgxVrQFaO/TxsrC4Is0V1sFbDwCgg=

# cat ./chpass.ldif 
dn: cn=Иванов Иван,ou=staff,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: {SHA256}n4bQgYhMfWWaL+qgxVrQFaO/TxsrC4Is0V1sFbDwCgg=

Заливаю, проверяю, работает!

Result: Success (0)

В скрипте это можно сделать так:

echo -n "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08" | xxd -r -p | base64

Генерация запроса на подпись ключа

Напоминалка себе, как генерировать ssl csr:

openssl genrsa -out ./domain.com.key 2048
openssl req -new -sha256 -key ./domain.com.key -out ./domain.com.csr

Сервер OpenVPN с аутентификацией через Radius

Настройка сервера OpenVPN с аутентификацией через Radius в Debian:

# aptitude install openvpn openvpn-auth-radius

# cat /etc/openvpn/radiusplugin.cnf
NAS-Identifier=openvpn
Service-Type=2
Framed-Protocol=1
NAS-Port-Type=5
NAS-IP-Address=10.100.10.85
OpenVPNConfig=/etc/openvpn/server.conf
subnet=255.255.255.0
overwriteccfiles=true
server
{
        # The UDP port for radius accounting.
        acctport=1815
        # The UDP port for radius authentication.
        authport=1812
        # The name or ip address of the radius server.
        name=10.100.4.100
        # How many times should the plugin send the if there is no response?
        retry=1
        # How long should the plugin wait for a response?
        wait=1
        # The shared secret.
        sharedsecret=mymegasecretkey
}

# cat /etc/openvpn/server.conf
local my_public_ip
port 443
proto tcp
dev tun
tun-mtu 1500
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key 
dh /etc/openvpn/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
client-cert-not-required
username-as-common-name
ifconfig-pool-persist ipp.txt
push "route 10.100.0.0 255.255.0.0"
push "route 10.102.0.0 255.255.0.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/status.log 1
plugin /usr/lib/openvpn/radiusplugin.so
log-append  /var/log/openvpn/openvpn.log
verb 3

Шифрование домашнего каталога

Миграция на шифрованный раздел.

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

Было:

+----------------------------------------------------+
|                  Disk /dev/sda                     |
| +-------+---------------------------------------+  |
| | sda1  | sda2     lvm                          |  |
| |       | +------+------+------+--------------+ |  |
| |  /    | | /usr | /var | swap | /home        | |  |
| |       | +------+------+------+--------------+ |  |
| +-------+---------------------------------------+  |
|                                                    |
+----------------------------------------------------+

Стало:

+----------------------------------------------------+
|                  Disk /dev/sda                     |
| +-------+---------------------------------------+  |
| | sda1  | sda2     lvm                          |  |
| |       | +------+------+------+--------------+ |  |
| |  /    | | /usr | /var | swap | luks         | |  |
| |       | |      |      |      | +----------+ | |  |
| |       | |      |      |      | | /home    | | |  |
| |       | |      |      |      | +----------+ | |  |
| |       | +------+------+------+--------------+ |  |
| +-------+---------------------------------------+  |
|                                                    |
+----------------------------------------------------+

* Кстати, схема-то упрощенная. У lvm не обозначена еще volume group :) *

Для этого мне понадобилось:

Включить в ядре опции:

 Cryptographic API -> SHA224 and SHA256 digest algorithm (CONFIG_CRYPTO_SHA256)

и

Device Drivers -> 
 Multiple devices driver support (RAID and LVM) -> 
 Device mapper support -> 
 Crypt target support (CONFIG_DM_CRYPT)

Далее я пересобрал ядро и установил пакет cryptosetup.

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

На домашнем разделе занято всего ~50 гигабайт.

Значит уменьшаю home до 60 гигабайт, создаю новый том lvm и шифрую его:

# lvresize -r -L60G /dev/mapper/vg-home

# lvcreate -n hm -l 51734 vg

# cryptosetup luksFormat /dev/mapper/vg-hm

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

Создаю на новом домашнем разделе файловую систему и переношу туда данные со старого раздела

# cryptsetup luksOpen /dev/mapper/vg-hm secret
# mkfs.ext4 /dev/mapper/secret
# mkdir /mnt/temp
# mount /dev/mapper/vg-hm /mnt/temp
# cp -r /home/* /mnt/temp
# umount /mnt/temp

Теперь устанавливаю pam_mount. У этого пакета необходимо включить USE-флаг crypt.

Добавляю в /etc/pam.d/system-auth строчки (выделены):

auth            required        pam_env.so 
auth            required        pam_unix.so try_first_pass likeauth nullok 
auth            optional        pam_permit.so
auth            optional        pam_mount.so

account         required        pam_unix.so 
account         optional        pam_permit.so

password        required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 
password        required        pam_unix.so try_first_pass use_authtok nullok sha512 shadow 
password        optional        pam_permit.so
  
session         required        pam_limits.so 
session         required        pam_env.so 
session         required        pam_unix.so 
session         optional        pam_permit.so
session         optional        pam_mount.so

А в /etc/security/pam_mount.conf.xml следующее:

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">
<!--
        See pam_mount.conf(5) for a description.
-->

<pam_mount>

                <!-- debug should come before everything else,
                since this file is still processed in a single pass
                from top-to-bottom -->

<debug enable="0" />

                <!-- Volume definitions -->
<volume user="yuri" path="/dev/mapper/vg-hm" mountpoint="~" cipher="aes-cbc-essiv:sha256" />

                <!-- pam_mount parameters: General tunables -->

<!--
<luserconf name=".pam_mount.conf.xml" />
-->

<!-- Note that commenting out mntoptions will give you the defaults.
     You will need to explicitly initialize it with the empty string
     to reset the defaults to nothing. -->
<mntoptions allow="nosuid,nodev,loop,encryption,nonempty,allow_root,allow_other" />
<!--
<mntoptions deny="suid,dev" />
<mntoptions allow="*" />
<mntoptions deny="*" />
-->
<mntoptions require="nosuid,nodev" />

<!-- requires ofl from hxtools to be present -->
<logout wait="0" hup="0" term="0" kill="0" />


                <!-- pam_mount parameters: Volume-related -->

<mkmountpoint enable="1" remove="true" />

</pam_mount>

И не забыть убрать строчку с home из /etc/fstab.

Симметричное шифрование файлов с помощью GPG

Для хранения файлов в Dropbox я использую симметричное шифрование с помощью GPG.
Зашифровать:

gpg -c --cipher-algo AES256 secret_file

Расшифровать:

gpg -d secret_file.gpg

Шифрованный образ раздела

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

Использовать будем старый добрый LUKS, с той небольшой разницей, что работа будет вестись с loop-устройством.
Создали сам образ из псевдослучайных значений:

# dd if=/dev/urandom of=/mnt/250/image.img bs=4M count=10

Создаём ассоциацию образа и loop-устройства:

# losetup /dev/loop0 /mnt/250/image.img

Вместо непосредственно указания loop-устройства можно поставить опцию -f, что значит "найти незанятое устройство".
А дальше работа с /dev/loop0 ничем не отличается от обычной работы cryptosetup:

# cryptosetup luksFormat /dev/loop0
# cryptosetup luksOpen /dev/loop0 secret
# mkfs.ext3 /dev/mapper/secret
# mount /dev/mapper/secret /mnt/secret

Отключение в таком порядке:

# umount /mnt/secret
# cryptosetup luksClose secret
# losetup -d /dev/loop0

Использование стеганографии

Википедия:

Стеганография — это наука о скрытой передаче информации путём сохранения в тайне самого факта передачи.

В отличие от криптографии, которая скрывает содержимое секретного сообщения, стеганография скрывает само его существование.

Шифрование раздела

Как я делал шифрованный раздел.