Fórumok
Állítólag az internetes szolgáltatás 70%-a lebénult.
Bővebben itt (Google fordítóval): https://www-rainews-it.translate.goog/articoli/2023/02/agenzia-per-la-c…
A cikk szerint a foltozatlan VMware ESXi a fő célpont.
A legcsúnyább VMware ESXi sérülékenységek és érintett verziók a linkben:
https://www.cvedetails.com/cve/CVE-2020-3992/ - 10/10
https://www.cvedetails.com/cve/CVE-2020-4005/ - 7.2
https://www.cvedetails.com/cve/CVE-2021-21994/ - 6.8
https://www.cvedetails.com/cve/CVE-2021-22045/ - 6.9
Amely rendszer érintett, javasolt foltozni.
Újabb részletek (február 6.):
https://www-rainews-it.translate.goog/articoli/2023/02/cybersicurezza-a…
Hozzászólások
Bár nagyvállalati/állami méretben nem lehet gond, de 1-1 gépes esxi esetén szerintem vastagon benne van a nevetséges/nem létező updatelhetőség.
Nemhogy automatizáltan nem tud frissülni, de még egy gomb sincs a felületén, hogy na akkor most keressük update-et és tegyük fel. Konzolon kell bohóckodni, vagy lokálisan telepitő médiával upgradelni. Röhej.
Nyilván azért, hogy a sok hülye vegyen vcenter-t hozzá. Meglátjuk melyik hoz több bevételt, most sokan fogják hallani a vmware és ransomware szókapcsolatot.
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.esxi.upgrade.doc/GUID-A4301ADA-8E02-459D-BF9D-0AD308DA5325.html
Szívesen!
Köszi szépen!
Azért bedobnád ide az egysoros fix parancsot amit bedobok a cron jobba és megoldja a dolgot?
Mert én csak olyat találok, hogy tölsük le az xml-t a depo-ból, kézzel keressük ki belőle azt a verziót amit szeretnénk (ha ugye gyártói image-et használunk, akkor a megfelelőt) és azt etessük meg vele. (az, hogy a hivatalos depo url-je sincs itt, az már tényleg a legalja)
Ha rosszat választasz, akkor igy jártál.
Bocs, de ez nekem nem a használható update 2023-ban, inkább viccnek tűnik.
Ha lenne egy parancs, ami automatikusan felmegy, letölti az adott géphez megfelelő utolsó patchelt verziót és felrakja, azzal semmi gondom nem lenne.
De nem baj, én vagyok a hülye, tökéletesen van megtervezve és kivitelezve az update metódus, látjuk az eredményét.
Elég meredeken hangzik éles szervert cronjob alapján, automatizáltan frissíteni.
Mégis csinálják. Lásd: Cpanel. Továbbá ilyenkor mi a rollback plan? Ki és hogyan fogja tudni azt végrehajtani?
Amikor egyszer egy cégnél eszmecserét folytattam az ottani IT vezetővel (kkv), akkor ő azzal söpörte le az érveket: "Eddig még nem volt gond ebből. Naponta lefut a script, a Cpanel egy széles körben használt termék, alaposan letesztelik."
Én nem győzködtem tovább. Aztán egyszer beütött a krach, volt fejvakarás.
Ha belefér, évente egy-két óra szolgáltatás kiesés egy elcsesződött patch miatt , akkor a logikusabb és olcsóbb választás az automata patchelés, mint az "élő erős".
Security patchek garantáltan a leggyorsabban kikerülnek ha cronból fut a patchelés...
Itt https://hup.hu/comment/2883814#comment-2883814 tessék kopogtatni :)
Nem a cronjob volt a lényeg, hanem, hogy van-e egy fix parancs, ami megoldja a frissitést az utolsó, adott gépre való image-re.
Úgy tűnik mégsincs...
A vcenter és a lifecycle manager ingyenes, ha meg az ember pénzt keres vele akkor meg kell vennie az OS-t, kell legalább 2+1 vas és valami DAS/SAN.
Semmi mást nem vinnék sehova, csak vmware megoldást. Semmi mást nem fizetnek ki a plusz üzemeltetési órákat, ingyen meg dolgozzon magának a megrendelő.
Most látom, ingyenes a vcenter? Ezt nem tudtam. Azt hittem, csak az esxi ingyenes.
De komolyan, hogyan ingyenes?
Bemegyek ide, a vmware id-mmal:
https://customerconnect.vmware.com/en/downloads/details?downloadGroup=V…
De azt irja:
"You either are not entitled or do not have permissions to download this product.
Check with your My VMware Super User, Procurement Contact or Administrator.
If you recently purchased this product through VMware Store or through a third-party, try downloading later."
60 napos trialt engedne csak letölteni.
Jah, én is csak lesek hogy mióta ingyenes a vcenter, mikor az az "intelligencia" a buta esxi-k fölött. A kapudrog az esxi, hogy utána a rendes menedzsement eszközt már csak heroinárban kapd meg. Legalabbis mikor esxi4 környékén foglalkoztam vele (expertje sosem voltam, nem szégyellem leírni), akkor még így volt.
Egy proxmox több órát igényelne üzemeltetésben?
Ezt akartam én is írni. Ingyenes kategóriában a szvsz messze a proxmox a legjobb szinte minden szempontból.
Méghogy ingyenesben milyen jó! De lehet akár támogatásért fizetni is, ha valaki (pl. a szoftvert használni szándékozó cég menedzsere) tuti biztosra akar menni. Szóval nem lehet olyan egyszerűen elvetni menedzsment szinten sem, hogy nem áll mögötte senki, nem bízunk benne, szó sem lehet róla.
Ha szeretnél hozzá supportot, akkor egy 3 node-os, HA képes VMware szett áráért (legutóbb a 6.5 újkorában néztem, olyan 5500 USD körül volt) kb. hozzád is költöztetnek egy support mérnököt... A nagy nevű licencelt termékeknél meg ugye a használati jogot kapod a nagy pénzért, és annál jóval nagyobb pénz a saját ember certifikálás és/vagy gyári support igénybe vétele.
Én azt mondom, a hazai kis- és középvállalatok a licenc árát inkább költsék szakemberre (az a drága termék mellé is kellene, csak nem marad rá).
Egy ingyenes dolog esetében ezt firtatni eléggé érdekes.
Fogod a CLI-s frissítést (amúgy nem tudom, ez miért hátrány, hogy CLI-ből lehet frissíteni, szerintem előny), berakon cron jobba és kész az automatikus update.
Mi az, hogy nem létezik az updatelhetőség?
lásd fentebb: https://hup.hu/comment/2883849#comment-2883849
Az meg, hogy ingyenes, nem menti fel. Az ingyenes hyper-v server-nek is 100x kulturáltabb update metódusa van.
Újraindítás minden kicseszett update után a Windowsból kiindulva? Kulturált XD
És ez miért is probléma? Hyper-V-t is clusterben illik üzemeltetni. Nincs semmi gond, ha 1 node ebből maintenance módban van (patchelés, reboot).
Persze ha az ügyfél és/vagy az üzemeltetés balfasz...
Évi 1 milliós (pár éve még 0 huf volt, de előre megyünk nem hátra) IT budgetemmel ez nem érint. :)
Felőlem az is lehet, hogy az ESXi vackot is minden patchnél restartolni kell :)
Vmware-en is újrainditás kell sok patch-hez.
De nem ez a lényeg.
Kétféle rendszer van: Az egyiknél megengedhető a tervezett pár perces leállás egy újrainditáshoz, mert pl. este nem dolgoznak. Itt tökmindegy, hogy újrainditás kell, oda időzited, amikor nem használják a userek.
A másiknál nem engedhető meg, mert mindig használják. Nos, ott klaszter kell, akár vmware, akár hyperv, akár bármi. Az egyik node restartol, a többi node kiszolgál.
Ilyen egyszerű. Olyan rendszer nincs (legalábbis épeszű ember által üzemeltetve) hogy nem engedhető meg a tervezett leállás, de egyetlen nyamvadt szerveren fut a kóceráj és összecsinálod magad, mert egy patcheléshez restartolni kell. Ott nem a rendszer a hülye.
Reméltem, hogy a CVE linkekben a 2020 nem azt jelenti, hogy azóta benne van... de. A 10/10-es 2022-06-15-on még benne volt, gratula. Fél éve frissített rendszerben is lehet ilyen:
- Integrity Impact: Complete
- Access Complexity: Low
- Authentication: Not required
Hát nem alszom nyugodtan, bár nincs ilyen rendszerhez közöm.
A 10/10-es leírásánál ott van, hogy konkrétan melyik verziók előttiek érintettek csak: 7.0 before ESXi_7.0.1-0.0.16850804, 6.7 before ESXi670-202010401-SG, 6.5 before ESXi650-202010401-SG
Azaz már régóta javítva van.
Javítva van a gyártónál, de hiába ha rengeteg szerverre nincs feltelepítve. És az olaszoknál (és sok más országban) is ez a probléma.
Ugyanez bármelyik Windows Serverre, KVM-es Linux szerverre is fennállna.
Ez Linux, vagy Windows alapú rendszer?
"https://hunvagyok.hu "
Debian asszem...
Az az ESX volt, ESXi már nem használ linux kernelt.
BareMetal-ra (csak a vas maga) telepíthető hypervisor, ami más OS-eket tud "futtatni". Tipikusan nagyobb gép, több OS, OS ügyfeleknek, OS külön szolgáltatásra.
Egyik se. Saját OS Type-1 típusú virtualizációra.
https://en.wikipedia.org/wiki/VMware_ESXi
Linuxra épült, aztán addig gyúrták, hogy saját kernelt raktak alá, de erősen hajaz rá. És azóta is elő-előfordulnak perek ellenük, hogy linux kódot használ kód megnyitása nélkül.
Lehet jobban jártak volna az olasz illetékesek, ha maradnak simán egy sztenderd Linux host-nál, azt frissítgették volna rendesen, ilyen súlyos sebezhetőség nem fordult volna elő. Gondolom ha rendesen frissítik az esxi-t, akkor se, de úgy néz ki, hogy valamiért nem tudják abszolválni a frissítést. Nem tudom, hogy ez most lustaság volt a részükről, vagy valami ósdi szutykok miatt ragadtak rég verzión, de az a 70%-os leállás nagyon durva, olyan károkat még a Wannacry se okozott.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Fú, ha Magyarországon történt volna ilyen...
De hát ez a Fejlett Nyugat.
CHS?
Biztos vagyok, hogy nem csak ők, de még nem szellőztette meg a média, csak egy topikban felmerült.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Nagy szerencse, hogy a másik topikban megtudtuk, hogy a VMWare mennyire secure.
Pontosan annyira secure amennyire a benne található GPL kódok és komponensek és amennyire jó az infrastruktúra alatta.
https://www.cvedetails.com/cve/CVE-2020-3992/ - 10/10
" who has access to port 427 on an ESXi machine" ... a management networknek nagyon máshol kell lennie mint clickhere cucika ikszpéje.
https://www.cvedetails.com/cve/CVE-2020-4005/ - 7.2
" privilege-escalation vulnerability " ... ismét csak az üzemeltetőnek legyen joga a rendszeren, csoportalapon, stb.
https://www.cvedetails.com/cve/CVE-2021-21994/ - 6.8
" network access to port 5989 on ESXi "ua. Az ESXI managementnek is egy szeparált vlan kell.
https://www.cvedetails.com/cve/CVE-2021-22045/ - 6.9
" vulnerability in CD-ROM device emulation "
ez is egy privilegizált user kérdés, nyílván aki VM-et módosít, telepít, azt nem azzal a userral végzi amivel éppen a netezik.
Mindegyik hibában van csúnyaság, de egy minimálisan alapos tervezéssel egyik se jelenthetne gondot, amellett, hogy ezek kurva régi CVE-k, aki így hagyta a rendszert azt az életből is kitiltanám.
Én tudom, meg frissíthető, frissítendő, csak a másik topikban eléggé kategórikusan leszolódott a Hyper-V. Eközben a VMWare-nél sem pont a VMWare volt gyengus ezek szerint, hanem konfig volt igen bátor. :)
CVE-2020-3992: https://www.vmware.com/security/advisories/VMSA-2020-0023.html itt a fix hozzá
CVE-2020-4005: https://www.vmware.com/security/advisories/VMSA-2020-0026.html itt a fix hozzá
CVE-2021-21994: https://www.vmware.com/security/advisories/VMSA-2021-0014.html itt a fix hozzá
CVE-2021-22045: https://www.vmware.com/security/advisories/VMSA-2022-0001.html itt a fix hozzá
Nagyon régi verziókról van szó, nem arról, hogy a Vmware hagyta az ismert biztonsági hibákat. Hanem arról, hogy az okos üzemeltetés baszott rá.
Én azt gondolom, hogy egy sokkal messzebbről nézendő probléma a gyökere az ilyen eseteknek, amikor is van a hibára javítás, de nem kerül fel a gépekre. Szerintem egyáltalán nem egy általános, minden IT szakemberre kiterjedő sledriánság/lustaság az oka.
Én úgy látom, hogy az üzleti világ nagy része menthetetlenül a Windows-on lóg. A Windows pedig ugye simán tudja, hogy egy nem-funkcióbővítő, nem-javító hanem sima biztonsági patch után meghal és lehet fejet vakarni (az ennél bővebb tartalmú patch-ekről ne is beszéljünk), hogy mi legyen. Emiatt aztán minden kisebb-nagyobb cégnél halogatják a frissítéseket (persze nem úgy, hogy simán nem teszik fel, hanem úgy, hogy azt mondját, tesztelik éles bevezetés előtt - csak ez a teszt örökké tart, így addig hivatalosan is odaázható az esetleges frissítés miatti szopás). És ez a gyakorlat olyan általános, hogy az összes többi rendszer sem frissül, aminél ilyen frissítés utáni elhalálozási gond nincs - fura is lenne, ha csak a Windows frissítéseket kellene hosszan tesztelni, a többi mehetne fel gondolkodás nélkül...
Én csak azt nem értem, hogy miért kell a netről elérhetővé tenni a VMware rendszereket? Ha pedig csak belső hálózatról érhetőek el, akkor hogyan kapják be a kártevőket?
mondjuk egy olyan belso geprol ami eleri... azon megnyit pistike egy virusos emailt ami vegscanneli a halot es megprobal mindent megfertozni. altalaban igy mukodnek ezek...