Ubuntu serveriai plačiai naudojami interneto svetainėms, API, duomenų bazėms, el. pašto sistemoms, konteineriams ir įvairioms verslo aplikacijoms. Tačiau vien įdiegti Ubuntu ir paleisti reikalingas paslaugas neužtenka – serverį būtina tinkamai apsaugoti.

Serverio saugumas nėra vienas nustatymas ar viena programa. Tai kelių sluoksnių procesas, apimantis operacinės sistemos atnaujinimus, prieigos kontrolę, SSH apsaugą, vartotojų teises, paslaugų izoliavimą ir nuolatinį stebėjimą.

Šiame straipsnyje aptarsime 7 praktiškus Ubuntu serverio saugumo stiprinimo (hardening) veiksmus, kuriuos verta atlikti beveik kiekviename viešai internete pasiekiamame serveryje.

1. Reguliariai atnaujinkite operacinę sistemą

Užduotis

Reguliariai atnaujinkite Ubuntu ir visus įdiegtus paketus.

Tai vienas paprasčiausių, bet kartu ir svarbiausių serverio saugumo veiksmų.

Kodėl tai svarbu?

Programinėje įrangoje nuolat aptinkamos saugumo spragos. Kai pažeidžiamumas ištaisomas, informacija apie jį dažnai tampa vieša, todėl neatnaujintas serveris gali tapti lengvu taikiniu.

Reguliarūs atnaujinimai:

užtaiso žinomas operacinės sistemos spragas;
atnaujina sistemines bibliotekas;
padeda apsaugoti tokias paslaugas kaip Nginx, Apache, PHP ar Node.js;
pagerina sistemos stabilumą;
padeda atitikti organizacijos ar klientų saugumo reikalavimus.

Atnaujinimus galite atlikti:

sudo apt update
sudo apt upgrade -y

Kai reikia įdiegti ir priklausomybių pakeitimus, naudinga naudoti:

sudo apt full-upgrade -y

Jeigu buvo atnaujintas branduolys (kernel), serverį gali reikėti perkrauti:

sudo reboot

Automatiniai saugumo atnaujinimai

Ubuntu taip pat galima sukonfigūruoti taip, kad saugumo atnaujinimai būtų diegiami automatiškai:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

Automatiniai atnaujinimai ypač naudingi serveriuose, kuriuos administruojate retai arba kurių negalite kasdien tikrinti rankiniu būdu.

Svarbu: prieš įjungiant automatinius atnaujinimus gamybinėje aplinkoje verta įvertinti, ar jūsų aplikacijos ir infrastruktūra toleruoja automatinius paketų pakeitimus. Kritinėse sistemose atnaujinimus dažnai geriau valdyti per testavimo ir diegimo procesą.

Esmė

Atnaujinta operacinė sistema – pirmasis sluoksnis prieš žinomas saugumo spragas.

2. Išjunkite tiesioginį root prisijungimą per SSH

Užduotis

Neleiskite vartotojui tiesiogiai prisijungti prie serverio per SSH kaip root.

Redaguokite SSH konfigūraciją:

sudo nano /etc/ssh/sshd_config

Suraskite arba pridėkite:

PermitRootLogin no

Tada perkraukite SSH tarnybą:

sudo systemctl restart ssh

Kodėl tai svarbu?

root yra privilegijuotas vartotojas, turintis praktiškai neribotas teises sistemoje.

Viešai internete pasiekiamus SSH serverius nuolat skenuoja automatizuoti botai. Jie dažnai bando prisijungti naudodami standartinius vartotojų vardus, o root yra vienas pirmųjų jų pasirinkimų.

Išjungus tiesioginį root prisijungimą:

sumažėja tiesioginių atakų prieš privilegijuotą paskyrą rizika;
sudėtingiau atlikti automatizuotą slaptažodžių spėliojimą;
administratoriai turi naudoti individualias paskyras;
lengviau nustatyti, kuris vartotojas atliko konkretų veiksmą;
sumažėja klaidingų administravimo veiksmų rizika.

Svarbu

Prieš išjungdami root SSH prisijungimą įsitikinkite, kad turite kitą administratoriaus paskyrą su sudo teisėmis.

Pavyzdžiui:

sudo adduser admin
sudo usermod -aG sudo admin

Niekada neišjunkite vienintelio administravimo būdo, prieš tai nepatikrinę, kad alternatyvus prisijungimas veikia.

Esmė

Administruokite serverį naudodami individualias paskyras, o ne tiesioginį root prisijungimą.

3. SSH naudokite tik su raktais

Užduotis

SSH autentifikacijai naudokite viešojo ir privataus rakto porą ir, kai įsitikinate, kad ji veikia, išjunkite prisijungimą slaptažodžiu.

Modernus pasirinkimas yra Ed25519 raktas:

ssh-keygen -t ed25519 -C "your-email"

Nukopijuokite viešąjį raktą į serverį:

ssh-copy-id user@server-ip

Patikrinkite prisijungimą:

ssh user@server-ip

Jeigu prisijungimas naudojant raktą veikia, galima išjungti slaptažodinę autentifikaciją.

Redaguokite:

sudo nano /etc/ssh/sshd_config

Nustatykite:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Tada:

sudo systemctl restart ssh

Kodėl tai svarbu?

Slaptažodžiai gali būti:

atspėti;
pavogti per phishingą;
nutekinti;
pakartotinai panaudoti iš kitų sistemų;
puolami automatizuotu brute-force būdu.

SSH raktai leidžia naudoti kriptografinę autentifikaciją ir pašalina slaptažodžių spėliojimo galimybę.

Be to, kiekvienas administratorius gali turėti savo raktą. Jei darbuotojas palieka organizaciją, jo raktą galima pašalinti nekeičiant kitų vartotojų prieigos.

Papildoma rekomendacija

Privatus SSH raktas turi būti saugomas kaip slapta informacija. Jo negalima siųsti el. paštu, kelti į viešas saugyklas ar dalintis su kitais administratoriais.

Dar geriau – naudoti SSH rakto apsaugą slaptafrazėmis ir, kur įmanoma, aparatinį saugumo raktą.

Esmė

SSH raktai sumažina slaptažodžių atakų riziką ir leidžia individualiai valdyti administratorių prieigą.

4. Pakeiskite numatytąjį SSH prievadą

Užduotis

SSH pagal nutylėjimą dažniausiai naudoja TCP prievadą 22.

Galima pasirinkti kitą prievadą, pavyzdžiui:

Port 2222

Redaguokite:

sudo nano /etc/ssh/sshd_config

Tada atverkite naują prievadą ugniasienėje:

sudo ufw allow 2222/tcp

Perkraukite SSH:

sudo systemctl restart ssh

Po to prisijunkite naudodami:

ssh -p 2222 user@server-ip

Kai įsitikinate, kad naujas prievadas veikia, galite pašalinti seną taisyklę:

sudo ufw delete allow 22/tcp

Ar tai iš tikrųjų padidina saugumą?

Čia svarbu suprasti vieną dalyką: SSH prievado pakeitimas nėra stipri saugumo priemonė.

Tai vadinama „security through obscurity“ – saugumas iš dalies grindžiamas paslaugos paslėpimu nestandartiniame prievade.

Pakeitus prievadą:

sumažėja automatinių skenavimų kiekis;
sumažėja brute-force bandymų skaičius;
serverio žurnaluose gali būti mažiau triukšmo.

Tačiau profesionalus užpuolikas gali nuskenuoti ir kitus prievadus.

Todėl:

SSH prievado pakeitimas neturi būti laikomas alternatyva SSH raktams, ugniasienei ar kitoms saugumo priemonėms.

Svarbi pastaba

Prieš perkraunant SSH tarnybą gamybinėje sistemoje patikrinkite konfigūraciją:

sudo sshd -t

Jeigu komanda nieko negrąžina, sintaksės klaidų paprastai nėra.

Taip pat rekomenduojama turėti aktyvią SSH sesiją, kol patikrinsite naują prisijungimą. Taip sumažinsite riziką netyčia užsirakinti už serverio durų.

Esmė

Nestandartinis SSH prievadas sumažina automatinių atakų triukšmą, tačiau pats savaime serverio neapsaugo.

5. Įdiekite ir sukonfigūruokite Fail2Ban

Užduotis

Fail2Ban stebi žurnalus ir, aptikęs pasikartojančius nesėkmingus prisijungimus, gali laikinai užblokuoti atitinkamą IP adresą.

Įdiegimas:

sudo apt install fail2ban -y

Rekomenduojama nekeisti pagrindinio jail.conf failo. Vietoje jo naudokite vietinę konfigūraciją:

sudo nano /etc/fail2ban/jail.local

Pavyzdinė SSH konfigūracija:

[sshd]
enabled = true
port = 22
maxretry = 5
bantime = 3600

Jeigu SSH perkėlėte į kitą prievadą, nurodykite jį:

port = 2222

Tada:

sudo systemctl restart fail2ban

Patikrinkite būseną:

sudo fail2ban-client status sshd

Kodėl tai naudinga?

Fail2Ban gali:

automatiškai blokuoti pasikartojančius nesėkmingus prisijungimus;
sumažinti brute-force atakų poveikį;
sumažinti nereikalingų įrašų kiekį žurnaluose;
sumažinti apkrovą, kurią sukelia nuolatiniai nesėkmingi prisijungimo bandymai.

Tačiau Fail2Ban nėra stebuklingas sprendimas

Fail2Ban neturėtų būti laikomas pagrindine SSH apsauga.

Jeigu naudojate:

SSH raktus;
išjungtą slaptažodinę autentifikaciją;
išjungtą root prisijungimą;
tinkamai sukonfigūruotą ugniasienę;

tuomet Fail2Ban tampa papildomu apsaugos sluoksniu.

Taip pat verta atsargiai konfigūruoti IP išimtis, kad neužblokuotumėte administratoriaus ar kito teisėto vartotojo.

Esmė

Fail2Ban automatiškai reaguoja į pasikartojančius nesėkmingus prisijungimus ir suteikia papildomą apsaugos sluoksnį.

6. Ribokite `sudo` vartotojų skaičių

Užduotis

Administratoriaus teises suteikite tik tiems vartotojams, kuriems jų iš tikrųjų reikia.

Sukurkite įprastą vartotoją:

sudo adduser username

Jeigu vartotojui būtinos administratoriaus teisės:

sudo usermod -aG sudo username

Patikrinti vartotojo teises galima:

sudo -l

Kodėl tai svarbu?

Jeigu paprasta vartotojo paskyra yra pažeidžiama, užpuolikas nebūtinai turėtų iš karto gauti visišką serverio kontrolę.

Kuo daugiau vartotojų turi sudo teises, tuo didesnė:

netyčinių pakeitimų rizika;
netinkamo administravimo rizika;
kompromituotos paskyros žalos apimtis;
privilegijų eskalavimo pasekmių rizika.

Tai atitinka vieną svarbiausių kibernetinio saugumo principų – mažiausių privilegijų principą (Principle of Least Privilege).

Dar geriau – ribotas `sudo`

Kai kurioms paskyroms nebūtina suteikti visiškos sudo prieigos.

Naudojant:

sudo visudo

galima sukurti taisykles, leidžiančias konkrečiam vartotojui vykdyti tik tam tikras komandas.

Pavyzdžiui, automatizavimo ar diegimo paskyrai gali būti suteikta teisė paleisti konkrečią tarnybą, tačiau ne visą sistemą administruoti.

Svarbu: sudoers konfigūraciją redaguokite naudodami visudo, nes jis padeda išvengti sintaksės klaidų, kurios gali sugadinti sudo konfigūraciją.

Esmė

Administratoriaus privilegijų turi būti tiek, kiek būtina darbui – ir ne daugiau.

7. Kiekvienai paslaugai naudokite atskirą vartotoją

Užduotis

Neleiskite visoms serverio paslaugoms veikti su tuo pačiu vartotoju.

Pavyzdžiui, galite sukurti atskiras paskyras:

sudo adduser nodeuser
sudo adduser phpuser
sudo adduser mailcub

Tada atskirkite aplikacijų katalogus:

sudo mkdir -p /var/www/nodeapp
sudo chown -R nodeuser:nodeuser /var/www/nodeapp

sudo mkdir -p /var/www/phpapp
sudo chown -R phpuser:phpuser /var/www/phpapp

Ir, pavyzdžiui:

sudo mkdir -p /var/mailcub
sudo chown -R mailcub:mailcub /var/mailcub

Kodėl tai svarbu?

Įsivaizduokite, kad serveryje veikia trys aplikacijos:

Node.js;
PHP;
el. pašto sistema.

Jeigu visos jos veikia su tuo pačiu vartotoju, vienos aplikacijos kompromitavimas gali suteikti prieigą prie kitų aplikacijų failų.

Atskiri vartotojai sukuria papildomą izoliacijos sluoksnį.

Jeigu, pavyzdžiui, pažeidžiama Node.js aplikacija, užpuolikas gauna nodeuser teises, tačiau neturėtų automatiškai turėti prieigos prie failų, priklausančių phpuser.

Tai nėra visiška izoliacija – tam geriau tinka konteineriai, virtualios mašinos ar kitos izoliacijos technologijos – tačiau tai reikšmingai sumažina vieno kompromitavimo poveikį.

Išjunkite SSH prieigą paslaugų vartotojams

Jeigu paslaugos vartotojui nereikia interaktyvaus prisijungimo, galite neleisti jam prisijungti per SSH:

sudo usermod -s /usr/sbin/nologin nodeuser
sudo usermod -s /usr/sbin/nologin phpuser

Tokios paskyros gali būti naudojamos aplikacijai vykdyti, tačiau nėra skirtos žmogaus prisijungimui.

Esmė

Atskiri vartotojai padeda izoliuoti paslaugas ir sumažina žalą, kurią gali sukelti vienos aplikacijos kompromitavimas.

Papildomas sluoksnis: ugniasienė

Nors tai nėra įtraukta į pradinius septynis punktus, Ubuntu serverio saugumo stiprinime verta atskirai paminėti ir ugniasienę.

Ubuntu sistemoje paprastas pasirinkimas yra UFW (Uncomplicated Firewall).

Pavyzdžiui:

sudo apt install ufw

Leiskite SSH:

sudo ufw allow 22/tcp

Jeigu naudojate žiniatinklio serverį:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Įjunkite ugniasienę:

sudo ufw enable

Patikrinkite taisykles:

sudo ufw status verbose

Svarbiausias principas – atidarykite tik tuos prievadus, kurių iš tikrųjų reikia.

Jeigu duomenų bazė, pavyzdžiui, naudojama tik lokaliai arba per privatų tinklą, jos prievadas neturėtų būti viešai pasiekiamas internete.

Ką dar verta apsvarstyti?

Septyni pagrindiniai veiksmai yra geras pradinis taškas, tačiau rimtesnei infrastruktūrai vien jų neužtenka.

Toliau verta apsvarstyti:

1. MFA administratorių prieigai

Kur įmanoma, papildykite autentifikaciją daugiafaktoriniu autentifikavimu.

2. SSH prieigos ribojimą

Jeigu žinote, iš kokių IP adresų administratoriai jungiasi, SSH galima riboti ugniasienės taisyklėmis arba tinklo lygiu.

3. Failų ir katalogų teises

Patikrinkite, ar aplikacijoms tikrai būtina rašymo teisė į visus jų katalogus.

Ypač svarbu vengti nereikalingų:

teisių.

4. Žurnalų stebėjimą

Saugus serveris nėra tik gerai sukonfigūruotas serveris. Turite žinoti, kas jame vyksta.

Stebėkite bent:

SSH prisijungimus;
sudo naudojimą;
sistemos žurnalus;
web serverio prieigos žurnalus;
aplikacijų klaidas;
neįprastą tinklo aktyvumą.

5. Atsargines kopijas

Saugumo priemonės neapsaugo nuo visko.

Ransomware, administratoriaus klaida, duomenų sugadinimas ar serverio gedimas gali sunaikinti duomenis net ir techniškai saugioje sistemoje.

Todėl būtinos reguliarios atsarginės kopijos, o dar svarbiau – periodiškai patikrinti, ar iš jų iš tikrųjų galima atkurti sistemą.

6. Pažeidžiamumų skenavimą

Vien paketų atnaujinimo ne visada pakanka. Reikėtų periodiškai tikrinti ir pačias aplikacijas, priklausomybes bei viešai pasiekiamas paslaugas.

Galutinis kontrolinis sąrašas

Prieš laikydami Ubuntu serverį paruoštu darbui, patikrinkite:

Ubuntu ir paketai reguliariai atnaujinami;
tiesioginis root SSH prisijungimas išjungtas;
administratoriai naudoja individualias paskyras;
SSH autentifikacija vykdoma naudojant raktus;
slaptažodinė SSH autentifikacija išjungta, kai tai įmanoma;
SSH prieiga apsaugota papildomais mechanizmais, pvz., Fail2Ban;
sudo teisės suteiktos tik tiems vartotojams, kuriems jų reikia;
paslaugos veikia su atskirais vartotojais;
nereikalingiems vartotojams išjungtas interaktyvus prisijungimas;
UFW arba kita ugniasienė leidžia tik reikalingą srautą;
stebimi sistemos ir aplikacijų žurnalai;
atliekamos atsarginės kopijos ir tikrinamas jų atkūrimas.

Išvada

Ubuntu serverio saugumas nėra viena komanda, programa ar konfigūracijos eilutė. Tai gynybos sluoksnių sistema, kurioje kiekviena priemonė mažina skirtingą riziką.

Reguliarūs atnaujinimai apsaugo nuo žinomų pažeidžiamumų. Individualios paskyros ir ribotos sudo teisės padeda kontroliuoti privilegijas. SSH raktai sumažina slaptažodinių atakų riziką. Fail2Ban suteikia papildomą apsaugą nuo automatizuotų bandymų prisijungti. Atskirti paslaugų vartotojai riboja galimos kompromitacijos poveikį, o ugniasienė padeda sumažinti viešai prieinamą serverio atakos paviršių.

Svarbiausia – serverio hardening nėra vienkartinis darbas. Sistema, aplikacijos ir grėsmių aplinka nuolat keičiasi, todėl saugumo konfigūraciją reikia periodiškai peržiūrėti.

Gerai apsaugotas serveris nėra tas, kuriame įjungta kuo daugiau saugumo priemonių. Tai serveris, kuriame kiekviena prieiga, paslauga ir privilegija turi aiškią paskirtį ir yra apribota tiek, kiek praktiškai įmanoma.

7 esminiai Ubuntu serverio saugumo stiprinimo žingsniai

Ubuntu serveriai plačiai naudojami interneto svetainėms, API, duomenų bazėms, el. pašto sistemoms, konteineriams ir įvairioms verslo aplikacijoms. Tačiau vien įdiegti Ubuntu ir paleisti reikalingas paslaugas neužtenka – serverį būtina tinkamai apsaugoti.

1. Reguliariai atnaujinkite operacinę sistemą

Užduotis

Kodėl tai svarbu?

Automatiniai saugumo atnaujinimai

Esmė

2. Išjunkite tiesioginį root prisijungimą per SSH

Užduotis

Kodėl tai svarbu?

Svarbu

Esmė

3. SSH naudokite tik su raktais

Užduotis

Kodėl tai svarbu?

Papildoma rekomendacija

Esmė

4. Pakeiskite numatytąjį SSH prievadą

Užduotis

Ar tai iš tikrųjų padidina saugumą?

Svarbi pastaba

Esmė

5. Įdiekite ir sukonfigūruokite Fail2Ban

Užduotis

Kodėl tai naudinga?

Tačiau Fail2Ban nėra stebuklingas sprendimas

Esmė

6. Ribokite sudo vartotojų skaičių

Užduotis

Kodėl tai svarbu?

Dar geriau – ribotas sudo

Esmė

7. Kiekvienai paslaugai naudokite atskirą vartotoją

Užduotis

Kodėl tai svarbu?

Išjunkite SSH prieigą paslaugų vartotojams

Esmė

Papildomas sluoksnis: ugniasienė

Ką dar verta apsvarstyti?

1. MFA administratorių prieigai

2. SSH prieigos ribojimą

3. Failų ir katalogų teises

4. Žurnalų stebėjimą

5. Atsargines kopijas

6. Pažeidžiamumų skenavimą

Galutinis kontrolinis sąrašas

Išvada

6. Ribokite `sudo` vartotojų skaičių

Dar geriau – ribotas `sudo`