automatische blokkade tijd omhoog na meerdere blokkades

[lawkexarib]

Hallo allemaal,

Onlangs heeft mijn werkgever de volgende vraag/wens aan onze IT-support leverancier gevraagd te kijken of het mogelijk is binnen onze Windows Server 2008 R2 of via een third-party tool voor Active Directory dat een account automatisch weer gedeblokkeerd, maar de automatische deblokkade moet aan volgende eisen voldoen:

1. Account geblokkeerd? Automatisch deblokkade van een account na 5 minuten
2. Dezelfe account weer geblokkeerd? Automatisch deblokkade van dezelfde account na 10 minuten
3. Dezelfde account geblokkeerd? Automatisch deblokkade van dezelfde account na 15 minuten

Het antwoord van onze IT-suppoert leverancier was dit niet mogelijk was en er geen third-party tools zijn voor Active Directory die deze extra functionatliteit toevoegen aan de Active Directory.

Uit eigen ervaring weet ik dat het automatisch deblokkeren mogelijk is in Active Directory na x aantal minuten, maar je kunt niet instellen wat er moet gebeuren als dezelfde account voor tweede, derde en vierde keer geblokkeerd wordt.

En ikzelf heb dit reeds uitgezocht op het net, maar kon niets vinden helaas.

Ik ben dus erg benieuwd of jullie oplossing hebben voor dit probleem/wens en welk third-party tool we moeten gaan gebruiken.

Ook ben ik benieuwd naar jullie ideeen over het automatische deblokkeren ivm beveiliging en zo, maar omdat er per maand ons 60 a 70 calls kost, tikt dit behoorlijk aan.

Alvast bedankt voor jullie feedback.

[Question Mark]

Voor zover ik weet is hier geen tooling voor...

Reguliere useraccounts worden hier overigens automatisch gedeblokkeerd. Voor Admin accounts geldt een strengere password policy: strengere password requirements en deze worden niet automatisch gedeblokkeerd.

Overigens is niet automatisch deblokkeren van locked accounts ook niet altijd even zuiver... hoe ga je controleren of de gebruiker die belt ook daadwerkelijk de gebruiker is wiens account gelocked is? Da's ook wel weer op te lossen met procedures, maar dat wordt nog wel eens vergeten te implementeren.

[lawkexarib]

Hi Question Mark,

Momenteel wordt er bij ons geen enkele accounts automatisch gedeblokkeerd, maar vanwege teveel calls p.m. voor een w.w. reset wilde men kijken naar mogelijkheden binnen de Windows Server om accounts automatisch te deblokkeren.
Het is de bedoeling dat bij automatisch deblokkeren juist automatisch gaat. Er worden dus geen vragen gesteld :-)

[F_J_K]

Dat hebben ze waar ik nu zit opgelost door account inschakelen decentraal te beleggen bij key users. Die dan maar enkele verzoeken krijgen - en vooral de betreffende persoon zowel kennen als aanspreken.

[lawkexarib]

hi F_J_K,

Ik snap je punt niet.
Bedoel je soms dat de key users toegang hebben tot de AD en geblokkeerd accounts kunnen deblokkeren?

Een mogelijk voor ons zou bijv. zijn om een power shell script te maken en die een keer per half uur draait om geblokkeerde accounts automatisch te laten deblokkeren. Dus als je geluk hebt , is jouw account direct weer gedeblokkeerd en anders een half uurtje op wachten?

[tweakict]

Met Delegation of Control kun je bepaalde gebruikers dmv RSAT tools toegang bieden tot een bepaald gebied van de Active Directory. Hierbij kun je dan ook enkel de rechten toekennen om gebruikers in / uit te schakelen en het wachtwoord aan te passen.

Maar waar ik meer benieuwd naar ben; waarom worden deze accounts zo vaak geblokkeerd. De oorzaak achterhalen is vaak veel interessanter dan een oplossing bedenken.

De AD bied standaard opties om een account na blokkade weer in te schakelen.

[WeHoDo]

Je kunt met Powershell een script runnen die geblokkeerde accounts unlocked. Deze script laat je dan elke 15 minuten lopen. Je kunt niet zeggen na 1x block, 5 minuten, 2x 10 minuten. Echter is dit script niet veilig.
De oorzaak van een blokkering is er niet voor niets. Zo kan men gewoon bruteforce uitvoeren.

[WeHoDo]

Of kiezen voor inloggen met de vingerscan. Als de oorzaak wachtwoorden kwijt zijn is.

[lawkexarib]

tweakict schreef op woensdag 20 juni 2018 @ 16:47:
Met Delegation of Control kun je bepaalde gebruikers dmv RSAT tools toegang bieden tot een bepaald gebied van de Active Directory. Hierbij kun je dan ook enkel de rechten toekennen om gebruikers in / uit te schakelen en het wachtwoord aan te passen.

Maar waar ik meer benieuwd naar ben; waarom worden deze accounts zo vaak geblokkeerd. De oorzaak achterhalen is vaak veel interessanter dan een oplossing bedenken.

De AD bied standaard opties om een account na blokkade weer in te schakelen.

Eindgebruikers hebben helemaal niets met de ICT en willen ook niets mee te maken, maar het moet wel werken schreeuwen/zuchten ze altijd . Daarbij komt kijken dat we werken op TC via Citrix, dus jah RSAT kan wel beschikbaar stellen, maar dat gaat niet gebeuren.

Het is idd een interessante vraag waarom zo vaak wordt geblokkeerd, terwijl er geen verander policy is voor het wijzigen van een w.w. Misschien last van dikke vingers Geen flauwe idee. Vaak zijn het groepsaccounts die geblokkeerd raken.

[tweakict]

lawkexarib schreef op woensdag 20 juni 2018 @ 17:09:
[...]

Eindgebruikers hebben helemaal niets met de ICT en willen ook niets mee te maken, maar het moet wel werken schreeuwen/zuchten ze altijd . Daarbij komt kijken dat we werken op TC via Citrix, dus jah RSAT kan wel beschikbaar stellen, maar dat gaat niet gebeuren.

Het is idd een interessante vraag waarom zo vaak wordt geblokkeerd, terwijl er geen verander policy is voor het wijzigen van een w.w. Misschien last van dikke vingers Geen flauwe idee. Vaak zijn het groepsaccounts die geblokkeerd raken.

Als IT professional krijg ik hier echt jeuk van. Anno 2018 kan dit echt niet meer. Gebruikers wordt aangeraden om minimaal elke 180 dagen het wachtwoord te wijzigen. Daarnaast met complexiteit e.d.

Dikke vingers kan, maar dan standaard pa na 3-5 foutieve inlogpogingen.

Wat betreft de IT leverancier. Laat hen het uitzoeken waarom dit voorkomt en anders een andere zoeken. Voor jullie; Wellicht is het verstandiger om te praten over een contract ipv uurtje factuurtje. Dan ben je van die 'extra' kosten af voor calls en weet jouw directeur exact waar hij/zij aan toe is per jaar voor support en beheer (als beheer er uberhaubt al is)

Zie ook: https://blog.devolutions....for-system-administrators
NOFI

[F_J_K]

offtopic:
Ik ben meestal geneigd marketingblogs te lezen als marketing, waar toevallig aspecten worden opgesomd waar hun tool aan voldoet.

Sowieso zijn algemene tienpuntslijstjes al snel te algemeen voor toepassing in %jouw% situatie.

Hoe dan ook, vereis bij dat soort policies dat min tijden zijn verdubbeld, max tijden zijn gehalveerd en complexiteitseisen zijn verzwaard voor beheers- en ook serviceaccounts. Zowel vanwege belang als eat your own dog food
Maar goed, offtopic voor de vraag goe om te gaan met de resets.

Ook niet per se eens met dat een externe IT beheerclub beter kan zien waarom zo vaak wordt gereset (anders dan het ter plekke vragen). Dat lijkt me meer een functionele of zelfs organisatorische vraag dan een technische. Behalve als het komt door faudte clients of zo, die oude passwords blijven duwen na een password reset.

lawkexarib schreef op woensdag 20 juni 2018 @ 16:42:
Ik snap je punt niet.
Bedoel je soms dat de key users toegang hebben tot de AD en geblokkeerd accounts kunnen deblokkeren?

Wat @tweakict zei dus, laat het weer ontsluiten over aan zeg een dozijn iets meer tech savvy eindgebruikers per paar honderd medewerkers.

[Question Mark]

lawkexarib schreef op woensdag 20 juni 2018 @ 17:09:
[...]
Daarbij komt kijken dat we werken op TC via Citrix, dus jah RSAT kan wel beschikbaar stellen, maar dat gaat niet gebeuren.

Wat heeft Citrix er mee te maken? Of je nu op een fat client werkt, of op een RDS of VDI oplossing.. in beide gevallen heb je gewoon een werkplek waar tooling op ontsloten kan worden.

Als oplossing voor je probleem zou je kunnen kijken of je deze Citrix oplossing niet kunt koppelen aan een 3rd party Radius server die deze optie wel heeft. Of dit mogelijk is, is afhankelijk van hoe de werkplekken exact worden aangeboden. Zit hier bv. een Access Gateway/Storefront tussen?

Dat zou je wellicht nog met je leverancier kunnen bespreken...

[Evilslayer]

Is een self service password reset tool geen optie? Hiermee kan je eindgebruikers zelf hun eigen gelockte account laten unlocken op basis van enkele vragen/policies/...

[Killah_Priest]

Lockout policies zijn tweeledig : aan de ene kant voorkom je misbruik, aan de andere kant zorg je juist voor een makkelijke denial of service.
In feite is een lockout van enkele seconden al voldoende om brute force aanvallen tegen te gaan (met 30 passwords per seconde kom je immers niet echt ver).

Maar wat de TS wilt is overigens binnen een uurtje opgezet met Powershell.

[Question Mark]

Killah_Priest schreef op woensdag 20 juni 2018 @ 19:01:
Maar wat de TS wilt is overigens binnen een uurtje opgezet met Powershell.

Mwoah... Je zult ergens moeten bijhouden hoeveel een account al locked is in een bepaalde periode, en daar de nieuwe lockout duration op moet baseren... Dat zal waarschijnlijk iets van een centrale database moeten zijn. Tel daarbij op dat dit mechanisme redudant uitgevoerd moet gaan worden...

Dan zie ik niet in hoe dit in een uur gebouwd, geimplementeerd, gedocumenteerd en overgedragen is aan een supportgroep.

[Killah_Priest]

Question Mark schreef op woensdag 20 juni 2018 @ 19:37:
[...]

Mwoah... Je zult ergens moeten bijhouden hoeveel een account al locked is in een bepaalde periode, en daar de nieuwe lockout duration op moet baseren... Dat zal waarschijnlijk iets van een centrale database moeten zijn. Tel daarbij op dat dit mechanisme redudant uitgevoerd moet gaan worden...

Dan zie ik niet in hoe dit in een uur gebouwd, geimplementeerd, gedocumenteerd en overgedragen is aan een supportgroep.

Het testen, documenteren en overdragen daar zit uiteraard (zoals gewoonlijk) meer tijd in als in het bouwen van zo'n script.
Maar een eerste opzet hoeft niet meer als een uurtje te kosten (en dan desnoods met een csv bestand in eerste instantie) en dan laat je direct aan zo'n support partij zien dat het wel mogelijk is (roepen dat iets niet mogelijk is daar heb ik zo'n hekel aan binnen de IT. Als men roept dat het niet rendabel is is het uiteraard een heel ander verhaal).

[ Voor 12% gewijzigd door Killah_Priest op 21-06-2018 00:19 ]

[Verwijderd]

Waarom zou je überhaupt een gebruiker blokkeren? Ik zou eerder het IP-adres in de firewall opnemen (fail2ban style). Gebruiker blokkeren na b.v. 50 pogingen, terwijl je de TCP connectie limiteert op 5 foutieve pogingen.

Het is een leuke vorm van DOS als je iemands gebruikersnaam weet. En erg vervelend als de gebruiker met meerdere apparaten verbind waarvan eentje nog het oude wachtwoord gebruikt (met hogere count kan de gebruiker al zijn apparaten aanpassen naar het nieuwe wachtwoord, zonder geblokkeerd te worden).

Beide mechanismes (blokkeren gebruiker v.s. blokkeren connectie) beschermen niet tegen gestolen wachtwoorden, dat is namelijk de 1e poging raak! Ze beschermen alleen tegen brute force attacks. En daarbij de vraag wat je effectiever vind tegen brute force attacks? Ik ga voor het blokkeren van de verbinding.

Ik noem het blokkeren van accounts "Gebruikers lastig vallen", met als gevolg een hogere call-rate.

tweakict schreef op woensdag 20 juni 2018 @ 17:18:
Als IT professional krijg ik hier echt jeuk van. Anno 2018 kan dit echt niet meer. Gebruikers wordt aangeraden om minimaal elke 180 dagen het wachtwoord te wijzigen.

Als gebruikers me verzekeren complexe wachtwoorden te gebruiken (passphrase style) en het wachtwoord niet hergebruiken, dan ga ik ze niet iedere 180 dagen lastig vallen. Anders gaan gebruikers volggetallen aan wachtwoorden toevoegen, in de vorm van 'wachtwoord1', 'wachtwoord2', etc.

Eens per jaar (of twee) een reset afdwingen is misschien handig, maar helpt alleen tegen phishing (lekkage door hack van derde is geen vector i.v.m. geen wachtwoord hergebruik). En tegen phishing helpt opvoeding, je werkt tenslotte met professionals, niet met kinderen.
^{Oke, oke! "Professionals" trappen ook in CEO fraude... maar ook dat is educatie!}

Gebruik vooral 2FA (of beter)! Wachtwoorden zijn (wat mij betreft) afgeschreven.
^{Wachtwoorden zijn oke voor forums en andere onzinnige websites. Niet om zakelijke authenticatie te realiseren.}

[WhizzCat]

WeHoDo schreef op woensdag 20 juni 2018 @ 16:52:
Je kunt met Powershell een script runnen die geblokkeerde accounts unlocked. Deze script laat je dan elke 15 minuten lopen. Je kunt niet zeggen na 1x block, 5 minuten, 2x 10 minuten. Echter is dit script niet veilig.
De oorzaak van een blokkering is er niet voor niets. Zo kan men gewoon bruteforce uitvoeren.

Dat is een beetje relatief. Als je een fatsoenlijk wachtwoordbeleid hebt (minimaal 8 karakters, hoofd/klein/cijfer/teken en niet vorige x wachtwoorden of lijkend op inlognaam, zoiets ff snel) dan is bruteforcen met 5 of 10 minuten tussen pauze al bijna niet meer te doen.

Ik zou gewoon een redelijke tijd kiezen voor een automatische unlock, zeg 15 minuten. Er staan op Internet wel diverse formules om de tijd uit te rekenen die dan nodig is voor een bruteforce en die is extreem lang

[Croga]

tweakict schreef op woensdag 20 juni 2018 @ 17:18:
Als IT professional krijg ik hier echt jeuk van. Anno 2018 kan dit echt niet meer. Gebruikers wordt aangeraden om minimaal elke 180 dagen het wachtwoord te wijzigen. Daarnaast met complexiteit e.d.

Als IT Professional krijg ik dáár dan weer jeuk van. Anno 2018 is al lang bekend dat periodiek wachtwoord veranderen en complexiteit absoluut zinloze maatregelen zijn die juist de root-cause van geblokkeerde accounts zijn zonder enige verhoging van de veiligheid te bieden......

[Verwijderd]

lawkexarib schreef op woensdag 20 juni 2018 @ 17:09:
[...]

Eindgebruikers hebben helemaal niets met de ICT en willen ook niets mee te maken, maar het moet wel werken schreeuwen/zuchten ze altijd . Daarbij komt kijken dat we werken op TC via Citrix, dus jah RSAT kan wel beschikbaar stellen, maar dat gaat niet gebeuren.

Het is idd een interessante vraag waarom zo vaak wordt geblokkeerd, terwijl er geen verander policy is voor het wijzigen van een w.w. Misschien last van dikke vingers Geen flauwe idee. Vaak zijn het groepsaccounts die geblokkeerd raken.

Wat is een groepsaccount? Als je meerdere mensen op 1 account laat inloggen, dan vraag je er wel een beetje om.

[tweakict]

Croga schreef op donderdag 21 juni 2018 @ 06:57:
[...]

Als IT Professional krijg ik dáár dan weer jeuk van. Anno 2018 is al lang bekend dat periodiek wachtwoord veranderen en complexiteit absoluut zinloze maatregelen zijn die juist de root-cause van geblokkeerde accounts zijn zonder enige verhoging van de veiligheid te bieden......

Het is misschien een vorm van schijnveiligheid. Het is nog steeds de best practice. Ik heb hier amper locked accounts doordat collega's hen wachtwoord *moeten* wijzigen. Kwestie van vroegtijdig aankondigen, opvoeden en helder communiceren aan welke voorwaarden dit dient te voldoen.

In dit geval is de root-cause niet duidelijk en worden er legio opties geboden voor iets (al hoewel 't de vraag is van de TS) wat waarschijnlijk niet noodzakelijk is als de best practises gevolgd worden en er iemand met enige kennis naar de kwestie gaat kijken en zodoende de terugkerende kosten verminderd.

(@F_J_K de huidige IT leverancier heeft waarschijnlijk toegang tot de Eventlogs e.d. van de AD en dat analyseert iets eenvoudiger

[Croga]

tweakict schreef op donderdag 21 juni 2018 @ 09:19:
Het is misschien een vorm van schijnveiligheid. Het is nog steeds de best practice.

Nope. Het is al een paar jaar bekend dat, als het om wachtwoorden gaat, de best practice is 2FA met eenvoudige wachtwoorden, of wachtzinnen. Complexiteit en vaak veranderen is vorig jaar debunked en valt nu, mede vanwege de problemen met vergeten wachtwoorden, onder worst practice.

[sh4d0wman]

Killah_Priest schreef op woensdag 20 juni 2018 @ 19:01:
Lockout policies zijn tweeledig : aan de ene kant voorkom je misbruik, aan de andere kant zorg je juist voor een makkelijke denial of service.
In feite is een lockout van enkele seconden al voldoende om brute force aanvallen tegen te gaan (met 30 passwords per seconde kom je immers niet echt ver).

Maar wat de TS wilt is overigens binnen een uurtje opgezet met Powershell.

Het is inderdaad een makkelijke denial of service maar wel brute-force proof.
Hier een voorbeeld van een moderne IP-block bypass:

HackerOne PoC voorbeeld:
Src: https://hackerone.com/reports/127844

Case: if an attacker sends login requests faster than every 4 seconds from the same IP address, it would get blocked.

Exploit:
As a PoC, an IPv6-powered VPS its external network interface was configured to have multiple IPv6 addresses from its range (500+). Then, a brute-force python script was developed that performs a login brute-force attack by rotating through these addresses and leaving at least 4 seconds between the reuse of every IP addresses, to never have a request refused.

Result:
At this rate, an attacker could guess the following number of credentials: 1.800/minute, 108.000/hour, 2.592.000/day, 77.760.000/month

Total Cost: $5

Voor TS hangt het er vanaf wat hij precies wil oplossen:
- Interne gebruikers die zichzelf / elkaar locken
- Externe inlog-verzoeken welke legitieme accounts locken

Beiden vereisen een andere aanpak. Mogelijke opties:
- Self-Service / Super-Users
- Captcha / 2FA / IP-block / Account-lock met manual reset

[Sissors]

Killah_Priest schreef op donderdag 21 juni 2018 @ 00:17:
[...]


Het testen, documenteren en overdragen daar zit uiteraard (zoals gewoonlijk) meer tijd in als in het bouwen van zo'n script.
Maar een eerste opzet hoeft niet meer als een uurtje te kosten (en dan desnoods met een csv bestand in eerste instantie) en dan laat je direct aan zo'n support partij zien dat het wel mogelijk is (roepen dat iets niet mogelijk is daar heb ik zo'n hekel aan binnen de IT. Als men roept dat het niet rendabel is is het uiteraard een heel ander verhaal).

Dan ga je dus je brute-force beveiliging compleet hangen aan een CSV bestandje? Dat lijkt mij potentieel een enorm gat in je beveiliging.

[Stoelpoot]

tweakict schreef op woensdag 20 juni 2018 @ 17:18:
[...]


Als IT professional krijg ik hier echt jeuk van. Anno 2018 kan dit echt niet meer. Gebruikers wordt aangeraden om minimaal elke 180 dagen het wachtwoord te wijzigen. Daarnaast met complexiteit e.d.

Dikke vingers kan, maar dan standaard pa na 3-5 foutieve inlogpogingen.

Wat betreft de IT leverancier. Laat hen het uitzoeken waarom dit voorkomt en anders een andere zoeken. Voor jullie; Wellicht is het verstandiger om te praten over een contract ipv uurtje factuurtje. Dan ben je van die 'extra' kosten af voor calls en weet jouw directeur exact waar hij/zij aan toe is per jaar voor support en beheer (als beheer er uberhaubt al is)

Zie ook: https://blog.devolutions....for-system-administrators
NOFI

Volgens Het NIST is periodiek wijzigen juist een heel slecht idee. Zeker i.c.m. die andere guidelines. Dan zou je elk halfjaar een nieuw wachtwoord moeten maken, van 15+ karakters, met speciale tekens en dergelijke... Poekie123!20181, Poekie123!20182, Poekie123!20191 zijn anderhalf jaar lang "hetzelfde" wachtwoord, volledig volgens die guidelines (en zelfs erboven met 4/4 onderdelen). Met 8 karakters en enkel lowercase karakters maak je een wachtwoord met minder vatbaar is voor dictionary attacks EN social engineering, wat de meest gebruikte aanvallen zijn. Bruteforcing is niet haalbaar.

Verder druist punt 10 tegen alle security-principes in. "10. Store Password Using Reversible Encryption for All Users policy". Daaronder zetten ze nog "alleen als het echt nodig is", en volledig tegen de headline in "on a per-user basis" ("For all users on a per-user basis" ). Als dit echt nodig is moet je de onderliggende reden daarvoor verhelpen, en niet omgekeerd.

Die guide hangt aan alle kanten, ik zou dat bedrijf niet vertrouwen met wachtwoorden.

[Question Mark]

lawkexarib schreef op woensdag 20 juni 2018 @ 17:09:
[...]
Vaak zijn het groepsaccounts die geblokkeerd raken.

Ik denk dat het management even een goede risico inventarisatie moet gaan maken.

Vanuit de topicstart merk ik dat men (account)beveiliging best serieus neemt, later lees ik dat men groepsaccounts gebruik en het voor sommige type accounts totaal niet boeit wie bij welke informatie mag komen..

De conclusie zou dan kunnen zijn:

1. Voor groepsaccount automatisch unlocken instellen. Deze accounts hebben toch geen toegang tot sensitive informatie
2. Voor overige accounts de huidige policy blijven handhaven.

Nog steeds relatief secure, en het aantal helpdesktickets zal afnemen.

[Killah_Priest]

Sissors schreef op donderdag 21 juni 2018 @ 09:44:
[...]

Dan ga je dus je brute-force beveiliging compleet hangen aan een CSV bestandje? Dat lijkt mij potentieel een enorm gat in je beveiliging.

Welk deel van "eerste opzet" was onduidelijk voor jou?