Česa ne smete početi

Modul 10: Ostanite varni · Čas branja: 12 minut

Učni cilj: Po tej lekciji boste prepoznali napake, ki najpogosteje vodijo do vdrtega ali okvarjenega strežnika, znali boste pojasniti, zakaj so nevarne, in vedeli boste, kaj storiti namesto tega.

Ključni pojmi: prijava root z geslom, šibko ali privzeto geslo, odprta podatkovna baza, Docker API na vratih 2375, docker.sock v vsebniku, chmod 777, curl | bash, skrivnosti v Gitu, skrbniška plošča brez dvostopenjskega preverjanja, požarni zid »samo za hip« izklopljen, brez posodobitev, brez varnostne kopije

Zakaj lekcija o napakah?

Večine strežnikov ne vdre genialen napadalec z neznano ranljivostjo. Vdrejo jih roboti, ki pregledujejo ves internet in iščejo znane napake: geslo, ki ga je mogoče uganiti, odprto podatkovno bazo, program, ki mu že mesece manjka posodobitev. Kdor se izogne napakam iz te lekcije, za te robote ni več zanimiv. To je največji del zaščite, ki jo lahko dosežete.

Pri vsaki napaki je opisano, zakaj je nevarna in kaj storiti namesto tega. Skoraj vse ste se naučili že v prejšnjih lekcijah; ta lekcija vse zbere na enem mestu.

1. Prijava root z geslom

Težava. Vsak strežnik ves dan prejema poskuse prijave na root (lekcija 5.3). Če se root lahko prijavi z geslom, je to geslo edino, kar stoji med robotom in popolnim nadzorom. Ponovno uporabljena ali prekratka gesla prej ali slej nekdo ugane ali pa so že na kakem seznamu ukradenih gesel.

Storite tole. Prijava samo s ključi: PasswordAuthentication no in KbdInteractiveAuthentication no, root kvečjemu s ključem (PermitRootLogin prohibit-password) ali sploh ne (no), za vsakdanje delo pa navaden uporabnik s sudo (lekciji 2.2 in 3.2). Od zunaj preverite, katere načine prijave ponuja Vaš strežnik (naloga Z2.2).

2. Podatkovna baza, predpomnilnik ali iskalna gruča, odprta proti internetu

Težava. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch ali OpenSearch (9200) in MongoDB (27017) so namenjeni zaupanja vrednim programom v zaupanja vrednem omrežju. Če poslušajo na 0.0.0.0 brez požarnega zidu, jih skenerji hitro najdejo. Redis v svoji dokumentaciji navaja, da ne sme biti izpostavljen internetu in da lahko kdor koli z dostopom izbriše celoten nabor podatkov; z ukazom CONFIG lahko napadalec celo zapisuje datoteke na strežnik. Odprte podatkovne baze in iskalne gruče so že leta znan vzrok velikih uhajanj podatkov in sporočil z zahtevo po »odkupnini« namesto Vaših podatkov.

Storite tole. Takšne storitve naj poslušajo na 127.0.0.1 (lekcija 5.1), naj bodo za požarnim zidom (lekcija 5.2), v Dockerju pa jih ne objavite ali pa le na 127.0.0.1 (lekcija 9.3). Če do njih dostopate sami s prenosnika: tunel SSH (lekcija 2.3). Preverite od zunaj (naloga Z5.1).

3. Odprt Docker API ali docker.sock v vsebniku

Težava. Kdor lahko upravlja demon Docker, je dejansko root na strežniku: dokumentacija Dockerja navaja, da smejo demon upravljati le zaupanja vredni uporabniki, in dostop do demona enači z dostopom root. Ta napaka ima dve različici:

• Demon posluša na vratih TCP brez TLS (običajno 2375). Kdor koli doseže ta vrata, lahko zažene vsebnike, v katere priklopi disk Vašega strežnika.
• Vsebnik dobi /var/run/docker.sock kot nosilec (»da lahko sam upravlja vsebnike«). Če nekdo vdre v ta vsebnik, je ves strežnik izgubljen.

Tudi skupina docker je enakovredna root (lekcija 9.2): vanjo dodajte samo skrbnike.

Storite tole. Docker naj deluje le prek lokalne vtičnice. Oddaljeno upravljanje poteka prek SSH (docker context z ssh://) ali, če res mora prek TCP, s TLS na vratih 2376 in odjemalskimi certifikati. docker.sock priklopite le v vsebnik, ki mu popolnoma zaupate in ga res potrebujete, po možnosti samo za branje prek omejevalnega posredniškega strežnika.

4. chmod 777, da izgine sporočilo o napaki

Težava. Pri nalaganju se pojavi »Permission denied« (dostop zavrnjen), forum pa svetuje: chmod -R 777 /var/www. Odslej lahko vsak uporabnik in vsak proces na strežniku zapisuje karkoli v Vaše spletno mesto, tudi vtičnik, v katerega so vdrli, ali drug račun. Kodo, v katero lahko zapisuje spletni strežnik, lahko ranljivost zamenja z zadnjimi vrati.

Storite tole. Ugotovite, kdo mora zapisovati in kam (lekcija 3.1): običajno le uporabnik spletnega strežnika v eno mapo za nalaganje ali predpomnilnik. Koda naj ima drugega lastnika kot spletni strežnik, pravice 644/755, nalaganja 750/640 ali podobno.

5. curl ... | bash in programska oprema od vsepovsod

Težava. Skript, ki ga brez pregleda zaženete kot root, lahko naredi vse: doda vire in ključe, prepiše datoteke, odpre storitev. Tudi če je namen dober, potem ne veste, kaj se je spremenilo, ob naslednji nadgradnji izdaje pa se kaj pokvari (lekcija 4.3).

Storite tole. Skript prenesite in ga preberite. Raje nameščajte iz paketnega vira Vaše distribucije ali iz uradnega vira izdelovalca, z lastnim ključem (Signed-By, lekcija 4.1). Zapišite si, kaj nameščate in zakaj.

6. Brez posodobitev ali posodobitve »pozneje«

Težava. Ranljivosti se popravijo in nato zlorabijo, pogosto v nekaj dneh. Strežnik, ki mesece ne dobi posodobitev ali teče na izdaji brez podpore, ima cel seznam znanih odprtin. Vsebnikov apt ne posodobi.

Storite tole. Vklopite samodejne varnostne posodobitve (lekcija 4.2), določite stalen termin za ponovni zagon, si v koledar zapišite datum konca podpore Vaše izdaje (lekcija 4.3) in redno posodabljajte vsebnike (lekcija 9.4).

7. Brez varnostne kopije ali s kopijo, ki ni bila nikoli preizkušena

Težava. Posnetek na isti shrambi ni varnostna kopija (lekcija 8.1). Varnostna kopija na samem strežniku izgine skupaj z njim ob vdoru ali izsiljevalski programski opremi. Varnostna kopija, ki je nikoli niste obnovili, pa je upanje, ne gotovost.

Storite tole. Šifrirane varnostne kopije zunaj strežnika (restic, lekcija 8.2), nadzor nad tem, ali se izvajajo, in vsaj vsako četrtletje preizkus obnovitve.

8. Skrbniške plošče, odprte za vse, brez dvostopenjskega preverjanja

Težava. Skrbniška plošča podatkovne baze (na primer phpMyAdmin), Dockerja (na primer Portainer), Vaše aplikacije ali Vašega trezorja gesel je privlačna tarča: eno geslo odpre dostop do vsega. Privzeta gesla, kot je admin/admin, in registracija, ki ostane odprta (Vaultwarden, lekcija 9.4), to še olajšajo.

Storite tole. Skrbniških plošč ne odpirajte proti internetu: dostopajte do njih prek tunela SSH ali le s stalnega naslova. Če mora biti plošča vseeno javna: https, močno edinstveno geslo iz Vašega upravitelja gesel, dvostopenjsko preverjanje in zaprta registracija. Privzeta gesla vedno zamenjajte.

9. Skrivnosti v Gitu ali v datoteki compose

Težava. Geslo, ključ API ali zasebni ključ v datoteki, ki pristane v repozitoriju Git, tam za vedno ostane v zgodovini, tudi če ga pozneje odstranite. Roboti javne repozitorije pregledujejo prav v iskanju takšnih ključev.

Storite tole. Skrivnosti naj bodo v ločeni datoteki s pravicami 600 (EnvironmentFile, lekcija 6.3; .env pri Docker Compose, lekcija 9.3), ki je navedena v .gitignore. Če je skrivnost vseeno ušla: takoj jo zamenjajte (novo geslo, nov ključ), samo čiščenje v Gitu ni dovolj.

10. Požarni zid »samo za hip« izklopljen, vse kot root in brez zapiskov

Težava. »Požarni zid bom samo za hip izklopil, da preizkusim« se pozabi. »Bom kar hitro kot root« postane navada. Strežnika, za katerega nihče ne ve, kaj teče na njem in zakaj, ni mogoče upravljati ali obnoviti.

Storite tole. Preizkušajte z začasnim, ozkim pravilom (ena vrata, en izvorni naslov) in ga nato odstranite. Delajte kot navaden uporabnik s sudo. Vodite kratko dokumentacijo strežnika: kaj teče na njem, katera vrata so odprta, kje so varnostne kopije, kdaj poteče podpora izdaji (lekcija 10.4).

V praksi

Vse te napake lahko naredite na vsakem VPS, pri WebOké prav tako kot pri drugih ponudnikih: kar se dogaja znotraj Vašega strežnika, upravljate sami. Ponudnik pa lahko strežnik odklopi iz omrežja, če pošilja neželeno pošto ali izvaja napade, ker to prizadene druge stranke. Preprečevanje je torej pomembno tudi za Vašo lastno dosegljivost.

Povzetek

• Večina vdorov izkorišča znane napake, ne neznanih ranljivosti.
• Prijava s ključi, prijava z geslom izklopljena; podatkovne baze, predpomnilniki in Docker API nikoli odprti proti internetu; brez docker.sock v vsebnikih, ki jim ne zaupate popolnoma.
• Brez chmod 777 in brez curl | bash: vedite, kdo sme kaj in kaj nameščate.
• Samodejne posodobitve, varnostne kopije zunaj strežnika in preizkušene, skrbniške plošče za tunelom ali z dvostopenjskim preverjanjem.
• Skrivnosti zunaj Gita in zunaj datotek compose; kar je ušlo, zamenjajte.

Kviz

Naloga

Naloga Z10.2: Za katero napako gre? V vzorčni datoteki casussen-z10-2.md je osem kratkih primerov strežnikov, pri katerih je nekaj narobe. Za vsak primer izberite, za katero napako s seznama te lekcije gre (od A do J) in kateri je najboljši prvi korak. Program odgovore primerja s fiksnim ključem in nato za vsak primer prikaže razlago.

Za nadaljnje branje

• Zaščita VPS: prvih pet minut
• Upravitelj gesel in passkeys: tako varno uredite prijavo
• Dokumentacija Docker, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
• Dokumentacija Docker, 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/