Sådan stopper du bots og skrabere fra at spise din båndbredde
En overraskende del af din trafik er robotter, og ikke den gode slags. Sådan spotter du skraberne, der spiser din båndbredde, fortæller dem bortset fra Google og lukker dem ude ved kanten.
Her er en ting, der sker for næsten alle voksende websteder. Du åbner dine analyser, ser et sundt trafiknummer og føler dig godt tilpas. Derefter åbner du dine rå serverlogs - dem analytics viser dig aldrig, fordi scrapere ikke kører JavaScript og derfor aldrig vises i Google Analytics overhovedet - og finder ud af, at et enkelt IP-interval har anmodet om din hele produktkataloget fire gange i denne uge, i alfabetisk rækkefølge, klokken tre om morgenen.
Det er en skraber. Det har ikke bidraget med noget, det har kostet dig båndbredde, og hvis dine priser er på disse sider, kender den dem nu.
Instinktet på dette tidspunkt er at blokere alt, hvad der ikke er et menneske. Gør det ikke: du ville tage Googlebot med det, og at miste din søgetrafik er et langt dyrere problem end den båndbredde, du forsøgte at spare. Du vil have en dørmand, ikke en væg.
Sortering af de bots, du har brug for, fra dem, du ikke har
Bots til at holde
- Googlebot, Bingbot – det er derfor, folk finder dig
- Overvågning af oppetid og ydeevne, som du har konfigureret
- Henter forhåndsvisning af links til Slack, WhatsApp og sociale platforme
- Betalings- og webhook-tilbagekaldelser fra tjenester, du bruger
Bots til at stoppe
- Pris- og indholdsskrabere, der kopierer dit katalog
- Afspilning af stjålne logins med legitimationsoplysninger
- Sårbarhedsscannere, der undersøger kendte udnyttelser
- Spambots, der hamrer formularer og kommenterer slutpunkter
Der er en tredje kategori, der er vokset meget på det seneste, og som ikke passer perfekt ind i nogen af kolonnerne: AI-træningscrawlere. Uanset om du vil have dem, er det en forretningsmæssig beslutning snarere end en sikkerhed, og det er værd at gøre bevidst snarere end ved et uheld. De fleste af dem respekterer robots.txt, og de fleste udgiver de brugeragentstrenge, de bruger, så et par linjer i robots.txt håndterer de velopdragne. Dem, der ignorerer robots.txt, er pr. definition i den anden kolonne.
At spotte de dårlige
Den kritiske regel er, at du identificerer robotter ud fra adfærd, ikke ud fra, hvad de hævder at være. En brugeragentstreng er et tekstfelt, som klienten udfylder; en skraber, der siger, at det er Chrome på macOS, koster forfatteren omkring fire sekunders indsats.
Adfærd er meget sværere at forfalske, fordi forfalskning betyder at være langsommere og dyrere, hvilket besejrer skrabningspunktet.
Umenneskelige anmodningshastigheder og rytme
En person indlæser ikke 60 produktsider på fire sekunder. De indlæses heller ikke nøjagtigt med intervaller på 250 millisekunder i seks timer. Mennesker er uregelmæssige; manuskripter er metronomer.
Kun HTML, ingen af møblerne
En browser, der indlæser en side, henter også CSS, skrifttyperne og billederne. En scraper vil have HTML og intet andet. En klient, der anmoder om tusind sider og nul stilark, er ikke en browser.
Påberåbt identitet, der ikke bekræfter
Googlebot offentliggør sine IP-områder, og et omvendt DNS-opslag på en rigtig Googlebot IP løser til googlebot.com og fremadrettet løser tilbage. Alt, hvad der hævder at være Googlebot fra en forbruger-VPS-udbyder, lyver.
Mekaniske URL-mønstre
Gå fra top til bund med dit sitemap eller gentage produkt-id'er sekventielt eller anmode om stier, der kun findes i en sårbarhedsscanners ordliste.
Trafik fra hostingområder, der aldrig konverterer
Rigtige kunder browse fra bolig- og mobilnetværk. En pludselig oversvømmelse fra et datacenters ASN med nul konverteringsrate er et stærkt signal i sig selv.
Bloker aldrig brugeragent alene, og vær forsigtig med at blokere hele lande. Begge dele ser afgørende ud i et dashboard, og de koster dig stille og roligt rigtige kunder. Især landeblokke har tendens til at blive indstillet under en hændelse og aldrig gennemgået igen.
Hvorfor kanten er det rigtige sted at gøre dette
Det er den del, der ændrer økonomien. Hvis du blokerer en skraber på din oprindelse, har anmodningen allerede krydset internettet, åbnet en TLS-forbindelse, vækket din ansøgning og forbrugt båndbredde på vej ind. Du betalte for alt det, og så returnerede du en 403.
Blokér den ved kanten – ude ved indgangen nærmest robotten – og anmodningen når slet ikke frem til din oprindelse. Din applikation vågner aldrig, din oprindelige båndbredde er uberørt, og dine logfiler forbliver læsbare. Under en seriøs skrabning er det forskellen mellem en generende og en strømafbrydelse.
De lag, der virker
Ingen enkelt mekanisme fanger alt, og det er fint, fordi de komponerer godt. I nogenlunde den rækkefølge, de skal køre:
| Lag | Hvad den fanger | Falsk positiv risiko |
|---|---|---|
| Blokeringsliste for netværk | Kendte dårlige IP'er, der allerede er identificeret på tværs af netværket | Meget lav |
| Kontrolleret bot | Bedragere hævder at være Googlebot | Meget lav |
| Satsbegrænsende | Alt, hvad der beder om, er hurtigere end et menneske kunne | Lav, hvis grænsen er generøs |
| Honeypot-stier | Krybskytter, der følger links, som mennesker ikke kan se | Nær nul |
| Udfordring med bevis for arbejde | Storstilet automatisering af enhver art | Lav |
| Land / ASN regler | Blunt, situationsbestemt | Høj – brug sparsomt |
Honeypots er undervurderede
En honeypot er en webadresse, som intet menneske nogensinde vil besøge – linket fra din side, men skjult for visning, og ikke tilladt i robots.txt. En rigtig besøgende ser det aldrig. En velopdragen crawler læser robots.txt og springer den over. Alt, hvad der anmoder om det, har både ignoreret robots.txt og fulgt et usynligt link, som er så tæt på bevis for dårlig hensigt, som du kommer på det åbne web. Falske positiver er tæt på nul, hvilket gør det til et af de få signaler, der er sikre at handle på med det samme og automatisk.
Bevis for arbejde er den høflige mulighed
En proof-of-work-udfordring beder kunden om at løse et lille computerpuslespil, før det bliver serveret. En rigtig browser gør det på et øjeblik, og den besøgende bemærker aldrig noget. Men en skraber, der laver 100.000 anmodninger, skal nu bruge rigtig CPU på hver enkelt, og aritmetikken, der gjorde operationen værd, stopper med at fungere. Det blokerer ikke nogen - det gør bare industriel skrabning dyrere end det vender tilbage, hvilket normalt er nok.
Hvad skal jeg gøre i denne uge?
- Læs dine rå logfiler, ikke analyser. Skrabere udfører ikke JavaScript, så de er usynlige i Google Analytics. Sorter anmodninger efter IP og efter brugeragent, og se på de øverste tyve af hver.
- Sæt en generøs satsgrænse på alt. Noget langt over, hvad et menneske kunne gøre - pointen er at fange det indlysende, ikke at overvåge dine brugere.
- Stram den på de slutpunkter, der betyder noget. Login, nulstilling af adgangskode, søgning og betaling fortjener meget strengere grænser end din blog.
- Tænd for kontrol af verificeret botter, så svindlerne Googlebots ikke længere får gratis adgang.
- Tilføj én sti til honningkage Se, hvad der sker i løbet af en uge, før du beslutter dig for, hvad du skal gøre ved det.
- Beslut dig for kunstig intelligens-crawlere med vilje. Uanset hvilken vej du vælger, så skriv det ind i robots.txt i stedet for at overlade det til tilfældighederne.
Ofte stillede spørgsmål
Hvordan forhindrer jeg skrabere i at kopiere mit websted?
Bloker dem ved CDN-kanten baseret på adfærd snarere end brugeragent. Den effektive kombination er satsbegrænsende, verificeret-bot kontrol, så bedragere crawlere afvises, honeypot stier, som kun automatiserede kunder vil anmode om, og en proof-of-work udfordring, der gør storstilet skrabning Det er for dyrt at være det værd. Blokering ved kanten betyder, at anmodningen aldrig når frem til din oprindelse eller koster dig båndbredde.
Hvordan kan jeg se en dårlig bot fra Googlebot?
Bekræft det i stedet for at stole på brugeragentstrengen, som alle kan indstille. Google udgiver sine crawler IP-områder, og en ægte Googlebot IP løser via omvendt DNS til et googlebot.com-værtnavn, der fremad-løser tilbage til den samme IP. Alt, hvad der hævder at være Googlebot fra en hostingudbyder eller VPS-sortiment, er en bedrager og kan blokeres sikkert.
Vil blokering af bots skade min SEO?
Ikke hvis du tillader bekræftede søgerobotter. Risikoen kommer fra stumpe regler – der blokerer et helt land eller en alt for aggressiv satsgrænse, der fanger Googlebot under en crawl. Hold verificerede søgemaskinerobotter fritaget for satsgrænser og udfordringer, og tjek din Search Console-crawlstatistik efter enhver ændring for at bekræfte, at crawlingen fortsatte normalt.
Stopper robots.txt skrabere?
Nej. robots.txt er en anmodning, ikke en håndhævelsesmekanisme. Velopdragne crawlere som Googlebot og de fleste AI-træningscrawlere ærer det; skrabere og ondsindede bots ignorerer det helt, og nogle bruger det som et kort over de stier, du hellere ikke ville se. Det er værd at vedligeholde for de bots, der samarbejder, men det er ikke en sikkerhedskontrol.
Hvad er en proof-of-work udfordring?
En proof-of-work-udfordring kræver, at klientens browser løser et lille beregningspuslespil, før siden serveres. En rigtig browser fuldfører det på en brøkdel af et sekund, og den besøgende ser intet usædvanligt, men en bot, der gør hundredtusindvis af anmodninger, skal bruge rigtig CPU på hver enkelt. Den identificerer ikke robotter – den gør automatisering i stor skala økonomisk meningsløs.
Hvorfor vises scrapere ikke i Google Analytics?
Google Analytics er afhængig af JavaScript i browseren, og de fleste skrabere anmoder om den rå HTML uden at køre nogen scripts. Det betyder, at skrabning af trafik er helt usynligt i analyser, mens du stadig bruger reel båndbredde og oprindelseskapacitet. For at se det skal du kigge på rå server- eller CDN-logfiler, hvor hver anmodning vises, uanset om JavaScript kørte.
Du vil aldrig komme til nul bots, og jagten på nul er, hvordan folk ender med at blokere deres egne kunder. Det realistiske mål er, at den automatiserede trafik, du betaler for, er den trafik, du har valgt at tillade.
Se, hvordan NordicCDN gør dette for dit websted:
Mads har arbejdet med IT – mest som vært – siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig og sikker infrastruktur enkel at bruge.
