Budapesten nagy sávszélesség: ESXi backup visszaállításához

Hálózatok általános

Sziasztok,

Egyik ismerősöm ESXi megoldása egy bérszerveren a Rackforestnél megpurcant és vissza kellene állítania 2 tera disk backupot.

Van ötletetek, hogy hol lehetne? Lakossági internettel picit lassú, Rackforestnél pedig nincs lehetőség bemenni és helyi hálózaton felmásolni egy új hostra az adatokat. :(

Update: support tud lehetőséget adni arra, hogy be lehessen menni – félretájékoztatást történt.

(Nem túl viccess a sztori: valami Ransomware pusztíthatott régi ESXi verzió miatt)

  • 1301 megtekintés

( mauzi v | 2023. 02. 12., v – 14:59 )

Rackforestnél pedig nincs lehetőség bemenni és helyi hálózaton felmásolni egy új hostra az adatokat.

Ezt ők mondták, vagy Te gondolod így? Eléggé rugalmasak szoktak lenni, pláne, ha baj van.

Engem az érdekelne, hogy a ransomware hogyan tudta elérni az ESXi menedzsment interfészét. Ugyanabban a VLAN-ban volt az ESXi menedzsment, mint valamelyik virtuális gép, amit megtörtek?

Eléggé rugalmasak szoktak lenni, pláne, ha baj van.

Ez gondolom valami régi tapasztalat lehet, mert mostanában ezt már nem így tapasztaltam én sem, sajnos. :( De már az utolsó saját gép elköltöztetése is folyamatban van... 

https://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Gonosz leszek: Mi szerepel a BCP, DRP tervekben? Mekkora az RPO / RTO? Azok miért nem alkalmazhatóak? Esetleg ezek sose léteztek, sose lettek tesztelve? Akkor ÍJ.

Ha csak kicsit is számolgatok, akkor ide minimum 10-25 Gb/s-s vagy gyorsabb kapcsolat kellene a "gyors" helyreállításhoz. Persze definiáljuk először, hogy mit értünk gyors alatt. Ha a backup egy SATA lemezen van, amiről tudunk olvasni 100-200 MB-tal, akkor annak kell a min. 1 Gb/s, de inkább a 10 Gb/s. Ha a backup egy SSD-n vagy storage-on van, akkor az reggelire megeszi a 10 Gb-t. Egy ilyen gyors kapcsolat még rövid időtávra bérelve is piszok drága.

Javaslat a gyors helyreállításra:
1. Fogtok egy PC-t, amibe betehető ez a backup lemez. Legyen a gépre telepítve valami OS, ami látja ezt a backup lemezt. A gépben legyen 10 vagy 25 Gb-s Ethernet kártya.
2. Beviszitek ezt a gépet a Rackforesthez. Kifizettek 1-2 hónap hosting díjat. Internet nem kell, elég ha remote konzolról eléritek, illetve ez a gép eléri a bérelt hostot. Természetesen nem 1 Gb, hanem 10 vagy 25-s Ethernet kapcsolattal kéritek.
3. Elindítjátok ezt a backup hostot és a remote konzolon dolgozva áttöltitek az adatokat a bérelt hostra.
4. 1-2 hónap múlva (a kifizetett hosting díj után) elhozzátok ezt a PC-t a Rackforesttől. Későbbiekben megtartjátok BCP/DRP esetre.

Természetesen ez a gyors helyreállítási javaslat csak egy vázlat, itt-ott át kell(het) gondolni. Továbbá a Rackforesttel is egyeztetni, hogy ez vállalható-e nekik. Elvileg ők ezen sem biztonságilag, sem anyagilag nem buknak.

A rövidéteseket sem ismerik sajnos azon a szinten, ami hostról dumálunk. Pár webshop / étterem rendszer állt csak meg. Egy komolyan vehető DRP-t az ő pénztárcájuk nem bírna el. :(

Ettől függetlenül amit mondasz az teljesen jó ötlet. A baj csak az, hogy vasárnap nem állítanak be szervert, főleg ha csak 1-2 hónapra fogod a helyét bérelni.

Értelek és megértelek.
Viszont a DRP nem csak az ügyfél érdeke lehet, hanem a szolgáltatóé is. Ha kevesebb rendszergazdával akarja lefedni a szolgáltatást és/vagy szeretne kisimult homlokú rendszergazdákat látni, akkor össze kell rakni egy ilyen DRP-t. Nem hiszem, hogy 1 napnyi gondolkodással nem lehet valamit összekalapálni, ami működik / működhet.
Az RTO / RPO már egy másik kérdés. Ott az ügyfélből kell kipréselni, hogy mit fizet ki. Ha 10 Ft-t szán rá, akkor ennek következményeit közölni kell az ügyféllel. Legyél védve papírral.

Az ügyfelek tisztában vannak szerencsére ezzel, senki sem veri az asztalt / nem is lenne mire, hiszen semmilyen vállalás nincs szerződés szinten.

Azt kell látni, hogy mi egy elég nagy “buborékban” vagyunk és nem is szolgálunk ki olyan ügyfeleket, ahol az SLA / szolgáltatás nem alap elvárás. Tökre jogos amit írsz, hogy elkerülhető lett volna. Sőt valószínűleg ha legfrissebb ESXi lett volna, akkor meg se történt volna az eset - de ugye az alkalmazás felügyeletet se tudják kiköhögni ezen ügyfelek sokszor, nem hogy a sysadminokat :(

Szóval csak azt akartam mondani, hogy még azután se fognak ezen ügyfelek váltani ha már egyszer megégették magukat.

Engem az érdekelne, hogy a ransomware hogyan tudta elérni az ESXi menedzsment interfészét. Ugyanabban a VLAN-ban volt az ESXi menedzsment, mint valamelyik virtuális gép, amit megtörtek?

Ez érdekel nagyon engem is. Van még egy olyan lehetőség is, hogy az ESXi publikus IP-n elérhető... Egyszerű, kényelmes megoldás, egyben óriási biztonsági kockázat. Remélem kapunk választ.

( arpi_esp v | 2023. 02. 12., v – 18:46 )

keressen valakit gigas optikai lakossagi nettel (telekom, digi) es azon felmegy percek alatt :)

vagy be kell vinni valami iskolaba/egyetemre, par doboz sorert biztos feltolti valaki :)

( nabil | 2023. 02. 12., v – 19:24 )

Kérlek nyiss ticketet nálunk (RackForest) és megoldjuk valahogy.

( nabil | 2023. 02. 12., v – 20:17 )

Több ügyfélnél is ez van most ami neked is van. behozzák a gépeket és onnan másolnak. hozd be te is és ott másolj csak nyiss egy ticketet vagy hívj fel minket.

Jahogy itt a HUP-on kell nekiállni picsogni és akkor történik is valami érdemben? :)

Akkor itt kérdezem meg, hogy a 2 éve teljes mértékben változatlan beállítással hostingon levő gépem management kártyája vajon hogy a fenébe kapott meg egy publikus IP címet???

https://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Van ticket, amire február 7-i válaszom óta, azaz 5 napja nem kaptam reagálást. Sőt, olyannyira tudnak róla, hogy hétfőn letiltották azt a switch portot amin a gép volt, _miközben_ a supportosnak a telefonon mondtam, hogy a tcpdump szerint nem használjuk azt az ismeretlen IP címet (kb. 20 xen guest van azon a fizikai gépen).  Csak azt az egy hibát ismerték el, hogy a telefonközpontjukban lehetett valami szoftveres probléma, ami miatt egy technikushoz való átkapcsoláskor 20 perces várakozást kaptam jutalmul a switch port letiltás reklamációmért :)  Végül kiderült, hogy a management kártya kapta azt a publikus IP címet amit kerestek rajtam illegális használatként, de arra már nem kapok érdemi választ, hogy ez hogyan fordulhatott elő csak úgy "magától" hétfő dél tájékán, és miért nem tudom elérni a management kártyát amióta dhcp helyett fixen be van állítva az általuk megadott localnetes IP cím (pontosan ugyan az, amin előtte rendesen működött a management elérés)... 

https://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Egy Intel Server Board S2600GZ alaplapon gyárilag levő "Integrated BMC with IPMI", ami fizikailag külön LAN kábellel csatlakozik a management VLAN-hoz. A gyári beállítása DHCP-n van, és miután egyszer egy ottani rendszermérnök azt írta az egyik szerver elhelyezésekor, hogy maradhat így majd beállítják és így is volt. Gondolom MAC alapján kapta meg eddig azt a címet, amit 2 éve rendszeresen használtam és működött.

https://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

( gabrielakos v | 2023. 02. 13., h – 11:21 )

Konkrétan a problémán nem segít de szerintem akinek gyalulták az esxi-jét az lehet nem jár rosszul ha megnézi a proxmoxot.
Én anno több mint tíz éve megnéztem (az akkori) virtualizációs lehetőségeket kkv-számára:
kb. proxmox, virtualbox, vmware esxi voltak a versenyzők.

A proxmox nyert (3.x verzió). Azóta se bántam meg.
A VM-ekkel (amit az esxi nyújt) sose volt semmi bajom. PMG, PBS azóta "kinőtt" megoldások egyenesen zseniálisak.
Konténerizációval időnként lehet szívni de ha óvatosan upgradel az ember akkor nem éri kínos meglepetés.
 

zászló, zászló, szív

Azért proxmoxnak is volt problémája, nálam 20+ hosztból álló cluster van, 5 és 6-os verzión hajlamos volt random lehalni a cluster (corosync és pmxcfs, főleg a 23. hoszt csatlakozása után), ami aztán packet stormot okozott (self DDOS), és proxmox fórumokon is azt írták hogy az a megoldás rá, ha udp 5405-re rakunk egy iptables rate limitet az outgoing packetekre. Szerencsére a 7-es verzió óta nem láttam ilyen problémát, úgy tűnik javították.

Ettől függetlenül elégedett vagyok a proxmox használatával, főleg mivel debian linuxra épül, sokkal egyszerűbb beletákolni egyedi funkciókat vagy scripteket mint egy zárt esxi rendszerbe. Én szeretek benézni a motorháztető alá :)

Mert ha az esxi-nek legalább a saját beépített tűzfalát nem használta (de még csak véletlenül sem arra akarok célozni, hogy azzal úgy rendben lenne a megoldás), akkor gondolod a Proxmoxban majd kezét-lábát törve nyomta volna a hardeninget?

Abban egyetértek, hogy sufni megoldással üzemeltetett (1 node, co-loc. hostingon, 1db public IP-vel, internetre lógatva, mindenféle frontend tűzfal nélkül) a Proxmoxnak jobb esélyei lehetnek mint egy ESXi-nek. Hiszen egy stock Debian van alatta, a hostra így akár vpn service is telepíthető, illetve a fail2ban-tól kezdve végtelen mennyiségű védekezési lehetőség, valamint az update folyamat is egyszerűbb. De azért ehhez tenni is kell, nem csak úgy magától lesz biztonságosabb.

( ncc1701 | 2023. 02. 13., h – 11:44 )

Esxi management felületet direktben el lehetett érni a netről, vagy hogyan történt ez?

Igen, ráadásul 2021 év eleji vulnerabilityt használ a ransomware, amit akkor a vmware patchelt is, de még workaroundra is volt/van KB.

De már eleve az meredek, hogy elérhető a management az internet felől. De az is csodaszámba megy, hogy 2 év után csak most jutott eszébe erre valakiknek automatizált/botnet alapú ransomwaret írni.

Az Open SLP-ben volt bug anno, nem csak a Vmwaret érintette, csak benne van/volt az ESXi-ben is. Ezért sem mennek most nagyon bele VMware oldalon, hogy advisory-t adjanak ki, meg mindenféle bejelentést tegyenek. Ezen már túl vannak 2 éve, ahogy mindenki más is aki slpd-t használt a termékében. Kb. az a mondás, hogy frissíts a latest-re, ugyanis nem ez volt az egyetlen CVE 2021 óta, az tulképpen mellékes, hogy ez a ransomware mit használ, ha az nem 0day. Holnap jöhet helyette új, ami meg egy másik, 1 éves sérülékenységet használ ki.

Nem értem, a kérdés szerintem egyértelmű volt. Ki volt-e publikálva a webes felületen más is az internet felé?

Az openslp tcp/udp 427-en fut vmware-nél. Ha az nem volt elérhető kivülről, akkor nem igy törték meg őket, mert nem a webes felületen volt a hiba. (ha belülről a vm-ek irányából elérhető volt, akkor pl. úgy)

Nekem mondjuk mindegy, évekkel korábban kidobtuk az összes vmware-t is a cégeknél, csak kiváncsi vagyok ebben az esetben hogy történt a törés.

Nincs semmiféle "publikálás", user telepít egy esxi-t, állít rajta egy vmkernel interfacet, annak beállítja a szolgáltatótól kapott public címet, és ennyi. Minden szolgáltatás elérhető rajta bárki számára bárhol a világon, ami fut, és a management networkben kellene hogy elérhető legyen (mert hát ezért futnak ugye). Nincs tűzfal, amin véletlenül be volt forwardolva xy port az esxi felé aminek nem kellett volna, direktben publikus hálózatra kötött esxi-kről van szó. Az egyik ilyen szolgáltatásban volt egy 2 éve befoltozott bug, ehhez készétettek most egy ajándékot valakik, és scannelték le az egész internetet + encryptálták le az így kirakott esxi-ket.

( tibyke | 2023. 02. 13., h – 12:26 )

Szerkesztve: 2023. 02. 13., h – 12:26

arra vigyazz, hogy nem *gyors* savszelesseg, hanem *nagy*.

ami gyors lehet, az a vonat :)