Security Professionals - ipfw add deny all from eindgebruikers to any

Periodiek bulk administrator wachtwoord aanpassen

18-06-2013, 09:43 door Pandit, 10 reacties
Hallo Security professionals.

Binnen een complexe multidomain \ multiforest \ workgroup \ DMZ omgeving met ca. 2000 Windows servers (2000\2003 en 2008 servers) en ca 600 Unix\Linux systemen willen we de lokale beheerwachtwoorden maandelijks wijzigen op een uniforme manier. Ik heb het internet afgestruind naar mogelijke oplossingen en niets gevonden. Wel oplossingen, maar die zijn niet inzetbaar zo is middels Group policies veel mogelijk, maar niet op standalone servers en zeker niet op Linux\Unix, al wil ik voor deze servers een andere methodiek in zetten.

Ik ben zeer benieuwd hoe andere organisaties die op hebben gelost

Ik heb al een theoretische methode bedacht maar hou deze nu nog voor mezelf en zal ik laten uitleggen.

Pandit
Reacties (10)
18-06-2013, 10:06 door Anoniem
Lijkt me dat je lokale beheerswachtwoorden gewoon niet moet willen gebruiken in een omgeving met 2600 servertjes, hooguit als laatste redmiddel. En dan is een 20-tekens willekeurig wachtwoord in een verzegelde envelop in een kluis een prima oplossing. Als je desondanks bang bent voor misbruik zet je maar een alert op het gebruik van deze niet-te-gebruiken logins. Niet moeilijk gaan doen met maandelijks veranderen, dat doe je maar met je dagelijks-gebruik beheerswachtwoorden, en die kunnen mooi in een gecentraliseerd systeem. Het systeem moet wel werkbaar blijven.
18-06-2013, 10:41 door yobi
Sommige organisaties doen het zo voor Windows:
Hernoem de locale administrator naar iets onzinnigs (random karakters). Geef deze een wachtwoord, die niet met Ophcrack te achterhalen is.
Maak een nieuwe administrator zonder rechten.

Doe het beheer met een domain-admin account. Open geen mail met dergelijke accounts, maar geef de administrators een extra normaal account voor het openen van mail.
18-06-2013, 13:15 door Anoniem
"Hernoem de locale administrator naar iets onzinnigs (random karakters). Geef deze een wachtwoord, die niet met Ophcrack te achterhalen is.
Maak een nieuwe administrator zonder rechten."


Dit heeft weinig tot geen effect; in principe is elk wachtwoord te kraken met Lopht als je maar lang genoeg wacht.

het hernoemen heeft ook weinig zin; bij het enumeraten van de accounts op een server zie je direct welk account de echte administrator is; (Security ID) eindigt op 500.
uit ervaring zou ik eerst enumeraten voor ik een bruteforce los zou laten om de hoeveelheid werk te beperken.

Voor de rest heeft Yobi wel gelijk; al admin niet aanloggen met extra rechten anders dan de mogelijkheid om een remote desktop naar een stepstone server te verbinden.


Uitgaande van het feit dat alle servers in AD staan kun je eenvoudig een script gebruiken wat alle computer accounts list en dat dan gebruikt om remote de machines te benaderen en het wachtwoord te wijzigen; geen rocketscience. Een wachtwoord gebaseerd op input + machinenaam = nieuwe wachtwoord oid


Voor standalone servers kun je een inputfile gebruiken met dezelfde functionaliteit.
18-06-2013, 13:21 door Anoniem
Niet goedkoop, wel erg goed: Cyber-Ark Enterprise Password Vault.

Het is in feite een wachtwoord kluis met daarbij de mogelijkheid om die wachtwoorden geheel geautomatiseerd te beheren op de achterliggende systemen. Via de front end kunnen eindgebruikers toegang krijgen tot een of meerdere passwords.

Het kan accounts op veel platforms beheren zoals Active Directory, lokale Windows servers, Unix Linux etc., maar voor databases, appliances (firewalls etc.) maar de lijst is veel langer.

Enorme mogelijkheden met parameterisering, policies, gebruik van groepsgewijze wachtwoorden, verschillende authenticatie methodes voor eindgebruikers (= administrators), multifactor authenticatie etc.

Ik ben al zo'n 2 jaar bezig met de implementatie hiervan in meerdere grote internationale organisaties.
Implementatie vergt zeker de nodige inspanning, maar dat mag duidelijk zijn met zo veel mogelijkheden.
18-06-2013, 13:53 door Anoniem
Voor resp. *nix en de routers hebben wij gewoon authoriatie op basis van openldap cq. radius/AAA. Centraliseren die inlog's dus. En anders is er nog iets als puppet, cfengine en familieleden.

Je noemt 600 systemen. Als je nog nooit over dit soort 'randspul' eromheen hebt nagedacht, dan doen jullie jezelf al jaren tekort.

Aan windows opmerkingen brandt ik mijn vingers in dit forum niet.
18-06-2013, 15:29 door Anoniem
De echte oplossing voor dit soort zaken zit hem in dit soort produkten:

http://www.ca.com/us/privileged-user.aspx

Nee ik heb geen aandelen en ik werk er ook niet, er zijn vast meer alternatieven.
18-06-2013, 15:33 door Anoniem
Wij doen dit maandelijks met powershell op Windows servers.
En het password is telkens random aangemaakt voor een bepaalde groep servers (Exchange, SQL, SCCM, etc).
Ik zou ook de passwords op Linux en Windows servers verschillend houden.

$strcomputers = Get-Content d:\scripts\passwords\servers.txt
foreach ($strcomputer in $strcomputers) {
$admin=[adsi]("WinNT://" + $strComputer + "/Administrator") `
$admin.psbase.invoke("SetPassword", "Password") }
18-06-2013, 19:06 door [Account Verwijderd]
[Verwijderd]
18-06-2013, 21:51 door sjonniev
Gebruik smart cards. Met op de smart card gegenereerde sleutelparen. Certificeer de publieke sleutels. Distribueer de publieke sleutels. Vergeet wachtwoorden. Onthou je PIN. Helaas niet overal toepasbaar (luister je, Apple?).
18-06-2013, 22:18 door Pandit
Bedank allemaal voor de vele reacties, Omdat Cyber-Ark Enterprise Password Vault. toch behoorlijk prijzig was hebben we een pilot gedaan met password manager pro, waar we alle onpersoonlijke accounts in wilden plaatsen. Omdat PMP voor een dergelijke grote omgeving te licht is (het beheer zou een nachtmerrie worden) hebben we het project na de pilot niet gecontinueerd. Ik ga ook kijken naar het product van anoniem 15:29. Verder deel ik de mening dat we alleen via domein beheeraccounts en niet via lokale beheeraccounts moeten inloggen, Voor sommige systemen zoals profilemachines voor Citrix , standalone en DMZ servers moeten we toch iets bedenken.

Ik heb ook aan powershell gedacht en dan via remote administration. alleen voor DMZ server wordt dit lastig door de communicatie via wmi met wisselende poorten. We zitten nog niet op 2012 die gebruik maakt van CIM (http(s)

Het idee wat ik had is het volgende: Bij ons is HP-OM de standaard monitoringtool. Op alle Windows en *nix systemen staan de HP-OM agents. Via de centrale HP-OM console kunnen we allemaal scripts afvuren op (groepen) machines. Mijn idee is om een script te schrijven die de wachtwoorden van alle systemen middels een scheduled job in HP-OM afvuurt naar groepen systemen. Hierdoor voldoe ik aan de eis dat er 1 methodiek moet zijn voor alle systemen. Als is het script voor *nix uiteraard anders dan voor Windows, en dat deel laat ik graag aan onze *nix beheerders over (Ik zit zelf in een Windows beheerteam). De volgende vraag die ik heb is of de communicatie tussen HP-OM en de machines secure is, anders moet ik hier ook iets voor gaan regelen. Het moet allemaal wel allemaal secure.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.