Linux Server Hardening – Deo 2: Firewall i minimizacija mrežno izloženih servisa

Prvi deo serije pokrio je SSH i sudo — kako se pristupa serveru i kako se upravlja administrativnim privilegijama. Drugi deo se bavi onim što server propušta na mrežnom nivou i šta uopšte radi u pozadini: firewall politiku i minimizaciju servisa koji su izloženi mreži. Sveža instalacija Linux servera dolazi bez ijednog firewall pravila i sa nizom servisa pokrenutih po difoltu — ni jedno ni drugo nije podešeno za bezbednost, već za praktičnost prilikom prve instalacije.

Alati se razlikuju, princip ostaje isti

Ovo je tačka gde se distribucije najviše razilaze u sintaksi, pa vredi razjasniti pejzaž pre nego što pređemo na princip. Na nivou kernela, gotovo sve savremene distribucije danas koriste nftables kao Netfilter podsistem za filtriranje paketa — čak i kad administrator i dalje kuca iptables komande, one se u pozadini najčešće prevode kroz kompatibilni sloj (iptables-nft) i izvršavaju preko nftables mehanizma. Iznad toga, administratori retko rade direktno sa nftables sintaksom; umesto toga koriste front-end alate: UFW je uobičajen izbor na Debian/Ubuntu sistemima, dok firewalld dominira na RHEL familiji distribucija (Rocky, AlmaLinux, Fedora).

Bez obzira na to koji alat je u upotrebi, princip koji ova serija zastupa kroz sve teme ostaje identičan: podrazumevano odbij (default deny), eksplicitno dozvoli samo ono što je stvarno potrebno.

Šta treba uraditi

• Odabrati front-end alat u skladu sa distribucijom i timskim iskustvom (UFW, firewalld, ili direktno nftables za slučajeve koji zahtevaju finiju kontrolu) i držati se dosledno jednog alata po serveru — mešanje više firewall alata na istom sistemu (npr. ručni iptables skriptovi uz UFW) je čest izvor konfuzije i sukobljenih pravila
• Postaviti podrazumevanu politiku za dolazni saobraćaj na "odbij" (deny/drop), a zatim eksplicitno dozvoliti samo servise koji server stvarno pruža — tipično SSH (na ograničen opseg izvora, opisan u prvom delu serije) i, za veb server, portove 80/443
• Razmotriti i podrazumevanu politiku za odlazni saobraćaj, posebno na serverima sa osetljivim podacima — isti princip opisan u seriji o Windows Server hardeningu, gde ograničena odlazna pravila otežavaju napadaču sledeći korak nakon početnog upada
• Uključiti logovanje odbijenih (dropped) paketa, uz razumno ograničenu stopu logovanja da se izbegne prepunjavanje diska u slučaju intenzivnog skeniranja

Napomena o riziku: uvođenje default-deny politike na aktivnom, produkcionom serveru nosi ozbiljan rizik samozaključavanja ako se SSH pravilo ne doda pre nego što se politika primeni — dodati eksplicitno dozvoljavajuće pravilo za SSH kao prvi korak, potvrditi da radi iz odvojene sesije, i tek onda uključiti podrazumevano odbijanje. Ovo je isto pravilo predostrožnosti opisano u prvom delu serije za SSH konfiguraciju, ovde primenjeno na firewall kao celinu.

Kontejneri kao čest izvor zaobilaženja firewall pravila

Vredi posebno istaći scenario koji iznenađuje mnoge administratore: Docker (i slični kontejnerski sistemi) po difoltu direktno manipuliše pravilima firewall-a kako bi objavio (publish) portove kontejnera, često zaobilazeći pravila koja je administrator postavio kroz UFW ili firewalld. Rezultat je situacija u kojoj administrator vidi naizgled ispravno postavljen firewall, dok je port kontejnera u stvarnosti otvoren ka celom internetu, mimo te konfiguracije.

Šta treba uraditi

• Ako se koristi Docker, eksplicitno podesiti da poštuje postojeća pravila (npr. kroz DOCKER-USER lanac na nftables/iptables nivou), umesto da se pretpostavi da će front-end firewall alat automatski kontrolisati i kontejnerski saobraćaj
• Nakon svakog pokretanja kontejnera koji objavljuje port, proveriti stvarno stanje sistema (ne samo status UFW/firewalld alata) da se potvrdi da nije nastala neplanirana izloženost
• Za kontejnerizovane aplikacije koje ne moraju biti direktno dostupne spolja, koristiti reverse proxy koji izlaže samo portove 80/443 ka spoljnoj mreži, dok sami kontejneri ostaju dostupni isključivo na internom mrežnom segmentu

Popis onoga što server zaista radi

Otvoreni portovi imaju tendenciju da se vremenom akumuliraju bez ičije svesne odluke — test okruženje koje niko nije uklonio, administrativni interfejs otvoren radi jednokratnog rešavanja problema i nikad zatvoren, baza podataka koja je trebalo da sluša samo lokalno, a ispostavilo se da je dostupna sa celog interneta. Servisi poput Redis-a, Elasticsearch-a, MongoDB-a ili Jenkins-a redovno se pronalaze izloženi internetu upravo na ovaj način — ne zato što je neko namerno tako odlučio, već zato što se nikad nije sprovela sistematska provera.

Šta treba uraditi

• Redovno proveravati koji portovi zaista slušaju na serveru (npr. `ss -tulpn`) i za svaki potvrditi da postoji jasan, dokumentovan razlog zašto je otvoren
• Popisati sve aktivne servise (npr. `systemctl list-units --type=service --state=running`) i za svaki koji nije eksplicitno potreban za funkciju tog servera, zaustaviti ga i onemogućiti (`systemctl disable --now`)
• Ukloniti nepotrebne pakete sa produkcionih servera, ne samo servise — kompajleri, razvojni alati i slični paketi koji su možda bili potrebni tokom postavljanja sistema retko imaju razlog da ostanu na produkcionom serveru trajno
• Za servise koji zaista moraju da rade lokalno, ali ne treba da budu dostupni spolja (baze podataka, keš servisi, interni API-jevi), eksplicitno ih vezati (bind) na loopback adresu (127.0.0.1) ili internu mrežnu adresu, umesto na sve interfejse (0.0.0.0), tako da mrežna izloženost i ne postoji nezavisno od firewall pravila

Napomena o riziku: gašenje servisa koji izgleda nepotrebno može prekinuti funkcionalnost koja nije odmah očigledna — pre gašenja bilo kog servisa na produkcionom serveru, proveriti da ga zaista ništa ne koristi, ugasiti ga prvo (ne trajno onemogućiti) i pratiti sistem kroz razuman period pre trajnog onemogućavanja. Reboot servera u kontrolisanom prozoru za održavanje, nakon serije izmena, koristan je način da se potvrdi da ništa neočekivano ne pokušava da se pokrene ili ne uspeva da startuje.

Dodatni sloj — ograničavanje servisa koje ne možete ukloniti

Za servise koji moraju da ostanu aktivni i mrežno dostupni (npr. sam veb server), moderni systemd nudi mogućnost dodatnog ograničavanja unutar samog definisanog servisa (unit fajla), nezavisno od firewall-a — direktive koje servisu oduzimaju mogućnosti koje mu uopšte nisu potrebne za normalan rad, čak i ako je taj servis kompromitovan.

Šta treba uraditi

• Za kritične servise, razmotriti dodavanje systemd sandboxing direktiva u unit fajl — na primer ProtectSystem=strict (fajl sistem samo za čitanje van eksplicitno dozvoljenih putanja), PrivateTmp=yes (izolovan privremeni prostor), NoNewPrivileges=yes (servis ne može da eskalira privilegije preko setuid mehanizma)
• Pokretati servise pod dedikovanim, neprivilegovanim nalogom, ne pod root-om, gde god aplikacija to podržava — isti princip najmanjih privilegija primenjen na nivou servisnog naloga, analogan servisnim nalozima opisanim u seriji o hardeningu MSSQL-a
• Testirati ove dodatne restrikcije u kontrolisanom okruženju pre primene u produkciji — neke aplikacije očekuju pristup delovima fajl sistema ili mogućnostima koje sandboxing direktive podrazumevano ograničavaju, pa prestrogo podešavanje može prekinuti legitiman rad

Sledeći deo serije bavi se automatskim ažuriranjem i upravljanjem paketima — kako uspostaviti disciplinu zakrpa na Linux serveru bez konstantnog ručnog nadzora, i kako prepoznati razliku između paketa koji zaslužuje pažljivo testiranje i onog koji može ići kroz automatizovan proces bez zastoja.