# Suppression rules in GuardDuty
Suppression rules

A suppression rule is a set of criteria, consisting of a filter attribute paired with a value, used to filter findings by automatically archiving new findings that match the specified criteria. Suppression rules can be used to filter low-value findings, false positive findings, or threats you do not intend to act on, to make it easier to recognize the security threats with the most impact to your environment.

 After you create a suppression rule, new findings that match the criteria defined in the rule are automatically archived as long as the suppression rule is in place. You can use an existing filter to create a suppression rule or create a suppression rule from a new filter you define. You can configure suppression rules to suppress entire finding types, or define more granular filter criteria to suppress only specific instances of a particular finding type. You can edit the suppression rules at any time.

Suppressed findings are not sent to AWS Security Hub CSPM, Amazon Simple Storage Service, Amazon Detective, or Amazon EventBridge, reducing finding noise level if you consume GuardDuty findings via Security Hub CSPM, a third-party SIEM, or other alerting and ticketing applications. If you've enabled [Malware Protection for EC2](malware-protection.md), the suppressed GuardDuty findings won't initiate a malware scan.

GuardDuty continues to generate findings even when they match your suppression rules, however, those findings are automatically marked as **archived**. The archived finding is stored in GuardDuty for 90-days and can be viewed at any time during that period. You can view suppressed findings in the GuardDuty console by selecting **Archived** from the findings table, or through the GuardDuty API using the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html) API with a `findingCriteria` criterion of `service.archived` equal to true. 

**Note**  
In a multi-account environment only the GuardDuty administrator can create suppression rules.

## Using suppression rules with Extended Threat Detection


GuardDuty Extended Threat Detection automatically detects multi-stage attacks that span data sources, multiple types of AWS resources, and time, within an AWS account. It correlates events across different data sources to identify scenarios that present themselves as a potential threat to your AWS environment, and then generates an attack sequence finding. For more information, see [How Extended Threat Detection works](guardduty-extended-threat-detection.md#extended-threat-detection-how-it-works).

When you create suppression rules that archive findings, Extended Threat Detection can't use these archived findings when correlating events for attack sequences. Broad suppression rules might impact the ability of GuardDuty to detect behaviors aligned with detecting multi-stage attacks. Findings that are archived because of suppression rules are not considered as signals for attack sequences. For example, if you create a suppression rule that archives all EKS cluster-related findings instead of targeting specific known activities, GuardDuty won't be able to use those findings to detect an attack sequence where a threat actor exploits a container, obtains privileged tokens, and accesses sensitive resources.

Consider the following recommendations from GuardDuty:
+ Continue using suppression rules to reduce alerts from known trusted activities.
+ Keep the suppression rules focused on specific behaviors for which you don't want GuardDuty to generate a finding.

## Common use cases for suppression rules and examples


The following finding types have common use cases for applying suppression rules. Select the finding name to learn more about that finding. Review the use case description to decide if you want to build a suppression rule for that finding type.

**Important**  
GuardDuty recommends that you build suppression rules reactively and only for findings for which you have repeatedly identified false positives in your environment.
+ [UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS](guardduty_finding-types-iam.md#unauthorizedaccess-iam-instancecredentialexfiltrationoutsideaws) – Use a suppression rule to automatically archive findings generated when VPC networking is configured to route internet traffic such that it egresses from an on-premises gateway rather than from a VPC Internet Gateway.

  This finding is generated when networking is configured to route internet traffic such that it egresses from an on-premises gateway rather than from a VPC Internet Gateway (IGW). Common configurations, such as using [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/), or VPC VPN connections, can result in traffic routed this way. If this is expected behavior, it is recommended that you use suppression rules and create a rule that consists of two filter criteria. The first criteria is **finding type**, which should be `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`. The second filter criteria is **API caller IPv4 address** with the IP address or CIDR range of your on-premises internet gateway. The example below represents the filter you would use to suppress this finding type based on API caller IP address.

  ```
  Finding type: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS API caller IPv4 address: 198.51.100.6
  ```
**Note**  
To include multiple API caller IPs you can add a new API Caller IPv4 address filter for each.
+ [Recon:EC2/Portscan](guardduty_finding-types-ec2.md#recon-ec2-portscan) – Use a suppression rule to automatically archive findings when using a vulnerability assessment application. 

  The suppression rule should consist of two filter criteria. The first criteria should use the **Finding type** attribute with a value of `Recon:EC2/Portscan`. The second filter criteria should match the instance or instances that host these vulnerability assessment tools. You can use either the **Instance image ID** attribute or the **Tag** value attribute depending on which criteria are identifiable with the instances that host these tools. The example below represents the filter you would use to suppress this finding type based on instances with a certain AMI.

  ```
  Finding type: Recon:EC2/Portscan Instance image ID: ami-999999999
  ```
+ [UnauthorizedAccess:EC2/SSHBruteForce](guardduty_finding-types-ec2.md#unauthorizedaccess-ec2-sshbruteforce) – Use a suppression rule to automatically archive findings when it is targeted to bastion instances.

  If the target of the brute force attempt is a bastion host, this may represent expected behavior for your AWS environment. If this is the case, we recommend that you set up a suppression rule for this finding. The suppression rule should consist of two filter criteria. The first criteria should use the **Finding type** attribute with a value of `UnauthorizedAccess:EC2/SSHBruteForce`. The second filter criteria should match the instance or instances that serve as a bastion host. You can use either the **Instance image ID** attribute or the **Tag** value attribute depending on which criteria is identifiable with the instances that host these tools. The example below represents the filter you would use to suppress this finding type based on instances with a certain instance tag value.

  ```
  Finding type: UnauthorizedAccess:EC2/SSHBruteForce Instance tag value: devops
  ```
+ [Recon:EC2/PortProbeUnprotectedPort](guardduty_finding-types-ec2.md#recon-ec2-portprobeunprotectedport) – Use a suppression rule to automatically archive findings when it is targeted to intentionally exposed instances.

  There may be cases in which instances are intentionally exposed, for example if they are hosting web servers. If this is the case in your AWS environment, we recommend that you set up a suppression rule for this finding. The suppression rule should consist of two filter criteria. The first criteria should use the **Finding type** attribute with a value of `Recon:EC2/PortProbeUnprotectedPort`. The second filter criteria should match the instance or instances that serve as a bastion host. You can use either the **Instance image ID** attribute or the **Tag** value attribute, depending on which criteria is identifiable with the instances that host these tools. The example below represents the filter you would use to suppress this finding type based on instances with a certain instance tag key in the console.

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

### Recommended suppression rules for Runtime Monitoring findings

+ [PrivilegeEscalation:Runtime/DockerSocketAccessed](findings-runtime-monitoring.md#privilegeesc-runtime-dockersocketaccessed) gets generated when a process inside a container communicates with the Docker socket. There may be containers in your environment that may need to access the Docker socket for legitimate reasons. Access from such containers will generate PrivilegeEscalation:Runtime/DockerSocketAccessed finding. If this is a case in your AWS environment, we recommend that you set up a suppression rule for this finding type. The first criteria should use the **Finding type** field with value equal to `PrivilegeEscalation:Runtime/DockerSocketAccessed`. The second filter criteria is **Executable path** field with value equal to the process's `executablePath` in the generated finding. Alternatively, the second filter criteria can use **Executable SHA-256** field with value equal to the process's `executableSha256` in the generated finding.
+ Kubernetes clusters run their own DNS servers as pods, such as `coredns`. Therefore, for each DNS lookup from a pod, GuardDuty captures two DNS events – one from the pod and the other from the server pod. This may generate duplicates for the following DNS findings:
  + [Backdoor:Runtime/C&CActivity.B\$1DNS](findings-runtime-monitoring.md#backdoor-runtime-ccactivitybdns)
  + [CryptoCurrency:Runtime/BitcoinTool.B\$1DNS](findings-runtime-monitoring.md#cryptocurrency-runtime-bitcointoolbdns)
  + [Impact:Runtime/AbusedDomainRequest.Reputation](findings-runtime-monitoring.md#impact-runtime-abuseddomainrequestreputation)
  + [Impact:Runtime/BitcoinDomainRequest.Reputation](findings-runtime-monitoring.md#impact-runtime-bitcoindomainrequestreputation)
  + [Impact:Runtime/MaliciousDomainRequest.Reputation](findings-runtime-monitoring.md#impact-runtime-maliciousdomainrequestreputation)
  + [Impact:Runtime/SuspiciousDomainRequest.Reputation](findings-runtime-monitoring.md#impact-runtime-suspiciousdomainrequestreputation)
  + [Trojan:Runtime/BlackholeTraffic\$1DNS](findings-runtime-monitoring.md#trojan-runtime-blackholetrafficdns)
  + [Trojan:Runtime/DGADomainRequest.C\$1DNS](findings-runtime-monitoring.md#trojan-runtime-dgadomainrequestcdns)
  + [Trojan:Runtime/DriveBySourceTraffic\$1DNS](findings-runtime-monitoring.md#trojan-runtime-drivebysourcetrafficdns)
  + [Trojan:Runtime/DropPoint\$1DNS](findings-runtime-monitoring.md#trojan-runtime-droppointdns)
  + [Trojan:Runtime/PhishingDomainRequest\$1DNS](findings-runtime-monitoring.md#trojan-runtime-phishingdomainrequestdns)

  The duplicate findings will include pod, container, and process details that correspond to your DNS server pod. You may set up a suppression rule to suppress these duplicate findings using these fields. The first filter criteria should use the **Finding type** field with value equal to a DNS finding type from the list of findings provided earlier in this section. The second filter criteria could be either **Executable path** with value equal to your DNS server's `executablePath` or **Executable SHA-256** with value equal to your DNS server's `executableSHA256` in the generated finding. As an optional third filter criteria, you can use **Kubernetes container image** field with value equal to the container image of your DNS server pod in the generated finding.

# Creating suppression rules in GuardDuty
Creating suppression rules

A suppression rule is a set of criteria that includes using filter attributes and providing values for which you don't want GuardDuty to generate a finding type. The finding types that match this criteria are automatically archived. To reduce noise, the suppressed findings are not sent to any of the AWS services with which you may integrate. For more information about common use cases for creating suppression rules, see [Suppression rules](findings_suppression-rule.md).

You can visualize, create, and manage suppression rules by using the **Suppression rules** page in the GuardDuty console. Suppression rules can also be generated from your existing saved filters. For more information about creating filters, see [Filtering findings in GuardDuty](guardduty_filter-findings.md). 

 The filter criteria can include an exact match using **Equals** and **NotEquals** operators, a **wildcard match** using the **Matches** and **NotMatches** operators or **comparison match** using **GreaterThan**, **GreaterThanEquals**, **LessThan** and **LessThanEquals** operators. More information on the available operators can be found in the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_Condition.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_Condition.html) page. 

Choose your preferred access method to create a suppression rule for GuardDuty finding types.

------
#### [ Console ]

**To create a suppression rule using the console:**

1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1.  On the **Suppression rules** page, click on the **Create suppression rule** to open the **Create suppression rule** form. 

1.  Enter a **Name** for the suppression rule. The name must be 3-64 characters. Valid characters are a-z, A-Z, 0-9, period (.), hyphen (-), and underscore (\$1). 

1.  The **Description** is optional. If you enter a description, it can have up to 512 characters. Valid characters are a-z, A-Z, 0-9, period (.), hyphen (-), colon (:), brackets(\$1\$1()[]), forward slash (/), and space. 

1.  The **Rank** is optional. It can be a numerical value from 1 up to the total count of filters and suppression rules, plus 1. 

1.  Under the **Attributes** section, select a **Key** and an **Operator** from the drop-down. 

1.  Enter the value either “string” or “date” from the datepicker based on the selected key. If it is a string value, type the text and press enter. Multiple values can be added in case of string values. 

1.  Additional criteria can be added by selecting **Add Criteria** to add another set of **Key**, **Operator** and **Value(s)**. 

1.  Select **Create suppression rule** to create and save the suppression rule. 

You can also create a suppression rule from an existing saved filter. For more information about creating filters, see [Filtering findings in GuardDuty](guardduty_filter-findings.md).

**To create a suppression rule from a saved filter:**

1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1. On the **Findings** page, from the **Saved rules** menu, select a saved filter set rule. This will automatically display the filter set and findings that match the criteria.

1. You can also add more filter criteria to this saved rule. If you don't need additional filter criteria, skip this step. To add one or more filter criteria, follow steps 3 through 7 in [Adding filters on Findings page](guardduty_filter-findings.md#guardduty-add-filters-findings-page), and then continue with the following steps. 

1. After you have added the filter criteria and confirmed that the filtered findings meet your requirements, choose **Create suppression rule**.

1. Enter a **Name** for the suppression rule.The name must be 3-64 characters. Valid characters are a-z, A-Z, 0-9, period (.), hyphen (-), and underscore (\$1).

1. The **Description** is optional. If you enter a description, it can have up to 512 characters.

1. Choose **Create**.

1.  If you don't need to add additional filter criteria to the saved rule, follow steps 4 through 7 to create the filter. 

------
#### [ API/CLI ]

**To create a suppression rule using API:**

1. You can create suppression rules through the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateFilter.html) API. To do so, specify the filter criteria in a JSON file following the format of the example detailed below. The below example will suppress any unarchived low-severity findings that has a DNS request to the `test.example.com` domain. For medium severity findings, the input list will be `["4", "5", "7"]`. For high severity findings, the input list will be `["6", "7", "8"]`. For critical severity findings, the input list will be `["9", "10"]`. You can also filter on the basis of any one value in the list.

   The following example adds a filter for low severity findings for lambda functions with function name prefix "MyFunc" and function tag with prefix not as "TestTag" 

   ```
   {
       "Criterion": {
           "service.action.dnsRequestAction.domain": {
               "Equals": [
                   "test.example.com"
               ]
           },
           "severity": {
               "Equals": [
                   "1",
                   "2",
                   "3"
               ]
           }
       }
   }
   ```

    You can create suppression rules using wildcard characters \$1 and ? . Wildcards in filters are supported using **Matches** and **NotMatches** operators only. To match any number of characters, you can use \$1 in the attribute value and to match a single character, you can use ? in the attribute value. Filters support a maximum of 5 attributes under a single wildcard condition and a maximum of 5 wildcard character within a single attribute. The following example adds a filter for Lambda name matching the prefix “MyFunc" but not Lambda functions with tags with "TestTag" as prefix followed by 0-2 characters. 

   ```
   {
       "Criterion": {
           "resource.lambdaDetails.functionName": {
               "Matches": [
                   "MyFunc*"
               ]
           },
           "resource.lambdaDetails.tags.key": {
               "NotMatches": [
                   "TestTag??"
               ]
           }
       }
   }
   ```

   For a list of JSON field names and their console equivalent see [Property filters in GuardDuty](guardduty_filter-findings.md#filter_criteria).

   To test your filter criteria, use the same JSON criterion in the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html) API, and confirm that the correct findings have been selected. To test your filter criteria using AWS CLI follow the example using your own detectorId and .json file.

   To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.

   ```
   aws guardduty list-detector
   ```

   ```
   aws guardduty list-findings \
   --detector-id 12abc34d567e8fa901bc2d34e56789f0 \
   --region us-east-1 \
   --finding-criteria file://criteria.json
   ```
**Note**  
 Wildcards matching are not available for ListFindings and GetFindingsStatistics. Criteria containing wildcards cannot be validated using ListFindings and GetFindingsStatistics. 

1. Upload your filter to be used as suppression rule with the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateFilter.html) API or by using the AWS CLI following the example below with your own detector ID, a name for the suppression rule, and .json file.

   To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.

   ```
   aws guardduty create-filter \
   --detector-id 12abc34d567e8fa901bc2d34e56789f0 \
   --region us-east-1 \
   --action ARCHIVE \
   --name yourfiltername \
   --finding-criteria file://criteria.json
   ```

You can view a list of your filters programmatically with the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFilter.html) API. You can view the details of an individual filter by supplying the filter name to the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetFilter.html) API. Update filters using [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateFilter.html) or delete them with the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteFilter.html) API.

------

# Updating suppression rules in GuardDuty
Updating suppression rules

 This section provides the steps to update a suppression rule in your AWS account in a specific AWS Region. 

 You can update existing suppression rules from the **Suppression rules** page in the GuardDuty console. GuardDuty supports updating the suppression filter description, rank and filter criteria from the GuardDuty console or by using the GuardDuty CLI/API. Updating suppression rule follows the same restrictions on the field values for description, rank and criteria as [Creating suppression rules](create-suppression-rules-guardduty.md). 

If you're a member account, your administrator account can take this action on your behalf. For more information, see [Administrator account and member account relationships](administrator_member_relationships.md). 

 Choose your preferred access method to delete a suppression rule for GuardDuty findingtypes. 

------
#### [ Console ]

1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1.  On the **Suppression rules** page, select the suppression rule to update. 

1.  From the **Actions** dropdown, select **Update suppression rule**. 

1. This opens the existing the suppression rule form.

1.  Make changes to the **Description**, **Rank** and **Attributes** section as required. 

1.  Select **Update suppression rule** to update the Suppression rule. 

------
#### [ API/CLI ]

**To update a suppression rule using API:**

1.  You can update suppression rules through the UpdateFilter API. Only **description**, **rank** and **criteria** can be updated using the UpdateFilter API. All these three fields are optional. 

1. To update an existing filter, you will need the name of the filter that you are planning to update.

1. If you want to update the existing criteria, create a JSON file with the updated criteria similar to how you first created the filter. An example criteria to suppress any unarchived low-severity findings that has a DNS request to the test.example.com domain. For medium severity findings, the input list will be ["4", "5", "7"]. For high severity findings, the input list will be ["6", "7", "8"]. For critical severity findings, the input list will be ["9", "10"]. You can also filter on the basis of any one value in the list. The following example adds a filter for low severity findings.

   ```
   {
       "Criterion": {
           "service.action.dnsRequestAction.domain": {
               "Equals": [
                   "test.example.com"
               ]
           },
           "severity": {
               "Equals": [
                   "1",
                   "2",
                   "3"
               ]
           }
       }
   }
   ```

    For a list of JSON field names and their console equivalent see [Property filters in GuardDuty](guardduty_filter-findings.md#filter_criteria). 

    To test your filter criteria, use the same JSON criterion in the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html) API, and confirm that the correct findings have been selected. To test your filter criteria using AWS CLI follow the example using your own detectorId and .json file. 

   To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.

   ```
   aws guardduty list-detectors --region us-east-1
   ```

1.  If you want to update the description, you can include the description parameter in the CLI call. 

1.  If you want to update the rank, you can include the rank parameter in the CLI call. 

1.  If you want to update from a suppression filter to a regular filter, using the action parameter and value as **ARCHIVE** in the CLI call. 

1.  Update your existing filter API or by using the AWS CLI following the example below with your own detector ID, a name for the suppression rule, and .json file. 

1.  The following is an example CLI that updates all the parameters described above. You can select the specific parameters to be updated for your use case from the command - 

   ```
   aws guardduty update-filter \
   --detector-id 12abc34d567e8fa901bc2d34e56789f0 \
   --region us-east-1 \
   --action ARCHIVE \
   --rank 1 \
   --description "Updated description" \
   --finding-criteria file://criteria.json
   ```

------

# Deleting suppression rules in GuardDuty
Deleting suppression rules

This section provides the steps to delete a suppression rule in your AWS account in a specific AWS Region.

You may want to delete a suppression rule that no longer depicts an expected behavior in your environment. You no longer want to suppress the associated finding type so that GuardDuty can generate a finding type.

If you're a member account, your administrator account can take this action on your behalf. For more information, see [Administrator account and member account relationships](administrator_member_relationships.md).

Choose your preferred access method to delete a suppression rule for GuardDuty finding types.

------
#### [ Console ]

1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).

1. On the **Suppression rules** page, select the suppression rule to delete.

1.  From the **Actions** dropdown, select **Delete suppression rule**. 

1.  It prompts a confirmation pop-up. Select **Delete** to proceed with the deletion. Or select **Cancel** to cancel the operation. 

------
#### [ API/CLI ]

Run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteFilter.html) API. Specify the filter name and the associated detector ID for the particular Region. 

Alternatively, you can use the following AWS CLI example by replacing the values formatted in *red*:

```
aws guardduty delete-filter \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--filter-name filterName \
--region us-east-1
```

To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.

------