Installation av Brandvägg för Server: Skydda Servern mot DDoS och Bots

Installation av brandvägg för server är en process där endast nödvändiga portar hålls öppna och all onödig åtkomst blockeras; det utgör det första försvarslagret mot DDoS, brute force och skadlig bottrafik. Målet är i praktiken att begränsa SSH-åtkomst, öppna webbservicer kontrollerat, tillämpa hastighetsbegränsningar på misstänkta förfrågningar, övervaka loggar och, om möjligt, filtrera trafik innan den når servern med hjälp av skydd som CDN/WAF.

När du öppnar en webbserver mot internet kan du på några minuter möta portskanningar, SSH-försök, sårbarhetsbottar och falska användaragenter. Speciellt i fall där WordPress, e-handel, paneler, API eller spelservrar körs, är en brandvägg inte bara en teknisk preferens utan en nödvändighet för kontinuitet. I den här guiden kommer vi att steg för steg bygga en brandväggsarkitektur för Linux-servrar; vi kommer att ta upp UFW, firewalld, nftables, Fail2ban, webbapplikationsbrandväggar och metoder för DDoS-reducering.

Låt oss börja med en viktig verklighet: Den lokala brandväggen på servern kan inte ensamt stoppa stora DDoS-attacker. När en attack på 20 Gbps, 80 Gbps eller mer når datacentret eller nätverksinfrastrukturen kan paketen fylla bandbredden innan de når regelsystemet i ditt operativsystem. Därför är den korrekta metoden att ha ett lagrat säkerhetsskydd: DDoS-skydd på leverantörsnivå, CDN/WAF, brandvägg i operativsystemet, hastighetsbegränsningar för applikationer och regelbunden logganalys måste fungera tillsammans. För att välja lämplig infrastruktur kan du hänvisa till Hostragons VPS- och VDS-serverlösningar och för säkra webbhotellalternativ kan du hänvisa till Hostragons webbhostingpaket.

Vad Gör en Brandvägg för Server?

En serverbrandvägg är ett säkerhetslager som filtrerar nätverkstrafik baserat på käll-IP, mål-IP, port, protokoll, anslutningstillstånd och i vissa fall paketegenskaper. Med ett enkelt exempel; för din webbplats bör portarna 80 och 443 vara öppna, men databasporten 3306 bör inte vara öppen mot internet. Att istället för att tillåta alla att försöka ansluta till port 22 för SSH, är det säkrare att bara tillåta anslutningar från ditt kontors IP-adress.

Brandväggens grundläggande syfte är inte att magiskt förstöra alla attacker. Det verkliga målet är att minska attackytan. Ju mindre attackytan är, desto färre alternativ har angriparen att välja på. Till exempel kan en nyinstallerad Linux-server ha SSH, webbpanel, e-posttjänst, databas, övervakningsagent och testtjänster alla öppna samtidigt. Varje enskild tjänst skapar en separat risk. En välkonfigurerad brandvägg fungerar utifrån principen "förneka som standard, tillåt det som behövs".

Förstå DDoS och Bottrafik

Vad Gör DDoS-attacker Annorlunda?

DDoS, eller distribuerad överbelastningsattack, syftar till att göra en tjänst otillgänglig genom att överösa den med trafik från många källor. Attacken kan ibland fylla bandbredden, ibland konsumera serverns CPU och RAM-resurser, och ibland trigga dyra operationer på applikationslagret. Till exempel kan en liten applikationsserver som tar emot 50 000 HTTP-förfrågningar per sekund bli obrukbar på grund av PHP-FPM, Node.js, eller databasanslutningspooler, även om nätverkslinjen inte är full.

Är Bots Alltid Dåliga?

Nej. Googlebot, Bingbot och vissa övervakningsbottar är användbara. Men skadliga bottar kan genomföra skanningar av administrationspaneler, söka efter öppna kataloger, spamma formulär, kopiera innehåll, utnyttja XML-RPC, skapa falska konton och göra inloggningsförsök. Därför syftar botförvaltning inte till att blockera alla bottar, utan att särskilja dem baserat på beteende. Hög felprocent, ett mycket stort antal förfrågningar på kort tid, rubriker som inte beter sig som en riktig webbläsare, och misstänkta URL-mönster är viktiga signaler.

Checklista Innan Installation

När du skriver brandväggsregler på en aktiv server är den största risken att du låser dig ute från servern. Därför är det viktigt att göra en kort förberedelse innan du gör ändringar. Följande checklista är en säker startmetod som ofta används i produktionsmiljöer.

• Stäng inte av aktiva SSH-sessioner; testa med en andra terminal.
• Se till att din serverleverantör erbjuder konsol-, VNC- eller återställningstillgång.
• Lista de nuvarande öppna portarna: granska utdata från ss -tulpn eller netstat -tulpn.
• Notera vilka portar webb-, e-post-, DNS-, databas-, panel- och övervakningstjänsterna använder.
• Om du använder IPv6, planera säkerhetsregler för IPv6 också.
• Tillämpa först tillåtelse-regler, sedan förneka-regler.
• Se till att regeluppsättningen är permanent; den får inte försvinna när servern startas om.

Till exempel, på en typisk server som endast hostar en webbplats, bör de portar som ska vara öppna ofta vara 80, 443 och en begränsad SSH-port. Om e-postservern inte är aktiv behövs inte portar som 25, 465, 587, 993 vara öppna. Om databasen endast används från samma server bör portar som 3306 eller 5432 vara stängda mot världen.

Vilket Brandväggsverktyg Bör Du Välja?

Det finns flera verktyg i Linux-världen, och de flesta hanterar samma kärnfilterinfrastruktur med olika användarvänligheter. För nybörjare är UFW enkelt och snabbt. I företags- eller Red Hat-baserade system är firewalld vanligt. För mer avancerade scenarier erbjuder nftables en modern och flexibel struktur. Tabellen nedan gör det lättare att välja.

Steg-för-Steg Installation av Brandvägg för Server

1. Identifiera Öppna Portar och Tjänster

Det första steget är att se vad som är öppet. På en Linux-server visar kommandot ss -tulpn vilka tjänster som lyssnar på vilka portar. Om nginx lyssnar på 0.0.0.0:80 och 0.0.0.0:443, betyder det att webbtrafik accepteras från alla gränssnitt. Om MariaDB lyssnar på 0.0.0.0:3306 är det vanligtvis riskabelt; i de flesta webbplatser ska databasen köras på 127.0.0.1.

Den praktiska regeln här är: Ingen tjänst som inte behöver nås från internet bör lyssna på 0.0.0.0. Det är bättre att först korrigera tjänstkonfigurationen och sedan stänga av den med brandväggen. Eftersom även om brandväggen är inaktiverad, bör tjänsten inte vara öppen för omvärlden.

2. Stäng Av Standardpolicyn

I säkra regeluppsättningar avvisas standard trafik, medan utgående trafik släpps fritt baserat på behov. Denna metod förhindrar att senare installerade tjänster oavsiktligt exponeras för internet. På en Ubuntu-server som använder UFW ser logiken ut så här: tillåt först SSH, öppna sedan 80 och 443, ställ in standardintra-policy till deny och aktivera brandväggen.

Ett exempel på flöde: Tillåt SSH för din administratörs IP-adress, öppna HTTP- och HTTPS-trafik, stäng av onödiga portar, och aktivera sedan. Att öppna brandväggen utan att ge SSH-tillstånd är en av de vanligaste misstagen, särskilt på fjärrservrar.

3. Begränsa SSH-åtkomst

SSH är en av de mest riktade tjänsterna av angripare. En server med standardöppen port 22 kan se hundratals eller tusentals lösenordsförsök per dag. Den säkraste metoden är att begränsa SSH-åtkomst till specifika IP-adresser. Om du använder en statisk IP, tillåt endast anslutningar från ditt kontor eller VPN IP-adress. Om du inte har en statisk IP, använd åtminstone nyckelbaserad autentisering och stäng av lösenordsinloggning.

• Stäng av direkt SSH-inloggning som root.
• Använd SSH-nyckel istället för lösenord.
• Begränsa användare med AllowUsers eller AllowGroups.
• Automatiskt blockera misslyckade försök med Fail2ban.
• Om du använder en administrationspanel, begränsa även panelens port med IP.

Att bara byta port ger inte säkerhet, men kan minska automatisk botbrus. Ändå är verkligt skydd baserat på IP-begränsning, stark autentisering och loggövervakning.

4. Öppna Webportar Kontrollerat

För de flesta servrar som publicerar webbplatser är portarna 80 och 443 nödvändiga. Men idag bör 443, det vill säga HTTPS, vara den huvudsakliga trafikporten, och 80 bör endast användas för HTTPS-omdirigering. Webbplatser utan SSL-certifikat påverkar både användarförtroende och SEO-prestanda negativt. Vid denna punkt är Hostragons SSL-certifikat en naturlig intern länkmöjlighet för att vägleda läsarna till en säker HTTPS-installation.

När du öppnar webportar, var uppmärksam på verklig IP-beteende. Om du använder ett CDN eller omvänd proxy, är det mer effektivt att tillåta trafik till din server på portarna 80 och 443 endast från CDN:s IP-områden istället för att öppna dem för hela internet. På så sätt kan en angripare, även om de känner till den verkliga server-IP-adressen, inte komma åt webbservicen direkt.

5. Stäng Databaser och Interna Tjänster mot Internet

Att ha tjänster som MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB, och liknande öppna mot internet utgör en allvarlig risk. Brist på autentisering för Redis, obehörig indexåtkomst för Elasticsearch eller en öppen administrationsport för MongoDB har tidigare lett till många dataläckor. Dessa tjänster bör, om möjligt, endast lyssna på localhost eller ett privat nätverk.

Till exempel, för en WordPress-webbplats som körs på samma server, är det tillräckligt för databasen att köras på 127.0.0.1. Om du använder en separat applikations- och databasserver, tillåt endast den privata IP-adressen för applikationsservern. Att lämna 3306 eller 5432 öppna för allmänheten är en känd fälla som bottar ständigt scannar.

6. Blockera Brute Force Försök med Fail2ban

Fail2ban övervakar loggfiler för att identifiera upprepade misslyckade inloggningsförsök och blockerar den aktuella IP-adressen temporärt. Jail-definitioner kan göras för SSH, nginx, Apache, Postfix, Dovecot, WordPress-inloggning och vissa paneltjänster. Till exempel att blockera en IP-adress som gör 5 misslyckade SSH-försök på 10 minuter i 1 timme är en enkel men effektiv start.

Var försiktig med att använda överdrivet aggressiva regler i Fail2ban-konfigurationen. Fel loggmönster kan blockera verkliga användare. Därför är det mer säkert att hålla bantime-värdet rimligt i det första steget, övervaka loggar och sedan gradvis skärpa reglerna.

7. Lägg till Hastighetsbegränsningar och Anslutningsgränser

Hastighetsbegränsningar på operativsystemsnivå kan vara till hjälp mot DDoS och bottrafik. Om det till exempel kommer ett överdrivet antal nya anslutningar från samma IP-adress kan begränsningar tillämpas. För webbservern kan modulerna limit_req och limit_conn för nginx, eller mod_evasive för Apache, användas. På applikationssidan bör hastighetsbegränsningar också införas för inloggningar, sökningar, korgar, betalningar och API-endpoints.

Ett konkret exempel: På en inloggningssida kan 10 försök per minut per IP vara rimligt. På en sök-API kan 2-5 förfrågningar per sekund vara tillräckligt. Om du erbjuder ett API bör användarbaserade tokenbegränsningar, IP-begränsningar och beteendeanalys utformas tillsammans. På så sätt kan angriparen inte enkelt överskrida hela begränsningen genom att bara byta IP.

Exempel på Säker Installation med UFW

På en Ubuntu- eller Debian-baserad webbserver kan en enkel säker startscenarie byggas med följande logik: kontrollera först de nuvarande tjänsterna, tillåt SSH-åtkomst från din administratörs IP-adress, öppna portarna 80 och 443, avvisa standardintra-trafik och verifiera UFW-statusen. Om din SSH-åtkomst inte kan begränsas till en statisk IP, kan du tillfälligt tillåta SSH från alla IP och sedan gå över till en VPN eller en statisk IP-lösning.

Beslutet kan se ut så här: låt 203.0.113.10 vara administratörens IP-adress. Tillåt SSH endast från denna IP. Webbtrafik ska förbli öppen för alla på 80 och 443. Databas-, Redis-, panel- och testportarna ska vara stängda mot omvärlden. Denna struktur är en bra start för många små och medelstora företagswebbplatser. För att göra rätt omdirigeringar på domän- och DNS-sidan kan du hänvisa till Hostragons domänsökning och registrering.

Brandvägg med firewalld och Zonlogik

Firewalld används ofta på AlmaLinux, Rocky Linux och RHEL-baserade servrar. Firewalld arbetar med begreppet zoner. Public zone används för gränssnitt som är öppna mot internet, trusted zone för pålitliga privata nätverk och drop zone för att tysta avvisa oönskad trafik. Den viktigaste punkten är skillnaden mellan runtime- och permanenta regler. En runtime-regel tillämpas omedelbart men kan försvinna vid omstart; en permanent regel är beständig men kan kräva omladdning.

När du använder firewalld i företagsmiljöer förenklar tjänstbaserade definitioner arbetet. Du kan till exempel öppna http och https-tjänster på public zone och säkerställa att SSH-tjänsten endast är tillgänglig från specifika käll-IP-adresser. Om administrationsnätverket, säkerhetskopieringsnätverket och användartrafiken är på separata gränssnitt kan zonstrukturen öka säkerheten och läsbarheten.

CDN, WAF och DDoS-skydd på Leverantörsnivå

Den lokala brandväggen fattar beslut efter att paketen har nått servern. Vid stora DDoS-attacker är målet att filtrera trafik innan den når servern. Därför är CDN, WAF och DDoS-skydd på leverantörsnivå kritiska. CDN levererar statiskt innehåll från kantlokationer, WAF filtrerar skadliga förfrågningar på applikationslagret, och leverantörens skydd absorberar eller rensar stora attacker på nätverksnivå.

I den ideala modellen passerar dina DNS-poster genom CDN, din verkliga server-IP är dold, och din serverbrandvägg accepterar endast trafik på 80 och 443 från CDN:s IP-områden. Administrationsportarna är tillgängliga via VPN eller statiska IP-adresser. En sådan modell minskar risken för direktattack mot IP och gör att du kan fånga bottrafiken innan den når applikationen. För innehåll som tar upp både webb säkerhet och prestanda kan Guider för webbplatsaccelerering och säkerhet användas.

Applikationslageråtgärder mot Bots

Bot-blockering handlar inte bara om att blockera IP-adresser. Moderna bottar kan använda proxies, mobilnät, datacenter-IP och föränderliga användaragenter. Därför behövs ett beteendefokuserat tillvägagångssätt. Snabbt återkommande inloggningsförsök från samma IP, konstant skanning som ger 404, hög trafik på wp-login.php eller xmlrpc.php, och misstänkta rubriker bör analyseras.

• Använd hastighetsbegränsningar i inloggnings- och registreringsformulär.
• Stäng av eller begränsa onödig XML-RPC-åtkomst.
• Skydda administrationspanelen med olika URL:er, IP-begränsningar och flerfaktorsautentisering.
• Filtrera misstänkta user-agent och referer-mönster på WAF-nivå.
• Använd CAPTCHA eller osynliga botverifieringsmekanismer balanserat i formulär.
• Lägg till nyckel-, signatur-, kvot- och tidsstämpelkontroller på API-endpoints.

Vid botförvaltning är det viktigt att inte påverka användarupplevelsen. Överdriven CAPTCHA, aggressiv blockering eller felaktiga landblockeringar kan skada dina riktiga kunder. Därför är mätning, testning och gradvis skärpning den mest effektiva metoden.

Loggövervakning och Alarmregler

Att tro att installationen är klar är ett vanligt misstag. Brandväggen är ett levande system och måste övervakas regelbundet. SSH-försök bör följas i auth.log eller secure-filen, onormala förfrågningstoppar bör övervakas i nginx access-loggar, och ökningar av 404 och 500 i fel-loggar samt systemmetrik för CPU och anslutningsantal bör också övervakas. Även en enkel alarm kan spara minuter när en attack inleds.

Exempel på tröskelvärden för nybörjare kan vara: mer än 100 404-förfrågningar från samma IP på 5 minuter, mer än 20 försök på inloggningssidan inom 1 minut, CPU-användning som överstiger 90% under 10 minuter, antalet anslutningar som ökar till tre gånger normalt. Dessa trösklar varierar beroende på varje webbplats; det viktiga är att känna till din normala trafikprofil.

Vanliga Misstag och Hur man Undviker Dem

• Aktivera brandväggen utan att ge SSH-tillstånd: Detta kan leda till att du förlorar åtkomst till en fjärrserver. Testa alltid med en andra session.
• Glömma IPv6: Tjänster kan fortfarande vara öppna via IPv6 när IPv4 är stängt.
• Lämna databasen öppen mot internet: Portar som 3306, 5432, 6379 och 9200 skannas ständigt av bottar.
• Använda CDN men lämna den verkliga IP:n öppen: Angripare kan omgå CDN och attackera servern direkt.
• Ändra regler utan dokumentation: Det blir svårt att förstå vilken regel som gör vad i en nödsituation.
• Inte ha en plan för backupåtkomst: Utan konsolåtkomst kan ett felaktigt regel leda till längre driftstopp.

Praktiskt Exempel på Brandväggspolicy

En sammanfattande policy som kan tillämpas för en liten företagswebbplats kan se ut så här: inkommande trafik avvisas som standard; 443 är öppen för alla besökare; 80 är öppen endast för HTTPS-omdirigering; SSH är endast tillgänglig från VPN eller en fast administratörs IP-adress; databasen är lokalhost eller på ett privat nätverk; om CDN används, tillåts 80 och 443 endast från CDN:s IP-områden; Fail2ban övervakar SSH och webb-inloggning; loggar skickas till ett centralt övervakningsverktyg.

För en medelstor e-handelswebbplats kan det läggas till att IP-adresser för betalningscallback placeras på en tillåtelselista, administrationspanelen placeras bakom en VPN, användarbaserade kvoter tillämpas på API, SQL-injektion och XSS-regler aktiveras på WAF, och en tillfällig filtreringsplan baserad på land eller ASN förbereds. Det är viktigt att denna plan dokumenteras; att tillämpa en förutbestämd procedur snarare än att fatta beslut under en attack minskar driftstoppet.

Testa: Fungerar Reglerna Verkligen?

Testning måste göras efter installationen av brandväggen. Utför en portskanning från ett annat nätverk, verifiera att SSH-åtkomst endast fungerar från de tillåtna IP-adresserna, kontrollera att webbplatsen är tillgänglig via HTTPS, och se till att databasporten är stängd för externa förfrågningar. Om du använder CDN, verifiera att direkta HTTP-förfrågningar till den verkliga server-IP:n blockeras.

Under testprocessen, undvik aggressiva skanningar som kan skada produktionssystem. Syftet är att göra en säker verifiering. Dessutom, efter varje ändring, exportera eller notera regeluppsättningen. Detta gör att det blir lättare att återgå till en tidigare fungerande konfiguration om problem uppstår.

Underhåll och Uppdateringsplan

Serverns säkerhet är inte en engångsinstallation utan en regelbunden underhållsprocess. När nya tjänster läggs till bör portbehovet ses över, och när gamla tjänster tas bort bör relaterade tillstånd raderas, säkerhetsuppdateringar tillämpas i tid, och loggar bör kontrolleras periodiskt. Att göra en portkontroll minst en gång i månaden och granska brandväggsreglerna varje kvartal är en bra praxis.

En backup-plan är också en del av säkerhetsstrategin. DDoS-attacker kan avbryta åtkomsten, men ransomware eller obehörig åtkomst kan orsaka dataläckor. Säkert webbhotell, SSL, domänhantering och backup bör övervägas tillsammans. I detta sammanhang är Att tänka på vid val av säker hosting och hur man installerar SSL-certifikat naturliga fortsättningslänkar.

Slutsats

Installation av brandvägg för server gör inte servern helt osynlig för DDoS och bottar; men det minskar attackytan avsevärt, minskar risken för obehörig åtkomst och gör att du kan hantera händelser mer kontrollerat. Det bästa resultatet uppnås genom att ha DDoS-skydd på leverantörsnivå, CDN/WAF, strikta portpolicyer, SSH-begränsningar, Fail2ban, hastighetsbegränsningar och regelbunden loggövervakning tillsammans.

Om du lanserar ett nytt projekt är det mycket lättare att planera brandväggspolicyn från början än att åtgärda den senare. När du utvärderar din server, hosting, domän och SSL-infrastruktur på Hostragons, bör du också tänka på dina säkerhetsbehov för att skapa en mer robust webbmiljö. Om du behöver, börja med en liten checklista: stäng öppna portar, begränsa SSH, gör HTTPS obligatoriskt och övervaka loggar.

Vanliga Frågor

Blockerar serverbrandväggen DDoS-attacker helt?

Nej. Den lokala brandväggen kan minska små och vissa protokollnivåattacker, men för stora DDoS-attacker krävs DDoS-skydd på leverantörsnivå, CDN och WAF.

Vilka portar ska vara öppna på en webbserver?

På en typisk webbserver förblir portarna 80 och 443 öppna. SSH-porten bör endast tillåtas för administratörens IP-adresser. Databas- och interna tjänstportar bör hållas stängda mot internet.

Ska jag använda UFW eller firewalld?

UFW erbjuder en enklare start för Ubuntu och Debian. Firewalld är vanligt på AlmaLinux, Rocky Linux och RHEL-baserade system. För avancerade och specifika scenarier kan nftables väljas.

Kan jag stoppa bottrafik genom att bara blockera IP?

Vanligtvis nej. Moderna bottar använder olika IP och proxies. Förutom IP-blockering bör hastighetsbegränsningar, WAF-regler, beteendeanalys, CAPTCHA och applikationsbaserade kvoter användas.

Vad är den största risken vid installation av brandväggar?

Den största risken är att du oavsiktligt låser din egen SSH-åtkomst på grund av felaktiga regler. Därför bör SSH-tillstånd definieras först, testas med en andra session, och konsolåtkomst från leverantören bör vara redo.