ACLs - DACLs/SACLs/ACEs

Gebruik Trickest om maklik te bou en outomatiseer werkstrome aangedryf deur die wêreld se mees gevorderde gemeenskapshulpmiddels. Kry Toegang Vandag:

Leer AWS hak van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Toegangsbeheerlys (ACL)

'n Toegangsbeheerlys (ACL) bestaan uit 'n geordende stel Toegangsbeheerinskrywings (ACEs) wat die beskerming vir 'n voorwerp en sy eienskappe bepaal. In wese bepaal 'n ACL watter aksies deur watter sekuriteitsprinsipale (gebruikers of groepe) toegelaat of ontken word op 'n gegewe voorwerp.

Daar is twee soorte ACLs:

  • Diskresionêre Toegangsbeheerlys (DACL): Spesifiseer watter gebruikers en groepe toegang tot 'n voorwerp het of nie.

  • Stelseltoegangsbeheerlys (SACL): Beheer die ouditering van toegangspogings tot 'n voorwerp.

Die proses van die toegang tot 'n lêer behels dat die stelsel die sekuriteitsbeskrywing van die voorwerp teen die gebruiker se toegangsteken nagaan om te bepaal of toegang verleen moet word en die omvang van daardie toegang, gebaseer op die ACEs.

Kernkomponente

  • DACL: Bevat ACEs wat toegangsregte aan gebruikers en groepe vir 'n voorwerp verleen of ontken. Dit is in wese die hoof-ACL wat toegangsregte bepaal.

  • SACL: Word gebruik vir die ouditering van toegang tot voorwerpe, waar ACEs die tipes toegang definieer wat in die Sekuriteitsgebeurtenisjoernaal gelog moet word. Dit kan van onschatbare waarde wees om ongemagtigde toegangspogings op te spoor of toegangsprobleme op te los.

Stelselinteraksie met ACLs

Elke gebruikersessie is geassosieer met 'n toegangsteken wat sekuriteitsinligting wat relevant is vir daardie sessie bevat, insluitend gebruiker-, groepidentiteite en voorregte. Hierdie teken sluit ook 'n aanmeldings-SID in wat die sessie uniek identifiseer.

Die Plaaslike Sekuriteitsowerheid (LSASS) verwerk toegangsaanvrae tot voorwerpe deur die DACL te ondersoek vir ACEs wat ooreenstem met die sekuriteitsprinsipaal wat toegang probeer verkry. Toegang word onmiddellik verleen as geen relevante ACEs gevind word nie. Andersins vergelyk LSASS die ACEs teen die sekuriteitsprinsipaal se SID in die toegangsteken om toegangsgeregtigheid te bepaal.

Gesommeerde Proses

  • ACLs: Definieer toegangsregte deur DACLs en ouditeringsreëls deur SACLs.

  • Toegangsteken: Bevat gebruiker-, groep- en voorreginligting vir 'n sessie.

  • Toegangsbesluit: Word gemaak deur DACL ACEs met die toegangsteken te vergelyk; SACLs word gebruik vir ouditering.

ACEs

Daar is drie hooftipes Toegangsbeheerinskrywings (ACEs):

  • Toegang Geweier ACE: Hierdie ACE ontken uitdruklik toegang tot 'n voorwerp vir gespesifiseerde gebruikers of groepe (in 'n DACL).

  • Toegang Toegelaat ACE: Hierdie ACE verleen uitdruklik toegang tot 'n voorwerp vir gespesifiseerde gebruikers of groepe (in 'n DACL).

  • Stelseloudit ACE: Geplaas binne 'n Stelseltoegangsbeheerlys (SACL), is hierdie ACE verantwoordelik vir die genereer van ouditlogboeke tydens toegangspogings tot 'n voorwerp deur gebruikers of groepe. Dit dokumenteer of toegang toegelaat of ontken was en die aard van die toegang.

Elke ACE het vier kritieke komponente:

  1. Die Sekuriteitsidentifiseerder (SID) van die gebruiker of groep (of hul hoofnaam in 'n grafiese voorstelling).

  2. 'n Vlag wat die ACE-tipe identifiseer (toegang geweier, toegelaat, of stelseloudit).

  3. Oorerwingvlagte wat bepaal of kindervoorwerpe die ACE van hul ouer kan oorneem.

  4. 'n toegangsmasker, 'n 32-bis-waarde wat die verleenregte van die voorwerp spesifiseer.

Toegangsbepaling word uitgevoer deur elke ACE sekwensieel te ondersoek totdat:

  • 'n Toegang Geweier ACE die versoekte regte uitdruklik ontken aan 'n trustee wat in die toegangsteken geïdentifiseer is.

  • Toegang Toegelaat ACE(s) verleen alle versoekte regte uitdruklik aan 'n trustee in die toegangsteken.

  • Na die ondersoek van alle ACEs, as enige versoekte reg nie uitdruklik toegelaat is nie, word toegang implisiet ontken.

Volgorde van ACEs

Die manier waarop ACEs (reëls wat sê wie toegang tot iets kan hê of nie) in 'n lys genaamd DACL geplaas word, is baie belangrik. Dit is omdat sodra die stelsel toegang gee of ontken op grond van hierdie reëls, hou dit op om na die res te kyk.

Daar is 'n beste manier om hierdie ACEs te organiseer, en dit word "kanoniese volgorde" genoem. Hierdie metode help om seker te maak dat alles glad en regtig werk. Dit gaan so vir stelsels soos Windows 2000 en Windows Server 2003:

  • Plaas eers al die reëls wat spesifiek vir hierdie item gemaak is voor diegene wat van elders kom, soos 'n ouermap.

  • In daardie spesifieke reëls, plaas diegene wat sê "nee" (ontken) voor diegene wat sê "ja" (toelaat).

  • Vir die reëls wat van elders kom, begin met diegene van die nabyste bron, soos die ouer, en gaan dan terug van daar af. Weereens, plaas "nee" voor "ja."

Hierdie opstelling help op twee groot maniere:

  • Dit maak seker dat as daar 'n spesifieke "nee" is, dit geëerbiedig word, ongeag watter ander "ja" reëls daar is.

  • Dit laat die eienaar van 'n item die laaste sê hê oor wie binnekom, voordat enige reëls van ouer-mappe of verder terug in werking tree.

Deur dit op hierdie manier te doen, kan die eienaar van 'n lêer of vouer baie presies wees oor wie toegang kry, en sorg dat die regte mense binnekom en die verkeerde nie.

So, hierdie "kanoniese volgorde" gaan alles oor om seker te maak dat die toegangsreëls duidelik en goed werk, spesifieke reëls eerste te plaas en alles op 'n slim manier te organiseer.

Gebruik Trickest om maklik te bou en outomatiseer werkstrome aangedryf deur die wêreld se mees gevorderde gemeenskapshulpmiddels. Kry Toegang Vandag:

GUI Voorbeeld

Voorbeeld van hier

Dit is die klassieke sekuriteitstabaan van 'n vouer wat die ACL, DACL en ACEs wys:

As ons op die Gevorderde knoppie klik, sal ons meer opsies soos erfenis kry:

En as jy 'n Sekuriteitsprinsipaal byvoeg of wysig:

En laastens het ons die SACL in die Oudit-taba:

Verduideliking van Toegangsbeheer op 'n Vereenvoudigde Manier

Wanneer ons toegang tot hulpbronne, soos 'n vouer, bestuur, gebruik ons lyste en reëls bekend as Toegangsbeheerlyste (ACLs) en Toegangsbeheerinskrywings (ACEs). Hierdie definieer wie sekere data kan of nie kan benader nie.

Toegang tot 'n Spesifieke Groep Weier

Stel jou het 'n vouer genaamd Koste, en jy wil hê dat almal dit kan benader behalwe vir 'n bemarkingsspan. Deur die reëls korrek op te stel, kan ons verseker dat die bemarkingsspan eksplisiet die toegang ontneem word voordat almal anders toegang kry. Dit word gedoen deur die reël om toegang te weier aan die bemarkingsspan te plaas voordat die reël wat toegang aan almal toelaat.

Toegang toelaat aan 'n Spesifieke Lid van 'n Geweierde Groep

Laat ons sê Bob, die bemarkingsdirekteur, toegang tot die Koste-vouer nodig het, selfs al behoort die bemarkingsspan normaalweg nie toegang te hê nie. Ons kan 'n spesifieke reël (ACE) vir Bob byvoeg wat hom toegang verleen, en dit voor die reël plaas wat toegang aan die bemarkingsspan ontken. Op hierdie manier kry Bob toegang ten spyte van die algemene beperking op sy span.

Begrip van Toegangsbeheerinskrywings

ACEs is die individuele reëls in 'n ACL. Hulle identifiseer gebruikers of groepe, spesifiseer watter toegang toegelaat of geweier word, en bepaal hoe hierdie reëls van toepassing is op sub-items (erfenis). Daar is twee hooftipes ACEs:

  • Generiese ACEs: Hierdie is breed van toepassing, wat óf al die tipes voorwerpe beïnvloed óf slegs onderskei tussen houers (soos vouers) en nie-houers (soos lêers). Byvoorbeeld, 'n reël wat gebruikers toelaat om die inhoud van 'n vouer te sien maar nie om die lêers daarin te benader nie.

  • Voorwerpspesifieke ACEs: Hierdie bied meer presiese beheer, wat reëls toelaat om ingestel te word vir spesifieke tipes voorwerpe of selfs individuele eienskappe binne 'n voorwerp. Byvoorbeeld, in 'n gids van gebruikers, mag 'n reël 'n gebruiker toelaat om hul telefoonnommer op te dateer maar nie hul aanmeldingstye nie.

Elke ACE bevat belangrike inligting soos aan wie die reël van toepassing is (deur 'n Sekuriteitsidentifiseerder of SID te gebruik), wat die reël toelaat of weier (deur 'n toegangsmasker te gebruik), en hoe dit deur ander voorwerpe geërf word.

Sleutelverskille Tussen ACE-tipes

  • Generiese ACEs is geskik vir eenvoudige toegangsbeheerscenarios, waar dieselfde reël van toepassing is op alle aspekte van 'n voorwerp of op alle voorwerpe binne 'n houer.

  • Voorwerpspesifieke ACEs word gebruik vir meer komplekse scenarios, veral in omgewings soos Aktiewe Gids, waar jy dalk toegang tot spesifieke eienskappe van 'n voorwerp andersins moet beheer.

Kortom, ACLs en ACEs help om presiese toegangsbeheer te definieer, wat verseker dat slegs die regte individue of groepe toegang tot sensitiewe inligting of hulpbronne het, met die vermoë om toegangsregte te spesifiseer tot op die vlak van individuele eienskappe of voorwerptipes.

Toegangsbeheerinskrywinguitleg

ACE-veldBeskrywing

Tipe

Vlag wat die tipe ACE aandui. Windows 2000 en Windows Server 2003 ondersteun ses tipes ACE: Drie generiese ACE-tipes wat aan alle beveiligbare voorwerpe geheg is. Drie voorwerp-spesifieke ACE-tipes wat vir Aktiewe Gids-voorwerpe kan voorkom.

Vlae

Stel van bietjievlags wat erfenis en ouditering beheer.

Grootte

Aantal bytes van geheue wat vir die ACE toegewys is.

Toegangsmasker

32-bisewaarde waarvan die bietjies ooreenstem met toegangsregte vir die voorwerp. Bietjies kan óf aan óf af gestel word, maar die betekenis van die instelling hang af van die ACE-tipe. Byvoorbeeld, as die bietjie wat ooreenstem met die reg om toestemmings te lees, aangeskakel is, en die ACE-tipe is Weier, weier die ACE die reg om die voorwerp se toestemmings te lees. As dieselfde bietjie aangeskakel is maar die ACE-tipe is Toelaat, verleen die ACE die reg om die voorwerp se toestemmings te lees. Meer besonderhede van die Toegangsmasker verskyn in die volgende tabel.

SID

Identifiseer 'n gebruiker of groep wie se toegang deur hierdie ACE beheer of gemonitor word.

Toegangsmaskeruitleg

Bietjie (Reeks)BetekenisBeskrywing/Voorbeeld

0 - 15

Voorwerp Spesifieke Toegangsregte

Lees data, Uitvoer, Voeg data by

16 - 22

Standaard Toegangsregte

Skrap, Skryf ACL, Skryf Eienaar

23

Kan toegang tot sekuriteit ACL kry

24 - 27

Voorbehou

28

Generiese ALLES (Lees, Skryf, Uitvoer)

Alles hieronder

29

Generiese Uitvoer

Alles wat nodig is om 'n program uit te voer

30

Generiese Skryf

Alles wat nodig is om na 'n lêer te skryf

31

Generiese Lees

Alles wat nodig is om 'n lêer te lees

Verwysings

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Gebruik Trickest om maklik werkvloeie te bou en outomatiseer met behulp van die wêreld se mees gevorderde gemeenskapsinstrumente. Kry Vandag Toegang:

Last updated