Sió-Informatika Rendszerház

Egy hibás Defender-verzió akár központilag, rendszergazdai kézi beavatkozás nélkül is eljuthatott szerverekhez.

A Microsoft két komoly hibát javított a Defender for Endpoint Linux-verziójában, miután kiderült, hogy egy hibás platformfrissítés bizonyos rendszereken újraindítás után letilthatta a biztonsági szolgáltatást, miközben egy másik probléma megakadályozta a frissítés telepítését egyes FIPS-módban működő Red Hat Enterprise Linux rendszereken.

A legsúlyosabb probléma a Microsoft Defender for Endpoint Linux 101.26042.0000 és 101.26042.0009 közötti platform buildjeit érintette.

A Microsoft hivatalos kiadási dokumentációja szerint upgrade vagy újratelepítés után egy rendszer-újraindítás következtében a Defender for Endpoint letiltott állapotba kerülhetett. A probléma minden támogatott Linux-disztribúciót érinthetett.

A hiba különösen érzékeny azoknál a szervezeteknél, amelyek Linux szervereiket a Microsoft Defender for Servers és Defender for Cloud segítségével védik, mivel a MDE.Linux extension használatakor a Defender for Endpoint automatikus frissítése alapértelmezetten engedélyezett lehet.

Ez azt jelenti, hogy egy hibás Defender-verzió akár központilag, rendszergazdai kézi beavatkozás nélkül is eljuthatott szerverekhez.

Az újraindítás után jelentkezett a probléma

A hiba veszélyességét elsősorban a kiváltási módja adta.

Egy Linux szerver látszólag sikeresen megkaphatta a Defender frissítését, majd tovább működhetett minden különösebb figyelmeztetés nélkül.

A probléma csak a következő reboot után jelentkezhetett.

Ez különösen kellemetlen vállalati környezetben, mivel a Linux szerverek újraindítása gyakran éppen biztonsági karbantartások során történik, például:

• kernel-frissítés;
• operációs rendszer patching;
• infrastruktúra-karbantartás;
• cloud VM újraindítás;
• konfigurációváltozás;
• vagy tervezett maintenance window

után.

Előállhatott tehát az a paradox helyzet, hogy egy szervezet biztonsági frissítéseket telepített, majd az ezek miatt végrehajtott újraindítás után éppen az egyik legfontosabb endpoint-security komponens vált működésképtelenné.

Ezek a Defender-verziók érintettek

A Microsoft szerint a problémás platform build tartomány:

101.26042.0000–101.26042.0009

A hibát elsőként a következő build javította:

101.26042.0011

A Microsoft release note szerint ez a verzió kifejezetten azt a buildhibát korrigálta, amely upgrade vagy reinstall után, rendszer-újraindítást követően letilthatta a Defender for Endpoint Linux szolgáltatását.

A Microsoft már eltávolította az érintett build-eket a normál production update csatornáról.

Nem sérülékenység, de valós védelmi rés

A Microsoft nem CVE-ként kezeli a problémát, és nincs arra utaló információ, hogy támadók közvetlenül kihasználták volna.

Technikailag tehát nem klasszikus security vulnerability-ről, hanem termékhibáról beszélünk.

Biztonsági szempontból azonban a következmény komoly lehetett.

Ha egy endpoint-protection szolgáltatás leáll vagy letiltott állapotba kerül, az érintett gépen csökkenhet:

• a valós idejű malware-detekció;
• a rosszindulatú folyamatok felismerése;
• az EDR-telemetria teljessége;
• az incidensvizsgálathoz rendelkezésre álló adatok mennyisége;
• és a security operations center láthatósága.

Egy ilyen állapot funkcionálisan részben hasonló ahhoz, amit egy támadó defence evasion technikával próbál elérni: kikapcsolni vagy megkerülni az endpoint-védelmet.

Ez önmagában nem bizonyít kompromittálást, de olyan időszakot hozhat létre, amelyben a szervezet kevesebb bizonyítékkal rendelkezik arról, mi történt a rendszeren.

A Defender for Cloud miatt automatikusan is terjedhetett

A probléma lehetséges hatását növeli a Microsoft Defender for Cloud integrációja.

Ha egy szervezet bekapcsolja a Defender for Servers csomagot, a Defender for Endpoint integráció alapértelmezetten engedélyezhető, és a Microsoft automatikusan telepítheti a Defender agentet a támogatott Windows- és Linux-gépekre.

Linux rendszereken a MDE.Linux extension használatakor a Microsoft Defender for Endpoint automatikus verziófrissítése is alapértelmezetten engedélyezett.

Ez az automatizálás normál körülmények között komoly előny.

Segítségével a biztonsági csapatnak nem kell több száz vagy több ezer Linux host frissítését manuálisan kezelnie.

Egy hibás release esetén azonban ugyanaz az automatizmus gyorsan nagyobb számú rendszerre terítheti ki a problémát.

A szerver akár napokig megfelelőnek tűnhetett

A hiba másik fontos következménye, hogy nem feltétlenül közvetlenül az upgrade után vált láthatóvá.

Egy szerver:

1. megkapta a hibás Defender-verziót;
2. tovább működött;
3. napokig vagy akár hosszabb ideig nem indították újra;
4. majd egy későbbi maintenance során rebootolták;
5. és csak ekkor jelentkezett a Defender-probléma.

Ezért azok a szervezetek sem feltétlenül tekinthetik lezártnak az ügyet, amelyek hetekkel korábban telepítették a problémás buildet.

A kérdés nem pusztán az:

települt-e hibás verzió?

Hanem az is:

a legutóbbi reboot után ténylegesen fut-e a Defender?

Nem elég csak a package version ellenőrzése

A Microsoft dokumentációja alapján a Linux Defender állapotát közvetlenül is ellenőrizni kell.

Az egyik legalapvetőbb parancs:

mdatp health

A Defender for Cloud dokumentációja szerint egy megfelelően onboardolt és működő rendszer esetében például az alábbi állapotok várhatók:

healthy : true
licensed : true

Az antivírus motor állapotát és más komponenseket az mdatp health további mezői is mutatják.

A Microsoft dokumentációja többek között külön jelzi:

• az engine_load_status értékét;
• a healthy státuszt;
• a real_time_protection_available állapotot;
• és a real_time_protection_enabled értéket.

A valós idejű védelem külön ellenőrizhető

A real-time protection közvetlen lekérdezésére használható:

mdatp health --field real_time_protection_enabled

A Microsoft dokumentációja szerint a true eredmény azt mutatja, hogy a valós idejű antivírus-védelem engedélyezve van.

Ugyanakkor ezt mindig az adott vállalati konfigurációval együtt kell értelmezni.

A Defender működhet például:

• real-time;
• passive;
• on-demand;
• vagy audit

üzemmódban is.

A későbbi júliusi Linux release már egy új antivirus_enforcement_level mezőt is hozzáadott az mdatp health kimenetéhez, amely közvetlenül megmutatja az aktuális enforcement módot.

Az engine állapotát is érdemes ellenőrizni

Az mdatp health egyik különösen fontos mezője:

engine_load_status

A Microsoft szerint:

• Engine load succeeded – az antivírus engine működik;
• Engine not loaded – az antivírus engine process nem fut.

Ez fontosabb információ lehet annál, mintha egy adminisztrátor pusztán azt látná, hogy a package telepítve van.

Egy telepített security agent ugyanis nem feltétlenül jelent ténylegesen működő védelmet.

Külön FIPS-hiba érintette a RHEL 8 és 9 rendszereket

A Microsoft egy második, az elsőtől független problémát is javított.

Ez a hiba bizonyos:

Red Hat Enterprise Linux 8 és RHEL 9

rendszereket érintett, amelyeken a FIPS mód aktív volt.

Az érintett gépek nem tudtak sikeresen frissíteni a 101.26042.x platformverzióra.

A Microsoft júliusi release note-ja szerint ezt a problémát a 101.26052.x ágban javították; a dokumentáció jelenlegi kiadása a 101.26052.0012 release alatt kifejezetten rögzíti, hogy a korábban frissítési hibát tapasztaló FIPS-enabled RHEL 8/9 eszközök már sikeresen telepíthetik az update-et.

A probléma következménye itt eltért az első hibától.

A FIPS-es rendszereken nem az történt, hogy egy működő Defender telepítés reboot után kikapcsolt.

Ehelyett maga az új Defender-verzió telepítése nem fejeződött be megfelelően, így a rendszer a korábbi verzión maradhatott.

Mi az a FIPS mód?

A FIPS a Federal Information Processing Standards rövidítése.

A FIPS 140 szabványsorozat meghatározza a kriptográfiai modulokra vonatkozó biztonsági követelményeket.

A NIST szerint a FIPS 140-2 és FIPS 140-3 követelményei az amerikai szövetségi szervezetek számára alkalmazandók, amikor kriptográfiai védelmet használnak az érintett információk és rendszerek védelmére.

FIPS-kompatibilis konfigurációkat nemcsak közvetlenül amerikai kormányzati rendszerekben használnak.

Előfordulhatnak:

• defense contractor környezetekben;
• pénzügyi szolgáltatóknál;
• kritikus infrastruktúrában;
• szabályozott iparágakban;
• és olyan vállalatoknál is, amelyek szerződéses vagy compliance követelmények miatt alkalmazzák őket.

A FIPS mód miatt bizonyos kriptográfiai algoritmusok és implementációk használata korlátozott lehet, ezért egy olyan szoftver, amely normál Linux környezetben hibátlanul települ, FIPS rendszerben kompatibilitási problémába ütközhet.

A Microsoft nem részletezte, pontosan mely kriptográfiai művelet okozta a Defender update problémáját.

A FIPS-hiba kevésbé volt veszélyes, de nem ártalmatlan

A FIPS-es telepítési probléma közvetlen következménye kevésbé súlyos volt, mint a reboot után leálló Defenderé.

A régi, működő Defender telepítés elvileg tovább futhatott.

Ez azonban hosszabb távon verzióelmaradáshoz vezethetett.

Egy endpoint-security agent esetében a folyamatos frissítés kulcsfontosságú, hiszen rendszeresen változik:

• a platform;
• az antivírus engine;
• a security intelligence;
• a detekciós logika;
• az EDR-képesség;
• és az új Linux kernel- vagy distribution-verziókkal való kompatibilitás.

Ezért a sikertelen upgrade-et nem célszerű egyszerű „package management” problémaként kezelni.

A Defender Linuxon egyre fontosabb vállalati security komponens

A Microsoft Defender for Endpoint Linux-változata ma már jóval több egyszerű antivírusnál.

A platform többek között támogatja:

• malware detection;
• endpoint detection and response;
• vulnerability visibility;
• behavioral monitoring;
• cloud-delivered protection;
• központi security telemetry;
• és Microsoft Defender portálon keresztül történő vizsgálatot.

A Microsoft dokumentációja szerint a Linux kliens folyamatosan képes security intelligence update-eket fogadni, az adminisztrátorok pedig központilag ellenőrizhetik az antivirus posture-t, engine- és platformverziót, valamint device health állapotokat.

A platform a modernebb Linux release-eken eBPF-alapú telemetry infrastruktúrát is használ.

Az mdatp health szerint a supplementary events subsystem újabb verziókon alapértelmezés szerint ebpf lehet.

Egyre mélyebbre integrált security agentek

Az ilyen termékek különleges kihívást jelentenek a fejlesztőknek.

Egy endpoint-protection rendszer:

• fájlrendszer-műveleteket figyel;
• process executiont követ;
• network activityt elemez;
• kernel mechanizmusokat használ;
• mandatory access control rendszerekkel működik együtt;
• cloud telemetryt generál;
• és rendszerint magas jogosultsággal fut.

Ennek következtében egy stabilitási hiba önmagában is sokkal komolyabb hatású lehet, mint egy átlagos alkalmazás hibája.

A biztonsági szoftver meghibásodása ugyanis nemcsak magát a programot érinti.

A teljes rendszer észlelési képessége csökkenhet.

Korábbi Defender Linux problémák is voltak

A Microsoft 2026 során más Linux-specifikus Defender hibákat is javított.

Korábban például egy /dev/watchdog eszközzel kapcsolatos real-time scanning probléma bizonyos hardware watchdog konfigurációknál váratlan rendszer-újraindítást okozhatott.

Más release-ekben SELinuxhoz és upgrade folyamatokhoz kapcsolódó stabilitási javítások is megjelentek.

Ezek különálló hibák voltak, ezért nem szabad őket egyetlen folyamatos Defender-problémaként értelmezni.

Ugyanakkor jól mutatják, hogy egy mélyen integrált endpoint agent kompatibilitásának biztosítása a különböző:

• Linux-disztribúciók;
• kernelverziók;
• SELinux policy-k;
• cloud környezetek;
• és FIPS-konfigurációk

között rendkívül összetett feladat.

Mit tegyenek most a szervezetek?

Az első lépés a teljes Linux estate inventoryja.

Az adminisztrátoroknak azonosítaniuk kell minden olyan szervert, amelyen a Defender for Endpoint platform buildje:

101.26042.0000 és 101.26042.0009 közé esik.

Ezeket a rendszereket támogatott, javított verzióra kell frissíteni.

Az első release, amely a reboot utáni Defender-disable hibát javította:

101.26042.0011.

A FIPS-es RHEL-problémát is kezelő újabb 101.26052.x release használata azonban célszerűbb közös célverzió lehet, illetve mindig a Microsoft által aktuálisan támogatott legfrissebb buildet érdemes használni.

Ellenőrizni kell a szolgáltatás tényleges állapotát

A frissítés után legalább az alábbiakat célszerű ellenőrizni:

mdatp health

és:

mdatp health --field real_time_protection_enabled

Az adminisztrátoroknak különösen figyelniük kell az alábbi mezőkre:

healthy
engine_load_status
real_time_protection_available
real_time_protection_enabled
health_issues

Az újabb verziókban pedig:

antivirus_enforcement_level

is segítséget nyújt annak meghatározásához, hogy az antivirus ténylegesen milyen üzemmódban működik.

A Defender portalban is keresni kell az eltéréseket

Nagyobb környezetben nem reális minden Linux szervert manuálisan ellenőrizni.

A security csapatoknak ezért meg kell keresniük:

• hosszabb ideje inaktív endpointokat;
• stale telemetryt;
• degraded sensor-health állapotot;
• reboot után eltűnő eszközöket;
• és váratlan Defender reporting gapeket.

A Microsoft Defender for Cloud központi deployment trackinget is biztosít az Azure VM-ek és Azure Arc-enabled gépek Defender állapotának ellenőrzésére.

A monitoring gapet is vizsgálni kell

Ha egy kritikus Linux szerveren ténylegesen leállt a Defender, nem feltétlenül elegendő egyszerűen újraindítani a szolgáltatást és továbblépni.

A kiesés időszaka bizonytalansági ablakot jelent.

Érdemes visszamenőleg megvizsgálni:

• új vagy módosított systemd service-eket;
• privilege escalation eseményeket;
• váratlan root loginokat;
• új user accountokat;
• cron jobokat;
• SSH authenticationt;
• ismeretlen outbound kapcsolatokat;
• shell historyt;
• persistence mechanizmusokat;
• és más security telemetryt.

Ez nem azért szükséges, mert a Microsoft szerint támadás történt.

Nincs ilyen bizonyíték.

Azért szükséges, mert amikor egy elsődleges EDR-sensor nem működik, a szervezet már nem rendelkezik ugyanazzal a bizonyossággal az adott host aktivitásáról.

A rollout stratégián is érdemes változtatni

Az incidens legfontosabb szervezeti tanulsága az automatikus security update-ek kontrollált alkalmazása.

Nem célszerű az update-eket indokolatlanul késleltetni, hiszen a gyors patching továbbra is alapvető védelem.

Viszont érdemes deployment ringeket használni.

Egy kis első hullám tartalmazhat például:

• Ubuntu szervert;
• Debian hostot;
• normál RHEL-t;
• FIPS-es RHEL-t;
• SELinux enforcing gépet;
• különböző kernelverziókat;
• Azure VM-et;
• Azure Arc rendszert;
• és egy Defender for Cloud által automatikusan menedzselt gépet.

A pilot update után pedig nemcsak azt kell ellenőrizni, hogy sikerült-e a package install.

A következő kérdéseket is:

Fut-e az agent?
Betöltődött-e az engine?
Működik-e a real-time protection?
Jön-e telemetry?
Reboot után is egészséges maradt-e?

Összegzés

A Microsoft már javította a Defender for Endpoint Linux problémáit, és nincs bizonyíték arra, hogy támadók kihasználták volna őket.

A reboot utáni service-disable probléma azonban fontos figyelmeztetés.

Egy security agent frissítése nem tekinthető sikeresnek pusztán attól, hogy a package manager azt írja:

installation completed successfully.

A valódi kérdés az:

a rendszer újraindítása után is működik-e a védelem?

A 101.26042.0000–101.26042.0009 Defender buildet futtató Linux szervereket ezért azonnal ellenőrizni és frissíteni kell, a FIPS-módban működő RHEL 8/9 rendszereken pedig külön ellenőrizni kell, hogy az újabb Defender platformverzió valóban sikeresen települt-e.

Azoknál a gépeknél, ahol a Defender egy időre leállt, a szolgáltatás helyreállítása mellett célszerű az érintett időszak biztonsági eseményeit is visszamenőleg áttekinteni.