Тема особенностей использования Domain-based Message Authentication, Reporting and Conformance или DMARC уже затрагивалась в рамках этого блога. Теперь хотелось бы остановиться на уже упомянутой в статье "DMARC для борьбы со спам на локальном и глобальном фронтах" особенностью обработки DMARC связанной с использованием возможности постепенного введения в действие политик типа quarantine и reject через использование их процентного модификатора.

К примеру, для отправителей из домена kostikov.co в соответствующей DMARC DNS-записи мы имеем следующее описание.

root@beta:~ # host -t txt _dmarc.kostikov.co
_dmarc.kostikov.co descriptive text "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-rua@kostikov.co"

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

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

root@beta:~ # drill -D peek.ru
...
peek.ru.        86400   IN      A       78.40.219.163
peek.ru.        86400   IN      RRSIG   A 6 2 86400 20161211171306 20161113171306 15134 peek.ru. ABZnLbVjEnQFk7sHoPH2iEX8KRygMjsRSsGzdMVy2scDrMsr8TQSCbs=
...

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

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

В опубликованных ранее постах уже затрагивался вопрос обеспечения должного уровня безопасности интернет сервисов посредством множества доступных в настоящее время механизмов, таких, например, как сертификаты SSL / TLS или электронную подпись DKIM.

Однако, ряд моментов, связанных с дополнительной защитой сайтов и, как следствие, технологией HTTP, мною пока детально не освещался. Тема же, безусловно, заслуживает более развёрнутого изложения. Такой попыткой и является эта статья.

Использование механизма DKIM в системе оборота электронной почты в последние годы получило широкое распространение.

Вкратце, суть его состоит в использовании цифровой подписи (пара открытый и закрытый ключи) к набору заголовков и тексту сообщения, которая позволяет подтвердить легитимность его происхождения. Благодаря этому DKIM в связке с механизмом SPF в надстройке в виде политик DMARC, в настоящее время являются одними из популярных способов борьбы с несанкционированными рассылками (спамом).

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

В этой связи, актуальным становится вопрос ротации ключей DKIM и автоматизации её процесса.

На страницах этого блога уже неоднократно затрагивались вопросы, связанные с защитой передаваемых по сети данных с использованием технологии SSL / TLS. Вопрос надёжности защищённых соединений в последнее время стал особенно актуальным для России, где на государственном уровне предполагается внедрение механизма для тотальной дешифровки всего трафика в Интернет одним из наиболее вероятных способов реализации которого, как раз, и может стать внедрение промежуточного сертификата для защищённых соединений.

В развитие темы, предлагаю вашему вниманию статью о внедрении относительно и новой пока малораспространённой технологии HTTP Public Key Pining (HPKP) и её использованию совместно с удостоверяющим центром Let's Encrypt.

Стандарт HPKP или key pining изложен в документе RFC7469 и описывает механизм, который призван повысить уровень защиты в WWW через дополнительную идентификацию и проверку того факта, что используемый в ходе защищённого соединения сертификат действительно принадлежит посещаемому сайту и не был подменён тем или иным заинтересованным лицом или структурой для несанкционированного доступа к передаваемой информации, то есть нейтрализации атак Man in the Middle (MitM).