Розуміння поглинання субдоменів: Практичний посібник для SEO-спеціалістів
Захоплення субдоменів не є поширеною темою в обговореннях SEO, проте воно може мати прямий і шкідливий вплив на ранжування. У цій статті я ділюся власним досвідом вирішення цієї проблеми, а також процесом, якого я дотримуюся для перевірки вразливих субдоменів під час технічного аудиту.
Коротка довідка
Незабаром після того, як я перейшов із загальної ролі SEO на суто технічну позицію, я отримав жахливе сповіщення в Search Console:
“Застосовано ручну дію – виявлено зламаний вміст”
Відмічена URL-адреса була забутою святковою акцією, розміщеною на christmas.client.co.uk. Мій менеджер поняття не мав, що це таке, як і я. Після деяких пошуків (і трохи несамовитого гугління) я зрозумів, що це був старий субдомен кампанії, який залишили занепадати. З тих пір він був перепрофільований кимось іншим для просування спам-контенту.
На щастя, клієнт виявився чуйним і технічно підкованим, і ми змогли усунути проблему протягом кількох годин. Але цей інцидент змусив мене замислитися: скільки інших занедбаних субдоменів можуть ховатися непоміченими, готовими до поглинання?
Що насправді сталося
Захоплення субдомену відбувається, коли DNS-запис вказує на сторонній сервіс (наприклад, GitHub Pages, Heroku, AWS тощо), і цей сервіс більше не використовується, але DNS-запис все ще існує.
Зловмисник може претендувати на покинутий ресурс на цій платформі і миттєво розмістити свій власний контент під вашим субдоменом.
У моєму випадку, старий мікросайт “адвент-календар” був сильно розкручений роками раніше. Коли його закрили, DNS залишився активним, що створило можливість для експлуатації. Викрадач скористався наявним авторитетом і зворотними посиланнями субдомену, використавши його для реклами сайту казино.
Це далеко не рідкісний випадок. Подібні інциденти траплялися з урядовими порталами, великими брендами і навіть сайтами з високим авторитетом, яким ШІ-моделі часто сліпо довіряють.
Чому це має хвилювати SEO-спеціалістів
Від вас не очікують, що ви будете фахівцем з кібербезпеки. Але скомпрометовані субдомени можуть спровокувати ручні дії, передати повноваження шкідливим сайтам і звести нанівець місяці або роки роботи над оптимізацією. Багато вразливостей походять від застарілих проектів, про створення яких ніхто не пам’ятає.
Google багато в чому розглядає субдомени як окремі об’єкти, але посилання між ними все одно можуть передавати повноваження. Якщо зламають занедбаний субдомен і ваш основний сайт посилається на нього, ви, по суті, ручаєтесь за контент зловмисника. Ось чому періодичні перевірки субдоменів повинні бути частиною вашого технічного аудиту.
Процес розслідування
Знайдіть наявні субдомени
Використовуйте такі інструменти, як ViewDNS або DNSDumpster. Пам’ятайте про обмеження пошуку; якщо клієнт має десятки або сотні субдоменів, варто позначити потенційні застарілі або невикористовувані ресурси.
Визначте платформи хостингу
Перевірте хостинг за допомогою таких інструментів, як WhatCMS або Google’s dig command. Також не переходьте за скомпрометованим посиланням напряму.
Оцініть вразливість
Порівняйте хостингові платформи з відомими сервісами, схильними до поглинання, такими як 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. Зловмисник не порушував внутрішні системи; він просто претендував на незахищене ім’я і успадкував трафік і довіру, які з ним пов’язані.
