Ko nedaryti

10 modulis: Išlikti saugiems · Skaitymo laikas: 12 min.

Mokymosi tikslas: Po šios pamokos atpažinsite klaidas, kurios dažniausiai baigiasi įsilaužimu į serverį arba jo gedimu, galėsite paaiškinti, kodėl jos pavojingos, ir žinosite, ką daryti vietoj jų.

Pagrindinės sąvokos: root prisijungimas slaptažodžiu, silpnas arba numatytasis slaptažodis, atvira duomenų bazė, Docker API per 2375 prievadą, docker.sock konteineryje, chmod 777, curl | bash, paslaptys Git saugykloje, administravimo skydelis be dviejų veiksnių autentifikavimo, užkarda „trumpam išjungta“, jokių atnaujinimų, jokios atsarginės kopijos

Kodėl pamoka apie klaidas?

Į daugumą serverių įsilaužia ne genialus užpuolikas, radęs nežinomą spragą. Į juos įsilaužia robotai, kurie naršo visą internetą ieškodami žinomų klaidų: atspėjamo slaptažodžio, atviros duomenų bazės, programos, kuriai jau kelis mėnesius trūksta atnaujinimo. Kas išvengia šioje pamokoje aprašytų klaidų, tas robotams tampa neįdomus. Tai didžioji dalis apsaugos, kurią apskritai galite gauti.

Prie kiekvienos klaidos nurodyta, kodėl ji pavojinga ir ką daryti vietoj jos. Beveik visa tai išmokote ankstesnėse pamokose; ši pamoka viską surikiuoja į vieną sąrašą.

1. Root prisijungimas slaptažodžiu

Problema. Kiekvienas serveris visą dieną gauna bandymų prisijungti per root (pamoka 5.3). Jei root gali prisijungti slaptažodžiu, tas slaptažodis yra vienintelis dalykas, skiriantis robotą nuo visiškos kontrolės. Pakartotinai naudojami ar per trumpi slaptažodžiai anksčiau ar vėliau atspėjami arba jau yra nutekintų slaptažodžių sąraše.

Darykite taip. Prisijunkite tik raktais: PasswordAuthentication no ir KbdInteractiveAuthentication no, root daugiausia su raktu (PermitRootLogin prohibit-password) arba visai ne (no), o kasdien dirbkite kaip įprastas naudotojas su sudo (pamokos 2.2 ir 3.2). Iš išorės patikrinkite, kokius prisijungimo būdus siūlo Jūsų serveris (užduotis Z2.2).

2. Duomenų bazė, podėlis ar paieškos klasteris atviri internetui

Problema. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch arba OpenSearch (9200) ir MongoDB (27017) sukurti patikimoms programoms patikimame tinkle. Jei jie klausosi adresu 0.0.0.0 be užkardos, skeneriai juos greitai suranda. Redis savo dokumentacijoje nurodo, kad jo nereikėtų atverti internetui ir kad prieigą turintis asmuo gali ištrinti visą duomenų rinkinį; komanda CONFIG užpuolikas netgi gali įrašyti failus į serverį. Atviros duomenų bazės ir paieškos klasteriai jau daug metų yra žinoma didelių duomenų nutekėjimų priežastis, o vietoj Jūsų duomenų neretai lieka tik „išpirkos“ pranešimas.

Darykite taip. Leiskite tokioms paslaugoms klausytis adresu 127.0.0.1 (pamoka 5.1), laikykite jas už užkardos (pamoka 5.2), o Docker jų neskelbkite arba skelbkite tik adresu 127.0.0.1 (pamoka 9.3). Jei patys norite prie jų prisijungti iš nešiojamojo kompiuterio, naudokite SSH tunelį (pamoka 2.3). Patikrinkite iš išorės (užduotis Z5.1).

3. Atvira Docker API arba docker.sock konteineryje

Problema. Kas gali valdyti Docker daemon, tas iš esmės yra root serveryje: Docker dokumentacijoje nurodyta, kad daemon valdyti turėtų tik patikimi naudotojai, o prieiga prie daemon prilyginama root prieigai. Yra du šios klaidos variantai:

• Daemon klausosi TCP prievado be TLS (dažniausiai 2375). Kiekvienas, pasiekiantis tą prievadą, gali paleisti konteinerius, į kuriuos prijungtas Jūsų serverio diskas.
• Konteineriui kaip tomas perduodamas /var/run/docker.sock („tada jis pats galės valdyti konteinerius“). Jei į tą konteinerį įsilaužiama, prarandamas visas serveris.

Grupė docker taip pat prilygsta root (pamoka 9.2): įtraukite į ją tik administratorius.

Darykite taip. Leiskite Docker veikti tik per vietinį lizdą (socket). Nuotolinis valdymas vyksta per SSH (docker context su ssh://), o jei tikrai reikia TCP, tada su TLS per 2376 prievadą ir kliento sertifikatais. docker.sock prijunkite tik prie konteinerio, kuriuo visiškai pasitikite ir kurio tikrai reikia, geriausia tik skaitymo režimu per ribojantį tarpinį serverį (proxy).

4. chmod 777 klaidos pranešimui pašalinti

Problema. Įkeliant failą rodoma „Permission denied“ (prieiga uždrausta), o forume patariama: chmod -R 777 /var/www. Po to kiekvienas serverio naudotojas ir procesas gali rašyti bet ką į Jūsų svetainę, įskaitant įsilaužtą papildinį ar kitą paskyrą. Kodą, į kurį žiniatinklio serveris gali rašyti, per spragą galima pakeisti užpakalinėmis durimis (backdoor).

Darykite taip. Išsiaiškinkite, kas turi rašyti ir kur (pamoka 3.1): dažniausiai tik žiniatinklio serverio naudotojas viename įkėlimų ar podėlio aplanke. Kodo savininkas turi būti ne žiniatinklio serveris, teisės 644/755, įkėlimams 750/640 ar panašiai.

5. curl ... | bash ir programinė įranga iš bet kur

Problema. Skriptas, kurį nepažiūrėję paleidžiate kaip root, gali padaryti viską: pridėti šaltinių ir raktų, perrašyti failus, atverti paslaugą. Net jei ketinimai geri, vėliau nežinote, kas pasikeitė, o per kitą leidimo atnaujinimą viskas sugenda (pamoka 4.3).

Darykite taip. Atsisiųskite ir perskaitykite skriptą. Geriau diekite iš savo distribucijos paketų šaltinio arba oficialaus kūrėjo šaltinio su atskiru raktu (Signed-By, pamoka 4.1). Užsirašykite, ką diegiate ir kodėl.

6. Jokių atnaujinimų arba atnaujinimai „vėliau“

Problema. Spragos ištaisomos, o po to išnaudojamos, dažnai per kelias dienas. Serveris, kelis mėnesius negaunantis atnaujinimų arba veikiantis su nebepalaikomu leidimu, turi žinomų spragų sąrašą. apt konteinerių neatnaujina.

Darykite taip. Įjunkite automatinius saugumo atnaujinimus (pamoka 4.2), nustatykite pastovų laiką paleidimui iš naujo, įsirašykite savo leidimo palaikymo pabaigos datą į kalendorių (pamoka 4.3) ir reguliariai atnaujinkite konteinerius (pamoka 9.4).

7. Jokios atsarginės kopijos arba niekada neišbandyta atsarginė kopija

Problema. Momentinė kopija (snapshot) toje pačioje saugykloje nėra atsarginė kopija (pamoka 8.1). Atsarginė kopija, laikoma pačiame serveryje, dingsta kartu su juo po įsilaužimo ar išpirkos reikalaujančios programos (ransomware) atakos. O niekada neatkurta atsarginė kopija yra tik viltis, ne garantija.

Darykite taip. Šifruotos atsarginės kopijos už serverio ribų (restic, pamoka 8.2), stebėsena, kad jos tikrai daromos, ir bent kartą per ketvirtį atkūrimo bandymas.

8. Administravimo skydeliai atviri visiems, be dviejų veiksnių autentifikavimo

Problema. Duomenų bazės (pvz., phpMyAdmin), Docker (pvz., Portainer), Jūsų programos ar slaptažodžių saugyklos administravimo skydelis yra patrauklus taikinys: vienas slaptažodis suteikia prieigą prie visko. Numatytieji slaptažodžiai, tokie kaip admin/admin, ir atvira registracija (Vaultwarden, pamoka 9.4) padaro tai dar lengvesniu.

Darykite taip. Neatverkite administravimo skydelių internetui: pasiekite juos per SSH tunelį arba tik iš pastovaus adreso. Jei skydelis vis dėlto turi būti viešas: https, stiprus unikalus slaptažodis iš slaptažodžių tvarkyklės, dviejų veiksnių autentifikavimas ir uždaryta registracija. Visada pakeiskite numatytuosius slaptažodžius.

9. Paslaptys Git saugykloje arba compose faile

Problema. Slaptažodis, API raktas ar privatusis raktas faile, kuris patenka į Git saugyklą, ten lieka istorijoje visam laikui, net jei vėliau jį pašalinate. Robotai viešose saugyklose ieško būtent tokių raktų.

Darykite taip. Paslaptis laikykite atskirame faile su teisėmis 600 (EnvironmentFile, pamoka 6.3; .env su Docker Compose, pamoka 9.3), kuris įrašytas į .gitignore. Jei paslaptis vis dėlto nutekėjo, nedelsdami ją pakeiskite (naujas slaptažodis, naujas raktas): vien išvalyti Git nepakanka.

10. „Trumpam“ išjungta užkarda, viskas kaip root ir jokių užrašų

Problema. „Trumpam išjungsiu užkardą, kad išbandyčiau“ pamirštama. „Greitai padarysiu kaip root“ tampa įpročiu. O serverio, apie kurį niekas nežino, kas jame veikia ir kodėl, neįmanoma nei administruoti, nei atkurti.

Darykite taip. Bandykite su laikina, siaura taisykle (vienas prievadas, vienas šaltinio adresas) ir po to ją pašalinkite. Dirbkite kaip įprastas naudotojas su sudo. Veskite trumpą serverio aprašą: kas veikia, kokie prievadai atviri, kur laikomos atsarginės kopijos, kada baigiasi leidimo palaikymas (pamoka 10.4).

Praktikoje

Visas šias klaidas galima padaryti bet kuriame VPS, tiek WebOké, tiek pas kitus teikėjus: tai, kas vyksta Jūsų serveryje, administruojate patys. Teikėjas gali atjungti serverį nuo tinklo, jei jis siunčia šlamštą arba vykdo atakas, nes tai paliečia kitus klientus. Todėl prevencija svarbi ir Jūsų pačių pasiekiamumui.

Santrauka

• Dauguma įsilaužimų išnaudoja žinomas klaidas, o ne nežinomas spragas.
• Prisijungimas raktais, prisijungimas slaptažodžiu išjungtas; duomenų bazės, podėliai ir Docker API niekada neatviri internetui; jokio docker.sock konteineriuose, kuriais visiškai nepasitikite.
• Jokio chmod 777 ir jokio curl | bash: žinokite, kas ką gali daryti ir ką diegiate.
• Automatiniai atnaujinimai, atsarginės kopijos už serverio ribų ir išbandytos, administravimo skydeliai už tunelio arba su dviejų veiksnių autentifikavimu.
• Paslaptys už Git ir compose failų ribų; nutekėjusią paslaptį reikia pakeisti.

Testas (quiz)

Užduotis

Užduotis Z10.2: Kokia tai klaida? Pavyzdiniame faile casussen-z10-2.md yra aštuoni trumpi atvejai apie serverius, su kuriais kažkas negerai. Kiekvienam atvejui pasirinkite, kokia tai klaida iš šios pamokos sąrašo (nuo A iki J), ir koks yra geriausias pirmasis žingsnis. Programa palygina atsakymus su nustatytu raktu ir po to kiekvienam atvejui parodo paaiškinimą.

Skaitykite daugiau

• Jūsų VPS apsauga: pirmosios penkios minutės
• Slaptažodžių tvarkyklė ir prieigos raktai: taip saugiai sutvarkysite savo prisijungimą
• 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/