Здравствуйте, товарищи!
Хочу поделиться одной особенностью процесса генерации сертификатов при помощи Let’s Encrypt, которую я недавно обнаружил и о которой раньше не знал.
Для начала немного предыстории. У меня есть арендованный VPS, который служит точкой входа из публичного интернета на домашние сервисы. Все сервисы персональные, никто кроме меня ими не пользуется. Для них куплен домен, который через wildcard указывает на мой сервер.
На сервере развернут NPM Plus, в котором настроены несколько Proxy Hosts, которые перенаправляют траффик домой в соответствующие контейнеры. При этом все Proxy Hosts настроены как субдомены, т.е. условного example.com у меня нигде нет, а все сервисы настроены как service1.example.com, service2.example.com и т.д. Сделал я это специально, чтобы условный хакер, пришедший на example.com по DNS, попал бы в никуда, и чтобы что-то сделать, ему бы приходилось еще и угадывать названия субдоменов.
Для каждого из Proxy Hosts также настроен выпуск своего сертификата в Let’s Encrypt.
До недавнего времени все было хорошо и в логах nginx я наблюдал примерно такие запросы от всяких сканнеров:
x.x.x.x:80 93.123.72.183 0.000 "GET /SDK/webLanguage HTTP/1.1" 444 0 0 - Mozilla/5.0
Т.е. в качестве заголовка Host они присылали IP моего сервера (x.x.x.x), а не доменное имя. Однако недавно увидел в логах уже что-то вот такое:
service1.example.com:443 93.123.72.183 0.000 "GET /SDK/webLanguage HTTP/1.1" 444 0 0 - Mozilla/5.0
Т.е. злоумышленник прислал уже доменное имя, и не абы какое, а именно то, которое я настроил в NPM!
Я был абсолютно уверен, что сам нигде не светил эти субдомены. Стал копать в сторону проблем на стороне Let’s Encrypt и обнаружил следующее.
Оказывается, существует такая штука как Certificate Transparency Logs, и многие сертификационные центры, в том числе и Let’s Encrypt, публикуют туда данные обо всех сертификатах, которые они выдают. Вот они сами об этом пишут: Журналы Certificate Transparency (CT) - Что такое Let's Encrypt.
Логи эти публичные, и нужны для того, чтобы любой желающий мог дополнительно проверить подлинность полученного от хоста сертификата. Наиболее вероятно, что злоумышленники их тоже читают, получая информацию о внутренней структуре сервисов за доменным именем, т.е. дополнительную информацию для атаки.
Вот такие дела. Если вы так же, как и я, решили добавить для своих публичных сервисов дополнительный слой защиты в виде размещения их в “секретных” субдоменах, то не выпускайте для них сертификаты через “certbot-HTTP”, иначе информация о ваших субдоменах будет абсолютно легально слита. Рассмотрите вместо этого возможность выпуска wildcard-сертификатов через DNS challenge, тогда в логи улетит что-то типа *.example.com, что гораздо лучше. Я пока что так и сделал. Хотя информация уже слита, я все равно ожидаю, что через какое-то время атаки на меня через правильные субдомены прекратятся: должны же они когда-то протухать.
Такие дела. Надеюсь, эта информация кому-то поможет.