Jednym z naszych klientów jest firma PCI poziomu 1, a ich audytorzy zasugerowali, że jesteśmy administratorami systemu i naszymi prawami dostępu.
Administrujemy ich całkowicie opartą na systemie Windows infrastrukturą około 700 komputerów stacjonarnych / 80 serwerów / 10 kontrolerów domeny.
Sugerują przejście do systemu, w którym mamy trzy oddzielne konta:
DOMAIN.CO.UK\UserWS
DOMAIN.CO.UK\UserSRV
DOMAIN.CO.UK\UserDC
- Gdzie WS jest kontem logującym się tylko na stacjach roboczych, jest lokalnym administratorem na stacjach roboczych
- Gdzie SRV jest kontem, które loguje się tylko na serwerach innych niż DC, jest lokalnym administratorem na serwerach
- Gdzie DC jest kontem, które loguje się tylko do kontrolerów domeny, w rzeczywistości konto administratora domeny
Następnie obowiązują zasady zapobiegające logowaniu do niewłaściwego typu systemu z niewłaściwego konta (co obejmuje usuwanie interaktywnego logowania dla kont administratora domeny na komputerach innych niż DC)
Zapobiega to sytuacji, w której zaatakowana stacja robocza może ujawnić token logowania administratorów domeny i użyć go ponownie na kontrolerze domeny.
Wydaje się, że jest to nie tylko bardzo inwazyjna polityka w naszych codziennych operacjach, ale także znaczna ilość pracy, aby zająć się tym, co jest stosunkowo mało prawdopodobnym atakiem / exploitem (i tak to rozumiem, być może źle rozumiem wykonalność tego exploita) .
Chciałbym usłyszeć opinie innych administratorów, szczególnie tych, którzy byli zaangażowani w firmę zarejestrowaną w PCI i macie podobne rekomendacje. Jakie są twoje zasady dotyczące logowania administratora.
Dla przypomnienia, obecnie mamy konto użytkownika domeny, którego używamy normalnie, i konto administratora domeny, które podwyższamy również, gdy potrzebujemy dodatkowych praw. Szczerze mówiąc, wszyscy jesteśmy trochę leniwi i często po prostu używamy konta Domain Admin do codziennych operacji, chociaż jest to technicznie sprzeczne z zasadami naszej firmy (jestem pewien, że rozumiesz!).
źródło
Odpowiedzi:
Jestem u dostawcy PCI poziomu 1. Mamy coś takiego z kilkoma różnicami.
Audytorzy faktycznie próbują opisać bardzo prawdziwy problem, ale wykonują niesamowicie słabą pracę, tłumacząc implikacje i analizę potrzeb.
Bardziej skuteczne jest teraz narażenie systemu na szwank przy użyciu skrótu hasła lub istniejącego tokena. Mówiąc wprost, osoba atakująca nie potrzebuje już nazwy użytkownika i hasła. Istnieją teraz łatwiejsze sposoby ataku na system. W żadnym wypadku nie należy zakładać ani wyciągać wniosków, że ten rodzaj ataku jest mało prawdopodobny. Ataki Hash są teraz wektorem ataku defacto .
Ataki Hash są w rzeczywistości gorsze w przypadku kont kart inteligentnych, co jest ironiczne, ponieważ większość ludzi spodziewa się, że wdrożenie kart inteligentnych zwiększy bezpieczeństwo systemu.
Jeśli konto zostanie naruszone z powodu ataku typu hash, zwykle odpowiedzią jest zmiana hasła do konta. Zmienia to skrót używany do uwierzytelnienia. Ponadto normalne wygaśnięcie / zmiana hasła może spowodować pojawienie się wtargnięcia, ponieważ hasz atakującego zacznie się nie powieść. Jednak w przypadku kart inteligentnych hasło jest „zarządzane przez system” (użytkownik nigdy nie wprowadza hasła w celu uwierzytelnienia), więc skrót nigdy się nie zmienia. Oznacza to, że w przypadku kont kart inteligentnych wtargnięcie może pozostać niezauważone o wiele dłużej niż w przypadku konta używającego hasła.
Oto ograniczenia, które rozważę:
W przypadku kont obsługujących karty inteligentne, z których korzysta wiele dużych firm w przypadku kont o wysokim poziomie uprzywilejowania, często zmieniaj hasło do konta. To zmienia skrót. Możesz również zmienić skrót poprzez odblokowanie karty inteligentnej, a następnie ponowne włączenie karty inteligentnej. Microsoft robi to co 24 godziny, ale musisz ocenić potencjalny wpływ, jaki może to spowodować w twoim środowisku, i ustalić rozsądny harmonogram, aby nie stwarzać dodatkowych problemów.
W przypadku stacji roboczych w ogóle nie korzystałbym z kont domeny do celów administracyjnych, jeśli to możliwe. Mamy konto lokalne, którego można użyć do podniesienia uprawnień do operacji typu UAC. Spełnia to 99,9% większości wymagań dotyczących wysokości. Stacje robocze są zazwyczaj wektorami ataku na gorąco, ze względu na brak regimitowanej kontroli zmian oraz istnienie Java JRE i Flash.
Takie podejście działa dla nas, ponieważ mamy formalny mechanizm zarządzania i egzekwowania hasła do kont lokalnych oraz że hasło jest unikalne w każdym systemie, a także istnieje bezpieczna metoda żądania hasła. Istnieją również aplikacje komercyjne, które mogą wykonywać tę funkcję.
Jeśli nie możesz zapewnić lokalnego konta dla stacji roboczych, to tak, oddzielny rachunek domeny powinien być używany do administracyjnego dostępu do stacji roboczych, a to konto nie powinno być używane do administracyjnego dostępu do serwerów. Inną opcją może być użycie zdalnych, nieinteraktywnych narzędzi do zarządzania obsługą, które używają LocalSystem do wykonywania działań, oraz mechanizmu uwierzytelniania, który jest niezależny od systemu Windows.
W przypadku kont o najwyższym poziomie uprzywilejowania (administrator przedsiębiorstwa, administrator domeny itp.) Użyj tylko serwera skoku. Ten serwer podlegałby najbardziej restrykcyjnym zabezpieczeniom, kontroli zmian i audytom. W przypadku wszystkich innych typów funkcji typu administracyjnego rozważ oddzielne konto administracyjne. Serwer skoku powinien być codziennie restartowany ponownie, aby usunąć tokeny procesu z procesu LSA.
Nie wykonuj zadań administracyjnych ze stacji roboczej. Użyj serwera wzmocnionego lub serwera skoku.
Rozważ użycie łatwego resetowania maszyn wirtualnych jako skoczni, które można zresetować, aby wyczyścić pamięć po każdej sesji.
Dalsza lektura:
https://blogs.technet.com/b/security/archive/2012/12/06/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash.aspx
Raport Microsoft Security Intelligence, tom 13, styczeń - czerwiec 2012 r.
Http://www.microsoft.com/security/sir/archive/default.aspx
Przeczytaj sekcję: „Obrona przed atakami typu pass-the-hash”.
Pokonaj przerażające ataki typu hash-pass-the-hash
https://www.infoworld.com/d/security/defeat-dreaded-pass-the-hash-attacks-179753
źródło