Oppsett av Brannmur for Servere: Beskytt Serveren mot DDoS og Bots

Oppsett av brannmur for servere er prosessen med å la kun nødvendige porter være åpne og blokkere all unødvendig tilgang; det utgjør det første forsvarslaget mot DDoS, brute force og skadelig bot-trafikk. I praksis er målet å begrense SSH-tilgang, åpne webtjenester på en kontrollert måte, begrense mistenkelige forespørseler med hastighetsbegrensning, overvåke logger, og filtrere trafikk før den når serveren med hjelp av overliggende beskyttelser som CDN/WAF.

Når du åpner en webserver for internett, kan du på få minutter bli utsatt for portskanninger, SSH-forsøk, sårbarhets-boter og falske brukeragenter. Spesielt i strukturer som kjører WordPress, e-handel, paneler, API-er eller spillservere, er brannmur ikke bare et teknisk valg, men en nødvendighet for kontinuitet. I denne guiden vil vi sette opp en brannmurarkitektur trinn for trinn for Linux-servere; vi vil se på UFW, firewalld, nftables, Fail2ban, webapplikasjonsbrannmur og tilnærmingen til DDoS-reduksjon.

La oss begynne med en viktig realitet: En lokal serverbrannmur kan ikke alene stoppe store DDoS-angrep. Når angrep med en kapasitet på 20 Gbps, 80 Gbps eller mer når datasenteret eller nettverksinfrastrukturen, kan pakkene fylle opp båndbredden før de når regelsettet på operativsystemet ditt. Derfor er den riktige tilnærmingen lagdelt sikkerhet: DDoS-beskyttelse på leverandørnivå, CDN/WAF, brannmur på operativsystemnivå, applikasjons-hastighetsbegrensning, og regelmessig logganalyse må samarbeide. For riktig valg av infrastruktur kan du se på Hostragons VPS- og VDS-serverløsninger for serverløsninger og Hostragons webhostingpakker for sikre hostingalternativer.

Hva Gjør en Serverbrannmur?

En serverbrannmur er et sikkerhetslag som filtrerer nettverkstrafikk basert på kilde-IP, mål-IP, port, protokoll, tilkoblingsstatus og i noen tilfeller pakkens egenskaper. Med et enkelt eksempel; for nettstedet ditt bør portene 80 og 443 være åpne, men databasens port 3306 bør ikke være åpen for internett. Å tillate tilgang til port 22 for SSH fra alle bør unngås; det er tryggere å kun tillate tilkoblinger fra kontorets IP-adresse.

Hovedmålet med brannmuren er ikke å magisk eliminere alle angrep. Det egentlige målet er å redusere angrepsflaten. Jo mindre angrepsflaten er, desto færre alternativer har angriperen. For eksempel kan en nyopprettet Linux-server ha SSH, webpanel, e-posttjeneste, database, overvåkningsagenter og testtjenester åpne samtidig. Hver av disse genererer en egen risiko. En godt konfigurert brannmur fungerer etter prinsippet "nekt som standard, tillat det som er nødvendig".

Forstå DDoS og Bot-trafikk

Hva Gjør DDoS-angrep Spesielle?

DDoS, eller distribuerte tjenestenektangrep, har som mål å gjøre en tjeneste utilgjengelig ved å oversvømme den med intens trafikk fra mange kilder. Angrepet kan noen ganger fylle opp båndbredden, noen ganger forbruke CPU og RAM-ressurser på serveren, eller aktivere kostbare prosesser på applikasjonsnivå. For eksempel kan en liten applikasjonsserver som mottar 50.000 HTTP-forespørsel per sekund, bli utilgjengelig ikke fordi nettverkslinjen er fylt opp, men på grunn av PHP-FPM, Node.js eller databaseforbindelsespoolen.

Er Bots Alltid Dårlige?

Nei. Googlebot, Bingbot og noen overvåkningsboter er nyttige. Men skadelige bots utfører oppgaver som scanning av administrasjonspaneler, åpen katalog-søk, skjema-spam, kopiering av innhold, misbruk av XML-RPC, oppretting av falske kontoer og login-forsøk. Derfor er målet med botforvaltning ikke å blokkere alle bots, men å skille dem etter atferd. Høye feilprosent, for mange forespørseler på kort tid, overskrifter som ikke oppfører seg som ekte nettlesere, og mistenkelige URL-mønstre er viktige signaler.

Kontrolliste Før Oppsett

Når du skriver brannmurregler på en live-server, er den største risikoen å låse deg ute fra serveren. Derfor er det nødvendig å gjøre en kort forberedelse før du gjør endringer. Nedenfor er en kontrolliste for en sikker startmetode som ofte brukes i produksjonsmiljøer.

• Ikke lukk aktive SSH-økter; test med en annen terminal.
• Sjekk at serverleverandøren din tilbyr konsoll, VNC eller gjenopprettingsadgang.
• List opp eksisterende åpne porter: gjennomgå utdataene fra ss -tulpn eller netstat -tulpn.
• Noter hvilke porter web, e-post, DNS, database, panel og overvåkningstjenester bruker.
• Hvis du bruker IPv6, planlegg også IPv6-brannmurregler.
• Implementer først tillatelsesregler, deretter nektelsesregler.
• Sørg for at regelsettet er permanent; det skal ikke forsvinne ved omstart av serveren.

For eksempel, i en typisk server som bare hoster nettsteder, er porter som vanligvis må være åpne for omverdenen ofte 80, 443 og en begrenset SSH-port. Hvis e-postserveren ikke kjører, er det ikke nødvendig for porter som 25, 465, 587, 993 å være åpne. Hvis databasen kun brukes fra samme server, bør porter som 3306 eller 5432 være lukket for omverdenen.

Hvilket Brannmurverktøy Bør Du Velge?

I Linux-verdenen finnes det flere verktøy, og de fleste bruker den samme kjernefiltreringsinfrastrukturen, men med ulik brukervennlighet. For nybegynnere er UFW enkelt og raskt. I bedrifts- eller Red Hat-baserte systemer er firewalld vanlig. For mer avanserte scenarier tilbyr nftables en moderne og fleksibel struktur. Tabellen nedenfor gjør det lettere å velge.

Trinn-for-Trinn Oppsett av Serverbrannmur

1. Identifiser Åpne Porter og Tjenester

Det første steget er å se hva som er åpent. Kommandoen ss -tulpn på en Linux-server viser hvilke tjenester som lytter på hvilke porter. For eksempel, hvis nginx lytter på 0.0.0.0:80 og 0.0.0.0:443, betyr det at webtrafikk aksepteres fra alle grensesnitt. Hvis MariaDB lytter på 0.0.0.0:3306, er dette ofte risikabelt; de fleste nettsteder bør ha databasen som kjører på 127.0.0.1.

Den praktiske regelen her er: Ingen tjenester som ikke skal være tilgjengelige fra internett bør lytte på 0.0.0.0. Det er bedre å rette opp tjenestekonfigurasjonen først og deretter stenge dem med brannmuren. For selv om brannmuren er deaktivert, bør tjenesten ikke være åpen for omverdenen.

2. Sett Standardpolitikken til Nekt

I sikre regelsett blir standard innkommende trafikk nektet, mens utgående trafikk slippes gjennom etter behov. Denne tilnærmingen forhindrer at tjenester som settes opp senere utilsiktet blir eksponert for internett. I en Ubuntu-server som bruker UFW, er logikken som følger: først tillates SSH, deretter åpnes 80 og 443, deretter settes standard innkommende politikk til nekt, og brannmuren aktiveres.

Eksempelstrøm: Tillat SSH for administrasjonens IP-adresse, åpne HTTP og HTTPS-trafikk, lukk unødvendige porter, så aktiver. Å åpne brannmuren uten å gi SSH-tillatelse er en av de vanligste feilene, spesielt på eksterne servere.

3. Begrens SSH-tilgang

SSH er en av tjenestene som angripere ofte målretter mot. En server med standard port 22 åpen kan bli utsatt for hundrevis eller tusenvis av passordforsøk per dag. Den sikreste tilnærmingen er å begrense SSH-tilgang til bestemte IP-adresser. Hvis du bruker fast IP, bør du kun tillate kontoret eller VPNs IP-adresse. Hvis du ikke har fast IP, bør du i det minste bruke nøkkelbasert autentisering og deaktivere passordinnlogging.

• Deaktiver direkte SSH-innlogging med root.
• Bruk SSH-nøkkel i stedet for passord.
• Begrens brukere med AllowUsers eller AllowGroups.
• Bruk Fail2ban for automatisk å blokkere mislykkede forsøk.
• Hvis du bruker et administrasjonspanel, bør porten også være under IP-begrensning.

Å bare endre porten gir ikke sikkerhet, men det kan redusere støyen fra automatiserte bots. Den virkelige beskyttelsen kommer fra IP-begrensning, sterk autentisering og loggovervåking.

4. Åpne Webporter Kontrollert

For de fleste servere som publiserer nettsteder, er porter 80 og 443 nødvendige. Men i dag bør 443, altså HTTPS, være hovedtrafikkporten, mens 80 bare skal brukes for HTTPS-omdirigering. Nettsteder uten SSL-sertifikater kan negativt påvirke både brukerens tillit og SEO-ytelse. Her er Hostragons SSL-sertifikater en naturlig intern lenkemulighet for å lede leseren til en sikker HTTPS-installasjon.

Når du åpner webporter, vær oppmerksom på den virkelige IP-atferden. Hvis du bruker CDN eller omvendt proxy, er det mer effektivt å tillate trafikk til serveren fra CDN IP-områder i stedet for å åpne portene 80 og 443 for hele internett. Dermed kan angriperen ikke få tilgang til webtjenesten direkte, selv om de kjenner den virkelige serverens IP-adresse.

5. Steng Databasen og Interne Tjenester for Internett

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB og lignende tjenester som er åpne for internett, utgjør en alvorlig risiko. Manglende autentisering for Redis, uautorisert indeksadgang for Elasticsearch, eller en åpen administrasjonsport for MongoDB har tidligere ført til mange datalekkasje. Disse tjenestene bør, om mulig, bare lytte på localhost eller private nettverk.

For eksempel, for en WordPress-side som kjører på samme server, er det tilstrekkelig at databasen kjører på 127.0.0.1. Hvis du bruker en separat applikasjons- og databaseserver, bør du kun tillate applikasjonsserverens private IP-adresse. Å la 3306 eller 5432 være åpent for offentlig internett er en kjent feil som bots ofte utnytter.

6. Bruk Fail2ban for å Hindre Brute Force Forsøk

Fail2ban overvåker loggfiler for å oppdage gjentatte mislykkede innloggingsforsøk og blokkerer den aktuelle IP-adressen midlertidig. Jail-definisjoner kan settes opp for SSH, nginx, Apache, Postfix, Dovecot, WordPress-innlogging og noen panel-tjenester. For eksempel, å blokkere en IP-adresse som har 5 mislykkede SSH-forsøk innen 10 minutter i en time, er en enkel, men effektiv start.

Vær forsiktig med å bruke for aggressive regler i Fail2ban-konfigurasjonen. Feil loggmal kan også blokkere ekte brukere. Derfor er det tryggere å holde bantime-verdien rimelig i begynnelsen, overvåke loggene, og deretter gradvis stramme inn reglene.

7. Legg Til Hastighetsbegrensning og Tilkoblingsgrenser

På operativsystemnivå kan hastighetsbegrensning være til hjelp mot DDoS og bot-trafikk. For eksempel, hvis det kommer for mange nye tilkoblinger fra samme IP-adresse per sekund, kan det settes grenser. På websiden kan nginx bruke moduler som limit_req og limit_conn, og Apache kan bruke mod_evasive eller lignende løsninger. På applikasjonsnivå må hastighetsbegrensning legges til for innlogging, søk, handlekurv, betaling og API-endepunkter.

Et konkret eksempel: På en innloggingsside kan 10 forsøk per minutt fra én IP-adresse være rimelig. På et søke-endepunkt kan 2-5 forespørseler per sekund være tilstrekkelig. Hvis du tilbyr API, bør det være en brukerspesifikk token-grense, IP-grense og atferdsanalyse i designet, slik at angriperen ikke kan omgå grensen bare ved å endre IP-adressen.

Eksempel på Sikker Oppsettsscenario med UFW

I en enkel sikker oppstartsscenario på en webserver basert på Ubuntu eller Debian kan man følge denne logikken: først sjekke eksisterende tjenester, tillate SSH-tilgang fra administrasjonens IP-adresse, åpne porter 80 og 443, nekte innkommende trafikk som standard, og verifisere UFW-status. Hvis SSH-tilgangen ikke kan begrenses til fast IP, kan du midlertidig tillate SSH fra alle IP-adresser og deretter gå over til en VPN eller fast IP-løsning.

Eksempel på beslutningssett: La oss si at 203.0.113.10 er administrasjonens IP-adresse. SSH bør kun tillates fra denne IP-adressen. Webtrafikk bør være åpen for alle via 80 og 443. Databasen, Redis, panel og testporter skal være lukket for omverdenen. Denne strukturen er et godt utgangspunkt for mange små og mellomstore bedriftsnettsteder. For korrekt videresending på domenet og DNS-siden kan du bruke Hostragons domenforespørsel og registrering som intern lenke.

Zone-prinsipp med firewalld

firewalld er vanlig i AlmaLinux, Rocky Linux og RHEL-baserte servere. firewalld fungerer med soner. Public zone brukes for grensesnitt åpent mot internett, trusted zone for pålitelige private nettverk, og drop zone for stille å droppe uønsket trafikk. Den viktigste forskjellen er mellom runtime og permanente regler. En runtime-regel blir umiddelbart brukt, men kan gå tapt ved omstart; en permanent regel er varig, men kan kreve en reload.

Når du bruker firewalld i bedriftsmiljøer, kan servicemessige definisjoner forenkle arbeidet. Du kan for eksempel åpne http- og https-tjenester i public zone og sørge for at SSH-tjenesten kun er tilgjengelig fra bestemte kilde-IP-adresser. Hvis administrasjonsnettverket, backup-nettverket og brukertrafikken er på separate grensesnitt, kan sonestrukturen forbedre sikkerheten og lesbarheten.

CDN, WAF og DDoS-beskyttelse på Leverandørnivå

Lokal brannmur tar beslutninger etter at pakkene har nådd serveren. I store DDoS-angrep er målet å filtrere trafikken før den når serveren. CDN, WAF og DDoS-beskyttelse på leverandørnivå er derfor kritisk. CDN leverer statisk innhold fra kantlokasjoner, WAF filtrerer skadelige forespørseler på applikasjonsnivå, og leverandørens beskyttelse demper eller renser store angrep på nettverksnivå.

I en ideell modell går DNS-postene dine gjennom CDN, den virkelige serverens IP-adresse er skjult, og serverens brannmur tillater bare 80 og 443 fra CDN IP-områder. Administrasjonsporter kan bare være tilgjengelige via VPN eller faste IP-adresser. En slik modell reduserer sjansen for direkte angrep på IP-en og lar deg filtrere bot-trafikk før den når applikasjonen. For innhold som omhandler web-sikkerhet og ytelse kan webside akselerering og sikkerhetsguider brukes som lenke.

Applikasjonslagstiltak mot Bots

Bot-blokkering er ikke bare en liste over IP-forbud. Moderne bots kan bruke proxyer, mobile nettverk, datasenter-IP-er og variable brukeragenter. Derfor er det nødvendig med en atferdsfokusert tilnærming. Det bør analyseres dersom det er mange innloggingsforsøk fra samme IP på kort tid, kontinuerlige 404-feilmeldinger, høy belastning på wp-login.php eller xmlrpc.php, og klikkmønstre som avviker fra normale brukere, samt mistenkelige overskrifter.

• Bruk hastighetsbegrensning på innloggings- og registreringsskjemaer.
• Steng eller begrens unødvendig XML-RPC-tilgang.
• Beskyt administrasjonspanelet med forskjellige URL-er, IP-begrensning og flerfaktorautentisering.
• Filtrer mistenkelige user-agent og referer-mønstre på WAF-nivå.
• Bruk CAPTCHA eller usynlige bot-verifikasjonsmekanismer balansert i skjemaene.
• Legg til nøkkel-, signatur-, kvote- og tidsstempelkontroller for API-endepunkter.

Det er viktig å ikke forringe brukeropplevelsen i botforvaltningen. Overdreven CAPTCHA, aggressiv blokkering eller feil landblokker kan skade ekte kunder. Derfor er måling, testing og gradvis stramming den sunneste metoden.

Logganalyse og Alarmregler

Å tro at installasjonen er ferdig er en vanlig feil. Brannmuren er et levende system og må overvåkes jevnlig. SSH-forsøk må overvåkes i auth.log eller secure-filer, unormale forespørselstopper i nginx access logger, økning av 404 og 500-feil i error logger, og CPU- og tilkoblingsantall må overvåkes i systemmetrikker. Selv en enkel alarm kan spare minutter når et angrep starter.

Eksempel på terskelverdier for nybegynnere kan være: 100 eller flere 404-forespørseler fra samme IP innen 5 minutter, mer enn 20 forsøk på innloggingssiden innen 1 minutt, CPU-bruk som overstiger 90% i 10 minutter, og antall tilkoblinger som er tre ganger høyere enn normalt. Disse tersklene varierer fra nettsted til nettsted; det viktigste er å kjenne ditt normale trafikkprofil.

Vanlige Feil og Hvordan Unngå dem

• Aktivere brannmuren uten å gi SSH-tillatelse: Kan føre til tap av tilgang på en ekstern server. Test alltid med en annen økt.
• Glemme IPv6: Tjenester kan forbli åpne via IPv6 selv om IPv4 er lukket.
• La databasen være åpen for internett: Porter som 3306, 5432, 6379 og 9200 blir kontinuerlig skannet av bots.
• Bruke CDN men la den virkelige IP-en være åpen: Angripere kan omgå CDN og angripe serveren direkte.
• Endre regler uten å dokumentere dem: Kan gjøre det vanskelig å forstå hvilken regel som gjør hva i en nødsituasjon.
• Ikke ha en backupplan for tilgang: Hvis det ikke er tilgang til konsollen med en feil regel, kan avbruddet bli langvarig.

Praktisk Eksempel på Brannmurpolitikk

For et lite bedriftsnettsted kan en anvendbar oppsummeringspolitikk være som følger: innkommende trafikk er som standard blokkert; 443 er åpen for alle besøkende; 80 er kun åpen for HTTPS-omdirigering; SSH er kun tilgjengelig fra VPN eller fast administrasjons-IP; databasen ligger på localhost eller privat nettverk; hvis CDN brukes, tillates 80 og 443 kun fra CDN IP-områder; Fail2ban overvåker SSH- og webinnlogginger; logger sendes til et sentralt overvåkningsverktøy.

For en middels stor e-handelsnettsted, i tillegg til dette, kan betalingscallback-IP-er legges til på tillatelseslisten, administrasjonspanelet plasseres bak en VPN, API kan få brukerspesifikke kvoter, WAF kan aktivere SQL-injeksjon og XSS-regler, og en midlertidig filtreringsplan basert på land eller ASN kan utarbeides. Det er viktig at denne planen er skriftlig; å handle etter forhåndsbestemte prosedyrer i stedet for å ta beslutninger under et angrep reduserer nedetid.

Testing: Fungerer Reglene Egentlig?

Det må alltid gjøres testing etter oppsett av brannmur. Skann åpne porter fra et annet nettverk, bekreft at SSH-tilgang kun fungerer fra tillatte IP-adresser, kontroller at nettstedet er tilgjengelig via HTTPS, og sørg for at databasens porter er stengt for eksterne forespørseler. Hvis du bruker CDN, bekreft at forespørseler direkte til den virkelige server-IP-en blir blokkert.

Unngå aggressive skanninger som kan skade produksjonssystemene i testprosessen. Målet er å gjøre sikker verifisering. I tillegg, etter hver endring, eksporter eller notér regelsettet. Dette gjør det lettere å gå tilbake til en tidligere, sunn konfigurasjon hvis problemer oppstår.

Vedlikeholds- og Oppdateringsplan

Server-sikkerhet er ikke en engangsinstallasjon, men en kontinuerlig vedlikeholdsprosess. Når nye tjenester legges til, må portbehovet vurderes på nytt, tillatelser må fjernes når gamle tjenester fjernes, sikkerhetsoppdateringer må implementeres i tide, og logger må kontrolleres periodisk. Å utføre portkontroller minst en gang i måneden og gjennomgå brannmurregler hver tredje måned er en god praktisk start.

I tillegg er backupplanen en del av sikkerhetsstrategien. DDoS-angrep kan kutte tilgang, men ransomware eller uautorisert tilgang kan føre til datatap. Sikker hosting, SSL, domenestyring og backup må vurderes sammen. I denne sammenhengen kan Hva du bør se etter når du velger sikker hosting og hvordan installere SSL-sertifikat være naturlige fortsettelseslenker.

Konklusjon

Oppsett av serverbrannmur gjør ikke serveren helt usynlig for DDoS og bots; men det reduserer angrepsflaten betydelig, senker risikoen for uautorisert tilgang, og gir deg mulighet til å håndtere hendelser på en mer kontrollert måte. De beste resultatene oppnås ved å implementere DDoS-beskyttelse på leverandørnivå, CDN/WAF, strenge portpolitikker, SSH-begrensninger, Fail2ban, hastighetsbegrensning og regelmessig logganalyse sammen.

Hvis du lanserer et nytt prosjekt, er det mye lettere å planlegge brannmurpolitikken fra starten av enn å rette opp i det senere. Når du vurderer server, hosting, domene og SSL-infrastrukturen din på Hostragons, kan du også ta hensyn til sikkerhetsbehovene dine for å skape et mer robust webmiljø. Hvis du trenger det, kan du starte med en liten kontrolliste: lukk åpne porter, begrens SSH, gjør HTTPS obligatorisk, og overvåk logger.

Ofte Stilte Spørsmål

Blokkerer serverbrannmur DDoS-angrep fullstendig?

Nei. Lokal brannmur kan redusere småskala og enkelte protokollnivåangrep, men for store DDoS-angrep må du bruke DDoS-beskyttelse på leverandørnivå, CDN og WAF.

Hvilke porter bør være åpne på webserveren?

På en typisk webserver bør portene 80 og 443 være åpne. SSH-porten bør kun være tillatt for administrasjons-IP-adresser. Databaseserver- og interne tjenesteporter bør være stengt for internett.

Bør jeg bruke UFW eller firewalld?

UFW gir en enklere start for Ubuntu og Debian. firewalld er vanlig i AlmaLinux, Rocky Linux og RHEL-baserte systemer. For avanserte og spesifikke scenarier kan nftables være å foretrekke.

Kan jeg stoppe bot-trafikk bare ved å blokkere IP-er?

Vanligvis nei. Moderne bots bruker forskjellige IP-er og proxyer. I tillegg til IP-blokkering bør hastighetsbegrensning, WAF-regler, atferdsanalyse, CAPTCHA og applikasjonsbaserte kvoter brukes.

Hva er den største risikoen ved å sette opp brannmur?

Den største risikoen er å miste SSH-tilgangen din på grunn av en feil regel. Derfor bør SSH-tillatelse defineres først, testes med en annen økt, og leverandørens konsolltilgang bør være klar.