воскресенье, 30 апреля 2017 г.

Контроль программного RAID-массива Linux через Zabbix

Статья про контроль с помощью Zabbix программных RAID-массивов Linux, созданных средствами mdadm. На этот раз кроме установленного и настроенного в системе Zabbix-агента не понадобится более никаких дополнительных пакетов.

Первое решение, приходящее на ум - использовать программу mdadm. Но есть решение получше - использовать для этого файл /proc/mdstat. Для этого можно вписать в файл конфигурации Zabbix-агента /etc/zabbix/zabbix_agentd.conf всего одну строчку:
UserParameter=raid,egrep -c '_U|U_' /proc/mdstat
В этом файле состояние RAID-массивов отображается в виде символов между двумя квадратными скобками. Символ U соответствует исправному диску, символ подчёркивания соответствует неисправному диску. Команда egrep считает количество строчек, в которых символ U соседствует с символом подчёркивания. Предполагается, что в массиве есть как минимум два диска и один из них всегда исправен.

Но однажды мне понадобилось поставить на контроль систему, в которой были настроены массивы RAID-50 и сделано это было так: сначала из дисков собиралось несколько массивов RAID-5, а уже из этих RAID-массивов собирался массив RAID-0. Выглядит это вот так:
$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4]
[raid10]
md0 : active raid0 md3[2] md2[1] md1[0] md4[3]
93765249024 blocks super 1.2 512k chunks

md4 : active raid5 sdw1[0] sdab1[5] sdz1[3] sdx1[1] sdaa1[4] sdac1[7] sdy1[2]
23441312640 blocks super 1.2 level 5, 64k chunk, algorithm 2 [7/7] [UUUUUUU]
bitmap: 1/15 pages [4KB], 131072KB chunk

md2 : active raid5 sdk1[2] sdi1[0] sdl1[3] sdn1[5] sdj1[1] sdm1[4] sdo1[7]
23441312640 blocks super 1.2 level 5, 64k chunk, algorithm 2 [7/7] [UUUUUUU]
bitmap: 1/15 pages [4KB], 131072KB chunk

md3 : active raid5 sdq1[1] sds1[3] sdp1[0] sdt1[4] sdu1[5] sdv1[7] sdr1[2]
23441312640 blocks super 1.2 level 5, 64k chunk, algorithm 2 [7/7] [UUUUUUU]
bitmap: 2/15 pages [8KB], 131072KB chunk

md1 : active raid5 sdc1[1] sdb1[0] sde1[3] sdd1[2] sdf1[4] sdg1[5] sdh1[7]
23441312640 blocks super 1.2 level 5, 64k chunk, algorithm 2 [7/7] [UUUUUUU]
bitmap: 1/15 pages [4KB], 131072KB chunk

unused devices: <none>
В случае объединения дисков в режиме LINEAR можно наблюдать такую же картину, что и в случае RAID-0:
$ cat /proc/mdstat
Personalities : [linear]
md0 : active linear sdb[0] sde[3] sdd[2] sdc[1]
15628074304 blocks super 1.2 0k rounding

unused devices: <none>
По идее, хорошо бы контролировать деградацию массивов RAID-0 и LINEAR, но описанный выше способ контроля для них не применим.

Поиски способов контроля вывели на файловую систему /sys. На русском языке лучшим материалом на интересующую нас тему является статья Виктора Вислобокова: Недокументированные фишки программного RAID в Linux.

В итоге сформировался новый вариант строчки для файла конфигурации Zabbix-агента /etc/zabbix/zabbix_agentd.conf:
UserParameter=raid,fgrep -L in_sync /sys/block/md*/md/dev-*/state | wc -l
Этот вариант, правда, тоже может таить в себе неожиданности. У меня есть подозрения, что если в системе заготовлен запасной диск, который включён в один из RAID-массивов в таковом качестве, то в его файле состояния будет строчка spare. Если это действительно так, то это состояние нормальное и не должно приводить к срабатыванию триггера. Однако, системы с запасным диском мне не попадались и проверить свои подозрения мне было негде, поэтому я решил оставить всё как есть - все состояния отличные от in_sync будут считаться аварийными. Если мне попадётся в будущем такая система, то можно будет переделать контроль соответствующим образом, чтобы состояние spare не считалось аварийным.

После внесения изменений в конфигурацию Zabbix-агента, не забудьте его перезапустить:
# /etc/init.d/zabbix-agent restart
Я подготовил два шаблона для контроля параметров исправности RAID-массивов:
В шаблоне есть всего один элемент данных, контролирующий количество неисправных элементов RAID-массивов:

И всего один триггер, который срабатывает при наличии хотя бы одного неисправного элемента хотя бы одного RAID-массива:

воскресенье, 23 апреля 2017 г.

Контроль длины очереди отложенных писем Postfix через Zabbix

В прошлом я писал статьи о настройке Postfix для пересылки сообщений для администратора через полноценный почтовый сервер:
Когда таких серверов становится много, а некоторые из них рассылают большое количество писем, становится трудно своевременно обнаруживать проблемы с отправкой писем. Помочь в таком случае может система мониторинга. При проблемах с отправкой писем почтовый сервер откладывает проблемные письма в отдельную очередь, чтобы через некоторое время попробовать отправить эти письма снова. В Postfix эта очередь отложенных писем называется deferred. Для контроля количества писем в этой очереди нам понадобится настроенный Zabbix-агент и установленный пакет sudo. Настройку Zabbix-агента и установку sudo не описываю в виду их тривиальности.

При помощи команды visudo разрешим пользователям из группы zabbix выполнять от имени пользователя root команду поиска файлов в очереди Postfix:
%zabbix    ALL=(ALL) NOPASSWD:/usr/bin/find /var/spool/postfix/deferred -type f
В файл конфигурации Zabbix-агента /etc/zabbix/zabbix_agentd.conf (или /usr/local/etc/zabbix24/zabbix_agentd.conf для случая FreeBSD с Zabbix-агентом версии 2.4) пропишем пользовательский параметр, который будет выполнять команду, подсчитывающую количество файлов, найденных в очереди отложенных писем Postfix:
UserParameter=postfix.deferred.length,sudo /usr/bin/find /var/spool/postfix/deferred -type f | wc -l
После внесения изменений в конфигурацию Zabbix-агента, не забудьте его перезапустить:
# /etc/init.d/zabbix-agent restart
В шаблоне есть:
  • один элемент данных с ключом postfix.deferred.length, с помощью которого раз в 5 минут контролируется количество писем в очереди отложенных,
  • один макрос {$POSTFIX_DEFERRED_LIMIT} со значением 200, который задаёт порог срабатывания триггера,
  • один триггер "Проблемы с отправкой почты", который срабатывает, если в очереди скопилось больше писем, чем указано в макросе.
Вот как выглядят соответствующие вкладки шаблона:



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

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

воскресенье, 16 апреля 2017 г.

Установка Debian с флешки по SSH

Когда возникает задача настроить сервер для другого города, часто задача решается одним из способов:
  1. Сервер отправляется в филиал полностью преднастроенным, так что местным системным администраторам остаётся только установить его в стойку и подключить к сети,
  2. Один из системных администраторов из головного офиса компании отправляется в командировку в филиал, где и настраивает сервер вместе с местными системными администраторами,
  3. Местные системные администраторы сами устанавливают на имеющееся оборудование операционную систему и настраивают на сервере сеть, после чего настройку сервера продолжают системные администраторы из головного офиса.
Последний способ позволяет обойтись без расходов на транспорт - не нужно платить за перевозку преднастроенного сервера, не нужно оплачивать командировочные расходы. Однако и у этого способа имеются свои недостатки - иногда на этапе установки операционной системы бывает нужно выполнить сложную разметку дисков или подгрузить дополнительные драйверы. В подобных случаях лучшим решением может быть использование устройства IP-KVM, если оно есть в филиале. Если же такого устройства в филиале нет, то сгодиться могут разнообразные суррогаты. Один из таких суррогатов и будет рассмотрен в этой статье. Мы подготовим образ флэш-карты с инсталлятором операционной системы Debian, консоль которого после загрузки будет доступна по SSH.

Чтобы подготовить загрузочный образ, необходима уже установленная система Debian. Установим пакет debian-installer, необходимые для его сборки зависимости и пакет fakeroot:
# apt-get source debian-installer
# apt-get build-dep debian-installer
# apt-get install fakeroot
В текущем каталоге будет создан каталог с исходными текстами пакета debian-installer. Перейдём в этот каталог:
# cd debian-installer-20130613+deb7u3/
Откроем в редакторе файл build/pkg-lists/base и добавим в него одну строчку:
#include "network-console"
Эта строчка добавит в инсталлятор дополнительные пакеты, которые сделают возможным доступ к загруженному инсталлятору по SSH.

Создадим файл preseed.cfg и пропишем в него ответы на первые вопросы инсталлятора:
# Выбираем локаль и раскладку клавиатуры
d-i localechooser/shortlist select RU
d-i keyboard-configuration/xkb-keymap select ru
# Задаём настройки сетевой карты
d-i netcfg/enable boolean true
d-i netcfg/choose_interface select eth0
d-i netcfg/disable_autoconfig boolean true
d-i netcfg/get_ipaddress string 192.168.1.16
d-i netcfg/get_netmask string 255.255.255.0
d-i netcfg/get_gateway string 192.168.1.1
d-i netcfg/get_nameservers string 192.168.1.2 192.168.1.3
d-i netcfg/confirm_static boolean true
# Задаём имя сервера и домен
d-i netcfg/get_hostname string server
d-i netcfg/get_domain string core.ufanet.ru
# Включаем доступ к инсталлятору по SSH с логином installer и паролем installer-password
d-i anna/choose_modules string network-console
d-i preseed/early_command string anna-install network-console
d-i network-console/password password installer-password
d-i network-console/password-again password installer-password
# Подключаем сетевой репозиторий для скачивания недостающих пакетов
d-i mirror/country string manual
d-i mirror/http/hostname string mirror.ufanet.ru
d-i mirror/http/directory string /debian
d-i mirror/http/proxy string
d-i mirror/suite string wheezy
d-i mirror/udeb/suite string wheezy
В этом файле можно сразу указать сетевые настройки будущего сервера, согласовав их с системными администраторами филилала. А можно договориться использовать одни и те же сетевые настройки только на период настройки новых серверов, после чего на готовом сервере менять настройки на постоянные.

Теперь отредактируем build/config/local и добавим в него полное имя файла preseed.cfg и кодовое имя релиза инсталлятора:
PRESEED=/root/preseed.cfg
USE_UDEBS_FROM=wheezy
Осталось только собрать образ загрузочного диска с инсталлятором. Для этого нужно перейти в каталог build и выполнить команду сборки образа:
# cd build
# fakeroot make rebuild_monolithic
Эта команда соберёт образ "small bootable CD image for network install" - "маленький загрузочный образ компакт-диска для сетевой установки". Такой образ содержит полный комплект пакетов самого инсталлятора, но устанавливаемые пакеты будет скачивать по сети.

Собранный образ можно найти в файле dest/netboot/mini.iso Остаётся только отправить этот образ системным администраторам филиала, например, по электронной почте. Дальше системные администраторы филиала должны будут записать этот образ на свободную флэшку и загрузить с неё будущий сервер. Дальнейший процесс разметки дисков, настройки учётных записей, настройки системных часов, часового пояса можно производить через SSH из головного офиса, зайдя по SSH с логином installer и указав пароль из файла preseed.cfg (в примере выше это пароль installer-password).

Полный список вариантов образов можно узнать, выполнив команду fakeroot make без указания конкретной цели сборки. Среди других вариантов для наших целей полезными могут оказаться:
  • rebuild_netboot - "tiny CD image that boots the netboot installer" - "крошечный образ компакт-диска, который загрузит установщик с сетевой загрузкой". Образ получится самым маленьким, т.к. недостающие пакеты инсталлятора будут загружаться по сети. Собранный образ можно найти в файле dest/monolithic/mini.iso,
  • rebuild_hd-media - "1 gb image (compressed) for USB memory stick" - "сжатый образ размером в 1 гигабайт для флэш-карт". Этот образ содержит в себе полный комплект пакетов инсталлятора и самые популярные устанавливаемые пакеты операционной системы. Собранный образ можно найти в файле dest/hd-media/boot.img.gz
При создании файла preseed.cfg можно ориентироваться на официальный пример файла wheezy/example-preseed.txt или брать значения опций из уже установленной где-либо системы. Для этого нужно установить в этой системе пакет debconf-utils:
# apt-get install debconf-utils
Вывести на экран значения настроек можно при помощи такой команды:
# debconf-get-selections --install
Вместо указания настроек mirror в файле preseed.cfg можно создать файл со списком репозиториев - build/sources.list.udeb.local. Например, вот такой:
deb http://mirror.ufanet.ru/debian wheezy main contrib non-free
deb http://mirror.ufanet.ru/debian wheezy-updates main contrib non-free
deb http://mirror.ufanet.ru/debian wheezy-proposed-updates main contrib non-free
deb http://mirror.ufanet.ru/debian-security wheezy/updates main contrib non-free
Использованные материалы:

воскресенье, 9 апреля 2017 г.

Решение проблемы с паразитным трафиком TCP ACK

Столкнулся с необычной проблемой. Имеется Zabbix-сервер, работающий под управлением FreeBSD, и Zabbix-прокси, работающий под управлением Linux. Между ними находится NAT-шлюз, работающий под управлением FreeBSD. В такой конфигурации Zabbix-сервер и Zabbix-прокси периодически начинают забрасывать друг друга огромным количеством пустых пакетов с флагом ACK:
09:59:13.868487 IP x.y.z.4.60272 > x.y.z.8.10054: Flags [.], ack 1, win 457, options [nop,nop,TS val 200464 ecr 3255861608], length 0
09:59:13.868496 IP x.y.z.8.10054 > x.y.z.4.60272: Flags [.], ack 4294967295, win 65535, length 0
09:59:13.868498 IP x.y.z.4.53217 > x.y.z.8.10054: Flags [.], ack 1, win 457, options [nop,nop,TS val 200464 ecr 738884814], length 0
09:59:13.868504 IP x.y.z.8.10054 > x.y.z.4.53217: Flags [.], ack 4294967295, win 65535, length 0
09:59:13.868990 IP x.y.z.4.60272 > x.y.z.8.10054: Flags [.], ack 1, win 457, options [nop,nop,TS val 200464 ecr 3255861608], length 0
09:59:13.868997 IP x.y.z.8.10054 > x.y.z.4.60272: Flags [.], ack 4294967295, win 65535, length 0
09:59:13.868999 IP x.y.z.4.53217 > x.y.z.8.10054: Flags [.], ack 1, win 457, options [nop,nop,TS val 200464 ecr 738884814], length 0
09:59:13.869005 IP x.y.z.8.10054 > x.y.z.4.53217: Flags [.], ack 4294967295, win 65535, length 0
09:59:13.869364 IP x.y.z.4.60272 > x.y.z.8.10054: Flags [.], ack 1, win 457, options [nop,nop,TS val 200464 ecr 3255861608], length 0
09:59:13.869372 IP x.y.z.8.10054 > x.y.z.4.60272: Flags [.], ack 4294967295, win 65535, length 0
09:59:13.869374 IP x.y.z.4.53217 > x.y.z.8.10054: Flags [.], ack 1, win 457, options [nop,nop,TS val 200464 ecr 738884814], length 0
09:59:13.869380 IP x.y.z.8.10054 > x.y.z.4.53217: Flags [.], ack 4294967295, win 65535, length 0
09:59:13.869863 IP x.y.z.4.60272 > x.y.z.8.10054: Flags [.], ack 1, win 457, options [nop,nop,TS val 200464 ecr 3255861608], length 0
09:59:13.869870 IP x.y.z.8.10054 > x.y.z.4.60272: Flags [.], ack 4294967295, win 65535, length 0
09:59:13.869872 IP x.y.z.4.53217 > x.y.z.8.10054: Flags [.], ack 1, win 457, options [nop,nop,TS val 200464 ecr 738884814], length 0
09:59:13.869878 IP x.y.z.8.10054 > x.y.z.4.53217: Flags [.], ack 4294967295, win 65535, length 0
09:59:13.870238 IP x.y.z.4.60272 > x.y.z.8.10054: Flags [.], ack 1, win 457, options [nop,nop,TS val 200464 ecr 3255861608], length 0
09:59:13.870245 IP x.y.z.8.10054 > x.y.z.4.60272: Flags [.], ack 4294967295, win 65535, length 0
09:59:13.870247 IP x.y.z.4.53217 > x.y.z.8.10054: Flags [.], ack 1, win 457, options [nop,nop,TS val 200464 ecr 738884814], length 0
09:59:13.870253 IP x.y.z.8.10054 > x.y.z.4.53217: Flags [.], ack 4294967295, win 65535, length 0
Тут видно два подключения с портов 60272 и 53217 на порт 10054. Интервалы времени между ответными пакетами составляют единицы микросекунд. В результате образуется взаимный шторм в десятки тысяч пакетов в секунду. Самое интересное, что остановка Zabbix-прокси не приводит к пропаданию этого трафика - пакеты продолжают сыпаться.

Имеется аналогичная конфигурация, в которой Zabbix-сервер работает под управлением Linux. То есть два Linux'а разделены NAT-шлюзом под управлением FreeBSD. В этой конфигурации подобной проблемы не наблюдается.

Как я выяснил, Zabbix тут вообще не при чём. Я нашёл описание заплатки для Linux, в которой описана эта проблема: Merge branch 'tcp_ack_loops'. Проблема проявляется, когда промежуточный шлюз вносит изменения в параметры TCP-подключения этих двух узлов - меняет номер последовательности, номер ACK или отметку времени. Один из узлов, получив такой пакет, сообщает противоположной стороне о несовпадении параметров установленного подключения, отправляя ей пакет ACK. Другая сторона получает этот пакет ACK, а параметры в нём тоже не совпадают с параметрами установленного подключения. Обе стороны начинают забрасывать друг друга ACK-пакетами, в которых сообщается, что противная сторона отправила пакет с параметрами, отличающимися от параметров установленного соединения.

В новых версиях ядра Linux должна появиться переменная net.ipv4.tcp_invalid_ratelimit, описание которой можно найти здесь - /proc/sys/net/ipv4/* Variables. Приведу перевод описания этой переменной ядра:
tcp_invalid_ratelimit - ЦЕЛОЕ

Ограничивает максимальную скорость отправки дубликатов подтверждений в ответ на входящие пакеты TCP, которые соответствуют существующему подключению, но по одной из причин считаются неправильными:
  1. номер последовательности за пределами окна,
  2. номер подтверждения за пределами окна, или
  3. ошибка проверки PAWS (Protection Against Wrapped Sequence numbers - защита от завёрнутых номеров последовательности).
Может помочь смягчить простые DoS-атаки "цикл ACK", когда неисправный хост или злоумышленник между ними может переписать поля заголовка TCP таким образом, что это заставит каждую из сторон считать, что другая отправляет неисправные сегменты TCP, что заставит каждую из сторон отправлять непрекращающийся поток дубликатов подтверждений о неисправных сегментах.

Значение 0 отключит ограничение скорости дубликатов подтверждений в ответ на неисправные сегменты; в противном случае значение указывает минимальный интервал между отправкой дубликатов подтверждений в миллисекундах.

Значение по умолчанию: 500 миллисекунд.
Обновлять ядро Linux мне не хотелось, т.к. в конфигурации Linux-FreeBSD-Linux всё работало нормально и без этой заплатки. Я стал искать обходные решения.

На правильное направление меня вывела вот эта статья - FreeBSD Tuning and Optimization. Приведу перевод фрагмента, описывающего возможные проблемы от включения функции Syncookies:
Syncookies обладают как плюсами, так и минусами. Syncookies полезны если вы находитесь под DoS-атакой, поскольку с их помощью можно отличать настоящих клиентов от компьютеров злоумышленников. Но, поскольку опции TCP из начального SYN-пакета не сохраняются в Syncookies, опции TCP не применяются к подключению, препятствуя использованию функций масштабирования окна, отметок времени или точному определению размера MSS. Поскольку при получении ответного ACK устанавливаетcя подключение, злоумышленник может попробовать наводнить машину пакетами ACK, чтобы попытаться создать подключение.

Дополнительно для переполнения получателя настоящих SYN-куки злоумышленник может добавить к пакету данные. Тогда злоумышленник сможет отправлять данные сетевому демону FreeBSD, даже используя поддельный IP-адрес отправителя. Это приведёт к тому, что FreeBSD будет обрабатывать данные, которые не обрабатывались бы, если бы Syncookies были выключены. Несмотря на то, что Syncookies полезны во время DoS-атак, мы собираемся отключить синкуки.
Я попробовал выключить на Zabbix-сервере под управлением FreeBSD использование опции Syncookies:
# sysctl -w net.inet.tcp.syncookies=0
Затем на время заблокировал на время исходящий трафик на Zabbix-прокси, работающем под управлением Linux:
# iptables -A OUTPUT -d x.y.z.8 -p tcp -m tcp --dport 10054 -j DROP
Выждав полминуты, снова его разблокировал:
# iptables -D OUTPUT -d x.y.z.8 -p tcp -m tcp --dport 10054 -j DROP
В результате паразитный трафик пропал.

То есть, как я понял, изменения, вносимые в TCP-пакеты промежуточным шлюзом, осуществляющим трансляцию адресов, могут приводить к тому, что обе стороны будут слать друг другу ACK-пакеты с несовпадающими параметрами. Эти ACK-пакеты сервером FreeBSD будут восприниматься как пакеты, продолжающие процесс установки нового подключения - FreeBSD посчитает, что отправитель ACK-пакета ранее отправлял ей SYN-пакет и уже получил в ответ подтверждение в виде SYN-ACK-пакета. Таким образом FreeBSD создаст новое подключение. В дальнейшем обе стороны будут обмениваться друг с другом сообщениями о получении пакета, не соответствующего тем параметрам подключения, которые обе стороны согласовали друг с другом ранее. Не претендую на полное понимание ситуации и точность объяснения, но отключение Syncookies на стороне Zabbix-сервера под управлением FreeBSD помогло избавиться от проблемы.

Чтобы Syncookies отключались после перезагрузки системы, нужно внести соответствующие настройки в файл /etc/sysctl.conf:
net.inet.tcp.syncookies=0

воскресенье, 2 апреля 2017 г.

Решение проблемы с остановкой загрузки из-за RAID-контроллера Intel RS2WC040

Столкнулся с проблемой - один из серверов не загружался после аварийного отключения питания. К сожалению, снимки экрана в процессе загрузки не сохранились, поэтому я сейчас не могу сказать, что натолкнуло меня на мысль о том, что причина заключается в RAID-контроллере. Решил сравнить при помощи diff настройки контроллеров на проблемном сервере и на сервере, где такой проблемы не наблюдается. Для этого вывел настройки RAID-контроллеров при помощи такой команды:
# megacli -AdpAllInfo -aALL
Глаз зацепился только на одном различии, которое можно причислить собственно к настройкам контроллеров, а не к их свойствам:
< BIOS Error Handling            : Pause on Errors
---
> BIOS Error Handling            : Stop On Errors
Поискал в интернете и нашёл статью How to disable LSI MegaRAID SAS controller’s suspend boot on error “feature”

Посмотреть текущее значение этой настройки можно следующей командой:
# MegaCli -AdpBIOS -Dsply -aALL
На проблемном сервере эта команда выдавала следующее:
BIOS on Adapter 0 is Enabled.
    BIOS will Bypass error.
Auto select Boot on Adapter 0 is Disabled.

Exit Code: 0x00
На сервере без проблем эта команда выдавала следующее:
BIOS on Adapter 0 is Enabled.
    BIOS will Stop on error.
Auto select Boot on Adapter 0 is Disabled.

Exit Code: 0x00
Выставить значение Stop on error можно следующей командой:
# MegaCli -AdpBIOS -SOE -aALL
При последующих перезагрузках сервера больше такой проблемы не наблюдалось.

воскресенье, 26 марта 2017 г.

Таймаут DNS в OpenNTPd

Как-то на работе настраивал сервер для отправки в филиал. Всё настроил, начал уже отключать от сервера провода, вдруг решил ещё раз проверить какой-то файл конфигурации. Включил сервер и обнаружил, что загрузка замерла.

Стал разбираться, что же не так. Как оказалось, загрузка остановилась на этапе запуска OpenNTPd. Заметил, что сервер не был подключен к сети. Воткнул сеть - сервер стал загружаться дальше. В интернете нашёл описание этой ошибки в OpenNTPd: net-misc/openntpd - failed dns results in extended startup delay when -s option in use

Проблема заключается в том, что у OpenNTPd предусмотрен таймаут для NTP-серверов, но не предусмотрен таймаут для DNS-серверов, поэтому демон продолжает в бесконечном цикле выполнять DNS-запросы, пытаясь узнать имена NTP-серверов.

Проблему можно решить одним из способов:
  • Убрать из настроек опцию -s,
  • Прописать в конфигурацию IP-адреса NTP-серверов, а не доменные имена,
  • Пропатчить пакет патчем из этого отчёта об ошибке.
Я решил тогда пропатчить пакет. Потом я много раз пользовался этим пакетом, но описать его сборку всё забывал. Вот сейчас решил всё-таки задокументировать эту процедуру, хотя в новых версиях Debian она станет больше не нужной, т.к. в новых версиях OpenNTPd ошибка уже исправлена.

Для начала отредактируем файл /etc/apt/sources.list и добавим строчки с репозиториями deb-src с исходными текстами:
deb http://mirror.ufanet.ru/debian/ wheezy main contrib non-free
deb http://mirror.ufanet.ru/debian/ wheezy-updates main contrib non-free
deb http://mirror.ufanet.ru/debian/ wheezy-proposed-updates main contrib non-free
deb http://mirror.ufanet.ru/debian-security wheezy/updates main contrib non-free

deb-src http://mirror.ufanet.ru/debian/ wheezy main contrib non-free
deb-src http://mirror.ufanet.ru/debian/ wheezy-updates main contrib non-free
deb-src http://mirror.ufanet.ru/debian/ wheezy-proposed-updates main contrib non-free
deb-src http://mirror.ufanet.ru/debian-security wheezy/updates main contrib non-free
Установим инструменты, необходимые для сборки пакета:
# apt-get install dpkg-dev devscripts fakeroot quilt
Установим пакет с исходными текстами openntpd:
# apt-get source openntpd
Скачаем подготовленный мной патч:
# wget http://stupin.su/files/openntpd-20080406p-dns-timeout.patch
Перейдём в каталог с исходными текстами пакета:
# cd openntpd-20080406p
Наложим скачанный патч:
# patch -Np0 < ../openntpd-20080406p-dns-timeout.patch
Установим пакеты, необходимые для сборки пакета openntpd:
# apt-get build-dep openntpd
Оформим изменения, сделанные в исходных текстах, в виде патча:
# dpkg-source --commit
В ответ на запрос имени заплатки введём dns-timeout.

Содержимое заголовка заплатки:
Description: DNS timeout added
 Added patch from https://bugs.gentoo.org/show_bug.cgi?id=493358
 .
 openntpd (20080406p-4) unstable; urgency=low
Author: Vladimir Stupin <vladimir@stupin.su>
Last-Update: <2017-02-09>

--- openntpd-20080406p.orig/ntpd.c
+++ openntpd-20080406p/ntpd.c
Теперь опишем сделанные изменения в журнале изменений:
# dch -i
Свежая запись в журнале будет выглядеть следующим образом:
openntpd (20080406p-4.1) UNRELEASED; urgency=low

  * DNS timeout added

 -- Vladimir Stupin <vladimir@stupin.su>  Thu, 09 Mar 2017 22:11:37 +0500
Соберём новый пакет с исходными текстами и двоичный пакет:
# dpkg-buildpackage -us -uc -rfakeroot
Теперь можно перейти на уровень выше и установить собранный пакет:
# cd ..
# dpkg -i openntpd_20080406p-4.1_amd64.deb
С новым пакетом пауза в процессе загрузки составляет 1 минуту 40 секунд, что вполне приемлемо, т.к. сервер в конце концов всё-таки загружается, а на фоне всего процесса загрузки эта дополнительная пауза почти не заметна.

воскресенье, 19 марта 2017 г.

Смена темы письма в Postfix

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

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

Чтобы решить эту проблему и облегчить себе работу, я решил настроить все свои серверы так, чтобы Postfix добавлял в тему отправляемого письма имя сервера.

Сделать это просто. Для начала нужно установить пакет postfix-pcre:
# apt-get install postfix-pcre
Далее, добавим в файл /etc/postfix/main.cf одну строчку:
header_checks = pcre:/etc/postfix/rewrite_subject
Теперь нужно создать файл /etc/postfix/rewrite_subject и поместить в него правило, которое будет добавлять в тему письма дополнительный текст с именем сервера. Например, вот так:
/^Subject: (.*)$/ REPLACE Subject: $1 (from server.domain.tld)
Текст "/^Subject: (.*)$/" является регулярным выражением в стиле Perl. Это регулярное выражение будет совпадать со строкой заголовка, начинающейся с текста "Subject: ". Текст "(.*)" совпадает с любой темой письма и будет запомнен в переменной $1.

Действие "REPLACE" говорит о том, что нужно произвести замену текста.

Строка "Subject: $1 (from server.domain.tld)" содержит в текст, который заменит совпавшую строчку. При этом вместо переменной $1 будет подставлено её значение. Если имя переменной не отделено от остального текста пробельными символами, тогда её имя следует записывать в виде ${1}

Итак, осталось перезапустить почтовый сервер:
# /etc/init.d/postfix restart
Проверить, добавляется ли текст к теме письма можно следующим образом:
# mail -s test box@mailserver.tld
test
.
При этом в почтовом ящике должно появиться письмо с темой "test (from server.domain.tld)".

воскресенье, 12 марта 2017 г.

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

Как известно, Python поставляется с "батарейками" - в комплекте идёт масса различных модулей. Одним из таких модулей является модуль urllib2, позволяющий выполнять веб-запросы. К сожалению, этот модуль не блещет наглядностью, потому что для выполнения запроса зачастую требуется соединить между собой несколько объектов. Это может быть привычным по идеологии для программистов, пишущих на Java, но вот у большинства программистов, использующих скриптовые языки, этот подход напрочь отбивает всё желание пользоваться этим модулем. В результате я наблюдаю, например, что коллеги для выполнения веб-запросов часто пользуются сторонними, более дружелюбными модулями. Трое из них пользовались pycurl, а один - requests. Кстати, девиз модуля requests звучит как "Python HTTP для людей", что как бы намекает на то, что по мнению авторов модуля requests модуль urllib2 сделан для инопланетян. Пожалуй, в этом есть доля истины.

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

1. GET-запрос

Начнём с самого простого - с выполнения GET-запроса. Нужно просто скачать страницу.
import warnings, urllib, urllib2
warnings.filterwarnings('ignore', category=UserWarning, module='urllib2')

def http_get(str_url, dict_params, dict_headers, float_timeout):
    query = urllib.urlencode(dict_params)
    req = urllib2.Request(str_url + '?' + query, headers=dict_headers, timeout=float_timeout)
    
    opener = urllib2.build_opener()
    
    try:
        res = opener.open(req)
    except urllib2.HTTPError as e:
        res = e
    except urllib2.URLError as e:
        return None, None
    except socket.timeout:
        return None, None
    except ssl.SSLError:
        return None, None
  
    return res.code, res.read()
Здесь можно увидеть функцию http_get, которая принимает параметры:
  • str_url - строка с URL страницы, которую нужно скачать,
  • dict_params - словарь с параметрами и их значениями, из которых будет сформирована строка запроса. Эта строка запроса потом будет добавлена к строке URL после знака вопроса. Ключи словаря являются именами параметров, а значения - соответственно значениями,
  • dict_headers - словарь с дополнительными заголовками, которые будут добавлены в GET-запрос. Ключи словаря являются именами заголовков, а значения - их значениями,
  • float_timeout - число с плавающей запятой, задающее таймаут ожидания запроса.
Функция возвращает кортеж из двух значений: первое значение содержит код ошибки от веб-сервера, а второе значение содержит тело ответа. Если в строке URL содержится ошибка, не отвечает DNS-сервер, DNS-сервер сообщает об ошибке поиска имени или если соединиться с веб-сервером не удалось, будет возвращён кортеж с двумя значениями None. Если вам нужно различать ошибки разного рода, переделайте обработку ошибок под свои нужды.

Если вам нужно узнать заголовки из ответа, то имейте в виду, что объект res принадлежит классу httplib.HTTPResponse. У объектов этого класса есть методы getheader и getheaders. Метод getheader вернёт значение заголовка с указанным именем или значение по умолчанию. Метод getheaders вернёт список кортежей с именами заголовков и их значениями. Например, словарь из заголовков и их значений (исключая заголовки с несколькими значениями) можно было бы получить следующим образом:
headers = dict(res.getheaders())

2. POST-запрос enctype=application/x-www-form-urlencoded

Можно сказать, что это "обычный" POST-запрос. В таких POST-запросах применяется кодирование параметров, аналогичное тому, которое используется для кодирования параметров в GET-запросах. В случае с GET-запросами строка с параметрами добавляется после вопросительного знака к строке URL запрашиваемого ресурса. В случае с POST-запросом эта строка с параметрами помещается в тело запроса. В запросах такого рода нельзя передать на сервер файл.
import warnings, urllib, urllib2
warnings.filterwarnings('ignore', category=UserWarning, module='urllib2')

def http_post(str_url, dict_params, dict_headers, float_timeout):
    query = urllib.urlencode(dict_params)
    dict_headers['Content-type'] = 'application/x-www-form-urlencoded'
    req = urllib2.Request(str_url, data=query, headers=dict_headers, timeout=float_timeout)
    
    opener = urllib2.build_opener()
    
    try:
        res = opener.open(req)
    except urllib2.HTTPError as e:
        res = e
    except urllib2.URLError as e:
        return None, None
    except socket.timeout:
        return None, None
    except ssl.SSLError:
        return None, None
  
    return res.code, res.read()
Функция http_post по входным и выходным параметрам полностью аналогична функции http_get, только выполняет POST-запрос.

3. POST-запрос enctype=multipart/form-data

Если в запросе нужно отправить много данных, то они могут оказаться слишком большими, чтобы уместиться в одной строке. В таких случаях, например если нужно приложить файл, в веб-приложениях используются формы с типом "multipart/form-data". Для отправки подобных запросов переделаем предыдущую функцию, воспользовавшись модулем poster.
import warnings, urllib2
warnings.filterwarnings('ignore', category=UserWarning, module='urllib2')
from poster.encode import multipart_encode

def http_post_multipart(str_url, dict_params, dict_headers, float_timeout):
    body, headers = multipart_encode(dict_params)
    dict_headers.update(headers)
    req = urllib2.Request(str_url, data=body, headers=dict_headers, timeout=float_timeout)
    
    opener = urllib2.build_opener()
    
    try:
        res = opener.open(req)
    except urllib2.HTTPError as e:
        res = e
    except urllib2.URLError as e:
        return None, None
    except socket.timeout:
        return None, None
    except ssl.SSLError:
        return None, None
  
    return res.code, res.read()
Функция http_post_multipart по входным и выходным параметрам полностью аналогична функциям http_get и http_post, только выполняет POST-запрос, закодировав параметры способом, пригодным для передачи данных большого объёма, в том числе - файлов.

4. GET-запрос с аутентификацией

Продемонстрирую аутентификацию на примере с GET-запросом:
import warnings, urllib, urllib2
warnings.filterwarnings('ignore', category=UserWarning, module='urllib2')

def http_get_auth(str_url, dict_params, dict_headers, float_timeout, str_user, str_password):
    query = urllib.urlencode(dict_params)
    req = urllib2.Request(str_url + '?' + query, headers=dict_headers, timeout=float_timeout)
    
    passman = urllib2.HTTPPasswordMgrWithDefaultRealm()
    passman.add_password(None, str_url, str_user, str_password)
    authhandler = urllib2.HTTPBasicAuthHandler(passman)
    
    opener = urllib2.build_opener(authhandler)
    
    try:
        res = opener.open(req)
    except urllib2.HTTPError as e:
        res = e
    except urllib2.URLError as e:
        return None, None
    except socket.timeout:
        return None, None
    except ssl.SSLError:
        return None, None
  
    return res.code, res.read()
Как видно, функция http_get_auth по выходным параметрам совпадает со всеми предыдущими функциями, но среди входных параметров появилось два новых:
  • str_user - строка, содержащая имя пользователя,
  • str_password - строка, содержащая пароль пользователя.
Внутри функции появились три новые строчки, выделенные жирным шрифтом. Эти строчки создают менеджер паролей и дополнительный обработчик ответа от веб-сервера. В четвёртой выделенной строчке создаётся объект, который будет выполнять запрос с использованием этого дополнительного обработчика. Задача обработчика простая - если при запросе без аутентификации будет возвращён код ошибки 401, то в запрос будет добавлен дополнительный заголовок, содержащий имя пользователя и его пароль, после чего запрос будет повторён.

Менеджер паролей может предоставлять обработчику разные пароли, в зависимости от области доступа (часто называемой realm'ом), которую сообщит веб-сервер или в зависимости от URL запрашиваемого ресурса.

5. GET-запрос с безусловной аутентификацией

Обработчик HTTPBasicAuthHandler устроен таким образом, что сначала всегда делает запрос без передачи логина и пароля. И только если получен ответ с кодом 401, уже пытается выполнить запрос с аутентификацией.

При попытке выполнить запрос к API, реализованному на основе библиотеки swagger, возникают некоторые трудности с аутентификацией. При обращении к API без аутентификации, API возвращает HTML-справку по использованию API с кодом ответа 403, поэтому дополнительных попыток получить страницу с аутентификацией не предпринимается.

Чтобы исправить эту ситуацию, я воспользовался ответом, подсмотренным здесь: does urllib2 support preemptive authentication authentication?
import warnings, urllib, urllib2, base64
warnings.filterwarnings('ignore', category=UserWarning, module='urllib2')

class PreemptiveBasicAuthHandler(urllib2.HTTPBasicAuthHandler):
    '''Preemptive basic auth.

    Instead of waiting for a 403 to then retry with the credentials,
    send the credentials if the url is handled by the password manager.
    Note: please use realm=None when calling add_password.'''
    def http_request(self, req):
        url = req.get_full_url()
        realm = None
        # this is very similar to the code from retry_http_basic_auth()
        # but returns a request object.
        user, pw = self.passwd.find_user_password(realm, url)
        if pw:
            raw = "%s:%s" % (user, pw)
            auth = 'Basic %s' % base64.b64encode(raw).strip()
            req.add_unredirected_header(self.auth_header, auth)
        return req

    https_request = http_request

def http_get_preemptive_auth(str_url, dict_params, dict_headers, float_timeout, str_user, str_password):
    query = urllib.urlencode(dict_params)
    req = urllib2.Request(str_url + '?' + query, headers=dict_headers, timeout=float_timeout)
    
    passman = urllib2.HTTPPasswordMgrWithDefaultRealm()
    passman.add_password(None, str_url, str_user, str_password)
    authhandler = PreemptiveBasicAuthHandler(passman)
    
    opener = urllib2.build_opener(authhandler)
    
    try:
        res = opener.open(req)
    except urllib2.HTTPError as e:
        res = e
    except urllib2.URLError as e:
        return None, None
    except socket.timeout:
        return None, None
    except ssl.SSLError:
        return None, None
  
    return res.code, res.read()
Функция http_get_preemptive_auth по входным и выходным параметрам полностью аналогична функции http_get_auth, но в ней используется другой дополнительный обработчик - PreemptiveBasicAuthHandler, который отличается от обработчика HTTPBasicAuthHandler тем, что не выполняет запрос без аутентификации, ожидая получить ошибку 401, а сразу отправляет логин и пароль, соответствующие запрашиваемому URL.

6. GET-запрос через прокси

Смотрим пример:
import warnings, urllib, urllib2
warnings.filterwarnings('ignore', category=UserWarning, module='urllib2')

def http_get_proxy(str_url, dict_params, dict_headers, float_timeout, str_proxy):
    query = urllib.urlencode(dict_params)
    req = urllib2.Request(url + '?' + query, headers=dict_headers, timeout=float_timeout)
    
    proxyhandler = urllib2.ProxyHandler(str_proxy)

    opener = urllib2.build_opener(proxyhandler)
    
    try:
        res = opener.open(req)
    except urllib2.HTTPError as e:
        res = e
    except urllib2.URLError as e:
        return None, None
    except socket.timeout:
        return None, None
    except ssl.SSLError:
        return None, None
  
    return res.code, res.read()
Функция http_get_proxy по выходным параметрам полностью соответствует функции http_get, а среди входных параметров имеется один дополнительный:
  • str_proxy - строка с адресом веб-прокси. Имеет вид http://proxy.domain.tld:3128
В этом примере используется дополнительный обработчик запросов ProxyHandler, который позволяет отправлять запросы через веб-прокси. На самом деле, этому обработчику можно передать не строку с одним веб-прокси, а передать словарь, в котором для разных протоколов будут указаны разные прокси:
{
 'http': 'http://proxy-http.domain.tld:3128',
 'https': 'http://proxy-https.domain.tld:3128',
 'ftp': 'http://proxy-ftp.domain.tld:3128'
}

7. Использование нескольких обработчиков запросов одновременно

Когда в запросе нужно использовать несколько обработчиков одновременно, то можно растеряться, т.к. в примерах выше каждый раз используется только один обработчик для аутентификации или для прокси. Но использовать несколько обработчиков совсем не трудно. Это можно сделать, указав их через запятую, вот так:
opener = urllib2.build_opener(authhandler, proxyhandler)
Но и в этом случае можно растеряться, если список обработчиков нужно формировать динамически, так что каждый конкретный обработчик может отсутствовать. Тут тоже всё просто. Можно добавлять обработчики в массив, а затем использовать этот массив как список аргументов:
# В начале список обработчиков пуст
handlers = []

# Если нужна аутентификация, добавляем обработчик в список
if ...:
    ...
    authhandler = ...
    handlers.append(authhandler)

# Если запрос нужно выполнить через прокси, добавляем обработчик в список
if ...:
    ...
    proxyhandler = ...
    handlers.append(proxyhandler)

# Выполняем запрос, используя все обработчики из списка
opener = urllib2.build_opener(*handlers)
Если нужно пройти аутентификацию и на прокси и на веб-ресурсе, то для аутентификации на прокси можно использовать обработчик ProxyBasicAuthHandler, так что всего будет использоваться аж сразу три обработчика запросов.

Этих примеров достаточно для того, чтобы научиться пользоваться модулем urllib2 и понимать, в каком направлении надо копать, чтобы сделать что-то такое, что здесь не описано. Если у вас есть чем дополнить эту статью, прошу написать мне об этом в комментариях.

воскресенье, 5 марта 2017 г.

HKPK - расширение для фиксации публичного ключа HTTP в Apache, nginx и Lighttpd

Перевод: HTTP Public Key Pinning Extension HPKP for Apache, NGINX and Lighttpd
Автор: Реми ван Элст (Remy van Elst)

Содержание
  1. HPKP - расширение для фиксации публичного ключа HTTP
  2. Отпечаток SPKI - теория
  3. Что фиксировать
  4. Отпечаток SPKI
  5. Неполадки
  6. Настройка веб-сервера
    1. Apache
    2. Lighttpd
    3. nginx
  7. Отчёты
  8. Не фиксировать, только отчитываться
Фиксация публичного ключа означает, что цепочка сертификатов должна включать публичный ключ из разрешённого списка. Это даёт гарантии того, что только удостоверяющий центр из разрешённого списка может подписывать сертификаты для *.example.com, но не какой-то другой удостоверяющий центр, сертификат которого имеется в хранилище браузера. В этой статье объясняется теория и приводятся примеры настройки Apache, Lighttpd и nginx.

HPKP - Расширение для фиксации публичного ключа HTTP

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

Если банк воспользуется расширением для фиксации публичного ключа - HPKP и зафиксирует первый промежуточный сертификат (от удостоверяющего центра компании A), браузеры не будут принимать сертификаты от удостоверяющих центров компаний B и C, даже если цепочка доверия верна. HPKP также позволяет браузеру отправлять в банк отчёты о попытках подмены, чтобы банк знал о проводящейся атаке.

Расширение для фиксации публичного ключа HTTP - Public Key Pinning Extension for HTTP (HPKP) - это стандарт пользовательских агентов HTTP, которые были разработаны начиная с 2011 года. Начало стандарту было положено в Google, когда фиксация была реализована в Chrome. Однако, впоследствии разработчики поняли, что ручное поддержание списка фиксированных сайтов не масштабируемо.

Вот краткий обзор возможностей HPKP:
  • HPKP задаётся на уровне HTTP с помощью заголовка Public-Key-Pins в ответах.
  • Политика срока хранения задаётся при помощи параметра max-age, который указывает длительность в секундах.
  • Заголовок Public-Key-Pins может использоваться только в успешном безопасном зашифрованном подключении.
  • При наличии нескольких заголовков обрабатывается только первый.
  • Фиксация может распространяться на поддомены при использовании параметра includeSubDomains.
  • При получении нового заголовка Public-Key-Pins, он заменяет ранее сохранённую фиксацию и метаданные.
  • Фиксация состоит из алгоритма хэширования и отпечатка Subject Public Key Info - информации публичного ключа субъекта.
В этой статье сначала рассматриваются принципы работы HPKP, а далее можно найти часть, где рассказывается, как получить необходимые отпечатки и настроить веб-сервер.

Отпечаток SPKI - теория

Как объясняет в своей статье Адам Лэнгли (Adam Langley), хэшируется публичный ключ, а не сертификат:
В общем, хэширование сертификатов - это очевидное решение, но не правильное. Проблема в том, что сертификаты удостоверяющего центра часто перевыпускаются: может быть несколько сертификатов с одним и тем же публичным ключом, именем в Subject и т.д., но с разными расширениями или сроками годности. Браузеры строят цепочки сертификатов из пула сертификатов снизу вверх, и альтернативная версия сертификата может заместить ожидаемую.

Например, у StartSSL имеется два корневых сертификата: один подписан SHA1, а другой - SHA256. Если нужно зафиксировать StartSSL как удостоверяющий центр, то какой из сертификатов следует использовать? Нужно использовать оба, но как узнать что есть второй корень, если об этом не сообщается?

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

Браузеры считают, что сертификат веб-сервера неизменен: он всегда является началом цепочки. Сертификат сервера содержит подпись родительского сертификата, которая должна быть верной. Подразумевается, что публичный ключ родителя неизменен для дочернего сертификата. И так далее, вся цепочка публичных ключей оказывается неизменной.

Единственный тонкий момент заключается в том, что не стоит фиксировать кросс-сертифицированные корневые сертификаты. Например, корневой сертификат GoDaddy подписан сертификатом Valicert, так что старые клиенты, не знающие корневой сертификат GoDaddy всё-таки доверяют таким сертификатам. Однако, не стоит фиксировать сертификат Valicert, потому что более новые клиенты завершают цепочку сертификатом GoDaddy.

Также хэшируется SubjectPublicKeyInfo, но не двоичная последовательность публичного ключа. SPKI, наряду с самим публичным ключом, включает в себя тип публичного ключа и некоторые параметры. Это важно, потому что простое хэширование публичного ключа оставляет возможность для атаки из-за неправильной интерпретации. Рассмотрим публичный ключ Диффи-Хеллмана: если хэшируется только публичный ключ, а не SPKI полностью, то атакующий может воспользоваться тем же публичным ключом, но заставить клиента интерпретировать его как другую группу Диффи-Хеллмана. Таким же образом можно заставить браузер интерпретировать ключ RSA как ключ DSA и т.п.

Что фиксировать

Что нужно фиксировать? Не стоит фиксировать собственный публичный ключ. Ключ может смениться или оказаться скомпрометированным. Может понадобиться использовать несколько сертификатов, а ключ может смениться из-за слишком частой ротации сертификатов. Ключ может оказаться скомпрометированным, если веб-сервер взломают.

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

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

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

Альтернативный и более безопасный способ решения этой проблемы - создать заблаговременно по меньшей мере три разных публичных ключа (с помощью OpenSSL, обратитесь к странице с Javascript, которая генерирует команду OpenSSL для генерации) и хранить два из этих ключей как резерв в безопасном месте, вне сети и в другом помещении.

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

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

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

Отпечаток SPKI

Для получения отпечатка SPKI из сертификата можно воспользоваться командой OpenSSL, которая указана в черновике RFC:
openssl x509 -noout -in certificate.pem -pubkey | \
openssl asn1parse -noout -inform pem -out public.key;
openssl dgst -sha256 -binary public.key | openssl enc -base64
Результат:
klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=
Файл certificate.pem, подаваемый на вход команды - это первый сертификат в цепочке для этого веб-сайта. На момент написания - сервер удостоверяющего центра для безопасной проверки доменов COMODO RSA (COMODO RSA Domain Validation Secure Server CA), серийный номер - 2B:2E:6E:EA:D9:75:36:6C:14:8A:6E:DB:A3:7C:8C:07.

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

Неполадки

На момент написания этой статьи (январь 2015 года) HPKP поддерживает только один браузер (Chrome), и у него имеется важная проблема, которая заключается в том, что Chrome понимает директивы max-age и includeSubdomains из заголовков HSTS и HPKP как взаимно исключающие. Это означает, что если имеется HSTS и HPKP с разными политиками max-age или includeSubdomains, они будут перетасовываться. Обратитесь к описанию этой неполадки за более подробной информацией: HPKP принудительно использует includeSubDomains даже когда директива не указана. Благодарю Скотта Хелми (Scott Helme) из https://scotthelme.co.uk за исследования и за то, что сообщил о проблеме мне и в проект Chromium.

Настройка веб-сервера

Далее приведены инструкции по настройке трёх наиболее популярных веб-серверов. Поскольку HPKP - это просто заголовок HTTP, большинство веб-серверов позволяют задать его. Заголовок нужно настраивать на веб-сайте HTTPS.

Ниже указан пример фиксации сервера удостоверяющего центра для безопасной проверки доменов COMODO RSA (COMODO RSA Domain Validation Secure Server CA) и запасного удостоверяющего центра 2 Comodo PositiveSSL (Comodo PositiveSSL CA 2), со сроком годности в 30 дней, включая все поддомены.

Apache

Отредактируйте файл конфигурации Apache (например, /etc/apache2/sites-enabled/website.conf или /etc/apache2/httpd.conf) и добавьте следующие строки в секцию VirtualHost:
# Загрузка не обязательного модуля headers:
LoadModule headers_module modules/mod_headers.so

Header set Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains"
Lighttpd

В случае Lighttpd всё очень просто. Добавим в файл конфигурации Lighttpd (например, в /etc/lighttpd/lighttpd.conf) следующие строки:
server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
  setenv.add-response-header = ( "Public-Key-Pins" => "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains")
}
nginx

Настройка nginx даже ещё короче. Добавьте следующую строку в блок server, относящийся к настройке HTTPS:
add_header Public-Key-Pins 'pin-sha256="klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY="; pin-sha256="633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q="; max-age=2592000; includeSubDomains';
Отчёты

Отчёты HPKP позволяют пользовательским агентам отправлять вам отчёты о проблемах.

Если добавить к заголовку дополнительный параметр report-uri="http://example.org/hpkp-report" и настроить по этой ссылке прослушиватель, клиенты будут отправлять отчёты при возникновении проблем. Отчёт отправляет JSON-данные на адрес из report-uri в теле POST-запроса:
{
    "date-time": "2014-12-26T11:52:10Z",
    "hostname": "www.example.org",
    "port": 443,
    "effective-expiration-date": "2014-12-31T12:59:59",
    "include-subdomains": true,
    "served-certificate-chain": [
        "-----BEGINCERTIFICATE-----\nMIIAuyg[...]tqU0CkVDNx\n-----ENDCERTIFICATE-----"
    ],
    "validated-certificate-chain": [
        "-----BEGINCERTIFICATE-----\nEBDCCygAwIBA[...]PX4WecNx\n-----ENDCERTIFICATE-----"
    ],
    "known-pins": [
        "pin-sha256=\"dUezRu9zOECb901Md727xWltNsj0e6qzGk\"",
        "pin-sha256=\"E9CqVKB9+xZ9INDbd+2eRQozqbQ2yXLYc\""
    ]
}
Не фиксировать, только отчитываться

С помощью заголовка Public-Key-Pins-Report-Only можно настроить HPKP в режиме отправки отчётов без принуждения соблюдать фиксацию.

Этот подход позволяет настроить фиксацию так, что сайт не станет недостижимым, если HPKP настроен неправильно. Позже можно включить принудительное использование фиксации заменой заголовка обратно на Public-Key-Pins.

воскресенье, 26 февраля 2017 г.

HSTS - строгая безопасность транспорта HTTP в Apache, nginx и Lighttpd

Перевод: HTTP Strict Transport Security for Apache, NGINX and Lighttpd
Автор: Реми ван Элст (Remy van Elst)

Содержание
  1. Что такое "строгая безопасность транспорта HTTP"?
  2. Важное замечание о предварительной загрузке
  3. Настройка HSTS в Apache
  4. Lighttpd
  5. nginx
  6. Заголовок X-Frame-Options
    1. X-Frame-Options в Apache
    2. Lighttpd
    3. nginx
Строгая безопасность транспорта HTTP (часто сокращается как HSTS) - это функция безопасности, которая позволяет веб-серверу сообщать веб-браузерам, что должно использоваться подключение только по HTTPS вместо HTTP. В этом руководстве рассказывается, как настроить HSTS в Apache, nginx и Lighttpd. Руководство протестировано со всеми перечисленными серверами: nginx 1.1.19, Lighttpd 1.4.28 и Apache 2.2.22 в Ubuntu 12.04, Debian 6 и 7, а также в CentOS 6. Руководство может быть пригодным и для других дистрибутивов, а данные дистрибутивы указаны в качестве эталона.

Что такое "строгая безопасность транспорта HTTP"?

Процитируем Mozilla Developer Network - сеть разработчиков Mozilla:
Если веб-сайт принимает подключения по HTTP и перенаправляет их на HTTPS, то пользователь в этом случае обращается сначала к нешифрованной версии сайта и только потом перенаправляется. Например, если пользователь введёт http://www.foo.com/ или даже просто foo.com.

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

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

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

Важное замечание о предварительной загрузке

В конфигурации ниже использовалась директива предварительной загрузки. По просьбе Лукаса Гэррона (Lucas Garron) из Google, я удалил её, поскольку у многих людей возникли с ней проблемы.

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

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

Если вы всё ещё хотите использовать предварительную загрузку, просто добавьте preload в заголовок после точки с запятой.

Настройка HSTS в Apache

Отредактируйте файл конфигурации Apache (например, /etc/apache2/sites-enabled/website.conf и /etc/apache2/httpd.conf) и добавьте следующие настройки в секцию VirtualHost:
# Необязательная загрузка модуля headers:
LoadModule headers_module modules/mod_headers.so

<VirtualHost 67.89.123.45:443>
  Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"
</VirtualHost>
Теперь веб-сайт будет при каждом посещении устанавливать заголовок со сроком годности два года (в секундах). Заголовок будет устанавливаться при каждом посещении. Например, завтра он опять будет иметь годность два года.

Заголовок нужно устанавливать только в виртуальном хосте, работающем по протоколу HTTPS. Его не может быть в виртуальном хосте, работающем по протоколу HTTP.

Чтобы перенаправить посетителей на HTTPS-версию сайта, воспользуйтесь следующими настройками:
<VirtualHost *:80>
  [...]
  ServerName example.com
  Redirect permanent / https://example.com/
</VirtualHost>
Если всегда будет происходить только перенаправление, то корень документов указывать не требуется.

Можно также воспользоваться modrewrite, хотя метод выше проще и безопаснее. Однако, вариант с modrewrite ниже перенаправляет пользователя на HTTPS-версию той страницы, на которую он хотел попасть, а конфигурация выше просто перенаправляет в /:
<VirtualHost *:80>
  [...]
  <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
  </IfModule>
</VirtualHost>
И не забудьте перезапустить Apache.

Lighttpd

В случае Lighttpd всё очень просто. Добавим в файл конфигурации Lighttpd (например, в /etc/lighttpd/lighttpd.conf) следующие строки:
server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
  setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=63072000; includeSubdomains; ")
}
И перезапустим Lighttpd. В этой конфигурации срок действия такой же - два года.

nginx

Настройка nginx даже ещё короче. Добавьте следующую строку в блок server, относящийся к настройке HTTPS:
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; ";
Не забудьте перезапустить nginx.

Заголовок X-Frame-Options

Последний совет, который я хочу дать - это заголовок X-Frame-Options, который можно добавить к веб-сайту HTTPS, чтобы предотвратить его встраивание в frame или iframe. Это позволит избежать кликджекинга и может быть полезно для веб-сайтов HTTPS. Снова процитирую Mozilla Developer Network - сеть разработчиков Mozilla:

Заголовок в HTTP-ответе X-Frame-Options может использоваться для того, чтобы обозначить, должен ли браузер показывать страницу в "<frame>" или в "<iframe>". Сайты могут использовать этот заголовок для защиты от кликджекинга, чтобы быть уверенным в том, что их страницы не будут встроены в другие сайты.

Вы можете заменить DENY (запретить) на SAMEORIGIN (тот же источник) или ALLOW-FROM (разрешено при переходе с) URI. Обратитесь по ссылке выше за более подробной информацией (или к RFC).

X-Frame-Options в Apache2

Как и в прошлый раз, добавим строчку в конфигурацию Apache:
Header always set X-Frame-Options DENY
Lighttpd

То же самое можно сделать и в Lighttpd. Убедитесь, что не дублируете настройки, указанные выше. Если настройки уже есть, просто добавьте в них новое правило.
server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
  setenv.add-response-header = ( "X-Frame-Options" => "DENY")
}
nginx

И снова, в блоке server:
add_header X-Frame-Options "DENY";

воскресенье, 19 февраля 2017 г.

Вшивание OCSP в Apache

Перевод: OCSP Stapling on Apache
Автор: Реми ван Элст (Remy van Elst)

Содержание
  1. Что такое "вшивание OSCP"?
  2. Требования
  3. Конфигурация Apache
    1. SSLUseStapling
    2. SSLStaplingCache
  4. Тестирование
  5. Источники
При подключении к серверу, клиент должен проверить действительность сертификата сервера по списку отозванных сертификатов - CRL, или по протоколу интерактивного статуса сертификата - OCSP. Проблема CRL заключается в том, что списки могут вырасти до огромных размеров и скачивание может затянуться на вечность.

OCSP намного легче, поскольку за один раз запрашивается одна запись. Но недостаток состоит в том, что при подключении к серверу нужно выполнить OCSP-запрос к стороннему ответчику, что увеличивает задержку и может оказаться причиной сбоев. Фактически, ответчики OCSP управляются удостоверяющим центром, недоступность которого для браузера приведёт к ошибке, если ответ не будет получен своевременно. Это уменьшает безопасность, позволяя атакующему наводнить запросами ответчик OCSP, чтобы отключить проверку.

Решение заключается в том, чтобы разрешить серверу отправлять в процессе рукопожатия TLS запись OCSP из кэша, так чтобы не затрагивать ответчика OCSP. Этот механизм избавляет клиента от необходимости связываться с ответчиком OCSP и называется вшиванием OCSP.

Сервер посылает ответ OCSP из кэша только если клиент его запрашивает, сообщая в CLIENT HELLO о поддержке расширения TLS status_request.

Большинство серверов сохраняют в кэш OCSP-ответы на 48 часов. Через регулярные интервалы времени сервер будет подключаться к ответчику OCSP удостоверяющего центра, чтобы получить свежую запись OCSP. Расположение ответчика OCSP берётся из подписанного сертификата, из поля Authority Information Access - доступ к информации о подлинности.

Это руководство также доступно для nginx.

Что такое "вшивание OCSP"?

Вшивание OCSP определено в IETF RFC 6066. "Вшивание" - это популярное слово, используемое для объяснения принципа получения OCSP-ответа от веб-сервера. Веб-сервер помещает в кэш ответ от удостоверяющего центра, выпустившего сертификат. В процессе рукопожатия SSL/TLS ответ клиенту возвращается веб-сервером, который прикладывает OCSP-ответ из кэша в сообщение CertificateStatus со статусом сертификата. Для использования вшивания OCSP клиент должен включить расширение status_request в его приветственном SSL/TSL-сообщении.

Вшивание OCSP имеет несколько дополнительных плюсов:
  • Клиент получает статус сертификата веб-сервера, когда это требуется (в процессе рукопожатия SSL/TLS).
  • Не требуется устанавливать дополнительное HTTP-подключение к удостоверяющему центру, выпустившему сертификат.
  • Вшивание OCSP увеличивает безопасность, уменьшая количество векторов атаки.
Обратитесь за дополнительной информацией об OCSP и вшивании OCSP по одной из следующих ссылок:
Требования

Для настройки потребуется Apache версии 2.3.3 или выше и OpenSSL версии 0.9.8h или выше. Они не доступны в текущем релизе Ubuntu LTS (12.04), где есть только 2.2.22, а в CentOS 6 есть только 2.2.15. Поищите неофициальный репозиторий в PPA или соберите программы самостоятельно.

Также нужно создать исключение в пакетном фильтре, чтобы разрешить веб-серверу совершать исходящие подключения к вышестоящим серверам OCSP. URI OCSP веб-сайта можно увидеть при помощи следующей команды:
OLDIFS=$IFS; \
IFS=':' certificates=$(openssl s_client -connect google.com:443 -showcerts -tlsextdebug -tls1 2>&1 </dev/null \
 | sed -n '/-----BEGIN/,/-----END/ {/-----BEGIN/ s/^/:/; p}'); \
for certificate in ${certificates#:}; do \
 echo $certificate | openssl x509 -noout -ocsp_uri; \
done; \
IFS=$OLDIFS
Вот результаты для google.com:
http://clients1.google.com/ocsp
http://gtglobal-ocsp.geotrust.com
Замените google.com на ваш домен. Также отметим, что требуются GNU-версии sed и bash. Команда не работает в OS X и в BSD.

Конфигурация Apache

Добавим следующие настройки в секцию VirtualHost:
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
Далее приведём объяснение этих двух строк:

SSLUseStapling

Вшивание OCSP освобождает клиента от необходимости обращаться к OCSP-ответчику самостоятельно, но необходимо отметить, что в соответствии со спецификацией RFC 6066, ответ сервера в поле CertificateStatus может содержать OCSP-ответ только для одного сертификата. Если же в сертификате сервера имеется цепочка сертификатов промежуточных удостоверяющих центров (что в наши дни встречается повсеместно), текущая реализация вшивания лишь частично достигает цели "снизить задержку и использование ресурсов". Обратитесь также к RFC 6961, где описывается TLS Multiple Certificate Status Extension - расширение TLS для проверки статуса нескольких сертификатов.

SSLStaplingCache

Настраивает кэш для хранения OCSP-ответов, которые будут использоваться в процедуре рукопожатия TLS, если включена директива SSLUseStapling. Необходима явная настройка кэша для вшивания OCSP. Поддерживаются те же типы хранилища, что и в SSLSessionCache, за исключением none и nonenotnull.

Глава о shmbc:

Создаёт высокопроизводительный циклический буфер (размером примерно size байт) в разделяемом сегменте оперативной памяти (создаётся через путь к файлу данных - /path/to/datafile) для синхронизации кэшей локальной памяти OpenSSL процессов сервера. Рекомендуется использовать его для кэширования сеансов. При использовании убедитесь, что загружен модуль mod_socache_shmcb.

Также можно указать несколько дополнительных опций. Например, время, через которое OCSP-ответ будет считаться устаревшим:
SSLStaplingResponseMaxAge 900
Эта директива разрешает держать ответ в кэше не более 15 минут (900 секунд).

Если сервер Apache находится за HTTP-прокси, может понадобиться выполнять OCSP-запросы через прокси. Для этого можно воспользоваться директивой SSLStaplingForceURL. Она заменяет URL из сертификата:
SSLStaplingForceURL http://internal-proxy.example.org
Перезапустите Apache, чтобы загрузить новую конфигурацию:
service apache2 restart
Теперь всё должно заработать. Давайте проверим.

Тестирование

Откройте терминал и воспользуйтесь следующей командой OpenSSL для подключения к вашему веб-сайту:
openssl s_client -connect example.org:443 -tls1 -tlsextdebug -status
В ответе обратим внимание на следующее:
OCSP response:                                                   # Ответ OCSP:
======================================
OCSP Response Data:                                              # Данные ответа OCSP
    OCSP Response Status: successful (0x0)                       #     Статус ответа OCSP: успешно (0x0)
    Response Type: Basic OCSP Response                           #     Тип ответа: Базовый ответ OCSP
    Version: 1 (0x0)                                             #     Версия: 1 (0x0)
    Responder Id: 99E4405F6B145E3E05D9DDD36354FC62B8F700AC       #     Идентификатор ответчика
    Produced At: Feb 3 04:25:39 2014 GMT                         #     Сформирован: 3 февраля 2014 года в 04:25:39 по Гринвичу
    Responses:                                                   #     Ответы:
    Certificate ID:                                              #     Идентификатор сертификата:
      Hash Algorithm: sha1                                       #       Алгоритм хэширования: sha1
      Issuer Name Hash: 0226EE2F5FA2810834DACC3380E680ACE827F604 #       Хэш имени эмитента
      Issuer Key Hash: 99E4405F6B145E3E05D9DDD36354FC62B8F700AC  #       Хэш ключа эмитента
      Serial Number: 1003                                        #       Серийный номер
    Cert Status: good                                            #     Статус сертификата: хороший
    This Update: Feb 3 04:25:39 2014 GMT                         #     Это обновление: 3 февраля 2014 года в 04:25:39 по Гринвичу
    Next Update: Feb 7 04:25:39 2014 GMT                         #     Следующее обновление: 7 февраля 2014 года в 04:25:39 по Гринвичу
Этот ответ означает, что всё работает. Если получен ответ, подобный следующему, то это значит что вшивание OCSP не работает:
OCSP response: no response sent # OCSP-ответ: ответ не получен
Вы также можете воспользоваться проверкой SSL Labs, чтобы проверить, что вшивание OCSP работает.

Источники

воскресенье, 12 февраля 2017 г.

Вшивание OCSP в nginx

Перевод: OCSP Stapling on nginx
Автор: Реми ван Элст (Remy van Elst)

Содержание
  1. Что такое "вшивание OSCP"?
  2. Требования
  3. Конфигурация nginx
  4. Тестирование
  5. Источники
При подключении к серверу, клиент должен проверить действительность сертификата сервера по списку отозванных сертификатов - CRL, или по протоколу интерактивного статуса сертификата - OCSP. Проблема CRL заключается в том, что списки могут вырасти до огромных размеров и скачивание может затянуться на вечность.

OCSP намного легче, поскольку за один раз запрашивается одна запись. Но недостаток состоит в том, что при подключении к серверу нужно выполнить OCSP-запрос к стороннему ответчику, что увеличивает задержку и может оказаться причиной сбоев. Фактически, ответчики OCSP управляются удостоверяющим центром, недоступность которого для браузера приведёт к ошибке, если ответ не будет получен своевременно. Это уменьшает безопасность, позволяя атакующему наводнить запросами ответчик OCSP, чтобы отключить проверку.

Решение заключается в том, чтобы разрешить серверу отправлять в процессе рукопожатия TLS запись OCSP из кэша, так чтобы не затрагивать ответчика OCSP. Этот механизм избавляет клиента от необходимости связываться с ответчиком OCSP и называется вшиванием OCSP.

Сервер посылает ответ OCSP из кэша только если клиент его запрашивает, сообщая в CLIENT HELLO о поддержке расширения TLS status_request.

Большинство серверов сохраняют в кэш OCSP-ответы на 48 часов. Через регулярные интервалы времени сервер будет подключаться к ответчику OCSP удостоверяющего центра, чтобы получить свежую запись OCSP. Расположение ответчика OCSP берётся из подписанного сертификата, из поля Authority Information Access - доступ к информации о подлинности.

Это руководство также доступно для Apache.

Что такое "вшивание OCSP"?

Вшивание OCSP определено в IETF RFC 6066. "Вшивание" - это популярное слово, используемое для объяснения принципа получения OCSP-ответа от веб-сервера. Веб-сервер помещает в кэш ответ от удостоверяющего центра, выпустившего сертификат. В процессе рукопожатия SSL/TLS веб-сервер возвращает клиенту ответ, к которому прикладывает OCSP-ответ из кэша в поле CertificateStatus со статусом сертификата. Для использования вшивания OCSP клиент должен включить расширение status_request в приветствии SSL/TSL.

Вшивание OCSP имеет несколько дополнительных плюсов:
  • Клиент получает статус сертификата веб-сервера, когда это требуется (в процессе рукопожатия SSL/TLS).
  • Не требуется устанавливать дополнительное HTTP-подключение к удостоверяющему центру, выпустившему сертификат.
  • Вшивание OCSP увеличивает безопасность, уменьшая количество векторов атаки.
Обратитесь за дополнительной информацией об OCSP и вшивании OCSP по одной из следующих ссылок:
Требования

Необходим nginx версии не ниже 1.3.7. Эта версия не доступна в текущем релизе Ubuntu LTS (12.04), где есть только 1.1.19, а в CentOS нужен EPEL или официальные репозитории. Однако, установить последнюю версию nginx довольно легко.

Также нужно создать исключение в пакетном фильтре, чтобы разрешить веб-серверу совершать исходящие подключения к вышестоящим серверам OCSP. URI OCSP веб-сайта можно увидеть при помощи следующей команды:
OLDIFS=$IFS; \
IFS=':' certificates=$(openssl s_client -connect google.com:443 -showcerts -tlsextdebug -tls1 2>&1 </dev/null \
 | sed -n '/-----BEGIN/,/-----END/ {/-----BEGIN/ s/^/:/; p}'); \
for certificate in ${certificates#:}; do \
 echo $certificate | openssl x509 -noout -ocsp_uri; \
done; \
IFS=$OLDIFS
Вот результаты для google.com:
http://clients1.google.com/ocsp
http://gtglobal-ocsp.geotrust.com
Конфигурация nginx

Добавьте следующую конфигурацию в блок server с настройками https (443):
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
Чтобы вшивание OCSP заработало, должен быть известен эмитент сертификата сервера. Если файл ssl_certificate не содержит промежуточных сертификатов, сертификат эмитента сертификата сервера должен быть представлен в файле ssl_trusted_certificate.

Мой сертификат для raymii.org выпущен удостоверяющим центром Positive CA 2. Этот сертификат выпущен корневым удостоверяющим центром Addtrust External CA Root. В файле, указанном в директиве ssl_certificate, должны присутствовать оба сертификата. Если в вашем случае это не так, создайте файл с цепочкой сертификатов и используйте его следующим образом:
ssl_trusted_certificate /etc/ssl/certs/domain.chain.stapling.pem;
До версии 1.1.7 можно было настроить только одно имя сервера. Указание имени серверов с помощью адресов IPv6 поддерживается, начиная с версий 1.3.1 и 1.2.2. По умолчанию nginx будет искать и адреса IPv4 и IPv6. Если поиск адресов IPv6 не желателен, можно указать параметр ipv6=off. Решение имён в адреса IPv6 поддерживается начиная с версии 1.5.8.

По умолчанию nginx помещает ответы в кэш, используя значение TTL из ответа. Необязательный параметр valid позволяет заменить его на 5 минут. До версии 1.1.9 настройка времени кэширования была невозможной и nginx всегда помещал ответы в кэш на 5 минут.

Перезапустите nginx, чтобы загрузить новую конфигурацию:
service nginx restart
Теперь всё должно заработать. Давайте проверим.

Тестирование

Откройте терминал и воспользуйтесь следующей командой OpenSSL для подключения к вашему веб-сайту:
openssl s_client -connect example.org:443 -tls1 -tlsextdebug -status
В ответе обратим внимание на следующее:
OCSP response:                                                   # Ответ OCSP:
======================================
OCSP Response Data:                                              #     Данные ответа OCSP
    OCSP Response Status: successful (0x0)                       #     Статус ответа OCSP: успешно (0x0)
    Response Type: Basic OCSP Response                           #     Тип ответа: Базовый ответ OCSP
    Version: 1 (0x0)                                             #     Версия: 1 (0x0)
    Responder Id: 99E4405F6B145E3E05D9DDD36354FC62B8F700AC       #     Идентификатор ответчика
    Produced At: Feb 3 04:25:39 2014 GMT                         #     Сформирован: 3 февраля 2014 года в 04:25:39 по Гринвичу
    Responses:                                                   #     Ответы:
    Certificate ID:                                              #     Идентификатор сертификата:
      Hash Algorithm: sha1                                       #       Алгоритм хэширования: sha1
      Issuer Name Hash: 0226EE2F5FA2810834DACC3380E680ACE827F604 #       Хэш имени эмитента
      Issuer Key Hash: 99E4405F6B145E3E05D9DDD36354FC62B8F700AC  #       Хэш ключа эмитента
      Serial Number: 1003                                        #       Серийный номер
    Cert Status: good                                            #     Статус сертификата: хороший
    This Update: Feb 3 04:25:39 2014 GMT                         #     Это обновление: 3 февраля 2014 года в 04:25:39 по Гринвичу
    Next Update: Feb 7 04:25:39 2014 GMT                         #     Следующее обновление: 7 февраля 2014 года в 04:25:39 по Гринвичу
Этот ответ означает, что всё работает. Если получен ответ, подобный следующему, то это значит что вшивание OCSP не работает:
OCSP response: no response sent # OCSP-ответ: ответ не получен
Вы также можете воспользоваться проверкой SSL Labs, чтобы проверить, что вшивание OCSP работает.

Источники

воскресенье, 5 февраля 2017 г.

Высокая безопасность SSL в Apache

Перевод: Strong SSL Security on Apache2
Автор: Реми ван Элст (Remy van Elst)

Содержание
  1. Атака BEAST и RC4
  2. Факторизация ключей RSA-EXPORT (FREAK)
  3. Logjam (DH EXPORT)
  4. Heartbleed - кровоточащее сердце
  5. Сжатие SSL (атака CRIME)
  6. SSLv2 и SSLv3
  7. Poodle и TLS-FALLBACK-SCSV
  8. Набор шифров
  9. Логика приоритезации
  10. Явный запрет
  11. Forward Secrecy и параметры эфемерного Диффи-Хеллмана
  12. HSTS - строгая безопасность транспорта HTTP
  13. HPKP - расширение для фиксации публичного ключа HTTP
  14. Вшивание OCSP
  15. Заключение


В этом руководстве показано, как настроить высокую безопасность SSL на веб-сервере Apache. Для этого мы обновим OpenSSL до самой свежей версии, чтобы избежать атак Heartbleed, отключим сжатие SSL и шифры EXPORT, чтобы избежать атак FREAK, CRIME и Logjam, отключим SSL версии 3 и ниже, потому что эти протоколы уязвимы и зададим строгий набор шифров, который по возможности включает Forward Secrecy. Мы также включим HSTS и HPKP. Таким образом мы получим стойкую конфигурацию SSL с богатыми возможностями защиты и получим оценку A+ в тесте Qually Labs SSL.

Я создал веб-сайт с примерами настройки стойких шифров для nginx, Apache, Lighttpd и для другого программного обеспечения: https://cipherli.st. Сайт может пригодиться, если нет времени читать это руководство целиком. Это руководство и веб-сайт https://cipherli.st обновляются по мере обнаружения новых уязвимостей.

Я написал веб-приложение с открытым исходным текстом для проверки SSL-серверов. Можно воспользоваться им для проверки конфигурации в дополнение к другим проверкам SSL. Исходные тексты открыты, поэтому вы можете разместить его локально. Проверка быстрая и отображает всю информацию, которая позволит принять собственное обоснованное решение (без оценок), а результаты сохраняются, так что можно сравнивать различные настройки. Сайт можно проверить по адресу https://ssldecoder.org.

Я также написал удобное веб-приложение, которое уведомляет о скором завершении срока действия сертификата. Исходные тексты открыты, поэтому можно разместить его локально. Уже установленное веб-приложение доступно по адресу https://certificatemonitor.org.

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

Атака BEAST и RC4

Вкратце: при взломе алгоритмов блочного шифрования части зашифрованного трафика могут быть тайно расшифрованы. Больше информации можно узнать по ссылке.

В новых версиях браузеров включено смягчение атаки BEAST со стороны клиента. Рекомендуется выключить все шифры TLS 1.0 и предлагать только RC4. Однако, список атак против RC4 растёт, многие из них становятся осуществимыми на практике. Более того, есть причины считать, что АНБ взломало RC4, назвав это "большим прорывом".

Отключение RC4 влечёт за собой несколько последствий. Во-первых, пользователи говнобраузеров Internet Explorer в Windows XP вместо него будут использовать 3DES. Triple-DES более безопасен по сравнению с RC4, но обходится значительно дороже. Веб-сервер заплатит цену за этих пользователей. Во-вторых, RC4 смягчает BEAST. Но отключение RC4 делает пользователей TLS 1.0 подверженными этой атаке, заставляя их использовать AES-CBC (обычно от этого защищает приоритет со стороны сервера, настаивающий на использовании RC4). Но я уверен, что сам RC4 несёт в себе больше рисков, чем риск от атак BEAST. Действительно, смягчения со стороны клиента (которые имеются в Chrome и Firefox), избавляют от BEAST. Но риск от использования RC4 со временем только возрастает: криптоаналитики выявляют всё больше проблем.

Факторизация ключей RSA-EXPORT (FREAK)

FREAK - это уязвимость типа "человек в середине", обнаруженная группой криптографов из INRIA, Microsoft Research и IMDEA. FREAK означает "Factoring RSA-EXPORT Keys" - факторизация ключей RSA-EXPORT.

Уязвимость ведёт историю с 1990-х годов, когда правительство США запретило продажу программных криптографических средств за границу, если в них используются наборы шифров с ключами длиннее 512-бит.

Оказалось, что некоторые современные клиенты TLS, включая SecureTransport от Apple и OpenSSL, содержат ошибку. Эта ошибка приводит к тому, что применяются ключи RSA экспортного класса, даже если клиент не запрашивает экспортный класс RSA. Воздействие этой ошибки может быть очень неприятным: это позволяет "человеку в середине" реализовать атаку, в результате которой атакующий сможет понизить безопасность соединения, если клиент имеет уязвимость, а сервер поддерживает экспортный RSA.

Для атаки необходимо выполнение двух условий, поскольку сервер тоже должен принимать "RSA экспортного класса".

Человек в середине атакует следующим образом:
  • В приветственном сообщении клиент запрашивает обычный шифр RSA.
  • Человек в середине меняет это сообщение на запрос RSA экспортного класса.
  • Сервер возвращает в ответе 512-битный ключ RSA экспортного класса, подписанный его долгосрочным ключом.
  • Клиент принимает этот слабый ключ из-за ошибки в OpenSSL/SecureTransport.
  • Атакующий факторизует модуль RSA, чтобы восстановить соответствующий ключ RSA для дешифрования.
  • Когда клиент шифрует премастер-секрет, то атакующий может расшифровать его, чтобы восстановить мастер-секрет TLS.
  • С этого момента атакующий может расшифровывать передаваемую информацию и может подменять её.
Предложенный здесь набор шифров не включает класс шифров EXPORT. Убедитесь, что OpenSSL обновлён до последней доступной версии и заставьте клиентов обновить их программное обеспечение.

Logjam (DH EXPORT)

Исследователи из нескольких университетов и институтов провели исследования, в результате которых в протоколе TLS были найдены проблемы. В отчёте этих исследователей сообщается о двух способах атаки.

Обмен ключами Диффи-Хеллмана позволяет в зависимости от TLS согласиться на общий ключ и согласовать безопасный сеанс через незащищённое подключение.

Первая угроза заключается в том, что человек в середине может ослабить уязвимое подключение TLS до 512-битной криптографии экспортного класса, что позволит атакующему читать и изменять данные. Вторая угроза основывается на том, что многие серверы используют одинаковые простые числа для обмена ключами Диффи-Хеллмана, вместо того, чтобы каждый раз создавать свои собственные новые уникальные параметры.

Команда оценила, что академические команды способны взломать 768-битные простые числа, а на государственном уровне возможно взломать 1024-битные простые числа. Взлом одного 1024-битного простого числа позволит прослушивать до 18 процентов из миллиона самых популярных доменов HTTPS. Взлом второго простого числа позволит открыть до 66 процентов VPN-подключений и до 26 процентов SSH-серверов.

Далее в этом руководстве мы создадим собственные уникальные параметры Диффи-Хеллмана и воспользуемся набором шифров, который исключает шифры класса EXPORT. Убедитесь, что OpenSSL обновлён до самой свежей версии и заставьте клиентов обновить их программное обеспечение. Обновлённые браузеры для устранения проблемы отклоняют параметры Диффи-Хеллмана короче 768/1024 бит.

У Cloudflare есть подробное руководство по Logjam.

Heartbleed - кровоточащее сердце

Heartbleed - это ошибка безопасности, обнаруженная в апреле 2014 года в криптографической библиотеке OpenSSL, которая широко используется для реализации протокола TLS. Уязвимостью Heartbleed можно воспользоваться вне зависимости от того, используется ли уязвимая версия OpenSSL для TLS на сервере или на клиенте. Ошибка заключается в недостаточной проверки входных данных (из-за отсутствия проверки границ) в реализации расширения сердцебиения DTLS (RFC6520), из-за чего ошибка получила название heartbleed - кровоточащее сердце, производное от названия расширения heartbeet - сердцебиение. Уязвимость классифицируется как чтение за пределами буфера - случай, когда можно прочитать больше информации, чем должно быть разрешено.

Какие версии OpenSSL затрагивает Heartbleed?

Состояние различных версий:
  • OpenSSL 1.0.1 и до 1.0.1f (включительно) уязвимы
  • OpenSSL 1.0.1g НЕ уязвима
  • Ветка OpenSSL 1.0.0 НЕ уязвима
  • Ветка OpenSSL 0.9.8 НЕ уязвима
Ошибка была добавлена в OpenSSL в декабре 2011 и встречалась в дикой природе начиная с релиза OpenSSL 1.0.1 от 14 марта 2012 года. Ошибка была исправлена в выпуске OpenSSL 1.0.1g от 7 апреля 2014 года.

Защититься от уязвимости можно обновив OpenSSL.

Сжатие SSL (атака CRIME)

Атака CRIME для своего тёмного дела использует сжатие SSL, поэтому его нужно отключить. В Apache 2.2.24+ можно добавить следующую строку в файл конфигурации SSL, который уже был редактирован выше:
SSLCompression off
Если используется одна из более ранних версий Apache или OpenSSL и в дистрибутив не бэкпортировали эту опцию, то нужно пересобрать OpenSSL без поддержки ZLIB. Это приведёт к отключению сжатия по методу DEFLATE в OpenSSL. Даже после этого можно по-прежнему использовать обычное сжатие HTML DEFLATE.

SSLv2 и SSLv3

SSL версии 2 небезопасен, поэтому нужно отключить его. Мы также отключим SSL версии 3, поскольку TLS 1.0 содержит возможность переключиться атакующему на использование SSL версии 3, а затем отключить forward secrecy.

SSL версии 3 позволяет воспользоваться ошибкой POODLE. Это одна из важных причин для его отключения!

Снова отредактируем файл конфигурации:
SSLProtocol All -SSLv2 -SSLv3
All - это сокращение для +SSLv2 +SSLv3 +TLSv1. Если используется версия OpenSSL 1.0.1 или более поздняя, то All соответствует +SSLv2 +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2. В строке выше включаются все протоколы, за исключением SSLv2 и SSLv3. Дополнительную информацию можно найти на веб-сайте Apache.

Poodle и TLS-FALLBACK-SCSV

SSL версии 3 позволяет воспользоваться ошибкой POODLE. Это одна из важных причин для его отключения.

Google предложил расширение для SSL/TLS, которое называется TLSFALLBACKSCSV и позволяет предотвратить переключение на более слабые возможности SSL. Оно автоматически включается по умолчанию при обновлении OpenSSL до одной из указанных версий:
  • OpenSSL 1.0.1 поддерживает TLSFALLBACKSCSV в 1.0.1j и выше.
  • OpenSSL 1.0.0 поддерживает TLSFALLBACKSCSV в 1.0.0o и выше.
  • OpenSSL 0.9.8 поддерживает TLSFALLBACKSCSV в 0.9.8zc и выше.
Набор шифров

(Perfect) Forward Secrecy - (совершенно) прямая секретность - гарантирует целостность сеансового ключа в ситуации, когда скомпрометирован долгосрочный ключ. Perfect Forward Secrecy - совершенно прямая секретность - достигается тем, что для каждого сеанса выводится новый ключ.

Это означает, что при компрометации приватного ключа нельзя воспользоваться им для расшифровки записанного трафика SSL.

Наборы шифров, предоставляющие Perfect Forward Secrecy - это те, которые используют эфемерный обмен ключами Диффи-Хеллмана. Их недостаток - это накладные расходы, которые можно снизить использованием вариантов на эллиптических кривых.

Я рекомендую следующие два набора шифров, а после меня их стали рекомендовать и Mozilla Foundation.

Рекомендуемый набор шифров:
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
Рекомендуемый набор шифров для обратной совместимости (IE6/WinXP):
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
В старых версиях OpenSSL недоступные шифры будут пропущены автоматически. Всегда используйте полный набор шифров, указанных выше и позвольте OpenSSL выбирать те из них, которые поддерживаются.

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

Более старые версии OpenSSL могут не возвращать полный список алгоритмов. Алгоритмы AES-GCM и некоторые виды ECDHE появились сравнительно недавно и отсутствуют в большинстве версий OpenSSL, поставляемых в составе Ubuntu или RHEL.

Логика приоритезации
  • Шифры ECDHE+AESGCM выбираются в первую очередь. Это шифры TLS 1.2. В настоящее время для этих шифров нет известных способов атаки.
  • Предпочитаются наборы шифров PFS сначала с ECDHE, а затем с DHE.
  • AES 128 более предпочтителен, чем AES 256. Есть мнение, что дополнительная степень безопасности AES256 имеет высокую цену при не очевидном результате. На данный момент предпочтительнее AES128, потому что он предоставляет хорошую безопасность, сравнительно быстр и, похоже, более устойчив к атакам по времени.
  • В наборах шифров для обратной совместимости AES предпочтительнее, чем 3DES. Атаки BEAST смягчены в TLS 1.1 и выше, а в TLS 1.0 труднореализуемы. В наборах шифров без обратной совместимости 3DES отсутствует.
  • RC4 удалён полностью. 3DES используется для обратной совместимости. Обратитесь к обсуждению по ссылке #RC4_weaknesses
Явный запрет
  • aNULL содержит не аутентифицированный обмен ключами Диффи-Хеллмана, поэтому подвержены атакам типа "человек в середине".
  • eNULL содержит шифры без шифрования (данные передаются открытым текстом).
  • EXPORT - это устаревшие слабые шифры, которые помечены как разрешённые для экспорта по законам США.
  • RC4 содержит шифры, которые используют устаревший алгоритм ARCFOUR.
  • DES содержит шифры, которые используют устаревший стандарт шифрования данных - Data Encryption Standard.
  • SSLv2 содержит все шифры, которые были определены в старой версии стандарта SSL, ныне устаревшего.
  • MD5 содержит все шифры, которые используют устаревший алгоритм проверки целостности - message digest 5.
Apache 2.2.x может работать только с наборами шифров с эфемерным Диффи-Хеллманом, но этого не достаточно. Во всех версиях Internet Explorer требуемые наборы шифров с эфемерным Диффи-Хеллманом не позволяют использовать Forward Secrecy. (Если вы не используете ключи DSA, но их никто не использует - это отдельная история.) Apache не поддерживает настройку параметров Диффи-Хеллмана ни в одной из версий, но существуют заплатки, которыми можно воспользоваться при установке из исходных текстов.

Даже если OpenSSL может предоставить ECDHE, Apache 2.2 в стабильном Debian не поддерживает этот механизм. Для полной поддержки Forward Secrecy нужен Apache 2.4.

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

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

Forward Secrecy и параметры эфемерного Диффи-Хеллмана

Концепция Forward Secrecy проста: клиент и сервер согласуют ключ, который никогда не передаётся по сети и уничтожается при завершении сеанса. Приватный RSA-ключ сервера используется для подписи обмена ключами Диффи-Хеллмана между клиентом и сервером. Премастер-ключ получается из рукопожатия Диффи-Хеллмана, а затем используется для шифрования. Поскольку премастер-ключ относится к подключению между клиентом и сервером и используется только ограниченное время, он называется эфемерным.

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

Apache вплоть до версии 2.4.7 и все версии nginx по состоянию на момент выхода версии 1.4.4 полагаются на входные параметры для протокола Диффи-Хеллмана из OpenSSL. Поэтому эфемерный протокол Диффи-Хеллмана будет использовать настройки по умолчанию из OpenSSL, которые включают использование 1024-битного ключа для обмена ключами. Поскольку мы используем 2048-битный сертификат, клиенты, использующие эфемерный протокол Диффи-Хеллмана, будут использовать более слабый обмен ключами, чем клиенты, использующие не эфемерный протокол Диффи-Хеллмана.

Единственный способ исправить Apache - обновление до версии 2.4.7 или более поздней. Начиная с этой версии Apache автоматически выбирает более стойкий ключ.

Если используется Apache версии 2.4.8 или более поздней и OpenSSL версии 1.0.2 или более поздней, можно сгенерировать и указать файл с параметрами Диффи-Хеллмана:
# Генерируем параметры:
cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096
Добавьте в конфигурацию Apache следующую строку:
SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"
Если используется Apache и библиотека LibreSSL или Apache 2.4.7 и библиотека OpenSSL версии 0.9.8a и выше, можно добавить сгенерированные параметры Диффи-Хеллмана в конец файла сертификата. Документация об этом приведена ниже:

Собственные параметры Диффи-Хеллмана и имя эллиптических кривых для эфемерных ключей можно также добавить в конец первого файла, указанного в SSLCertificateFile. Такая возможность доступна в версии 2.4.7 и более поздних. Такие параметры могут быть сгенерированы с помощью команд openssl dhparam и openssl ecparam. Параметры могут быть добавлены как есть в конец первого файла сертификата. Для настройки особых параметров может использоваться только первый файл, поскольку они применяются вне зависимости от используемого алгоритма аутентификации.

Примерно в мае в Debian бэкпортировали шифры ECDH для их использования в Apache 2.2, после чего появилась возможность использования Perfect Forward Secrecy: http://metadata.ftp-master.debian.org/changelogs//main/a/apache2/apache22.2.22-13+deb7u3changelog
> apache2 (2.2.22-13+deb7u2) wheezy; urgency=medium

* Backport support for SSL ECC keys and ECDH ciphers. # Бэкпортирована поддержка ключей SSL ECC и шифров ECDH.
HSTS - строгая безопасность транспорта HTTP

По возможности лучше включить строгую безопасность транспорта HTTP (HSTS), которая предписывает браузеру связываться с сайтом только через HTTPS.

Обратитесь к моей статье по HSTS, чтобы узнать, как её настроить.

HKPK - расширение для фиксации публичного ключа HTTP

Также стоит включить расширение для фиксации публичного ключа HTTP.

Фиксация публичного ключа означает, что цепочка сертификатов должна включать публичный ключ из белого списка. Это гарантирует, что сертификаты для *.example.com могут быть подписаны только удостоверяющими центрами из белого списка, но не какими-либо другими удостоверяющими центрами из хранилища в браузере.

Я написал статью с объяснением теории и примерами конфигурации для Apache, Lighttpd и nginx.

Вшивание OCSP

При подключении к серверу клиенты должны проверить действительность сертификата сервера по списку отозванных сертификатов (CRL) или через протокол интерактивного статуса сертификата (OCSP). Проблема списков отозванных сертификатов заключается в том, что такие списки вырастают до огромных размеров и их скачивание может затянуться на вечность.

OCSP намного легче, поскольку за один раз запрашивается одна запись. Но недостаток состоит в том, что при подключении к серверу нужно выполнить OCSP-запрос к стороннему ответчику, что увеличивает задержку и может оказаться причиной сбоев. Фактически, ответчики OCSP управляются удостоверяющим центром, недоступность которого для браузера приведёт к ошибке, если ответ не будет получен своевременно. Это уменьшает безопасность, позволяя атакующему наводнить запросами ответчик OCSP, чтобы отключить проверку.

Решение заключается в том, чтобы разрешить серверу отправлять в процессе рукопожатия TLS запись OCSP из кэша, так чтобы не затрагивать ответчика OCSP. Этот механизм избавляет клиента от необходимости связываться с ответчиком OCSP и называется вшиванием OCSP.

Сервер посылает ответ OCSP из кэша только если клиент его запрашивает, сообщая в CLIENT HELLO о поддержке расширения TLS status_request.

Большинство серверов сохраняют в кэш OCSP-ответы на 48 часов. Через регулярные интервалы времени сервер будет подключаться к ответчику OCSP удостоверяющего центра, чтобы получить свежую запись OCSP. Расположение ответчика OCSP берётся из подписанного сертификата, из поля Authority Information Access - доступ к информации о подлинности.

Обратитесь к моему руководству о включении вшивания OCSP в Apache.

Заключение

Чтобы указанные выше строчки файла конфигурации вступили в силу, нужно перезапустить Apache:
# Сначала проверим файл конфигурации:
apache2ctl -t
# Теперь перезапустим:
/etc/init.d/apache2 restart

# Если используется RHEL/CentOS:
apachectl -t
/etc/init.d/httpd restart
Теперь воспользуемся проверкой SSL Labs, чтобы увидеть рейтинг A+. И, конечно, у нас получилась безопасная и строгая конфигурация SSL с запасом на будущее!