Instalarea unui Firewall pentru Server: Protejarea Serverului împotriva DDoS și a Botilor

Instalarea unui firewall pentru server reprezintă procesul de a lăsa deschise doar porturile necesare și de a bloca toate accesările inutile; acesta constituie primul strat de apărare împotriva atacurilor DDoS, forțelor brute și traficului de boturi malițioase. În practică, obiectivul este de a limita accesul SSH, de a deschide serviciile web într-un mod controlat, de a aplica rate limiting pentru cererile suspecte, de a monitoriza jurnalele și, dacă este posibil, de a filtra traficul înainte ca acesta să ajungă la server prin soluții de tip CDN/WAF.

Când expuneți un server web la internet, în câteva minute puteți fi bombardat de scanări ale porturilor, încercări SSH, boturi de vulnerabilitate și user-agents false. În special, pentru structuri care rulează WordPress, comerț electronic, panouri de control, API-uri sau servere de jocuri, un firewall nu este doar o opțiune tehnică, ci o necesitate pentru continuitate. În acest ghid, vom construi o arhitectură de firewall pas cu pas, aplicabilă pe servere Linux; vom aborda UFW, firewalld, nftables, Fail2ban, firewall-uri pentru aplicații web și abordări de reducere a DDoS-ului.

Începem cu un adevăr important: un firewall local pe server nu poate opri atacurile DDoS de volum mare. Atacurile cu o lățime de bandă de 20 Gbps, 80 Gbps sau mai mult pot umple lățimea de bandă înainte ca pachetele să ajungă la setul de reguli din sistemul dumneavoastră de operare. De aceea, abordarea corectă este securitatea stratificată: protecția DDoS la nivelul furnizorului, CDN/WAF, firewall-ul sistemului de operare, rate limiting pentru aplicații și analiza regulată a jurnalele trebuie să colaboreze. Puteți face referire la pagina Solutii de server VPS și VDS Hostragons pentru alegerea infrastructurii adecvate și la pagina Pachetele de web hosting Hostragons pentru opțiuni de găzduire sigură pe site-ul web.

Ce Face un Firewall pentru Server?

Firewall-ul pentru server este un strat de securitate care filtrează traficul de rețea în funcție de IP-ul sursă, IP-ul destinație, port, protocol, starea conexiunii și, în unele cazuri, caracteristicile pachetelor. De exemplu, pentru site-ul dumneavoastră, porturile 80 și 443 ar trebui să fie deschise, dar portul bazei de date 3306 nu ar trebui să fie accesibil de pe internet. Este mai sigur să permiteți accesul pe portul 22 pentru SSH doar de la adresa IP a biroului dumneavoastră, în loc să permiteți oricui să încerce.

Scopul principal al firewall-ului nu este de a distruge magic toate atacurile, ci de a reduce suprafața de atac. Cu cât suprafața de atac este mai mică, cu atât opțiunile pe care le poate încerca un atacator sunt mai puține. De exemplu, pe un server Linux nou instalat, SSH, panoul web, serviciile de email, baza de date, agenții de monitorizare și serviciile de testare pot fi deschise simultan. Fiecare dintre acestea generează un risc separat. Un firewall bine configurat funcționează pe principiul „refuză implicit, permite ce este necesar”.

Înțelegerea DDoS și a Traficului de Boti

De Ce sunt Diferite Atacurile DDoS?

DDoS, adică atacurile de Denial of Service Distribuit, au ca scop să facă serviciul țintă inaccesibil printr-un trafic intens provenit din numeroase surse. Atacul poate umple lățimea de bandă, poate consuma resursele CPU și RAM ale serverului sau poate declanșa procese costisitoare la nivelul aplicației. De exemplu, un server de aplicații mic care primește 50.000 de cereri HTTP pe secundă poate deveni incapabil să răspundă din cauza PHP-FPM, Node.js sau a conexiunilor cu baza de date, chiar dacă linia de rețea nu este complet umplută.

Toți Boti sunt Răi?

Nu. Googlebot, Bingbot și anumiți boti de monitorizare sunt utili. Cu toate acestea, boti malițioși efectuează scanări ale panoului de administrare, căutări de directoare deschise, spam în formulare, copiere de conținut, abuzuri XML-RPC, crearea de conturi false și încercări de autentificare. Prin urmare, scopul gestionării botilor nu este de a bloca toți boti, ci de a face distincții în funcție de comportament. O rată mare de erori, un număr excesiv de cereri într-un interval scurt de timp, antete care nu se comportă ca un browser real și modele URL suspecte sunt semnale importante.

Lista de Verificare înainte de Instalare

Când scrieți o regulă de firewall pe un server live, cel mai mare risc este să vă blocați accesul la server. De aceea, este necesar să faceți o pregătire scurtă înainte de a efectua modificări. Lista de verificare de mai jos oferă o abordare sigură, frecvent utilizată în medii de producție.

• Nu închideți sesiunea SSH activă; testați cu un al doilea terminal.
• Asigurați-vă că furnizorul de server oferă acces la consolă, VNC sau recuperare.
• Listați porturile deschise existente: verificați ieșirile ss -tulpn sau netstat -tulpn.
• Notați ce porturi sunt utilizate de serviciile web, email, DNS, baze de date, panouri și monitorizare.
• Dacă utilizați IPv6, planificați și regulile de firewall pentru IPv6.
• Aplicați mai întâi regulile de permitere, apoi cele de blocare.
• Asigurați-vă că setul de reguli este permanent; nu trebuie să se piardă la repornirea serverului.

De exemplu, pe un server tipic care găzduiește doar un site web, porturile care ar trebui să fie deschise pentru extern sunt de obicei 80, 443 și un port SSH limitat. Dacă serverul de email nu este activ, nu este necesară deschiderea porturilor 25, 465, 587, 993. Dacă baza de date este utilizată doar de pe același server, porturile 3306 sau 5432 ar trebui să rămână închise pentru lumea exterioară.

Ce Instrument de Firewall Ar Trebui Să Alegeți?

În lumea Linux există mai multe instrumente, iar majoritatea gestionează aceeași infrastructură de filtrare a nucleului cu diferite ușurințe de utilizare. Pentru începători, UFW este simplu și rapid. În sistemele corporative sau bazate pe Red Hat, firewalld este comun. În scenarii mai avansate, nftables oferă o structură modernă și flexibilă. Tabelul de mai jos facilitează alegerea.

Instalarea Pas cu Pas a Firewall-ului pentru Server

1. Identificați Porturile și Serviciile Deschise

Primul pas este să vedeți ce este deschis. Comanda ss -tulpn pe un server Linux arată ce servicii ascultă pe ce porturi. De exemplu, dacă nginx ascultă pe 0.0.0.0:80 și 0.0.0.0:443, asta înseamnă că traficul web este acceptat din toate interfețele. Dacă MariaDB ascultă pe 0.0.0.0:3306, asta este de obicei riscant; în majoritatea site-urilor, baza de date ar trebui să funcționeze pe 127.0.0.1.

Regula practică aici este: Niciun serviciu care nu trebuie să fie accesibil de pe internet nu ar trebui să asculte pe 0.0.0.0. Este mai sănătos să corectați mai întâi configurația serviciului și apoi să o blocați cu firewall-ul. Deoarece, chiar dacă firewall-ul este dezactivat, serviciul nu ar trebui să fie deschis lumii exterioare.

2. Deactivate Politica Implicită

În seturile de reguli de securitate, traficul implicit care vine este respins, iar traficul care iese este permis în funcție de necesitate. Această abordare previne deschiderea accidentală la internet a serviciilor instalate ulterior. Pe un server Ubuntu care folosește UFW, logica este următoarea: mai întâi se permite pentru SSH, apoi se deschid 80 și 443, după care politica implicită pentru traficul care vine devine deny și firewall-ul este activat.

Fluxul exemplu: Permiteți accesul pentru SSH de la adresa IP a administratorului, deschideți traficul HTTP și HTTPS, închideți porturile inutile, apoi activați firewall-ul. A activa firewall-ul fără a permite accesul SSH este una dintre cele mai frecvente greșeli, mai ales pe servere remote.

3. Limitați Accesul SSH

SSH este unul dintre serviciile cele mai vizate de atacatori. Un server cu portul 22 deschis poate primi sute sau mii de încercări de parolă pe zi. Cea mai sigură abordare este de a limita accesul SSH la anumite adrese IP. Dacă utilizați un IP fix, permiteți accesul doar de la biroul sau IP-ul VPN-ului dumneavoastră. Dacă nu aveți un IP fix, utilizați cel puțin autentificarea bazată pe chei și dezactivați introducerea parolei.

• Dezactivați accesul direct SSH cu root.
• Folosiți chei SSH în loc de parolă.
• Limitați utilizatorii cu AllowUsers sau AllowGroups.
• Automatizați blocarea încercărilor nereușite cu Fail2ban.
• Dacă utilizați un panou de administrare, aplicați restricții IP și port pentru acesta.

Schimbarea portului nu oferă singură securitate, dar poate reduce zgomotul generat de boturi automate. Totuși, adevărata protecție se obține prin restricții IP, autentificare puternică și monitorizarea jurnalele.

4. Deschideți Porturile Web în Mod Controlat

Pentru majoritatea serverelor care publică site-uri web, porturile 80 și 443 sunt necesare. Cu toate acestea, în zilele noastre, 443, adică HTTPS, ar trebui să fie portul principal de trafic, iar 80 ar trebui să fie folosit doar pentru redirecționarea către HTTPS. Site-urile fără certificat SSL afectează atât încrederea utilizatorilor, cât și performanța SEO. În acest punct, Certificate SSL Hostragons oferă o oportunitate naturală de a direcționa cititorii către instalarea sigură a HTTPS.

Când deschideți porturile web, fiți atenți la comportamentul IP-ului real. Dacă utilizați un CDN sau un proxy invers, este mai sigur să permiteți traficul pe porturile 80 și 443 doar de la intervalele de IP ale CDN-ului, în loc să le expuneți direct întregii lumi. Astfel, chiar dacă atacatorul cunoaște adresa IP reală a serverului, nu poate accesa direct serviciul web.

5. Închideți Baza de Date și Serviciile Interne pentru Internet

Serviciile precum MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB și altele deschise pe internet generează riscuri serioase. Lipsa autentificării pentru Redis, acces neautorizat la indexurile Elasticsearch sau porturi de administrare deschise pentru MongoDB au dus în trecut la numeroase scurgeri de date. Aceste servicii ar trebui să asculte, dacă este posibil, doar de pe localhost sau prin rețea privată.

De exemplu, pentru un site WordPress care rulează pe același server, baza de date ar trebui să funcționeze pe 127.0.0.1. Dacă utilizați un server de aplicații și unul de baze de date separat, permiteți accesul doar de la adresa IP privată a serverului de aplicații. Lăsarea accesului de pe internet la 3306 sau 5432 este o eroare cunoscută pe care botii o scanează constant.

6. Blocați Încercările de Forță Brută cu Fail2ban

Fail2ban monitorizează fișierele de jurnal pentru a detecta încercările repetate nereușite de autentificare și blochează temporar adresa IP asociată. Definițiile de închisoare pot fi făcute pentru SSH, nginx, Apache, Postfix, Dovecot, login-ul WordPress și unele servicii de panou. De exemplu, blocarea unei adrese IP care a avut 5 încercări nereușite în 10 minute timp de 1 oră este un început simplu dar eficient.

Fiți atenți când utilizați reguli excesiv de agresive în configurația Fail2ban. Un model greșit în jurnal poate bloca utilizatorii reali. De aceea, în prima etapă, este mai sigur să păstrați valoarea bantime rezonabilă, să monitorizați jurnalele și să faceți apoi o întărire treptată.

7. Adăugați Rate Limiting și Limite de Conexiune

Rate limiting la nivelul sistemului de operare poate ajuta împotriva traficului DDoS și a botilor. De exemplu, dacă se primesc un număr excesiv de noi conexiuni de la aceeași adresă IP pe secundă, se poate aplica o limită. Pe partea serverului web, modulele limit_req și limit_conn pentru nginx, sau soluții similare pentru Apache, pot fi utilizate. Pe partea aplicației, este necesară aplicarea de limite de rată pentru login, căutare, coș, plată și endpoint-uri API.

Un exemplu concret: pentru o pagină de login, 10 încercări pe minut pentru o singură adresă IP poate fi rezonabil. Pentru un endpoint de căutare, 2-5 cereri pe secundă pot fi suficiente. Dacă oferiți API, limitele bazate pe utilizator, limitele IP și analiza comportamentală trebuie să fie proiectate împreună, astfel încât atacatorul să nu poată depăși limita schimbând doar IP-ul.

Scenariul de Instalare Securizată cu UFW

Pe un server web bazat pe Ubuntu sau Debian, un scenariu simplu de început securizat poate fi realizat după următoarea logică: verificați serviciile existente, permiteți accesul SSH de la adresa IP a administratorului, deschideți porturile 80 și 443, respingeți traficul care vine implicit și verificați starea UFW. Dacă accesul SSH nu poate fi limitat la un IP fix, puteți permite temporar SSH din toate IP-urile, apoi să treceți la o soluție VPN sau IP fix.

Setul de decizii poate fi următorul: să considerăm că adresa IP a administratorului este 203.0.113.10. Permiteți SSH doar de la această IP. Traficul web ar trebui să rămână deschis pentru toată lumea pe 80 și 443. Baza de date, Redis, panoul și porturile de testare ar trebui să fie închise pentru exterior. Această configurație este un bun început pentru multe site-uri web mici și medii. Pentru a face redirecționarea corectă pe partea de domeniu și DNS, se poate face referire la pagina Verificarea domeniului și înregistrare Hostragons.

Logica de Zonă cu firewalld

Pe serverele bazate pe AlmaLinux, Rocky Linux și RHEL, firewalld este utilizat frecvent. firewalld funcționează pe baza conceptului de zone. Zona Publică este pentru interfețele deschise către internet, zona de încredere este pentru rețelele private de încredere, iar zona drop este utilizată pentru a reduce în tăcere traficul nedorit. Cel mai important aspect este diferența dintre regulile runtime și cele permanente. Regula runtime se aplică imediat, dar poate dispărea la repornire; regula permanentă este durabilă, dar poate necesita reîncărcare.

Când utilizați firewalld în medii corporative, definițiile bazate pe servicii facilitează lucrurile. De exemplu, puteți deschide serviciile http și https pe zona publică, asigurându-vă că serviciul SSH este accesibil doar din anumite adrese IP sursă. Dacă rețeaua de management, rețeaua de backup și traficul utilizatorilor sunt pe interfețe separate, structura zonelor îmbunătățește securitatea și lizibilitatea.

CDN, WAF și Protecția DDoS la Nivel de Furnizor

Firewall-ul local ia decizii după ce pachetele ajung la server. În atacurile DDoS de mari dimensiuni, scopul este de a filtra traficul înainte ca acesta să ajungă la server. De aceea, CDN, WAF și protecția DDoS la nivel de furnizor sunt critice. CDN-ul livreză conținuturi statice la locații de margine, WAF-ul filtrează cererile malițioase la nivelul aplicației, iar protecția furnizorului absoarbe sau curăță atacurile de volum mare la nivel de rețea.

În modelul ideal, înregistrările DNS trec prin CDN, adresa IP reală a serverului este ascunsă, iar firewall-ul serverului acceptă doar traficul pe 80 și 443 din intervalele de IP ale CDN-ului. Porturile de administrare pot fi accesibile doar prin VPN sau IP fix. Un astfel de model reduce probabilitatea de atac direct asupra IP-ului și vă permite să eliminați traficul bot înainte ca acesta să ajungă la aplicație. Pentru conținuturi care abordează simultan problemele de securitate și performanță web, se poate utiliza linkul Ghiduri pentru accelerarea și securizarea site-ului web.

Măsuri la Nivelul Aplicației Împotriva Botilor

Blochearea botilor nu se limitează doar la o listă de interdicție IP. Botii moderni pot utiliza IP-uri de proxy, rețele mobile, IP-uri de centre de date și user-agents variabile. De aceea, este necesară o abordare bazată pe comportament. Încercările repetate de autentificare de la aceeași IP într-un interval scurt, scanările care generează constant 404, densitatea wp-login.php sau xmlrpc.php, modelele de clicuri diferite de cele ale utilizatorului normal și antetele suspecte trebuie analizate.

• Utilizați rate limiting în formularele de autentificare și înregistrare.
• Dezactivați sau limitați accesul XML-RPC inutil.
• Protejați panoul de administrare cu un URL diferit, restricții IP și autentificare multifactor.
• Filtrați modelele suspecte de user-agent și referer la nivelul WAF.
• Utilizați echilibrat CAPTCHA sau mecanisme de verificare a boturilor invizibile în formulare.
• Adăugați controale de cheie, semnătură, cotă și marcaj temporal pentru endpoint-urile API.

În gestionarea botilor, este important să nu compromiteți experiența utilizatorului. CAPTCHA excesiv, blocări agresive sau blocări greșite pe baza țării pot afecta clienții reali. De aceea, măsurarea, testarea și întărirea treptată sunt cele mai sănătoase metode.

Monitorizarea Jurnalelor și Regulile de Alarmă

A crede că instalarea este completă este o greșeală frecventă. Firewall-ul este un sistem viu și trebuie monitorizat regulat. În fișierele auth.log sau secure, trebuie urmărite încercările SSH, densitatea cererilor anormale în jurnalele de acces nginx, creșterea 404 și 500 în jurnalele de erori, precum și monitorizarea metricelor sistemului pentru CPU și numărul de conexiuni. Chiar și un simplu sistem de alarmă poate economisi minute atunci când începe un atac.

Exemplele de valori limită pentru început ar putea fi: 100 de cereri 404 de la aceeași IP în 5 minute, mai mult de 20 de încercări pe pagina de login în 1 minut, utilizarea CPU-ului care rămâne peste 90% timp de 10 minute, numărul de conexiuni crescând de 3 ori față de normal. Aceste valori limită variază de la un site la altul; ceea ce este important este să cunoașteți profilul normal al traficului dumneavoastră.

Greșeli Frecvente și Moduri de Evitare

• Activarea firewall-ului fără a permite SSH: Poate duce la pierderea accesului pe un server remote. Testați întotdeauna cu o a doua sesiune.
• Uitați de IPv6: Serviciile pot rămâne deschise pe IPv6, chiar dacă IPv4 este închis.
• Lăsarea bazei de date deschise pe internet: Porturi precum 3306, 5432, 6379 și 9200 sunt scanate constant de bot.
• Utilizarea CDN-ului, lăsând IP-ul real deschis: Atacatorul poate ocoli CDN-ul și poate ataca direct serverul.
• Modificarea regulilor fără a le documenta: Într-o situație de urgență, va fi greu să înțelegeți care regulă ce face.
• Necrearea unui plan de acces de rezervă: În cazul unei reguli greșite, fără acces la consolă, întreruperea se poate prelungi.

Exemplu de Politică Practică pentru Firewall

Pentru un site web mic de tip corporate, o politică aplicabilă ar putea fi: traficul care vine este închis implicit; 443 este deschis tuturor vizitatorilor; 80 este deschis doar pentru redirecționare HTTPS; SSH este accesibil doar de la VPN sau de la IP-ul fix al administratorului; baza de date este pe localhost sau rețea privată; dacă se utilizează CDN, 80 și 443 sunt deschise doar pentru IP-urile CDN; Fail2ban monitorizează încercările de login SSH și web; jurnalele sunt trimise către un instrument de monitorizare centralizat.

Pentru un site de comerț electronic de dimensiuni medii, în plus, IP-urile de callback pentru plăți sunt incluse în lista de permisiuni, panoul de gestionare este mutat în spatele VPN-ului, se aplică cote bazate pe utilizatori pentru API, regulile SQL injection și XSS sunt activate pe WAF, iar un plan de filtrare temporară pe baza țării sau ASN-ului este pregătit. Este important ca acest plan să fie documentat; aplicarea unei proceduri predefinite în loc de a lua decizii în timpul unui atac reduce timpul de nefuncționare.

Testare: Regulile Chiar Funcționează?

După instalarea firewall-ului, este esențial să efectuați teste. Realizați un scanare a porturilor deschise dintr-o rețea diferită, verificați că accesul SSH funcționează doar de la IP-urile permise, asigurați-vă că site-ul este accesibil prin HTTPS, verificați că portul bazei de date este închis pentru exterior. Dacă utilizați CDN, verificați că cererile HTTP directe către adresa IP reală a serverului sunt blocate.

În procesul de testare, evitați scanările agresive care ar putea afecta sistemele de producție. Scopul este de a face o verificare sigură. De asemenea, după fiecare modificare, exportați setul de reguli sau luați notițe. Astfel, în cazul unei probleme, va fi mai ușor să reveniți la configurația sănătoasă anterioară.

Plan de Întreținere și Actualizare

Securitatea serverului nu este o instalare unică, ci un proces regulat de întreținere. Atunci când se adaugă servicii noi, trebuie revizuită nevoia de porturi, iar atunci când un serviciu vechi este eliminat, permisiunile respective trebuie șterse, actualizările de securitate trebuie aplicate la timp, iar jurnalele verificate periodic. Realizarea unei verificări a porturilor deschise cel puțin o dată pe lună și revizuirea setului de reguli ale firewall-ului la fiecare trei luni sunt un bun început practic.

În plus, un plan de backup este o parte a strategiei de securitate. Atacurile DDoS pot întrerupe accesul, dar ransomware-ul sau accesul neautorizat pot duce la pierderi de date. Găzduirea sigură, SSL, gestionarea domeniilor și backup-ul trebuie să fie gândite împreună. În acest context, Aspecte de care trebuie să ții cont la alegerea hosting-ului sigur și cum se face instalarea certificatului SSL sunt linkuri naturale de continuare.

Concluzie

Instalarea unui firewall pentru server nu face serverul complet invizibil la atacurile DDoS și a botilor; totuși, reduce semnificativ suprafața de atac, scade riscul de acces neautorizat și permite o intervenție mai controlată asupra incidentelor. Cele mai bune rezultate se obțin prin aplicarea simultană a protecției DDoS la nivel de furnizor, CDN/WAF, politici stricte de porturi, restricții SSH, Fail2ban, rate limiting și monitorizarea regulată a jurnalelor.

În cazul în care lansați un proiect nou, planificarea politicii de firewall de la început este mai ușoară decât corectarea ulterioară. Pe Hostragons, atunci când evaluați serverul, găzduirea, domeniul și infrastructura SSL, gândiți-vă la nevoile dumneavoastră de securitate pentru a crea un mediu web mai rezistent. Dacă aveți nevoie, începeți cu o mică listă de verificare: închideți porturile deschise, limitați SSH, faceți HTTPS obligatoriu și monitorizați jurnalele.

Întrebări Frecvente

Firewall-ul serverului blochează complet atacurile DDoS?

Nu. Firewall-ul local poate reduce atacurile de mică amploare și unele atacuri la nivel de protocol, dar pentru atacuri DDoS voluminoase este necesară protecția la nivel de furnizor, CDN și WAF.

Ce porturi ar trebui să fie deschise pe un server web?

Pe un server web tipic, porturile 80 și 443 rămân deschise. Portul SSH ar trebui să fie permis doar pentru adresele IP de administrator. Porturile pentru baza de date și serviciile interne ar trebui să fie închise pentru internet.

Ar trebui să folosesc UFW sau firewalld?

UFW oferă o început mai ușoară pentru Ubuntu și Debian. Firewalld este comun pe sistemele bazate pe AlmaLinux, Rocky Linux și RHEL. În scenarii avansate și speciale, nftables poate fi preferat.

Pot opri traficul bot doar prin blocarea IP-urilor?

De obicei, nu. Botii moderni folosesc IP-uri și proxy-uri diferite. Pe lângă blocarea IP-urilor, ar trebui să utilizați rate limiting, regulile WAF, analiza comportamentală, CAPTCHA și cote bazate pe aplicație.

Care este cel mai mare risc atunci când configurăm un firewall?

Cel mai mare risc este să vă blocați accesul SSH din cauza unei reguli greșite. De aceea, trebuie să definiți mai întâi permisiunea SSH, să testați cu a doua sesiune și să aveți acces la consola furnizorului pregătit.