Etichetă: server

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

Testează mailurile de pe local cu Mandrill

De câte ori ați pățit să vreți să trimiteți un mail de pe local (http://localhost/) sau dintr-o mașină virtuală în care dezvoltați o aplicație și să nu reușiți să-i dați de cap serverului de mail: ba nu e instalat, ba nu se poate conecta pe portul x sau configurarea lui e o aventură.

Personal evit să instalez pe computerul personal orice program care ar putea deschide și asculta pe porturi standard. Asta include servere http, servere de mail sau de ftp. Dacă am nevoie de un mediu de dezvoltare și testare a aplicațiilor PHP  folosesc o mașină virtuală și VMWare Player își face treaba destul de bine.

Un inconvenient este că adresele IP alocate mașinilor virtuale sunt aleatorii, însă pentru asta puteți modifica default-lease-time și max-lease-time în C:ProgramDataVMwarevmnetdhcp.conf (calea pe Windows Vista / 7) la o valoare mai mare.
De exemplu: default-lease-time 10368000; setează timpul implicit de expirare a adreselor IP la 4 luni.

Acum revenind la problema trimisului de mail de pe local, soluția e un server de mail aflat la distanță – preferabil unul de smtp și gratuit. Iar soluția e Mandrill un serviciu lansat de băieții care au făcut și MailChimp, care te lasă să trimiți până la 12k de mailuri pe lună gratuit. Și pe deasupra oferă și SMTP, chiar cu SSL dacă e nevoie.

Pentru a accesa serviciul trebuie să vă înregistrați pe MailChimp mai întâi, deoarece serviciul permite autentificarea doar prin contul de MailChimp. Iar informațiile de autentificare la SMTP le aflați din Setări:

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.

Motoare de template-uri în Javascript

Zilele astea, mai mult de nevoie dar și de curiozitate am căutat un motor de template-uri în javascript. Probabil mulți sunteți familiarizat cu template engine-uri în PHP, cum e Smarty de exemplu. Eh, trebuie să vă spun că niciodată nu mi-au plăcut template engine-urile pentru PHP de vreme ce PHP însăși e un astfel de motor ;) .

Dar template engine-urile în Javascript chiar încep să îmi placă. De ce?

Desigur nu sunt o alegere viabilă pentru un sait pe internet, care trebuie să aibă link-uri către pagini individuale pe care motoarele de căutare să le poată parsa, de vreme ce motoarele de căutare nu înțeleg  javascript. Da googlebot știe să citească și PDF-uri sau SWF-uri dar javascript nu.

Însă cred că sunt cea mai bună alegere pentru un sait într-un intranet, sau unul cu acces limitat la conturi (utilizator/parolă).   Asta pentru că un astfel de engine îți permite să iei doar datele de care are nevoie clientul de pe server, nu și markup-ul iar template-ul să-l iei dintr-un fișier static în timp ce prelucrarea lui și înlocuirea variabilelor se face pe mașina clientului, care e foarte probabil să aibă mai mulți RAMi disponibili decât serverul tău. Și tu ca programator nu mai trebuie să înveți Smarty dacă știi deja PHP/JavaScript.

Partea cea mai bună e că aveți de unde alege, iar unul dintre inițiatorii curentului este chiar John Resig :

Desigur lista ar putea continua, dar acestea sunt cele pe care le iau eu în considerare bazate pe caracteristicile de compilare și caching. Dar sunt curios ce preferințe aveți și voi?