Computer >> 컴퓨터 >  >> 체계 >> Windows Server

디버그 프로그램 정책이 활성화된 경우 SeDebugPrivilege를 얻는 방법

이전 기사에서 우리는 mimikatz와 같은 유틸리티를 방어하는 방법 중 하나가 디버그 프로그램 정책을 사용하여 시스템 관리자에 대한 디버그 권한을 비활성화하는 것이라고 말했습니다. 그러나 최근에 디버그 권한(Windows의 경우 SeDebugPrivilege)이 없으면 로컬 서버 관리자가 Microsoft SQL Server를 설치하거나 업데이트할 수 없다는 사실이 밝혀졌습니다. 문제는 SQL Server 설치 프로그램이 시작될 때 SeSecurity, SeBackup 및 SeDebug 권한이 있는지 확인한다는 것입니다. SQL Server 프로세스를 실행하고 SQL Server의 성공적인 시작에 대한 정보를 가져와야 합니다. 다음은 어떻게 생겼는지입니다.

SQL Server 설치 중에 설치 프로그램은 예비 검사를 수행하고 계정 권한 설정과 관련된 몇 가지 문제를 식별합니다. .

디버그 프로그램 정책이 활성화된 경우 SeDebugPrivilege를 얻는 방법

실패 링크를 클릭하면 다음 메시지를 볼 수 있습니다.

'계정 권한 설정' 규칙이 실패했습니다.
SQL Server 설치 프로그램을 실행하는 계정에 파일 및 디렉터리 백업 권한, 감사 및 보안 로그 관리 권한, 프로그램 디버그 권한 중 하나 또는 모두가 없습니다. 계속하려면 두 권한이 모두 있는 계정을 사용하세요. 자세한 내용은 https://msdn.microsoft.com/en-us/library/ms813696.aspx, https://msdn.microsoft.com/en-us/library/ms813959.aspx 및 https://msdn을 참조하세요. .microsoft.com/en-us/library/ms813847.aspx.

디버그 프로그램 정책이 활성화된 경우 SeDebugPrivilege를 얻는 방법

이제 SystemConfigurationCheck_Report.htm을 엽니다. 보고서.

디버그 프로그램 정책이 활성화된 경우 SeDebugPrivilege를 얻는 방법

보시다시피 HasSecurityBackupAndDebugPrivilegesCheck를 확인할 때 규칙에 따라 설치 프로그램이 현재 프로세스에 다음 권한 중 하나가 없음을 발견했습니다.

  • SeSecurity – 감사 및 보안 로그 관리
  • SeBackup – 파일 및 폴더 백업 권한
  • SeDebug — 프로그램을 디버그할 수 있는 권한

설치 프로세스에 SeDebug 플래그가 없음을 보여주는 로그에 몇 가지 자세한 정보가 있습니다.

(09) 2017-12-12 11:15:13 Slp: Initializing rule      : Setup account privileges
(09) 2017-12-12 11:15:13 Slp: Rule is will be executed  : True
(09) 2017-12-12 11:15:13 Slp: Init rule target object: Microsoft.SqlServer.Configuration.SetupExtension.FacetPrivilegeCheck
(09) 2017-12-12 11:15:13 Slp: Rule ‘HasSecurityBackupAndDebugPrivilegesCheck’ Result: Running process has SeSecurity privilege, has SeBackup privilege and does not have SeDebug privilege.
(09) 2017-12-12 11:15:13 Slp: Evaluating rule        : HasSecurityBackupAndDebugPrivilegesCheck
(09) 2017-12-12 11:15:13 Slp: Rule running on machine: rom-sql10
(09) 2017-12-12 11:15:13 Slp: Rule evaluation done   : Failed

디버그 프로그램 정책을 변경하거나 비활성화하지 않고 SeDebugPrivilege를 가져오는 해결 방법을 찾기로 결정했습니다. 서버에 대한 로컬 관리자 권한이 있는 경우 이 정책을 무시하는 아주 쉬운 방법이 있는 것으로 나타났습니다. secedit 서버의 로컬 보안 정책을 관리할 수 있는 도구가 도움이 될 것입니다.

현재 권한 확인:

whoami /priv

디버그 프로그램 정책이 활성화된 경우 SeDebugPrivilege를 얻는 방법

보시다시피 사용자의 현재 토큰에는 SeDebugPrivilege가 없습니다.

그룹 정책에 의해 설정된 현재 사용자 권한을 텍스트 파일로 내보내기:

secedit /export /cfg secpolicy.inf /areas USER_RIGHTS

텍스트 편집기를 사용하여 secpolicy.inf를 엽니다. [Privilege Rights]에 문자열 추가 로컬 관리자 그룹에 대한 디버그 프로그램 권한을 활성화하는 섹션입니다.

SeDebugPrivilege = *S-1-5-32-544

디버그 프로그램 정책이 활성화된 경우 SeDebugPrivilege를 얻는 방법

참고 . 로컬 관리자 그룹 S-1-5-32-544의 SID는 다른 SID로 변경할 수 있습니다. 그룹 또는 사용자 이름을 SID로 변환하려면 SID를 UserName으로 또는 그 반대로 변환하는 방법을 참조하십시오.

파일을 저장합니다. 이제 새 사용자 권한을 적용하십시오.

secedit /configure /db secedit.sdb /cfg secpolicy.inf /overwrite /areas USER_RIGHTS

참고 . 현재 설정의 덮어쓰기를 확인해야 합니다.

디버그 프로그램 정책이 활성화된 경우 SeDebugPrivilege를 얻는 방법

로그오프했다가 다시 로그온하고 secpol.msc를 사용하여 디버그 프로그램 권한이 로컬 관리자 그룹에 할당되었는지 확인합니다. whoami /priv 명령의 결과에도 동일하게 표시됩니다.

SeDebugPrivilege                Debug programs                            Enabled

디버그 프로그램 정책이 활성화된 경우 SeDebugPrivilege를 얻는 방법

이제 설치를 실행하거나 SQL Server를 업데이트할 수 있습니다. 그러나 SeDebugPrivilege는 일시적으로 할당되며 다음 GPO 업데이트 주기(사용자가 로그오프한 후)에 재설정됩니다.

디버그 프로그램 정책을 활성화하면 로컬 관리자 권한으로 이미 서버에 침투한 악성 소프트웨어가 SeDebugPrivilege를 얻는 것을 완전히 보호할 수 없으며 서버에서 작업하는 모든 사용자/관리자 계정이 손상될 수 있음을 이해해야 합니다.