의 억제 규칙 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 - Internet VPC Gateway가 아닌 온프레미스 게이트웨이에서 전송되도록 인터넷 트래픽을 라우팅하도록 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 인스턴스를 대상으로 하는 경우 억제 규칙을 사용하여 자동으로 결과를 보관합니다.

    무차별 포스 시도의 대상이 바스트레이션 호스트인 경우 환경에 예상되는 동작을 나타낼 수 있습니다 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. 따라서 포드에서 DNS 조회할 때마다 는 포드에서 하나씩, GuardDuty 서버 포드에서 하나씩 두 개의 DNS 이벤트를 캡처합니다. 이렇게 하면 다음 DNS 결과에 대해 중복이 발생할 수 있습니다.

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