Ruleta ruseasca 2.0

Am dat la un momentdat de o postare pe Reddit in care cineva intreba pe un forum de sysadmins ce solutie de stocat parole e mai buna, iar eu am spus ca toate solutiile existente sunt de fapt niste mizerii nesigure. Evident c-am fost contrazis si mi-am luat downvote pana mi s-a ascuns comentariul.

Doua saptamani mai tarziu a aparut stirea despre vulnerabilitatea din extensia de Chrome a Lastpass si o serie de oameni au inteles atunci faptul ca centralizarea tuturor parolelor intr-un singur loc folosind o aplicatie third party nu e decat o bomba cu ceas si ca in definitiv e mult mai sigur sa pastrezi parolele scrise de mana undeva, eventual intr-un carnetel facut pentru asa ceva pe care sa-l ascunzi in biblioteca decat sa le incredintezi unui software despre care nu cunosti prea multe lucruri.

Evident ca niciunul dintre cei care au recomandat Lastpass in postarea de care aminteam n-a revenit sa-si faca mea culpa in vreun fel.

Foarte multi constientizeaza din pacate ce inseamna sa te joci ruleta ruseasca cu propriile date abia dupa ce e prea tarziu, mult prea tarziu, iar exemplul asta cu Lastpass reprezinta doar introducerea in subiect.

Ce s-a intamplat in cazul Namebox n-a fost deloc surprinzator prin prisma celor direct afectati ci mai degraba prin prisma celor care desi erau gazduiti in alte locuri si n-au fost deloc afectati si-au dat seama ca asa ceva li se poate intampla si lor oricand si s-au pus de facut backupuri sau scris tutoriale pe subiect ignorand de altfel faptul ca pana la backup mai sunt o gramada de factori care pot sa cauzeze pierderea sau coruperea datelor.

Si poate ca subiectul asta nu ar avea o importanta foarte mare daca unii nu s-ar mandri cu faptul ca nu dau doi bani pe securitatea propriilor date si merg pe ideea ca lor nu li se poate intampla fiindca ei n-au nimic important sau valoros de oferit.

Ieri am comentat la o postare pe Facebook vis-a-vis de decizia celor de la Debian de a renunta la FTP, decizie ce mi s-a parut de bun augur si de altfel destul de tarzie dat fiind faptul ca FTP a ajuns un protocol rudimentar si nesigur.

Am fost contrazis desigur de un brav utilizator de FTP care in ignoranta sa (sau poate lipsa de cunostinte in domeniu) omitea faptul ca rsync a aparut ca alternativa la FTP de aproape 21 de ani si ca spre deosebire de FTP prin rsync poti sa folosesti compresie, criptare si mai ales transfer incremental. Ba mai mult rsync merge prin daemonul de SSH ceea ce scuteste nevoia de a rula un daemon separat pentru FTP si de a suporta consumul de resurse cauzat de atacurile de bruteforce care sunt constante si permanente.

Cand i-am spus de problemele cu atacurile a inceput sa-mi dea exemplu propriul sistem cu un VPN necriptat si nesecurizat si cu FTP pe port custom, lucru care-l face sa fie foarte sigur de datele sale fiindca in opinia lui nu mai suntem la finalul anilor ’90 cand oricine spargea servere ca sa puna un psyBNC. Acum, spunea el, tinta sunt doar cei care au ceva de oferit.

Partial are dreptate, nu mai sparge nimeni servere pentru psyBNC si desigur nu mai prea exista vulnerabilitati de tip buffer overflow si heap overflow care sa afecteze direct daemonii, insa exista in continuare o sumedenie de atacuri de bruteforce care sunt mult mai nocive prin prisma impactului pe care-l au asupra resurselor de pe server. Pe sisteme configurate prost un bruteforce masiv poate sa aiba acelasi impact ca un synflood.

Dincolo de asta, orice server conectat la internet, oricat de irelevant ar parea are ceva de oferit pentru ca in primul rand atacatorii au nevoie de resursele serverului respectiv pentru atacurile lor. Si resursele alea pot sa fie folosite in diverse scopuri, de la banalele campanii de spam sau propagare de malware pentru creare de retele botnet la minare de cryptocurrency sau chiar seeding de torrenti. Evident ca nu stiu lucrurile astea din auzite sau citite pe net ci din cazurile pe care le-am auditat de-a lungul anilor.

Cum singurul argument al omului era faptul a lui i-a mers si asa si n-a avut probleme nu m-am mai obosit sa-i explic ca tot din experienta am invatat faptul ca cei care sunt reticenti la schimbare sunt fix oamenii care sunt constienti de faptul ca sunt incapabil sa produca schimbarea. In 6 din 10 cazuri schimbarile tehnice produc probleme (remediabile) si in 9 din 10 cazuri schimbarile sunt refuzate intocmai pentru a evita astfel de probleme sau mai bine zis pentru a evita responsabilitatile ce survin.

Probabil ca cel mai amuzant aspect din toata discutia avuta cu respectivul e faptul ca, in articolul de referinta, stafful Debian isi motiva decizia cu aceleasi argumente pe care incercam sa i le traduc eu interlocutorului meu.

E drept ca sunt rare situatiile in care dau de vreunul care se joaca ruleta ruseasca cu datele sale si mult mai rare situatiile in care respectivul mai e si mandru de treaba asta, dar de fiecare data cand se intampla lucrul asta imi imaginez scena aia din Supravietuitorul lui Sergiu Nicolaescu in care ignoranta eroului principal atinge cote atat de mari incat iti da impresia ca dupa ce a apasat pe tragaci atatia ani pare-se ca a devenit de-a dreptul nemuritor. Si dintr-o data inevitabilul se produce…

Leave a Reply

Your email address will not be published. Required fields are marked *