I de fleste tilfeller må nettapplikasjonsservere være offentlig tilgjengelige, noe som betyr at de er utsatt for alle slags trusler.
Mange av disse truslene er forutsigbare og lett unngåelige, mens andre er ukjente og kan ta deg uoversiktlig. For å minimere muligheten for dette siste tilfellet, tilbyr vi en liste med viktige tips for å holde webapplikasjonsservere så sikre som mulig.
Før du begynner med tipslisten, må du forstå at en webapplikasjonsserver ikke er en øy. Serveren er den sentrale komponenten i webapplikasjonsfarmen som gjør hosting og drift av en webapplikasjon mulig. Derfor, for å sikre, må du ta hensyn til alle komponentene som omgir den og sikre hele webapplikasjonsmiljøet.
Et grunnleggende miljø for å være vert for og kjøre webapplikasjoner inkluderer operativsystemet (Linux, Windows), webserverprogramvaren (Apache, Nginx), en databaseserver. Hvis noen av disse komponentene brytes inn, kan angripere få tilgang og utføre alle de ondsinnede handlingene de ønsker.
Et første og grunnleggende tips for å sikre et miljø som det som er beskrevet ovenfor, er å lese sikkerhetsretningslinjene og listen over beste praksis for hver av komponentene. Når det er sagt, la oss gå gjennom en rekke sunne sikkerhetsretningslinjer som gjelder for nesten alle nettapplikasjonsmiljøer.
Innholdsfortegnelse
Brannmuren avmystifisert
Du kan bli fristet til å sjekke dette elementet raskt og tenke: «Heldig meg, jeg har allerede en brannmur som beskytter nettverket mitt.» Men du bør holde hestene dine.
Brannmuren din tar kanskje vare på nettverkets grenser, holder de slemme ute og de gode inne, men den etterlater garantert en dør på vidt gap for angripere å bryte inn nettapplikasjonsserveren din.
Hvordan?
Enkelt: nettverkets brannmur må i det minste tillate innkommende trafikk på portene 80 og 443 (det vil si HTTP og HTTPS), og vet ikke hvem eller hva som passerer gjennom disse portene.
Det du trenger for å beskytte applikasjonen din er en brannmur for nettapplikasjoner (WAF) som spesifikt analyserer nettrafikk og blokkerer ethvert forsøk på å utnytte sårbarheter som skripting på tvers av nettsteder eller kodeinjeksjon. En WAF fungerer som et typisk antivirus og antimalware: den ser etter kjente mønstre i datastrømmen og blokkerer den når den oppdager en ondsinnet forespørsel.
For å være effektiv må WAF ha sin database konstant oppdatert med nye trusselmønstre, for å kunne blokkere dem. Problemet med mønsterbasert angrepsforebygging er at nettapplikasjonen din kan være et av de første målene for en ny trussel som WAF ennå ikke er klar over.
Av disse grunnene trenger nettapplikasjonen ytterligere beskyttelseslag i tillegg til nettverksbrannmuren.
Skann etter nettspesifikke sårbarheter
Igjen, ikke tro at webapplikasjonsserveren din er sårbarhetsfri bare fordi nettverkssikkerhetsskanneren sier det.
Nettverksskannere kan ikke oppdage applikasjonsspesifikke sårbarheter. For å oppdage og eliminere disse sårbarhetene, må du sette applikasjonene under en rekke tester og revisjoner, for eksempel penetrasjonstester, svartboksskanning og kildekoderevisjon. Ingen av disse metodene er imidlertid skuddsikre. Ideelt sett bør du utføre så mange av dem som mulig for å eliminere alle sårbarheter.
For eksempel sikkerhetsskannere, som Invicti, sikre at ingen utnyttbar kode kommer til produksjonsmiljøet. Men det kan være logiske sårbarheter som bare kan oppdages ved manuell koderevisjon. Manuell revisjon, i tillegg til å koste mye, er en menneskelig og derfor feilutsatt metode. En god idé å gjøre denne typen revisjon uten å kaste bort mye penger er å bygge den inn i utviklingsprosessen, for det meste ved å utdanne utviklerne dine.
Lær utviklerne dine
Utviklere har en tendens til å tro at applikasjonene deres kjører i ideelle verdener, hvor ressursene er ubegrensede, brukerne ikke gjør feil, og det er ingen mennesker med hensynsløse intensjoner. Dessverre må de på et tidspunkt møte problemer i den virkelige verden, spesielt de som gjelder informasjonssikkerhet.
Når du utvikler nettapplikasjoner, må kodere kjenne til og implementere sikkerhetsmekanismer for å sikre at den er fri for sårbarheter. Disse sikkerhetsmekanismene bør være en del av veiledningen for beste praksis som utviklingsteamet må overholde.
Programvarekvalitetsrevisjon brukes for å sikre samsvar med beste praksis. Beste praksis og revisjon er de eneste måtene å oppdage logiske sårbarheter, som (for eksempel) å sende ikke-krypterte og synlige parametere inne i en URL, som en angriper enkelt kan endre for å gjøre det han eller hun vil.
Slå av unødvendig funksjonalitet
Forutsatt at nettapplikasjonene er så feilfrie som mulig og nettfarmen er sikret, la oss se hva som kan gjøres på selve serveren for å beskytte den mot angrep.
Et grunnleggende, sunn fornuft tips er å redusere antall potensielt sårbare inngangspunkter. Hvis angripere kan utnytte noen av komponentene til webserveren, kan hele webserveren være i fare.
Lag en liste over alle åpne porter og kjørende tjenester eller demoner på serveren din og lukk, deaktiver eller slå av de unødvendige. Serveren skal ikke brukes til andre formål enn å kjøre nettapplikasjonene dine, så vurder å flytte all tilleggsfunksjonalitet til andre servere i nettverket ditt.
Bruk separate miljøer for utvikling, testing og produksjon
Utviklere og testere trenger privilegier på miljøene de jobber med som de ikke skal ha på live-applikasjonsserveren. Selv om du stoler blindt på dem, kan passordene deres lett lekke og falle i uønskede hender.
I tillegg til passord og privilegier, er det i utviklings- og testmiljøene vanligvis bakdører, loggfiler, kildekode eller annen feilsøkingsinformasjon som kan avsløre sensitive data, for eksempel databasebrukernavn og passord. Nettapplikasjonsdistribusjonsprosessen bør gjøres av en administrator, som må sørge for at ingen sensitiv informasjon blir eksponert etter at applikasjonen er installert på live-serveren.
Det samme segregeringskonseptet må brukes på applikasjonens data. Testere og utviklere foretrekker alltid ekte data å jobbe med, men det er ikke en god idé å gi dem tilgang til produksjonsdatabasen, eller til og med en kopi av den. Foruten åpenbare personvernhensyn, kan databasen inneholde konfigurasjonsparametere som avslører interne serverinnstillinger – for eksempel endepunktadresser eller stinavn, for å nevne et par.
Hold serverprogramvaren oppdatert
Så åpenbart som det kan virke, er dette en av de mest oversett oppgavene. SUCURI fant at 59 % av CMS-applikasjonene var utdaterte, noe som er åpent for risiko.
Nye trusler dukker opp hver dag, og den eneste måten å hindre dem i å sette serveren din i fare, er å alltid installere de nyeste sikkerhetsoppdateringene.
Vi nevnte før at nettverksbrannmurer og nettverkssikkerhetsskannere ikke er tilstrekkelige til å forhindre angrep på nettapplikasjoner. Men de er nødvendige for å beskytte serveren din mot vanlige cybersikkerhetstrusler, som DDoS-angrep. Så sørg for at du alltid har slike applikasjoner oppdatert, og at de effektivt beskytter bedriftsapplikasjonen din.
Begrens tilgang og privilegier
Et grunnleggende sikkerhetstiltak er å holde ekstern tilgangstrafikk – som RDP og SSH – kryptert og tunnelert. Det er også en god idé å holde en redusert liste over IP-adresser der ekstern tilgang er tillatt, og sørge for at ethvert forsøk på å logge eksternt fra en annen IP er blokkert.
Administratorer gir av og til tjenestekontoer alle mulige rettigheter fordi de vet at ved å gjøre det, «alt vil fungere.» Men dette er ikke en god praksis siden angripere kan bruke sårbarheter i tjenestene for å penetrere serveren. Hvis disse tjenestene kjører med administratorrettigheter, kan de beslaglegge hele serveren.
En god balanse mellom sikkerhet og praktisk bruk krever at hver konto – både påloggingskontoer og tjenestekontoer – har rettighetene den trenger for å utføre jobben sin, og ingenting annet.
Du kan for eksempel definere forskjellige kontoer for en administrator for å gjøre forskjellige oppgaver: en for å lage sikkerhetskopier, andre for å rense loggfiler, andre for å endre konfigurasjonen av tjenester, og så videre. Det samme gjelder for databasekontoer: en applikasjon trenger vanligvis bare tillatelsene til å lese og skrive data, og ikke for å opprette eller slippe tabeller. Derfor bør den kjøres med en konto med privilegier begrenset til å utføre oppgavene den må utføre.
Hold øye med serverloggene
Loggfiler er der av en grunn.
Administratorer bør overvåke dem regelmessig for å oppdage mistenkelig oppførsel før den gjør skade. Ved å analysere loggfiler kan du avdekke mye informasjon for å hjelpe deg bedre å beskytte applikasjonen. Hvis et angrep skulle skje, kan loggfiler vise deg når og hvordan det startet, og bidra til bedre skadekontroll.
Du må også ha en automatisert prosedyre for å slette gamle loggfiler eller for å beskjære utdatert informasjon, for å forhindre at de bruker all tilgjengelig lagringsplass på serveren.
Bonustips: Hold deg informert
Det er mye gratis og nyttig informasjon på Internett som du kan bruke til fordel for nettapplikasjonen din. Ikke gå glipp av noe nytt innlegg på anerkjente sikkerhetsblogger (som denne) og hold deg informert om hva som skjer i sikkerhets- og nettbransjen.
Veiledninger, kurs, videoer og bøker er også kilder til nyttig kunnskap. Øv deg på å bruke én eller to timer i uken bare for å holde deg informert om bransjenyheter – Det vil gi deg trygghet ved å vite at du gjør det rette for å holde applikasjonene dine sikret.