Threat Hunting

Hunting
Published

November 27, 2024

För att skydda sina servrar bör man givetvis uppgradera alla komponenter med jämna mellanrum och bevaka CVE:s för att kunna patcha allvarliga luckor som dokumenterats. Ofta finns dock förutsättningar som gör att detta blir för dyrt eller omöjligt av andra skäl. Men det går att göra ganska mycket med små medel för att säkra upp en web-applikation. Här är en kort beskrivning av hur man kan härda en linux web-server med open source verktyg.

Jag började med att scanna vilka portar som är öppna med nmap. Endast de portar som används bör vara öppna, dvs. 80 och 443 i det här fallet. SSH porten (22) bör endast vara öppen för administratörer, tex via VPN eller white-listade IP-adresser. I det här fallet gick även det att göra connect på ftp-porten (21) trots att den inte var öppen i brandväggen. Det går dock inte att logga in, anslutningen görs och efter några sekunder stängs den igen. Kanske är detta en feature i brandväggen för att göra det svårare att leta efter öppna ftp-servrar! Även om 22 är inte är öppen för allmänheten är det bra med en ett extra skydd i form av fail2ban ifall konfigurationen av brandväggen skulle ändras av misstag. fail2ban har även en Webmin modul vilket för den lättanvänd.

Sedan körde jag verktyget logwatch. Rapporten var >20.000 rader lång! Rotationen av loggarna gör att de har 3 år med historik. Till största del var detta dock för försök att nå URL:er som inte finns på servern. Detta visar att även en relativt okänd server som inte marknadsförs i olika search-motorer utsätts för mängder med attacker. Försöken hade gjorts av ca 300 IP-adresser. Jag gjorde även en undersökning av dessa IP-adresser, mer om detta i en kommande artikel.

Nästa steg var att installera en Web Application Firewall (WAF). ModSecurity är en beprövad WAF med stöd för ett antal olika plattformar. OWASP ger kontinuerligt uppdateringar av regler för ModSecurity som kan laddas ner här. Alla regler går inte att använda med alla web-applikationer så det krävs lite arbete för att konfigurera detta. Jag var tvungen att ta bort en del regler i det här fallet, men de flesta gick att använda. Ett antal undantag var också nödvändiga för att alla sidor skulle fungera. Dessa kan tex läggas in i ett lokalt regelset.

Sedan är det bra att se till att 40x meddelanden inte läcker information. Detta kan tex bero re-write regler. Jag skapade nya 40x meddelanden som endast säger ‘Invalid path’. När jag testade några av de URL:er som angriparna använt får jag svaret ‘Invalid path’. Prestanda är också bättre eftersom ModSecurity hanterar detta effektivt och affärslogiken belastas inte.

ConfigServer Security and Firewall (CSF) är ett bra sätt att konfigurera en lokal brandvägg och få ett antal extra säkerhetsmekanismer på köpet.CSF är open source och det finns även en Webmin modul. Viss konfiguration måste göras, som tex att öppna Webmin porten.

File Integrity Management (FIM) är en central komponent i ett Host Intrusion Detection System (HIDS). Här är aide ett bra open source alternativ. En databas med hashes skapas vid installationen som sedan uppdateras när ny programvara installeras eller uppdateras. Konfigurationen styr vilka bibliotek som ska bevakas så hem-bibliotek och annat som ändras ofta brukar inte bevakas. Det är enkelt att kolla vilka filer som har förändrats sedan senaste uppdatering.

En sista skyddsmekanism, ifall en angripare tar sig igenom övriga skydd är ett Network Intrusion Detections System (NIDS). snort är ett open source alternativ som antingen installeras på web-servern för monitorering real-tid eller så sparar man ner PCAP-filer (tex med TcpDump ) och kör analysen på en separat maskin. En fördel med att göra analysen på en separat maskin är att belastningen minskar på web-servern. Nackdelen är förstås att det blir en fördröjningen tills en eventuell varning når fram. I det här fallet hade snort inget attt rapportera, som tur var! snort har en tjänst där man kan prenumerera på regler som uppdateras kontinuerligt. Här använde jag community reglerna som är gratis.