Instalacija zaštitnog zida na serveru: Kako zaštititi server od DDoS i bot napada

Instalacija zaštitnog zida na serveru znači ostaviti otvorene samo nužne portove i blokirati sav nepotreban pristup; time se formira prvi sloj odbrane protiv DDoS, brute force i štetnog bot prometa. Osnovni cilj je: ograničiti SSH pristup, pažljivo otvoriti web servise, sumnjive zahtjeve staviti pod ograničenja, pratiti logove i, ako je moguće, filtrirati promet pre nego što stigne do servera korištenjem CDN/WAF rješenja.

Čim objavite web server na internetu, već u prvih nekoliko minuta možete očekivati port skeniranja, SSH pokušaje, ranjivost botove i lažne korisničke agente. Posebno kod WordPressa, e-trgovine, panela, API-ja ili game servera, zaštitni zid nije samo tehnički izbor, već nužnost za stabilan rad. U ovom vodiču ćemo korak po korak izgraditi zaštitni zid na Linux serverima: UFW, firewalld, nftables, Fail2ban, web aplikacijski firewall i strategije za ublažavanje DDoS napada.

Važna istina na početku: lokalni zaštitni zid sam ne može zaustaviti masivne DDoS napade. Na primjer, udar od 20 Gbps ili 80 Gbps popunjava bandwidth na data centru ili mrežnoj infrastrukturi prije nego što paket dođe do vaših firewall pravila. Zato je pravi pristup slojevita zaštita: DDoS zaštita na nivou provajdera, CDN/WAF, OS firewall, ograničenja na aplikacijama i redovna analiza logova – sve to treba raditi zajedno. Za izbor odgovarajuće infrastrukture možete posjetiti Hostragons rješenja za VPS i VDS servere, a za sigurne hosting opcije Hostragons paketi web hostinga.

Čemu služi zaštitni zid na serveru?

Zaštitni zid filtrira mrežni promet na osnovu izvora IP adrese, ciljne IP, porta, protokola, statusa veze i nekad karakteristika paketa. Jednostavno: portovi 80 i 443 trebaju biti otvoreni za web, dok port za bazu podataka 3306 nikako ne smije biti dostupan internetu. Za SSH, umjesto da dopuštate pristup svima na port 22, dozvolite samo vašoj kancelarijskoj IP adresi.

Firewall nije čarobni alat koji eliminiše sve napade. Pravi cilj je smanjiti površinu napada. Manja površina – manje mogućnosti za napadača. Na novom Linux serveru može biti otvoren SSH, web panel, mail servis, baza, monitoring agent i test servisi – svaki je potencijalni rizik. Dobro postavljen firewall radi po principu “odbaci sve po defaultu, dozvoli samo što je nužno”.

Razumijevanje DDoS i bot prometa

Zašto su DDoS napadi posebni?

DDoS (Distributed Denial of Service) napadi ciljaju da ogromnim prometom iz više izvora učine uslugu nedostupnom. Napad može popuniti bandwidth, iscrpiti CPU/RAM servera ili izazvati skupe procese na aplikaciji. Na primjer, mali server koji primi 50.000 HTTP zahtjeva u sekundi može pasti zbog PHP-FPM, Node.js ili pool konekcija na bazi – iako mreža nije zagušena.

Jesu li svi botovi loši?

Nisu. Googlebot, Bingbot i monitoring botovi su korisni. Ali štetni botovi traže administratorske panele, otvorene direktorije, spamaju forme, kopiraju sadržaj, zloupotrebljavaju XML-RPC, prave lažne registracije i pokušavaju login. Cilj nije blokirati sve botove, već razlikovati dobre od loših prema ponašanju. Signali su: visoka greška, previše zahtjeva u kratkom vremenu, sumnjivi headeri, neobični URL uzorci.

Lista za provjeru prije početka instalacije

Najveći rizik kod pisanja firewall pravila na produkciji je zaključavanje samog sebe sa servera. Prije promjena napravite kratku pripremu. Ova lista je provjerena i sigurna:

• Nemojte zatvarati aktivnu SSH sesiju; otvorite drugi terminal za test.
• Provjerite da vaš hosting nudi konzolu, VNC ili recovery pristup.
• Izlistajte otvorene portove: ss -tulpn ili netstat -tulpn.
• Zabilježite portove za web, mail, DNS, bazu, panel i monitoring servise.
• Ako koristite IPv6, planirajte i IPv6 firewall pravila.
• Prvo postavite allow (dozvolu), pa deny (blokadu).
• Provjerite da su pravila trajna – da ostanu nakon restarta servera.

Na serveru koji hostuje samo web sajt, obično su otvoreni portovi 80, 443 i ograničen SSH. Ako nemate mail server, portovi 25, 465, 587, 993 ne trebaju biti otvoreni. Baza podataka (3306 ili 5432) treba biti dostupna samo iznutra, ne izvana.

Koji firewall alat odabrati?

Na Linuxu postoji više alata, svi koriste isti kernel filtering, ali nude različite nivoe jednostavnosti. Za početnike je UFW najjednostavniji. Na Red Hat/Enterprise sistemima je firewalld standard. Za napredne je nftables moderan i fleksibilan. Pogledajte tabelu za lakši izbor:

Korak po korak instalacija firewall-a na serveru

1. Identificirajte otvorene portove i servise

Prvo provjerite šta je otvoreno. Komanda ss -tulpn pokazuje koji servisi slušaju na kojim portovima. Ako nginx sluša na 0.0.0.0:80 i 0.0.0.0:443, web promet je dozvoljen sa svih interfejsa. Ako MariaDB sluša na 0.0.0.0:3306, to je rizik – baza treba biti dostupna samo na 127.0.0.1.

Praktično pravilo: nijedan servis koji nije za javni pristup ne smije slušati na 0.0.0.0. Prvo podesite konfiguraciju servisa, zatim firewall. Čak i ako firewall padne, servis ne smije biti dostupan izvana.

2. Postavite default politiku na “zatvoreno”

Sigurna pravila: dolazni promet je odbijen po defaultu, odlazni je dozvoljen po potrebi. Tako nećete greškom otvoriti novi servis prema internetu. Na UFW: prvo dozvolite SSH (samo za administraciju), zatim otvorite 80 i 443, nakon toga default policy na deny i aktivirajte firewall.

Primjer: dozvolite SSH za vašu IP, HTTP/HTTPS za sve, blokirajte nepotrebne portove, aktivirajte firewall. Najčešći problem je aktivirati firewall bez dozvole za SSH – pogotovo kod udaljenih servera.

3. Ograničite SSH pristup

SSH je najčešća meta napada. Otvoren port 22 prima stotine ili hiljade pokušaja dnevno. Najsigurnije je dozvoliti pristup samo određenim IP adresama. Ako imate statički IP, dozvolite samo vašoj kancelariji/VPN-u. Ako nemate, koristite SSH ključ i zabranite login lozinkom.

• Zabranite root SSH login.
• Koristite SSH key umjesto lozinke.
• Ograničite korisnike pomoću AllowUsers ili AllowGroups.
• Fail2ban automatski blokira neuspjele pokušaje.
• Panel port također ograničite po IP.

Promjena porta smanjuje bot promet, ali nije pravi oblik zaštite. Prava zaštita je IP ograničenje, jaka autentifikacija i praćenje logova.

4. Otvorite web portove kontrolisano

Većina servera treba portove 80 i 443. Danas je 443 (HTTPS) glavni port; 80 služi samo za preusmjerenje na HTTPS. Bez SSL-a gubite povjerenje korisnika i SEO ocjenu. Ovdje je Hostragons SSL certifikati idealna interna poveznica za sigurno postavljanje HTTPS-a.

Pazite na IP ponašanje kad otvarate portove. Ako koristite CDN ili reverse proxy, dozvolite promet samo iz CDN IP opsega. Tako napadač, čak i da zna IP servera, ne može direktno pristupiti web servisu.

5. Zatvorite bazu podataka i interne servise za internet

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB i slični servisi su veliki rizik kada su otvoreni prema internetu. Nedostatak autentifikacije na Redis-u, neovlašteni pristup indeksima na Elasticsearch-u ili otvoren MongoDB su česti uzroci curenja podataka. Ovi servisi trebaju slušati samo na localhost ili privatnoj mreži.

Za WordPress na istom serveru, baza treba biti na 127.0.0.1. Ako imate odvojene servere za aplikaciju i bazu, dozvolite pristup samo iz aplikacijskog servera. Nikada ne ostavljajte 3306 ili 5432 otvorenim za internet – botovi ih neprestano skeniraju.

6. Fail2ban za blokiranje brute force pokušaja

Fail2ban prati logove i automatski blokira IP adrese s ponovljenim neuspjelim login pokušajima. Možete definirati jail za SSH, nginx, Apache, Postfix, Dovecot, WordPress login i razne panele. Na primjer, ako IP napravi 5 neuspjelih pokušaja u 10 minuta, blokirajte ga na 1 sat.

Ne pretjerujte sa strogošću – pogrešno pravilo može blokirati legitimne korisnike. Počnite sa umjerenim bantime vrijednostima, pratite logove i postepeno pojačavajte pravila.

7. Ograničenja protoka (rate limiting) i konekcija

Protiv DDoS i bot prometa pomaže ograničenje na OS i aplikaciji. Na primjer, ako jedan IP pravi previše konekcija u sekundi, postavite limit. Na nginxu koristite limit_req i limit_conn, na Apache mod_evasive ili slično. Za aplikaciju ograničite login, pretragu, korpu, plaćanje i API endpoint.

Primjer: login stranica – dozvolite 10 pokušaja po IP-u u minuti. Pretraga – limit 2-5 zahtjeva u sekundi. Kod API-ja dizajnirajte ograničenja po korisniku, IP-u i ponašanju. Tako napadač ne može probiti limit samo mijenjanjem IP adrese.

UFW: primjer sigurne konfiguracije

Na Ubuntu/Debian serveru možete postaviti sigurnu početnu konfiguraciju: provjerite servise, dozvolite SSH pristup za svoju IP, otvorite 80 i 443, postavite default deny za dolazni promet i provjerite status UFW-a. Ako nemate statički SSH pristup, privremeno dozvolite SSH za sve IP, zatim pređite na VPN ili statički IP.

Primjer: admin IP je 203.0.113.10. SSH dozvoljen samo za ovaj IP. Web promet (80, 443) otvoren za sve. Baza, Redis, panel i test portovi zatvoreni. Ova konfiguracija je dobra za male i srednje firme. Za pravilno DNS i domensko usmjeravanje, posjetite Hostragons pretraga domene i registracija.

firewalld i zone logika

Na AlmaLinux, Rocky Linux i RHEL serverima firewalld je standard. Zone su: public (za javne interfejse), trusted (za privatne mreže), drop (za tihi drop neželjenog prometa). Važno je razlikovati runtime i permanent pravila – runtime su odmah aktivna, ali nestaju nakon restarta; permanent ostaju, ali zahtijevaju reload.

U firmama, firewalld servisna pravila olakšavaju administraciju. Na public zoni otvorite http i https, SSH dozvolite samo iz definisanih IP adresa. Ako imate management, backup i user mreže, zone povećavaju sigurnost i preglednost.

CDN, WAF i DDoS zaštita na nivou provajdera

Lokalni firewall odlučuje tek kad paket stigne do servera. Kod velikih DDoS napada cilj je filtriranje prije dolaska. CDN, WAF i DDoS zaštita kod provajdera su zato ključni. CDN servira statički sadržaj sa edge lokacija, WAF filtrira štetne aplikacijske zahtjeve, provajder upija ili čisti napade na mrežnom nivou.

Idealno: DNS ide preko CDN-a, prava IP servera je skrivena, firewall dozvoljava 80 i 443 samo iz CDN IP opsega. Admin portovi su dostupni samo preko VPN-a ili statičkog IP-a. Ovakav model smanjuje rizik direktnog napada i filtrira botove prije nego dođu do aplikacije. Za kombinirani pristup sigurnosti i performansi, pogledajte Vodiči za ubrzavanje i sigurnost web stranice.

Aplikacijski sloj: zaštita od botova

Bot zaštita nije samo IP ban lista. Moderni botovi koriste proxy, mobilne mreže, data centar IP-eve i promjenljive user agente. Potrebna je analiza ponašanja: previše login pokušaja sa istog IP-a u kratkom vremenu, masovno skeniranje 404 stranica, napadi na wp-login.php ili xmlrpc.php, neobični obrasci klikova i sumnjivi headeri.

• Ograničite login i registraciju po IP-u i vremenu.
• Zatvorite ili ograničite nepotrebni XML-RPC.
• Zaštitite admin panel jedinstvenim URL-om, IP ograničenjem i višefaktorskom autentifikacijom.
• Filtrirajte sumnjive user-agent i referer kod WAF-a.
• Koristite CAPTCHA ili nevidljive bot provjere na formama.
• Za API endpoint dodajte ključeve, potpise, kvote i timestamp provjeru.

Važno je ne narušiti korisničko iskustvo. Previše CAPTCHA-a, agresivno blokiranje ili pogrešna geo-ograničenja štete korisnicima. Zato postupno pooštravanje i testiranje je najbolji pristup.

Praćenje logova i alarmi

Firewall instalacija nije kraj – firewall je živ sistem i treba konstantno praćenje. U auth.log ili secure pratite SSH pokušaje, u nginx access.log neobičan broj zahtjeva, u error log 404/500 spike, u sistemskim metrikama CPU i broj konekcija. Jedan alarm može vam uštedjeti dragocjene minute.

Osnovne granice: 100+ 404 zahtjeva sa iste IP u 5 minuta, 20+ login pokušaja na login u 1 minuti, CPU iznad 90% 10 minuta, broj konekcija 3x veći od prosjeka. Granice prilagodite svom sajtu – ključ je poznavanje normalnog prometa.

Najčešće greške i kako ih izbjeći

• Aktiviranje firewall-a bez SSH dozvole: Možete izgubiti pristup udaljenom serveru. Uvijek testirajte u drugoj sesiji.
• Zaboravljanje na IPv6: Servis može biti otvoren na IPv6 iako je IPv4 zatvoren.
• Baza dostupna internetu: Portovi 3306, 5432, 6379, 9200 su stalna meta botova.
• Ostaviti stvarnu IP otvorenu uz CDN: Napadač može zaobići CDN i napasti direktno.
• Mijenjanje pravila bez dokumentacije: Teško je shvatiti šta je koja pravila radila u hitnim situacijama.
• Nedostatak backup pristupa: Ako nemate konzolu, greška može produžiti downtime.

Primjer praktične firewall politike

Za mali poslovni web sajt, politika može biti: default dolazni promet zatvoren; 443 otvoren za sve; 80 otvoren samo za preusmjerenje na HTTPS; SSH dostupan samo sa VPN-a ili statičkog admin IP-a; baza dostupna samo lokalno ili na privatnoj mreži; ako koristite CDN, 80/443 dozvoljeni samo iz CDN IP opsega; Fail2ban prati SSH i web login pokušaje; logovi se šalju centralno.

Za srednju e-trgovinu dodajte: allowlist callback IP-eva za plaćanje, admin panel iza VPN-a, API ograničenja po korisniku, WAF pravila za SQL injection i XSS, privremeno filtriranje po državi ili ASN-u. Politika mora biti napisana – tako u napadu primjenjujete proceduru, ne improvizaciju.

Testiranje: da li pravila zaista rade?

Nakon instalacije firewall-a obavezno testirajte. Skenirajte portove sa drugog mrežnog segmenta, provjerite da SSH radi samo sa dozvoljene IP, provjerite dostupnost web sajta na HTTPS, uvjerite se da baza nije dostupna izvana. Sa CDN-om testirajte direktni HTTP zahtjev na IP servera – mora biti blokiran.

Ne radite agresivne testove koji mogu naštetiti produkciji. Cilj je sigurna verifikacija. Nakon svake promjene eksportujte ili zabilježite pravila – tako se možete vratiti na prethodno stanje ako nastane problem.

Plan održavanja i ažuriranja

Server sigurnost nije jednokratna akcija, već stalni proces. Kad dodate novi servis, provjerite portove; kad uklonite stari, izbrišite dozvole; redovno instalirajte sigurnosna ažuriranja i provjeravajte logove. Najmanje jednom mjesečno testirajte otvorene portove, svaka tri mjeseca pregledajte firewall pravila.

Backup je dio sigurnosti. DDoS može prekidati pristup, ali ransomware ili neovlašteni pristup uzrokuju gubitak podataka. Razmišljajte o sigurnom hostingu, SSL-u, domenama i backupu zajedno. Pogledajte Stvari na koje treba obratiti pažnju pri odabiru sigurnog hostinga i Kako se instalira SSL certifikat za nastavak.

Zaključak

Instalacija firewall-a ne čini server potpuno nevidljivim DDoS-u i botovima, ali značajno smanjuje napadnu površinu, smanjuje rizik neovlaštenog pristupa i omogućuje bolju kontrolu u incidentima. Najbolji rezultat daje kombinacija: DDoS zaštita na nivou provajdera, CDN/WAF, stroga port politika, ograničen SSH, Fail2ban, rate limiting i redovno praćenje logova.

Planirajte firewall politiku na početku projekta – kasnije je mnogo teže ispravljati. Na Hostragons platformi, razmišljajte o sigurnosti zajedno sa serverom, hostingom, domenom i SSL-om. Počnite sa jednostavnom listom: zatvorite nepotrebne portove, ograničite SSH, forsirajte HTTPS i pratite logove.

Često postavljana pitanja

Može li firewall potpuno blokirati DDoS napade?

Ne. Lokalni firewall može smanjiti male i specifične napade, ali za velike DDoS je potrebna zaštita na nivou provajdera, CDN i WAF.

Koji portovi trebaju biti otvoreni na web serveru?

Obično su otvoreni samo 80 i 443. SSH port dozvolite samo admin IP adresama. Baza i interni servisi moraju biti zatvoreni za internet.

UFW ili firewalld – šta koristiti?

Za Ubuntu/Debian UFW je lakši za početak. Na AlmaLinux, Rocky Linux i RHEL firewalld je standard. Za napredne ili specifične potrebe koristite nftables.

Može li se bot promet zaustaviti samo blokadom IP adresa?

Obično ne. Moderni botovi koriste razne IP-eve i proxy-e. Potrebni su rate limiting, WAF pravila, analiza ponašanja, CAPTCHA i kvote na aplikaciji.

Koji je najveći rizik kod instalacije firewall-a?

Najveći rizik je pogrešnim pravilom blokirati vlastiti SSH pristup. Zato prvo definirajte dozvolu za SSH, testirajte u sekundarnoj sesiji i osigurajte konzolu kod provajdera.