Namestitev požarnega zidu za strežnik: zaščita pred DDoS in botovskim prometom

Namestitev požarnega zidu za strežnik je postopek, ki omogoča odprtje le nujnih vrat in blokira nepotrebne dostope; predstavlja prvo obrambno plast proti DDoS, brute force in škodljivim botom. V praksi je cilj omejiti SSH dostop, nadzorovati odprtost spletnih storitev, omejiti sumljive zahteve, spremljati dnevnike in, kadar je to mogoče, filtrirati promet pred njegovim dostopom do strežnika z uporabo zaščitnih plasti, kot sta CDN/WAF.

Ko odprete spletni strežnik za internet, se lahko v nekaj minutah srečate z iskanjem vrat, poskusi SSH, botovskim napadom in lažnimi uporabniškimi agenti. Zlasti v primerih, kjer delujejo WordPress, e-trgovina, nadzorne plošče, API-ji ali igralni strežniki, je požarni zid nujno potreben za vzdrževanje varnosti. V tem vodniku bomo korak za korakom zgradili arhitekturo požarnega zidu za Linux strežnike; skupaj bomo obravnavali UFW, firewalld, nftables, Fail2ban, spletni požarni zid in DDoS obvladovanje.

Začnimo z pomembno resnico: lokalni požarni zid ne more sam po sebi ustaviti velikih DDoS napadov. Napad s kapaciteto 20 Gbps, 80 Gbps ali več lahko zapolni pasovno širino, preden paketi dosežejo niz pravil vašega operacijskega sistema. Zato je pravilen pristop plastična varnost: zaščita pred DDoS na ravni ponudnika, CDN/WAF, požarni zid operacijskega sistema, omejevanje hitrosti aplikacij in redno analizo dnevnikov je potrebno izvajati skupaj. Za izbiro ustrezne infrastrukture si lahko ogledate Hostragons rešitve za VPS in VDS strežnik in za možnosti varnega gostovanja na spletni strani Hostragons paketi spletnega gostovanja.

Za kaj se uporablja požarni zid za strežnik?

Požarni zid za strežnik je varnostna plast, ki filtrira omrežni promet glede na izvorni IP, ciljni IP, vrata, protokol, stanje povezave in v nekaterih primerih značilnosti paketov. Na preprostem primeru: vaša spletna stran bi morala imeti odprta vrata 80 in 443, medtem ko vrata, kot je 3306 za bazo podatkov, ne bi smela biti odprta za internet. Namesto da pustite vsakomur dostop do vrata 22 za SSH, je bolj varno omogočiti povezave le iz vaše pisarne.

Osnovna naloga požarnega zidu ni, da bi vse napade čarobno uničil. Glavni cilj je zmanjšati napadno površino. Manjša kot je napadna površina, manj možnosti ima napadalec. Na primer, na novo nameščenem Linux strežniku so lahko hkrati odprti SSH, spletna nadzorna plošča, elektronska pošta, baza podatkov, monitoring agent in testne storitve. Vsaka od teh predstavlja dodaten tveganje. Dobro konfiguriran požarni zid deluje po načelu 'privzeto zavrni, dovoli potrebno'.

Razumevanje DDoS in botovskega prometa

Zakaj so DDoS napadi drugačni?

DDoS, torej napad za onemogočanje storitve, si prizadeva, da bi storitev, ki ji je cilj, postala nedostopna zaradi velikega prometa iz številnih virov. Napad včasih zapolni pasovno širino, včasih porabi CPU in RAM strežnika, včasih pa sproži drage postopke na ravni aplikacije. Na primer, manjši strežnik aplikacij, ki prejme 50.000 HTTP zahtevkov na sekundo, se morda ne bo mogel odzvati zaradi PHP-FPM, Node.js ali povezovalnega baz podatkovnega skladišča, tudi če je omrežni pas razpoložljiv.

So boti vedno slabi?

Ne. Googlebot, Bingbot in nekateri boti za spremljanje so koristni. Vendar škodljivi boti izvajajo iskanje po nadzornikih, odprte iskalnike, spamovanje obrazcev, kopiranje vsebine, zlorabo XML-RPC, ustvarjanje lažnih računov in poskuse prijave. Zato cilj upravljanja z botom ni blokiranje vseh botov, temveč ločevanje na podlagi vedenja. Visok delež napak, prekomerna števila zahtevkov v kratkem času, naslovi, ki se ne obnašajo kot pravi brskalniki, in sumljivi URL vzorci so pomembni signali.

Kontrolni seznam pred začetkom namestitve

Pri pisanju pravil požarnega zida na aktivnem strežniku je največje tveganje, da se zaklenete iz strežnika. Zato je potrebno pred spremembami izvesti kratko pripravo. Naslednji kontrolni seznam predstavlja varen pristop, ki se pogosto uporablja v proizvodnih okoljih.

• Ne zaprite aktivne SSH seje; testirajte z drugim terminalom.
• Prepričajte se, da vaš strežniški ponudnik ponuja konzolo, VNC ali dostop za obnovitev.
• Seznanite se z obstoječimi odprtimi vrati: preglejte izhodne rezultate ukazov ss -tulpn ali netstat -tulpn.
• Prijavite, katera vrata uporabljajo storitve spletnega, e-poštnega, DNS, baz podatkov, nadzora in panelov.
• Če uporabljate IPv6, načrtujte tudi pravila požarnega zida za IPv6.
• Najprej uporabite pravila za dovolitev, nato pa pravila za zavrnitev.
• Preverite, ali je niz pravil trajen; ne sme izginjati ob ponovnem zagonu strežnika.

Na primer, na strežniku, ki gosti samo spletno mesto, so vrata, ki morajo biti odprta, pogosto 80, 443 in omejena vrata za SSH. Če elektronski strežnik ne deluje, vrata, kot so 25, 465, 587 in 993, ne bi smela biti odprta. Če je baza podatkov uporabljena samo znotraj istega strežnika, bi morala biti vrata 3306 ali 5432 zaprta pred zunanjo svetom.

Kateri način požarnega zidu izbrati?

V svetu Linuxa obstaja več različnih orodij, ki večina upravlja isto osnovno infrastrukturo filtriranja na različne način.

Za začetnike je UFW preprosto in hitro. V korporativnih ali sistemih, ki temeljijo na Red Hatu, je firewalld razširjen. V bolj naprednih scenarijih nftables ponuja sodoben in prilagodljiv sistem. Spodnja tabela olajša izbiro.

Korak za korakom: nastavitev požarnega zidu za strežnik

1. Določite odprta vrata in storitve

Prvi korak je videti, kaj je odprto. Na Linux strežniku ukaz ss -tulpn prikazuje, katere storitve poslušajo na katerih vratih. Na primer, če nginx posluša na 0.0.0.0:80 in 0.0.0.0:443, pomeni, da sprejema spletni promet iz vseh vmesnikov. Če MariaDB posluša na 0.0.0.0:3306, je to običajno tvegano; večina spletnih mest bi morala biti baza podatkov na 127.0.0.1.

Praktično pravilo je to: nobena storitev, ki ne potrebuje dostopa z interneta, ne bi smela poslušati na 0.0.0.0. Prvič je bolje, da popravite konfiguracijo storitve, nato pa jo zaprete s požarnim zidom. Kajti tudi če je požarni zid onemogočen, storitev ne bi smela biti odprta svetovnemu trgu.

2. Privzeto politiko nastavite kot zaprto

V varnih nizih pravil privzeti prispejoči promet zavrnejo, izhodni promet pa omogočajo na podlagi potreb. Ta pristop preprečuje, da bi naključno odprli storitve na internetu. Pri UFW na Ubuntu strežniku logika zgleda takole: najprej je dovoljen SSH, nato so odprta vrata 80 in 443, nato pa se privzeta politika za prispejoče zavrne in požarni zid je aktiviran.

Primer poteka: Dovoli dostop do SSH za vaš IP naslov, odpri HTTP in HTTPS promet, zapri nepotrebna vrata, nato pa aktiviraj. Odprtje požarnega zidu brez dovoljenja SSH je eden najpogostejših napak, zlasti na oddaljenih strežnikih.

3. Omejite dostop do SSH

SSH je ena izmed storitev, ki so najpogosteje tarča napadalcev. Strežnik z odprtimi vrati 22 lahko čez dan prejme na desetine ali stotine poskusov vnašanja gesel. Najbolj varna izbira je omejitev SSH dostopa na določene IP naslove. Če imate statični IP, dovolite povezave le iz pisarne ali VPN IP naslova. Če statičnega IP ni, vsaj uporabite avtentikacijo na osnovi ključev in izklopite dostop z geslom.

• Onemogočite neposreden SSH dostop za root.
• Uporabite SSH ključ namesto gesla.
• Omejite uporabnike preko AllowUsers ali AllowGroups.
• Za samodejno blokiranje neuspešnih poskusov uporabite Fail2ban.
• Če uporabljate nadzorno ploščo, omejite tudi vrata nadzorne plošče.

Sprememba vrat ne zagotavlja samotne varnosti, lahko pa zmanjša motnje avtomaških botov. Kljub temu resnično zaščito zagotovi IP omejevanje, močna avtentikacija in spremljanje dnevnikov.

4. Počasi odprite spletna vrata

Za večino strežnikov, ki objavljajo spletna mesta, so 80 in 443 vrata nujna. Vendar bi morala postati 443 (HTTPS) primarna vrata za promet, medtem ko bi morala biti 80 uporabljena le za preusmeritev na HTTPS. Spletna mesta brez SSL certifikata škodujejo zaupanju uporabnikov in SEO zmogljivosti. V tem trenutku je Hostragons SSL certifikati priložnost za naravno notranjo povezavo, da usmerite bralce k varni HTTPS nastavitvi.

Pri odpiranju spletnih vrat bodite pozorni na obnašanje realnega IP. Če uporabljate CDN ali obratni proxy, je bolj varno, da svoj strežnik ne odprete neposredno za vso internet, temveč le za promet, ki prihaja iz IP razponov CDN. Tako napadalec, četudi pozna dejanski IP naslov strežnika, ne more neposredno dostopati do spletne storitve.

5. Zaprite dostop do baz podatkov in internimi storitvami

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB in podobne storitve predstavljajo resen tveganje, če so odprte za internet. Pomanjkanje avtentikacije za Redis, nepooblaščen dostop do indeksov za Elasticsearch ali odprta vrata za upravljanje MongoDB so preteklost povzročila številne uhajanja podatkov. Te storitve bi morale poslušati le na localhost ali omrežju za posebno uporabo, kadar je to mogoče.

Na primer, za WordPress naslov, ki deluje na istem strežniku, je dovolj, da baza podatkov posluša na 127.0.0.1. Če uporabljate ločeni aplikacijski strežnik in strežnik za baz podatkov, dovolite le dostop do posebnega IP naslova aplikacijskega strežnika. Odpiranje 3306 ali 5432 za splošni internet predstavlja znano napako, ki jo nenehno skenirajo boti.

6. Uporabite Fail2ban za onemogočanje neuspešnih poskusov za brute force

Fail2ban spremlja dnevniške datoteke in zaznava ponavljajoče se neuspešne poskuse dostopa ter začasno blokira ustrezen IP naslov. Da bi to dosegli, lahko nastavite zapor za SSH, nginx, Apache, Postfix, Dovecot, WordPress prijavo in nekatere storitve nadzorne plošče. Na primer, blokirati IP naslov, ki je v 10 minutah izvedel 5 neuspešnih SSH poskusov, je preprosta vendar učinkovita začetna točka.

Pri konfiguraciji Fail2ban bodite previdni pri uporabi preveč agresivnih pravil. Napačna oblika dnevnika lahko blokira tudi prave uporabnike. Zato je na začetku bolje obdržati razumno vrednost bande, spremljati dnevnike in kasneje postopoma zaostrovati pravila.

7. Dodajte omejevanje hitrosti in meje povezav

Omejevanje hitrosti na ravni operacijskega sistema lahko pomaga pri DDoS in botovskem prometu. Če na primer iz istega IP naslova prihaja izrazito veliko novih povezav na sekundo, se lahko uvede meja. Na strani spletnega strežnika lahko uporabite modules limit_req in limit_conn za nginx, ali mod_evasive ali podobne rešitve za Apache. Na strani aplikacije pa je treba prav tako dodati omejitve hitrosti za prijave, iskanje, nakupne košarice, plačila in API končne točke.

Praktičen primer: 10 poskusov na minuto za en sam IP naslov na prijavni strani se zdi razumljivo. Na iskalnem končnem vprašanju bi 2-5 zahtevkov na sekundo lahko bilo dovolj. Če ponujate API, bi morali zasnovati omejitev na ravni uporabnikov, IP omejitev in analizo vedenja skupaj. Tako napadalec ne more prekiniti celotne omejitve le z izmenjavo IP.

Primer enostavne varne nastavitve z UFW

Tukaj je primer preproste varne nastavitve za spletni strežnik na osnovi Ubuntu ali Debian: najprej preverite obstoječe storitve, dovolite dostop do SSH z vašega upravitelja IP naslova, odprite vrata 80 in 443, zavrnite prispejoči promet privzeto in prepričajte se, da je stanje UFW.

Izbor lahko predstavlja naslednje: 203.0.113.10 je upraviteljev IP naslov. SSH naj prihaja le iz tega naslova. Spletni promet naj bo odprt na 80 in 443 za vse. Baza podatkov, Redis, nadzorna plošča in testna vrata naj bodo zaprta navzven. Ta struktura je dober začetek za številne majhne in srednje velike korporativne spletne strani. Za pravilno preusmeritev na domenu in DNS strani je možno povezati Hostragons preverjanje domen in registracija.

Logika con z firewalld

Firewalld je široko uporabljen na strežnikih, ki temeljijo на AlmaLinux, Rocky Linux in RHEL. Firewalld deluje z konceptom con. Javno območje se uporablja za vmesnike odprte za internet, zaupno območje za zanesljive zasebne mreže in območje padlo za tiho zavrnitev neželenega prometa. Najpomembnejša točka je razlika med runtime in permanent pravili. Runtime pravilo se takoj uporablja, vendar se lahko izgubi ob ponovnem zagonu; permanent pravilo je trajno, vendar morda potrebuje ponovno nalaganje.

Pri uporabi firewalld v korporativnih okoljih poenostavijo definicije na podlagi storitev. Na primer, lahko odprete storitve http in https na javnem območju, ter zagotovite, da je dostop do SSH na voljo le iz določenih IP naslovov. Če je omrežje za upravljanje, omrežje za varnostno kopiranje in promet uporabnikov na ločenih vmesnikih, struktura con povečuje varnost in berljivost.

CDN, WAF in zaščita na ravni ponudnika DDoS

Na lokalnem požarnem zidu odloča, ko paketi prispejo do strežnika. V primerih velikih DDoS napadov pa je cilj filtrirati promet pred njegovim dostopom do strežnika. CDN, WAF in zaščita pred DDoS na ravni ponudnika so zato kritični. CDN dostavlja statične vsebine iz poti, WAF filtrira zlonamerne zahteve na ravni aplikacije, zaščita ponudnika pa absorbira ali očisti obsežne napade na ravni omrežja.

V idealnem modelu se vaši DNS zapisi usmerjajo preko CDN, vaš dejanski IP naslov strežnika je skrit, vaš požarni zid strežnika pa sprejema le 80 in 443 iz IP razpona CDN. Upravljavska vrata pa so dostopna le preko VPN ali statičnega IP. Takšen model zmanjšuje možnost napada na dejanski IP in omogoča, da ukrepate proti botovskemu prometu, preden le-ta doseže aplikacijo. Za vsebine, ki skupaj obravnavajo varnost spletnih strani in zmogljivost, je možno uporabiti vodniki za pospeševanje spletne strani in varnost.

Ukrepanje proti botom na ravni aplikacije

Blokiranje botov ni le zadeva blokiranja IP naslovov. Sodobni boti lahko uporabljajo proxy, mobilne omrežja, podatkovne centre in spremenljive uporabniške agente. Zato je potrebna vedenjska pristop. Zelo veliko poskusov prijave v kratkem času iz istega IP naslova, močno skeniranje, povečana obremenitev wp-login.php ali xmlrpc.php, nenormalen vzorec klikanja in sumljivi naslovi morajo biti analizirani.

• Uporabite omejevanje hitrosti na prijavah in v registracijskih obrazcih.
• Onemogočite nepotrebno dostop do XML-RPC ali ga omejite.
• Zaščitite nadzorno ploščo z drugačnim URL-jem, omejitvijo IP in dvofaktorsko avtentikacijo.
• Filtrirajte sumljive uporabnike-agent in referer vzorce na ravni WAF.
• V obrazcih zmerno uporabljajte CAPTCHA ali mehanizme za preverjanje botov.
• Dodajte kontrole za ključe, podpise, kvote in časovne žige za API končne točke.

Upravljanje botov ne sme poškodovati uporabniške izkušnje. Prekomerna uporaba CAPTCHA, agresivno blokiranje ali napačne blokade držav lahko škodijo vašim pravim strankam. Zato sta merjenje, testiranje in postopno zaostrovanje najboljši pristop.

Spremljanje dnevnikov in pravila alarmov

Meniti, da je namestitev končana, je pogosta napaka. Požarni zid je sistem, ki potrebuje redno spremljanje. Potrebno je preveriti poskuse SSH v auth.log ali secure datoteki, nenormalen promet v dnevnikih dostopa nginx, povečano število 404 in 500 napak v dnevnikih napak, ter spremljati sistemske metrike CPU in število povezav. Enostaven alarm lahko prične napad in vas obvesti v trenutku.

Na začetku bi lahko bile primerne pragovne vrednosti: več kot 100 404 zahtevkov v 5 minutah iz istega IP, več kot 20 poskusov na prijavni strani v 1 minuti, ostati nad 90% porabe CPU za 10 minut, število povezav pa se mora povečati trikrat. Ti pragovi se spreminjajo od spletne strani do spletne strani; pomembno je poznati svoj normalen profil prometa.

Pogoste napake in načini za izogibanje

• Aktivirati požarni zid brez dovoljenja SSH: To lahko povzroči, da izgubite dostop do oddaljenega strežnika. Vedno testirajte z drugo sejo.
• Pozabiti na IPv6: Medtem ko je IPv4 zaprt, lahko storitve ostanejo odprte preko IPv6.
• Pustiti bazo podatkov odprto za internet: Vrata 3306, 5432, 6379 in 9200 se nenehno skenirajo s strani botov.
• Uporaba CDN in pusti dejanski IP odprt: Napadalci lahko obidejo CDN in napadajo strežnik neposredno.
• Spremeniti pravila brez dokumentacije: V nujnih primerih je lahko težko ugotoviti, katero pravilo kaj pomeni.
• Ne ustvariti načrta za rezervni dostop: Brez konzolskega dostopa se lahko ustavi dolg niz izpada.

Praktični primer politike požarnega zidu

Za majhno podjetniško spletno stran lahko velja naslednja povzetek izvedljive politike: prispejoči promet je privzeto zaprt; 443 je odprt za vse obiskovalce; 80 je odprt le za preusmeritev na HTTPS; SSH je dostopen samo iz VPN ali fiksnega IP naslova; baza podatkov je na localhostu ali posebnem omrežju; če uporabljate CDN, so 80 in 443 dovoljeni le za IP razpone CDN; Fail2ban spremlja prijave SSH in spletne prijave; dnevniški zapisi se pošljejo na osrednje orodje za spremljanje.

Za srednje veliko e-trgovinsko spletno stran bi bilo poleg tega treba dovoliti IP naslove za plačilne povratne informacije, postaviti nadzorno ploščo za dostop za VPN, uporabiti omejitve kvote na ravni uporabnikov za API, aktivirati pravila proti SQL injecti in XSS na WAF in razviti načrt za začasno filtriranje na podlagi države ali ASN. Pomembno je, da je ta načrt zapisan; odločanje v trenutku napada namesto da bi se obrnil na vnaprej določene postopke skrajša čas izpada.

Testiranje: ali pravila res delujejo?

Po namestitvi požarnega zida je treba izvesti testiranje. Iz drugega omrežja izvedite skeniranje odprtih vrat, potrdite, da dostop do SSH deluje le z dovoljenimi IP naslovi, preverite dostop do spletnega mesta preko HTTPS in zagotovite, da so vrata baz podatkov zaprta za zunanji dostop. Če uporabljate CDN, pošljite neposredno HTTP zahtevo na dejanski IP strežnika in potrdite, da je dostop blokiran.

Med testiranjem se izogibajte agresivnemu skeniranju, ki bi lahko škodovalo proizvodnim sistemom. Cilj je varna validacija. Prav tako po vsaki spremembi izvozite ali zapišite niz pravil. Tako lahko enostavno vrnete prejšnjo zdravo konfiguracijo v primeru težav.

Načrt vzdrževanja in posodabljanja

Varnost strežnika ni enkraten postopek, temveč postopek rednega vzdrževanja. Nova storitev, ki je dodana, zahteva revizijo potrebnih vrat; ko je stara storitev odstranjena, morajo biti ustrezna dovoljenja izbrisana; varnostne posodobitve je treba pravočasno uporabiti in dnevniki morajo biti redno preverjani. Dobro začetno pravilo je, da izvajate nadzor odprtih vrat najmanj enkrat na mesec in pregledujete niz pravil požarnega zida vsakih tri mesece.

Poleg tega je načrt za varnostno kopiranje del varnostne strategije. Napad DDoS lahko prekine dostop, vendar zlonamerna programska oprema ali nepooblaščen dostop lahko povzročita izgubo podatkov. Varno gostovanje, SSL, upravljanje domen in varnostne kopije bi morale biti obravnavane skupaj. V tem smislu so Kaj upoštevati pri izbiri varnega gostovanja in kako namestiti SSL certifikat naravni povezani povezavi.

Zaključek

Nastavitev požarnega zida za strežnik ne naredi strežnika popolnoma nevidnega za DDoS in botovski promet; vendar resno zmanjša napadno površino, zmanjšuje tveganje nepooblaščenega dostopa in vam omogoča obvladovanje incidentov na bolj nadzorovan način. Najboljši rezultati se dosežejo z izvajanjem zaščite DDoS na ravni ponudnika, CDN/WAF, strogimi politikami vrat, omejevanjem SSH, Fail2banom, omejevanjem hitrosti in rednim spremljanjem dnevnikov skupaj.

Če z novim projektom začnete, je načrtovanje politike požarnega zida na začetku lažje kot popravljanje težav kasneje. Pri Hostragonsu lahko ocenite svoje potrebe glede strežnika, gostovanja, domen in SSL infrastrukture, da ustvarite bolj robustno spletno okolje. Če potrebujete, začnite z majhnim kontrolnim seznamom: zaprite odprta vrata, omejite SSH, naredite HTTPS obvezen in spremljajte dnevnike.

Pogosto zastavljena vprašanja

Ali požarni zid za strežnik povsem preprečuje DDoS napad?

Ne. Lokalni požarni zid lahko zmanjša majhne in nekatere napade na protokolarni ravni, vendar je potrebna zaščita DDoS na ravni ponudnika, CDN in WAF pri večjih obsegih DDoS napadov.

Katera vrata bi morala biti odprta na spletnem strežniku?

Na tipičnem spletnem strežniku ostaneta odprta vrata 80 in 443. Vrata SSH morajo biti dovoljena samo za upravne IP naslove. Vrata za dostop do baz podatkov in notranje storitve morajo biti zaprta za internet.

Ali naj uporabim UFW ali firewalld?

Za Ubuntu in Debian je UFW lažji začetek. Firewalld je pogost na sistemih, ki temeljijo na AlmaLinux, Rocky Linux in RHEL. V naprednih in posebnih scenarijih lahko izberete nftables.

Ali lahko ustavim botovski promet le z blokiranjem IP-jev?

Splošno gledano, ne. Sodobni boti uporabljajo različne IP-je in proxyje. Poleg blokad IP-jev je treba uporabiti tudi omejevanje hitrosti, pravila WAF, analize vedenja, CAPTCHA in omejitve na ravni aplikacij.

Kakšno je največje tveganje pri nastavitvi požarnega zida?

Največje tveganje je, da z napačnim pravilom prekinete lastni dostop do SSH. Zato je potrebno najprej definirati dovoljenja za SSH, testirati z drugo sejo in pripraviti dostop do konzole ponudnika.