의 억제 규칙 GuardDuty - Amazon GuardDuty
억제 규칙의 일반 사용 사례 및 예시

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

의 억제 규칙 GuardDuty

억제 규칙은 지정된 기준과 일치하는 새 결과를 자동으로 보관하여 결과를 필터링하는 데 사용되는 값과 페어링된 필터 속성으로 구성된 일련의 기준입니다. 억제 규칙을 사용하면 가치가 낮은 결과, 오탐지 결과 또는 조치를 취하지 않으려는 위협을 필터링할 수 있으므로 환경에 가장 큰 영향을 미치는 보안 위협을 보다 쉽게 파악할 수 있습니다.

억제 규칙을 생성한 후, 억제 규칙이 지정되어 있는 동안에는 규칙에 정의된 기준과 일치하는 새 결과가 자동으로 보관됩니다. 기존 필터를 사용하여 억제 규칙을 생성하거나 정의한 새 필터에서 억제 규칙을 생성할 수 있습니다. 억제 규칙을 구성하여 전체 결과 유형을 억제하거나, 보다 세부적인 필터 기준을 정의하여 특정 결과 유형의 특정 인스턴스만 억제할 수 있습니다. 언제든지 차단 규칙을 편집할 수 있습니다.

억제된 조사 결과는 AWS Security Hub Amazon Simple Storage Service, Amazon Detective 또는 Amazon으로 전송되지 않으므로 Security Hub, 타사 SIEM또는 기타 알림 및 티켓팅 애플리케이션을 통해 조사 GuardDuty 결과를 사용하는 경우 조사 결과 노이즈 수준이 EventBridge줄어듭니다. 에 대한 맬웨어 보호 EC2를 활성화한 경우 억제된 GuardDuty 조사 결과는 맬웨어 스캔을 시작하지 않습니다.

GuardDuty 는 억제 규칙과 일치하는 경우에도 결과를 계속 생성하지만, 해당 결과는 아카이브된 것으로 자동으로 표시됩니다. 보관된 결과는 90일 GuardDuty 동안에 저장되며 해당 기간 동안 언제든지 볼 수 있습니다. 결과 테이블 GuardDuty API에서 아카이브됨을 선택하거나를 사용하여 GuardDuty 콘솔에서 억제된 결과를 볼 수 있습니다. ListFindings API findingCriteria 기준이 trueservice.archived인 경우.

참고

다중 계정 환경에서는 GuardDuty 관리자만 금지 규칙을 생성할 수 있습니다.

억제 규칙의 일반 사용 사례 및 예시

다음 검색 결과 유형에는 억제 규칙을 적용하는 일반적인 사용 사례가 있습니다. 검색어 이름을 선택하면 해당 검색어에 대해 자세히 알아볼 수 있습니다. 사용 사례 설명을 검토하여 해당 검색 유형에 대한 억제 규칙을 작성할지 결정하세요.

중요

GuardDuty 에서는 환경에서 오탐을 반복적으로 식별한 결과에 대해서만 억제 규칙을 사후적으로 빌드할 것을 권장합니다.

  • UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS - 인터넷 게이트웨이가 아닌 온프레미스 게이트웨이에서 전송되도록 인터넷 트래픽을 라우팅하도록 VPC 네트워킹이 구성된 경우 생성된 결과를 자동으로 아카이브하려면 억제 규칙을 사용합니다VPC.

    이 결과는 인터넷 게이트웨이VPC()가 아닌 온프레미스 게이트웨이에서 전송되도록 네트워킹이 인터넷 트래픽을 라우팅하도록 구성된 경우에 생성됩니다IGW. AWS Outposts또는 VPC VPN 연결 사용과 같은 일반적인 구성으로 인해 트래픽이 이러한 방식으로 라우팅될 수 있습니다. 예상된 동작인 경우 의 억제 규칙을 사용하고 두 개의 필터 기준으로 구성된 규칙을 만드는 것이 좋습니다. 첫 번째 기준은 결과 유형으로 UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS이어야 합니다. 두 번째 필터 기준은 온프레미스 인터넷 게이트웨이의 IP API IPv4 주소 또는 범위를 가진 호출자 주소입니다. CIDR 아래 예제는 API 호출자 IP 주소를 기반으로이 결과 유형을 억제하는 데 사용할 필터를 나타냅니다.

    Finding type: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS API caller IPv4 address: 198.51.100.6
    참고

    여러 API 발신자를 포함하려면 각각에 대해 새 API 발신자 IPv4 주소 필터를 추가할 IPs 수 있습니다.

  • Recon:EC2/Portscan - 취약성 평가 애플리케이션을 사용하는 경우 억제 규칙을 사용하여 자동으로 결과를 보관합니다.

    억제 규칙은 두 개의 필터 기준으로 구성해야 합니다. 첫 번째 기준에는 Finding type(결과 유형) 속성과 Recon:EC2/Portscan 값을 사용해야 합니다. 두 번째 필터 기준은 이러한 취약성 평가 도구를 호스팅하는 인스턴스와 일치해야 합니다. 이러한 도구를 호스팅하는 인스턴스에서 식별 가능한 기준에 따라 Instance image ID 속성 또는 Tag 값 속성을 사용할 수 있습니다. 아래 예제는 특정가 있는 인스턴스를 기반으로이 결과 유형을 억제하는 데 사용할 필터를 나타냅니다AMI.

    Finding type: Recon:EC2/Portscan Instance image ID: ami-999999999

  • UnauthorizedAccess:EC2/SSHBruteForce - Bastion 인스턴스를 대상으로 하는 경우 억제 규칙을 사용하여 자동으로 결과를 보관합니다.

    무차별 포스 시도의 대상이 Bastion Host인 경우 환경에 예상되는 동작을 나타낼 수 있습니다 AWS . 이 경우 이 결과에 대해 억제 규칙을 설정하는 것이 좋습니다. 억제 규칙은 두 개의 필터 기준으로 구성해야 합니다. 첫 번째 기준에는 Finding type(결과 유형) 속성과 UnauthorizedAccess:EC2/SSHBruteForce 값을 사용해야 합니다. 두 번째 필터 기준은 Bastion Host로 사용되는 인스턴스와 일치해야 합니다. 이러한 도구를 호스팅하는 인스턴스에서 식별 가능한 기준에 따라 인스턴스 이미지 ID 속성 또는 태그 값 속성을 사용할 수 있습니다. 아래 예시는 특정 인스턴스 태그 값을 기반으로 이 결과 유형을 억제하는 데 사용할 필터를 나타냅니다.

    Finding type: UnauthorizedAccess:EC2/SSHBruteForce Instance tag value: devops

  • Recon:EC2/PortProbeUnprotectedPort - 의도적으로 노출된 인스턴스를 대상으로 하는 경우 억제 규칙을 사용하여 자동으로 결과를 보관합니다.

    인스턴스가 웹 서버를 호스팅하는 경우와 같이 의도적으로 노출되는 경우가 있을 수 있습니다. AWS 환경의 경우이 결과에 대한 금지 규칙을 설정하는 것이 좋습니다. 억제 규칙은 두 개의 필터 기준으로 구성해야 합니다. 첫 번째 기준에는 Finding type(결과 유형) 속성과 Recon:EC2/PortProbeUnprotectedPort 값을 사용해야 합니다. 두 번째 필터 기준은 Bastion Host로 사용되는 인스턴스와 일치해야 합니다. 이러한 도구를 호스팅하는 인스턴스에서 식별 가능한 기준에 따라 인스턴스 이미지 ID 속성 또는 태그 값 속성을 사용할 수 있습니다. 아래 예시는 콘솔의 특정 인스턴스 태그 키를 기반으로 이 결과 유형을 억제하는 데 사용할 필터를 나타냅니다.

    Finding type: Recon:EC2/PortProbeUnprotectedPort Instance tag key: prod

런타임 모니터링 결과에 대한 권장 억제 규칙

  • PrivilegeEscalation:Runtime/DockerSocketAccessed는 컨테이너 내부의 프로세스가 Docker 소켓과 통신할 때 생성됩니다. 환경에 합법적인 이유로 Docker 소켓에 액세스해야 하는 컨테이너가 있을 수 있습니다. 이러한 컨테이너에서 액세스하면 PrivilegeEscalation:Runtime/DockerSocketAccessed 결과. AWS 환경의 경우이 결과 유형에 대한 금지 규칙을 설정하는 것이 좋습니다. 첫 번째 기준에는 값이 PrivilegeEscalation:Runtime/DockerSocketAccessed와 같은 결과 유형 필드를 사용해야 합니다. 두 번째 필터 기준은 생성된 결과에서 프로세스의 executablePath와 값이 동일한 실행 파일 경로 필드입니다. 또는 두 번째 필터 기준은 생성된 결과의 프로세스와 동일한 값을 가진 실행 파일 SHA-256 필드를 사용할 수 executableSha256 있습니다.

  • Kubernetes 클러스터는 자체 DNS 서버를와 같은 포드로 실행합니다coredns. 따라서 포드 GuardDuty에서 DNS 조회할 때마다는 두 개의 DNS 이벤트를 캡처합니다. 하나는 포드에서 캡처하고 다른 하나는 서버 포드에서 캡처합니다. 이렇게 하면 다음 DNS 결과에 대해 중복이 발생할 수 있습니다.

    중복 조사 결과에는 DNS 서버 포드에 해당하는 포드, 컨테이너 및 프로세스 세부 정보가 포함됩니다. 이러한 필드를 사용하여 이러한 중복 결과를 억제하는 억제 규칙을 설정할 수 있습니다. 첫 번째 필터 기준은이 섹션의 앞부분에 제공된 조사 결과 목록의 DNS 조사 결과 유형과 값이 동일한 조사 결과 유형 필드를 사용해야 합니다. 두 번째 필터 기준은 값이 DNS 서버의와 같은 실행 파일 경로 executablePath 또는 값이 executableSHA256 생성된 결과의 DNS 서버와 같은 실행 파일 SHA-256일 수 있습니다. 선택 사항인 세 번째 필터 기준으로, 생성된 결과에서 DNS 서버 포드의 컨테이너 이미지와 동일한 값을 가진 Kubernetes 컨테이너 이미지 필드를 사용할 수 있습니다.