Raport din spatele firewall-ului

Administrând un server linux (un VPS CentOS + WHM), printre altele sunt zilnic la ”pupitru” urmărind log-uri și rapoarte, în special cele de uptime și de la firewall. Și firewall-ul are întodeauna de raportat ceva: încercări de autentificare la diverse servicii, port scanning ș.a.m.d.

Ca un experiment, m-am gândit pentru o lună să păstrez fișierele de log ale firewall-ului pentru un sumar al atacurilor. Și aici vă prezint cele găsite:

Sumarul atacurilor pe zi:
firewall-daily

Media este de 5,97 de posibile atacuri detectate pe zi, cu maximul atins marți 10 decembrie a.c. de 34 de atacuri unice detectate. Alte zile în care am înregistrat un număr semnificativ de detecții sunt noiembrie 27, noiembrie 25 și noiembrie 11, cu o frecvență mai mare de 10. Se pare că în a doua jumătate a lunii noiembrie frecvența s-a menținut la o medie de peste 5 pe zi, după care a scăzut la sub 5 pentru 9 zile (intervalul 29 noiembrie – 7 decembrie), revenind la valori mari după data de 8 decembrie.

Servicii aflate sub “asediu”
services under attack

Cifrele prezentate mai sus indică numărul de posibile atacuri. În cazul serviciilor ca ssh, smtp, pop3 și ftp firewall-ul consideră un atac oricare 3 sau mai multe încercări consecutive de autentificare eșuate.
În acest top, ssh conduce detașat, cu un număr de 230 de încercări eșuate de autentificare. Urmat de serverul smtp, serviciul care trimite mailul, cu 115 de autentificări eșuate.
Și pentru că pentru un atac mai eficace e foarte prețioasă o listă de porturi deschise, s-au detectat 35 de astfel de încercări de scanare.
Mod_security a detectat în mare parte URL-uri malformate și încercări de evaziune a protocolului HTTP, cel mai probabil din cereri generate de un botnet.
Demonul POP3 a fost încercat de 25 ori, probabil de un curios, sau poate fi cineva care și-a uitat parola sau încearcă să-și citească mailurile de pe un alt dispozitiv, iar ftp de 12 ori.

Sursa atacurilor pe țări
attack top countries

Am listat în legendă doar primele 12 țări după numărul de detecții. După FQDN, multe dintre acestea par a proveni din rețelele unor companii de hosting și a unor operatori de telecom. Datele sunt puține pentru a trage o concluzie vis-a-vis de o companie de hosting sau un operator cu serviciile compromise sau abuzate la scară, însă sunt câteva host-uri care apar mai frecvent în log-uri: dynamic.ttnet.com.tr (Turcia), clients.your-server.de (Germania), static.opt-online.net (SUA), host.redstation.co.uk (Regatul Unit), electrosim.ro (România). Cât despre China, în majoritatea cazurilor nu s-a reușit asocierea sursei cu un host sau IP, cel mai probabil deoarece se aflau în spatele unui firewall SPI.

Totuși pentru sursele pentru care s-a putut stabili o adresă, pentru o imagine de ansamblu, le-am pus pe hartă:attacks-map

CryptoLocker – protejarea lui Windows 7 prin Software Restriction Policy

Acum aproximativ o lună a apărut un ransomware nou și îngrijorător de eficient pe numele lui- Cryptolocker. Dacă nu știți ce este un ransomware vă invit să vă informați de pe wikipedia.

Există de asemenea un post pe Reddit foarte activ cu noutăți zilnice despre ”infecție”, iar mai jos am pregătit un tutorial video care vă arată cum puteți seta pe Windows 7 (aplicabil și la Vista cu mici diferențe) politica de restricție software care vă poate proteja de CryptoLocker.

Ca o notă în primul rând, pentru a vă proteja, ar trebui să aveți un antivirus instalat și actualizat la zi, recomandarea mea este BitDefender sau Avast!, și desigur un backup al datelor voastre importante undeva off-site.

 

Pentru backup cel mai la îndemână e Windows Backup, desigur pe un disc extern sau un NAS.

Din terminologia utilizată de hackeri

În acest articol o să descriu succint, dar sper pe înțelesul vostru, câțiva din termenii utilizați des de cercetătorii în domeniul securității sistemelor informatice (numiți de media și hackeri).

Ca o scurtă notă, comunitatea ”hackerilor” a apărut dintr-o nevoie, una pe care acum poate societatea o resimte tot mai aproape, după expansiuea rețelelor de socializare și binențeles a internetului. Ca exemplu, o să vă dau o lege din constituția SUA, care permite oricărui cetățean să dețină o armă pentru a se putea apăra de guverul SUA.
Nu este scopul acestui articol să intre în polemici de etică, conduită sau morală așa că o să trec direct la subiect.

PoC: prescurtarea de la Proof of Concept, respectiv un document, o prezentare, sau o legătură care poate fi folosită pentru a dovedi că o presupusă vulnerabilitate chiar există, și deci poate fi reprodusă. Un astfel de exemplu este prezentarea lui Barnaby Jack.

RCE: Remote Code Execution, este un tip de vulnerabilitate prin care un sistem poate fi manipulat să ruleze secvențe de cod specificate și/sau comenzi trimise de pe o altă mașină – de la distanță.

Un exemplu elocvent sunt cele raportate recent cu mașina virtuală Java. De exemplu folosind această metodă la vizitarea unei pagini web care încarcă un applet Java ce conține un cod specific de evaziune, mașina virtuală care rulează pe sistemul vizitatorului pentru a executa applet-ul din pagina web, poate fi manipulată să execute un fișier specific de pe disc – de exemplu notepad.exe sau shudtown.exe.
Desigur că Java a fost actualizat și este acum mai sigur însă ar fi o idee bună să verificați dacă aveți instalată ultima versiune.

Buffer Overflow/Underflow: un tip de vulnerabilitate care permite abuzul memoriei rezervat unei aplicații. Acestea cauzează blocarea sau oprirea forțată a soft-ului în cauză și uneori poate duce la blocarea mașinii pe care ruleză softul afectat. Un exemplu este cea cu antetul Range în Apache versiunea 2.0. Aceasta permitea trimiterea unei cantități mari de de valori care se suprapun în antetul Range, printr-o cerere către un server Apache 2.0, ducând la suprautilizarea de resurse hardware. Adesea acest tip de vulnerabilități sunt folosite pentru a provoca atacuri de tip DoS.

CSRF/XSRF: prescurtarea de la Cross-Site Request Forgery, este un tip de vulnerabilitate care permite trimiterea unei cereri automate din domeniul X la domeniul B în sesiunea mașinii/utilizatorului autorizate pe domeniul B.

Mai pe larg, acest tip de atac profită de fereastra de autorizare garantată de primul domeniu. Atunci cînd vă autentificați pe un site, (domeniul B.com), pentru a vă recunoaște, navigatorul dvs. primește de la aplicație bucăți de informații pe care le salvează într-o memorie temporară, numite și cookie-uri. Navigatorul dvs va re-trimite aceste ”prăjiturele” la domeniul B.com cu fiecare cerere (la fiecare încărcare de pagină) și astfel serverul știe că sunteți autentificat, și mai ales sub ce identitate sunteți autentificat. Să zicem că postați ceva pe saitul de pe domeniul B.com și apoi navigați la un alt sait pe domeniul X.net. Acesta din urmă, nu are acces la ”prăjiturelele” pe care navigatorul dvs. le-a primit de la domeniul B.com, însă nici nu are nevoie de ele, deoarece poate face o cerere către domeniul B.com, în timp ce dvs. încărcați una dintre paginile sale, pe domeniul X.net. Deoarece cererea se face direct din navigatorul dvs., și merge direct la domeniul B.com, acesta va include ”prăjiturelele” în anetele cererii. Astfel domeniul B.com este ”păcălit” că dvs. ați inițiat în mod voit cererea, și va proceda la autentificarea și autorizarea ei. Ceea ce conține această cerere este la alegerea atacatorului, și cel mai probabil strâns legată de specificul aplicației de pe domeniul B.com. De la publicarea unui mesaj pe o platformă de socializare până la transferul de bani într-un cont.

Pentru a vă proteja de acest tip de atacuri puteți apela la următoarele tehnici:

  • Folosiți navigatorul în ”mod incognito” (CTRL+Shift+N) pentru a accesa saituri importante. Astfel toate cookie-urile sesiunii sunt șterse la închiderea navigatorului;
  • Dați click be butonul de Logout (Deautentificare) înainte de a părăsi saiturile pe care sunteți autentificat;

XSS: este un acronim pentru de la Cross-Site Scripting și implică posibilitatea de expolatare a unei vulnerabilități într-o aplicație web, astfel încât să afecteze funcționarea respectivei aplicații, sau să permită accesul la informații considerate confidențiale între server și client. Este unul dintre cele mai răspândite tipuri de atacuri, de unde putem deduce că este și una dintre cele mai răspândite vulnerabilități în aplicațiile web.

Un exemplu poate fi o secțiune de comentarii, care permite postarea de comentarii, însă nu reușește să filtreze codul scris în Javascript înainte de afișarea comentariilor. Astfel un comentator poate include cod în Javascript în comentariul său. Când acest comentariu va fi afișat, va fi executat și codul Javascript, pe navigatoarele celor care vizitează pagina. Astfel atacatorul pate redirecționa utilizatorii la o altă pagină sau să afle cookie-urile stocate în navigatoarele lor.

SQL Injection: este un tip de vulnerabilitate ce permite unui atacator să execute cereri directe către un server de baze de date, prin intermediul aplicației web care este autorizată să facă conexiunea.

O sursă foarte răspândita pentru astfel de vulnerabilități ne-sanitizarea parametriilor de intrare (GET și POST) în aplicațiile web. Astfel, un atacator poate executa o cerere SQL special contruită, pentru a accesa sau modifica date care nu sunt accesibile decât aplicației web și utilizatorilor autorizați.

Un exemplu poate fi o pagină care listează profilele utilizatorilor, și oferă o funcție de căutare. Dacă aplicația nu sanitizează parametrii de căutare, un hacker poate insera în parametrii, o cerere specială către baza de date, care să listeze adresele de e-mail ale utilizatorilor sau chiar să schimbe parolele unor utilizatori. Mai multe exemple găsiți aici.

Information disclosure: este un tip de vulnerabilitate care permite aflarea de date confidențiale despre un utilizator sau un serviciu, apelând la servicii similare care stochează date similare pentru a filtra informația.

De exemplu, unele saituri de socializare afișează prietenilor adresa de e-mail și câteva cifre din numărul de telefon. Să presupunem că afișează primele 4 cifre din numărul de telefon. Știind că pe alte saituri, dacă ceri resetarea parolei pentru o adresă de e-mail la ultimul pas se vor afișa ultimele 4 cifre din numărul de telefon… mai rămâne de ghicit o cifră, pentru a afla numărul de telefon al persoanei respective.

Shell upload: o vulnerabilitate care permite încărcarea unui fișier executabil pe serverul ce găzduiește aplicația.

Un exemplu este cea descoperită în scriptul timthumb.php acum 2 ani, care permitea încărcarea unui fișier php pe serverele ce găzduiau acest script. Scriptul în sine este destinat să re-dimensioneze imagini, însă printr-o cerere special contruită acesta putea fi manipulat să salveze local un fișier aflat la pe un alt server.

Zero-Day: termen folosit pentru descrierea anvergurii unei vulnerabilități proaspăt raportate, și înseamnă că este posibil să afecteze milioane de saituri și computere, pe tot globul. Practic  ar trebui să pună toți administratorii din domeniul IT, și mai ales pe cei din domeniul securității pe jar.

Exploit: este rezultatul unui PoC. Un script sau executabil care poate fi folosit ca PoC.

DoS/DDoS: prescurtarea de la Denial of Service respectiv Distributed Denial of Service, este un atac care urmărește oprirea unui serviciu. Diferența dintre DoS și DDoS este că pentru un DoS se folosește o singură mașină sursă, pe când într-un DDoS sunt implicate mai multe mașini în paralel.

Brute-Force/Dictionary Attack: este un tip de atac ce are ca scop aflarea unei parole, sau a unei chei de criptare prin încercări repetate de combinații posibile. Dacă aceste combinații provin dintr-un dicționar (o listă filtrată de combinații pe diverse criterii) atunci este un dictionary attack.

Și lista poate continua… însă cred că pentru moment sunt destule. Totuși doresc să menționez că devine și mai interesant dacă combinăm acești termeni: astfel putem avea o vulnerabilitate buffer overlow DoS, un DDoS dictionary attack, zero-day expoit, information disclosure SQL injection vulnerability ș.a.m.d .

Ce este HTTPS?

Am scris în ultima vreme despre ”scăpările” renumitului protocol https. Acum vin cu un articol explicativ care să vă descrețească frunțile.

Intro (aproape scurt)

HTTPS este protocol care adaugă un nivel de confidențialitate comunicațiior între server și client. De aici și denumirea ”HTTP” – protocolul de facto utilizat de serverele web, și ”S” de la Secure – acel nivel de securitate.

Pentru a înțelege mai bine Facebook folosește HTTP pentru a ”vorbi” cu navigatorul vostru. Dacă dați click pe acest link http://www.facebook.com/ veți fi dus la Facebook.com. HTTP este protocolul, www este subdomeniul (implicit) și facebook.com este domeniul.
Dacă dați click pe acest link ftp://facebook.com/ navigatorul nu va reuși să se conecteze, pentru că serverul facebook.com nu ascultă protocolul ftp. Însă dacă dați click pe https://www.facebook.com vă veți conecta la Facebook.com prin protocolul https.

Și unde-i serverul în toată chestia asta? Dar clientul? (tot pe scurt…)

Păi serverul este un calculator (un fel de) pe care este găzduit domeniul facebook.com . Altfel spus acel calculator, spune la alte calculatoare din internet că el are domeniul facebook.com. Clientul ești tu, adică calculatorul tău, care la cererea navigatorului întreabă cel mai apropiat (teoretic) calculator de tip server din rețea unde se găsește facebook.com. Celelalte calculatoare vor returna o adresă (adresa calculatorului respectiv), iar navigatorul tău, informat în prealabil va trimite toate mesajele către facebook.com la acea adresă.
Acum http://www.facebook.com/home.php este un mesaj către serverul ce găzduiește facebook.com, și cere resursa /home.php prin protocolul http.
Ce returnează serverul e treaba lui, dar dacă navigatorul a înțeles va afișa pagina respectivă. Sau un mesaj de eroare dacă nu a înțeles.

Ce face HTTPS diferit față HTTP?

  • Criptează toate mesajele trimise la server;
  • Rulează implicit pe portul 443;
  • Este (puțin) mai lent;
  • Este validată printr-un certificat;

Ce este un mesaj criptat?
Mesajul meu: mesaj denecriptat
Mesajul meu criptat: Dg0WCA9DDAAHAAAaDBkRAhw= (dau o bere celui care recunoaște algoritmul, știind că cheia este ”cheie” ;) )

Așa cum puteți vedea dacă cineva ar putea vedea sau intercepta mesajele dintre client și server, îi va fi mult mai greu să le înțeleagă atunci când sunt criptate. Sau nu le va înțelege deloc. Și ăsta e practic nivelul de securitate adus de HTTPS, care îți permite să comunici cu un server prin mesaje criptate.

Să înțelegem HTTPS
HTTPS , (TLS practic, protocolul pe care este construit https) folosește două chei pentru a cripta și mai apoi decripta mesajele.
• O cheie publică, pe care o poate vedea oricine se conectează la server prin https. Dar poate fi folosită doar pentru a cripta mesaje.
• O cheie privată, aflată pe server, la care au acces doar administratorii serverului și singura care poate fi folosită pentru a decripta mesajele primite de server.

Așadar criptarea mesajelor are loc pe calculatorul tău, și apoi sunt trimise la server, care le decriptează și dă un răspuns adecvat.
În consecință:
• un administrator al serverului va putea întodeauna să-ți vadă mesajele pentru că el știe cheia pentru a decripta mesajele, dar mai ales pentru că pe server mesajele decriptate deja sunt ținute în jurnale specifice;
• un hacker dacă a reușit să copieze cheia privată de pe server, îți va putea vedea mesajele;
• un program de tip keylogger sau spyware, instalat în calculatorul sau navigatorul tău îți va putea vedea mesajele pentru că are acces la ele înainte de a fi criptate.

HTTPS este viabil doar pentru a transmite mesaje criptate pe un canal nesigur, cum este internetul. Așadar dacă un sait are https, sau l-ai accesat prin https nu înseamnă că este automat un sait sigur și de încredere, că nu propagă viruși, sau că nu are de gând să-ți fure datele personale și numărul de card. Un sait https poate fi la fel de ușor ținta și sursa unor fraude prin sisteme informatice cum este unul care folosește http. Securitatea datelor transmise către un server este doar atât de bună pe cât persoanele implicate în administrarea serverului care găzduiește datele o iau în serios.

Să înțelegem certificatele
Certificatele sunt fișiere pe baza cărora un program specializat generează perechi de chei publice și private, emise și oferite (majoritatea contra-cost) de companii private. Aceste companii administrează și emit propriile certificate rădăcină (root certificate) pe baza cărora pot fi validate toate certificatele pe care le oferă. Funcționând ca o terță parte pentru validarea unei conexiuni https.
Certificatele sunt valabile și se emit pe anumite perioade de timp (între 2 și 5 ani). Așa că un certificat expirat este considerat automat invalid.

Cum știu dacă un certificat este invalid?
Păi asta e destul de evident. Navigatorul meu Chrome afișează ceva de genul:

Chiar dacă mesajul arată ”amenințător” nu este chiar așa. Dacă observați acolo jos mai scrie: ”Vă recomandăm să nu continuaţi, mai ales dacă nu aţi mai văzut niciodată acest avertisment pentru acest site.” . Deci dacă am mai fost pe acest sait și n-am mai văzut așa ceva ar fi bine să nu intru momentan pe sait. Însă dacă știu despre ce este vorba pot să continui liniștit.

De fapt mesajul apare pentru că navigatorul meu nu a putut valida certificatul prezentat de sait cu vreunul din certificatele rădăcină pe care le are instalate. Și cum probabil v-ați gândit, navigatorul meu are doar câteva certificate rădăcină pre-instalate. Evident cel al companiei care a emis certificatul de pe saitul respectiv nu este printre acestea.
Pentru a vedea certificatele rădăcină preinstalate în Chrome, mergeți la Setări și căutați ”ssl”. Va apare un buton ”Gestionați certificatele” pe care dacă dați click va apare o fereastră cu mai multe tab-uri. În tab-ul ”Trusted Root Certification Authorities” veți vedea această listă.

Dacă este invalid certificatul, https-ul e invalid?
Nicidecum. De fapt starea de validitate sau invaliditate a certificatului nu afectează cu nimic conexiunea https. Mesajele transmise sunt criptate în continuare și serverul le va decripta în mod corect. De fapt în unele cazuri chiar folosirea unui certificat invalid este recomandat pentru că https este un canal sigur.
De exemplu dacă am un server de dezvoltare la care se conectează 5 sau 10 persoane și vreau să țin comunicațiile cu serverul securizate pentru a preveni spionajul (industrial sau ocazional), prefer să folosesc o conexiune https chiar fără un certificat valid. Persoanelor care se conectează la server le vor fi criptate mesajele și nu trebuie să îmi fac griji așa mari de locul sau rețeaua din care se conectează.
Desigur pe un server public, la care se conectează vizitatori aleatoriu, va trebui să cumpăr și să folosesc un certificat valid, altfel mesajele emise de navigatoarele lor îi vor face să ignore saitul meu.

Dacă https-ul funcționează de ce arată mesajul acela cu roșu?
Pe un server public pot fi un număr de motive pentru care certificatul să nu mai fie valid, sau să fie revocat. Cum ar fi:
• Administratorii serverului au descoperit o gaură de securitate în recepția mesajelor prin https, și au decis să revoce certificatul până când remediază problema.
• Certificatul a expirat. Certificatele au o durată de valabilitate dintr-un motiv ușor de intuit. Pentru că prin încercări repetate un hacker ar putea găsi cheia privată emisă prin intermediul certificatului. Fără să fie nevoit să acceseze serverul care a emis-o. Această tehnică este numită și BF sau Brute Force Attack. În consecință un certificat expirat are șanse mai mari să fie deja compromis.
• Certificatul a fost înlocuit de către o persoană neautorizată. Și toate mesajele transmise folosind noul certificat invalid, vor putea fi decriptate de persoana în cauză. Care sigur poate fi un hacker, sau vecinul de la etaj care și-a lăsat wireless-ul fără parolă :P .

Iar navigatorul ia cel mai nefavorabil scenariu în considerare. De aceea și zice ””Vă recomandăm să nu continuaţi, mai ales dacă nu aţi mai văzut niciodată acest avertisment pentru acest site.” Așadar dacă nu ai mai văzut așa ceva probabil e stricat.

Codul culorilor


  • Conexiunea la www.encrypted.com este securizate prin https, însă certificatul nu prezintă garanție.


  • Conexiunea la www.encrypted.com este securizată prin https și certificatul prezintă garanție. Însă pe pagină sunt elemente incluse folosind http sau alte conexiuni nesigure. Știu că e mai complicat dar pentru a afișa o pagină web, navigatorul trimite mai multe mesaje pentru diverse imagini și fișiere incluse în pagină. Unele dintre acestea pot fi incluse prin alte protocoale decât cel folosit inițial de pagină.

  • Conexiunea la www.encrypted.com este securizată prin https și certificatul prezintă garanție.

  • Conexiunea la www.encrypted.com este securizată prin https și certificatul prezintă garanție. În plus se specifică compania PayPal Inc. ca responsabilă de domeniul encrypted.com.

Dacă ar fi să aleg pe care dintre aceste variante aș transmite date și informații confidențiale, aș alege doar ultimele două.

Să păcălim https!
Sunt câteva vulnerabilități demonstrate în ultima vreme ale protocolului. Majoritatea au efect pe partea de client. Dar este una foarte interesantă pe care o puteți încerca și voi, așa de curiozitate.
Dacă nu știați pentru a stabili valabilitatea unui certificat, navigatorul compară data la care expiră certificatul cu data sistemului pe care rulează. Dar, nu numai data de expirare ci și data la care a fost emis! Așadar dacă pun data calculatorului meu cu 5 ani în urmă toate certificatele emise ”în viitor” vor fi marcate ca invalide. Puteți face asta pe calculatorul unui prieten și apoi să-i explicați frumos că i-ați furat datele de card. Bine da nu faceți asta chiar de ziua lui! Mai bine de 1 Aprilie.

Concluzie
Protocolul https nu garantează că datele transmise sunt în siguranță, acesta ține datele în siguranță doar pe timpul transmisiei. Certificatele indică ”starea de sănătate” a unei conexiuni https prin validarea respectivului certificat asupra unui certificat ”rădăcină” emis de o companie terță. Oricum o conexiune cu un certificat invalid este fi la fel de sigură ca una cu certificat valid. Securitatea datelor trimise și primite însă depinde de securitatea individuală a clientului și a serverului.

Acest articol are un scop pur educațional. Orice referințe la companii sau produse reale este din pură coincidență.

Yours truly – security advisor.

Securitatea HTTPS, avem sau n-avem?

HTTPS este un protocol foarte cunoscut și totodată foarte utilizat. Traficul cu serverul este criptat, așa că se elimină  posibilitatea unui atac man-in-the-middle.  Până aici toate bune, practic cu o conexiune https putem fi siguri că parola noastră este ascunsă. Însă, și aici este un mare ”însă”, sesiunile și identificatorii lor sunt stocate ușor ”la vedere”, în cookie-uri. Adică folosind un script malițios și câteva șmecherii pentru a păcăli navigatorul un atacator le-ar putea extrage, și fără să știe datele de autentificare să obțină acces la contul utilizatorului, în care tocmai s-a autentificat.

Desigur ca să reușească atacul, inițiatorul trebuie să aibă câțiva ași în mânecă: să fie bine plasat în rețea pentru a putea ”asculta” cererile sau să aibă control asupra proxy-ului prin care trece traficul.

Prima dată s-a discutat de BEAST, care exploata o vulnerabilitate cunoscută a TLS, însă clasificată ca ”teoretică”. Acum discutăm de CRIME, care exploatează de data aceasta direct navigatorul utilizatorului. Și desigur dacă serverul urmărit are și el câteva scăpări deschide mai multe posibilități.

Ca utilizator, te poți proteja de aceste tentative prin folosirea unui navigator actualizat la zi (personal recomand Firefox sau Chrome) în modul privat sau incognito (CTRL+SHIFT+N – pe Chrome), prin conectarea la rețele de încredere (nb. evitați cele ”de cartier”), și desigur printr-un antivirus actualizat și ce are și module de scanare a traficului prin rețea. Nu știu cât protejează ultima opțiune dar în cazul în care vă conectați la o rețea ne-securizată, acesta din urmă ar trebui să fie primul care vă atenționează.