Zrozumienie przejmowania subdomen: Praktyczny przewodnik dla SEO

Przechwytywanie subdomen nie jest częstym tematem w dyskusjach SEO, ale może mieć bezpośredni i szkodliwy wpływ na rankingi. W tym wpisie dzielę się własnymi doświadczeniami w tej kwestii, a także procesem, który teraz stosuję, aby sprawdzić podatne subdomeny podczas audytów technicznych.

Krótkie wprowadzenie

Niedługo po przejściu z ogólnej roli SEO na stanowisko czysto techniczne, otrzymałem przerażające powiadomienie w Search Console:

„Zastosowano ręczne działanie – wykryto zhakowaną zawartość”

Oflagowanym adresem URL była zapomniana promocja świąteczna hostowana pod adresem christmas.client.co.uk. Mój menedżer nie miał pojęcia, co to było, podobnie jak ja. Po kilku poszukiwaniach (i odrobinie gorączkowego Googlowania) zdałem sobie sprawę, że była to stara subdomena kampanii pozostawiona do rozpadu. Od tego czasu została ona zmieniona przez kogoś innego w celu umieszczania spamerskich treści.

Na szczęście klient był responsywny i obeznany technicznie, a my byliśmy w stanie usunąć problem w ciągu kilku godzin. Ale ten incydent sprawił, że zacząłem się zastanawiać: ile innych zaniedbanych subdomen może czaić się niezauważonych, gotowych do przejęcia?

Co się właściwie stało

Przejęcie subdomeny ma miejsce, gdy rekord DNS wskazuje na usługę innej firmy (np. GitHub Pages, Heroku, AWS itp.) i usługa ta nie jest już używana, ale wpis DNS nadal istnieje.

Atakujący może przejąć porzucony zasób na tej platformie i natychmiast udostępnić własną zawartość w subdomenie.

W moim przypadku stara mikrowitryna „kalendarza adwentowego” była mocno promowana wiele lat wcześniej. Kiedy została porzucona, DNS pozostał aktywny, tworząc okazję do wykorzystania. Porywacz wykorzystał istniejący autorytet subdomeny i linki zwrotne, używając jej do reklamowania strony kasyna.

Nie jest to rzadkie zjawisko. Podobne incydenty dotknęły portale rządowe, duże marki, a nawet witryny o wysokim autorytecie, którym modele AI często ślepo ufają.

Dlaczego SEO powinno się tym przejmować

Nie oczekuje się, że będziesz specjalistą od cyberbezpieczeństwa. Jednak zagrożone subdomeny mogą wyzwalać ręczne działania, przekazywać uprawnienia złośliwym witrynom i cofać miesiące lub lata pracy nad optymalizacją. Wiele luk w zabezpieczeniach pochodzi ze starszych projektów, których konfiguracji nikt nie pamięta.

Google traktuje subdomeny jako oddzielne właściwości pod wieloma względami, ale linki między nimi mogą nadal przekazywać uprawnienia. Jeśli zaniedbana subdomena zostanie zhakowana, a Twoja główna witryna będzie do niej linkować, zasadniczo ręczysz za treść atakującego. Właśnie dlatego okresowe kontrole subdomen powinny być częścią rutynowego audytu technicznego.

Proces dochodzenia

Odkryj istniejące subdomeny

Użyj narzędzi takich jak ViewDNS lub DNSDumpster. Należy pamiętać o limitach wyszukiwania; jeśli klient ma dziesiątki lub setki subdomen, warto oznaczyć potencjał starszych lub nieużywanych zasobów.

Identyfikacja platform hostingowych

Sprawdź hosting za pomocą narzędzi takich jak WhatCMS lub polecenie dig Google. Unikaj też bezpośredniego odwiedzania zagrożonych linków.

Ocena podatności na ataki

Porównaj platformy hostingowe ze znanymi usługami podatnymi na przejęcia, takimi jak AWS (Elastic Beanstalk/S3), GitHub Pages, Heroku, Shopify, Ghost, Microsoft Azure, Agile CRM, WordPress.com i usługi JetBrains. Użyj ViewDNS, aby znaleźć subdomeny, Wappalyzer, aby je profilować i dopasować wyniki do publicznie dostępnych list podatności.

Jeśli znajdziesz podatną subdomenę

Jeśli jest powiązana z jedną z platform wysokiego ryzyka i jest nieużywana (lub planowana do wyłączenia), należy skoordynować z kimkolwiek, kto zarządza DNS, aby usunąć lub przekierować rekord. Chociaż SEO nie są bezpośrednio odpowiedzialni za konfiguracje serwerów, uświadomienie interesariuszom zarówno konsekwencji dla bezpieczeństwa, jak i SEO często pomaga nadać priorytet tej kwestii.

Nie jestem testerem penetracyjnym – tylko technicznym SEO, który spotkał się z tym wystarczająco wiele razy, aby dostrzec wartość proaktywnych kontroli. Uwzględnienie tego kroku w audytach może zaoszczędzić późniejszych bólów głowy.

Przykład z życia wzięty: EY.com

Niedawny przykład, udostępniony przez Michaela Curtisa na LinkedIn, dotyczył subdomeny EY hostowanej przez Microsoft Azure. Zasób Azure został usunięty, ale wpis DNS pozostał.

Atakujący zarejestrował nową aplikację Azure z tą samą nazwą hosta, która była wcześniej używana przez subdomenę EY. Ponieważ DNS nadal tam wskazywał, był w stanie obsługiwać treści jawne w zaufanej domenie EY.

Nie jest to „włamanie” w tradycyjnym sensie, ale oportunistyczne wykorzystanie porzuconych wpisów DNS. Atakujący nie naruszył wewnętrznych systemów; po prostu przejął niezabezpieczoną nazwę i odziedziczył związany z nią ruch i zaufanie.