Домены – неочевидные опасности для инфраструктуры
Многие администраторы придерживаются принципа, что имя узла должно отражать его роль. Это распространенная практика и в том или ином виде используется многими, в том числе и автором этого канала.
Действительно, просто и понятно:
SRV-DC01
SRV-SMB01
UBNT-GW01
VPN-WG02
Подобный подход перешел и на доменные имена или, как их чаще называют, поддомены. Система плюс-минус та же:
mail.example.com
ftp.example.com
rdp.example.com
share.eample.com
Легко понять, легко запомнить, легко продиктовать, при необходимости. Долгое время такая схема не вызывала проблем, до тех пор, пока не случился массовый переход на защищенные соединения.
Сегодня TLS-защита и валидный сертификат от внешнего CA являются нормой жизни, но они же несут в себе новые угрозы, достаточно неочевидные.
Дело в том, что как только вы хотя бы один раз получите сертификат для своего доменного имени, то любой желающий легко и просто сможет получить его и все остальные поддомены вашего домена простым запросом.
И это не утечка, и не уязвимость. Для прозрачности деятельности и повышения безопасности управления сертификатами все серьезные CA (включая СА Минцифры) поддерживают и ведут публичные Certificate Transparency логи, куда вносят все выданные сертификаты.
Это хорошо для безопасности сертификатов и пользователей, так как можно всегда проконтролировать кто, где и когда выпускал сертификаты для домена. Но это может быть очень плохо в плане раскрытия информации об инфраструктуре.
Любой праздношатающийся легко и непринужденно получает полный список ваших ресурсов, даже если они находятся на разных площадках и у разных провайдеров.
Далее ему сразу становится понятно назначение многих узлов. Т.е. больше ему не нужно угадывать, что скрывается за тем или иным узлом, все и так написано в доменном имени. Это уменьшает активность злоумышленника, а следовательно, уменьшает шансы заметить и пресечь ее еще на раннем этапе.
А сам злоумышленник может сразу выделить интересующие его узлы инфраструктуры и сосредоточить на них свое внимание, не распыляясь на все подряд.
Кроме того, сами администраторы порой добровольно дают хорошие подсказки. Скажем у нас уже есть узел терминального сервера, теперь мы решили ввести второй. Да что там думать, давай сделаем так:
rdp.example.com
rdp22.example.com
или
rdp2022.example.com
Даже если это число обозначает просто год, то уже дает намек на то, что на другом сервере стоит более старая версия ПО, что уже делает его приоритетным. Ну а если мы видим такое, то тут и думать ничего не надо (реальный пример, между прочим):
rdp2008.example.com
rdp2012.example.com
rdp2016.example.com
Подобный подход именования сервисов равносилен тому, что вы нарисовали и публично опубликовали схему свой инфраструктуры, но при этом продолжаете замазывать белые IP на скриншотах.
Как быть, что делать? Ну в крайности впадать тоже не стоит, совершенно абстрактные имена доменов также неудобны и приводят к сложностям и хаосу. Попробуйте без дополнительных записей поймите кто здесь есть кто?
p4sssic.example.com
3f1f9b6.example.com
tafcbbd.example.com
То-то же… В тоже время в мире есть много простых и запоминающихся взаимосвязанный некоторой общностью наборов слов, которые можно использовать в качестве доменных имен.
Вы можете даже построить некоторую систему, которая будет понятна только вам, но не раскроет лишней информации злоумышленнику. Женские имена, цвета, буквы греческого алфавита, животные, породы собак, кошек, планеты, звезды и т.д. и т.п.
Попробуйте догадаться, что стоит за каждым сервисом:
red.example.com
yellow.example.com
green.example.com
Их столь же просто запомнить, легко понять, легко продиктовать… Но они не раскрывают никакой дополнительной информации о вашей инфраструктуре.
