Копытов Иван: заметки с тегом защита

Сервисы для тестирования веб, почты и других серверов (обновляемая запись)

Fri, 20 Jan 2023 13:35:10 +0700

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

Почта
CheckTLS. Очень любопытный сервис проверки почты. Наблюдаем за прогрессом в реальном времени.

DKIM Core Tools. Генерация и проверка настроек DKIM.

DMARC Inspector. Проверка корректности записи DMARC.

ESMTP email. Проверка настройки MTA-STS. Это функция, призывающая удаленные серверы обмениваться почтовыми сообщениями, используя защищенное соединение.

Mail tester. Всё время «теряю» этот сервис. Отправляете письмо на указанный адрес и через некоторое время можете посмотреть отчет о прохождении письма.

MX Toolbox. Сервис проверки почтового сервера и, немножко, веб-сервера. Множество самых различных тестов. Имхо, один из самых лучших сервисов.

SSL Tools. Старый и уже позабытый мной сервис проверки SSL почтового сервера. Также есть проверка web-сервера и некоторых уязвимостей.

UptimeBot. Можно по быстрому посмотреть на каких портах поддерживается TLS/STARTTLS. А также проверить DKIM, DMARC, SPF, Whois.

Сканеры открытых портов
Сканер IPv6. Сканирует на выбор либо только указанный порт, либо все часто используемые. В первом случае можно указать использовать TCP или UDP протокол.

Jabber
Тест jabber-сервера. Проверка jabber-сервера на наличие часто используемых функций.

IPv6
Тест IPv6. Тест доступности сервера по IPv6. Краткий, но доступный для понимания проблем отчет.

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

Черепашка. Если вы видите танцующую черепашку, то доступ к страницам, работающим по IPv6, у вас есть.

Скорость соединения
Speedtest. Всем известный ресурс проверки скорости соединения. Настолько известный, что почти все провайдеры так или иначе мухлюют при обращении клиента к этому сайту, чтобы он показал скорость выше той, что есть на самом деле.

Тест от Cloudflare. Не менее известный сервис проверки скорости соединения.

Общее
DNS Checker. Несмотря на название, это комплекс утилит для проверки почты, домена и т. д. В чем-то схож с MX Toolbox.

HSTS Preload. Сервис проверки на включение вашего сервера в список HSTS Preload. Это список серверов, при обращении к которым будет сразу использоваться HTTPS-соединение, минуя HTTP. На мой взгляд, сейчас не сильно актуально, потому все поголовно переходят на HTTPS. Там же находятся рекомендации по настройке сервера для последующего включения его в список. Если проверка прошла успешно, фон страницы станет зеленым. Эта настройка отображается в отчете SSL Labs.

Hardenize. Проверяет веб- и почтовый серверы. Выдает информацию по зоне, DNS-записям и настройкам. Среди проверяемых функций такие как: DNSSEC, CAA, MTA-STS, TLSRPT, SPF, DMARC, DANE, заголовки ответов и прочее. Выдает достаточно информативный отчет.

Immuniweb. Есть два неплохих теста: SSL и безопасности сайта. В первом проверяет настройки сервера на соответствие стандартам PCI DSS, HIPAA and NIST и Industry Best Practices. Второй проверяет GDPR Compliance, PCI DSS и заголовки ответов (куда же без них?).

internet.nl. Позволяет проверить настройки веб- и почтового серверов. Тестирует DNSSEC, IPv6, DANE, заголовки ответов и RPKI. Для меня лично новинкой стала проверка файла security.txt.

NetTools. Сборник самых различных тестов: почта, веб-сервер, сканер открытых портов, скорости соединения, NTP-сервера, DNS, FTP..

Security Headers. Проверяет заголовки ответов веб-сервера. Пройдя по ссылкам, можно попасть на блог Scott Helme и узнать как настроить тот или иной заголовок. Вообще в блоге много полезной информации. Единственный «минус» — всё на английском.

SSL Labs. Один из самых популярных сервисов тестирования веб-серверов. Проверяет сертификаты, используемые шифры, протоколы (HTTP, HTTP/2), совместимость с популярными браузерами, наличие уязвимостей и некоторых настроек (HSTS, OCSP, HPKP и другие). К сожалению, почту проверять не умеет.

Verisign анализатор. Быстрая проверка DNSSEC. Не могли что ли сделать шрифт покрупнее в отчете?

ZoneMaster. Проводит полную проверку вашего доменного имени.

Проверка STUN и TURN. Собственно весь функционал описан в названии. В случае корректной настройки STUN должен вернуть «srflx» в списке. В случае с TURN — «relay».

Тест DoH. Проверка работоспособности DNS-over-HTTPS от Cloudflare. Показывает «Yes» только в случае, если вы настроили DoH на их серверы. В противном случае стоит ориентироваться на ASN.

Тест утечки DNS. Отображает серверы, которым вы «доверяете» хранить и, возможно, использовать информацию о том, к каким серверам или сайтам вы подключаетесь.

Генераторы настроек
Генератор настроек SSL. Генератор настроек SSL от Mozilla для различных программ.

Генератор файла security.txt Удобная форма генератора security.txt.

Реклама
CheckAdBlock. Один из первых сайтов, который мне попался много лет назад, когда возникла мысль протестировать работу блокировщиков рекламы в браузере.

Связка nginx+Apache

Thu, 01 Sep 2016 14:47:22 +0700

Немного почитав про эту связку, пришел к выводу, что стоит попробовать ее использовать. Установил nginx, перенастроил Apache таким образом, чтобы он работал только локально, затем настроил nginx таким образом, чтобы он все запросы отдавал Apache. Потом еще некоторое время пришлось повозиться с настройками nginx, но вуаля! Я добился-таки того, что все сайты, на которых я проводил тестирование своего сервера, выдали мне оценку «А+». Итак, что из «плюсов» мы имеем:

— возросла скорость загрузки сайта;
— уменьшилась нагрузка на Apache;
— статические данные теперь отдает nginx, динамические — формирует Apache;
— остались все «плюшки» .htaccess;
— возросла безопасность сервера.

Из «минусов»:

— теперь на сервере у меня два веб-сервера.

Чуть позже попробую конфигурацию с «голым» nginx, если его работа меня устроит, то, скорее всего, полностью перейду на него. Теперь что касается безопасности сервера (ну да, у меня маленький бзик на этот счет).

В связи с тем, что nginx, в отличие от Apache, поддерживает наборы шифрования ECDHE, появилась возможность их использовать. Также он поддерживает OCSP stapling, что позволяет немного ускорить загрузку страниц при работе через HTTPS.

Тестирование проводилось при помощи трех сайтов: SSL Analyzer от Comodo, Free SSL Server Test от High-Tech Bridge, ну и конечно незабвенный SSL Server Test от лаборатории Qualys SSL.

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

Затем тест проводился при помощи High-Tech Bridge. По скорость он является более медленным, но проверяет чуть больше параметров. В том числе на соответствие требованиям NIST (американский институт стандартов и технологий) и стандарта PCI DSS. Здесь пришлось немного попотеть, разыскивая наборы шифрования, которые, по его мнению, должны быть включены в список.

И под конец проверка шла при помощи Qualys SSL. Он является самым медленным из указанного списка, но выдает результаты практически по всем параметрам. Здесь пришлось поработать над несколькими пунктами, но и тут была одержана победа.

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

— сервер работает только по протоколу TLS;
— слабые шифры удалены из списка;
— Perfect Forward Secrecy (PFS) работает со всеми более-менее новыми браузерами;
— поддерживаются HSTS и HPKP;
— поддерживается OCSP stapling;
— работает Content Security Policy;
— работает вся ранее настроенная в Apache защита от атак.

В общем все круто и я всем доволен :-) Кроме, разве что того момента, что теперь в этом плане мне делать нечего и скоро я опять начну скучать.

Защита сайта при помощи HTTP Public Key Pinning (HPKP)

Tue, 16 Aug 2016 22:24:24 +0700

Данная технология призвана защитить посетителя вашего сайта от атаки типа MITM (Man in the middle, человек посередине). Иными словами посетитель может быть уверен, что данные, которые он получает, исходят с вашего сайта, а не с какого-то другого.

Суть технологии состоит в создании публичного ключа на основе сертификата, который установлен на вашем сайте. Соответственно, чтобы она работала, требуется валидный сертификат. Впрочем, она будет работать и на самоподписанных (self-signed) сертификатах. Полученный на основе вашего сертификата ключ добавляется в заголовок ответа вашего сервера, после чего браузер сравнивает полученный ключ с тем, который он вычисляет после получения данных о вашем сертификате.

Итак, что нам требуется:

Какой-либо установленный для сайта сертификат.
Консоль для получения публичного ключа.

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

Действовал я по следующей схеме:

— получаем сертификат на сайте Let’s Encrypt для двух сайтов: example.com и www.example.com;
— так как я использую вариант без www, то ключ, полученный на базе первого будет основным, на базе второго — резервным;
— генерируем ключи для обоих сертификатов;
— добавляем нужные инструкции в файл /etc/httpd2/conf/sites-available/default-http.conf.

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

openssl x509 -noout -in certificate.pem -pubkey | openssl rsa -pubin -outform der | \

openssl dgst -sha256 -binary | base64

где certificate.pem — полный путь к сертфикату.

После выполнения команды вы получите нечто подобное:

LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=

Это и есть нужный вам ключ. Повторяем команду для второго сертификата и добавляем данные в файл конфигурации сайта:

Header set Public-Key-Pins "pin-sha256=\"pin1\"; pin-sha256=\"pin2\"; max-age=time"

где:

pin1 — основной ключ для данного сайта. В моем случае example.com;
pin2 — резервный ключ для сайта. То есть www.example.com;
time — время действия ключа в секундах.

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

Какие тут есть нюансы? Если вы неправильно настроите HPKP, ваш сайт станет недоступен. Можно также настроить отправку отчетов в случае каких-либо ошибок. Для этого немного меняем заголовок (или просто добавляем еще одной строкой):

Header set Public-Key-Pins-Report-Only "pin-sha256=\"pin1\"; pin-sha256=\"pin2\"; max-age=time"

Внедрение HTTP Strict Transport Security (HSTS) на свой сайт

Tue, 16 Aug 2016 11:56:05 +0700

Сначала небольшая выдержка из википедии:

«HSTS (сокр. от англ. HTTP Strict Transport Security) — механизм, активирующий форсированное защищённое соединение через протокол HTTPS. Данная политика безопасности позволяет сразу же устанавливать безопасное соединение, вместо использования HTTP-протокола. Механизм использует особый заголовок Strict-Transport-Security для принудительного использования браузером протокола HTTPS даже в случае перехода по ссылкам с явным указанием протокола HTTP. Механизм специфицирован в RFC6797 в ноябре 2012 года.

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

Дополнительную защиту https-соединений предоставляют методы Certificate pinning (хранение списка разрешенных для домена сертификатов или CA в исходных текстах браузера) и HTTP Public Key Pinning (англ.). Они предотвращают множество возможностей подмены tls-сертификатов https-сервера.»

Для внедрения этой технологии нам понадобится несколько вещей:

Наличие валидного сертификата (можно бесплатно получить на сайте Let’s Encrypt)
Уверенность в том, что будет использоваться только https протокол, включая все ваши субдомены.
Полное перенаправление с http-версий сайтов на https.

Если что-то из этого по каким-то причинам вам не подходит, то эта технология вам не нужна.

Так как у меня используется «старенький» Apache версии 2.2, то и настраивать, соответственно, мы будет его. Для включения HSTS нам нужно добавить в файл /etc/httpd2/conf/sites-available/default_https.conf следующие строки:

<IfModule ssl_module>
    <VirtualHost *:443>
        Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
   </VirtualHost>
</IfModule>

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

Инструкция Header set позволяет вставить заголовок в ответ сервера. В данном случае заголовок «Strict-Transport-Security». В скобках за ним расположены параметры этого заголовка:

max-age — время в секундах, которое будет действовать этот заголовок. Если быть точнее, то это время, в течение которого сайт будет доступен по протоколу HTTPS. Не рекомендуется устанавливать его менее 18 недель;

includeSubDomains — указывается, если действие заголовка распространяется также на поддомены. Не является обязательным;

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

Итак, данные мы добавили, теперь нужно перезагрузить файлы конфигурации:

# service httpd2 condreload

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

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Идем на сайт ssllabs, вводим адрес своего сайта с указанием https и тестируем, что у нас получилось. Тест занимает некоторое время, его вполне хватит на то, чтобы, например, налить себе чашечку кофе.

По итогу мы должны увидеть такие строчки:

Эту строчку вы увидите в шапке отчета

Эта будет находиться ближе к концу отчета

Если вы их видите, значит все в порядке. В противном случае ищите ошибку.

И, наконец, про параметр preload. Существует так называемый «preload list», в котором перечислены все домены, использующие технологию HSTS. Своего рода список «избранных» :-) При желании вы можете подать заявку на включение вашего домена в этот список, но на скорый ответ не рассчитывайте. Список обновляется с выпуском каждой версии браузера Chrome, поэтому может пройти несколько месяцев, прежде, чем вы увидите, что ваш домен добавлен в него. Для подачи заявки нужно выполнить несколько требований, указанных на главной странице сайта, поэтому рекомендую прочитать ее внимательно. Значение имеет даже регистр параметров заголовка. В случае критической ошибки после нажатия на кнопку «Check status and eligibility» фон страницы станет красным, в случае некритической — желтым, если же все верно — зеленым. На этой же странице указано, что нужно делать, чтобы удалить свой домен из этого списка.

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