In het hoofdscherm worden gebruikers, groepen en resources gedefinieerd.

Hogere beveiligingsniveau's voor standaard operating systems

Het grootste probleem in het beveiligingsmodel van de Unix en Windows operating systems is dat de superuser alles mag op zijn machine. Niet alleen heeft hij toegang tot alle bestanden, processen en het hele geheugen, hij mag zelfs de log bestanden aanpassen. Access Control van Computer Associates breidt het standaard security model van deze systemen uit, zodat resources sterker van elkaar kunnen worden afgescheiden, en de onbeperkte rechten van de superuser aan banden kunnen worden gelegd.

Het grootste probleem in het beveiligingsmodel van de meestgebruikte operating systems is dat de superuser alles mag op zijn machine. Onder Unix gaat het dan om het root account, en onder Windows om de Administrator. Deze superusers hebben altijd toegang tot alle bestanden, tot alle processen en tot het hele geheugen. Zij mogen zelfs de log files van het systeem aanpassen.

Hoewel dit model voor beginners snel te doorgronden is, en het leven van de systeembeheerder eenvoudig houdt, brengt het grote veiligheidsrisico's met zich mee. Het meest in het oog springende daarvan is natuurlijk dat het hele systeem in één keer verloren is als kwaadwillenden eenmaal root access op de machine hebben weten te bemachtigen. Maar ook type- en andere fouten die in een root terminal worden gemaakt, kunnen grote schade opleveren.

Maximale bewegingsvrijheid

De belangrijkste constatering is echter dat deze maximale bewegingsvrijheid voor de superuser zonder meer onnodig is, en de bijkomende risico's dus vermeden kunnen worden. Waarom zou de beheerder van een systeem ook de log files mogen veranderen? De enige reden dat deze dat inderdaad kan, is omdat diezelfde superuser die de log files als enige moet kunnen lezen en roteren, daarvoor in het klassieke security model ook de eigenaar van die bestanden moet zijn. Hetzelfde geldt voor de bestanden van de gebruikers. Waarom zou de superuser deze mogen lezen en mogen veranderen? Alleen omdat deze toevallig ook de home directory van deze gebruiker beheert? Vergelijkbare argumenten voor databases, transactieverwerkers en andere applicaties zijn ook zo te bedenken.

Hackers maken dankbaar gebruik van de eenvoud van dit model. Iemand die toegang weet te krijgen tot het superuser account van een systeem, installeert daarop direct een standaard hackers toolkit die ervoor zorgt dat alle sporen van de inbraak automatisch worden verwijderd. Bovendien wordt alle activiteit van de hacker verborgen gehouden voor de beheerders: logs worden niet weggeschreven, entries in de process tables worden aangepast of weggelaten, en standaard daemons worden voorzien van een achterdeurtje. De enige manier om een dergelijk systeem weer op orde te krijgen, is het compleet terugzetten van een eerdere installatie. In het ergste geval, als geen backup van het originele, onbesmette systeem meer beschikbaar is, moet de hele configuratie opnieuw worden opgebouwd.

Access Control

Gecertificeerde systemen - vroeger volgens de Orange Book specificaties, tegenwoordig volgens de Common Criteria (ISO 15408) - steken dan ook een stuk ingewikkelder in elkaar. De log en audit files kunnen door geen enkele gebruiker worden veranderd. Ook de beheerders kunnen deze alleen lezen. Daarnaast is er een veel sterkere afscherming tussen de verschillende gegevensbestanden, applicaties en andere resources. In het algemeen geldt voor deze systemen dat ze steeds verder en strikter zijn gecompartimenteerd naarmate ze op een hoger niveau zijn gecertificeerd.

eTrust Access Control van Computer Associates levert vergelijkbare mogelijkheden voor standaard Unix en Windows machines. De zogenaamde Dynamic Security Extension (DSX) technologie maakt daarvoor gebruik van een agent op het host systeem. Access control policies die centraal kunnen worden opgeslagen en op afstand kunnen worden beheerd, worden afgedwongen door de agents die alles wat er op de host systemen gebeurt in de gaten houden. Op dit moment zit de software in het traject voor certificering op Common Criteria niveau EAL 4 (vergelijkbaar met het oude Orange Book B1 niveau). Het spreekt daarmee vanzelf dat het geen zin heeft om Access Control te installeren op speciale operating systems die al voor dit niveau zijn gecertificeerd.

Hoewel de agents er ook voor Windows (NT, 2000, XP en 2003) zijn, installeerden we voor deze gelegenheid Access Control for Unix versie 5.3 op een standaard Red Hat Enterprise Linux ES versie 3 systeem.

Agent

De installatie zelf verloopt van een leien dakje. Alleen security administrators mogen de instellingen veranderen, en alleen leden van de audit groep mogen ook de audit files lezen. De root heeft alleen toegang als dat expliciet in de policies wordt opgegeven. Dat doe je natuurlijk niet, want het doel van deze hele exercitie was juist om de rechten van de root in te perken en de verschillende functies zoveel mogelijk van elkaar af te schermen. De Access Control gebruikersdatabase kan worden ingelezen van de locale passwd en group files en/of uit NIS. In principe hoeven alleen de gebruikers waarvoor speciale regels gelden ook in de gebruikersdatabase te worden opgenomen, de anderen niet. In de Policy Manager, de grafische (remote) management omgeving, kunnen gebruikers in beide "lijsten" tegelijkertijd worden beheerd.

Policies kunnen op een aparte server in een policy model database worden opgeslagen, en vandaaruit naar de verschillende host systemen worden verspreid. De communicatie tussen de systemen en de beheersomgeving kan beveiligd worden met DES of Triple DES (3DES). Omdat het hier gaat om een symmetrisch encryptieprotocol, niet om een public key systeem (vergelijk RSA), moet daarvoor dus wel een geheime sleutel op alle machines worden geïnstalleerd. Hoewel je van start kunt gaan met de meegeleverde standaard sleutels, hebben die voor de echte beveiliging natuurlijk geen zin.

De Access Control agent die de policies op het host systeem afdwingt kan lokaal (vanaf de command line of in een boot script) worden opgestart, of op afstand met een seload commando. Voor die laatste mogelijkheid wordt het seosload service daemon in de inetd configuratie (/etc/services) opgenomen. Via poort 8892 kan de management software dan de agent (daemons) opstarten. Deze installeren de eTrust kernel module en library hooks. Is de agent eenmaal in de lucht, dan worden de ingestelde policies afgedwongen, en kunnen we in de audit file precies zien wie wat doet, welke processen daarvoor worden opgestart, en welke files daardoor worden benaderd. De drie daemons waaruit de Access Control agent bestaat, houden elkaar constant in de gaten. Mocht een daarvan "iets overkomen", dan wordt deze door de andere weer opnieuw opgestart.

Policy Manager

Het hele Access Control pakket is direct lokaal te besturen via de selang command line interpreter of een grafische tool. De interpreter is vooral handig bij de installatie en voor het gebruik in scripts. Voor dagelijks gebruik is de meegeleverde Policy Manager voor Windows onontbeerlijk. Met deze grafische management tool kunnen de policies op afstand centraal worden beheerd. De functionaliteit van de Policy Manager is hetzelfde als die van de selang commando's.

In het hoofdscherm worden gebruikers, groepen en resources gedefinieerd.
In het hoofdscherm worden gebruikers, groepen en resources gedefinieerd.

De Policy Manager geeft ons een veel duidelijker overzicht van de mogelijkheden van het Access Control pakket dan de selang commando's dat doen. In het hoofdscherm worden gebruikers, groepen en resources gedefinieerd. Die laatste categorie bestaat uit een hele lijst met allerlei verschillende zaken: files, groepen van files, programma's, processen, terminals, netwerken, remote hosts, en de login applicaties als telnet, ssh, ftp, Kerberos, de rtools en de X desktop omgeving. Vervolgens worden de rechten van gebruikers op de resources gespecificeerd: wie de eigenaar is, welke gebruikers toegang hebben en op welke manier, wat precies in de audit file gelogd wordt, en wanneer een notificatie per e-mail wordt verzonden. Eventueel kunnen die rechten nog worden gekoppeld aan een kalender, zodat bepaalde rechten bijvoorbeeld alleen gedurende werktijden en niet in vakanties beschikbaar zijn.

De configuratie is vooral een kwestie van een heleboel informatie invullen in allerlei windows.
De configuratie is vooral een kwestie van een heleboel informatie invullen in allerlei windows.

Rule sets

Voor de eenvoudige taken, zoals bijvoorbeeld het aanmaken van een nieuwe gebruiker, zijn wizards beschikbaar. De overige configuraties zijn vooral een kwestie van een heleboel informatie invullen in allerlei windows. Gelukkig kunnen bij de installatie op de host ook gelijk de Baseline Security Pack Rules worden geïmplementeerd. Daarmee wordt het operating system direct van een set basis instellingen voorzien. Het gemakkelijkst is om daar van uit te gaan, en deze set regels vervolgens naar eigen inzicht en voor de eigen specifieke situatie verder aan te passen en te verfijnen.

De services organisatie van CA heeft ook weer voor verschillende applicaties als SAP en Oracle al sets van policy regels die bij de implementatie van Access Control als basis kunnen worden gebruikt. Bovendien wordt een nieuwe configuratie meestal eerst een aantal maanden in warning modus gedraaid. In die tijd wordt steeds gekeken welke acties om welke redenen door het systeem zouden worden geweigerd, zodat de instellingen in die tijd steeds verder aangepast en verfijnd kunnen worden. Pas daarna wordt Access Control ook daadwerkelijk geactiveerd en worden de regels keihard afgedwongen.

Hier in Nederland is men bij de ABN-Amro een jaar bezig geweest met een hele uitgebreide implementatie van Access Control. Van de drie andere grote Nederlandse banken wordt deze oplossing ook nog door twee andere gebruikt. Hiervoor werkt CA samen met Quinse, dat zich heeft gespecialiseerd in de beveiling van de infrastructuren voor deze sector.

Plaats reactie

Security code Vernieuwen

Verstuur