Summary

After upgrading the application identification (App-ID) protobundle from an older release (for example 1.630) to a newer one (for example 1.700 or later), customers who allow only amazon_aws in a security policy observe that other applications begin to be allowed as well. Examples include WeTransfer and Netflix. This article explains why this happens, confirms it is expected behavior, and describes how to scope the policy more precisely.

Symptom

A security policy is configured to allow only amazon_aws and deny everything else. After an App-ID bundle upgrade, traffic for applications such as WeTransfer or Netflix that was previously denied is now permitted.

Session output shows the flow classified as amazon_aws alongside the actual application:

vsm-vcsn0> show vsf session all brief | grep we
0x401ead5   2  1  6  192.168.27.2  18.244.214.71  52558 443  121  184  0  0  wetransfer/(predef)
0x401eadd   2  2  6  192.168.27.2  18.244.214.71  54094 443  161  227  0  0  wetransfer/(predef)
...

Extensive session output with the newer bundle:

    Vparse Session info:
        l7_protos:             211(http) 808(amazon) 809(amazon_aws) 3074(wetransfer)
        l7_base_protos:        211(http) 808(amazon)

    NGFW:
      Evaluation status: Complete
      Evaluation result: Amazon_allow (rule-id: 6209, rule-order: 4)
      Action           : Enforced, user authentication is disabled

Root cause

This is expected behavior, not a defect.

  1. App-ID reports a stack of applications per flow. A single HTTPS session can be classified as multiple applications at once. For a WeTransfer flow served from AWS, App-ID reports http, amazon, amazon_aws, and wetransfer on the same session.
  2. If any reported application is allowed, the session is allowed. VOS security enforcement matching logic allows a session when any one of the applications reported on that session matches an allow rule. Because amazon_aws is in the allow list and is reported on the flow, the session is permitted even though wetransfer was never explicitly allowed.
  3. The newer bundle identifies AWS-hosted infrastructure more completely. The amazon_aws application group sits at base.ip.tcp.ssl.https.amazon.amazon_aws, and over 1300 applications can be reported on top of it. Many vendors host all or part of their service on AWS. WeTransfer has moved its entire infrastructure onto Amazon AWS, so its flows are now identified as amazon_aws and matched by the allow rule.
  4. Older bundles did not detect the underlying AWS layer. Bundle 1.630 was released around April 2023 and carries outdated App-ID signatures. On that bundle the same WeTransfer or Netflix flow is identified only as the application itself, not as amazon_aws, so it falls through to the deny rule.

Comparison on the older bundle (1.630), where the AWS layer is not detected and the flow is denied:

Vparse Session info:
        l7_protos:             211(http) 3074(wetransfer)
        l7_base_protos:        211(http) 3074(wetransfer)

    NGFW:
      Denied Session by rule Allow_all

The same applies to Netflix. Netflix uses AWS for backend services (authentication, browsing, recommendations, billing, APIs, logging) while most video delivery comes from its own Open Connect CDN. As a result, a Netflix session can be classified as amazon_aws when it traverses AWS, or only as netflix when it is served from Netflix-owned servers. Both are Netflix, but only the AWS-served flow matches an amazon_aws rule.

Confirming destination ownership illustrates the distinction:

  • 45.57.91.1 (host assets.nflxext.com) is owned by Netflix, not AWS. It does not match the AWS rule and is denied.
  • 44.229.122.169 (host logs.netflix.com) is owned by AWS. It matches the AWS rule and is allowed.

All destination IPs in the reported WeTransfer sessions resolve to Amazon (AS16509), predominantly Amazon CloudFront edge nodes, which is why those flows match amazon_aws.

Resolution

Allowing the amazon_aws application is inherently broad, because so many third-party applications are delivered over AWS. To permit AWS itself without admitting every application hosted on AWS, replace the rule that allows the amazon_aws application with a rule that matches AWS by URL using a URL-filtering (URLF) rule. Match the following AWS domain patterns instead of the amazon_aws application:

.*amazonaws.com*
.*amazonwebservices.com*
.*aws.amazon.com*
.*aws.dev*
.*awsapps.com*
.*awsstatic.com*
.*cloudfront.net*
.*console.aws.a2z.com*
.*media-amazon.com*
.*signin.aws*
.*ssl-images-amazon.com*

This narrows the allow decision to genuine AWS service domains rather than any flow that App-ID happens to report as amazon_aws. Applications such as WeTransfer that are merely hosted on AWS but use their own domains will then be matched and handled by their respective rules instead of being allowed under the AWS rule.

Recommendations

  • Always run the latest App-ID protobundle. Bundle 1.630 (April 2023) has outdated signatures; newer bundles provide more accurate and complete application identification.
  • When the intent is to allow Amazon AWS as a service, prefer URL-based matching over allowing the broad amazon_aws application group, since over 1300 applications can be reported on top of it.
  • To verify what an individual flow is being classified as, use vsh connect vsmd, then  identify the session in question and view: show vsf session handle extensive <handle> and review the l7_protos list and the NGFW evaluation result.