File Server Hardening – Deo 3: Linux File Server – Samba hardening

Prva dva dela serije pokrila su Windows fajl server. Treći deo prelazi na Linux stranu — konkretno na Samba, softver koji Linux serveru omogućava da servira fajlove preko istog SMB protokola opisanog u prvom delu serije, čineći Linux share vidljivim Windows klijentima potpuno isto kao i nativni Windows fajl server. Ovo je čest izbor u mešovitim okruženjima — Linux infrastruktura ispod, Windows radne stanice iznad — i dobra vest je da veći deo principa iz prva dva dela serije direktno prenosi ovde, samo kroz drugačiju sintaksu konfiguracije.

Zašto Samba nasleđuje istu istoriju rizika kao i sam SMB

Samba implementira isti SMB protokol koji smo detaljno obradili u prvom delu serije, što znači da nasleđuje i istu istoriju rizika — uključujući EternalBlue ranjivost iskorišćenu u WannaCry i NotPetya napadima 2017. godine, koja je pogodila SMBv1 implementacije bez obzira na to da li su radile na Windows ili Linux sistemu. Podrazumevana Samba konfiguracija na svežoj instalaciji, slično kao i kod Windows-a, nije podešena za produkcionu bezbednost bez dodatnog rada.

Konfiguracioni fajl kao centralna tačka kontrole

Sva Samba podešavanja idu kroz jedan centralni konfiguracioni fajl, /etc/samba/smb.conf, podeljen na globalnu sekciju (podešavanja koja važe za ceo server) i pojedinačne sekcije za svaki share. Ova centralizacija je praktična prednost u odnosu na Windows pristup (gde se podešavanja često rasprostiru kroz GUI, Group Policy i registry) — jedan fajl, čitljiv u tekstualnom obliku, koji se lako verzioniše i pregleda.

Šta treba uraditi

  • Postaviti minimalnu dozvoljenu verziju protokola na SMB2 ili noviju (server min protocol = SMB2), čime se SMBv1 potpuno isključuje na nivou protokola, bez obzira na to šta klijent pokuša da pregovori — isti princip isključivanja SMBv1 opisan u prvom delu serije, ovde primenjen kroz Samba sintaksu
  • Zahtevati SMB signing eksplicitno na obe strane (server signing = mandatory, client signing = mandatory), ne ostavljati na "auto" ili "if_required" vrednosti koje dozvoljavaju da signing bude izostavljen ako druga strana ne insistira na njemu
  • Zahtevati SMB enkripciju (smb encrypt = mandatory ili required, u zavisnosti od verzije Samba-e) za sve konekcije, posebno ako share ikad prolazi kroz mrežni segment van striktno kontrolisane, poverljive interne mreže
  • Nakon svake izmene konfiguracije, proveriti ispravnost sintakse pomoću `testparm` pre restarta Samba servisa — ovaj alat detektuje greške u sintaksi ili logičke sukobe u konfiguraciji pre nego što izazovu problem u produkciji

Napomena o riziku: zahtevanje obavezne enkripcije i SMB2+ minimuma protokola može odseći starije klijente ili treće-strane SMB implementacije koje ne podržavaju te zahteve, isti rizik opisan za Windows u prvom delu serije. Proveriti unapred koji klijenti (uključujući stariju mrežnu opremu, NAS uređaje ili specijalizovane aplikacije) se povezuju na share, i sprovesti period auditinga (Samba loguje odbijene konekcije kad se podigne nivo logovanja) pre stroge primene ovih zahteva.

Kontrola pristupa na nivou mreže — dodatan sloj, ne zamena za firewall

Samba nudi sopstveni, dodatan mehanizam za ograničavanje sa kojih izvornih adresa se sme povezati na server, nezavisno od pravila samog firewall-a opisanih u ranijoj seriji o hardeningu Linux servera. Ovo nije zamena za firewall, već dopunski, aplikativni sloj koji vredi koristiti uporedo.

Šta treba uraditi

  • Koristiti hosts allow i hosts deny direktive u globalnoj sekciji smb.conf da se eksplicitno ograniči koji mrežni opsezi smeju uopšte da se povežu na Samba servis, po istom principu segmentacije koji se provlači kroz svaku seriju na ovom blogu
  • Kombinovati ovo sa firewall pravilima na nivou samog hosta (ograničiti portove 139 i 445 na poznate, očekivane mrežne segmente), ne osloniti se isključivo na Samba-inu internu kontrolu pristupa kao jedinu odbranu
  • Za share-ove koji ne treba da budu vidljivi u mrežnom pregledu (network browsing), postaviti browseable = no na nivou tog konkretnog share-a — ovo ne sprečava direktan pristup ako neko zna tačan naziv share-a, ali smanjuje slučajno otkrivanje osetljivih share-ova kroz rutinsko pregledanje mreže

Dozvole na nivou share-a i fajl sistema

Isti princip dva sloja dozvola opisan za Windows u prvom delu serije postoji i ovde, samo pod drugačijim imenima: Samba share definicija (valid users, write list, read only) kontroliše ko sme da se poveže na share preko mreže i sa kojim nivoom pristupa, dok standardne Linux dozvole fajl sistema (opisane u seriji o hardeningu Linux servera) kontrolišu šta se stvarno sme uraditi na nivou samih fajlova, bilo preko mreže ili lokalno na serveru.

Šta treba uraditi

  • Ograničiti pristup share-u kroz valid users ili valid users = @grupa direktivu, koristeći Linux grupe (idealno sinhronizovane sa AD grupama ako je Samba integrisana u domen) umesto pojedinačnih korisnika, po istom principu opisanom kroz AD i Windows fajl server delove serije
  • Postaviti dozvole na nivou fajl sistema (chmod/chown) tako da odražavaju stvarnu poslovnu potrebu, ne 777 "da bi radilo" — isti anti-obrazac kritikovan kroz svaku prethodnu seriju kad se pojavi u drugom kontekstu
  • Koristiti force group direktivu na nivou share-a gde je potrebno da svi fajlovi kreirani kroz taj share automatski dobiju konzistentno grupno vlasništvo, izbegavajući situaciju gde različiti korisnici kreiraju fajlove sa međusobno nekompatibilnim dozvolama u istom deljenom folderu
  • Redovno proveravati stvarne, efektivne dozvole (kombinaciju Samba share podešavanja i Linux dozvola fajl sistema) po istom principu periodične revizije koji se provlači kroz celu ovu seriju blogova

Logovanje i integracija sa fail2ban

Podrazumevani nivo Samba logovanja je često nedovoljan za bezbednosnu svrhu — dovoljan za osnovno rešavanje problema, ali ne i za praćenje pokušaja neovlašćenog pristupa ili obrazaca koji ukazuju na napad. Podizanje nivoa logovanja, uz integraciju sa fail2ban (alatom detaljno opisanim u prvom delu serije o hardeningu Linux servera), zatvara isti bezbednosni prostor koji smo pokrili za SSH, sada primenjen na SMB autentifikaciju.

Šta treba uraditi

  • Podići nivo Samba logovanja (log level) na vrednost dovoljnu za bezbednosno relevantne događaje (autentifikacija, pristup fajlovima) bez preplavljivanja loga potpuno rutinskim detaljima — testirati konkretnu vrednost u praksi, jer previsok nivo generiše sličan problem prevelikog obima logova opisan za Windows Event ID 4663 u drugom delu serije
  • Konfigurisati fail2ban jail specifično za Samba autentifikacione neuspehe, po istom principu (maxretry, bantime, findtime) opisanom za SSH u ranijoj seriji — Samba je jednako izložena brute-force pokušajima pogađanja lozinke kao i SSH
  • Razmotriti VFS (Virtual File System) audit modul, ugrađenu Samba funkcionalnost koja beleži operacije nad fajlovima (kreiranje, brisanje, preimenovanje) na nivou samog share-a, analogno Windows file access auditingu opisanom u drugom delu serije — ovo daje isti nivo vidljivosti "ko je i kada nešto uradio" na Linux strani
  • Prosleđivati Samba logove na centralnu lokaciju kroz isti mehanizam (rsyslog ili sličan) opisan u Linux Server hardening seriji za auditd zapise — konzistentnost pristupa logovanju kroz celu infrastrukturu olakšava i izgradnju i održavanje centralnog sistema za praćenje

Napomena o riziku: fail2ban konfiguracija bez pažljivo podešene liste izuzetaka (poznata upravljačka mreža, adrese aplikacija koje legitimno prave veći broj konekcija) nosi isti rizik samozaključavanja opisan u ranijoj seriji — testirati podešavanje pre primene u produkciji, i uvrstiti poznate, poverljive izvore na listu izuzetaka unapred.

Redovno ažuriranje — isti princip, ista disciplina

Samba prima redovne bezbednosne ispravke kroz standardni paket menadžer distribucije, i isti princip discipline ažuriranja opisan u trećem delu serije o hardeningu Linux servera važi ovde bez izuzetka — Samba, kao softver koji direktno izlaže mrežnu uslugu, zaslužuje isti prioritet u ciklusu zakrpa kao i SSH ili bilo koji drugi mrežno izložen servis.

Sledeći deo serije bavi se NFS-om — drugim, starijim protokolom za mrežno deljenje fajlova na Linux sistemima, sa svojim sopstvenim, drugačijim modelom autentifikacije i pristupnim rizicima koji zaslužuju odvojenu pažnju od onoga što je pokriveno za SMB/Samba u ovom delu.

Коментари

Постави коментар

Популарни постови са овог блога

Šta je ISO 27001 i da li je mojoj firmi stvarno potreban?

  Prvi tekst na blogu InfoSec bez stresa — i pitanje koje sebi postavi skoro svaki vlasnik male ili srednje firme onog trenutka kad prvi put čuje za ovaj standard. Realna situacija Zamislite ovo: firma ima 15 zaposlenih, radi razvoj softvera ili pruža IT usluge, posluje solidno, sve funkcioniše. Onda stigne mejl od velikog klijenta — banke, osiguravajuće kuće ili strane kompanije s kojom se pregovara o saradnji. U prilogu je bezbednosni upitnik, a na dnu jedna rečenica koja pokvari popodne: „Molimo dostavite ISO 27001 sertifikat ili plan implementacije u naredna tri meseca." Ili, druga verzija iste priče: firma konkuriše na tenderu, sve uslove ispunjava — sem jednog. Traži se ISO 27001. Prva reakcija je obično paničan Google upit u stilu „šta je ISO 27001" i „da li mi to stvarno treba", u ponoć, uz osećaj da se upravo otvorila rupa u budžetu i rasporedu koje niko nije planirao. Ako je ovo vaša situacija — ili slutite da bi mogla postati — ovaj tekst je tu da va...
Прикажи све

ISO 27031: Upravljanje IRBC-om i usklađivanje sa ciljevima kontinuiteta (klauzula 6.1–6.3)

6.1 – Opšte Standard deli uzroke prekida u nekoliko grupa: prirodni uzroci – požar, poplava. Retki, ali fizički pogađaju celu lokaciju odjednom, ne samo jednu komponentu. tehnički kvarovi – hardver, softver, napajanje, klimatizacija. Najčešća kategorija u praksi, i ona za koju firme obično imaju najviše iskustva. ljudska greška – loše podešen bekap, propust u upravljanju izmenama. Retko ko je namerno kriv, ali posledice su iste kao da jeste. namerna akcija – hakovanje, malver, sabotaža. Ovde je pored oporavka bitna i istraga – ko je i kako ušao. društveni faktori – pandemija, štrajk. Ne pogađaju tehnologiju direktno, nego ljude koji je održavaju. cyber napadi – DoS, DDoS, napadi koji preplave sistem saobraćajem dok ne prestane da radi. lanac snabdevanja – prekid kod cloud provajdera, nejasni bezbednosni uslovi u ugovoru sa dobavljačem. Ovde firma nema direktnu kontrolu, samo ugovor i poverenje. Rizik da IT prestane da radi ima jedan prepoznatljiv obrazac: retko se ...
Прикажи све

ISO 22301:2019 u praksi — Praktična obuka na primeru fabrike piva

Ova serija od osam članaka provodi vas kroz sve zahteve standarda ISO 22301:2019 — Sistemi upravljanja kontinuitetom poslovanja (BCMS) , klauzulu po klauzulu, na konkretnom praktičnom primeru: fiktivnoj proizvodnoj pivari „Zeleni Hmelj" d.o.o. , sa sopstvenom varionicom, punionicom i hibridnom IT/OT arhitekturom (SCADA/PLC industrijski sistemi, lokalni ERP i cloud servisi — Microsoft 365, cloud backup/DR, SaaS CRM). Umesto apstraktnog prepričavanja teksta standarda, svaki post gradi stvaran, upotrebljiv dokument — politiku, matricu, BIA analizu, BCP plan, zapisnik — kakav bi auditor tražio na sertifikacionoj proveri. Kroz celu seriju provlači se jedan princip: zahtevi kontinuiteta poslovanja dolaze od biznisa ka IT sektoru, a ne obrnuto — proizvodnja i komercijala definišu koliko dugo mogu da izdrže bez svog sistema, a IT/OT sektor sprovodi tehnička rešenja koja taj zahtev ispunjavaju. Sadržaj serije Deo 1 Uvod u BCMS i Klauzula 4 — Kontekst organizacije Razlika BCMS v...
Прикажи све