Kako zaštititi Linux server: SSH, firewall i nadogradnje

Linux server može godinama raditi stabilno, ali server dostupan internetu treba stalnu zaštitu. Automatizirani pokušaji prijave, iskorištavanje ranjivosti i pogrešne konfiguracije nisu rijetkost. Dobra početna sigurnost ne zahtijeva desetke skupih alata; zahtijeva disciplinu i nekoliko pravilno postavljenih slojeva obrane.

Počnite od inventara i ažuriranja

Zapišite distribuciju, verziju, javne IP adrese, servise i odgovorne osobe. Ako operacijski sustav više ne prima sigurnosne zakrpe, planirajte nadogradnju ili migraciju. Prije većih promjena napravite backup i provjerite mogućnost pristupa konzoli kod pružatelja hostinga.

Ažuriranja automatizirajte tamo gdje je rizik prihvatljiv, ali kritične promjene testirajte. Posebno pratite aplikacije i dodatne repozitorije koji ne pripadaju standardnim paketima distribucije. Zastarjeli web dodatak može biti jednako opasan kao zastario operacijski sustav.

SSH pristup: minimalne ovlasti

Svaki administrator treba vlastiti račun. Koristite SSH ključeve, ograničite pristup administrativnim računima i uklonite nepotrebne korisnike. Kad provjerite da prijava ključem radi i imate alternativan pristup u slučaju pogreške, razmotrite isključivanje prijave lozinkom.

Administratorske naredbe pokrećite uz kontrolirani sudo umjesto stalnog rada kao root. Bilježite administrativne radnje i odmah ukidajte pristupe osobama koje više ne rade na sustavu. Multifaktorska autentifikacija za pristup preko VPN-a ili identitetskog pristupnika može dodatno smanjiti rizik.

Firewall i minimalna izloženost

Prema internetu otvorite samo ono što je potrebno, najčešće HTTPS i eventualno ograničeni administrativni pristup. Baza podataka, Redis, nadzorne ploče i interni servisi u pravilu ne trebaju javne portove. Pravila mrežnog vatrozida postavite tako da propuštaju nužan promet, a ostalo odbijaju.

Ako mijenjate SSH pravila na udaljenom serveru, prvo omogućite novu dozvoljenu vezu i testirajte je u drugoj sesiji. Jedna pogrešna naredba inače može zaključati administratora iz sustava. U produkciji je koristan i izvanpojasni konzolni pristup.

Zaštita aplikacije je zaseban sloj

TLS certifikat, sigurna autentifikacija, validacija ulaza, ograničavanje zahtjeva i upravljanje tajnama jednako su važni. Nije dovoljno sakriti administratorsku stranicu pod neobičnom adresom. Svaki web sustav treba vlastitu konfiguraciju, sigurnosne zakrpe i jasne ovlasti.

Nadzor ne smije ostati na ručnom pregledu. Postavite obavijesti za neuspješne servise, neobične prijave, istjecanje certifikata, disk i backup. Logove čuvajte dovoljno dugo za dijagnostiku, ali definirajte pravila pristupa i zadržavanja osobnih podataka.

Jednostavan sigurnosni pregled

Jednom mjesečno odgovorite na pet pitanja: što je javno dostupno, tko se može prijaviti, koje zakrpe nedostaju, radi li backup i može li se usluga vratiti? Ako je odgovor nepoznat, sigurnosna mjera nije dovršena. Cilj nije obećati apsolutnu zaštitu, nego redovito smanjivati najvjerojatnije rizike i pripremiti oporavak.

Primjer kontrolirane promjene SSH pristupa

Administrator želi onemogućiti prijavu lozinkom. Najprije kreira osobni račun, postavlja javni SSH ključ i provjerava da se može prijaviti u novoj sesiji. Zatim potvrđuje ima li dostupnu konzolu preko pružatelja hostinga. Tek nakon toga mijenja konfiguraciju SSH servisa, provjerava njezinu ispravnost i ponovno testira pristup. Time smanjuje rizik da sam sebe zaključa iz udaljenog poslužitelja.

Slično vrijedi za firewall: nova pravila prvo treba pripremiti i provjeriti da dozvoljavaju postojeći administrativni put. Ozbiljna sigurnost uključuje i sigurnost samog procesa promjene konfiguracije.

Česta pitanja

Pomaže li promjena SSH porta? Može smanjiti količinu automatskog skeniranja, ali nije zamjena za ključeve, ograničen pristup i zakrpe.

Treba li bazu izložiti javnom internetu? U većini poslovnih aplikacija ne. Pristupite joj iz privatne mreže ili preko kontroliranog administrativnog kanala.

Je li firewall dovoljan? Ne. Propusti u aplikaciji, kompromitirani korisnički računi i ranjive ovisnosti i dalje su mogući. Zaštita mora imati više slojeva.

Mjesečna sigurnosna kontrola Linux poslužitelja

Sigurnost se pogoršava kada se promjene na serveru rade bez evidencije. Kratak redoviti pregled može otkriti novi otvoreni port, račun kojem pristup više nije potreban ili servis koji nije ažuriran. Kontrolna lista treba se prilagoditi ulozi servera, a rezultati ostati zabilježeni.

• Jesu li instalirane relevantne sigurnosne zakrpe sustava i aplikacija te postoji li plan za nepodržane verzije?
• Koji portovi slušaju na javnom sučelju i postoji li poslovni razlog da je svaki od njih dostupan?
• Jesu li administratorski računi osobni, prijave zaštićene ključevima i nepotrebni pristupi uklonjeni nakon promjena zaposlenika?
• Jesu li baze, Redis i interni administracijski alati ograničeni na privatnu mrežu ili lokalni pristup?
• Radi li centralno ili lokalno bilježenje važnih sigurnosnih događaja i tko zapravo pregledava upozorenja?
• Postoji li testiran način da se sustav vrati u rad i u slučaju gubitka pristupa samom hostu?

Prava zaštita rezultat je održavanja svih slojeva, ne jedne čarobne naredbe ili paketa.

Za servere kojima pristupaju vanjski suradnici uvedite i redovitu provjeru njihovih računa. Samo ograničavanje porta nije dovoljno ako je ukradeni ključ i dalje važeći. Pristup dodjeljujte za jasnu svrhu, pratite korištenje i uklonite ga kada suradnja prestane.