Понимание захвата поддоменов: Практическое руководство для SEO-специалистов
Перехват поддоменов — не самая распространенная тема в SEO-обсуждениях, однако он может оказывать прямое и пагубное влияние на ранжирование. В этой статье я рассказываю о своем личном опыте в этой области, а также о том, как я теперь проверяю уязвимые поддомены во время технического аудита.
Краткая предыстория
Вскоре после того, как я перешел с должности SEO-специалиста на чисто техническую должность, я получил страшное уведомление в Search Console:
«Применено ручное действие — обнаружен взломанный контент»
Помеченный URL был забытой праздничной акцией, размещенной на christmas.client.co.uk. Мой менеджер понятия не имел, что это такое, да и я тоже. После некоторых раскопок (и неистового гугления) я понял, что это был старый поддомен кампании, оставленный на произвол судьбы. С тех пор он был использован кем-то другим для размещения спамерского контента.
К счастью, клиент оказался отзывчивым и технически подкованным, и мы смогли устранить проблему в течение нескольких часов. Но этот инцидент заставил меня задуматься: сколько еще заброшенных поддоменов может скрываться незамеченными, готовыми к захвату?
Что произошло на самом деле
Захват поддомена происходит, когда DNS-запись указывает на сторонний сервис (например, GitHub Pages, Heroku, AWS и т. д.), который больше не используется, но DNS-запись все еще существует.
Злоумышленник может воспользоваться заброшенным ресурсом на этой платформе и мгновенно разместить свой собственный контент на вашем поддомене.
В моем случае старый микросайт «адвент-календарь» активно продвигался несколько лет назад. Когда он был заброшен, DNS остался активным, что создало возможность для эксплуатации. Угонщик воспользовался существующим авторитетом поддомена и обратными ссылками, использовав его для рекламы сайта казино.
Это далеко не редкость. От подобных инцидентов пострадали правительственные порталы, крупные бренды и даже высокоавторитетные сайты, которым модели искусственного интеллекта часто доверяют вслепую.
Почему SEO-специалистам стоит беспокоиться
От вас не ждут, что вы станете специалистом по кибербезопасности. Но взломанные поддомены могут спровоцировать ручные действия, передать полномочия вредоносным сайтам и свести на нет месяцы и годы работы по оптимизации. Многие уязвимости возникают в старых проектах, о настройке которых никто не помнит.
Google во многом рассматривает поддомены как отдельные объекты, однако ссылки между ними все равно могут передавать авторитет. Если заброшенный поддомен взломан, а ваш основной сайт ссылается на него, вы, по сути, ручаетесь за контент злоумышленника. Именно поэтому периодическая проверка поддоменов должна стать частью вашего технического аудита.
Процесс расследования
Обнаружение существующих поддоменов
Используйте такие инструменты, как ViewDNS или DNSDumpster. Помните о лимитах поиска; если у клиента десятки или сотни поддоменов, стоит обратить внимание на возможность наличия устаревших или неиспользуемых активов.
Определите хостинговые платформы
Проверьте хостинг с помощью таких инструментов, как WhatCMS или команда dig от Google. Кроме того, избегайте прямого перехода по скомпрометированной ссылке.
Оцените уязвимость
Сравните хостинговые платформы с известными сервисами, подверженными захвату, такими как AWS (Elastic Beanstalk/S3), GitHub Pages, Heroku, Shopify, Ghost, Microsoft Azure, Agile CRM, WordPress.com и сервисы JetBrains. Используйте ViewDNS для поиска поддоменов, Wappalyzer для их профилирования и сопоставьте результаты с общедоступными списками уязвимостей.
Если вы нашли уязвимый поддомен
Если он связан с одной из платформ высокого риска и не используется (или планируется к закрытию), скоординируйте свои действия с тем, кто управляет DNS, чтобы удалить или перенаправить запись. Хотя SEO-специалисты не несут прямой ответственности за конфигурацию серверов, информирование заинтересованных сторон о последствиях для безопасности и SEO часто помогает придать проблеме приоритетное значение.
Я не тестировщик на проникновение — просто технический SEO-специалист, который сталкивался с этим достаточно раз, чтобы понять ценность проактивных проверок. Включение этого шага в аудит может избавить от головной боли впоследствии.
Пример из реального мира: EY.com
Недавний пример, которым поделился Майкл Кертис на LinkedIn, касался поддомена EY, размещенного через Microsoft Azure. Ресурс Azure был удален, но DNS-запись осталась.
Злоумышленник зарегистрировал новое приложение Azure с тем же именем хоста, которое ранее использовалось поддоменом EY. Поскольку DNS по-прежнему указывал на него, он смог обслуживать явный контент в доверенном домене EY.
Это не «взлом» в традиционном смысле, а оппортунистическое использование заброшенных записей DNS. Злоумышленники не взламывали внутренние системы; они просто присвоили себе незащищенное имя и унаследовали трафик и доверие, которые к нему прилагались.
