I de flesta fall måste webbapplikationsservrar vara offentligt tillgängliga, vilket innebär att de utsätts för alla typer av hot.
Många av dessa hot är förutsägbara och lätt att undvika, medan andra är okända och kan fånga dig på osäkerhet. För att minimera risken för det senare fallet erbjuder vi en lista med viktiga tips för att hålla webbapplikationsservrar så säkra som möjligt.
Innan du börjar med tipslistan måste du förstå att en webbapplikationsserver inte är en ö. Servern är den centrala komponenten i webbapplikationsfarmen som möjliggör hosting och drift av en webbapplikation. För att säkra måste du därför ta hänsyn till alla komponenter som omger den och säkra hela webbapplikationsmiljön.
En grundläggande miljö för att vara värd och köra webbapplikationer inkluderar operativsystemet (Linux, Windows), webbservermjukvaran (Apache, Nginx), en databasserver. Om någon av dessa komponenter bryts in kan angripare få åtkomst och utföra alla skadliga åtgärder de vill.
Ett första och grundläggande tips för att säkra en miljö som den som beskrivs ovan är att läsa säkerhetsriktlinjerna och listan över bästa praxis för var och en av komponenterna. Med detta sagt, låt oss granska ett antal sunt förnuftiga säkerhetsriktlinjer som gäller för nästan alla webbapplikationsmiljöer.
Innehållsförteckning
Brandväggen avmystifierades
Du kan bli frestad att snabbt kontrollera det här objektet och tänka, ”lyckligt, jag har redan en brandvägg som skyddar mitt nätverk.” Men du bör hålla i dina hästar.
Din brandvägg kanske tar hand om ditt nätverks gränser, håller de onda ute och de goda inne, men den lämnar säkert en dörr vidöppen för angripare att bryta sig in i din webbapplikationsserver.
Hur?
Enkelt: din nätverksbrandvägg måste åtminstone tillåta inkommande trafik på portarna 80 och 443 (det vill säga HTTP och HTTPS), och vet inte vem eller vad som passerar genom dessa portar.
Det du behöver för att skydda din applikation är en brandvägg för webbapplikationer (WAF) som specifikt analyserar webbtrafik och blockerar alla försök att utnyttja sårbarheter som skript över webbplatser eller kodinjektion. En WAF fungerar som ett typiskt antivirus och antimalware: den letar efter kända mönster i dataströmmen och blockerar den när den upptäcker en skadlig begäran.
För att vara effektiv behöver WAF ha sin databas ständigt uppdaterad med nya hotmönster, för att kunna blockera dem. Problemet med mönsterbaserat attackförebyggande är att din webbapplikation kan vara ett av de första målen för ett nytt hot som din WAF ännu inte är medveten om.
Av dessa skäl behöver din webbapplikation ytterligare skyddsskikt förutom nätverkets brandvägg.
Sök efter webbspecifika sårbarheter
Återigen, tro inte att din webbapplikationsserver är sårbar bara för att din nätverkssäkerhetsskanner säger det.
Nätverksskannrar kan inte upptäcka programspecifika sårbarheter. För att upptäcka och eliminera dessa sårbarheter måste du sätta applikationerna under en serie tester och granskningar, såsom penetrationstester, svart låda-skanning och källkodsgranskning. Ingen av dessa metoder är dock skottsäker. Helst bör du utföra så många av dem som möjligt för att eliminera alla sårbarheter.
Till exempel säkerhetsskannrar, som Invicti, se till att ingen exploateringsbar kod kommer till produktionsmiljön. Men det kan finnas logiska sårbarheter som bara kan upptäckas genom manuell kodgranskning. Manuell revision är, förutom att det kostar mycket, en mänsklig och därför felbenägen metod. En bra idé att göra den här typen av revision utan att slösa mycket pengar är att bädda in det i utvecklingsprocessen, mestadels genom att utbilda dina utvecklare.
Utbilda dina utvecklare
Utvecklare tenderar att tro att deras applikationer körs i idealiska världar, där resurserna är obegränsade, användare inte gör misstag och det finns inga människor med hänsynslösa avsikter. Tyvärr behöver de någon gång möta verkliga problem, särskilt de som gäller informationssäkerhet.
När du utvecklar webbapplikationer måste kodare känna till och implementera säkerhetsmekanismer för att säkerställa att den är fri från sårbarheter. Dessa säkerhetsmekanismer bör vara en del av guiden för bästa praxis som utvecklingsteamet måste följa.
Kvalitetsrevision av programvara används för att säkerställa efterlevnad av bästa praxis. Bästa tillvägagångssätt och granskning är de enda sätten att upptäcka logiska sårbarheter, som (till exempel) att skicka icke-krypterade och synliga parametrar inuti en URL, som en angripare lätt kan ändra för att göra vad han eller hon vill.
Stäng av onödig funktionalitet
Förutsatt att webbapplikationerna är så felfria som möjligt och webbfarmen är säkrad, låt oss se vad som kan göras på själva servern för att skydda den från attacker.
Ett grundläggande sunt förnuftstips är att minska antalet potentiellt sårbara ingångspunkter. Om angripare kan utnyttja någon av komponenterna i webbservern kan hela webbservern vara i fara.
Gör en lista över alla öppna portar och körande tjänster eller demoner på din server och stäng, inaktivera eller stäng av de onödiga. Servern ska inte användas för något annat ändamål ä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 privilegier på de miljöer de arbetar i som de inte ska ha på live-applikationsservern. Även om du litar blint på dem kan deras lösenord lätt läcka och hamna i oönskade händer.
Förutom lösenord och privilegier, i utvecklings- och testmiljöer, finns det vanligtvis bakdörrar, loggfiler, källkod eller annan felsökningsinformation som kan avslöja känslig data, så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 installation av applikationen på liveservern.
Samma segregationskoncept måste tillämpas på applikationens data. Testare och utvecklare föredrar alltid riktiga data att arbeta med, men det är inte en bra idé att ge dem tillgång till produktionsdatabasen, eller ens till 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 ett par.
Håll din serverprogramvara uppdaterad
Hur självklart det än kan tyckas är detta en av de mest förbisedda uppgifterna. SUCURI fann att 59 % av CMS-applikationerna var föråldrade, vilket är riskfritt.
Nya hot dyker upp varje dag, och det enda sättet att förhindra att de äventyrar din server är att alltid installera de senaste säkerhetskorrigeringarna.
Vi nämnde tidigare att nätverksbrandväggar och nätverkssäkerhetsskannrar inte är tillräckliga för att förhindra attacker på webbapplikationer. Men de är nödvändiga för att skydda din server från vanliga cybersäkerhetshot, som DDoS-attacker. Så se till att du alltid har sådana applikationer uppdaterade och att de effektivt skyddar din affärsapplikation.
Begränsa åtkomst och privilegier
En grundläggande säkerhetsåtgärd är att hålla fjärråtkomsttrafik – såsom RDP och SSH – krypterad och tunnlad. Det är också en bra idé att hålla en reducerad lista över IP-adresser där fjärråtkomst är tillåten, och se till att alla försök att logga på distans från någon annan IP är blockerad.
Administratörer ger ibland tjänstekonton alla möjliga privilegier eftersom de vet att genom att göra det ”allt kommer att fungera.” Men detta är inte en bra praxis eftersom angripare kan använda sårbarheter i tjänsterna för att penetrera servern. Om dessa tjänster körs med administratörsbehörighet kan de lägga beslag på hela servern.
En bra balans mellan säkerhet och praktiska funktioner kräver att varje konto – både inloggningskonton och tjänstekonton – har de privilegier det behöver för att utföra sitt jobb, och inget annat.
Du kan till exempel definiera olika konton för en administratö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 för databaskonton: ett program behöver vanligtvis bara behörigheterna för att läsa och skriva data, och inte för att skapa eller släppa tabeller. Därför bör det köras med ett konto med begränsade privilegier för att utföra de uppgifter den behöver utföra.
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 beteende innan det gör någon skada. Genom att analysera loggfiler kan du avslöja mycket information för att hjälpa dig att bättre skydda applikationen. Om en attack skulle inträffa kan loggfiler visa dig när och hur det började, vilket hjälper till att göra bättre skadekontroll.
Du måste också ha en automatiserad procedur för att radera gamla loggfiler eller för att beskära föråldrad information, för att förhindra dem från att konsumera 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 något nytt inlägg på välrenommerade säkerhetsbloggar (som den här) och håll dig informerad om vad som händer inom säkerhets- och webbbranschen.
Handledningar, kurser, videor och böcker är också källor till användbar kunskap. Träna på att spendera en eller två timmar i veckan bara för att hålla dig informerad om branschnyheter — Det ger dig sinnesfrid att veta att du gör rätt för att hålla dina applikationer säkra.