I de fleste tilfælde skal webapplikationsservere være offentligt tilgængelige, hvilket betyder, at de er udsat for alle slags trusler.
Mange af disse trusler er forudsigelige og let undgåelige, mens andre er ukendte og kan fange dig uoverskuelig. For at minimere muligheden for dette sidstnævnte tilfælde tilbyder vi en liste over vigtige tips til at holde webapplikationsservere så sikre som muligt.
Før du starter med tiplisten, skal du forstå, at en webapplikationsserver ikke er en ø. Serveren er den centrale komponent i webapplikationsfarmen, der gør hosting og drift af en webapplikation mulig. Derfor, for at sikre, skal du tage højde for alle de komponenter, der omgiver det og sikre hele webapplikationsmiljøet.
Et grundlæggende miljø til hosting og kørsel af webapplikationer inkluderer operativsystemet (Linux, Windows), webserversoftwaren (Apache, Nginx), en databaseserver. Hvis nogen af disse komponenter er brudt ind, kan angribere få adgang og udføre alle de ondsindede handlinger, de ønsker.
Et første og grundlæggende tip til at sikre et miljø som det, der er beskrevet ovenfor, er at læse sikkerhedsretningslinjerne og listen over bedste praksis for hver enkelt af komponenterne. Når det er sagt, lad os gennemgå en række sunde fornuftssikkerhedsretningslinjer, der gælder for næsten alle webapplikationsmiljøer.
Indholdsfortegnelse
Firewallen afmystificeret
Du kan blive fristet til hurtigt at tjekke dette element og tænke, “heldig mig, jeg har allerede en firewall, der beskytter mit netværk.” Men du må hellere holde dine heste.
Din firewall tager sig muligvis af dit netværks grænser, holder de onde ude og de gode inde, men den efterlader helt sikkert en dør åben for angribere til at bryde ind i din webapplikationsserver.
Hvordan?
Simpelt: din netværksfirewall skal som minimum tillade indgående trafik på porte 80 og 443 (det vil sige HTTP og HTTPS), og ved ikke, hvem eller hvad der passerer gennem disse porte.
Det, du skal bruge for at beskytte din applikation, er en webapplikationsfirewall (WAF), der specifikt analyserer webtrafik og blokerer ethvert forsøg på at udnytte sårbarheder såsom cross-site scripting eller kodeinjektion. En WAF fungerer som en typisk antivirus og antimalware: den leder efter kendte mønstre i datastrømmen og blokerer den, når den registrerer en ondsindet anmodning.
For at være effektiv skal WAF have sin database opdateret konstant med nye trusselsmønstre, for at kunne blokere dem. Problemet med mønsterbaseret angrebsforebyggelse er, at din webapplikation kan være et af de første mål for en ny trussel, som din WAF endnu ikke er opmærksom på.
Af disse grunde har din webapplikation brug for yderligere beskyttelseslag udover netværkets firewall.
Scan for web-specifikke sårbarheder
Igen, tro ikke, at din webapplikationsserver er sårbarhedsfri, bare fordi din netværkssikkerhedsscanner siger det.
Netværksscannere kan ikke registrere applikationsspecifikke sårbarheder. For at opdage og eliminere disse sårbarheder skal du sætte applikationerne under en række tests og revisioner, såsom penetrationstests, black box-scanning og kildekodeauditering. Ingen af disse metoder er dog skudsikre. Ideelt set bør du udføre så mange af dem som muligt for at eliminere alle sårbarheder.
For eksempel sikkerhedsscannere, som Invicti, sikre, at ingen udnyttelig kode kommer til produktionsmiljøet. Men der kan være logiske sårbarheder, som kun kan opdages ved manuel kodeauditering. Manuel revision er, udover at det koster meget, en menneskelig og derfor fejltilbøjelig metode. En god idé at lave denne form for revision uden at spilde en masse penge er at integrere det i udviklingsprocessen, for det meste ved at uddanne dine udviklere.
Uddan dine udviklere
Udviklere har en tendens til at tro, at deres applikationer kører i ideelle verdener, hvor ressourcerne er ubegrænsede, brugerne ikke laver fejl, og der ikke er nogen med hensynsløse hensigter. Desværre skal de på et tidspunkt stå over for problemer i den virkelige verden, især dem vedrørende informationssikkerhed.
Når de udvikler webapplikationer, skal kodere kende og implementere sikkerhedsmekanismer for at sikre, at de er fri for sårbarheder. Disse sikkerhedsmekanismer bør være en del af den bedste praksis-vejledning, som udviklingsteamet skal overholde.
Softwarekvalitetsrevision bruges til at sikre overholdelse af bedste praksis. Bedste praksis og revision er de eneste måder at opdage logiske sårbarheder, såsom (for eksempel) at overføre ikke-krypterede og synlige parametre inde i en URL, som en angriber nemt kan ændre for at gøre, hvad han eller hun vil.
Slå unødvendig funktionalitet fra
Forudsat at webapplikationerne er så fejlfrie som muligt, og webfarmen er sikret, så lad os se, hvad der kan gøres på selve serveren for at beskytte den mod angreb.
Et grundlæggende, sund fornuft tip er at reducere antallet af potentielt sårbare indgangspunkter. Hvis angribere kan udnytte nogen af komponenterne på webserveren, kan hele webserveren være i fare.
Lav en liste over alle de åbne porte og kørende tjenester eller dæmoner på din server og luk, deaktiver eller sluk for de unødvendige. Serveren bør ikke bruges til andre formål end at køre dine webapplikationer, så overvej at flytte al yderligere funktionalitet til andre servere i dit netværk.
Brug separate miljøer til udvikling, test og produktion
Udviklere og testere har brug for privilegier på de miljøer, de arbejder på, som de ikke skal have på live-applikationsserveren. Selvom du blindt stoler på dem, kan deres adgangskoder nemt lække og falde i uønskede hænder.
Udover adgangskoder og privilegier er der i udviklings- og testmiljøerne normalt bagdøre, logfiler, kildekode eller andre fejlfindingsoplysninger, der kan afsløre følsomme data, såsom databasebrugernavne og adgangskoder. Webapplikationsimplementeringsprocessen bør udføres af en administrator, som skal sørge for, at ingen følsomme oplysninger afsløres efter installation af applikationen på live-serveren.
Det samme adskillelseskoncept skal anvendes på applikationens data. Testere og udviklere foretrækker altid rigtige data at arbejde med, men det er ikke en god idé at give dem adgang til produktionsdatabasen eller endda til en kopi af den. Udover åbenlyse bekymringer om privatlivets fred kan databasen indeholde konfigurationsparametre, der afslører interne serverindstillinger – såsom slutpunktsadresser eller stinavne, for at nævne et par.
Hold din serversoftware opdateret
Hvor indlysende det end kan virke, er dette en af de mest oversete opgaver. SUCURI fandt, at 59 % af CMS-applikationer var forældede, hvilket er åbent for risiko.
Nye trusler dukker op hver dag, og den eneste måde at forhindre dem i at bringe din server på spil, er altid at installere de nyeste sikkerhedsrettelser.
Vi nævnte før, at netværksfirewalls og netværkssikkerhedsscannere ikke er tilstrækkelige til at forhindre angreb på webapplikationer. Men de er nødvendige for at beskytte din server mod almindelige cybersikkerhedstrusler, såsom DDoS-angreb. Så sørg for, at du altid har sådanne applikationer opdateret, og at de effektivt beskytter din virksomhedsapplikation.
Begræns adgang og privilegier
En grundlæggende sikkerhedsforanstaltning er at holde fjernadgangstrafik – såsom RDP og SSH – krypteret og tunneleret. Det er også en god idé at holde en reduceret liste over IP-adresser, hvorfra fjernadgang er tilladt, og sørg for, at ethvert forsøg på at logge eksternt fra enhver anden IP er blokeret.
Administratorer giver lejlighedsvis servicekonti alle mulige privilegier, fordi de ved, at ved at gøre det “alt vil fungere.” Men dette er ikke en god praksis, da angribere kan bruge sårbarheder i tjenesterne til at trænge ind på serveren. Hvis disse tjenester kører med administratorrettigheder, kan de beslaglægge hele serveren.
En god balance mellem sikkerhed og praktiske forhold kræver, at hver konto – både login-konti og servicekonti – har de privilegier, den skal bruge for at udføre sit job, og intet andet.
For eksempel kan du definere forskellige konti for en administrator til at udføre forskellige opgaver: en til at lave sikkerhedskopier, en anden til at rense logfiler, andre til at ændre konfigurationen af tjenester og så videre. Det samme gælder for databasekonti: en applikation behøver normalt kun tilladelserne til at læse og skrive data og ikke til at oprette eller slette tabeller. Derfor bør den køre med en konto med begrænsede rettigheder til at udføre de opgaver, den skal udføre.
Hold øje med serverlogfiler
Logfiler er der af en grund.
Administratorer bør overvåge dem regelmæssigt for at opdage enhver mistænkelig adfærd, før den gør skade. Ved at analysere logfiler kan du afdække en masse information for at hjælpe dig med at beskytte applikationen bedre. Hvis et angreb skulle ske, kunne logfiler vise dig, hvornår og hvordan det startede, hvilket hjælper med at forbedre skadeskontrol.
Du skal også have en automatiseret procedure til at slette gamle logfiler eller for at beskære forældede oplysninger for at forhindre dem i at optage al tilgængelig lagerplads på serveren.
Bonustip: Hold dig orienteret
Der er en masse gratis og nyttig information på internettet, som du kan bruge til gavn for din webapplikation. Gå ikke glip af noget nyt indlæg på velrenommerede sikkerhedsblogs (som denne) og bliv orienteret om, hvad der sker i sikkerheds- og webindustrien.
Selvstudier, kurser, videoer og bøger er også kilder til nyttig viden. Øv dig i at bruge en eller to timer om ugen bare for at holde dig orienteret om branchenyheder – Det vil give dig ro i sindet ved at vide, at du gør det rigtige for at holde dine applikationer sikret.