Linux Server Hardening – Deo 1: Osnovna bezbednosna podešavanja i pristup

Ovim tekstom počinje nova serija posvećena hardeningu Linux servera — namerno pisana distribution-agnostic, jer principi ostaju isti bez obzira na to da li je u pitanju Ubuntu, Debian, RHEL/Rocky ili neka druga distribucija, dok se konkretne komande i putanje fajlova razlikuju. Gde je razlika bitna, biće naznačena; van toga, fokus je na principu, ne na sintaksi jedne konkretne distribucije. Prvi deo pokriva osnovu koja određuje sve ostalo — pristup serveru preko SSH-a i upravljanje administrativnim privilegijama preko sudo mehanizma.

Zašto SSH dobija prvo mesto u ovoj seriji

Podrazumevana instalacija Linux servera dolazi podešena za praktičnost, ne za bezbednost — SSH po difoltu često dozvoljava prijavu lozinkom i direktnu prijavu kao root korisnik. Server izložen internetu sa ovakvom konfiguracijom biva pronađen i napadnut automatizovanim skeniranjem u roku od nekoliko sati od puštanja u rad, bez obzira na to koliko je "nebitan" ili privremen taj server u nečijoj proceni. SSH je gotovo uvek prvi, a često i jedini spoljni ulaz u server, pa hardening s pravom počinje upravo tu.

Autentifikacija ključem umesto lozinkom

Prijava lozinkom preko SSH-a je izložena brute-force napadima — automatizovanim, kontinuiranim pokušajima pogađanja lozinke, koji se na internet-izloženom serveru dešavaju kontinuirano, ne povremeno. Autentifikacija javnim/privatnim ključem eliminiše ovaj vektor napada u potpunosti: bez odgovarajućeg privatnog ključa, prijava lozinkom uopšte nije moguća, koliko god pokušaja napadač uputio.

Šta treba uraditi

• Generisati SSH par ključeva za svakog administratora koji pristupa serveru, i postaviti javni ključ na server pre nego što se lozinka isključi
• U konfiguraciji SSH servera (tipično /etc/ssh/sshd_config) postaviti PasswordAuthentication na "no", čime se prijava lozinkom u potpunosti onemogućava
• Onemogućiti i direktnu prijavu root korisnika preko SSH-a (PermitRootLogin no) — administracija treba da ide preko običnog naloga i sudo mehanizma, opisanog dalje u tekstu
• Za timove, razmotriti SSH sertifikate umesto pojedinačnih javnih ključeva na svakom serveru — sertifikat izdat od strane interne autoriteta pojednostavljuje opozivanje pristupa kad neko napusti tim, bez potrebe da se ručno uklanja ključ sa svakog servera pojedinačno

Napomena o riziku: isključivanje autentifikacije lozinkom pre nego što je javni ključ zaista postavljen i testiran vodi direktno u trajno zaključavanje iz servera. Pre bilo koje izmene SSH konfiguracije, napraviti kopiju konfiguracionog fajla, proveriti ispravnost sintakse novog fajla (npr. `sshd -t`) pre restarta servisa, i — najvažnije — nikad ne zatvarati postojeću SSH sesiju dok se u potpuno odvojenom terminalu ne potvrdi da nova prijava, sa novim podešavanjima, zaista radi. Ako je moguće, obezbediti i alternativan pristup (konzola servera preko hipervizora ili provajdera) kao rezervni put u slučaju greške.

Ograničavanje ko i odakle sme da se poveže

I uz autentifikaciju ključem, SSH servis izložen celom internetu ostaje meta neprekidnog skeniranja i pokušaja povezivanja, čak i ako svaki takav pokušaj propadne. Dodatni slojevi ograničenja smanjuju i vidljivost servisa i broj legitimnih razloga za brigu.

Šta treba uraditi

• Ograničiti SSH pristup na nivou firewall-a (obrađenog detaljnije u sledećem delu serije) na poznate, očekivane izvorne adrese ili opsege — upravljačku mrežu, VPN opseg, ili poznate kancelarijske adrese, umesto da port ostane otvoren ka celom internetu
• Razmotriti promenu podrazumevanog SSH porta (22) na drugi, nestandardni port — ovo ne predstavlja stvarnu bezbednosnu meru u smislu otpornosti na ciljani napad, ali značajno smanjuje "pozadinsku buku" automatizovanog skeniranja u logovima, čime stvarni, ciljani pokušaji postaju lakše uočljivi
• Eksplicitno navesti (AllowUsers ili AllowGroups u sshd_config) koji nalozi ili grupe uopšte smeju da se povežu preko SSH-a, umesto da podrazumevano važi da svaki nalog na sistemu ima i SSH pristup
• Uvesti fail2ban ili sličan alat koji automatski, privremeno blokira izvorne adrese nakon više uzastopnih neuspešnih pokušaja prijave — razuman polazni obrazac je tri do pet pokušaja u kratkom vremenskom prozoru, sa periodom blokade od bar sat vremena, produženim za ponovljene prekršioce

Napomena o riziku: uvođenje fail2ban-a ili sličnog alata bez pažljivo podešene "ignoreip" liste (adrese koje se nikad ne blokiraju) nosi rizik da administrator sam sebe privremeno zaključa nakon serije sopstvenih pogrešno ukucanih lozinki ili prekinutih konekcija — uvrstiti poznatu upravljačku mrežu na tu listu unapred. Promena SSH porta takođe zahteva usklađivanje firewall pravila i eventualnih monitoring alata koji očekuju SSH na standardnom portu — testirati novu konfiguraciju iz odvojene sesije pre nego što se stara ukine, po istom principu opisanom za izmenu autentifikacije.

Sudo umesto deljenog root pristupa

Za razliku od Windows-a, gde je moguće u potpunosti onemogućiti ugrađeni Administrator nalog, root nalog na Linux-u uvek postoji — ne može se obrisati niti trajno isključiti na isti način. Zaštita zato ide preko kontrole puteva ka root-u: ko sme da postane root, i na koji način, umesto pokušaja da se sam root nalog ukloni.

Praksa direktne prijave kao root, ili deljenja root lozinke između više administratora, čini nemogućim da se naknadno utvrdi ko je tačno izvršio koju akciju — svaka akcija u logu jednostavno piše "root", bez ikakvog traga o tome koja je stvarna osoba to izvela. Sudo mehanizam rešava ovaj problem: administrator se prijavljuje sopstvenim, imenovanim nalogom, i koristi sudo da privremeno izvrši komande sa povišenim privilegijama, uz jasan zapis o tome ko je i kada tu komandu pokrenuo.

Šta treba uraditi

• Zaključati (ne obrisati) root nalog za direktnu prijavu — na primer, postaviti mu shell na /sbin/nologin ili ekvivalentnu vrednost, i zaključati lozinku (`passwd -l root`), tako da direktna prijava kao root postane praktično nemoguća
• Kreirati imenovan nalog za svakog administratora, dodati ga u odgovarajuću administratorsku grupu (npr. sudo ili wheel grupu, u zavisnosti od distribucije), i koristiti sudo za sve operacije koje zahtevaju povišene privilegije
• Konfigurisati sudo pravila (kroz /etc/sudoers ili fajlove u /etc/sudoers.d/) što je moguće preciznije — ako je nekome zaista potreban samo pristup za restart određenog servisa, dodeliti tačno to pravo, ne neograničen sudo pristup "za svaki slučaj"
• Osigurati da je sudo aktivnost logovana (podrazumevano jeste, kroz syslog ili journal) i da se ti logovi prosleđuju na centralnu lokaciju, po istom principu centralizovanog logovanja opisanom kroz prethodne serije na ovom blogu za Windows okruženja
• Ukloniti ili onemogućiti stare, neiskorišćene sistemske naloge koji dolaze uz podrazumevanu instalaciju, a nemaju stvarnu funkciju na tom serveru (npr. nalozi poput games ili news na nekim distribucijama) — postaviti im nologin shell umesto brisanja, radi izbegavanja potencijalnih problema sa vlasništvom fajlova

Napomena o riziku: zaključavanje root naloga pre nego što je bar jedan administratorski nalog sa ispravno podešenim sudo pristupom potvrđeno funkcionalan nosi isti rizik od zaključavanja kao i preuranjeno isključivanje SSH lozinke — testirati sudo pristup novog naloga (uključujući mogućnost da se, ako je zaista potrebno, privremeno postane root preko `sudo -i`) pre nego što se root nalog zaključa. Prestrogo definisana sudo pravila mogu, takođe, sprečiti administratora da izvrši legitiman, hitan zadatak u trenutku krize — balansirati preciznost sa realnom operativnom potrebom, i imati jasan proces za brzo proširenje ovlašćenja kad okolnosti to zaista zahtevaju.

Sledeći deo serije bavi se firewall-om i minimizacijom mrežno izloženih servisa — koji su podrazumevano dostupni servisi zaista potrebni, i kako uspostaviti "podrazumevano odbij" politiku bez nesvesnog prekidanja rada aplikacija koje server hostuje.