I de flesta situationer behöver webbapplikationsservrar vara allmänt tillgängliga, vilket gör dem mottagliga för en rad olika faror.
Vissa av dessa faror är förutsägbara och enkla att undvika, medan andra är oväntade och kan överraska dig. För att reducera risken för det sistnämnda, presenterar vi en lista med viktiga rekommendationer för att hålla webbapplikationsservrar så säkra som möjligt.
Innan vi går in på tipsen är det viktigt att förstå att en webbapplikationsserver inte är en isolerad enhet. Servern är den centrala delen i en webbapplikationsmiljö som möjliggör drift och hantering av en webbapplikation. För att uppnå säkerhet måste du därför ta hänsyn till alla komponenter som interagerar med servern och skydda hela webbapplikationsmiljön.
En typisk miljö för att hosta och köra webbapplikationer inkluderar operativsystemet (t.ex. Linux, Windows), webbservermjukvaran (t.ex. Apache, Nginx) och en databasserver. Om någon av dessa delar komprometteras, kan angripare få tillgång och utföra skadliga handlingar.
Ett första och grundläggande råd för att skydda en sådan miljö är att studera säkerhetsriktlinjerna och rekommendationerna för varje enskild komponent. Med det sagt, låt oss gå igenom några förnuftiga säkerhetsprinciper som är tillämpliga i de flesta webbapplikationsmiljöer.
Brandväggen – förklarad
Du kanske känner dig frestad att snabbt avfärda detta avsnitt med tanken: ”Jag har redan en brandvägg som skyddar mitt nätverk”. Men det kan vara bra att stanna upp ett tag.
Din brandvägg kan ta hand om nätverkets yttre gräns, hålla dåliga aktörer ute och goda inne, men den kan lämna en öppning för angripare att tränga in i din webbapplikationsserver.
Hur går det till?
Enkelt: din nätverksbrandvägg måste som minimum tillåta inkommande trafik på portarna 80 och 443 (d.v.s. HTTP och HTTPS) och har inte koll på vem eller vad som passerar genom dessa portar.
Det du behöver för att skydda din applikation är en webbapplikationsbrandvägg (WAF), som specifikt granskar webbtrafik och blockerar alla försök att utnyttja sårbarheter, som cross-site scripting eller kodinjektion. En WAF fungerar som ett typiskt antivirus- eller antimalwareprogram: den letar efter kända mönster i dataflödet och blockerar det när den upptäcker en skadlig förfrågan.
För att vara effektiv måste WAF:s databas uppdateras kontinuerligt med de senaste hotmönstren, för att kunna blockera dem. Problemet med mönsterbaserat attackskydd är att din webbapplikation kan vara en av de första målen för en ny typ av hot som din WAF ännu inte är medveten om.
Av dessa anledningar behöver din webbapplikation ytterligare skyddslager utöver nätverkets brandvägg.
Sök efter specifika webbsårbarheter
Tro inte att din webbapplikationsserver är säker bara för att din nätverkssäkerhetsskanner säger det.
Nätverksskannrar kan inte upptäcka applikationsspecifika svagheter. För att identifiera och åtgärda dessa sårbarheter måste du utsätta applikationerna för en rad tester och granskningar, som penetrationsprovning, black-box-scanning och granskning av källkod. Ingen av dessa metoder är dock helt vattentäta. Helst bör du genomföra så många av dem som möjligt för att eliminera alla svagheter.
Säkerhetsskannrar, som Invicti, säkerställer exempelvis att ingen kod som kan utnyttjas når produktionsmiljön. Men det kan finnas logiska sårbarheter som bara kan upptäckas genom manuell granskning av koden. Manuell granskning är, förutom att det är kostsamt, en mänsklig och därför osäker metod. En bra idé för att utföra den här typen av granskning utan att spendera för mycket pengar är att integrera den i utvecklingsprocessen, främst genom att utbilda dina utvecklare.
Utbilda dina utvecklare
Utvecklare tenderar att tro att deras applikationer körs i idealiska miljöer, där resurserna är obegränsade, användare inte gör misstag och det inte finns några personer med onda avsikter. Tyvärr måste de ibland konfronteras med verkliga problem, speciellt de som handlar om informationssäkerhet.
När du utvecklar webbapplikationer måste programmerare vara medvetna om och implementera säkerhetsmekanismer för att garantera att den är fri från sårbarheter. Dessa säkerhetsmekanismer bör ingå i den guide för bästa praxis som utvecklingsteamet måste följa.
Kvalitetsgranskning av programvara används för att säkerställa efterlevnad av god praxis. Bästa praxis och granskning är de enda metoderna för att upptäcka logiska sårbarheter, som (till exempel) att skicka okrypterade och synliga parametrar inuti en URL, som en angripare enkelt kan ändra för att utföra vad de önskar.
Stäng av onödig funktionalitet
Förutsatt att webbapplikationerna är så felfria som möjligt och webbmiljön är säker, låt oss se vad som kan göras på själva servern för att skydda den mot attacker.
Ett grundläggande råd är att reducera antalet potentiellt sårbara ingångspunkter. Om angripare kan utnyttja någon av komponenterna i webbservern kan hela webbservern hamna i fara.
Gör en sammanställning av alla öppna portar och aktiva tjänster eller demoner på din server och stäng, inaktivera eller avinstallera de onödiga. Servern ska inte användas för något annat än att köra dina webbapplikationer, så överväg att flytta all ytterligare funktionalitet till andra servrar i ditt nätverk.
Använd separata miljöer för utveckling, testning och produktion
Utvecklare och testare behöver rättigheter i de miljöer där de arbetar som de inte ska ha på den skarpa applikationsservern. Även om du fullt ut litar på dem kan deras lösenord lätt läcka ut och hamna i fel händer.
Förutom lösenord och behörigheter finns det ofta bakdörrar, loggfiler, källkod eller annan felsökningsinformation i utvecklings- och testmiljöer, som kan exponera känslig information, som databasanvändarnamn och lösenord. Distributionsprocessen för webbapplikationer bör göras av en administratör, som måste se till att ingen känslig information exponeras efter att applikationen har installerats på den skarpa servern.
Samma segregationsprincip måste tillämpas på applikationens data. Testare och utvecklare föredrar alltid att arbeta med riktig data, men det är ingen bra idé att ge dem tillgång till produktionsdatabasen, eller ens en kopia av den. Förutom uppenbara integritetsproblem kan databasen innehålla konfigurationsparametrar som avslöjar interna serverinställningar, såsom slutpunktsadresser eller sökvägar, för att nämna några.
Håll din serverprogramvara uppdaterad
Oavsett hur uppenbart det kan låta är detta en av de mest förbisedda uppgifterna. SUCURI upptäckte att 59 % av CMS-applikationerna var föråldrade, vilket innebär en risk.
Nya hot dyker upp varje dag, och det enda sättet att undvika att de riskerar din server är att alltid installera de senaste säkerhetsuppdateringarna.
Vi nämnde tidigare att nätverksbrandväggar och nätverkssäkerhetsskannrar inte är tillräckliga för att förhindra attacker mot webbapplikationer. Men de är nödvändiga för att skydda din server mot vanliga cybersäkerhetshot, som DDoS-attacker. Se därför till att du alltid har sådana program uppdaterade och att de effektivt skyddar din affärsapplikation.
Begränsa åtkomst och privilegier
En grundläggande säkerhetsåtgärd är att se till att fjärråtkomsttrafik, som RDP och SSH, är krypterad och tunnelbaserad. Det är också en bra idé att ha en begränsad lista över IP-adresser där fjärråtkomst är tillåten, och att blockera alla försök att logga in på distans från andra IP-adresser.
Administratörer ger ibland tjänstekonton alla möjliga behörigheter eftersom de vet att ”allt kommer att fungera” genom att göra det. Men detta är inte en bra metod, eftersom angripare kan använda sårbarheter i tjänsterna för att tränga in i servern. Om dessa tjänster körs med administrativa rättigheter kan de lägga beslag på hela servern.
En bra balans mellan säkerhet och funktionalitet kräver att varje konto – både inloggningskonton och tjänstekonton – har de privilegier de behöver för att utföra sina uppgifter och inget annat.
Du kan till exempel definiera olika konton för en administratör för att utföra olika uppgifter: ett för att göra säkerhetskopior, ett annat för att rensa loggfiler, andra för att ändra konfigurationen av tjänster och så vidare. Detsamma gäller databaskonton: en applikation behöver normalt bara behörighet att läsa och skriva data, och inte att skapa eller ta bort tabeller. Därför bör den köras med ett konto med begränsade rättigheter för att utföra de uppgifter den behöver.
Håll ett öga på serverloggar
Loggfiler finns där av en anledning.
Administratörer bör övervaka dem regelbundet för att upptäcka misstänkt aktivitet innan den orsakar skada. Genom att analysera loggfiler kan du få fram mycket information som hjälper dig att skydda applikationen bättre. Om en attack inträffar kan loggfiler visa dig när och hur den började, vilket hjälper till att göra bättre skadekontroll.
Du måste också ha en automatiserad rutin för att radera gamla loggfiler eller för att minska föråldrad information, för att förhindra att de konsumerar allt tillgängligt lagringsutrymme på servern.
Bonustips: Håll dig informerad
Det finns mycket gratis och användbar information på internet som du kan använda för din webbapplikation. Missa inte nya inlägg på välrenommerade säkerhetsbloggar (som denna) och håll dig uppdaterad om vad som händer inom säkerhets- och webbbranschen.
Handledningar, kurser, videor och böcker är också källor till användbar kunskap. Försök att avsätta en eller två timmar i veckan bara för att hålla dig informerad om branschnyheter – det ger dig sinnesro att veta att du gör rätt för att skydda dina applikationer.