Ko nevajadzētu darīt

10. modulis: Drošība ilgtermiņā · Lasīšanas laiks: 12 min.

Mācīšanās mērķis: Pēc šīs nodarbības Jūs atpazīsiet kļūdas, kuru dēļ serveri visbiežāk tiek uzlauzti vai sabojāti, varēsiet izskaidrot, kāpēc tās ir bīstamas, un zināsiet, ko darīt to vietā.

Pamatjēdzieni: root pieteikšanās ar paroli, vāja vai noklusējuma parole, atvērta datubāze, Docker API uz porta 2375, docker.sock konteinerā, chmod 777, curl | bash, noslēpumi Git, pārvaldības panelis bez divpakāpju verifikācijas, ugunsmūris "uz brīdi izslēgts", nav atjauninājumu, nav rezerves kopijas

Kāpēc nodarbība par kļūdām?

Lielāko daļu serveru neuzlauž ģeniāls uzbrucējs, kas izmanto nezināmu ievainojamību. Tos uzlauž boti, kas pārmeklē visu internetu, meklējot zināmas kļūdas: paroli, ko var uzminēt, atvērtu datubāzi, programmu, kurai jau mēnešiem trūkst atjauninājuma. Ja izvairāties no šajā nodarbībā aprakstītajām kļūdām, šie boti Jūsu serveri vairs neinteresē. Tā ir lielākā daļa aizsardzības, ko vispār iespējams iegūt.

Pie katras kļūdas ir paskaidrots, kāpēc tā ir bīstama un ko darīt tās vietā. Gandrīz visu Jūs jau esat apguvuši iepriekšējās nodarbībās; šī nodarbība to apkopo.

1. Root pieteikšanās ar paroli

Problēma. Katrs serveris visu dienu saņem pieteikšanās mēģinājumus uz root (nodarbība 5.3). Ja root var pieteikties ar paroli, tad šī parole ir vienīgais, kas stāv starp botu un pilnu kontroli. Atkārtoti izmantotas vai pārāk īsas paroles agrāk vai vēlāk tiek uzminētas vai jau atrodas nopludinātā sarakstā.

Dariet tā. Piesakieties tikai ar atslēgām: PasswordAuthentication no un KbdInteractiveAuthentication no, root labākajā gadījumā tikai ar atslēgu (PermitRootLogin prohibit-password) vai nemaz (no), ikdienā strādājiet kā parasts lietotājs ar sudo (nodarbība 2.2 un 3.2). No ārpuses pārbaudiet, kādas pieteikšanās metodes piedāvā Jūsu serveris (uzdevums Z2.2).

2. Datubāze, kešatmiņa vai meklēšanas klasteris, kas atvērts internetam

Problēma. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch vai OpenSearch (9200) un MongoDB (27017) ir paredzēti uzticamām programmām uzticamā tīklā. Ja tie klausās uz 0.0.0.0 bez ugunsmūra, skeneri tos ātri atrod. Redis savā dokumentācijā norāda, ka to nedrīkst pakļaut internetam un ka ikviens ar piekļuvi var izdzēst visu datu kopu; ar komandu CONFIG uzbrucējs var pat ierakstīt failus serverī. Atvērtas datubāzes un meklēšanas klasteri jau gadiem ir zināms lielu datu noplūžu iemesls, kā arī iemesls tam, ka Jūsu datu vietā parādās "izpirkuma maksas" ziņojumi.

Dariet tā. Ļaujiet šādiem pakalpojumiem klausīties uz 127.0.0.1 (nodarbība 5.1), turiet tos aiz ugunsmūra (nodarbība 5.2) un Docker vidē nepublicējiet tos vai publicējiet tikai uz 127.0.0.1 (nodarbība 9.3). Lai pašiem piekļūtu no sava klēpjdatora, izmantojiet SSH tuneli (nodarbība 2.3). Pārbaudiet no ārpuses (uzdevums Z5.1).

3. Atvērts Docker API vai docker.sock konteinerā

Problēma. Tas, kurš var vadīt Docker dēmonu, faktiski ir root serverī: Docker dokumentācijā teikts, ka dēmonu drīkst vadīt tikai uzticami lietotāji, un piekļuve dēmonam tiek pielīdzināta root piekļuvei. Šai kļūdai ir divi varianti:

• Dēmons klausās uz TCP porta bez TLS (parasti tas ir 2375). Ikviens, kas sasniedz šo portu, var palaist konteinerus, kuros pievienots Jūsu servera disks.
• Konteineram tiek pievienots /var/run/docker.sock kā sējums ("tad tas pats varēs pārvaldīt konteinerus"). Ja šis konteiners tiek uzlauzts, viss serveris ir zaudēts.

Arī grupa docker ir pielīdzināma root (nodarbība 9.2): iekļaujiet tajā tikai administratorus.

Dariet tā. Ļaujiet Docker darboties tikai caur lokālo ligzdu. Attālā pārvaldība notiek caur SSH (docker context ar ssh://) vai, ja tiešām nepieciešams TCP, ar TLS uz porta 2376 un klientu sertifikātiem. Montējiet docker.sock tikai konteinerā, kuram pilnībā uzticaties un kas tiešām ir nepieciešams, turklāt vēlams tikai lasīšanas režīmā caur ierobežojošu starpniekserveri.

4. chmod 777, lai atbrīvotos no kļūdas paziņojuma

Problēma. Augšupielādējot parādās "Permission denied", un kāds forums iesaka: chmod -R 777 /var/www. Pēc tam ikviens lietotājs un ikviens process serverī drīkst rakstīt visu Jūsu vietnē, arī uzlauzts spraudnis vai cits konts. Kodu, kurā var rakstīt tīmekļa serveris, ievainojamības gadījumā var aizstāt ar sētas durvīm (backdoor).

Dariet tā. Noskaidrojiet, kam jāraksta un kur (nodarbība 3.1): parasti tikai tīmekļa servera lietotājam vienā mapē augšupielādēm vai kešatmiņai. Kodam jāpieder citam īpašniekam, nevis tīmekļa serverim, ar tiesībām 644/755, augšupielādēm 750/640 vai līdzīgi.

5. curl ... | bash un programmatūra no visurienes

Problēma. Skripts, ko neapskatot izpildāt kā root, var darīt jebko: pievienot avotus un atslēgas, pārrakstīt failus, atvērt pakalpojumu. Pat ja nodoms ir labs, pēc tam Jūs nezināt, kas ir mainīts, un nākamajā laidiena jaunināšanā kaut kas salūzt (nodarbība 4.3).

Dariet tā. Lejupielādējiet un izlasiet skriptu. Labāk instalējiet no savas distribūcijas pakotņu avota vai no izstrādātāja oficiālā avota ar atsevišķu atslēgu (Signed-By, nodarbība 4.1). Pierakstiet, ko instalējat un kāpēc.

6. Nav atjauninājumu vai atjauninājumi "vēlāk"

Problēma. Ievainojamības tiek izlabotas un pēc tam izmantotas, bieži vien dažu dienu laikā. Serverim, kas mēnešiem nesaņem atjauninājumus vai darbojas ar laidienu, kas vairs netiek atbalstīts, ir vesels saraksts ar zināmām spraugām. Konteinerus apt neatjaunina.

Dariet tā. Ieslēdziet automātiskos drošības atjauninājumus (nodarbība 4.2), nosakiet fiksētu laiku restartēšanai, ierakstiet sava laidiena atbalsta beigu datumu kalendārā (nodarbība 4.3) un regulāri atjauniniet konteinerus (nodarbība 9.4).

7. Nav rezerves kopijas vai rezerves kopija nekad nav pārbaudīta

Problēma. Momentuzņēmums tajā pašā krātuvē nav rezerves kopija (nodarbība 8.1). Rezerves kopija, kas glabājas pašā serverī, pazūd kopā ar to uzlaušanas vai izspiedējvīrusa gadījumā. Un rezerves kopija, kas nekad nav atjaunota, ir cerība, nevis drošība.

Dariet tā. Glabājiet šifrētas rezerves kopijas ārpus servera (restic, nodarbība 8.2), uzraugiet, vai tās tiek veidotas, un vismaz reizi ceturksnī veiciet atjaunošanas testu.

8. Pārvaldības paneļi, kas atvērti visiem, bez divpakāpju verifikācijas

Problēma. Datubāzes pārvaldības panelis (piemēram, phpMyAdmin), Docker panelis (piemēram, Portainer), Jūsu lietotnes vai paroļu glabātuves panelis ir pievilcīgs mērķis: viena parole dod piekļuvi visam. Noklusējuma paroles, piemēram, admin/admin, un reģistrācija, kas paliek atvērta (Vaultwarden, nodarbība 9.4), to padara vēl vieglāku.

Dariet tā. Neatveriet pārvaldības paneļus internetam: piekļūstiet tiem caur SSH tuneli vai tikai no fiksētas adreses. Ja panelim tomēr jābūt publiski pieejamam: https, stipra unikāla parole no Jūsu paroļu pārvaldnieka, divpakāpju verifikācija un slēgta reģistrācija. Vienmēr nomainiet noklusējuma paroles.

9. Noslēpumi Git vai Jūsu compose failā

Problēma. Parole, API atslēga vai privātā atslēga failā, kas nonāk Git repozitorijā, tur paliek vēsturē uz visiem laikiem, pat ja vēlāk to izņemat. Publiskos repozitorijus boti pārmeklē tieši šādu atslēgu meklējumos.

Dariet tā. Glabājiet noslēpumus atsevišķā failā ar tiesībām 600 (EnvironmentFile, nodarbība 6.3; .env Docker Compose gadījumā, nodarbība 9.3), kas ir norādīts .gitignore. Ja noslēpums tomēr ir noplūdis, nekavējoties to nomainiet (jauna parole, jauna atslēga); ar tīrīšanu Git vien nepietiek.

10. "Uz brīdi" izslēgts ugunsmūris, viss kā root un nekādu piezīmju

Problēma. "Es uz brīdi izslēgšu ugunsmūri, lai notestētu" tiek aizmirsts. "Es to ātri izdarīšu kā root" kļūst par ieradumu. Un serveri, par kuru neviens nezina, kas tajā darbojas un kāpēc, nav iespējams ne pārvaldīt, ne atjaunot.

Dariet tā. Testējiet ar pagaidu, šauru noteikumu (viens ports, viena avota adrese) un pēc tam to noņemiet. Strādājiet kā parasts lietotājs ar sudo. Uzturiet īsu servera dokumentāciju: kas darbojas, kuri porti ir atvērti, kur glabājas rezerves kopijas, kad beidzas laidiena atbalsts (nodarbība 10.4).

Praksē

Visas šīs kļūdas var pieļaut jebkurā VPS, gan WebOké, gan pie citiem pakalpojumu sniedzējiem: to, kas notiek Jūsu serverī, pārvaldāt Jūs paši. Pakalpojumu sniedzējs gan var atvienot serveri no tīkla, ja tas sūta surogātpastu vai veic uzbrukumus, jo tas ietekmē citus klientus. Tāpēc novēršana ir svarīga arī Jūsu pašu pieejamībai.

Kopsavilkums

• Lielākā daļa uzlaušanu izmanto zināmas kļūdas, nevis nezināmas ievainojamības.
• Pieteikšanās ar atslēgām, pieteikšanās ar paroli izslēgta; datubāzes, kešatmiņas un Docker API nekad nav atvērti internetam; nekāda docker.sock konteineros, kuriem pilnībā neuzticaties.
• Nekāda chmod 777 un nekāda curl | bash: ziniet, kam ko drīkst darīt un ko Jūs instalējat.
• Atjauninājumi automātiski, rezerves kopijas ārpus servera un pārbaudītas, pārvaldības paneļi aiz tuneļa vai ar divpakāpju verifikāciju.
• Noslēpumi ārpus Git un ārpus compose failiem; noplūdis nozīmē nomainīts.

Tests

Uzdevums

Uzdevums Z10.2: Kura kļūda tā ir? Piemēra failā casussen-z10-2.md ir astoņi īsi gadījumi ar serveriem, kuros kaut kas nav kārtībā. Katram gadījumam izvēlieties, kura kļūda tā ir no šīs nodarbības saraksta (no A līdz J), un kāds ir labākais pirmais solis. Programma salīdzina Jūsu atbildes ar fiksētu atslēgu un pēc tam katram gadījumam parāda skaidrojumu.

Vairāk lasīt

• Jūsu VPS aizsardzība: pirmās piecas minūtes
• Paroļu pārvaldnieks un piekļuves atslēgas: kā droši pārvaldīt savu pieteikšanos
• Docker dokumentācija, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
• Docker dokumentācija, 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/