Applocker 및 소프트웨어 제한 정책

사용자가 터미널 서버에서 원치 않는 프로그램을 실행하지 못하도록하는 것이 목표입니다.

나는 새로운 Applocker 기능이 이전 소프트웨어 제한 정책보다 100 % 우수하며 후자를 대신 할 것을 권장한다고 Microsoft와 다른 사람들로부터 많은 기사를 읽었습니다.

커널 모드 실행과 별개로 Applocker의 실제 장점을 이해하지 못했습니다. 대부분의 기능은 소프트웨어 제한 정책으로 재현 할 수 있습니다.

마찬가지로 BIG의 단점 중 하나는 매우 쓸모가 없다는 것입니다. 확장 할 수 없으며 제한하려는 사용자 정의 파일 확장자를 추가 할 수 없습니다.

SRP에 비해 Applocker의 장점은 무엇이며 소프트웨어 제어에 권장하는 것은 무엇입니까?

Windows 7 Enterprise / Ultimate가 AppLocker를 도입 한 이후 Microsoft는 소프트웨어 제한 정책을 더 이상 사용하지 않습니다 ( SRP를 효과적으로 주장한다고 주장하는 technet은 지원되지 않음 ).

실제로 SRP에는 위양성 및 위양성 모두에 대한 함정이 있습니다. AppLocker는 여전히 적극적으로 유지 관리되고 지원되고 있다는 이점이 있습니다. AppLocker가 옵션이라면 시간과 위험을 고려한 후에 더 저렴할 수 있습니다. 적절한 타사 대안이있을 수도 있습니다 (그러나이 질문에는 해당 옵션이 포함되지 않았습니다 :).

SRP의 함정에 대해 완전히 이해하기를 바랍니다 </sarcasm>. 그들 중 일부는 Vadims Podāns 의 멋진 보안 기사에 설명되어 있습니다.

알려진 함정

1. 기본적으로 \Windows폴더 에서 실행 이 허용됩니다. 일부 하위 폴더는 사용자가 쓸 수 있습니다. Applocker는 동일하지만 최소한 공식 문서에는이 제한 사항이 언급되어 있습니다.

   편집 : " 사용자 쓰기 권한 이있는 모든 폴더 를 열거 하려면 ( 예 : Sysinternals 팩의 AccessEnum 유틸리티)." (또는 AccessChk ).

   기술 적으로 문서는 기본 규칙을 무시하지 않도록주의합니다 . 편집 : NSA 문서는 SRP를 사용하여 블랙리스트에 폴더의 16 가지 예를 제공 하지만 레지스트리 경로 규칙은 백 슬래시를 잘못 사용하므로 수정해야하며 (아래 레지스트리 경로의 포인트 참조) 일반적인 오버 브로드 블랙리스트 항목에 대해 경고합니다.

   분명한 질문은 왜 개별 경로를 신중하게 화이트리스트에 올리지 않는 \Windows것입니다. ( \Windows\*.exe레거시 System32\*.exe등 포함). 나는 어디서나 이것에 대한 답을 보지 못했다.

2. 와 같은 환경 변수를 사용하면 환경 변수 %systemroot%를 지워서 SRP를 무시할 수 있습니다. 편집 : 제안 된 기본값에는 사용되지 않습니다. 그러나 그들은 사용하기를 원할 수도 있습니다. 이 풋건은 환경 변수를 보지 않기 때문에 AppLocker에서 수정되었습니다.

3. 제안 된 기본값 \Program Files은 최신 64 비트 설치에서 서로 다른 두 가지를 사용할 수 없도록 무시 합니다. 보다 안전한 "레지스트리 경로"를 사용하여이 문제를 해결하면 테스트에서 쉽게 놓칠 수있는 임의 상황에서 허위 거부가보고됩니다. 예를 들어 SpiceWorks SRP howto 에 대한 의견을 보십시오 . 편집 : 이것은 레지스트리의 WOW6432Node에서 관련 경로를 읽는 32 비트 응용 프로그램과 관련이 있습니다. 해결 방법은 모든 프로그램이 32 비트 및 64 비트 컴퓨터에서 무제한으로 시작할 수 있도록 SRP 에이 경로를 모두 추가 하는 것입니다. x64 또는 x86 호스트 프로세스 :%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
4. 기본 확장은 Windows에서 지원하는 PowerShell 스크립트 (* .PS1)를 금지합니다 . ( 비디오 참조 ). 그리고 APPX도 ... Microsoft의 비교표에 따르면 SRP는 Windows 8에서 "Packaged apps"를 관리 할 수 ​​없습니다. 이것이 의미하는 바는 없습니다.
5. 레지스트리 경로 규칙에는 마지막 백분율 기호 바로 뒤에 슬래시가 없어야하며 (XP / Server 2003의 Microsoft 자체 내장 규칙에 포함되어 있음) 규칙이 작동하려면 백 슬래시를 슬래시로 바꿔야합니다 ( 1 / 2 / 3 ).
6. 내가 SRP에 대해 찾은 소스 중 아무도 위의 전체 목록을 함께 제공하지 않았습니다. 그리고 우연히 Vadims Podāns의 기사를 발견했습니다. 거기에 또 무엇이 숨어 있습니까?
7. 많은 출처에서 간단히 목록에서 LNK 파일을 제거하는 것이 좋습니다. (그리고 즐겨 찾기를 중단하지 않기 위해 웹 바로 가기?!). 혼란스럽게도 소스가 LNK 취약점에 대해 논의하지 않는 것 같습니다 ... 또는 스크립트 인터프리터가 예기치 않은 확장자로 파일을 실행하도록하는wscript /e 것 ... 또는 인라인 스크립트 매개 변수에 충분한 쉘 코드를 채우는 등 ...
8. 데스크탑에서 LNK 파일을 허용하여 손상을 시도하고 사용자에게 데스크탑에 대한 쓰기 액세스 권한을 부여한 경우 이제 사용자는 정책을 완전히 무시할 수 있습니다. Vadims Podāns의 멋진 팁. 설명은 경로 규칙에서 확장을 사용하는 경우에 적용됩니다. Microsoft는를 포함하여 이에 대한 여러 가지 예를 *.Extension경고없이 제공합니다. 따라서 공식 문서를 신뢰할 수 없으며 현재 수정되지 않을 것 같습니다.
9. [잠재적 AppLocker 단점]. Vadims Podāns는 매핑 된 드라이브를 사용하는 SRP 항목이 작동하지 않는다고보고합니다. 대신 UNC 경로를 사용해야합니다. 어쩌면 그들은 매핑 된 드라이브를 통해 액세스 할 수 있습니까? 100 % 명확하지 않습니다. 분명히 AppLocker는 다음과 같이 다릅니다. :(. " . 알 수없는 이유로 인해 UNC 경로가 Applocker에서 작동하지 않습니다! 즉, 응용 프로그램이 네트워크에 설치되어 있으면 해시 또는 게시자 규칙을 만들어야합니다. "

실용적 접근

소프트웨어 화이트리스트는 잠재적으로 매우 강력한 방어책입니다. 냉소적 인 경우 : 이것이 바로 Microsoft가 저렴한 버전을 더 이상 사용하지 않고 더 복잡한 버전을 발명하는 이유입니다.

다른 옵션을 사용할 수 없습니다 (타사 솔루션 포함). 그런 다음 SRP를 최대한 간단하게 구성하는 것이 실용적인 방법입니다. 알려진 구멍이있는 추가 방어 계층으로 취급하십시오. 위의 함정과 일치 :

1. 기본 규칙부터 시작하십시오 (Win7 이전 시대부터).
2. 환경 변수를 사용하지 않는 것이 좋습니다 (예 :) %systemroot%.
3. \Program Files\최신 64 비트 시스템에서 두 디렉토리가 모두 허용 되도록 규칙을 추가하십시오 . \Program Files\64 비트 컴퓨터에 추가해야하는 추가 "레지스트리 경로" 는 %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%및 %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%입니다.
4. 레지스트리 경로 규칙에 추가 할 경우, 즉시 퍼센트 기호 뒤의 백 슬래시를 생략하고, 더 이상의 백 슬래시 대체 \forwardslashes와을 /(예를 %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
5. 제어 된 확장자 목록에 PS1을 추가하십시오.
6. 관리 가능한 SRP 구성은이를 방지하기로 결정한 사용자로부터 안전하지 않다는 것을 이해하십시오. 목표는 사용자가 정책 내에서 작업하도록 돕고 "드라이브 바이 다운로드"와 같은 공격으로부터 사용자를 보호하는 것입니다.
7. LNK 파일을 허용하십시오. (일부 경로 규칙이 아닌 확장명 목록에서 제거하여)
8. 위 참조 :).
9. 로그온 스크립트 폴더가 허용되는지 확인하십시오. NSA 문서는 추가를 제안 \\%USERDNSDOMAIN%\Sysvol\합니다. (포인트 # 2 참조, 한숨, 포인트 # 6 참조).

SRP에 AppLocker가 실제로 활용할 수있는 몇 가지 추가 기능이 있음에 동의합니다.

즉, AppLocker의 큰 이점 ( 이 비교에 설명되어 있음 )은 다음과 같습니다.

• AppLocker 규칙은 특정 사용자 또는 사용자 그룹을 대상으로하는 반면 SRP는 전체 컴퓨터에서 시행됩니다.
• AppLocker는 감사 모드를 지원하므로 규칙을 적용하기 전에 프로덕션에서 규칙을 테스트 할 수 있습니다. SRP에는 동등한 로그 전용 모드가 없습니다.

나에게 가장 큰 장점은 게시자가 서명 한 실행 파일을 허용 목록에 추가 할 수 있다는 것입니다. 이 http://technet.microsoft.com/en-us/library/ee460943(v=ws.10).aspx를 살펴보십시오.

Microsoft가 발표 한 명백한 거짓말은 AppLocker의 이점이 없습니다. 1. SAFER 규칙이있는 GPO를 사용자 및 사용자 그룹에 연결할 수 있습니다. 2. Windows Vista는 도메인 컨트롤러없이 동일한 결과를 달성하는 여러 로컬 GPO를 도입했습니다. 3. 강화 된 로깅 기능을 통해 감사 모드를 사용할 수 있습니다.

회사 내에서 Applocker를 사용합니다. 우리가 사용하는 전략은 모든 것을 기본으로 거부하고 (실제로는 Applocker 기본값) 서명 된 응용 프로그램 (사무실, 어도비, wintools, 도끼 등) 만 허용하는 규칙을 만듭니다. 대부분의 맬웨어는 서명되지 않은 소프트웨어이므로 실행되지 않습니다. 거의 유지 보수가 아닙니다. 3 개의 추가 레거시 앱만 허용해야했습니다.

또한 UNC 경로를 사용할 수 없다는 것을 확인할 수 없습니다. 일부 추가 안전 거부 규칙에서는 UNC 경로를 성공적으로 사용합니다. 함정은 환경 변수를 사용하는 것입니다. Applocker에서는 작동하지 않습니다. * 와일드 카드를 사용하십시오. Windows 2008 R2 및 Windows 2012 R2에서 사용합니다.

나는 그것을 아주 좋아한다 : 성능 저하가 거의 없다. 설명서에 나와 있듯이 Applocker는 Application Identity Service를 사용합니다 (자동으로 시작되는지 확인).