En forbløffende mengde nettsteder bruker omvendte proxyer og DDoS-reduksjonstjenester som Cloudflare (f.eks. Reddit) for å beskytte dem mot store katastrofer og holde lysene på konsekvent måte. Disse tjenestene markedsfører seg ofte som leverandører av sikkerhet og ytelseforbedring.

Likevel, i en motsetning til dette, 17. februar 2017, forårsaket en stor feil i Cloudflares programvare en massiv mengde private data fra millioner av nettsteder for å være tilgjengelig når som helst. Noen av disse dataene kom til og med på bufret kopier av nettsteder som dukket opp i Googles søkeresultater. Denne spesielle begivenheten, som ble kjent som Cloudbleed, har gitt en verdifull anledning til en diskusjon om sikker bruk av teknologi.

Hva er alt dette ?!

For uninitiated er Cloudflare en tjeneste som fungerer som mellommann mellom nettstedet ditt og det bredere Internett. Når du går til et nettsted som bruker tjenesten, kobler du faktisk til Cloudflare som kobler til nettstedet og relayer utgangen til deg. Det vil cache noen av de hyppigst besøkte sidene, slik at nettstedet ikke trenger å svare hver eneste gang noen forbinder, og dermed redusere virkningen av store mengder trafikk på den lokale serveren. Dette bidrar også til å redusere virkningen av distribuerte avslag på tjenesten (DDoS) på nettstedet ditt siden det er en mellommann som kan hindre bruken av disse angrepene, som fungerer som en slags trafikklys som lar legitime besøkende gjennom og stopper bots i sporene sine . Cloudflare og andre omvendte proxy-tjenester (som Incapsula og Akamai) vil ofte markedsføre seg som leverandører av nettsikkerhet.

Hva er Cloudbleed?

Cloudbleed er en hendelse der en feil ble oppdaget i Cloudflares programvare av et medlem av Googles Project Zero-team som avdekket private meldinger fra store nettsteder, online passordadministratordata og full HTTPS-forespørsler fra flere andre servere. Cloudflares svar på tilkoblingsforespørsler vil ofte overskride deres tildelte bufferplass og presentere data fra andre kunder som får tilgang til nettsteder på det tidspunktet. Det overlater alt ut i det åpne og presenterer en katastrofal sikkerhetsrisiko for alle som bruker eller eier nettsteder som er avhengige av tjenesten.

Feilen ble patched mot slutten av februar, selv om tjenesten innrømmer at data lekkasjer kan ha gått så tidlig som innføringen av sin nye HTML-parser 22. september 2016.

Leksjoner Lært

Hvis du har lest historiene våre for en stund, kan du huske en meget lignende begivenhet som kalles Heartbleed tilbake i 2014, hvor nettsteder som bruker OpenSSL var sårbare for en utnyttelse som kunne eksponere fragmenter av private data til snooping-parter. Dette sammen med den nyere Cloudbleed kerfuffle lærer oss en verdifull leksjon: ingenting er hundre prosent pålitelig, ikke engang tjenestene med det eksplisitte formålet med å beskytte deg.

Dette er ikke ment å bash Cloudflare. Feilen kunne ha skjedd med noen tjeneste. Poenget her er at Internett ikke er et sted hvor du bør forvente et garantert sikkerhetsnivå. Du kan gjøre alt for å beskytte deg selv og fortsatt bli utelatt i det åpne av en situasjon som du ikke har kontroll over.

Hva burde du gjøre?

Sannheten er, som Inc.Coms Joseph Steinberg skriver, "Den nåværende risikoen er mye mindre enn prisen som ville bli betalt i økt" cybersecurity tretthet ", som fører til mye større problemer i fremtiden." Det han mener å si her er at naturen av feilen gjør at sjansene for at passordet ditt lekkasje så astronomisk lavt som endrer det, vil bare få den til å bære deg ned. Når en ekte krise treffer, kan du bli for utmattet av all støy, panikk og hype som du kan ignorere et anrop om å endre passordet ditt på et avgjørende tidspunkt. Cloudbleed er ikke det øyeblikket. Men hvis du virkelig føler behov for det, må du endre passordet ditt.

Annet enn det, vær bare årvåken og ikke ignorere e-postmeldinger fra tjenestene du elsker. I det øyeblikket en krise treffer, vil de sannsynligvis sende deg et vennlig brev med alt du trenger å vite om det, og kan til og med gi forslag til hva du bør gjøre for å sikre at du ikke blir påvirket.

Tror du at cybersecurity tretthet eksisterer som Steinberg foreslår? Skal folk være i konstant tilstand, selv når det ikke er en sterk nok begrunnelse for panikk? Fortell oss hva du synes i en kommentar!