Hoe Om ’n Bediener Firewall Op Te Stel: Jou Bediening Teen DDoS-aanvalle en Botte Te Beskerm

Die opstel van ’n bediener firewall behels om net die noodsaaklike poorte oop te laat en alle ander toegang te blokkeer; dit vorm die eerste verdedigingslyn teen DDoS-aanvalle, brute force-pogings en kwaadaardige botverkeer. Die praktyk behels om SSH-toegang te beperk, webdienste beheersbaar oop te stel, verdagte versoeke te beperk, logboeke dop te hou en, waar moontlik, verkeer reeds via CDN- of WAF-lae te filter voordat dit by die bediener uitkom.

Sodra jy jou webbediener aan die internet koppel, kan jy binne minute begin verwag om gekraakpogings, poortskanderings, kwesbaarheidsbotte en vals gebruikersagente te ervaar. Vir WordPress, e-handel, beheerpanele, API’s of speletjiesbedieners is ’n firewall nie net ’n tegniese opsie nie, maar ’n noodsaaklike maatreël om dienskontinuïteit te verseker. Hierdie gids lei jou stap-vir-stap deur ’n firewall-argitektuur op Linux-bedieners, insluitend UFW, firewalld, nftables, Fail2ban, webtoepassingsfirewalls en DDoS-versagtingstrategieë.

’n Belangrike feit om mee te begin: ’n plaaslike bediener-firewall kan nie hoë-volume DDoS-aanvalle alleen stop nie. As ’n aanval van 20 Gbps, 80 Gbps of hoër jou datasentrum of netwerk oorlaai, kan pakkette jou bedryfstelsel se reëlstel bereik sonder om verwerk te word. Daarom is ’n gelaagde sekuriteitsbenadering die beste: DDoS-beskerming op verskaffervlak, CDN/WAF, bedryfstelsel-firewall, toepaslike koersbeperking en gereelde logontleding werk saam. Vir geskikte infrastruktuur kan jy Hostragons VPS en VDS bediening oplossings besoek, en vir veilige webhostingopsies Hostragons web hosting pakkette.

Wat Doen ’n Bediener Firewall?

’n Bediener-firewall filter netwerkverkeer op grond van bron- en bestemming-IP, poort, protokol, verbindingsstatus en in sommige gevalle pakketkenmerke. Byvoorbeeld, jou webwerf moet poorte 80 en 443 oop hê, maar die databasispoort 3306 moet nie aan die internet blootgestel word nie. Dit is veiliger om SSH-toegang op poort 22 te beperk tot slegs jou kantoor se IP-adres, eerder as om dit vir almal oop te stel.

Die hoofdoel van ’n firewall is nie om ál aanvalle magies te keer nie, maar om die aanvalle-oppervlak te verklein. Hoe kleiner die aanvalle-oppervlak, hoe minder opsies het ’n aanvaller om te probeer. ’n Nuwe Linux-bediener kan byvoorbeeld verskeie dienste soos SSH, webpaneel, e-pos, databasis, monitoringsagteware en toetsdienste oop hê, wat elkeen ’n risiko inhou. ’n Goed gekonfigureerde firewall volg die beginsel “standaard weiering, slegs wat nodig is word toegelaat”.

Verstaan DDoS en Botverkeer

Hoekom is DDoS-aanvalle Anders?

DDoS, of verspreide diensonderbreking, is ’n aanval wat mik om ’n diens onbeskikbaar te maak deur ’n oorweldigende hoeveelheid verkeer van verskeie bronne te stuur. Dit kan bandwydte oorlaai, bediener se CPU en RAM uitput, of duur toepassingsprosesse in werking stel. Byvoorbeeld, ’n klein toepassing wat 50 000 HTTP-versoeke per sekonde ontvang, kan onreaktief raak weens PHP-FPM, Node.js of databasisverbindingpoolbeperkings, selfs al word die netwerk nie oorlaai nie.

Is Botte Altyd Sleg?

Nee. Googlebot, Bingbot en ander moniteringsbotte is nuttig. Maar kwaadwillige botte soek na bestuursgebiede, oopgidse, vormspam, inhoudskraping, XML-RPC-misbruik, vals registrasies en aanmeldpogings. Die doel van botbestuur is nie om alle botte te blokkeer nie, maar om gedrag te onderskei. Tekens soos hoë foutsyfers, baie versoeke binne ’n kort tyd, koptekste wat nie soos ’n werklike blaaier optree nie, en verdagte URL-patrone is belangrike aanduidings.

Kontrolelys Voor Opstelling

Die grootste risiko met firewall-reëls op ’n lewende bediener is om jouself uit te sluit. Maak dus ’n deeglike voorbereiding voordat jy veranderinge maak. Die volgende kontrolelys is ’n veilige beginpunt vir produksie-omgewings.

• Sluit nie jou aktiewe SSH-sessie nie; toets eerder met ’n tweede terminal.
• Maak seker jou bedienerverskaffer bied konsol-, VNC- of hersteltoegang.
• Lys huidige oop poorte met ss -tulpn of netstat -tulpn.
• Neem nota van poorte vir web, e-pos, DNS, databasis, paneel en moniteringsdienste.
• Beplan ook IPv6-firewallreëls as jy IPv6 gebruik.
• Pas eers toelaat-reëls toe, dan weiering-reëls.
• Maak seker die reëlstel word permanent gestoor en bly na herlaai.

’n Tipiese webbediener het meestal net poorte 80, 443 en ’n beperkte SSH-poort oop. As daar geen e-posbediener is nie, hoef poorte soos 25, 465, 587, 993 nie oop te wees nie. ’n Databasis wat slegs lokaal gebruik word, moet nie poort 3306 of 5432 na die internet oop hê nie.

Watter Firewall Gereedskap Kies Jy?

Daar is verskeie Linux-firewall-instrumente wat almal dieselfde kernfiltrering gebruik, maar verskil in gebruikersvriendelikheid. UFW is eenvoudig en vinnig vir beginners. Firewalld is gewild in ondernemingsomgewings en Red Hat-gebaseerde stelsels. Vir gevorderde scenario’s bied nftables ’n moderne en buigsame opsie. Die volgende tabel gee ’n oorsig:

Stap-vir-Stap Bediener Firewall Opstel

1. Identifiseer Oop Poorte en Dienste

Begin deur te kyk watter poorte en dienste oop is. Die opdrag ss -tulpn wys watter programme op watter poorte luister. Byvoorbeeld, as nginx op 0.0.0.0:80 en 0.0.0.0:443 luister, beteken dit webverkeer word van alle koppelvlakke aanvaar. As MariaDB op 0.0.0.0:3306 luister, is dit gewoonlik ’n risiko; meeste webwerwe gebruik 127.0.0.1 vir hul databasis.

’n Praktiese reël is dat geen diens wat nie toeganklik moet wees nie, op 0.0.0.0 moet luister nie. Eerstens moet die diens se konfigurasie reggestel word, dan kan die firewall dit afsluit. Selfs as die firewall afgaan, moet die diens nie oop wees nie.

2. Stel die Standaardbeleid Op “Toegang Weier”

Veilige firewall-reëls weier standaard inkomende verkeer en laat uitgaande verkeer toe soos nodig. Dit voorkom dat nuwe dienste per ongeluk aan die internet blootgestel word. Op ’n Ubuntu-bediener met UFW beteken dit eers SSH toelaat, dan poorte 80 en 443 oopmaak, dan standaard inkomende verkeer weier en die firewall aktiveer.

Byvoorbeeld: Laat SSH toe vanaf jou administrateur se IP, maak HTTP en HTTPS oop, sluit onnodige poorte af, en aktiveer dan die firewall. Om die firewall aan te skakel sonder om SSH toe te laat is ’n algemene fout op afstandbedieners.

3. Beperk SSH-toegang

SSH is ’n hoofdoelwit vir aanvallers. ’n Bediener met poort 22 oop kan honderde of duisende wagwoordpogings per dag sien. Die veiligste metode is om SSH-toegang te beperk tot spesifieke IP-adresse. Indien jy ’n statiese IP het, laat net jou kantoor of VPN toe. Sonder ’n statiese IP, gebruik sleutelgebaseerde verifikasie en sluit wagwoordtoegang uit.

• Deaktiveer direkte root SSH-toegang.
• Gebruik SSH-sleutels in plaas van wagwoorde.
• Beperk gebruikers met AllowUsers of AllowGroups.
• Gebruik Fail2ban om mislukte pogings outomaties te blokkeer.
• Beperk paneeltoegang tot spesifieke IP’s indien van toepassing.

Om net die poort te verander verminder nie die risiko nie, maar kan bot-ruis verminder. Ware beskerming kom van IP-beperking, sterk verifikasie en logmonitering.

4. Maak Webpoorte Beheerdoop

Poorte 80 en 443 is noodsaaklik vir webwerwe, maar 443 (HTTPS) moet die hoofverkeerpoort wees, en 80 moet slegs vir herleiding na HTTPS gebruik word. Webwerwe sonder SSL sertifikate verloor gebruikersvertroue en SEO-waardes. Hier is Hostragons SSL sertifikate ’n natuurlike hulpbron vir veilige HTTPS-opstelling.

As jy ’n CDN of omgekeerde proxy gebruik, maak die bediener se poorte 80 en 443 slegs oop vir verkeer van die CDN se IP-reekse. Dit bied ’n ekstra laag beskerming, selfs as ’n aanvaller die werklike bediener-IP ken, kan hulle nie direk toegang kry nie.

5. Sluit Databasis en Interne Dienste af vir Internettoegang

Databasisse en ander interne dienste soos MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch en MongoDB moet nie aan die internet blootgestel word nie. Gebrek aan verifikasie by Redis, onbevoegde toegang tot Elasticsearch-indekse of oop MongoDB-administrasiepoorte het in die verlede tot baie datalekke gelei. Hierdie dienste moet slegs op localhost of ’n privaat netwerk luister.

Byvoorbeeld, ’n WordPress-webwerf kan sy databasis op 127.0.0.1 laat loop. As jy ’n aparte toepassing- en databasisbediener het, laat net die interne IP toe. Om poorte 3306 of 5432 vir die internet oop te laat, is ’n bekende foute wat botte lok.

6. Gebruik Fail2ban om Brute Force-pogings te Blokkeer

Fail2ban monitor logboeke vir herhaalde mislukte toegangspogings en blokkeer die betrokke IP tydelik. Jy kan dit opstel vir SSH, nginx, Apache, Postfix, Dovecot, WordPress-aanmeldings en selfs paneeldienste. ’n Basiese voorbeeld is om ’n IP wat binne 10 minute 5 mislukte SSH-pogings maak, vir 1 uur te blokkeer.

Wees versigtig met te streng reëls, want dit kan regmatige gebruikers blokkeer. Begin met matige tydperke, monitor logboeke en verskerp reëls geleidelik.

7. Voeg Koersbeperking en Verbindingsgrense by

Koersbeperking op bedryfstelselvlak help om DDoS en botverkeer te beperk. As ’n IP byvoorbeeld te veel nuwe verbindings per sekonde maak, kan dit beperk word. Aan webbedieners kan jy nginx se limit_req en limit_conn modules gebruik, of Apache se mod_evasive of soortgelyke modules. Op toepassingsvlak moet jy beperkings plaas op aanmeldings, soek, inkopieswa, betalings en API-eindpunte.

’n Praktiese voorbeeld: ’n Aanmeldbladsy kan ’n maksimum van 10 pogings per minuut per IP toelaat. ’n Soek-eindpunt kan beperk word tot 2-5 versoeke per sekonde. Vir API’s moet jy gebruikersgebaseerde tokenlimiete, IP-limiete en gedragsanalise kombineer. Dit voorkom dat ’n aanvaller net van IP verander om die limiet te omseil.

Veilige Opstelling met UFW: ’n Voorbeeld

Op ’n Ubuntu- of Debian-webbediener kan jy ’n eenvoudige veilige begin volg: eers dienste kontroleer, dan SSH-toegang vanaf jou administrateur se IP toelaat, poorte 80 en 443 oopmaak, inkomende verkeer standaard blokkeer en UFW aktiveer. As jou SSH-toegang nie tot ’n statiese IP beperk kan word nie, kan jy tydelik alle IP’s toelaat en later na ’n VPN of statiese IP oorskakel.

Byvoorbeeld, laat 203.0.113.10 toe vir SSH, maak webverkeer vir almal oop op 80 en 443, sluit databasis-, Redis-, paneel- en toetspoorte af. Hierdie stel is ’n goeie begin vir klein tot medium ondernemingswebwerwe. Vir korrekte domein- en DNS-installasie kan jy Hostragons domeinnaam navraag en registrasie raadpleeg.

firewalld en Zone-Konsep

Op AlmaLinux, Rocky Linux en RHEL-stelsels is firewalld ’n gewilde opsie. Dit werk met zones: ’n publieke zone vir internetgeskikte koppelvlakke, ’n trusted zone vir betroubare privaat netwerke, en ’n drop zone wat verkeer stilweg verwerp. Dit is belangrik om die verskil tussen runtime (tydelike) en permanente reëls te verstaan. Runtime-reëls werk onmiddellik, maar gaan verlore na herlaai; permanente reëls bly maar kan herlaai benodig.

In ondernemings kan jy dienste maklik aan zones koppel. Byvoorbeeld, HTTP en HTTPS kan in die publieke zone oop wees, maar SSH slegs vanaf spesifieke IP’s. As bestuur-, rugsteun- en gebruikersverkeer verskillende koppelvlakke gebruik, help zones om sekuriteit en leesbaarheid te verbeter.

CDN, WAF en Verskaffervlak DDoS-beskerming

Plaaslike firewall besluit eers nadat pakkette jou bediener bereik, maar by groot DDoS-aanvalle is dit belangrik om verkeer te filter voordat dit jou bediener tref. CDN’s bedien statiese inhoud van naaldlokasies, WAF’s filter kwaadwillige toepassingsverkeer, en verskafferbeskerming hanteer volumetriese netwerk-aanvalle.

Die ideale scenario is dat jou DNS na jou CDN wys, jou bediener se werklike IP verberg word, en jou firewall slegs verkeer vanaf CDN-IP-reekse op poorte 80 en 443 toelaat. Bestuursportale is dan slegs via VPN of statiese IP’s toeganklik. Hierdie model verminder direkte IP-aanvalle en blokkeer botverkeer voordat dit die toepassing bereik. Vir ’n kombinasie van websekuriteit en spoed, sien webwerf versnelling en veiligheid gidse.

Toepassingsvlak Maatreëls Teen Botte

Botbestuur gaan verder as net IP-blokkering. Moderne botte gebruik prokies, mobiele netwerke, datasentrum-IP’s en veranderlike gebruikersagente. ’n Gedragsgebaseerde benadering is noodsaaklik. Ondersoek massiewe aanmeldpogings van dieselfde IP, gereelde 404’s, verhoogde wp-login.php of xmlrpc.php versoeke, ongewone klikpatrone en verdagte koptekste.

• Gebruik koersbeperking op aanmeld- en registrasievorme.
• Sluit of beperk onnodige XML-RPC toegang.
• Beskerp die bestuurspaneel met unieke URL’s, IP-beperking en multi-faktor verifikasie.
• Filter verdagte user-agent en verwysingspatrone op WAF-vlak.
• Balans CAPTCHA en onsigbare botverifikasies op vorms.
• Voeg sleutels, handtekeninge, kwotas en tydstempels by API-eindpunte.

Die gebruikerservaring moet behou word terwyl bots bestuur word. Oormatige CAPTCHA, te aggressiewe blokkering of foutiewe landblokke kan jou regte kliënte benadeel. Meet, toets en verskerp geleidelik.

Logmonitering en Alarmreëls

Om te dink die opstelling is klaar is ’n algemene fout. Firewalls is lewendige stelsels wat gereeld dopgehou moet word. Kyk na auth.log of secure vir SSH-pogings, nginx toeganglogboeke vir abnormale versoekte, foutlogboeke vir 404- en 500-stygings, en monitor stelselstatistieke soos CPU en verbindings. Selfs eenvoudige alarms kan minute se tyd koop tydens ’n aanval.

Beginpunt-drempels kan wees: meer as 100 404’s van dieselfde IP in 5 minute, meer as 20 aanmeldpogings per minuut, CPU-gebruik oor 90% vir 10 minute, of verbindings wat driemaal die normale vlak bereik. Hierdie drempels verskil per webwerf, maar die belangrikste is om jou normale verkeerpatroon te ken.

Algemene Foute en Hoe Om Dit Te Vermy

• Firewall aktiveer sonder om SSH toe te laat: Kan jou toegang tot ’n afstandbediener sny. Gebruik altyd ’n tweede sessie om te toets.
• IPv6 vergeet: IPv6-dienste kan oop bly terwyl IPv4 gesluit is.
• Databasis aan die internet blootgestel: Poorte soos 3306, 5432, 6379 en 9200 word gereeld deur botte geskaan.
• CDN gebruik maar werklike IP ooplaat: Aanvallers kan dan direk die bediener aanval.
• Reëls aanbring sonder dokumentasie: Dit maak dit moeilik om vinnig te verstaan wat elke reël doen.
• Geen rugsteuntoegang beplan nie: As jou reëls jou konsoltoegang blokkeer, kan die herstel lank duur.

’n Praktiese Firewall-Beleid Voorbeeld

Vir ’n klein ondernemingswebwerf kan ’n samevattende beleid soos volg lyk: inkomende verkeer is standaard gesluit; poort 443 is vir almal oop; poort 80 slegs vir HTTPS-herleiding; SSH net via VPN of ’n statiese administrateur-IP; databasis op localhost of ’n privaat netwerk; as ’n CDN gebruik word, is poorte 80 en 443 net oop vir CDN-IP’s; Fail2ban monitor SSH en web-aanmeldings; logboeke word na ’n sentrale moniteringsdiens gestuur.

Vir ’n mediumgrootte e-handelswebwerf kan daar byvoorbeeld ’n witlys van IP’s vir betalings-terugvoer wees, die bestuurspaneel word agter ’n VPN gesit, API’s het gebruikersgebaseerde kwotas, WAF reëls vir SQL-inspuiting en XSS word geaktiveer, en land- of ASN-gebaseerde tydelike filterplanne word opgestel. Hierdie plan moet gedokumenteer wees om tydens ’n aanval vinnige besluitneming toe te laat en stilstand te verminder.

Toetsing: Werk Die Reëls Regtig?

Na die opstelling moet jy altyd toets. Skandeer vanaf ’n ander netwerk vir oop poorte, bevestig dat SSH slegs vanaf toegelate IP’s werk, maak seker jou webwerf is via HTTPS bereikbaar, en kontroleer dat databasispoorte gesluit is. As jy ’n CDN gebruik, probeer om die bediener se ware IP direk te bereik om seker te maak versoeke geblokkeer word.

Moenie aggressiewe skanderings op produksiestelsels doen wat skade kan veroorsaak nie. Die doel is veilige verifikasie. Maak ook seker om jou reëlstel na elke verandering te stoor of dokumenteer, sodat jy maklik terug kan gaan indien ’n probleem ontstaan.

Onderhoud en Opdateringsplan

Bedienersekuriteit is nie ’n eenmalige taak nie, maar ’n voortdurende proses. Elke keer as ’n nuwe diens bygevoeg word, moet poortbehoeftes beoordeel word. Verwyder ou dienste se regte en pas sekuriteitsopdaterings betyds toe. Kontroleer logs gereeld. ’n Maandelikse poortondersoek en ’n kwartaallikse hersiening van firewall-reëls is ’n goeie praktyk.

Rugsteun is ook ’n belangrike deel van jou sekuriteitsbeleid. DDoS kan toegang belemmer, maar ransomware en onbevoegde toegang kan data verloor. Sekuriteit, SSL, domeinbestuur en rugsteun moet saam beplan word. Vir meer inligting, sien Punte om in ag te neem wanneer u veilige hosting kies en Hoe om SSL sertifika te installeer.

Gevolgtrekking

Die opstel van ’n bediener-firewall maak jou bediener nie heeltemal onsigbaar vir DDoS en botte nie, maar dit verminder die aanvalle-oppervlak aansienlik, verlaag risiko’s van ongemagtigde toegang en help jou om meer beheer te hê oor sekuriteitsinsidente. Die beste resultate word behaal deur ’n kombinasie van verskaffervlak DDoS-beskerming, CDN/WAF, streng poortbeleid, SSH-beperking, Fail2ban, koersbeperking en gereelde logmonitering.

As jy ’n nuwe projek aan die gang sit, beplan jou firewallbeleid van die begin af. Op Hostragons kan jy jou bediener, hosting, domein en SSL-infrastruktuur saam evalueer om ’n sterker webomgewing te bou. Begin met ’n eenvoudige kontrolelys: sluit oop poorte, beperk SSH, vereis HTTPS en hou logs dop.

Gereelde Vrae

Kan ’n bediener-firewall DDoS-aanvalle heeltemal stop?

Nee. ’n Plaaslike firewall kan klein of protokolvlak aanvalle verminder, maar vir groot DDoS-aanvalle is verskaffervlak DDoS-beskerming, CDN en WAF nodig.

Watter poorte moet op ’n webbediener oop wees?

Poorte 80 en 443 moet oop wees. SSH moet slegs vir administrateur-IP’s toegelaat word. Databasis- en interne dienspoorte moet gesluit bly vir die internet.

Moet ek UFW of firewalld gebruik?

UFW is makliker vir Ubuntu en Debian. Firewalld is gewild op AlmaLinux, Rocky Linux en RHEL. Vir gevorderde behoeftes is nftables ’n goeie opsie.

Kan ek botverkeer net met IP-blokkering stop?

Gewoonlik nie. Moderne botte gebruik verskeie IP’s en prokies. Koersbeperking, WAF-reëls, gedragsanalise, CAPTCHA en toepassingsvlak kwotas moet saam gebruik word.

Wat is die grootste risiko tydens firewall-opstelling?

Die grootste risiko is om jou eie SSH-toegang te verloor deur verkeerde reëls. Daarom moet jy eers SSH-toegang laat toe, met ’n tweede sessie toets en verskaffer se konsoltoegang beskikbaar hê.