Ono kad default nije dobar odabir

Cijeli život u razvoju softverskih projekata vodim se jednim pravilom koje sam naučio kao mladi inženjer od kolege, možda i najboljeg developera s kojim sam imao prilike raditi. Pravilo kaže: "Ukoliko imamo potrebu ponuditi neku opciju kao dio postavki softvera, to ne znači da korisniku dajemo mogućnost prilagoditi proizvod prema svojim potrebama, već to znači da mi zapravo ne znamo koja je ispravna postavka." Ovo zapravo znači da što aplikacije imaju više postavki, to smo mi zapravo manje sigurni kako bi aplikacija trebala raditi i manje poznajemo potrebe korisnika. Dakle, kada su postavke u pitanju - manje je bolje, a defaultne postavke trebaju biti takve da omoguće optimalno i nesmetano korištenje proizvoda.

E, ovaj vikend sam naučio da to pravilo nije univerzalno i da, kada je u pitanju sigurnost računalnih sustava, default nije uvijek najbolja opcija. No krenimo redom.

Dio vikenda sam proveo migrirajući mali virtualni poslužitelj s Hetznera na Contabo. Radi se o poslužitelju na kojem se vrte neki moji servisi za monitoriranje IoT stvarčica na moru, kao i dva Minecraft poslužitelja za obiteljska druženja u online svijetu.

Setup je standardni: LTS Ubuntu server, na kojem je konfiguriran UFW firewall koji propušta samo promet po poznatim portovima (SSH, Minecraft, HTTP i HTTPS). SSH demon je konfiguriran da prihvaća autentikaciju korisnika putem ključeva, root account je onemogućen, a samo je određenim korisnicima dozvoljeno spajanje na poslužitelj putem SSH protokola. Apache radi redirect s HTTP-a na HTTPS, na kojem je postavljen Let's Encrypt bot za obnovu SSL certifikata.

Jedina izmjena u odnosu na stari poslužitelj bila je u tome da sam ovaj put ipak odlučio uvesti određenu razinu alarmiranja u slučaju nekih nepredviđenih događaja. Za to se koristi Telegram bot koji šalje poruke u izvanrednim situacijama. Kako prije nisam imao uvida u to koliko su česti pokušaji neuspješnih SSH autentikacija, prvi alarm koji sam složio je alarm kod dodavanja i uklanjanja IP adrese s BAN liste.

Ovo mi se činilo kao jako dobar početak dobivanja uvida u to što se s mojim serverom događa kada ja nisam spojen na njega. E kakav je to hladan tuš bio - telefon se nije gasio. Svako malo nova notifikacija o tome da je nova adresa stavljena na BAN listu.

Uglavnom, unutar tridesetak sati koliko je SSHD bio konfiguriran da sluša na standardnom portu, 234 puta je IP adresa dodana na BAN listu, od čega je 154 adresa bilo jedinstveno.

Dakle, pričamo o ukupno 965 neuspješnih pokušaja prijave.

Fail2ban je bio konfiguriran da polaznu IP adresu stavi na BAN listu i blokira joj pristup do SSH servera nakon tri neuspjela pokušaja, da IP adresu drži na listi sat vremena i da neuspjele pokušaje autentikacije promatra unutar deset minuta.

Kako sam složio Telegram obavijesti za još neke izvanredne situacije (greške u servisu za nadzor IoT uređaja, raspoloživost paketa za nadogradnju, rkhunter obavijesti, auditd obavijesti i lynis obavijesti), vrlo brzo sam došao do zaključka da u moru obavijesti od fail2ban alert-a ostale obavijesti neću ni primijetiti.

Stoga je upravo to saznanje bilo okidač za promjenu. Nakon kratkog razmišljanja zaključio sam da većina napadača koristi glupe skripte (već sama činjenica da imamo opetovane napade s iste IP adrese potvrđuje tu pretpostavku). Zdrava logika nalaže da bi micanje SSHD-a sa standardnog porta na neki random port trebalo značajno smanjiti broj napada i samim time rasteretiti moj Telegram kanal.

Odluka je pala - mijenjamo port na kojem SSHD sluša dolazne konekcije.

Kakva je to pobjeda bila! Od trenutka kada sam promijenio port na random vrijednost do danas fail2ban nije blokirao niti jednu IP adresu. Dakle, možemo slobodno pretpostaviti da u tri dana nismo imali niti jedan pokušaj neuspjele autentikacije na poslužitelj. Moj Telegram kanal je prazan i sadrži samo periodičke poruke drugih servisa.

Za one koji malo više vole slikice od suhoparnog teksta, evo još malo grafova.

Idemo ponešto reći i o samom procesu. Većinu fizičkog posla vezanog za konfiguraciju servera i servisa, kao i instalaciju minecraft server management toola, odradio je Claude code koji ima pristup mom privatnom SSH ključu i koji se SSH-om spaja na server. Znam, znam, nije mi ovo bilo previše pametno za napraviti i svjestan sam toga. Plan za sljedeći korak je za Claude kreirati poseban korisnički račun i dodatni par SSH ključeva koje će koristiti Claude. Taj account potom mogu ručno omogućiti ili ne omogućiti kada god mi treba Claudeov support. Ključevi će biti u odvojenim folderima, tako da Claude neće imati pristup mojim privatnim SSH ključevima i neće postojati šansa da ih na bilo koji način kompromitira. Još bi bolji korak izolacije bio da se Claude vrti u izoliranom virtualnom računalu ili unutar kontejnera pa je i fizički izoliran od hosta. Markdown datoteka koja opisuje cijeli proces i u kojoj su sve skripte nalazi se na githubu i slobodno je možete koristiti ako želite sami napraviti svoj server. Osim postavljanja i hardeninga servera, Claude je iskodirao i python skriptu sa kojom su generirane vizualizacije za ovaj post.

I za kraj najbitnija stvar, cijeli je ovaj proces bio gotov unutar sat vremena. A to predstavlja uštedu od nekoliko dana u odnosu na opciju da se to radi ručno. Dakle, ovo nije posao koji ne bih mogao odraditi ručno, ali bi mi tako uzeo višestruko više vremena. Druga bitna stvar je da sam osobno radio superviziju svake komande koju je Claude izvodio na serveru, tako da sam u svakom trenutku bio svjestan što radi i 100% siguran da nigdje nije uvalio "rm -rf".

Pouka priče je sljedeća: koristite AI, ali ga koristite odgovorno i u svakom trenutku budite svjesni što radi i koje su posljedice njegovih akcija (pozitivne i negativne), a ako trebate bilo kakvu pomoć s AI sustavima ili trebate da vam izgradimo bilo kakav softverski proizvod koji se sastoji od ili je izgrađen od privatnog LLM-a, obratite nam se sa povjerenjem.