На IP сервера смотрят домены, о которых вы не знали: что с ними делать

MAATRIX

Вы проверяете, кто смотрит на IP вашего сервера снаружи — и в списке оказывается домен, который вы никогда не регистрировали, не настраивали и даже не слышали о нём. Это не глюк сервиса и не ошибка проверки: A-запись в чужой DNS-зоне может указывать на ваш IP без вашего участия и без вашего ведома — для этого не нужно ничего менять на вашей стороне. Разберём, как искать такие домены через обратный DNS-поиск и passive DNS, почему этот список почти никогда не совпадает со списком доменов, настроенных на самом сервере, и что делать с каждой находкой — от безобидной до откровенно опасной.

Откуда на вашем IP чужие домены

Ключевой факт, который многие узнают только столкнувшись с ним: чтобы направить домен на чужой IP, не требуется никакого разрешения владельца этого IP. A-запись — это строка в чужой DNS-зоне, которую полностью контролирует владелец домена. Он вписывает туда любой IP-адрес, который знает, и с этого момента запросы браузеров к этому домену теоретически идут на указанный сервер — независимо от того, готов сервер их принять или нет. Отсюда несколько типичных сценариев, почему на вашем IP оказываются домены, к которым вы не имеете отношения.

Переиспользованный IP-адрес. У большинства облачных провайдеров и VPS-хостингов IP-адреса — это общий пул. Когда клиент отказывается от сервера, его адрес через какое-то время возвращается в пул и выдаётся следующему арендатору — то есть вам. Если предыдущий владелец не почистил свои DNS-записи (а он может об этом даже не вспомнить — сервер давно выключен, зачем думать о домене), эти записи продолжают указывать на IP, который на самом деле сейчас работает у вас. Это самый частый и самый безобидный источник «чужих» доменов на новом сервере.

Небрежность стороннего владельца домена. Кто-то когда-то арендовал у того же провайдера сервер с этим IP, настроил A-запись, потом перенёс проект в другое место, но забыл обновить DNS. Или скопировал IP из старого письма, старой инструкции, черновика конфига — и вписал его в свою зону по ошибке, даже не будучи с вами связанным.

Целенаправленное указание домена на ваш IP. Это уже другой уровень: кто-то — например, оператор фишинговой или мошеннической схемы — узнаёт ваш IP (он публичен, узнать его не проблема) и намеренно прописывает свой домен на него. Расчёт может быть на то, что сервер случайно ответит содержимым по умолчанию и создаст видимость легитимности, либо это просто отвлекающий след при разборе инцидента. Технически на самом сервере при этом ничего не происходит, но запись в публичном DNS существует и видна всем, кто умеет её искать.

Разграничение с похожей темой: если вы разбираете унаследованный сервер и ищете сайты, физически настроенные на нём — конфиги nginx, каталоги, поддомены, — это отдельная задача, разобранная в статье «Сколько сайтов на этой машине: ищем проекты, о которых вам не сказали». Здесь мы идём в обратную сторону: не «что настроено на сервере», а «что смотрит на сервер снаружи» — и это два пересекающихся, но не тождественных списка.

Как искать: reverse DNS и passive DNS

Прямого запроса «дай мне все домены, у которых A-запись указывает на IP X» в стандартном DNS не существует — эта информация не хранится централизованно и не раздаётся никаким официальным протоколом. Есть два обходных подхода, и оба дают частичную картину, которую стоит комбинировать.

PTR-запись (обратный DNS) — это единственный «официальный» способ спросить у DNS «что это за IP», но он возвращает максимум одно имя, и это имя обычно назначает хостинг-провайдер (что-то вроде vps-1234.provider.net), а не реальный владелец сайта:

dig -x 203.0.113.10 +short

Для наших целей PTR почти бесполезен — он скажет, кто провайдер, но не покажет ни одного из доменов клиентов.

Reverse IP lookup сервисы собирают домены, чей A-record указывает на конкретный IP, сканируя массивы DNS-записей. Бесплатный пример с ограничением по частоте запросов:

curl -s "https://api.hackertarget.com/reverseiplookup/?q=203.0.113.10"

Результат — список доменов, у кого-то он будет пустым (если IP «чистый» или сервис его ещё не просканировал), у кого-то — из нескольких десятков строк. Учитывайте: бесплатные лимиты таких API невелики, и один запрос в сутки-другие — разумная частота для регулярной проверки, а не для многократных повторов.

Passive DNS сервисы хранят историю резолвинга — какие домены когда-либо указывали на IP, даже если сейчас уже не указывают. Это шире, чем снимок «прямо сейчас», но именно поэтому там будет много устаревших записей. У SecurityTrails и аналогичных сервисов есть бесплатный уровень с API-ключом и ограниченным числом запросов в месяц — для разовой или квартальной проверки этого обычно достаточно.

Certificate Transparency как косвенный источник. Если для домена когда-либо выпускали TLS-сертификат, где в SAN фигурирует ваш IP, это иногда всплывает в CT-логах, хотя индексация по IP на crt.sh работает не для всех адресов одинаково надёжно:

curl -s "https://crt.sh/?q=203.0.113.10&output=json" | head -c 2000

Shodan и подобные сканеры интернета индексируют хосты по IP и иногда показывают связанные hostname в карточке адреса (shodan.io/host/203.0.113.10) — бесплатного аккаунта хватает для единичных просмотров без API-автоматизации.

Ни один из источников не даёт исчерпывающего и мгновенно актуального списка — это кандидаты для дальнейшей проверки, а не готовый реестр. Разумная практика — прогнать IP через два-три источника и объединить результаты.

Почему этот список не совпадает со списком vhosts на сервере

Здесь важно не путать две принципиально разные вещи. Список доменов, найденный через reverse DNS и passive DNS, — это то, что *указывает* на ваш IP снаружи. Список server_name в конфигах nginx (или ServerName/ServerAlias в Apache) — это то, что сервер реально *готов обслужить*. Пересечение между ними может быть неполным в обе стороны, и на это есть три технические причины.

Во-первых, passive DNS показывает историю, а не текущее состояние. Домен мог указывать на ваш IP два года назад, потом его владелец сменил хостинг, а запись в базе сервиса осталась — вы увидите домен в выдаче, хотя сейчас его A-запись ведёт совсем в другое место. Проверить актуальность легко:

for domain in found1.com found2.ru found3.net; do
  echo -n "$domain: "; dig +short A "$domain"
done

Если возвращённый IP не совпадает с вашим — запись устарела, и в самой DNS-зоне домена её уже нет, беспокоиться не о чем.

Во-вторых, даже если A-запись домена реально указывает на ваш IP прямо сейчас, это не значит, что ваш сервер что-то ему ответит. Если в конфиге веб-сервера нет блока с подходящим server_name, запрос падает на блок по умолчанию (default_server) — и там либо стоит явный отказ, либо, что хуже, тот же контент, что и на основном сайте сервера, потому что первый server блок в конфиге негласно стал дефолтным. Проверить, что сервер реально отдаёт по конкретному домену, можно напрямую, минуя резолвинг:

curl -sI -H "Host: found-domain.com" http://203.0.113.10/

Код ответа и содержимое покажут, служит ли сервер этому домену на самом деле, или запрос просто проваливается в дефолт.

В-третьих, работает и обратная ситуация: домен из вашего собственного портфеля может использовать CDN или прокси (Cloudflare, другой edge-провайдер) перед сервером — тогда публичная A-запись указывает на IP CDN, а не на ваш, и reverse-lookup сервисы его в связке с вашим адресом не найдут вовсе, хотя фактически домен ваш и работает через ваш сервер как origin.

Как классифицировать находку

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

1. Сверьте со своим реестром доменов. Если у вас ведётся список доменов и сертификатов компании — это первая и самая быстрая проверка. Нашли совпадение — вопрос закрыт, это ваш.
2. Проверьте WHOIS/RDAP найденного домена. Дата регистрации, регистратор, иногда организация — даже с учётом того, что личные данные владельца сейчас почти везде скрыты редактором приватности, дата создания домена и история изменений часто дают зацепку (совсем новый домен с непонятным именем — повод насторожиться сильнее, чем домен, зарегистрированный пять лет назад).
3. Проверьте, что реально отдаёт сервер по этому домену — командой curl -H "Host: ...", показанной выше. Если ответ 444/403/заглушка — сервер этот домен не обслуживает, риска утечки данных нет.
4. Проверьте логи веб-сервера на реальные запросы с этим Host-заголовком за последние недели:

grep "found-domain.com" /var/log/nginx/access.log* | awk '{print $1, $7}' | sort -u | head -20

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

1. Откройте сам домен через curl (curl -sI https://found-domain.com/) и сравните с ответом напрямую по IP — иногда впереди стоит CDN, и реальный контент отдаёт не ваш сервер, хотя A-запись формально указывает на вас.

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

Что делать в каждом случае

Свой или клиентский домен, который просто не задокументирован — самый простой случай: внесите его в реестр доменов и сертификатов, при необходимости приведите конфиг server_name в соответствие с реальностью, если сервер уже отдаёт по нему контент, но блок настроен небрежно (например, через дефолтный catch-all вместо явного имени).

Забытая чужая запись без реального трафика на ваш сервер. Если проверка показала, что сервер по этому домену ничего не отдаёт (444, отказ, дефолтный ответ без содержимого), с вашей стороны рисков нет — вы физически не размещаете чужой контент. Вы не обязаны и, строго говоря, не в состоянии починить чужую DNS-зону — это не ваша запись и не в вашей власти её удалить. Разумный минимум — убедиться, что дефолтный блок сервера явно отклоняет неизвестные Host-заголовки, а не тихо показывает содержимое основного сайта:

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;
    return 444;
}

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

Подозрительный или откровенно вредоносный домен. Если находка похожа на фишинг (домен маскируется под известный бренд, свежая регистрация, при прямом обращении — форма ввода данных карты или логина), важно понимать границы своей ответственности. Технически, если ваш сервер не отдаёт по этому домену никакого контента (нет server_name, дефолт отвечает 444), вы не размещаете фишинговую страницу — реальный контент, скорее всего, крутится на другом сервере злоумышленника, а его домен просто «засветился» в вашем IP как отвлекающий след. Полномочий снять чужую A-запись у вас нет — это не ваша зона. Практично: сохранить лог-выдержку, подтверждающую, что сервер не отвечает по этому домену (пригодится в разборе, если кто-то со стороны решит выяснять, почему домен резолвится на ваш IP), и по желанию сообщить о находке в абузу регистратора домена или хостинга, где реально размещён вредоносный контент — но это жест доброй воли, а не обязанность.

Постоянный мониторинг и защита репутации IP

Разовая проверка честна ровно до следующего изменения — чужие домены появляются и исчезают из выдачи reverse DNS без вашего участия, и единственный способ не пропустить новую подозрительную запись — сделать проверку регулярной, а не разовой акцией после того, как что-то уже пошло не так.

Практический минимум — повторять проверку через reverse IP lookup и passive DNS раз в квартал, и обязательно сразу после получения нового IP-адреса при аренде сервера (особенно у облачных провайдеров с переиспользуемым пулом адресов) — именно в этот момент выше всего шанс унаследовать чужой «хвост» записей от предыдущего владельца. Если вы уже ведёте регулярный контроль сертификатов и доменов компании, логично объединить эту проверку с тем же циклом — подробнее об организации такого регламента в статье «Мониторинг сертификатов и доменов».

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

Если у сервера уже есть общий документ-паспорт с описанием инфраструктуры, логичнее не заводить отдельный файл под этот регламент, а добавить туда раздел с последней датой проверки reverse DNS и списком известных «чужих, но безопасных» записей — подробнее о таком документе в статье «Паспорт сервера: одна страница вместо памяти админа». А если сервер и вовсе выключается и IP возвращается провайдеру — учитывайте, что вы сами становитесь тем «предыдущим владельцем», чьи забытые записи могут спутать следующего арендатора: как правильно закрывать домен и хостинг при завершении проекта, разобрано в статье «Выключили сервер и забыли про домен: что происходит с ним дальше».

Частые вопросы