Hamis merevlemez vásárlása – miért kerüld el? – 2. rész

Az első részben már bemutattuk a hamis merevlemez vásárlásának piaci, alapvető kockázatait és a leggyakoribb csalási módszereket. Most, a második részben mélyebbre ásunk a technikai részletekbe, és konkrét ellenőrzési módszereket mutatunk be, amelyekkel IT szakemberként és döntéshozóként képes leszel azonosítani a manipulált vagy problémás enterprise tárolókat, mielőtt azok a kritikus rendszereidbe kerülnének.

Technikai ellenőrzési módszertan

A használt merevlemez beszerzés során alkalmazott technikai ellenőrzések három fő területre koncentrálódnak. Ezek közé tartozik a SMART adatok integritásának vizsgálata, amely feltárhatja a manipulált üzemóra-adatokat és a kriptobányász eredetből származó extrém terhelési nyomokat. A második kritikus terület a firmware verzió ellenőrzése, különös tekintettel a problémás storage-specifikus verziókra, amelyek enterprise környezetből származhatnak. A harmadik alapvető ellenőrzési pont pedig a fizikai szektorméret vizsgálata, mivel az enterprise 520 byte-os szektorok komoly kompatibilitási problémákat okozhatnak.

SMART adatok manipulációja?

A hamis merevlemez kereskedők legrafináltabb módszere a SMART értékek szisztematikus manipulációja. Az első részben már említettük az üzemóra számláló nullázásának problémáját, most azonban konkrét detektálási módszereket is bemutatunk. A Seagate merevlemezek esetében a SeaTools diagnosztikai szoftver képes alternatív üzemóra forrásokat is lekérdezni, amelyek gyakran ellentmondanak a főszámlálónak.

Üzemóra manipuláció

A SMART tesztek futtatásakor a merevlemez tárolja, hogy hanyadik üzemórában indult a teszt – ez lehet az első és legegyszerűbb lépés egy manipulált HDD felismeréséhez. Alább láthatsz egy példát egy (hibásan) SMART resetelt HDD SMART logjáról. A teljes logból kiemeltük a fontos részeket (vastaggal jelezve a különösen fontos részeket):

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-96-generic] (local build)
=== START OF INFORMATION SECTION ===
Vendor: SEAGATE
Product: ST8000NM0075
[…]
=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
[…]
Manufactured in week 15 of year 2016
Specified cycle count over device lifetime: 10000
Accumulated start-stop cycles: 58
Specified load-unload count over device lifetime: 300000
Accumulated load-unload cycles: 1951
[…]
Vendor (Seagate/Hitachi) factory information
number of hours powered up = 19.02
number of minutes until next internal SMART test = 35
[…]
SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
Description                              number   (hours)
1  Background short  Completed                  96   31368                 – [-   –    -]
2  Background long   Completed                  96   31241                 – [-   –    -]
3  Background short  Completed                  96       4                 – [-   –    -]
4  Reserved(7)       Completed                  64       4                 – [-   –    -]
5 Background short  Completed                  96       1                 – [-   –    -]

A fenti logból az látszik, hogy a lemezen naplózott utolsó kettő SMART teszt a 31241. illetve a 31368. órában készült, miközben a lemez által jelentett teljes üzemidő csupán 19.02 óra:   number of hours powered up = 19.02

A kriptobányász eredetű tárolók felismerése különösen kritikus lett pl. a Chia cryptocurrency megjelenése óta. Ezek a meghajtók extrém write-intensive terhelés alatt működtek, ahol például egy 1TB-os SSD akár 80 nap alatt elérheti a teljes kopási határát, míg normál irodai használat mellett ugyanez a paraméter 10 évet is jelenthet. A SMART adatok közül különösen figyelni kell a Total_LBAs_Written és a Wear_Leveling_Count értékekre, amelyek aránytalanul magasak lehetnek a Power_On_Hours értékhez képest. Ezeket az értékeket mindkét operációs rendszeren ellenőrizni tudjuk:

# Linux – SMART attribútumok részletes listázása
sudo smartctl -A /dev/sda

# Teljes SMART teszt futtatása
sudo smartctl -t long /dev/sda

# Windows – CrystalDiskInfo adatainak PowerShell-es lekérdezése
# Alternatívaként WMI objektumokból
Get-WmiObject -Namespace root\wmi -Class MSStorageDriver_FailurePredictData | 
    Select-Object InstanceName, VendorSpecific

# Vagy a beépített Get-PhysicalDisk paranccsal
Get-PhysicalDisk | Get-StorageReliabilityCounter | 
    Select-Object DeviceId, PowerOnHours, ReadErrorsTotal, WriteErrorsTotal

Firmware verziók

Az enterprise környezetből származó merevlemezek gyakran speciális firmware verziókkal rendelkeznek, amelyek az első részben említett inkompatibilitási problémákhoz vezethetnek. A firmware verzió programozott lekérdezése több operációs rendszeren is elvégezhető. Windows PowerShell környezetben a következő paranccsal történik:

# Windows PowerShell – minden csatlakoztatott meghajtó firmware verzióját listázza
Get-WmiObject -Class Win32_DiskDrive | Select-Object Model, FirmwareRevision

#Linux környezetben ugyanezt az információt a smartctl utilitával szerezhetjük meg:
# Linux – részletes meghajtó információk firmware verzióval együtt
sudo smartctl -i /dev/sda | grep -E „(Device Model|Firmware Version)”

# Vagy minden meghajtóra egyszerre
for disk in /dev/sd?; do echo „=== $disk ===”; sudo smartctl -i $disk | grep -E „(Device Model|Firmware Version)”; done

A NAxx, 3Pxx, BCxx,ECxx, VETxxxxx, 7Fxx firmware verziók (illetve egyéb storage specifikus verziók) különleges kategóriát képviselnek, mivel ezek gyakran az adott gyártó storage NAS, SAN, DAS eszközeihez optimalizált konfigurációkat tartalmaznak. Ezek a verziók sajátos power management beállításokkal, módosított error handling rutinokkal és speciális enterprise funkciókkal rendelkezhetnek, amelyek fogyasztói környezetben váratlan viselkedést vagy akár instabilitást okozhatnak. Ezek a meghajtók csak és kizárólag az adott gyártó eszközeivel használhatóak megfelelően (vendor lock-in).

A 520/4160 byte szektorméret problémakör

A szektorméret ellenőrzése talán a legkritikusabb technikai vizsgálat, amit használt enterprise merevlemezekkel kapcsolatban el kell végezni. Ebből a tesztből gyorsan kiderül, ha a megvásárolt használt merevlemez eredetileg nem standard szerverekbe, hanem gyártóspecifikus storage eszközökbe lett szánva. 

Az első részben már érintettük ezt a problémát, most azonban a gyakorlati megoldási módszereket is bemutatjuk. A dedikált storage megoldások (NetApp, EMC, HPE 3PAR, Hitachi VSP) “non-standard” blokkméretet, az esetek többségébe 520 byte-os vagy 4160 byte-os szektorméretet használnak a standard 512/4096 byte helyett, ami teljes inkompatibilitást eredményez a legtöbb operációs rendszerrel.

Ezeket a lemezeket a szerverekben található hardveres RAID vezérlők nem kezelik, letiltják azokat. Ha a frissen vásárolt használt merevlemez nem működik megfelelően vagy nem jelenik meg egyáltalán az operációs rendszerben / RAID kártya vagy HBA kártya felületén, akkor ez lehet az első probléma, amire gyanakodhatsz. Nem hivatalos forrásból vagy gyanúsan olcsón vásárolt használt merevlemeznél ez a legelső teszt, amit érdemes elvégezni. A nem-standard blokkméretű merevlemezeket nem fogod tudni használni.

Linux környezetben a smartctl paranccsal tudjuk diagnosztizálni a szektorméretet, míg Windows alatt a fsutil vagy PowerShell parancsok használhatók:

# Linux – részletes szektorinformációkat ad vissza

sudo smartctl -i /dev/sda | grep „Sector Size”

# Alternatívaként a blockdev parancs is használható

sudo blockdev –getpbsz /dev/sda

# Windows PowerShell – szektorméret lekérdezése WMI objektumokból

Get-WmiObject -Class Win32_DiskDrive | Select-Object Model, BytesPerSector

# Vagy fsutil segítségével konkrét meghajtóra

fsutil fsinfo ntfsinfo C: | findstr „Bytes Per Sector”

Ha a Linux kimenet „520 bytes logical/physical” értéket mutat, akkor az adott meghajtó nem használható standard környezetben. Windowsban pedig a BytesPerSector érték 520 lesz a standard 512 helyett.

Modellszám alapú hitelesítés és CLAR típusok

A pontos modellszám ellenőrzése minden használt merevlemez beszerzésnél alapkövetelmény. (Megjegyezendő, hogy a címkén általában a normál típus szerepel: például SEAGATE ST8000NM0065, de a S.M.A.R.T. értékeket tekintve: IBM-E050. Másik példa a SEAGATE ST4000NM0043 esetében, azonban a S.M.A.R.T. specifikációkat kiolvasva a tipus már ST4000NXCLAR4000!) Az enterprise merevlemezek gyakran speciális szuffixekkel rendelkeznek, amelyek eltérő konfigurációkat jelölnek. A CLAR végződésű modellek például gyakran speciális enterprise optimalizációkat tartalmaznak, EMC storage rendszerekhez.

A modern Seagate merevlemezek QR kód alapú hitelesítési rendszert használnak. Ez a QR kód a gyártó hivatalos adatbázisához kapcsolódik, így egyszerű módszert biztosít a hamisítások és az átcímkézett modellek azonosítására. A QR kód mobilalkalmazással való beolvasása azonnal visszajelzi a meghajtó legitimitását és specifikációit. 

Ez a QR kód azonban nem szerepel a HPE vagy DELL brandelt merevlemezeken – így csak erre az egy tesztre ne alapozz. A QR kódot kizárólag a “külön kereskedelmi forgalomban kapható – boltban megvehető” lemezek kapják meg, a szerverekkel együtt eladott, szervergyártó által brandelt változatok nem.

Beszerzési folyamat optimalizálása

IT döntéshozóként elengedhetetlen, hogy strukturált ellenőrzési protokollt alakíts ki a használt enterprise tárolók beszerzéséhez. Ez a protokoll minden egyes meghajtó esetében kötelezővé teszi a firmware verzió auditálását, a szektorméret vizsgálatát és a SMART adatok keresztellenőrzését több diagnosztikai eszközzel.

Különös figyelmet érdemel a beszállítói transzparencia kérdése. Megbízható eladók készségesen biztosítják a részletes SMART reportokat és firmware információkat, míg a kétes forrásból származó ajánlatok gyakran hiányos vagy elavult adatokat tartalmaznak.

Az első részben említett ROI számítások itt válik konkréttá: egy alapos kockázattervezés elvégzése ugyan időt és erőforrást igényel, de megelőzheti a későbbi üzletmenet-folytonossági problémákat, amelyek költsége gyakran többszöröse a kezdeti megtakarításnak.

Összegzés és gyakorlati gyorsreferencia

A használt enterprise tároló piac navigálása komplex technikai kihívásokat tartogat, amelyek megfelelő szakértelem nélkül jelentős kockázatot jelenthetnek. A bemutatott ellenőrzési módszerek szisztematikus alkalmazása azonban hatékony védelmet nyújt a leggyakoribb csalások és kompatibilitási problémák ellen.

Technikai ellenőrzési cheat sheet

Firmware verzió lekérdezése:
# Windows
Get-WmiObject -Class Win32_DiskDrive | Select-Object Model, FirmwareRevision

# Linux
sudo smartctl -i /dev/sda | grep -E „(Device Model|Firmware Version)”

SMART adatok ellenőrzése:
# Windows
Get-PhysicalDisk | Get-StorageReliabilityCounter | Select-Object DeviceId, PowerOnHours

# Linux
sudo smartctl -A /dev/sda | grep -E „(Power_On_Hours|Total_LBAs_Written|Wear_Leveling_Count)”

Szektorméret lekérdezése:
# Linux
sudo smartctl -i /dev/sda | grep „Sector Size”

Gyors (short) SMART teszt indítása
#Linux
sudo smartctl -t short /dev/sda

Alapos (long) SMART teszt indítása
#Linux
sudo smartctl -t long /dev/sda

Utolsó sikeres smart teszt eredmény lekérdezése:
#Linux
sudo smartctl -l selftest /dev/sda

A következő lépés saját szervezetedben egy standardizált beszerzési protokoll bevezetése, amely integrálja ezeket az ellenőrzési pontokat a döntéshozatali folyamatba. Ez a módszeres megközelítés nemcsak a közvetlen technikai kockázatokat csökkenti, hanem biztosítja a hosszú távú rendszermegbízhatóságot és költséghatékonyságot is. Minden ellenőrzési lépést dokumentálj, és alakíts ki visszakövethető auditnyomvonalat, amely későbbi problémák esetén segíti a gyökérok-elemzést.