Sigurnost podataka na Linuxu: sigurnosni audit i hardening servera

Article Image

Zaštita podataka na Linux serveru: zašto audit i hardening nisu opcija

Kao administrator ili odgovorna osoba za server, vi upravljate sistemom koji sadrži kritične informacije — korisničke podatke, konfiguracije i aplikacije. Nepravilno konfigurisani servisi, zaostali bagovi ili nepotrebni procesi mogu otvoriti puteve za napadače. Sigurnosni audit i hardening su praktični procesi koji vam omogućavaju da otkrijete ranjivosti, smanjite površinu napada i primenite dosledna pravila zaštite.

Audit daje mapu trenutnog stanja: šta radi, ko ima pristup i gde su potencijalne tačke proboja. Hardening je skup tehnika kojim smanjujete rizik — zatvarate portove, ograničavate privilegije i primenjujete sigurnosne politike. U ovom delu upoznaćete se sa osnovnim pristupom koji će vam pomoći da audit i hardening sprovedete sistematski i ponovljivo.

Kako planirati sigurnosni audit: šta treba prikupiti i zašto

Pre nego što počnete sa promenama, potrebno je da prikupite podatke i definišete obim audita. Bez jasnog planiranja postoji rizik da preskočite kritične elemente ili da izvršite izmene koje prekidaju rad servisa.

  • Popis servisa i procesa: identifikujte šta je aktivno (web serveri, baze, cron poslovi) i koje verzije koristite.
  • Korisnici i privilegije: pregledajte korisničke naloge, sudo pravila i grupne dodele — posebno naloge sa root pristupom.
  • Otvoreni portovi i mrežna konfiguracija: skenirajte portove i proverite firewall pravila (iptables/nftables/ufw).
  • Logovi i audit zapisi: sakupite sistemske logove, autentifikacione zapise i dnevnik aplikacija; bez njih ne možete rekonstruisati incidente.
  • Patch nivo i paketi: evidentirajte zastarele pakete i poznate ranjivosti u instaliranim softverima.

Dok prikupljate ove informacije, vodite evidenciju u strukturisanom obliku (tabele, CSV ili alat za praćenje promena). Ovo vam omogućava da pratite napredak, vratite promene ako je potrebno i ponovo izvršite audit nakon primene mera.

Brzi alati i tehnike za početno prikupljanje podataka

  • ps, ss/netstat za pregled procesa i mreže
  • dpkg/rpm za listu instaliranih paketa
  • grep i journalctl za ekstrakciju relevantnih logova
  • nmap sa spoljne perspektive da biste otkrili vidljive servise

Ovi koraci su osnova — cilj je da dobijete celovitu sliku pre nego što krenete u hardening. Sledeći deo će vas provesti kroz konkretne principe hardeninga: minimizaciju napadnih površina, upravljanje privilegijama i primenu sigurnosnih mehanizama kao što su SELinux/AppArmor i enkripcija.

Minimizacija napadne površine: uklanjanje, zatvaranje i izolacija

Prvi i najefikasniji korak hardeninga je smanjivanje onoga što napadač može da vidi i iskoristi — što manje usluga, portova i paketa, to manje mogućih vektora napada. Minimizacija treba da bude sistematska i ponovljiva.

  • Uklanjanje nepotrebnog softvera: zaustavite i uklonite pakete koje sistem ne zahteva. Na Debian/Ubuntu: apt purge paket, na RHEL/CentOS: yum remove paket. Pre nego što uklonite, proverite zavisnosti i napravite backup konfiguracija.
  • Onemogućavanje servisa: listajte aktivne jedinice (systemctl list-unit-files --state=enabled) i onemogućite sve što nije kritično (systemctl disable --now servis).
  • Kontrola mreže: skenirajte otvorene portove (ss -tuln) i zatvorite nepotrebne kroz firewall (npr. nftables/iptables/ufw). Pravila bi trebalo da budu „deny by default“ i eksplicitno dozvoljavanje samo potrebnih portova.
  • Izolacija servisa: koristite namespace-e, cgroups ili kontejnerizaciju (systemd-nspawn, Docker, Podman) da ograničite uticaj kompromitovanog procesa. Razmotrite korišćenje sandboksa za aplikacije (firejail, seccomp).
  • Redukcija površine na nivou paketa: preferirajte minimalne instalacione profile i LTS verzije; uklonite razvojne alate sa produkcijskih servera (kompajleri, debuggers) koji olakšavaju eskalaciju.
Article Image

Upravljanje privilegijama i politike pristupa

Kontrola ko i šta može da radi na sistemu je ključna. Primena principa najmanjih privilegija i striktna politika upravljanja pristupom smanjuju rizik od internog i eksternog kompromitovanja.

  • Sudo i delegiranje prava: koristite /etc/sudoers umesto deljenja root lozinke; uređujte kroz visudo. Ograničite komande koje su dozvoljene, logujte sudo session-e i razmislite o vremenski ograničenim privilegijama.
  • Onemogućite direktan root login: u SSH konfiguraciji (/etc/ssh/sshd_config) postavite PermitRootLogin no i prisilite autentifikaciju preko ključeva (PasswordAuthentication no kad je moguće).
  • Razdvajanje naloga i RBAC: definišite uloge (operater, developer, DBA) i koristite Linux grupe, sudoers, ili alate za RBAC (npr. FreeIPA, LDAP) za centralizovano upravljanje pristupom.
  • Provera i čišćenje privilegovanih binarnih fajlova: redovno skenirajte setuid/setgid fajlove (find / -perm -4000 -type f -ls) i uklonite ili zameni one koji nisu neophodni; gde je moguće koristite Linux capabilities (setcap) umesto potpunog root privilegija.
  • PAM i autentifikacija: konfigurišite PAM politike za složenije zahteve (blokiranje slabih lozinki, ograničavanje pokušaja prijave, 2FA). Upotrebom fail2ban-a ili sistemskih rate-limit pravila smanjite rizik brute-force napada.

Mandatory Access Control (SELinux/AppArmor) i enkripcija podataka

Kontrolni mehanizmi na nivou jezgra i šifrovanje čuvaju podatke i ograničavaju posledice kompromitovanja procesa.

  • SELinux ili AppArmor: aktivirajte i pređite u enforcing režim kada je moguće. Proverite status (sestatus ili aa-status), pratite audit logove i koristite audit2allow ili profile da fino doterate politike. Ne ostavljajte MAC u permissive režimu trajno — koristite ga za testiranje pa pređite na enforcing.
  • Enkripcija diska i swap: koristite LUKS za full-disk ili particionu enkripciju (cryptsetup luksFormat, cryptsetup open) i obavezno šifrujte swap da biste sprečili izlistavanje osetljivih podataka iz memorije.
  • TLS i komunikacija: obavezno koristite TLS za sve servise koji prenose osetljive podatke (web, IMAP, SMTP, interne API-jeve). Konfigurišite jake šifre, automatsko obnavljanje certifikata (Let’s Encrypt + certbot) i OCSP stapling gde je moguće.
  • Sigurni backup-i i menadžment ključeva: enkriptujte bekap fajlove (GPG, age), ograničite pristup ključevima i planirajte rotaciju i sigurno skladištenje ključeva (HSM/TPM ili upravljani KMS za cloud).
Article Image

Zaključno razmišljanje i sledeći koraci

Bezbednost sistema nije jednokratan zadatak već kontinuirani proces koji zahteva rutinu, praćenje i timsku disciplinu. Nakon inicijalnog audita i primene mera hardeninga, fokus prebacite na automatizaciju, monitoring i redovne provere kako biste održali stanje sigurnosti bez regresija. Automatizujte konfiguracije i politike (npr. pomoću alata za upravljanje konfiguracijom i skeniranje), integrišite alarme i playbook-ove za incident response, i planirajte periodične revizije kako biste pravovremeno otkrili promene.

Za smernice i preporuke konfiguracija možete pratiti standarde i preporuke industrije — na primer CIS Benchmarks — i prilagoditi ih specifičnostima vaše infrastrukture. Uvek testirajte promene u kontrolisanom okruženju pre primene na produkciji i obučavajte tim da prepozna i reaguje na bezbednosne incidente.

Frequently Asked Questions

Koliko često treba pokretati kompletan sigurnosni audit?

Preporuka je najmanje jednom godišnje za kompletan audit, uz kraće, ciljane inspekcije (npr. nakon važnih promena, nadogradnji ili incidenta) kvartalno ili mesečno za kritične komponente. Frekvencu prilagodite riziku i regulativnim zahtevima.

Koji je prvi praktični korak na postojećem serveru koji nikada nije bio auditan?

Počnite sa bezbednosnom kopijom i inventarizacijom: sačuvajte konfiguracije i podatke, evidentirajte aktivne servise i otvorene portove, i zatim onemogućite očigledno nepotrebne servise. Nakon toga uvedite ograničenje pristupa i obaveznu autentifikaciju preko ključeva za SSH.

Da li aktivacija SELinux-a ili AppArmor-a može da prekine postojeće aplikacije?

Da, prelazak iz permissive u enforcing režim može uzrokovati da aplikacije izgube pristup resursima ako politike nisu pravilno definisane. Zato prvo testirajte u permissive modu, analizirajte audit zapise i postepeno prilagodite politike pre nego što pređete na enforcing.