Što ne smijete raditi

Modul 10: Ostanite sigurni · Vrijeme čitanja: 12 minuta

Cilj učenja: Nakon ove lekcije prepoznat ćete pogreške koje najčešće dovode do hakiranog ili pokvarenog poslužitelja, moći ćete objasniti zašto su opasne i znat ćete što učiniti umjesto toga.

Ključni pojmovi: root prijava lozinkom, slaba ili zadana lozinka, otvorena baza podataka, Docker API na priključku 2375, docker.sock u kontejneru, chmod 777, curl | bash, tajne u Gitu, administratorska ploča bez dvofaktorske provjere, vatrozid "nakratko isključen", bez ažuriranja, bez sigurnosne kopije

Zašto lekcija o pogreškama?

Većinu poslužitelja ne hakira genijalni napadač s nepoznatim propustom. Hakiraju ih botovi koji pretražuju cijeli internet u potrazi za poznatim pogreškama: lozinkom koju je moguće pogoditi, bazom podataka koja je otvorena, programom kojem već mjesecima nedostaje ažuriranje. Tko izbjegne pogreške iz ove lekcije, tim botovima više nije zanimljiv. To je najveći dio zaštite koju možete postići.

Uz svaku pogrešku navodimo zašto je opasna i što učiniti umjesto toga. Gotovo sve ste naučili u prethodnim lekcijama; ova lekcija to sažima na jednom mjestu.

1. Root prijava lozinkom

Problem. Svaki poslužitelj cijeli dan prima pokušaje prijave na root (lekcija 5.3). Ako se root može prijaviti lozinkom, ta je lozinka jedino što stoji između bota i potpune kontrole. Ponovno korištene ili prekratke lozinke prije ili kasnije budu pogođene ili se već nalaze na nekom procurjelom popisu.

Učinite ovo. Prijavljujte se samo ključevima: PasswordAuthentication no i KbdInteractiveAuthentication no, root najviše ključem (PermitRootLogin prohibit-password) ili nikako (no), a svakodnevno radite kao običan korisnik sa sudo ovlastima (lekcije 2.2 i 3.2). Izvana provjerite koje načine prijave Vaš poslužitelj nudi (zadatak Z2.2).

2. Baza podataka, predmemorija ili klaster za pretraživanje otvoreni prema internetu

Problem. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch ili OpenSearch (9200) i MongoDB (27017) namijenjeni su pouzdanim programima u pouzdanoj mreži. Ako slušaju na 0.0.0.0 bez vatrozida, skeneri ih brzo pronađu. Redis u vlastitoj dokumentaciji navodi da ne smije biti izložen internetu te da netko s pristupom može izbrisati cijeli skup podataka; naredbom CONFIG napadač može čak zapisivati datoteke na poslužitelj. Otvorene baze podataka i klasteri za pretraživanje već su godinama poznat uzrok velikih povreda podataka i poruka s traženjem "otkupnine" umjesto Vaših podataka.

Učinite ovo. Neka takve usluge slušaju na 127.0.0.1 (lekcija 5.1), držite ih iza vatrozida (lekcija 5.2) i u Dockeru ih ne objavljujte ili ih objavite samo na 127.0.0.1 (lekcija 9.3). Ako im sami trebate pristupiti s prijenosnog računala: SSH tunel (lekcija 2.3). Provjerite izvana (zadatak Z5.1).

3. Otvoren Docker API ili docker.sock u kontejneru

Problem. Tko može upravljati Docker daemonom, zapravo je root na poslužitelju: Docker dokumentacija navodi da daemonom smiju upravljati samo pouzdani korisnici i pristup daemonu izjednačava s root pristupom. Dvije inačice ove pogreške:

• Daemon sluša na TCP priključku bez TLS-a (uobičajeno je 2375). Svatko tko dođe do tog priključka može pokretati kontejnere u koje je uključen disk Vašeg poslužitelja.
• Kontejner dobije /var/run/docker.sock kao volumen ("tako može sam upravljati kontejnerima"). Ako taj kontejner bude hakiran, gotovo je s cijelim poslužiteljem.

I grupa docker jednaka je rootu (lekcija 9.2): u nju stavite samo administratore.

Učinite ovo. Neka Docker radi samo preko lokalnog socketa. Udaljeno upravljanje ide preko SSH-a (docker context s ssh://), a ako baš mora preko TCP-a, onda s TLS-om na priključku 2376 i klijentskim certifikatima. docker.sock montirajte samo u kontejner kojem potpuno vjerujete i koji ga zaista treba, i po mogućnosti samo za čitanje putem ograničavajućeg proxyja.

4. chmod 777 kako bi nestala poruka o pogrešci

Problem. Pri prijenosu datoteke pojavi se "Permission denied", a neki forum kaže: chmod -R 777 /var/www. Nakon toga svaki korisnik i svaki proces na poslužitelju može pisati bilo što u Vašu web-stranicu, uključujući hakirani dodatak ili neki drugi račun. Kod u koji web-poslužitelj može pisati napadač kroz propust može zamijeniti stražnjim vratima (backdoor).

Učinite ovo. Utvrdite tko mora pisati i gdje (lekcija 3.1): obično samo korisnik web-poslužitelja, u jednu mapu za prijenose ili predmemoriju. Kod neka ima drugog vlasnika od web-poslužitelja, prava 644/755, prijenosi 750/640 ili slično.

5. curl ... | bash i softver s bilo kojeg mjesta

Problem. Skripta koju bez pregledavanja pokrenete kao root može sve: dodati izvore i ključeve, prepisati datoteke, otvoriti uslugu. Čak i kad je namjera dobra, poslije ne znate što se promijenilo, a pri sljedećoj nadogradnji izdanja nešto se pokvari (lekcija 4.3).

Učinite ovo. Preuzmite skriptu i pročitajte je. Radije instalirajte iz repozitorija paketa svoje distribucije ili iz službenog izvora proizvođača, s vlastitim ključem (Signed-By, lekcija 4.1). Zabilježite što instalirate i zašto.

6. Bez ažuriranja ili ažuriranja "kasnije"

Problem. Propusti se popravljaju, a zatim zloupotrebljavaju, često u roku od nekoliko dana. Poslužitelj koji mjesecima ne dobiva ažuriranja ili radi na izdanju bez podrške ima popis poznatih otvora. Kontejneri se ne ažuriraju naredbom apt.

Učinite ovo. Uključite automatska sigurnosna ažuriranja (lekcija 4.2), odredite stalni termin za ponovno pokretanje, unesite datum kraja podrške svog izdanja u kalendar (lekcija 4.3) i redovito ažurirajte kontejnere (lekcija 9.4).

7. Bez sigurnosne kopije ili sa sigurnosnom kopijom koja nikad nije testirana

Problem. Snimka (snapshot) na istoj pohrani nije sigurnosna kopija (lekcija 8.1). Sigurnosna kopija koja se nalazi na samom poslužitelju nestaje zajedno s njim pri hakiranju ili ransomwareu. A sigurnosna kopija koja nikad nije vraćena samo je nada, a ne sigurnost.

Učinite ovo. Šifrirane sigurnosne kopije izvan poslužitelja (restic, lekcija 8.2), nadzor koji potvrđuje da se izvode i barem jednom u tromjesečju test vraćanja.

8. Administratorske ploče otvorene svima, bez dvofaktorske provjere

Problem. Administratorska ploča baze podataka (poput phpMyAdmina), Dockera (poput Portainera), Vaše aplikacije ili Vašeg trezora lozinki privlačna je meta: jedna lozinka daje pristup svemu. Zadane lozinke poput admin/admin i registracija koja ostane otvorena (Vaultwarden, lekcija 9.4) to dodatno olakšavaju.

Učinite ovo. Ne otvarajte administratorske ploče prema internetu: pristupajte im preko SSH tunela ili samo s jedne stalne adrese. Ako ploča ipak mora biti javna: https, jaka jedinstvena lozinka iz upravitelja lozinki, dvofaktorska provjera i zatvorena registracija. Zadane lozinke uvijek promijenite.

9. Tajne u Gitu ili u compose datoteci

Problem. Lozinka, API ključ ili privatni ključ u datoteci koja završi u Git repozitoriju zauvijek ostaje u povijesti, čak i ako ga kasnije uklonite. Botovi pretražuju javne repozitorije upravo u potrazi za takvim ključevima.

Učinite ovo. Tajne držite u zasebnoj datoteci s pravima 600 (EnvironmentFile, lekcija 6.3; .env kod Docker Composea, lekcija 9.3) koja je navedena u .gitignore. Ako je tajna ipak procurjela, odmah je zamijenite (nova lozinka, novi ključ); samo čišćenje u Gitu nije dovoljno.

10. "Nakratko" isključen vatrozid, sve kao root i bez bilješki

Problem. "Samo ću nakratko isključiti vatrozid da testiram" zaboravi se. "Samo ću ovo napraviti kao root" postane navika. A poslužiteljem za koji nitko ne zna što na njemu radi i zašto nije moguće upravljati niti ga obnoviti.

Učinite ovo. Testirajte s privremenim, uskim pravilom (jedan priključak, jedna izvorna adresa) i zatim ga uklonite. Radite kao običan korisnik sa sudo ovlastima. Vodite kratku dokumentaciju poslužitelja: što na njemu radi, koji su priključci otvoreni, gdje su sigurnosne kopije, kada završava podrška za izdanje (lekcija 10.4).

U praksi

Sve ove pogreške moguće je napraviti na svakom VPS-u, kod WebOkéa jednako kao i kod drugih pružatelja usluga: ono što se događa unutar Vašeg poslužitelja sami upravljate. Pružatelj usluge može poslužitelj isključiti iz mreže ako šalje spam ili izvodi napade, jer to pogađa druge korisnike. Sprječavanje je stoga važno i za Vašu vlastitu dostupnost.

Sažetak

• Većina hakiranja koristi poznate pogreške, a ne nepoznate propuste.
• Prijava ključevima, prijava lozinkom isključena; baze podataka, predmemorije i Docker API nikad otvoreni prema internetu; bez docker.sock u kontejnerima kojima ne vjerujete u potpunosti.
• Bez chmod 777 i bez curl | bash: znajte tko smije što i što instalirate.
• Automatska ažuriranja, sigurnosne kopije izvan poslužitelja i testirane, administratorske ploče iza tunela ili s dvofaktorskom provjerom.
• Tajne izvan Gita i izvan compose datoteka; ono što je procurjelo, treba zamijeniti.

Kviz

Zadatak

Zadatak Z10.2: Koja je to pogreška? U primjeru datoteke casussen-z10-2.md nalazi se osam kratkih slučajeva poslužitelja s nekim problemom. Za svaki slučaj odaberite o kojoj se pogrešci s popisa iz ove lekcije radi (od A do J) i koji je najbolji prvi korak. Program uspoređuje Vaše odgovore s fiksnim ključem i zatim za svaki slučaj prikazuje objašnjenje.

Dodatno štivo

• Zaštita Vašeg VPS-a: prvih pet minuta
• Upravitelj lozinki i passkeyji: ovako sigurno uredite svoju prijavu
• Docker dokumentacija, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
• Docker dokumentacija, Protect the Docker daemon socket: https://docs.docker.com/engine/security/protect-access/
• Redis, Security: https://redis.io/docs/latest/operate/oss_and_stack/management/security/