Sikkerhet for nettsider – hvordan gjøre nettsiden sikker
Skrevet av: Trond Olav Ånesen

Å ivareta sikkerheten på nett er ikke på noen måte noe nytt. Mange tenker gjerne kun sikkerhet som besøkende på en nettside, men som eier må man også tenke sikkerhet. Det har ingen betydning hvilken type nettside du har. Enten det er en enkel informasjonsside, en blogg, en nettavis, en nettbutikk eller hva som helst.

Sikkerheten er viktig både for deg som eier og driver siden, og for de som besøker og bruker nettsiden. I denne artikkelen ser vi på hvordan man opprettholder grunnleggende sikkerhet og hva man kan/må gjøre hvis noe inntreffer.

Sikkerhet på nettsiden din handler om:

  • Det skal være trygt for alle å besøke nettsiden
  • Nettsiden skal ikke være infisert med skadelig kode som kan infisere besøkende
  • Nettsiden skal ikke videresende til sider med skadelig kode
  • Informasjonen som utveksles mellom besøkende og nettside/server skal ikke kunne fanges opp av uvedkommende

I en artikkel som dette har vi ikke anledning til å gå i dybden på alt, men vi fokuserer på det viktigste; Det skal være trygt å besøke nettsiden din!

sikkerhet for nettsider

Sørg for at nettsiden ikke er eller kan bli infisert

Når en nettside er åpen på nett er den et potensielt mål for en hacker. Hackeren er ikke nødvendigvis en kar i svart hettejakke som bor i en klam kjeller. I de aller fleste tilfellene er en hacker bare en automatisert «Bot» (Robot). Slike «Boter» står kontinuerlig og skanner både kjente og ukjente nettsider etter sårbarheter som kan utnyttes. Sårbarhetene eksisterer i koden man kjører, direkte, eller i tillegg, utvidelser og annet. Et klassisk eksempel er en nettside laget i WordPress, med eget tema og en håndfull plugins installert. Vi tar utgangspunkt i nettopp dette eksempelet videre i denne artikkelen.

Siden WordPress er så utbredt som det er, så er det populært å lete etter svakheter i denne type installasjoner. Klarer man å infisere 1 nettside, kan man potensielt gjøre det samme med mange tusen flere nettsider.

Motivet bak det å infisere en nettside kan være forskjellig; en hacker ønsker å spre sitt eget budskap, de ønsker å sende ut spam fra din konto, de ønsker å fange opp sensitiv informasjon fra besøkende, de ønsker å videresende besøkende til andre lumske sider, de ønsker å bruke ressursene til konto i andre angrep osv. Dette er noe man selvsagt ønsker å unngå. Som regel er det ikke deg direkte de ønsker å ta.

Sjekkliste for å unngå at din nettside blir infisert

  • Alt må være oppdatert, alltid
    Siden WordPress (og andre lignende systemer) er såpass populært, kommer det også oppdateringer så snart sårbarheter blir funnet, og utbedringer blir laget. Man må følge med slik at man får med seg oppdateringer og implementere disse i egen installasjon. Så snart en sårbarhet er oppdaget og kjent, er det kun et tidsspørsmål før nettsider som ikke er oppdatert blir angrepet. Det samme gjelder for alt av tillegg som er installert.I eksempelet vårt kjøres et eget tema og en del plugins. Disse kan også inneholde sårbarheter og utviklerne kommer da jevnlig med oppdateringer som retter dette. Derfor er det like viktig at dette holdes oppdatert som selve installasjonen.
  • Alt som ikke er i bruk på webhotellet bør fjernes
    Alle temaer og utvidelser/plugins som ikke er i bruk bør slettes/fjernes. Selv om man deaktiverer en utvidelse/plugin eller tema så er ikke alltid alt faktisk borte. Filer ligger ofte igjen og kan da potensielt misbrukes. Altså; kun det som er nødvendig for å ha nettsiden fungerende optimalt skal være åpent tilgjengelig. Alt annet må enten slettes eller flyttes til et område hvor det ikke kan nås.
  • Bruk captcha i skjemaer
    Skjemaer; da av typen kontaktskjemaer, bestillingsskjemaer osv, må sikres slik at de ikke kan fylles ut automatisk. Slike «Boter» som vi nevnte i sted kan også brukes til å misbruke slike skjemaer, når de finnes, og da eksempelvis sende ut spam fra nettside/konto. Dette går ut over de besøkende på to måter:
    1. Ved at ressurser på webhotellet kan bli brukt til kun dette, slik at besøkende ikke får lastet siden.
    2. Ved at misbruket er av en slik karakter at konto må suspenderes for å unngå videre problemer. Da blir siden i praksis tatt ned. På alt av skjemaer og annet hvor besøkende kan fylle ut info, bør man ha en ekstra sjekk på plass. Captcha er den mest brukte (og anbefalte) metoden for dette.

sikkerhet for nettsider

  • Passord som benyttes må være sikre
    Et sikkert passord er langt og satt sammen av både tall, små og store bokstaver og ander tegn. Lange passord kan også være setninger eller fraser sammen med tilfeldige tall/tegn som kan være enklere å huske. Passord er relevant både på kundesider hos oss, på webhotell, på epostkontoer og på selve nettsiden/installasjonen. De passordene som brukes mest er også de som er mest sårbare. Man bør bytte passord minst et par ganger i løpet av er år. Det bør heller ikke brukes samme passord noe sted.
  • Implementer ekstra sikkerhet hvor det er mulig
    For mange CMSer (WordPress/Joomla/Drupal) utvikles det egne plugins som fokuserer kun på sikkerhet. Her bør man undersøke litt hvilke behov man har, og installere det man mener passer best. Det finnes flere gratis alternativer som er gode nok, men har man en stor side som genererer mye trafikk kan det være verdt å betale for ekstra sikkerhet. Eksempel på en aktør med godt rykte rundt dette, som også tilbyr gratis plugin, er Sucuri.

sikkerhet for nettside

  • Sørg for å alltid ha backup (sikkerhetskopi) av innholdet
    Man bør alltid sørge for at man har backup (sikkerhetskopi) av innholdet. Kunder av PRO ISP har inkludert en av de beste løsningene som er i markedet for backup. Denne løsningen har de tilgang til direkte via webhotellets kontrollpanel (cPanel). PRO ISP tar backup av all data 1 gang pr døgn, og backupen beholdes i 30 dager. Selv om man har svært god backup inkludert i webhotellet hos PRO ISP så anbefales det alltid å ha en ekstra kopi lagret eksternt. Slik backup kan da være av typen tatt 1 gang pr måned, 1 gang pr kvartal osv, litt avhengig av hvor kritisk det er og hvor mye endringer man er villige til å miste.

Nettsiden er allerede blitt infisert, hva gjør man?

Hva om skaden alt er skjedd? Hva om kontoen din har blitt suspendert av oss? Mange kan oppleve dette, og det oppleves i de fleste tilfellene som svært urettferdig.

Alle hostingselskaper operer på samme måte når det gjelder webhoteller; mange webhoteller deler ressurser på samme server. Det er naturlig nok litt av opphavet til navnet; Serveren er hotellet, kundenes kontoer er hotellrom på dette hotellet.

Når en webhotelleverandør opplever at ressurser misbrukes må dette stoppes for å unngå at det går ut over alle andre på samme hotell. Tenk for eksempel at et hotellrom blir ekstremt mye besøkt, så mye at ingen andre hotellgjester kommer seg verken inn eller ut av sine rom. Da må det rommet som skaper problemer stenges for å unngå nettopp dette.
Det er ikke alltid at en konto stenges ned, men ser vi tegn til hacking/misbruk så kan vi gi beskjed direkte om dette slik at det kan utbedres.

Det viktigste i slike tilfeller er; Følg de instrukser som gis, og spør om tips/råd/veiledning dersom man er usikker.

Dersom vi oppdager hacking/misbruk, og enten gir beskjed om det eller suspenderer konto, så gir vi alltid beskjed om hva som må gjøres.
I de fleste tilfeller er hackingen såpass ny at man kan benytte seg av backupen som er inkludert i webhotellet. Prosedyren er da forholdsvis enkel:

  • Slett innhold på webhotellet som er relatert til nettsiden.
  • Gjenopprett innholdet fra en dato FØR hacking fant sted (evt den eldste tilgjengelige backup, ved usikkerhet)
  • Gjennomgå punktene over for å hindre videre hacking/misbruk, altså oppdater alt, slett alt som er unødveding, sikre alle skjemaer, bytt alle passord og implementer ekstra sikkerhet

Gjør man det som blir anbefalt, og sørger for å skjerpe rutinene med alle nevnte punkter, så er man så sikker man kan få blitt. Da vil både du som eier nettsiden, de som besøker nettsiden, og vi som serverer den fra våre servere være fornøyd.

Sikre informasjon mellom besøkende og server (SSL sertifikat)

Sikkerhetssertifikat er noe som blir mer og mer aktuelt å snakke om, og høyst aktuelt når det gjelder sikkerhet for nettsider. Vi har tidligere hatt innlegg både om «Hvordan velge riktig SSL sertifikat» og hvordan de store leverandørene planlegger å «tvinge» mer og bedre bruk av dette for å opprettholde sikkerheten på nettet («Google advarer: Sikre nettsiden din»).

Nå blir det noen litt tekniske ord og uttrykk her, men litt teknisk må vi bli for å forklare:
SSL* er en krypteringsprotokoll, eller et sett med regler som forteller en server/klient (nettsiden og besøkende) om hvordan kryptering av data skal foregå. Kryptering er da prosessen med å gjøre noe uleselig eller uforståelig for andre.

* I praksis er det TLS som benyttes, men SSL og SSL sertifikater benyttes i dagligtalen, så derfor også her.

Målet med SSL er altså at kun den som besøker nettstedet, og serveren/nettstedet, skal kunne lese data som sendes mellom disse. Det er da spesielt viktig når det er personlig eller sensitiv informasjon som utveksles, så som telefonnr, brukernavn, passord, epostadresser, kredittkortinformasjon og lignende; for vi ønsker IKKE at slik info skal kunne ses av andre.

sikkerhet for nettside

For å få til denne krypteringen bruker vi såkalte «nøkler», og når både den besøkende og serveren/nettsiden har samme type «nøkkel», er det kun de som kan lese, og kryptere, informasjonen. Et SSL sertifikat er da et sertifikat som bekrefter eierskapet til disse nøklene, og at de er autentiske og gyldige. Hvor nøyaktig og grundig den bekreftelsen er kommer an på sertifikatet, les mer om dette i «Hvordan velge riktig SSL». I praksis bekreftes at sertifikatet er utstedt av en gyldig utsteder, for det nettstedet man besøker, og at det er gyldig for nettopp dette.
Du som besøkende kan se dette ved at man får opp en hengelås i adressefeltet og at nettleseren rapporterer om at nettstedet er å anse som «sikkert».

Som vi nevnte i «Google advarer: Sikre nettsiden din» så er kryptering av informasjon høyst aktuelt siden det snart blir et krav. Man kan selvsagt unngå bruk av SSL sertifikater, men da vil besøkende bli advart når de går til siden din. Denne advarselen kan sammenlignes med å rope til kundene: «Jeg tar ikke sikkerhet på alvor». For de som ikke har fått nettsiden sin over på https er tiden definitivt inne for å ta grep!

Har du flere spørsmål etter å ha lest innlegget?

Som nevnt innledningsvis er sikkerhet et såpass stort tema man ikke kan dekke alt i en enkel artikkel. Likevel, følger man de råd som er gitt her, og har sikkerhet litt mer i «bakhodet» har man kommet et langt stykke på vei.

Leser du innlegget og sitter igjen som et spørsmålstegn? Er det ting du lurer på som ikke ble forklart eller besvart her? Eller ønsker du bare råd og veiledning? Ikke nøl med å ta kontakt med oss.

Epost: support@proisp.no
Facebook: https://www.facebook.com/proisp/

Facebooktwittergoogle_pluslinkedin

DDoS angrep – Hvordan håndtere og stoppe det
Skrevet av: Trond Olav Ånesen

I denne artikkelserien ser nettverksadministrator Trond nærmere på DDoS angrep. Hva det er, hvorfor det skjer og hvordan det kan håndteres. Serien er i 3 deler og hver uke publiseres en ny del.

I del 1 og  del 2 så vi  på hva et DDoS angrep egentlig er, hvem som utfører de og hvorfor det skjer samt litt om hva som faktisk foregår under et angrep. I denne artikkelen skal vi se på hvordan man kan håndtere og stoppe slike angrep.

Hvor stort er DDoS angrepet?

Først og fremst; hvordan det håndteres kan variere ut i fra hvordan angrepet utføres og viktigst av alt, hvor stort angrepet faktisk er.

Ett lite, usofistikert, DDoS angrep vil i de fleste tilfeller kunne stoppes ved hjelp av en ordinær brannmur, gjerne softwarebasert direkte på server/enheten som angripes. Dette kan være eksempelvis et TCP-SYN-Flood angrep. Vi går ikke inn på detaljer om de enkelte angrepene, men i all enkelhet handler angrepet om å starte, men ikke stoppe, tilkobling mot en server/tjeneste. Måten TCP fungerer på gjør at slike «halveis-tilkoblinger» kan bli værende åpne over noe tid, og en server/tjeneste har kun et gitt antall tilkoblinger tilgjengelig. På denne måten kan en server gjøres utilgjengelig uten at større mengder data overføres.

En forholdsvis enkel brannmur kan oppdage denne type angrep og utføre tiltak som blokkering av IP adressene tilkoblingene kommer fra, resette sesjoner raskere og lignende (igjen, vi går ikke inn på alle detaljene her).

TCP-SYN-Flood er et enkelt angrep og ikke vanskelig å stoppe. Men hva med de større angrepene, når en server bombarderes med 1Gbit/s trafikk?

Den første regelen er; man må alltid ha større kapasitet på egen internettforbindelse, enn hva angriperne har tilgang til. For en infrastrukturleverandør (eks et datasenter) er ikke 1Gbit/s en veldig stor mengde trafikk, men en server har gjerne en uplink (tilkobling mot Internet) på 1Gbit/s, og da er i praksis denne serveren lammet. Man kommer altså ikke noen vei med brannmuren man har på serveren, siden mengden trafikk overvelder denne og den vil ikke lenger ha noen effekt. Man må da altså stoppe angrepet før det kommer til serveren.

proisp blogg ddos angrep stoppe

Vi snakket tidligere om hvordan «Ola» angrep sine motspillere etter noen dårlige omganger i et online spill. La oss se nærmere på hvordan en typisk internettleverandør vil håndtere dette.

Ola har skaffet seg en konto på et russisk hackerforum, og avtalt å betale for et DDoS angrep på 2Gbit/s rettet mot 2stk IP adresser, tilhørende 2 av motspillerne. Angrepet skal opprettholdes i 4 timer.

For en Internettleverandør (ISP) er ikke 1Gbit/s mye trafikk, men når det er rettet mot 1 enkelt IP blir saken fort en annen.

Motspillerne til Ola har gjerne en Internettforbindelse på 30Mbit/s, så trafikken er mer enn nok til å oppta all tilgjengelig båndbredde og gjøre internett for brukeren ubrukelig. Problemet er at i samme nabolag er det 10 andre koblet til samme base/knutepunkt, og til dette knutepunktet har gjerne ISPen en linje med 200Mbit/s kapasitet. Det som skjer er altså at hele nabolaget mister internettforbindelsen, noe ISPen selvsagt må rette opp.

En av de vanligste metodene her er å «nullroute» trafikken. I praksis betyr det at man tar all trafikk som er rettet mot en gitt IP (den som blir angrepet), og sender denne til et annet sted hvor den bare blir ignorert/kastet. For å være sikker på at nytt angrep ikke starter uten videre blir som regel den angrepet var rette mot, suspendert for en periode (1-24t).

Så har vi de riktig store angrepene. Tidligere har vi nevnt angrep på en nettavis i Ukraina og epost-tjenesten ProtonMail. Dette er begge tjenester som er bygd for å håndtere svært mange besøkende og mye datatrafikk i alle retninger. For å effektivt slå ut en sånn tjeneste kreves store datavolum, og det er da snakk om 20Gbit/s++.

Den første regelen når vi snakker om DDoS beskyttelsen gjelder også her; man må ha større kapasitet på eget nettverk og egne linjer, enn hva angriper klarer å levere. Når vi snakker om de store angrepene er det ofte her problemene starter; båndbredde og kapasitet på brannmurer/Anti-DDoS utstyr koster mye, mye penger. For noen vil det ikke være verken mulig, eller ønskelig, å investere millionbeløper i avansert utstyr, bla siden man også må skaffe kompetanse til å drifte dette. For en nettverksadministrator vil det også være veldig vanskelig å forsvare slike investeringer, da det man beskytter seg mot «kanskje» vil skje en gang i fremtiden, kanskje.

Oppe i «skyen»

De siste årene har ordet cloud blitt mer eller mindre innarbeidet i de fleste tekniske løsninger; det ligger i «clouden», er det nok flere som har hørt, og noen mener dette for lengst har blitt et moteord som misbrukes på det sterkeste.

Uansett; der det finnes et marked vil det unektelig dukke opp noen som ønsker å tilby tjenester til dette markedet, og de opererer ofte med «CloudBased protection». Det er ofte dette vi snakker om når de veldig store angrepene skal håndteres.

proisp blogg ddos angrep stoppe

De siste årene har mange selskaper sett sitt snitt til å tilby denne type tjenester, og de som gjør det best er som regel de som allerede er store på fysisk utstyr. Eksempler er Arbor og F5, som kombinerer fysisk utstyr plassert «foran serveren», men skybaserte løsninger. Samtidig har man leverandører som i utgangspunktet kun satser på skybaserte (cloud based) løsninger, og en av de mest kjente og største her er CloudFlare.

Når man snakker skybaserte løsninger snakker man som regel om såkalte CDN, altså Content Delivery System. I praksis fungerer dette som en proxyløsning. Dvs at når noen besøker en nettside så går ikke trafikken direkte fra serveren nettsiden er plassert på, men via en tredjepart. Som besøkende er man uvitende om at det er en aktør mellom seg og nettsiden, og alt av angrep som måtte bli utført mot nettsiden blir i praksis utført mot tredjepart; leverandøren av CDN.

Disse leverandørene tilbyr ofte produkter i de fleste prisklasser, fra helt gratis til svært dyre, avhengig av hva som skal beskyttes, hva man ønsker beskyttelse mot, størrelse på angrep osv.

Skybaserte løsninger er bygd opp av store menger fysisk utstyr, og hos de store leverandørene er dette også spredd over mange geografiske lokasjoner. Summert opp betyr dette at de har all den kapasitet de trenger, og vel så det, for å ta unna selv de største angrepene før det når kundens lokasjon. Det er også grunnen til at tjenesten kan benyttes uavhengig av hvor din server og ditt innhold er plassert.

Siden det er såpass mange angrep som skjer, hele tiden, har disse store leverandørene veldig god oversikt over metodene som benyttes og hvordan de best kan håndtere det. Dette er noe av grunnen til at det tilbys gratis beskyttelse; i tilfelle små angrep får man masse «god data» man kan analysere for å finne nye og bedre måter å beskytte seg på.

Hvordan beskytte seg mot DDoS angrep?

Som man forhåpentligvis vil forstå etter å ha lest dette, er det vanskelig å gi noe konkret svar på hvordan man beskytter seg mot DDoS. Både fordi det finnes mange typer angrep og mange måter å beskytte seg mot og hindre dette, men også fordi ikke alle har samme forutsetninger. Det gjelder både teknisk og økonomisk.

Det ville vært enkelt å si at; invester 10 000,- så får du en garanti mot DDoS! Dette går ikke. Man kan nok finne leverandører som garanterer både det ene og det andre, men en garanti betyr som regel bare at hvis det ikke overholdes så kompenseres man ihh til avtale som er inngått. Mange har nok derfor et litt urealistisk syn på hvor beskyttet man faktisk er, gitt «garantien».

Her er våre topp 3 tips:

1. Velg leverandørene dine med omhu. Mange ser kun på pris når de velger leverandør, det være seg domeneregistrering, webhotell, serverdrift og annet. Pris må selvsagt vurderes, men det er noen spørsmål man bør stille før man velger;
Er leverandøren kjent i markedet?
Finner man (positiv) info når man søker opp leverandøren i forum og lignende? Har leverandøren en portal/infoside hvor hendelser informeres om, hvor detaljert er infoen og hvor lett tilgjengelig er infoen (sosiale medier etc)?

2. Har leverandøren support og oppfølging av kundene sine, som står i stil med det du forventer og trenger? Mange har også her en litt urealistisk oppfatning av hva de faktisk betaler for. En leverandør kan ha så gode og stabile produkter de bare vil; problemer kan og vil oppstå, og da er man avhengig av å både få kontakt med, få hjelp av, og ikke minst samarbeide med leverandøren når uhellet er ute (litt uavhengig av om det er snakk om DDoS eller bare generelt).

3. Gjør det du kan fra din side, slik at det du ønsker å beskytte er så sikkert det kan være før det er «synlig» på nett. Hvis det eks gjelder en nettside du har laget i WordPress, så handler det om å holde alt oppdatert/patchet til enhver tid, holde seg oppdatert og følge opp evt sikkerhetsbrister som publiseres, sørge for å benytte gratis-tjenester ift «CloudBased» beskyttelse osv. Det er MYE man både kan og bør gjøre for å ha en så sikker nettside som mulig.

Det er mange måter et DDoS angrep kan utføres på, mange grunner til at det utføres og mange måter man kan beskytte seg mot det på. Uavhengig av hva man måtte mene er dette problematikk som må tas seriøst.

Denne artikkelen er ikke en fullstendig oversikt over DDoS, på noen som helst måte. Ei heller en håndbok i hvordan man beskytter seg, hvordan det fungerer etc, men det er et forsøk på å opplyse på en forholdsvis enkel måte om hvem, hva og hvor ift angrepet som flere og flere dessverre stifter bekjentskap med.

Kilder:
The Register – «Internet’s root servers take hit in DDoS attack»

GEN – Cyber attacks – how to protect your newsroom

Facebooktwittergoogle_pluslinkedin

DDoS angrep – hva skjer under et angrep?
Skrevet av: Trond Olav Ånesen

I denne artikkelserien ser nettverksadministrator Trond nærmere på DDoS angrep. Hva det er, hvorfor det skjer og hvordan det kan håndteres. Serien er i 3 deler og hver uke publiseres en ny del.

I del 1 så vi på hva et DDoS angrep er, hvem som kan utføre disse og hvilke hensikter de kan ha. I denne artikkelen skal vi se nærmere på hva som egentlig foregår når angrepet skjer.

Hva skjer under et DDoS angrep?

‘Distributed’ betyr at det er mange enheter (hjemmepc, kontorpc, servere og lignende) som er med på angrepet. I de aller fleste tilfeller er eierne av disse enhetene helt intetanende til dette.

I tilfellet nettsider, så kan disse som regel håndtere fra et titalls, til noen millioner treff i sekundet, avhengig av leverandør, server, oppsett og lignende.

proisp blogg ddos del 2 hacker

Det kreves altså mange enheter for å utføre et vellykket angrep. Som nevnt er eierne av enhetene ikke klar over at de er med på angrepet, og da kaller vi ofte disse enhetene for «zombier». En enhet/maskin/PC blir en zombie hvis den blir infisert, noe en angriper kan gjøre via nettsider brukeren av enheten besøker, epost sendt til brukeren/eieren osv. Når angriper har infisert en enhet kan denne kontrolleres via kommandoer kjørt fra angriper. Har man mange nok infiserte enheter under egen kontroll, kaller man det et zombie-nettverk, eller bot-net. I de tilfellene hvor man leier DDoS angrep er det disse zombie-nettverkene man faktisk betaler for å benytte.

Hvorfor oppdages ikke dette av eieren av den infiserte enheten/PCen/serveren? Vel; selv om anti-virus, brannmur og lignende er kjente begreper, er det svært mange som ikke tar dette alvorlig nok. Man har utdaterte versjoner eller ikke noen sikkerhetsprogramvare i det hele tatt. Koden som er plassert på enheten er laget på en måte slik at eier ikke skal oppdage det, og en av grunnene til at eierne(e) ikke oppdager dette er at trafikken som sendes fra hver enkelt infisert enheter er svært liten.

Siden kommandoer sendt fra angriperen til zombie-enheten ikke påvirker ytelsen til den infiserte enheten, og heller ikke båndbredde/Internett-hastighet i særlig grad, kan en enhet være en zombie hele sin levetid uten å vekke mistanke.
Selv om trafikken fra hver enkelt enhet ikke er stor, blir det fort veldig mye hvis man har mange nok enheter man kan benyttes.

Hvordan fungerer det i praksis?

La oss ta utgangspunkt i en standard hostingleverandør og en standard nettside plassert hos dem. Vanligvis har en konto hos en hostingleverandør begrenset ressursbruk, både fysisk på serveren (cpu, ram) og når det gjelder båndbredde som kan benyttes. Dette vil si at det ikke nødvendigvis kreves så veldig store angrep.

Når man skriver inn en adresse i nettleseren sin, er det første som skjer at din enhet sender en forespørsel til serveren nettsiden er plassert på, dette i form av: HTTP GET request.

Når server mottar denne forespørselen svarer den med å sende innholdet på fremsiden for nettsiden man besøker, til besøkerens nettleser. Båndbredden som benyttes avhenger da av størrelsen på nettsiden som skal lastes, men la oss ta utgangspunkt i at en besøkende krever 1mbit/s i 5 sekunder for å få lastet hele nettsiden. Mange leverandører har som nevnt begrensninger på hvor mye båndbredde en enkelt konto kan benytte, eks 100mbit/s. Med andre ord; dersom 100 personer besøker nettsiden på nøyaktig samme tidspunkt, vil i praksis båndbredden til nettsiden være brukt opp i 5 sekunder, og alle andre som forsøker å laste siden i denne tidsperioden vil oppleve lang lastestid på siden, og eventuelt få feilmelding (gjerne 503 error).

Å ta ned en nettside som ligger i et hostingmiljø er altså ikke nødvendigvis så vanskelig, og hvis vi tar i betraktning at et zombie-nettverk kan bestå av flere millioner enheter, er skadepotensialet enormt mye større.

Hvor stor skade kan et DDoS angrep gjøre?

Når vi snakker om DDoS snakker vi ofte om størrelsen på angrepene, og det er da snakk om trafikkvolum. Selv om intensjonen til angriperen er å ta ned en enkelt nettside, kan skaden bli mye større.

La oss si at hostingleverandøren til nettsiden har en internettforbindelse på 500Mbit/s. Et DDoS angrep kan svært enkelt «fylle opp» båndbredden på denne forbindelsen, og i praksis tar da ikke angriper ned kun en nettside, men hele leverandøren og potensielt tusenvis av sider og kontoer.

Hvis vi «zoomer» litt ut; hostingleverandøren har en underleverandør som leverer internettforbindelsen til det datarommet/datasenteret hvor hostingleverandøren har sine servere/tjenester plassert. Denne underleverandøren har eksempelvis 2Gbit/s båndbredde, som deles mellom hostingleverandøren og X antall andre kunder. Et angrep som i utgangspunktet skal ta ned en nettside, tar da plutselig ned ikke bare hostingleverandøren, men også alle andre kunder internettleverandøren leverer tjenester til.

Hva fører DDoS angrep til?

Det kan kanskje være vanskelig å skjønne dette med båndbredde, ytelse og kapasitet hvis man ikke er kjent med fagspråket. For å forklare det så enkelt som mulig;

Se for deg at nettsiden din er 1 av mange butikker i et kjøpesenter, hvor kjøpesenteret i denne sammenhengen er serveren, og de andre butikkene er andre kontoer/nettsider på samme server.

Hvis din butikk får 3000 kunder en dag, men kun har kapasitet til å yte service til 1000, vil din butikk i praksis være utilgjengelig for de 2000 som står i kø. Hvis noen så sender 10 000 kunder til din butikk, vil hele kjøpesenteret fylles av folk, og ingen av butikkene vil kunne besøkes. Øker vi til 100 000 kunder vil alle veier i området rundt kjøpesenteret fylles opp, som gjør at andre sentere og butikker også i praksis blir utilgjengelige.

Med andre ord; et DDoS angrep fører til fullt kaos på veiene til/fra en server.

I denne artikkelen har vi sett på hvordan zombie-enheter benyttes til å utføre et DDoS direkte. Dette er bare en av mange måter man kan utføre et angrep på og de tekniske løsningene som ligger bak vil naturlig nok variere og endre seg.

Et annen måte å forklare det på er denne visuelle fremstillingen av en nettside som fungerer som normalt:

Som motsetning viser videoen nedenfor en visuell fremstilling av en nettside under DDoS angrep:

I del 3 kan du kunne lese om hvordan DDoS angrep kan håndteres.

Kilder:
List of HTTP status codes 

Facebooktwittergoogle_pluslinkedin

DDoS angrep – hva er det og hvor kommer de fra?
Skrevet av: Trond Olav Ånesen

I denne artikkelserien ser nettverksadministrator Trond nærmere på DDoS angrep. Hva det er, hvorfor det skjer og hvordan det kan håndteres. Serien er i 3 deler og hver uke publiseres en ny del.

I denne første delen av serien skal vi se på hva et DDoS angrep er,  hvem som kan utføre disse og hvilke hensikter de kan ha.

Hva er DDoS angrep?

Folk som har vært noen år i IT bransjen, og da spesielt innen nettverk og serverdrift, kjenner dessverre så altfor godt til DDoS og hva det står for. La oss ta det enkle først; DDoS står for «Distributed Denial-of-Service».

Et slikt «Denial-of-Service» angrep er et forsøk på å ta ned en server, gjøre en nettside utilgjengelig, eller angripe selve internettet. Mulighetene er mange og like mange er årsakene til at det at de forekommer.

proisp blogg ddos angrep system failure

Hvorfor skjer DDoS angrep?

Det kan finnes flere årsaker til noen ønsker å gjøre en nettside eller en server utilgjengelig. De tre klassiske eksemplene er politisk aktivisme, «script kiddies» eller utpressing.

Politisk aktivisme
Vi lever i en verden hvor ytringsfriheten er viktig og folk er berettiget til å mene hva de vil. I ytterkantene av disse meningene finner vi dog de som er villig til å gå lengre enn andre for å få frem nettopp sin mening. Man nøyer seg ikke med å ytre sin mening på sosiale medier, debatter og lignende, men man ønsker i tillegg å straffe de som måtte mene det motsatte.

Hvis man eier eller drifter en nettside med kontroversielt innhold vil man, grunnet innholdet, stå i fare for å bli angrepet. Hva som er kontroversielt innhold kan selvsagt diskuteres, men i det man snakker om religion eller politikk (spesielt i «ekstreme» religiøse miljøer, eller ytterkanter på høyre/venstre sidene i politikken) blir det fort kontroversielt uansett. Det beste eksempelet på dette er nyhetssider/nettaviser. I Norge har vi heldigvis ikke sett så mye til dette, men i land der sitasjonen er annerledes; eks Ukraina, har dette vært et problem. Pravada er en Ukrainsk nettavis som fokuserer på å formidle alle sider av de politiske debattene. Som en følge av dette har de vært under store angrep, og nettsiden har derfor over flere år hatt problemer med nedetid som følge av dette.

Angriperne ønsker altså å gjøre tjenesten ustabil slik at folk ikke kan benyttes seg av den (gir da også nettavisen dårligere rykte grunnet nedetiden), og akkurat det oppnår de.

«Script Kiddies»
DDoS angrep er langt ifra det det en gang var. Som så mye annet går utviklingen den veien at det blir utviklet verktøy som «selv mor» kan benytte. Når verktøyene blir lettere å bruke og mer tilgjengelige, opplever man at angrep kan bli utført fra gutterommet (bokstavelig talt).

La oss si at «Ola» spiller LoL (League Of Legends), og taper kampene i spillet. Han blir irritert, sint og gjør et søk på internett om hvordan han kan ødelegge for sine medspillere. Han finner et program hvor han skriver inn IPen (spillerens «adresse» på internett) til medspillerne (dette er som regel mulig å finne ganske enkelt). Programmet er laget slik at det raskt og effektivt sender store mengder trafikk mot medspillerne, noe som resulterer i at deres internettforbindelse blir treg og til slutt stopper. Ola har altså oppnådd det han ønsket, og medspillerne som har blitt utsatt for angrepet kan oppleve at internettleverandøren midlertidig stenger forbindelsen helt.

Vi kaller Ola for en «script kiddie» fordi han benytter verktøy andre har utviklet for å utføre sine misgjerninger. Ola trenger altså ikke å ha noe som helst kunnskap om nettverk, servere eller annet for å ødelegge for andre. All informasjon er tilgjengelig på nett.

Utpressing
Her snakker vi om store, avanserte og som regel veldig godt planlagt angrep. Målet er enkelt: Penger.

Ofrene for slike angrep er som regel store aktører som internasjonale selskaper, internettleverandører, innholdsleverandører osv. Det hele er veldig enkelt; en angriper starter et angrep som er stort nok til å garantert lamme for eksempel en internettleverandør. Samtidig som angrepet starter, og i noen tilfeller også før angrepet, blir det sendt et brev som ber om en viss sum penger, ellers vil angrepet opprettholdes på ubestemmelig tid.

Hvis angrepet faktisk lammer leverandøren mister alle abonnenter internettforbindelse, så dette er med andre ord meget kritisk. Dersom leverandøren har et robust nettverk og gode rutiner, så vil angrepet kunne håndteres innen forholdsvis kort tid (0-1 timer). Dersom de ikke har mulighet til å håndtere det vil nok mange betale kravet for å stoppe det. Her er det antageligvis en del mørketall da få vil innrømme dette.

Proton Mail er blant de selskapene som har innrømmet å ha betalt for å få stoppet angrepet, men som opplevde at angrepene bare fortsatte.

proisp blogg ddos protonmail

I del 2 kan du lese om hva som egentlig foregår når et DDoS angrep skjer.

Kilder:
Threat Post «ProtonMail Back Online Following Six-Day DDoS Attack»

Facebooktwittergoogle_pluslinkedin