Patch menedzsment – tradicionális vs modern megoldás

Posted on by
Reply

A Windows patchelés mindig fontos feladat volt. Figyelemmel kellett kísérni a havonta érkező hotfixeket, és mivel ezek sokszor tartalmaznak biztonsággal kapcsolatos hibajavításokat is, gondoskodni kellett a telepítésükről. A cikkemben megmutatnék két megközelítést, illetve tennék best practice javaslatot is, hogyan csökkenthető a patchelés unalmas munkája.

Mi a tradícionális megoldás?

Nagyobb cégeknél jellemzően SCCM-mel végzik a patchelést. Az SCCM egy nagyon sokoldalú, robosztus termék, tökéletesen megfelel a célnak. Nagy előnye a granularitás, igen részletekbe menően szabályozható (milyen patcheket küldünk ki, mikor küldjük, gépcsoportok szerinti telepítések, riportolási funkciók)Hátránya viszont, hogy komoly infrastruktúrát igényel, domaines környezetet, szakembereket. A megnőtt mobilitási igényeknél (pláne a COVID okozta remote work hullám) figyelni kell a hálózattól távollévő gépek menedzsmentjére. Nehézség lehet, ha egyszerre sokszáz gép tölti a frissítéseket a belső hálózatról, VPN-en keresztül. Ez mind a céges sávszélességet terheli.A SCCM patch workflow-t az alábbi ábra szemlélteti nagy vonalakban:19Az SCCM adminisztrátornak minden hónapban össze kell állítania egy szoftvercsomagot, azt eljuttatni a disztribúciós pontokra, gépcsoportokra telepítést meghatározni, később pedig monitorozni a sikeres-sikertelen telepítéseket. 

Mi a modern megoldás?

A Microsoft által modernnek hívott megoldást az Intune biztosítja. Ebben az esetben nincs szükség helyi infrastruktúrára, disztribúciós pontokra, egyéb megoldásokra. A patch menedzsmentet az Intune-on át a Microsoft Update biztosítja, a kliensek oda fordulnak és töltik le a frissítéseket. Ez a fent részletezett remote work scenárióknál komoly sávszélesség és erőforrás-spórolás a céges infrát tekintve.Az Intune patch management workflow az alábbi képen látható:Untitled 

Melyik a jó megoldás?

 

Általánosságban elmondható, ha nem előírás a nagyfokú kontroll a patch menedzsment minden lépésében, akkor érdemes a modern (Intune) megközelítést használni. A gépek az Intune-on át megkapják a windowsupdate policyket és azok mentén töltik le a frissítéseket a Microsoft Update-ről és telepítik. Evvel a megoldással biztosítható, hogy gyors legyen az update terítés és a gépek mindig a friss patcheket telepítsék.

Üzemeltetési oldalról is jóval könnyebb ennél a forgatókönyvnél, nincs szükség a fent részletezett lépésekre (patch csomagok összeállítása, deployment stb). A céges infrastruktúrát sem terheli a patch folyamat (sávszélesség, szerverek, tárhely)

A következő cikkembe bemutatom részletesen, hogy miként lehet az Intune-ra terelni a frissítési mechanizmust.

Skype/Teams coexsistence – és a csapda

Posted on by
Reply

A Microsoft Teams egy nagyon népszerű és könnyen használatba vehető alkalmazás. Azonban, ha van meglévő földi Skype for Business környezetünk, federációs lehetőséggel (azaz külsősökkel történő kommunikáció), arra szükséges egy kis odafigyelés.

A call/presence/chat viselkedése a TeamsUpgrade beállítási módtól függ (ez lehet per user vagy tenant-wide beállítás)

A lehetséges beállítási módok:

  • Island mode: ilyenkor a Skype és  Teams kliensek egymás mellett futnak, sziget módban, azaz nem tudnak egymás létezéséről. Ilyenkor a szervezeten belül indított Skype chat a Skype kliensbe, a Teams chat a Teams kliensbe fog megérkezni. Az Island mode az alapértelmezett beállítás.
  • Skype for Business only: minden chat/call/meeting funkciót a Skype kliens kezel
  • Skype for Business with Teams Collaboration: a chat/call/meeting a Skype kliensben történik, de a Teamset lehet használni csoportmunkára (Team-ek, dokumentumok)
  • Skype for Business with Teams Collaboration and meetings: továbbra is a Skype kliens kezeli a chat/call funkciókat, de van mód már a Teamsben is meetinget szervezni és természetesen a csoportmunka funkciók is támogattottak.

Ahogy említettem, a fenti módok akár felhasználónként szabályozhatók, eltérve a Tenant-Wide beállítástól:

01

A routolás is háromféle módot ismer:

  • native: organizáción (tenanton) belüli Teams-Teams kommunikáció
  • interop: organizáción (tenanton) belüli Skype-Teams kommunikáció
  • federated: tenantok közötti federált kommunikáció

Hogy a fenti routing megoldások közül melyik kerül felhasználásra, az alábbiak határozzák meg:

  • a címzett TeamsUpgrade beállítása
  • a küldő által használt kliensprogram
  • új vagy meglévő chat-ről (conversation) van szó
  • a chat organizáción belüli-e vagy federált chat

 

Nézzük a kezdeti felvetést: van működő Skype for Business környezetünk, és elkezdjük használni a Teamset. Ilyenkor minden felhasználó Island módban van, tehát a két kliens párhuzamos futtatása szükséges. A táblázat mutatja, melyik kliensbe érkezik meg az üzenet.

Table 1a: in-tenant new chat or call routing to an islands mode recipient

Mode Originator

Client

 SfB homed Recipient

Islands
Islands Teams
Skype for Business
Teams
Skype for Business		 Online
Online
On-prem
On-prem		 Teams
Skype for Business
Teams
Skype for Business
Mi történik, ha a felhasználó kikapcsolja a Skype kliensét, avval a felkiáltással, hogy már úgyis van Teams-ünk? Az ő szemszögéből semmi, ír a kollégának Teamsen, aki szintén Teamsen kapja meg az üzenetet.
Viszont itt dől össze a federáció, legalábbis az a lehetőség, hogy külsősök tudjanak chatelni velük. Miért? Az alábbi táblázat alapján látható, hogy ha külsős Teamsből indít chatet, akkor az a Skype kliensbe kézbesítődik. Azaz kézbesítődne, de a Skype kliens már nem fut. A küldő csak hibaüzenetet kap, hogy nem kézbesíthető.

Table 2a: federated new chat or call routing to an Islands recipient

Mode Originator

Client

 SfB homed Recipient

Islands
Islands Teams
Skype for Business
Teams
Skype for Business		 Online
Online
On-prem
On-prem		 Skype for Business
Skype for Business
Not Possible
Skype for Business
Mi a megoldás? Egyrészről, figyeljünk oda az Island módra.
Amennyiben muszáj, hogy a felhasználónk ezt a megoldást használja, fel kell hívni a figyelmét, hogy mindig futtassa a Teams és Skype klienst párhuzamosan. Amennyiben lehetséges a migráció, akkor a legjobb választás a Teams-only mód (ehhez előfeltétel a Skype-hybrid kiépítése és a felhasználó migrálása a Skype for Business Online-ba, utána állítható be számára a Teams-only mód).
Továbbá, ha van meglévő földi telefónia integráció (SIP trunk stb), akkor az nem fog működni a Teams-only módban, csak ha megfelelő dial plan licensszel és direct routing beállításokkal rendelkezünk.

AzureAD Password Protection

Posted on by
1

A jelszavak problémája az üzemeltetők és felhasználók örök fejfájása. Nem részletezem, mindenki ismeri a problémát, túl bonyolult, túl gyakran kell változtatni, a felhasználó felírja egy post-it-re a monitorára ragasztva, a panaszlista végtelen.

Talán rövidesen eljut a világ a jelszómentes berendezkedésig, ahol ezeket a gondokat elfelejthetjük, addig is egy kis hasznos segítség:

Világszerte nagy problémát jelentenek a gyakran használt gyenge jelszavak (pl. password, admin, qwert123, letmein, secret….) és a könnyen kitalálható verziók (pl. p@ssw0rd stb). A felhasználók is előszeretettel próbálják a cégnevet belevenni a jelszóba, hogy számukra könnyen megjegyezhető legyen (pl. Adatum cégnél @datuM123 és hasonló formák). Az esetleges támadónak így nem nagyon kell erőlködnie, pár jól célzott próbálkozással akár hozzáférést is szerezhet a felhasználói fiókhoz.

A gyenge és könnyen kitalálható jelszavak problémájára ad megoldást az AAD PP.

Beépített és folyamatosan frissülő “weak passwords list” és az adminok által egyedileg definiált tiltott jelszavak listájával megakadályozza, hogy könnyen kitalálható jelszavakat állítsanak be a felhasználók. Ez működhet az tisztán az AzureAD-ra, de akár a földi rendszerek is védhetőek vele.

A beállítása egyszerű, az Azure portálon az Azure Active Directory / Authentication methods / Password protection részhez kell navigálni, és kitölteni a Custom banned passwords mezőt:

A listába 1000 tételt lehet felvenni, minimum 4, maximum 16 karakter a követelmény.

A tiltott jelszó kiértékelése többlépcsős folyamat, mélyebben a mechanizmust a https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad cikk írja. Nagyon dióhéjban, tud különbséget tenni az “a és @” illetve “o és 0” értékek között, a végén egy pontszámítással megállapítva, hogy megfelelő-e a jelszó vagy sem (hány tiltott formát tartalmaz a jelszó, van-e további karakter megadva stb)

Nagy erőssége a megoldásnak, hogy földi rendszerrel is integrálható. Ebben az esetben a földi domain controllerek minden jelszóváltoztatás előtt “bekérdeznek” az AAD PP-be, hogy megfelel-e a policynek a jelszó. Ehhez minden domain controllerre (Windows Server 2012 vagy újabb) telepíteni kell egy AzureAD Password Protection DC Agent klienst, illetve egy vagy több member serverre a AzureAD Password Protection Proxy összetevőt.

A DC agentek a Proxy kliensek segítségével kommunikálnak az AzureAD-val és validálják a jelszóváltoztatást. Az alábbi ábra mutatja a működést:

A rendszer kipróbálható Audit és Enforced módban, természetesen érdemes az elején a teszt-üzemmódot választani. A domain controllereken található Eventlogok segítségével láthatóak a jelszóváltozatások, amik éles üzemmód esetén tiltásra kerülnének:

Éles üzem esetén pedig ha a felhasználó nem megfelelő jelszót állítana be, az alábbi üzenetet kapja:

A licenszelést tekintve, ha egyedi tiltólistát szeretnénk használni, és/vagy hibrid környezetben használni, Azure AD Premium P1 vagy P2 licensz szükséges.

Részletes step-by-step leírások a működésről és beüzemelésről itt találhatóak:

Step-by-Step guide to Azure AD Password protection
Using the new Azure Active Directory password protection feature

Segít a felhasználó – könnyebb védekezés a spamek ellen

Posted on by
Reply

A levélszemét egy érdekes terület, amit mind a felhasználók, mind az adminok jól ismernek (sajnos…). Számszerűleg az adminok vannak a legkevesebben, a felhasználók a legtöbben, hát miért ne kérnénk hogy segítsenek a spam elleni küzdelemben? 🙂

Az M365 egy jó eszközt biztosít ehhez, az új user submission policy segítségével. A beállítást a Threat Management alatt találjuk:

Lényege, hogy az Outlookba beépül a Report Message nevű addon, amivel a felhasználó könnyen jelentheti a levélszemetet:

Ezt az add-ont lehet csoportokra vagy minden felhasználóra érvényes módon telepíteni.

A policy újdonsága, hogy beállítható egy reporting mailbox, ahova a bejelentett emailek másolata is kerül, ami további elemzésekben segíthet:

A bejelentésekhez lehet egyedi üzenetet is fűzni a felhasználól számára (itt fel lehet hívni a figyelmet, hogy a Microsoft is átvizsgálhatja a mailt, ezért fontos a személyes vagy érzékeny adatok védelme)

Érdemes ezt a az eszközt igénybe venni, a felhasználókat is bevonni a levélszemét probléma megoldásába, hiszen ez közös érdek és több szem többet lát 🙂

OneDrive mint felhasználói backup

Posted on by
1

Az alábbi cikkben az OneDrive nem új, de vállalati környezetben kevéssé használt funkcióját szeretném bemutatni: automatikus folder átirányítást.

Picit messzebbről indulva: vállalati környezetben nagyon régóta szabályozott, hogy adatokat nem mentünk a helyi gépre, kizárólag a fileszerverre/sharepointra/egyéb központi helyre, amit az IT felügyel, redundáns, van róla mentés stb.

A valóságban viszont számos alkalommal előfordul, hogy a szabályozás ellenére bizony a Desktopra, Documentsbe, egyéb helyekre kerülnek a fileok (tegye fel a kezét, aki még nem “követett el” ilyet 🙂 ) Ennek okai változatosak “nem volt jó a hálózat, nem értem el a fileszervert” , “nem ment valamiért a vpn” és bizony sok alkalmazás alapból ezeket a helyeket kínálja fel mentésre.

A probléma pedig akkor van, mikor a géppel valami történik, tönkremegy benne az adathordozó, ellopják, egyéb dráma történik. Ilyenkor senki nem szeretne az illető helyében lenni, akinek a főnökénél kell számot adnia róla, hogy miért veszett el a nagyon fontos szerződés vagy egyéb céges adat…

A megoldást az OneDrive KnownFolderMove funkciója jelentheti, azaz a gépen található Desktop, Documents és Pictures folderek átirányítását az OneDrive-ba. Innentől kezdve ha bármit lementünk mondjuk a Desktopra, az automatikusan szinkronizálódik a felhőbe.

A KFM (KnownFolderMove) funkció bekapcsolható Intune-nal menedzselt gépek esetén, illetve System Center Configuration Manager és Group Policy is támogatott.

Kétféle módon működhet történhet az átmozgatás:

Automatikusan, ekkor a felhasználó üzenetet kap, hogy a mappák átkerültek az OneDrive-ba

Vagy a felhasználóknak kell elvégezniük a beállítást és ekkor kapnak egy felbukkanó üzenetet:

Amennyiben a felhasználó csak bezárja az ablakot, további üzenetekkel fogja informálni a rendszer, hogy ez a beállítás kötelező:

Ez addig ott marad a képernyő sarkában (nem zárható be) amíg a beállítás meg nem történik.

A legjobb megközelítés a két policy ötvözése: legyen automatikus az átmozgatás, de ha az nem sikerül valamiért, akkor a felhasználót kéri fel a rendszer hogy végezze el. Ekkor persze lehet kérni az IT segítségét, és az adminok is biztosak lehetnek benne, hogy mindenhol végbement az átmozgatás.

Az adminoknak szintén jó hír, hogy policyból letiltható hogy a felhasználók megszüntessék ezt az átirányítást. Ilyenkor az OneDrive kliensen a Stop Backup gomb kiszürkül, tehát nincs mód rá, hogy ezek a mappák kikerüljenek a védelem alól.

Tervezéskor érdemes még észbentartani, hogy egyes felhasználóknál nagy lehet a Desktop/Documents/Pictures mappa mérete, ami a KFM beállításkor jelentős hálózati forgalmat fog okozni.

A KFM implementálása erősen ajánlott bármilyen vállalati környezetben, az automatikus mentés nagy terhet levesz a felhasználók és rendszergazdák válláról egyaránt.

Istvánffy Zoltán

Bejelentkezés lustáknak…

Posted on by
Reply

..ráadásul biztonságosan 🙂

Aki hozzám hasonlóan nem szeret sokat gépelni bejelentkezéskor, annak jó szolgálatot tehet egy FIDO2 security key.

Ez egy USB (vagy Type-C) csatlakozójú kis token, amivel az Azure/Office szolgáltatásokba felhasználónév és jelszó megadása nélkül lehet bejelentkezni.

Természetesen támogat minden más platformot is, amelyik implementálta ezt a lehetőséget, pl. Google, Facebook, AWS (Linkedin, az nem…) Másik nagy előnye, hogy nem igényel semmilyen driver telepítést, így bármelyik gépen azonnal használható.

Nézzük, hogyan történik egy bejelentkezés az Office Portalra, Chrome böngészőből. (először persze regisztrálnom kell a security keyt az AzureAD-ban)

A kezdőképernyőn nem kell beírni felhasználónevet, csak kattintani a Sign-in Optionsra

Az opciók közül a Sign in with security key-t választva.

Meg kell adni a security key-hez tartozó PIN-kódot (a hitelesítés első faktora)

Végül pedig meg kell nyomni a security key-en lévő fizikai gombot.

Ez a fizikai gomb biztosítja a második faktort a hitelesítéshez (kell felhasználói interakció, nem lehet programkódból kitrükközni)

A fenti módon tehát úgy léptem be a portálra, hogy semmilyen felhasználónevet és jelszót nem kellett gépelnem, megtakarítottam némi fáradtságot, esetleg elrontott jelszó miatti bosszankodást is. A kétfaktoros hitelesítés miatt pedig a belépési folyamat is biztonságosabb volt.

A FIDO2 kulcsok használhatóak Windows 10 bejelentkezéshez is (csak AzureAD joined gépeken, a klasszikus on-prem domainhez csatlakoztatott eszközöknek tavaszig várniuk kell erre a funkcióra)

Összefoglalva, a világ a jelszómentes, kétfaktoros hitelesítések felé halad, egy FIDO2 security key pedig egy nagyszerű alternatíva ehhez.

Új szemlélet az IT-biztonságban – Zero Trust Modell

Posted on by
Reply

avagy a perimeter-alapú hálózati védekezés miért kevés?

Az utóbbi években bekövetkezett robbanásszerű IT-fejlődés komoly kihívás elé állítja az üzemeltetőket és cégvezetőket egyaránt. Elterjedtek a mobileszközök (laptopok, tabletek, okostelefonok), az olcsó internet gyakorlatilag közszolgáltatássá lépett elő, és ezek a folyamatok változást generáltak a felhasználók oldalán is.

Egyre nőtt az igény, hogy mobileszközét a céges hálózaton kívül is használhassa, dolgozhasson otthonról, esetleg akár a saját eszközeit is bevethesse (BYOD). Alapvető elvárás lett, hogy a levelezését kezelhesse az okostelefonján, utazás közben is tudjon céges dokumentumokat megnyitni és így tovább. Az IT-mobilitás megteremtése kvázi kötelező feladat lett.

Ennek a nyomásnak a szervezetek igyekeznek is megfelelni, a felhős megoldások bevezetésével egyre könnyebbé válik a szolgáltatások elérése (pl, Exchange Online, Microsoft Teams), már akár az otthoni tableten is gond nélkül lehet követni a céges levelezést. Az eszközök védelmét is igyekeznek úgy-ahogy megoldani, általában antivirus megoldás bevezetésével (laptopok esetén, okostelefonoknál szinte semmi…)

Ettől függetlenül azonban a szervezeteknél még mindig kardinális kérdés maradt a klasszikus céges hálózat védelme. Ez érthető, hiszen a nagyon új, “felhőben született” cégeket leszámítva, mindenki rendelkezik földi infrasruktúrával, ott található az identitás-középpont (Active Directory), és a céges erőforrások nagy része is. A védelemre jellemzően nagy figyelmet fordítanak, robosztus tűzfalrendszer-megoldások, IDS/IPS, DDOS védelem,bonyolult VPN-es megoldások, ezekre hajlamosak milliókat is költeni. Sok esetben csak annyi a gondolatmenet, hogy “mi védettek vagyunk, minket nem lehet feltörni”

A gond ott kezdődik, hogy ezek a védelmi megoldások csak “kintről”, az internet felől élnek. Mi történik, ha egy mobilkliens bekerül a céges hálózatba? Semmi, hiszen a határon belül van, nem vonatkozik rá védelmi policy. Sok terméknél a belső hálózat esetén leold minden védelem, az eszköz “szabaddá válik”.

(Természetesen, vannak megoldások a belső hálózat védelmére, kliensek szűrésére. Régen a Microsoft Network Access Protection tudta ellátni ezt a feladatot, illetve a Cisco-nak is van ilyen terméke)

A céges adatok, adatvagyon védelme viszont ugyanúgy lényeges, nem számít, honnan érik el a kliensek, külső vagy belső hálózatból. Itt jön a képbe a Zero Trust megközelítés:

“Állandó ellenőrzés, bizalom nélkül!”

A Zero Trust három alapelve:

  • az identitás (felhasználó hitelesítése) ellenőrzése
  • az eszköz védelme (egészségi állapota legyen megfelelő)
  • hozzáférés ellenőrzése (csak annyi jogosultsága legyen a felhasználónak, és csak azokhoz, ami éppen szükséges)

Hogyan biztosíthatók ezek?

Identitás védelmének erősítése és megkövetelése: többfaktoros hitelesítés megkövetelésével, biometrikus azonosítási megoldásokkal, jelszavak felszámolásával

Eszköz állapota: az eszközök MDM-megoldásba bevonásával, megfelelő egészség-állapot megkövetelésével (device health)

Least privileged user rights: senkinek ne legyen több jogosultsága, mint szükséges

A fenti három tétel megvalósításával (vonatkozzon ez külső-belső hálózatra) nagy lépés lehet tenni a biztonság növelésére.

A Microsoft Zero Trust architektúráját a lenti ábra szemlélteti:

A megoldás lényege: a felhasználó az Azure AD-ban hitelesíti magát (MFA-val), az eszközének felügyeletét az Intune látja el. Az Itune előír egy bizonyos egészség-állapotot az eszköz számára (pl. kötelező lennie vírusirtó megoldásnak, vagy PIN kód és eszköztitkosítás megléte). Az Azure AD Conditional Access megköveteli, felhasználó esetén kockázati szint nem lehet magas (azaz nem komprimittálódott az accountja, nem voltak gyanús bejelentkezési kísérletei több országból stb.). Szintén megkövetelhető, hogy milyen alkalmazásokkal lehet elérni a céges erőforrásokat. A Conditional Access segítségével ez a végtelenségig variálható, a szervezet igényei szerint.

Az utolsó jobboldali kockán látjuk az Azure Application Proxy megnevezést. Ennek segítségével földi (on-premise) erőforrásokat tudunk biztonságosan publikálni, adott esetben a földi Sharepoint elérését is a fenti feltételrendszehez köthetjük. Még akkor is, ha a kliens és az SP szerver egy hálózatban vannak!

Összefoglalva: az Azure AD-Intune-Azure Application Proxy segítségével megvalósulhat a Zero Trust Modell, amellyel valós időben szűrhető-engedhető-tiltható, hogy milyen erőforrást milyen felhasználó, milyen feltételekkel érhet el.

A Zero Tust Modell felé elmozdulás nagyon ajánlott minden szervezet számára, megfelelő feltételek biztosításval kielégíti a biztonsági és felhasználói élmények iránti igényeket.

SCCM Capture “A fatal error occurred while trying to sysprep the machine.”

Image

Reply

Yesterday I ran into a weird issue when I tried to capture a Windows 10 image with sccm.

‘A fatal error occurred while trying to sysprep the machine.’

Let’s check the logfile: c:\windows\system32\sysprep\panther\setuperr.log

Hmm, the problem is related with one of the built-in application.
I didnt want to remove these apps.

In this Windows installation, the local username created for first time was ‘User’

In this time, I had an idea…what if local username was the problem?

Immediately I installed another image where the local username was ‘SCCM’. Test with sysprep…bamm, sysprep ran without error!

 

Wrapping up: do not use built-in usernames like ‘user’ or ‘administartor’ etc. Local username should be unique

Certificate érvényességi idejének módosítása

Posted on by
Reply

Kezdő CA-üzemeltetőként belefutottam egy problémába:

Szerettem volna egy tanúsítványt 5 évre kiadni. Megnéztem a template-ek között, átállítottam a Validity Periodot, Apply, OK

A tanúsítványt kiállítottam, jött a meglepetés: az érvényességi ideje bizony csak 2 év lett, nem 5.

A megoldás persze triviális volt: mivel ez a CA nem egy CAPolicy.inf file segítségével lett telepítve, alapból 2 év az érvényessége a kiadott certeknek.

Ezt módosítani így lehet:

A CA-n át kell írni a lenti registry kulcsot:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>

ValidityPeriod értéke legyen Years

ValidityPeriodUnits értéke pedig a kívánt érték, pl 5

Kell még egy:        net stop certsvc
net start certsvc

Eután ha kiadjuk a tansúítványt, immár 5 évre fog szólni az érvényessége.

Nem egy nagy dolog, de bosszantó tud lenni 🙂