Virtualū privačius serveriai (VPS) šiandien yra vienas populiariausių sprendimų įmonėms ir privatiems asmenims, kuriems reikia lankstios, patikimos ir prieinamos serverių infrastruktūros. Deja, būtent tas prieinamumas, kuris daro VPS tokį patrauklų, taip pat sukuria didžiulę riziką: serveris, prijungtas tiesiogiai prie interneto, tampa taikiniu automatiniams botams, sukčiams ir kenkėjiškiems scenarijams, kurie kas minute skanuoja tūkstančius IP adresų ieškodami silpnų vietų.
Tyrimai rodo, kad naujai sukurtas VPS serveris, neturintis jokios papildomos apsaugos, per pirmąją valandą gali sulaukti šimtų nesankcionuoto prisijungimo bandymų. Tai nėra hipotetinė grėsmė – tai kasdienybė. Todėl serverio saugumas nėra vienkartinis nustatymas, o nuolatinis procesas, reikalaujantis sistemingo požiūrio, supratimo apie grėsmes ir gebėjimo taikyti kelis apsaugos sluoksnius.
Šiame straipsnyje aptarsime viską, ko reikia norint užtikrinti maksimalų VPS serverio saugumą – nuo pirmųjų žingsnių po operacinės sistemos diegimo iki sudėtingesnių strategijų, tokių kaip tinklo segmentacija, elgsenos analitikos įrankiai ir automatinis incidentų reagavimas. Nesvarbu, ar esate patyręs sistemos administratorius, ar tik pradedate kelionę su savo pirmuoju VPS – čia rasite praktinių, taikomų patarimų.
Pirmas žingsnis: operacinės sistemos pažeidžiamumų šalinimas
Pats pirmas dalykas, kurį reikia padaryti vos įsigijus VPS, yra įsitikinti, kad operacinė sistema yra visiškai atnaujinta. Distribucijos, tokios kaip Ubuntu, Debian ar CentOS, reguliariai išleidžia saugumo pataisas, tačiau jos nėra įdiegtos automatiškai, nebent specialiai tokį veikimo režimą sukonfigūruosite. Daugelis sėkmingų atakų prieš serverius pasinaudoja seniai žinomomis pažeidžiamybėmis, kurioms pataisos buvo išleistos prieš mėnesius ar net metus.
Ubuntu ir Debian sistemose atnaujinimui pakanka vykdyti komandas apt update ir apt upgrade. CentOS ar AlmaLinux atveju naudojamas dnf update arba yum update. Atrodo paprasta, tačiau nustebtinite, kiek sistemų tuo pamiršta pasirūpinti. Problema dažniausiai yra ne žinios stoka, o laiko trūkumas – atnaujinimai atidedami „vėliau“, o tarp tuo laiku atakuojama.
Geresnis sprendimas yra automatinis saugumo atnaujinimų diegimas. Ubuntu sistemose galima naudoti unattended-upgrades paketą, kuris automatiškai įdiegia saugumo pataisas, kai jos pasirodo. Konfigūracija leidžia atskirti saugumo atnaujinimus (diegiami automatiškai) nuo funkcinių atnaujinimų (lieka rankiniu būdu), kad sumažintų riziką, jog atnaujinimas sutrikdys veikiančią sistemą. Reikėtų paminėti, kad automatiniai atnaujinimai nėra be rizikos – kartais pataisa gali sugadinti priklausomybes arba sukurti nesuderinamumą su trečiųjų šalių programine įranga. Todėl svarbu sekti atnaujinimų rezultatus ir turėti atsarginę kopiją prieš diegiant.
SSH sauga: labiausiai atakuojamas įėjimo taškas
SSH (Secure Shell) yra pagrindinis būdas prisijungti prie VPS ir jį administruoti. Jis taip pat yra pirmasis taikinys automatiniams brutalios jėgos (brute-force) išpuoliams, kurie bando tūkstančius slaptažodžių kombinacijų vildamiesi rasti silpną ar numanomą slaptažodį. Pagal nutylėjimą daugelis VPS teikėjų sukonfigūruoja SSH taip, kad leidžia prisijungti naudojant root naudotoją ir slaptažodžio autentifikaciją – tai yra pavojingiausias įmanomas derinys.
Pirmas dalykas, kurį reikia pakeisti, yra SSH prisijungimo būdas. Slaptažodžio autentifikacija turi būti išjungta ir pakeista SSH raktų autentifikacija. SSH raktai naudoja asimetrišką kriptografiją – privatusis raktas lieka jūsų kompiuteryje, o viešasis raktas dedamas serverį. Kadangi privatusis raktas niekada nepersiunčiamas tinklu, net jei užpuolikas sugautų visą srautą, jis negalėtų jo naudoti. Raktų generavimui naudojama komanda ssh-keygen, o pageidautina naudoti Ed25519 algoritmą, kuris siūlo stipresnę saugą ir trumpesnius raktus nei senesni RSA variantai.
Antras esminis pakeitimas – root prisijungimo draudimas. Vietoje to sukurkite paprastą naudotoją, suteikiate jam sudo teises, o SSH konfigūracijoje nustatote PermitRootLogin no. Tai reiškia, kad net jei užpuolikas surinktų teisingą slaptažodį ar raktą, jis negalėtų tiesiogiai prisijungti kaip root – turėtų pirmiausia prisijungti kaip paprastas naudotojas, o tada eskaluoti teises. Tai sukuria papildomą apsaugos barjerą.
Trečias žingsnis – SSH prievado keitimas. Pagal nutylėjimą SSH klauso 22 prievade, ir visi automatizuoti skanavimo botai tikrina būtent šį prievadą. Pakeitus prievadą į nestandartinį skaičių (pvz., 2222 arba bet kokį kitą numerį tarp 1024 ir 65535), žymiai sumažėja triukšmo kiekis registruose, nors tai nėra tikra apsaugos priemonė – nusiteikęs užpuolikas vis tiek gali nuskanuoti visus prievadus. Nepaisant to, tai mažiau apsaugo nuo atakų ir daugiau pagerina administravimo patirtį, sumažinant nereikalingą triukšmą.
Galiausiai verta apriboti, kurie IP adresai iš viso gali prisijungti per SSH. Jei jūsų administravimas vykdomas iš fiksuoto biuro ar VPN, galima naudoti SSH konfigūracijos direktyvas AllowUsers arba ugniasienės taisykles, apribojančias priėjimą konkrečiais IP adresais. Tai ne visada įmanoma jei keliate iš dinaminių IP, bet kuriais atvejais, kai įmanoma, tai yra viena efektyviausių apsaugos priemonių.
Ugniasienė: pirmoji gynybos linija
Ugniasienė yra tarp serverio ir interneto esantis filtras, kuris nusprendžia, koks srautas yra leidžiamas ir koks blokuojamas. VPS be ugniasienės yra lyg namas be durų – visi prievadai atviri, ir kiekviena tarnyba, paleista serveryje, automatiškai pasiekiama iš išorės. Tai dažna klaida: žmonės įdiegia duomenų bazes, pvz., MySQL ar PostgreSQL, ir palieka jas klausytis visuose tinklo sąsajuose, kas reiškia, kad visame internete yra prieinama duomenų bazės prisijungimo sąsaja.
Linux sistemose populiariausi ugniasienės įrankiai yra iptables, nftables (naujesnė iptables kartą) ir ufw (Uncomplicated Firewall – supaprastinta sąsaja, dažniausiai naudojama Ubuntu). iptables ir nftables yra galingi, bet reikalauja gilesnio supratimo; ufw yra pradedantiesiems draugiškesnė išvaizda, tačiau jos užkaboris yra tas pats branduolio modulis.
Esminis principas konfigūruojant ugniasienę yra numatytojo draudimo strategija: viskas, kas nėra aiškiai leidžiama, yra draudžiama. Kitaip tariant, pirmiausia blokuojamas visas įeinantis srautas, o tada atidaromi tik tie prievadai, kurie iš tikrųjų reikalingi. Tipiškam žiniatinklio serveriui reikia tik dviejų atvirų prievadų: 80 (HTTP) ir 443 (HTTPS), plius SSH prievadas administravimui. Viskas kita – duomenų bazės, vidiniai API, administravimo skydeliai – turi būti uždaryta arba prieinama tik iš vidinio tinklo.
Kalbant apie išeinantį srautą, rekomenduojama leisti tik tai, ko iš tikrųjų reikia. Kai kurie kenkėjiški scenarijai, patekę į serverį, bando susisiekti su savo komandiniais centrais (C&C serveriais) ar siųsti iššifruotus duomenis. Apribojus išeinantį srautą tik tam tikroms tarnyboms ir prievadams, galima bent iš dalies sumažinti šią riziką. Žinoma, tai gali apsunkinti kai kurias legitimias operacijas, todėl reikia rasti balansą tarp saugumo ir funkcionalumo.
Fail2ban: automatizuota brutalios jėgos atakų blokavimas
Net jei SSH yra apsaugotas raktų autentifikacija, vis dar verta apsisaugoti nuo tų, kurie bando prisijungti naudodami slaptažodžius. Fail2ban yra įrankis, kuris seka serverio registrus ir, pastebėjęs kelis nesėkmingus prisijungimo bandymus iš to paties IP adreso, automatiškai sukuria ugniasienės taisyklę, kuri blokuoja tą adresą. Paprastai konfigūruojama taip, kad po penkių nesėkmingų bandymų per dešimt minučių IP adresas blokuojamas valandai ar ilgiau.
Fail2ban gali stebėti ne tik SSH, bet ir kitas tarnybas – žiniatinklio serverius, el. pašto serverius, FTP ir daugelį kitų. Kiekvienai tarnybai gali būti nustatytas atskiras jautrumas ir ban trukmė. Pavyzdžiui, SSH gali turėti griežtesnį limitą (trys bandymai = valandos banas), o žiniatinklio serveris – švelnesnį (dešimt bandymų = dešimt minučių banas), nes žiniatinklio tarnybose nesėkmingi bandymai gali atsirasti dėl natūralių priežasčių (klaidingi užklausimai, sugedę klientai).
Svarbu suprasti, kad Fail2ban nėra tobula apsauga. Užpuolikas, naudojantis didelį botų tinklą, gali pereiti nuo vieno IP adreso prie kito greičiau, nei Fail2ban spėja blokuoti. Tai vadinama „hit-and-run“ strategija. Tačiau Fail2ban žymiai padidina atakos sąnaudas ir sumažina triukšmo kiekį, o tai suteikia daugiau laiko pastebėti ir sureaguoti į didesnes grėsmes.
Naudotojų teisių valdymas ir principas „mažiausiai teisių“
Vienas svarbiausių saugumo principų informacinėse sistemose yra principas „mažiausiai teisių“ (principle of least privilege). Jo esmė paprasta: kiekvienas naudotojas, procesas ir tarnyba turi turėti tik tas teises, kurios yra būtinos jų funkcijoms atlikti – ne daugiau. Jei tarnyba ar naudotojas turi daugiau teisių, nei reikia, pažeidus tą tarnybą užpuolikas gauna daugiau prieigos, nei turėtų.
Praktiškai tai reiškia, kad žiniatinklio serveris (Apache, Nginx) turi veikti su specialiu naudotoju, kuris neturi sudo teisių ir negali rašyti į sistemos failus. Duomenų bazė turi veikti su atskiru naudotoju, kuris gali pasiekti tik duomenų bazės failus. Jei žiniatinklio aplikacija turi FTP ar failų įkėlimo funkciją, įkelti failai turi būti izoliuoti nuo likusios sistemos.
Linux sistemoje tai pasiekiama naudojant naudotojus ir grupes, Failų sistemos leidimus, ir prireikus – sudėtingesnius mechanizmus, tokius kaip AppArmor ar SELinux. Šie saugumo moduliai leidžia apibrėžti, ką konkretus procesas gali daryti sistemoje – prie kurių failų prisieiti, kuriuos tinklo prievadus atidaryti, kokias sistemos komandas vykdyti. AppArmor yra paprastesnis ir dažniau naudojamas Ubuntu, o SELinux yra sudėtingesnis ir dažniau naudojamas CentOS/RHEL sistemose. Abu yra galingi, tačiau reikalauja laiko išmokti ir konfigūruoti.
Papildomas sluoksnis gali būti sudo konfigūracija. Galima leisti konkretiems naudotojams vykdyti tik tam tikras komandas su sudo (pvz.,.restartuoti žiniatinklio tarnybą), o ne suteikti jiems pilną administravimo prieigą. Tai naudinga komandose, kur ne kiekvienas narys turi turėti pilną serverio kontrolę.
DDoS apsauga: kai ataka skirta ne įsilaužti, o paralyžiuoti
Skirtingai nei daugelis kitų atakų, kurių tikslas yra patekti į sistemą, DDoS (Distributed Denial of Service) atakos tikslas yra paprasčiausiai padaryti serverį nepasiekiamą legitimiems naudotojams. Tai daroma užtvindant serverį tokiu srauto kiekiu, kurio jis negali apdoroti – arba uždelsiant tinklo ryšį, arba priverstinai nutraukiant procesorinę atmintį.
DDoS apsauga VPS lygyje yra sudėtinga, nes serverio resursai yra riboti. Paprastas VPS su vienu branduoliu procesoriaus ir 2 GB RAM vargu ar galės atremti net nedidelę DDoS ataką. Todėl efektyviausia DDoS apsauga dažniausiai yra ne serverio lygyje, o tinklo infrastruktūros lygyje. Daugelis hostingo teikėjų siūlo DDoS apsaugą kaip papildomą paslaugą – ji veikia prieš srautą pasiekiant serverį, filtruojant ir nukreipiant kenkėjišką srautą.
Jei tokios paslaugos nėra prieinama, yra keli serverio lygio metodai. iptables arba nftables gali būti konfigūruojami riboti ryšio skaičių iš vieno IP adreso per sekundę (rate limiting), atpažinti ir blokuoti SYN flood atakas naudojant SYN cookies, arba riboti ICMP srautą. CDN (Content Delivery Network) paslaugos, tokios kaip Cloudflare, taip pat gali tarnauti kaip DDoS apsaugos sluoksnis – jos slepia tikrąjį serverio IP adresą ir sugeria atakos srautą prieš jį pasiekiant serverį.
Reikėtų paminėti, kad programinės įrangos DDoS apsauga serverio lygyje turi ribotas galimybes. Ji gali padėti nuo mažų, paprastų atakų, tačiau prieš didelius, koordinuotus atakos iš tūkstančių IP adresų ji bus bejėgė. Todėl planuojant rimtesnę infrastruktūrą būtina galvoti apie tinklo lygio apsaugą.
SSL/TLS šifravimas: ne prabanga, o būtinybė
Bet kokia komunikacija tarp serverio ir naudotojo, kurioje perduodama jautri informacija (slaptažodžiai, asmeniniai duomenys, mokėjimo informacija), turi būti šifruota. TLS (Transport Layer Security) yra standartinis būdas tai padaryti – tai protokolas, užtikrinantis, kad srautas tarp naršyklės ir serverio yra privatus, autentifikuotas ir vientisas.
Iki šiol SSL sertifikatai buvo laikomi brangia prabanga, kurią sau leido tik didelės organizacijos. Šiandien padėtis yra visiškai pasikeitusi. Let’s Encrypt – nemokama, automatizuota sertifikato išdavimo paslauga – leidžia kiekvienam gauti ir atnaujinti TLS sertifikatus be jokių išlaidų. Įrankiai, tokie kaip certbot, automatizuoja sertifikato gavimo ir atnaujinimo procesą, integruodami juos tiesiogiai su Apache ar Nginx.
Sertifikatas pats savaime nėra pakankamas – svarbu ir tai, kaip TLS yra konfigūruotas. Seni protokolai, tokie kaip SSLv3 ir TLS 1.0, yra pažeidžiami ir turi būti išjungti. Pageidautina naudoti TLS 1.2 ar naujesnę versiją (TLS 1.3), ir sukonfigūruoti stiprius šifravimo paketus (cipher suites). Įrankiai, tokie kaip Mozilla SSL Configuration Generator, padeda sugeneruoti saugias konfigūracijas pagal serverio programinę įrangą. Taip pat verta reguliariai tikrinti sertifikatą ir TLS konfigūraciją naudojant Qualys SSL Labs testą – tai nemokama paslauga, kuri įvertina sertifikato stiprumą, protokolo versijas, šifravimo paketus ir kitus saugumo aspektus.
Papildomas saugumo sluoksnis yra HSTS (HTTP Strict Transport Security) antraštė – ji nurodo naršyklei, kad ateityje visada naudotų HTTPS, net jei naudotojas vestų HTTP adresą. Tai apsaugo nuo vadinamųjų SSL stripping atakų, kuriose užpuolikas, esantis tarp serverio ir naudotojo (pvz., viešajame Wi-Fi tinkle), bando priversti naršyklę perjungti į nešifruotą ryšį.
Atsarginės kopijos: paskutinė gynybos linija
Nesvarbu, kiek saugumo priemonių įdiegsite – visada yra tikimybė, kad kažkas nutiks. Gali būti rastas naujas pažeidžiamumas jūsų naudojamame programiniame įrime, gali įvykti klaida konfigūruojant, gali būti tiesiog fizinė įrangos gedimas. Tokiais atvejais vienintelis dalykas, kuris skiria rimtą incidentą nuo katastrofos, yra atsarginė kopija.
Atsarginės kopijos strategijai būtina laikytis trijų principų: kopijos turi būti reguliaros, automatiškos ir saugomos fiziškai kitur nei pagrindinis serveris. Jei atsarginė kopija laikoma tame pačiame serveryje ar net tame pačiame duomenų centre, ji žus kartu su serveriu. Todėl kopijos turi būti saugomos ne tik kitame serveryje, bet idealiai ir kitoje geografinėje lokacijoje.
Praktiškai tai gali būti daroma įvairiai. Galima naudoti rsync sinchronizacijai su atsargos serveriu, borg arba restic – šifravimą palaikantiems atsarginės kopijos įrankiams, arba naudoti savo hostingo teikėjo snapshot funkciją. Debesų saugyklos, tokios kaip Amazon S3 ar Backblaze B2, taip pat yra populiarūs atsarginių kopijų tikslai. Svarbu, kad kopijos būtų šifruotos – kitaip pati atsarginė kopija tampa nauja grėsme, nes joje gali būti visi jūsų duomenys, paruošti išimti.
Dar vienas dažnai ignoruojamas aspektas – atsarginių kopijų testavimas. Turėti atsarginę kopiją be praktinio bandymo ją atkurti yra beveik tas pats, kaip neturėti jos išvis. Retkarčiais reikia atlikti atkūrimo procedūros testą: paimti atsarginę kopiją, atkurti į testinę aplinką ir patikrinti, ar duomenys yra tinkami, ar programa veikia. Tai padeda atrasti problemas tada, kai dar turite laiko jas išspręsti, o ne tada, kai jau vyksta incidentas.
Tarnybų izoliavimas naudojant konteinerius ir virtualizaciją
Jei jūsų VPS vykdo kelias tarnybas – pavyzdžiui, žiniatinklio serverį, duomenų bazę, el. pašto serverį, ir galbūt dar keletą mažesnių aplikacijų – verta pagalvoti apie jų izoliavimą naudojant konteinerius. Docker ir panašios konteinerių technologijos leidžia kiekvienai tarnybai veikti savo izoliuotoje aplinkoje su atskiromis priklausomybėmis, atskirais tinklo sąsajais ir atskirais failų sistemos vaizdais.
Izoliavimas turi kelis saugumo privalumus. Pirma, jei viena tarnyba yra pažeidžiama, užpuolikui sunkiau pereiti prie kitų tarnybų, nes jos veikia atskirose aplinkose. Antra, konteineriai gali būti paleidžiami su apribotomis teisėmis – pavyzdžiui, be tinklo prieigos, jei tam nėra reikalo, arba su read-only failų sistema. Trečia, konteinerių atnaujinimas yra paprastesnis – galima traukti naują versiją ir paleisti iš naujo, nedarant įtakos kitoms tarnyboms.
Žinoma, konteinerių saugumas nėra absoliutus. Konteineriai nėra tokie izoliuoti, kaip pilnos virtualios mašinos, ir buvo žinomi atvejai, kai pažeidus konteinerį buvo galima „pabėgti“ į pagrindinę sistemą (container escape). Todėl svarbu naudoti naujausias konteinerių runtime versijas, vengti paleisti konteinerius su --privileged vėliava, ir, jei reikia didesnio saugumo, naudoti sunkesnės virtualizacijos sprendimus, tokius kaip KVM arba atskirus VPS kiekvienai tarnybai.
Stebėjimas ir registravimas: kaip pastebėti tai, kas negerai
Daugelis saugumo incidentų yra neaptikti ne todėl, kad jų negalima buvo aptikti, o todėl, kad niekas nestebėjo. Serverio registrai (logs) yra neapsiepiamas informacijos šaltinis, bet be sistemos, kuri juos centralizuotai renka, analizuoja ir įspėja apie anomalijas, jie tebėra tik begalinė teksto dykyna, kurioje niekas nieko neranda.
Mažiausiai, ką reikia padaryti, yra įsitikinti, kad registravimas yra įjungtas ir registrai yra saugomi pakankamai ilgai. Pagal nutylėjimą daugelis Linux distribucijų naudoja systemd-journald arba rsyslog žurnalo tvarkymo sistemą. Svarbu patikrinti, ar registrai nėra per trumpai saugomi (pvz., tik kelias dienas) ir ar jie neperpildo disko. Rekomenduojama saugoti registru bent kelias savaites, jei įmanoma – ilgiau.
Didesnėms infrastruktūroms verta pagalvoti apie centralizuotą žurnalo rinkimą. Įrankiai, tokie kaip ELK stack (Elasticsearch, Logstash, Kibana) ar Graylog, leidžia rinkti registru iš kelių serverių į vieną vietą, indeksuoti juos ir leisti ieškoti bei vizualizuoti. Tai ne tik palengvina incidentų tyrimą, bet ir leidžia pastebėti modelius, kurie rodo besivystančią ataką dar prieš jiems sukdamis realios žalos.
Stebėjimas taip pat reiškia resursų naudojimo sekimą. Netikėtas CPU naudojimo šuolis, nepamąstytas tinklo srauto padidėjimas ar diskų rašymo intensyvumo augimas gali būti požymiai, kad kažkas negerai – galbūt paleistas kriptovaliutų kasimo scenarijus, galbūt vyksta duomenų exfiltracija, galbūt serveris dalyvauja DDoS atakoje prieš ką nors kitą. Įrankiai, tokie kaip htop, iftop, nethogs, ir nuolatinio stebėjimo sistemos, tokios kaip Netdata ar Prometheus su Grafana, padeda matyti, kas vyksta serveryje realiu laiku.
Reti, bet svarbūs papildomi saugumo sluoksniai
Yra keletas mažiau žinomų, bet vertingų saugumo priemonių, kurios gali stipriai padidinti VPS saugumą, bet dažnai lieka nepastebėtos.
Port knocking – tai metodas, kuriuo prievadas (pvz., SSH) lieka uždarytas, kol iš išorės negaunama specifinė „šablono“ seka ryšio bandymų į tam tikrus prievadus. Tai tarsi slaptas pasibeldimas į duris – kas nežino sekos, nemato, kad prievadas išvis egzistuoja. Tai nėra plačiai naudojama, nes gali būti sudėtinga administruoti, tačiau kai kurioms situacijoms tai suteikia papildomą slaptumo sluoksnį.
Wireguard VPN – jei jūsų serveriui reikia prieigos prie vidinių tarnybų, geresnis sprendimas nei atidaryti prievadus internetui yra sukurti VPN ryšį tarp savo darbo kompiuterio ir serverio. Wireguard yra lengvesnis, greitesnis ir turi mažiau kodu nei OpenVPN, kas reiškia mažesnį pažeidžiamumo paviršių. Viskas, kas nėra žiniatinklio serveris ar kita viešai prieinama tarnyba, gali būti pasiekiama tik per VPN.
AIDE ar Tripwire – failų vientisumo stebėjimo įrankiai. Jie sukuria „atvaizdą“ visų svarbių sistemos failų (hash’us, leidimus, savininkus) ir reguliariai patikrina, ar kas nors pasikeitė. Jei užpuolikas pakeičia sisteminį failą, pvz., sshd ar ls, į savo versiją, AIDE tai aptiks ir įspės. Tai ypač naudinga aptikti vadinamuosius rootkits – kenkėjišką programinę įrangą, kuri bando pasislėpti sistemoje.
Auditing – Linux branduolyje yra įmontuotas audit modulis (auditd), kuris leidžia detalai sekti sistemos įvykius: kas vykdė kokias komandas, kas prisijungė, kas kuriuos failus atidarė. Tai galingas įrankis incidentų tyrimui ir合规 patikrinimui, nors jo konfigūravimas reikalauja laiko ir patirties.
Ką daryti incidento atveju
Nepaisant visų saugumo priemonių, kiekvienas sistemos administratorius turi būti pasirengęs tai, kad incidentas gali įvykti. Svarbu turėti planą, kaip reaguoti, nes chaosas metu blogi sprendimai gali padaryti daugiau žalos nei pati ataka.
Pirmas žingsnis yra išlaikyti ramybę ir nebandyti slėpti pėdsakų. Išjungti serverį galima atrodytų logiškas žingsnis, norint sustabdyti ataką, tačiau tai sunaikins visus registruose esančius įkalčius, kurie gyvena atmintyje. Geriau atjunkti serverį nuo tinklo (network cable / virtual network interface) ir taip izoliuoti, bet palikti jį įjungtą, kad registrai išliktų.
Antras žingsnis – dokumentuoti viską, kas vyksta. Kada buvo pastebėta, kaip, ką matėte, ką darėte. Tai bus nebrangu ir vertinga tiek pačiam tyrimui, tiek ateityje, kai reikės analizuoti, kas nutiko.
Trečias žingsnis – atstatyti kontrolę. Pakeisti visus slaptažodžius, sugeneruoti naujus SSH raktus, peržiūrėti, ar nėra naujų naudotojų, kurių jūs nekūrėte, ar nėra naujų cron užduočių, kurios gali paleisti kenkėjišką programinę įrangą. Jei abejojate dėl sistemos vientisumo, saugiausia yra perstatyti serverį iš naujo: ištrinti viską, įdiegti švarią operacinę sistemą, ir atkurti duomenis iš atsarginės kopijos, kuri buvo sukurta iki incidento.
Galiausiai – atlikite post-mortem analizę. Supraskite, kaip ataka įvyko, kokia pažeidžiamybė buvo išnaudota, ir ką galima padaryti, kad tai nepasikartotų. Saugumo incidentas yra skausminga, bet vertinga pamoka, jei ji yra išnaudota tinkamai.
Išvados
VPS serverio saugumas nėra vienas nustatymas ar vienas įrankis – tai yra kelių sluoksnių strategija, kuri apima infrastruktūros, tinklo, operacinės sistemos, programinės įrangos ir proceso aspektus. Nėra tokio dalyko kaip „visiškai saugus serveris“ – yra tik serveris, kuris yra pakankamai saugus, atsižvelgiant į tai, ką jis saugo ir kokie prieš jį nukreipti pajėgumai gali būti.
Svarbiausi žingsniai, aptarti šiame straipsnyje, yra: operacinės sistemos atnaujinimai, SSH sauginimas raktų autentifikacija, ugniasienės konfigūracija pagal nutylėjimą-draudimo principu, Fail2ban įdiegimas, naudotojų teisių valdymas pagal mažiausiai teisių principą, SSL/TLS šifravimas, reguliarios atsarginės kopijos, konteinerių izoliavimas, stebėjimas ir registravimas, bei parengtis reaguoti į incidentus. Kiekvienas iš šių sluoksnių pats savaime nėra pakankamas, tačiau kartu jie sukuria giluminę gynybą, kurioje vieno sluoksniaus nesėkmė nereiškia visos sistemos kritimo.
Galiausiai saugumas yra ne techninis, o organizacinis iššūkis. Technologijos yra – svarbu turėti discipliną jas taikyti, nuolatos jomis rūpintis ir būti pasirengusiam tai dienai, kai jos nesuveiks.