Postavljanje vatrozida na serveru: Zaštita od DDoS napada i botova

Postavljanje vatrozida na serveru podrazumijeva ostavljanje otvorenih samo potrebnih portova, dok se svi nepotrebni pristupi blokiraju; predstavlja prvi sloj obrane protiv DDoS, brute force napada i zloćudnog bot prometa. U praksi, cilj je ograničiti SSH pristup, kontrolirano otvoriti web servise, primijeniti ograničenja na sumnjive zahtjeve, pratiti logove i, ako je moguće, filtrirati promet prije nego što dođe do servera koristeći dodatne mjere zaštite kao što su CDN ili WAF.

Kada otvorite web server za internet, u nekoliko minuta možete se suočiti s port skeniranjem, SSH pokušajima, botovima koji traže ranjivosti i lažnim korisničkim agentima. Osobito je važno da organizacije koje pokreću WordPress, e-trgovinu, panele, API-je ili serverske igre shvate da vatrozid nije samo tehnička opcija, već nužnost za kontinuitet. U ovom vodiču ćemo korak po korak izgraditi arhitekturu vatrozida na Linux serverima; razmatrat ćemo UFW, firewalld, nftables, Fail2ban, web aplikacijski vatrozid i pristupe smanjenju DDoS napada zajedno.

Važno je naglasiti: lokalni vatrozid ne može samostalno zaustaviti velike DDoS napade. Kada napad od 20 Gbps, 80 Gbps ili veći stigne do data centra ili mrežne infrastrukture, paketi mogu ispuniti propusnost prije nego što stignu do pravila vašeg operativnog sustava. Stoga je pravi pristup slojevita sigurnost: zaštita od DDoS na razini pružatelja usluga, CDN/WAF, vatrozid na razini operativnog sustava, ograničavanje prometa na razini aplikacije i redovno analiziranje logova trebali bi zajedno raditi. Za odgovarajući izbor infrastrukture, možete se povezati na Hostragons VPS i VDS serverska rješenja, a za sigurne opcije web hostinga na Hostragons web hosting paketi.

Što radi vatrozid na serveru?

Vatrozid na serveru je sigurnosni sloj koji filtrira mrežni promet prema izvornoj IP adresi, odredišnoj IP adresi, portu, protokolu, stanju veze i, u nekim slučajevima, karakteristikama paketa. Na jednostavnom primjeru, portovi 80 i 443 trebaju biti otvoreni za vašu web stranicu, dok port 3306, koji se koristi za bazu podataka, ne bi trebao biti otvoren za internet. Umjesto da svima dopustite testiranje port 22 za SSH, sigurnije je omogućiti pristup samo s vaše uredske IP adrese.

Osnovna svrha vatrozida nije čarobno uništavanje svih napada. Glavni cilj je smanjiti površinu napada. Što je površina napada manja, to je manje opcija koje napadač može isprobati. Na primjer, na novoinstaliranom Linux serveru, SSH, web panel, usluga e-pošte, baza podataka, agencija za nadzor i testne usluge mogu biti otvorene istovremeno. Svaka od njih stvara poseban rizik. Dobro konfiguriran vatrozid djeluje prema načelu "zadano odbij, dopusti ono što je potrebno".

Razumijevanje DDoS i bot prometa

Zašto su DDoS napadi drugačiji?

DDoS, tj. distribuirani napad uskraćivanja usluge, ima za cilj učiniti ciljani servis nedostupnim intenzivnim prometom iz mnogo izvora. Napad ponekad ispunjava propusnost, ponekad troši CPU i RAM resurse servera, a ponekad aktivira skupe procese na razini aplikacije. Na primjer, mala aplikacija koja prima 50.000 HTTP zahtjeva u sekundi može postati neodgovarajuća zbog PHP-FPM, Node.js ili bazen veza s bazom podataka, čak i kada mrežni kanal nije zasićen.

Jesu li botovi uvijek loši?

Ne. Googlebot, Bingbot i neki botovi za praćenje su korisni. Međutim, zloćudni botovi provode pretraživanje upravljačke ploče, pretraživanje otvorenih direktorija, spam forme, kopiranje sadržaja, zloupotrebu XML-RPC, stvaranje lažnih računa i pokušaje prijave. Stoga, cilj upravljanja botovima nije blokiranje svih botova, već razlikovanje prema ponašanju. Visoka stopa grešaka, previše zahtjeva u kratkom vremenu, glave koje se ne ponašaju kao pravi preglednici i sumnjivi obrasci URL-a su važni signali.

Kontrolna lista prije početka instalacije

Kada pišete pravilo vatrozida na aktivnom serveru, najveći rizik je da se zaključate iz servera. Stoga je potrebno napraviti kratku pripremu prije nego što izvršite promjene. Sljedeća kontrolna lista predstavlja siguran pristup koji se često koristi u produkcijskim okruženjima.

• Ne zatvarajte aktivnu SSH sesiju; testirajte s drugim terminalom.
• Provjerite nudi li vaš pružatelj usluga konzolu, VNC ili pristup za oporavak.
• Izradite popis trenutno otvorenih portova: pregledajte izlazne podatke ss -tulpn ili netstat -tulpn.
• Zabilježite koje portove koriste web, e-pošta, DNS, baza podataka, panel i usluge nadzora.
• Ako koristite IPv6, planirajte i pravila vatrozida za IPv6.
• Prvo primijenite pravila za dopuštenje, a zatim pravila za odbijanje.
• Pobrinite se da je skup pravila trajni; ne smije nestati kada se server ponovo pokrene.

Na primjer, na tipičnom serveru koji hosta samo web stranicu, portovi koji trebaju biti otvoreni često su 80, 443 i ograničeni SSH port. Ako usluga e-pošte ne radi, portovi kao što su 25, 465, 587, 993 ne trebaju biti otvoreni. Ako se baza podataka koristi samo unutar istog servera, portovi 3306 ili 5432 trebaju ostati zatvoreni za vanjski svijet.

Koji alat za vatrozid trebate odabrati?

U Linux svijetu postoji više alata, a većina upravlja istom osnovnom infrastrukturom filtriranja na različite načine. Za početnike, UFW je jednostavan i brz. U korporativnim ili sustavima temeljenim na Red Hatu, firewalld je široko rasprostranjen. Za naprednije scenarije, nftables nudi modernu i fleksibilnu strukturu. Sljedeća tablica olakšava izbor.

Korak po korak instalacija vatrozida na serveru

1. Odredite otvorene portove i usluge

Prvi korak je vidjeti što je otvoreno. Na Linux serveru, komanda ss -tulpn pokazuje koje usluge slušaju na kojim portovima. Na primjer, ako nginx sluša na 0.0.0.0:80 i 0.0.0.0:443, to znači da web promet prihvaća sa svih sučelja. Ako MariaDB sluša na 0.0.0.0:3306, to je obično rizično; u većini web stranica baza podataka trebala bi raditi na 127.0.0.1.

Praktično pravilo ovdje je: nijedna usluga koja ne treba biti dostupna s interneta ne bi trebala slušati na 0.0.0.0. Bolje je prvo ispraviti konfiguraciju usluge, a zatim je zatvoriti s vatrozidom. Jer i ako je vatrozid isključen, usluga ne bi trebala biti dostupna izvan svijeta.

2. Postavite zadanu politiku na zatvoreno

U sigurnim skupovima pravila, zadani dolazni promet se odbija, dok se odlazni promet oslobađa prema potrebi. Ovaj pristup sprječava slučajno otvaranje usluga koje se naknadno instaliraju za internet. UFW na Ubuntu serveru radi ovako: prvo se dozvoljava SSH, zatim se otvaraju 80 i 443, a potom se postavlja zadana dolazna politika na deny i aktivira vatrozid.

Primjer toka: Dopustite pristup SSH samo vašoj IP adresi, otvorite HTTP i HTTPS promet, zatvorite nepotrebne portove, a zatim aktivirajte. Otvoriti vatrozid bez odobravanja SSH je jedan od najčešćih grešaka, posebno na udaljenim serverima.

3. Ograničite SSH pristup

SSH je jedna od usluga koju napadači najčešće cilјaju. Server s otvorenim zadanim portom 22 može dnevno primati stotine ili tisuće pokušaja ulaska. Najsigurniji pristup je ograničiti SSH pristup na određene IP adrese. Ako koristite statički IP, dopustite samo pristup s ureda ili VPN IP adrese. Ako nemate statički IP, barem koristite autentifikaciju temeljem ključeva i isključite unos lozinke.

• Zatvorite direktan SSH pristup s root računom.
• Koristite SSH ključeve umjesto lozinke.
• Ograničite korisnike s AllowUsers ili AllowGroups.
• Automatski blokirajte neuspješne pokušaje s Fail2ban.
• Ako koristite upravljačku ploču, ograničite pristup i za port upravljačke ploče.

Promjena porta sama po sebi ne pruža sigurnost, ali može smanjiti automatski bot promet. Ipak, prava zaštita dolazi od IP ograničenja, snažne autentifikacije i praćenja logova.

4. Kontrolirano otvorite web portove

Za većinu servera koji objavljuju web stranice, portovi 80 i 443 su potrebni. Međutim, danas bi port 443 trebao biti glavni port za promet, dok se port 80 trebao koristiti samo za preusmjeravanje na HTTPS. Web stranice bez SSL certifikata negativno utječu na povjerenje korisnika i SEO performanse. U ovom trenutku, Hostragons SSL certifikati predstavlja prirodnu priliku za povezivanje čitatelja na sigurno postavljanje HTTPS-a.

Kada otvarate web portove, obratite pažnju na ponašanje stvarne IP adrese. Ako koristite CDN ili obrnuti proxy, bolje je dopustiti promet na portovima 80 i 443 samo iz IP raspona CDN-a, umjesto da ih otvorite za cijeli internet. Tako, čak i ako napadač zna pravi IP adresu servera, ne može pristupiti izravno web servisu.

5. Zatvorite bazu podataka i unutarnje servise za internet

Otvoreni MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB i slični servisi predstavljaju ozbiljan rizik. Nedostatak autentifikacije za Redis, neovlašteni pristup indeksima za Elasticsearch ili otvoreni upravljački port za MongoDB doveli su do mnogih curenja podataka u prošlosti. Ove usluge trebale bi slušati samo na localhostu ili privatnoj mreži.

Na primjer, za WordPress stranicu koja radi na istom serveru, dovoljno je da baza podataka radi na 127.0.0.1. Ako koristite odvojeni aplikacijski i bazni server, dopustite samo privatnoj IP adresi aplikacijskog servera. Ostaviti pristup 3306 ili 5432 iz javnog interneta je poznata greška koju botovi stalno skeniraju.

6. Zaustavite brute force pokušaje s Fail2ban-om

Fail2ban prati log datoteke kako bi otkrio ponovljene neuspješne pokušaje prijave i privremeno blokira odgovarajuću IP adresu. Jail definicije mogu se napraviti za SSH, nginx, Apache, Postfix, Dovecot, WordPress prijavu i neke usluge panela. Na primjer, blokiranje IP adrese koja ima 5 neuspješnih SSH pokušaja u 10 minuta na 1 sat predstavlja jednostavan, ali učinkovit početak.

Budite oprezni pri korištenju preagresivnih pravila u konfiguraciji Fail2ban-a. Pogrešan obrazac loga može blokirati stvarne korisnike. Stoga je u početnoj fazi bolje zadržati razumnu vrijednost bantime, pratiti logove i kasnije postupno pojačavati sigurnost.

7. Dodajte ograničenja prometa i veze

Ograničenja prometa na razini operativnog sustava mogu pomoći protiv DDoS i bot prometa. Na primjer, ako dolazi previše novih veza s istog IP-a u sekundi, može se primijeniti ograničenje. Na strani web servera, za nginx se mogu koristiti moduli limit_req i limit_conn, dok se za Apache mogu koristiti mod_evasive ili slična rješenja. Na strani aplikacije, također je potrebno postaviti ograničenja prometa za prijavu, pretraživanje, košaricu, plaćanje i API endpoint-e.

Konkretan primjer: Na stranici za prijavu, 10 pokušaja u minuti za jedan IP adresu može biti razumno. Na API endpointu za pretraživanje, 2-5 zahtjeva u sekundi može biti dovoljno. Ako pružate API, trebate zajednički dizajnirati ograničenje bazirano na tokenima, IP-u i analizi ponašanja, kako bi napadač ne mogao jednostavno promijeniti IP adresu i preći preko svih ograničenja.

Primjer sigurnog postavljanja s UFW-om

Na web serveru temeljenom na Ubuntu ili Debianu, jednostavna sigurnosna početna strategija može se postaviti ovako: provjerite postojeće usluge, dopustite SSH pristup samo s vaše IP adrese, otvorite portove 80 i 443, postavite dolazni promet prema zadano na odbijanje i potvrdite status UFW-a. Ako ne možete ograničiti SSH pristup na statički IP, privremeno možete dopustiti SSH pristup sa svih IP adresâ, a kasnije preći na VPN ili rješenje sa statičkim IP-om.

Primjer odluka može biti sljedeći: neka 203.0.113.10 bude vaša upravljačka IP adresa. SSH nek dolazi samo s ove IP adrese. Web promet neka ostane otvoren za sve putem 80 i 443. Baza podataka, Redis, panel i test portovi neka budu zatvoreni za van.

firewalld s logikom zona

firewalld se široko koristi na serverima temeljenim na AlmaLinux, Rocky Linux i RHEL. firewalld radi sa konceptom zona. Public zona je za sučelja otvorena internetu, trusted zona je za pouzdane privatne mreže, a drop zona se koristi za tiho odbacivanje neželjenog prometa. Ključna razlika je između runtime i permanent pravila. Runtime pravilo se odmah primjenjuje, ali se može izgubiti pri ponovnom pokretanju; permanent pravilo je trajno, ali može zahtijevati ponovno učitavanje.

Kada koristite firewalld u korporativnim okruženjima, definicije na temelju usluga olakšavaju stvari. Na primjer, možete otvoriti http i https usluge na javnoj zoni, dok samo određeni izvorni IP adrese mogu pristupiti ssh usluzi. Ako su upravljačka mreža, mreža za sigurnosne kopije i korisnički promet na različitim sučeljima, struktura zona poboljšava sigurnost i čitljivost.

CDN, WAF i zaštita od DDoS na razini pružatelja

Lokalni vatrozid donosi odluke nakon što paketi stignu na server. Kod velikih DDoS napada, cilj je filtrirati promet prije nego što stigne do servera. CDN, WAF i zaštita od DDoS na razini pružatelja usluga su stoga kritične. CDN isporučuje statički sadržaj s rubnih lokacija, WAF filtrira zloćudne zahtjeve na razini aplikacije, a zaštita pružatelja apsorbira ili pročišćava velike napade na razini mreže.

U idealnom modelu, vaši DNS zapisi prolaze kroz CDN, pravi IP vašeg servera je skriven, a vaš vatrozid na serveru prihvaća samo promet na portovima 80 i 443 iz IP raspona CDN-a. Upravljački portovi bit će dostupni samo preko VPN-a ili statičkog IP-a. Ova struktura smanjuje mogućnost napada na pravi IP i omogućuje vam da zaustavite bot promet prije nego što dođe do aplikacije. Za sadržaje koji obuhvaćaju sigurnost weba i performanse, može se koristiti veza Hostragons pretraga domena i registracija.

Mjere na razini aplikacije protiv botova

Blokiranje botova ne sastoji se samo od popisa zabranjenih IP adresa. Moderni botovi mogu koristiti proxy, mobilne mreže, IP adrese iz data centara i promjenjive korisničke agente. Stoga je potreban pristup temeljen na ponašanju. Treba analizirati previše pokušaja prijave u kratkom vremenu s istog IP-a, kontinuirano skeniranje koje generira 404, gustoća wp-login.php ili xmlrpc.php, uzorci klikanja koji se razlikuju od normalnih korisnika i sumnjive glave.

• Koristite ograničenja prometa na obrascima prijave i registracije.
• Isključite ili ograničite nepotrebne XML-RPC pristupe.
• Zaštitite upravljačku ploču različitim URL-om, IP ograničenjem i višefaktorskom autentifikacijom.
• Filtrirajte sumnjive obrasce user-agent i referer na WAF razini.
• Umjereno koristite CAPTCHA ili mehanizme za verifikaciju botova.
• Dodajte kontrole ključeva, potpisa, kvota i vremenskih oznaka za API endpoint-e.

U upravljanju botovima važno je ne narušiti korisničko iskustvo. Prekomjerni CAPTCHA, agresivno blokiranje ili netočne blokade po zemljama mogu naškoditi vašim stvarnim kupcima. Stoga je mjerenje, testiranje i postupno pojačavanje najbolji pristup.

Praćenje logova i pravila alarma

Pogrešno je misliti da je postavljanje završeno. Vatrozid je živi sustav koji treba redovito pratiti. U auth.log ili secure datoteci trebate pratiti SSH pokušaje, abnormalnu gustoću zahtjeva u nginx access logovima, porast 404 i 500 grešaka u error logovima, te pratiti sustavne metrike kao što su CPU i broj veza. Čak i jednostavni alarm može vas upozoriti na napad u nekoliko minuta.

Primjeri praga za početak mogu biti: više od 100 404 zahtjeva s iste IP adrese u 5 minuta, više od 20 pokušaja na stranici za prijavu u 1 minuti, CPU korištenje iznad 90% tijekom 10 minuta, broj veza koji se povećao na 3 puta više od normalnog. Ovi pragovi variraju od stranice do stranice; važno je poznavati svoj normalni profil prometa.

Uobičajene greške i načini izbjegavanja

• Aktivacija vatrozida bez odobrenja za SSH: To može dovesti do gubitka pristupa na udaljenom serveru. Uvijek testirajte s drugom sesijom.
• Zaboraviti na IPv6: Dok je IPv4 zatvoren, usluga može ostati otvorena putem IPv6.
• Ostaviti bazu podataka otvorenom za internet: Portovi poput 3306, 5432, 6379 i 9200 stalno se skeniraju od strane botova.
• Korištenje CDN-a i ostavljanje stvarnog IP-a otvorenim: Napadač može zaobići CDN i napasti izravno server.
• Promjena pravila bez dokumentiranja: U hitnim situacijama, teško je shvatiti što koje pravilo radi.
• Ne stvoriti plan za rezervni pristup: Ako nema konzolnog pristupa zbog pogrešnog pravila, prekid može trajati dulje.

Primjer praktične politike vatrozida

Za malu korporativnu web stranicu, sažeta politika može biti sljedeća: dolazni promet je prema zadano zatvoren; 443 je otvoren za sve posjetitelje; 80 je otvoren samo za preusmjeravanje na HTTPS; SSH je dostupan samo s VPN-a ili statičke upravljačke IP adrese; baza podataka je lokalna ili na privatnoj mreži; ako se koristi CDN, 80 i 443 su otvoreni samo za IP raspon CDN-a; Fail2ban prati SSH i web prijave; logovi se šalju u središnji alat za praćenje.

Za srednje velike e-trgovine, osim toga, IP adrese za povratne informacije o plaćanju trebaju biti na allowlisti, upravljačka ploča treba biti iza VPN-a, korisničke kvote trebaju biti postavljene za API, a na WAF-u trebaju biti aktivirana pravila za SQL injekciju i XSS, te treba pripremiti plan privremenog filtriranja temeljenog na zemlji ili ASN-u. Važno je da ovaj plan bude napisan; primjenom unaprijed definiranih procedura umjesto donošenja odluka u trenutku napada smanjuje se vrijeme prekida.

Testiranje: Radite li pravila ispravno?

Nakon postavljanja vatrozida, obavezno testirajte. Izvršite skeniranje otvorenih portova s druge mreže, provjerite da SSH pristup radi samo s odobrenih IP adresa, provjerite je li web stranica dostupna putem HTTPS-a, a port baze podataka zatvoren za vanjske pristupe. Ako koristite CDN, pošaljite izravni HTTP zahtjev pravom IP-u servera kako biste provjerili je li blokiran.

Nemojte provoditi agresivna skeniranja koja bi mogla naštetiti produkcijskim sustavima tijekom testiranja. Cilj je osigurati sigurnu verifikaciju. Također, nakon svake promjene, izvezite skup pravila ili zabilježite. Tako će se lakše vratiti na prethodnu zdravu konfiguraciju u slučaju problema.

Plan održavanja i ažuriranja

Sigurnost servera nije jednokratna instalacija, već redoviti proces održavanja. Kada se dodaje nova usluga, potrebe za portovima trebaju se preispitati, kada se ukloni stara usluga, odgovarajuće dozvole trebaju se ukloniti, sigurnosna ažuriranja trebaju se primijeniti na vrijeme, a logovi redovito provjeravati. Dobar početak je provoditi provjeru otvorenih portova barem jednom mjesečno, a pregledavati skup pravila vatrozida svaka tri mjeseca.

Također, plan sigurnosnih kopija dio je strategije sigurnosti. DDoS napadi mogu prekinuti pristup, ali ransomware ili neovlašteni pristup mogu dovesti do gubitka podataka. Sigurno hostanje, SSL, upravljanje domenama i sigurnosno kopiranje trebaju se razmatrati zajedno. U tom kontekstu, Vodiči za ubrzavanje i sigurnost web stranice i Što treba uzeti u obzir pri odabiru sigurnog hostinga prirodne su nastavne veze.

Završne misli

Postavljanje vatrozida na serveru ne čini server potpuno nevidljivim za DDoS i botove; međutim, značajno smanjuje površinu napada, smanjuje rizik od neovlaštenog pristupa i omogućuje vam kontrolirano reagiranje na incidente. Najbolji rezultati postižu se primjenom zaštite od DDoS na razini pružatelja usluga, CDN/WAF, stroge politike portova, ograničenja SSH, Fail2bana, ograničenja prometa i redovitog praćenja logova.

Ako pokrećete novi projekt, planiranje politike vatrozida na samom početku mnogo je lakše od ispravljanja kasnije. Dok ocjenjujete svoje servere, hosting, domene i SSL infrastrukturu na Hostragons-u, razmatrajte i svoje sigurnosne potrebe kako biste stvorili otpornije web okruženje. Ako je potrebno, započnite s malom kontrolnom listom: zatvorite otvorene portove, ograničite SSH, obavezno koristite HTTPS i pratite logove.

Često postavljana pitanja

Da li vatrozid servera potpuno blokira DDoS napade?

Ne. Lokalni vatrozid može smanjiti male napade i neke napade na razini protokola, ali za velike DDoS napade trebate zaštitu na razini pružatelja usluga, CDN i WAF.

Koji portovi trebaju ostati otvoreni na web serveru?

Na tipičnom web serveru portovi 80 i 443 ostaju otvoreni. SSH port trebao bi biti otvoren samo za odobrene IP adrese. Portovi baza podataka i unutarnjih usluga trebaju biti zatvoreni za internet.

Trebam li koristiti UFW ili firewalld?

UFW nudi lakši početak za Ubuntu i Debian. firewalld je široko rasprostranjen na sustavima temeljenim na AlmaLinux, Rocky Linux i RHEL. Za napredne i specifične scenarije može se koristiti nftables.

Možeš li zaustaviti bot promet samo blokiranjem IP-a?

Obično ne. Moderni botovi koriste različite IP adrese i proksije. Osim blokiranja IP-a, također se trebaju koristiti ograničenja prometa, WAF pravila, analiza ponašanja, CAPTCHA i kvote na razini aplikacije.

Koji je najveći rizik prilikom postavljanja vatrozida?

Najveći rizik je prekinuti vlastiti SSH pristup zbog pogrešnog pravila. Stoga je važno prvo definirati dozvolu za SSH, testirati s drugom sesijom i imati pristup konzoli pružatelja usluga spreman.