DEV Community: nishikawaakira

Mitigating Session Hijacking with JA4 Session Binding and AWS WAF Dynamic Label Interpolation

nishikawaakira — Sat, 18 Jul 2026 20:19:25 +0000

So, how are you protecting your applications against session hijacking?

For many web applications, the harsh reality is that once a session cookie is stolen, the game is basically over. With infostealer malware now exfiltrating cookies along with everything else, the assumption that “possession of the cookie equals proof of identity” is gradually becoming less reliable.

In this article, I will show how to use AWS WAF Dynamic Label Interpolation to pass a JA4 TLS fingerprint to your application and bind it to the user’s session. With this design, even if an attacker steals a session cookie, the application can detect its use when the attacker’s TLS stack differs from that of the legitimate user.

I previously wrote about mitigating session hijacking with an “Impossible Location” check. You can think of this article as a location-independent version of that approach.

The other articles in this series are listed below. This article is also written to stand on its own, so you can continue reading without them.

Forwarding JA4 to the Application: A Recap of Article 2

JA4 is a fingerprint of the client implementation calculated from the TLS ClientHello. Chrome, curl, and Python’s requests library produce different values because they use different TLS stacks.

The important point is that a JA4 fingerprint cannot be reproduced merely by stealing a cookie. JA4 reflects characteristics of the TLS stack itself, so producing the same value requires the attacker to imitate the victim’s TLS implementation as well.

AWS WAF Dynamic Label Interpolation lets you forward JA4 to the origin with a single Count rule. No CloudFront origin request policy configuration is required for this path.

{
  "Name": "forward-ja4",
  "Statement": { "...": "A condition that matches all requests" },
  "Action": {
    "Count": {
      "CustomRequestHandling": {
        "InsertHeaders": [
          { "Name": "ja4", "Value": "${awswaf:ja4:}" }
        ]
      }
    }
  }
}

The origin receives the value in the x-amzn-waf-ja4 header. Because AWS WAF inserts this header, the application can treat it as a server-side signal that the client cannot directly spoof—provided that there is no route to the origin that bypasses WAF.

If clients can reach the origin directly, the header becomes little more than a self-declared value. The origin must therefore reject traffic that does not come through CloudFront.

Implementing Session Binding

The basic implementation is simple: record the JA4 fingerprint in the session after a successful login, then compare it with the fingerprint observed on subsequent requests.

// After a successful login
function onLoginSuccess(req, session) {
    session.boundFingerprints = [req.headers['x-amzn-waf-ja4']];
    session.fingerprintAlerts = 0;
}

// Authentication middleware
function verifySession(req, res, next) {
    const current = req.headers['x-amzn-waf-ja4'];
    const bound = req.session.boundFingerprints;

    if (bound.includes(current)) return next();  // Known fingerprint

    // Unknown fingerprint: treat it as a risk signal rather than blocking immediately
    req.session.fingerprintAlerts += 1;
    if (isHighRiskOperation(req) || req.session.fingerprintAlerts > THRESHOLD) {
        return res.redirect('/reauth');  // Add it to bound after successful reauthentication
    }
    next();
}

At this point, you may be thinking: “Why use bound.includes(current)? Why not bind the session to one exact value with bound === current?”

Good catch. That question leads directly to the main topic of this article: strict equality can incorrectly reject legitimate users.

JA4 Can Change Even for the Same Client

The FoxIO README includes several JA4 fingerprints produced by the same Chrome client under different conditions.

section a  section b    section c
t13d1516h2_8daaf6152771_02713d6af862   (TCP)
q13d0312h3_55b375c5d22e_06cda9e17597   (QUIC = HTTP/3)
t13d1517h2_8daaf6152771_b0da82dd1658   (pre-shared key = session resumption)
t13d1517h2_8daaf6152771_b1ff8ab2d16f   (no key)

There are at least three sources of variation.

TLS session resumption with a PSK

When a client reconnects using session resumption, the ClientHello includes the pre_shared_key extension. This changes the extension count in the a section and also changes the c section. In the example above, the relevant value changes from 1516 to 1517.

HTTP/2 (`h2`) versus HTTP/3 (`h3`)

HTTP/3 runs over QUIC, so the protocol marker changes from t to q, and the a, b, and c sections can all change. Modern browsers can move between HTTP/2 and HTTP/3, so it is normal for a single user to produce more than one family of JA4 fingerprints.

Browser updates

A browser update can change the TLS stack and therefore change the JA4 fingerprint. This may not happen with every release, but over a sufficiently long period it is inevitable.

Testing the Behavior

To verify this behavior, I configured an AWS WAF Count rule to insert ${awswaf:ja4:}, then used a CloudFront Function to return the observed value as JSON. I collected and compared JA4 fingerprints from the same machine under different conditions.

First, I changed the HTTP version while using the same curl binary.

Client	JA4
`curl --http1.1`	`t13d3012h1_1d37bd780c83_882d495ac381`
`curl --http2`	`t13d3012h2_1d37bd780c83_882d495ac381`
`curl --http3`	`q13d0312h3_55b375c5d22e_c0efc70deb60`

The HTTP/1.1 and HTTP/2 values are identical except for the ALPN field, h1 versus h2. When the connection switches to HTTP/3 over QUIC, however, the leading transport marker changes from t to q, and all three JA4 sections change.

In other words, even the same curl binary can produce a different fingerprint when the transport path changes.

Next, I forced Chrome to use TCP with HTTP/2 and compared a full TLS handshake with resumed sessions. The procedure was:

Fully quit and restart Chrome.
Access the site once to produce a full handshake.
Open chrome://net-internals/#sockets and select Flush socket pools.
Reload the page to trigger session resumption.

State	JA4	Numeric portion of the `a` section
Full handshake, first request	`t13d1516h2_8daaf6152771_806a8c22fdea`	`1516`
Session resumption, first attempt	`t13d1517h2_8daaf6152771_a87ad97598a9`	`1517`
Session resumption, second attempt	`t13d1517h2_8daaf6152771_a87ad97598a9`	`1517`
Session resumption, third attempt	`t13d1517h2_8daaf6152771_a87ad97598a9`	`1517`

Even though this was the same browser and the same application session, session resumption changed the numeric value in the a section from 1516 to 1517, and the c section changed as well. This is because the resumed ClientHello contains one additional pre_shared_key extension. The final two digits in that part of the a section represent the extension count.

Interestingly, the transition from t13d1516..._8daaf6152771 to t13d1517..._8daaf6152771 matches the Chrome example in the FoxIO README through both the a and b sections.

These results reveal three facts that directly affect session-binding design.

1. The `b` section is relatively stable within the same transport family

The b section is the hash of the cipher-suite list. In my tests, it remained unchanged across HTTP/1.1 and HTTP/2 and across full and resumed TCP handshakes: 8daaf6152771 for Chrome and 1d37bd780c83 for curl.

Switching to QUIC can change it because QUIC uses TLS 1.3 and presents a different cipher-suite profile. Even so, the b section was the most stable part of JA4 within a given transport family.

2. The variation converges on a small number of values

For the TCP case, the fingerprint changed once between the full handshake and the first PSK-based resumption, then remained stable on the second and third resumed connections.

This suggests that remembering two values—a full-handshake fingerprint and a resumed-session fingerprint—may be sufficient to recognize that client’s normal TCP behavior.

3. QUIC reduces distinguishing power

QUIC is limited to TLS 1.3 and therefore has fewer cipher-suite combinations. In my measurements, Chrome over HTTP/3 produced a fingerprint beginning with q13d0311h3_55b375c5d22e_..., whose a and b sections were very similar to those produced by curl over HTTP/3.

With HTTP/3, the c section or an additional signal such as JA4H may be necessary to distinguish clients reliably.

Turning the Findings into a Practical Design

Based on these observations, a practical session-binding design looks like this:

Do not require one exact JA4 value. Otherwise, legitimate users may be rejected whenever TLS session resumption occurs or the browser switches between HTTP/2 and HTTP/3.
Maintain a set of previously observed fingerprints and combine it with a risk score. An unknown value should increase risk rather than cause an immediate block. Require reauthentication only before high-risk operations such as money transfers, password changes, email-address changes, or account deletion.
When using a relaxed comparison, compare JA4 section by section. JA4 is designed so that similar client fingerprints remain structurally comparable. For example, you can give greater weight to a matching b section while allowing expected variation in a and c.

Simply being able to notice that a stolen cookie is being used from a different TLS stack is already valuable. Adding too many conditions, on the other hand, can quickly drown the system in false positives. The balance matters.

Step-Up Authentication with ATP Signals

Another authentication-related use case for Dynamic Label Interpolation is AWS WAF Account Takeover Prevention, or ATP.

ATP inspects login requests and emits labels for signals such as compromised credential use and credential-stuffing activity.

Previously, forwarding these signals required a separate rule for each label. With Dynamic Label Interpolation, you can forward the entire namespace instead.

{
  "Name": "forward-atp-signals",
  "Statement": {
    "LabelMatchStatement": {
      "Scope": "NAMESPACE",
      "Key": "awswaf:managed:aws:atp:signal:"
    }
  },
  "Action": {
    "Count": {
      "CustomRequestHandling": {
        "InsertHeaders": [
          {
            "Name": "atp-signals",
            "Value": "${awswaf:managed:aws:atp:signal:}"
          }
        ]
      }
    }
  }
}

The application receives the values in x-amzn-waf-atp-signals. If the header contains credential_compromised, for example, the application could allow the login to complete but immediately require the user to reset the password.

This is not simply “blocking with WAF.” It turns WAF detections into inputs for adaptive or step-up authentication, allowing the application to strengthen the authentication flow according to the observed risk.

One caveat: ATP is a paid managed rule group with subscription and request-based charges. You should also confirm the current label names and behavior in the official documentation before deploying this in production.

Conclusion

AWS WAF Dynamic Label Interpolation can forward JA4 to the application, allowing a session to be associated with a TLS fingerprint. An attacker may steal a cookie, but reproducing the victim’s TLS fingerprint requires substantially more effort.
JA4 can change even for the same client because of TLS session resumption, HTTP/2-to-HTTP/3 switching, and browser updates. Binding a session to one exact JA4 value can therefore reject legitimate users.
A set of known fingerprints, a risk score, and reauthentication before high-risk operations appear to be a practical middle ground.
ATP detections can be used not only to block requests, but also to drive stronger authentication and account-recovery controls.

In the next article, I will cover the reverse direction: a feedback loop in which the application reports a malicious client back to the edge so that subsequent requests can be blocked there.

Building a False-Positive-Resilient Challenge Architecture with AWS WAF Dynamic Label Interpolation

nishikawaakira — Wed, 15 Jul 2026 22:19:27 +0000

In May 2026, AWS WAF introduced a feature called dynamic label interpolation. Did you catch the announcement?

It may look like a small addition at first, but I think it offers an elegant way to address one of the hardest parts of operating bot defenses: dealing with false positives.

In this article, I’ll show how to use dynamic label interpolation to build a challenge architecture that gives legitimate users caught by a false positive a self-service way to report the issue and regain access.

Anyone who operates bot protection with a WAF has probably wrestled with false positives. Legitimate users can occasionally be misclassified as bots, which often leads teams to avoid enabling blocking altogether.

The architecture described in this article takes a different approach: instead of treating a bot-detection signal as a final verdict, it redirects suspicious clients to a challenge and allows legitimate users to recover on their own. In practice, this can virtually eliminate false-positive blocking caused by bot detection, even when the underlying detection is not perfect. This design extends the architecture from my previous article, in which clients flagged by JA4H-based detection are redirected to a challenge page rather than blocked immediately. However, this article is written to stand on its own.

What Is Dynamic Label Interpolation?

AWS WAF rules can attach labels to requests. Managed rule groups such as Bot Control also emit a large number of labels, including values such as:

awswaf:managed:aws:bot-control:bot:category:scraping

Previously, forwarding these label values to the origin or including them in a response required a separate rule for each label and a statically defined header value.

Dynamic label interpolation changes that. With the ${namespace:} syntax, AWS WAF can resolve labels attached to a request at evaluation time and embed the resulting values in custom headers or response bodies.

Request label:        awswaf:managed:aws:bot-control:bot:category:scraping
Configured value:     ${awswaf:managed:aws:bot-control:bot:category:}
Resolved value:       scraping

The resolution rules are straightforward:

If exactly one label matches the namespace, AWS WAF returns the final value.
If multiple labels match, AWS WAF removes the namespace prefix and returns a comma-separated list, such as scraping,advertising.
If no labels match, the placeholder resolves to an empty string.

You can also use built-in values called synthetic labels. Unlike ordinary labels, which are attached to a request as rules evaluate it, synthetic labels resolve information already associated with the request itself, such as the client IP address, TLS handshake fingerprint, or the request ID assigned by AWS WAF.

Synthetic label	Value
`${awswaf:request_id:}`	AWS WAF request ID
`${awswaf:ip:}`	Client IP address
`${awswaf:ja3:}`	JA3 TLS fingerprint
`${awswaf:ja4:}`	JA4 TLS fingerprint

Constraints to Understand Before You Design

Before looking at the use cases, let’s review the constraints that affect the architecture. Missing these details can lead to avoidable rework later.

1. Custom request headers can be inserted only by Allow, Count, CAPTCHA, and Challenge actions

A Block action can return only a custom response: a status code, response headers, and a response body.

This is logical when you think about it. “Block the request while also forwarding a header to the origin” is inherently contradictory, because a blocked request never reaches the origin.

2. Inserted request headers receive the `x-amzn-waf-` prefix

Many AWS WAF users will already be familiar with this behavior. If you configure a rule to insert a header named bot-category, the origin receives it as:

x-amzn-waf-bot-category

The prefix is not added to response headers.

3. With CAPTCHA and Challenge actions, requests without a valid token are not forwarded to the origin

AWS WAF returns the challenge response immediately. Custom request headers are inserted only for requests that pass token inspection and are forwarded.

Conversely, the origin can treat the presence of such a header as evidence that the request has already passed the AWS WAF challenge.

4. Each string value can contain at most 10 placeholders

The eleventh and subsequent placeholders are not resolved. They are emitted literally as ${...}.

This limit applies per string value rather than to the entire request, so you can work around it by splitting the values across multiple headers.

5. Interpolating custom labels requires fully qualified names

In a rule definition, you can attach a custom label using a short name such as:

app:tier:enterprise

However, an interpolation reference must include the full Web ACL context:

${awswaf:ACCOUNT_ID:webacl:WEBACL_NAME:app:tier:}

Label match statements can use the short local namespace, so the two mechanisms are asymmetric in this respect.

6. A namespace with no matching labels resolves to an empty string

Remember to handle the case where the header exists but its value is empty. At the origin, that will usually represent an unclassified request.

Use Case 1: Embed `request_id` in the Block Page to Create a False-Positive Feedback Loop

False positives are unavoidable in bot mitigation operations.

Security products and corporate proxies may rewrite headers and change a client fingerprint. A legitimate user may also happen to use the same client implementation as one listed as malicious. In either case, a real user can be caught by a blocking rule.

When that happens, the report from the user is often no more specific than, “I cannot access the site.” Identifying which request matched which rule can then take a significant amount of time.

A simple improvement is to embed the AWS WAF request ID directly in the block page.

{
  "CustomResponseBodies": {
    "BlockPage": {
      "Content": "Access has been blocked.\n\nRequest ID: ${awswaf:request_id:}\nIP: ${awswaf:ip:}\n\nIf you believe this is an error, contact support and include the Request ID shown above.",
      "ContentType": "TEXT_PLAIN"
    }
  }
}

The user only needs to copy the Request ID into the support ticket. The support team can then search the AWS WAF logs for that ID and immediately identify the request, the rule that matched, and every label attached to it.

What used to be “half a day investigating a possible false positive” becomes a single log query. Once the request is confirmed as legitimate, you can exempt the relevant fingerprint or signature and close the case.

This may sound like a modest improvement, but it represents an important shift in design philosophy: make false-positive recovery part of the operational workflow.

Eliminating false positives entirely is unrealistic. It is often more productive to invest in minimizing the cost of recovery when they inevitably occur.

Use Case 2: Carry the Fingerprint into the Challenge Page

An outright block can still damage user trust. In my previous article, I introduced an architecture in which suspicious clients are redirected to a challenge page rather than blocked immediately. Once they pass the challenge, a clearance cookie allows subsequent requests through.

Dynamic label interpolation strengthens that architecture in two places.

During redirection: interpolate values into the `Location` header

A custom response from a Block action can specify a status code and response headers. Interpolation also works in the Location header.

When redirecting a suspicious request to a challenge page with a 302, you can include the fingerprint and request ID observed at that moment in the query string.

{
  "Name": "suspicious-to-challenge",
  "Statement": {
    "LabelMatchStatement": {
      "Scope": "NAMESPACE",
      "Key": "awswaf:managed:aws:bot-control:bot:category:"
    }
  },
  "Action": {
    "Block": {
      "CustomResponse": {
        "ResponseCode": 302,
        "ResponseHeaders": [
          {
            "Name": "Location",
            "Value": "/challenge?fp=${awswaf:ja4:}&rid=${awswaf:request_id:}"
          },
          { "Name": "Cache-Control", "Value": "no-store" }
        ]
      }
    }
  }
}

The challenge page now knows, from the start, which fingerprint and which request caused the redirect.

You can aggregate challenge impressions and completion rates by fingerprint. This enables data-driven hygiene checks on your fingerprint list—for example, “This fingerprint has a 99% challenge pass rate, so we should remove it from the suspicious list.”

There is one important security caveat: the fp query parameter can be modified by the client. Do not use it for authorization decisions. Limit its use to logging and correlation analysis.

The authoritative fingerprint used for authorization must be observed again during challenge verification, as described next.

After success: issue a clearance cookie bound to the fingerprint

Validate the challenge—using Turnstile, reCAPTCHA, or another mechanism—at the origin. When validation succeeds, issue a clearance cookie protected by an HMAC signature.

Include the JA4 value observed during verification in the signed cookie. The origin can obtain a trusted value from the CloudFront-Viewer-JA4-Fingerprint header forwarded through an origin request policy.

clearance = base64(ja4 + "|" + expiry) + "." + HMAC-SHA256(ja4 + "|" + expiry, secret)

For subsequent requests, validate the cookie in a CloudFront Function on the viewer-request event. In addition to checking the signature and expiration time, compare the JA4 stored in the cookie with the JA4 of the current request.

// Example clearance validation in CloudFront Functions (cloudfront-js-2.0)
var crypto = require('crypto');

function hasValidClearance(request) {
    var c = request.cookies['clearance'];
    var ja4 = request.headers['cloudfront-viewer-ja4-fingerprint'];
    if (!c || !ja4) return false;

    var parts = c.value.split('.');
    if (parts.length !== 2) return false;
    var payload = String.bytesFrom(parts[0], 'base64');  // "ja4|expiry"
    var sig = crypto.createHmac('sha256', SECRET).update(payload).digest('hex');
    if (sig !== parts[1]) return false;

    var fields = payload.split('|');
    if (Number(fields[1]) < Date.now() / 1000) return false;   // Expired
    return fields[0] === ja4.value;                            // JA4 matches
}

This prevents an attacker from stealing only the clearance cookie and reusing it from a different client with a different TLS stack.

Stealing a cookie is one thing. Accurately reproducing the associated TLS fingerprint at the same time is a substantially harder problem.

The Evaluation-Order Trap

As I mentioned in the previous article, AWS WAF evaluates a CloudFront request before CloudFront Functions runs.

The responsibilities in this architecture are therefore divided as follows:

AWS WAF: Redirects suspicious requests to the challenge flow with Block + 302, and interpolates ordinary and synthetic labels. AWS WAF cannot calculate an HMAC, so it can check only whether the cookie is present.
CloudFront Functions: Cryptographically validates the clearance cookie by checking its HMAC and matching its JA4 value. This is where requests carrying a cookie that AWS WAF allowed through are authenticated.
Origin: Verifies the challenge and issues the clearance cookie.

The AWS WAF rule should be structured as follows:

Suspicious label is present AND clearance cookie is absent -> 302 redirect

Requests that have a clearance cookie are allowed through AWS WAF and validated by CloudFront Functions.

An attacker who knows the cookie name can get past the AWS WAF condition by sending a fake cookie, but the function immediately rejects an invalid value. The result is a two-stage defense.

Testing the Actual Behavior

A few details could not be established conclusively from the documentation alone, so I created a test Web ACL and verified them directly.

The test configuration included:

A Count rule that inserts headers whose values contain synthetic labels
Two rules that attach different custom labels under the same namespace
A Block rule that returns a 302 with interpolation in the Location header

For observation, I used a probe CloudFront Function on the viewer-request event that returns all request headers as JSON.

`rules.json`

[
  {
    "Name": "label-one",
    "Priority": 10,
    "Statement": {
      "ByteMatchStatement": {
        "SearchString": "multi",
        "FieldToMatch": { "SingleHeader": { "Name": "x-waf-test" } },
        "PositionalConstraint": "EXACTLY",
        "TextTransformations": [{ "Priority": 0, "Type": "NONE" }]
      }
    },
    "RuleLabels": [{ "Name": "app:test:one" }],
    "Action": { "Count": {} },
    "VisibilityConfig": { "SampledRequestsEnabled": true,
      "CloudWatchMetricsEnabled": true, "MetricName": "labelone" }
  },
  {
    "Name": "label-two",
    "Priority": 11,
    "Statement": {
      "ByteMatchStatement": {
        "SearchString": "multi",
        "FieldToMatch": { "SingleHeader": { "Name": "x-waf-test" } },
        "PositionalConstraint": "EXACTLY",
        "TextTransformations": [{ "Priority": 0, "Type": "NONE" }]
      }
    },
    "RuleLabels": [{ "Name": "app:test:two" }],
    "Action": { "Count": {} },
    "VisibilityConfig": { "SampledRequestsEnabled": true,
      "CloudWatchMetricsEnabled": true, "MetricName": "labeltwo" }
  },
  {
    "Name": "forward-signals",
    "Priority": 20,
    "Statement": {
      "SizeConstraintStatement": {
        "FieldToMatch": { "SingleHeader": { "Name": "x-waf-test" } },
        "ComparisonOperator": "GE", "Size": 1,
        "TextTransformations": [{ "Priority": 0, "Type": "NONE" }]
      }
    },
    "Action": {
      "Count": {
        "CustomRequestHandling": {
          "InsertHeaders": [
            { "Name": "test-ja4",     "Value": "${awswaf:ja4:}" },
            { "Name": "test-rid",     "Value": "${awswaf:request_id:}" },
            { "Name": "test-ip",      "Value": "${awswaf:ip:}" },
            { "Name": "test-multi",   "Value": "${awswaf:ACCOUNT_ID:webacl:WEBACL_NAME:app:test:}" },
            { "Name": "test-nomatch", "Value": "${awswaf:ACCOUNT_ID:webacl:WEBACL_NAME:app:nothing:}" }
          ]
        }
      }
    },
    "VisibilityConfig": { "SampledRequestsEnabled": true,
      "CloudWatchMetricsEnabled": true, "MetricName": "forwardsignals" }
  },
  {
    "Name": "challenge-redirect",
    "Priority": 30,
    "Statement": {
      "ByteMatchStatement": {
        "SearchString": "block",
        "FieldToMatch": { "SingleHeader": { "Name": "x-waf-test" } },
        "PositionalConstraint": "EXACTLY",
        "TextTransformations": [{ "Priority": 0, "Type": "NONE" }]
      }
    },
    "Action": {
      "Block": {
        "CustomResponse": {
          "ResponseCode": 302,
          "ResponseHeaders": [
            { "Name": "Location",
              "Value": "/challenge?fp=${awswaf:ja4:}&rid=${awswaf:request_id:}" },
            { "Name": "Cache-Control", "Value": "no-store" }
          ]
        }
      }
    },
    "VisibilityConfig": { "SampledRequestsEnabled": true,
      "CloudWatchMetricsEnabled": true, "MetricName": "challengeredirect" }
  }
]

# Because this is a Count rule, the headers should be inserted and the
# synthetic-label values should be available.
$ curl -s "https://dxxxx.cloudfront.net/probe" -H "x-waf-test: 1" \
    | jq '.headers[] | select(.name | startswith("x-amzn-waf"))'
{ "name": "x-amzn-waf-test-ja4",     "value": "t13d4907h2_0d8feac7bc37_7395dae3b2f3" }
{ "name": "x-amzn-waf-test-rid",     "value": "F1CXnajGxmUxPQ5e_..." }
{ "name": "x-amzn-waf-test-ip",      "value": "2400:xxxx:..." }
{ "name": "x-amzn-waf-test-multi",   "value": "" }
{ "name": "x-amzn-waf-test-nomatch", "value": "" }

# Verify comma-separated resolution. Two Count rules attach app:test:one
# and app:test:two when x-waf-test is "multi". This shows how
# ${...:app:test:} resolves both labels.
$ curl -s ... -H "x-waf-test: multi" | jq -r '...test-multi...'
one,two

# Verify interpolation in the Location header of a Block custom response.
# Because this is a block rule, the response should redirect to the challenge.
$ curl -sv ... -H "x-waf-test: block" 2>&1 | grep -i '^< location'
< location: /challenge?fp=t13d4907h2_0d8feac7bc37_7395dae3b2f3&rid=SHCiGoKo...

The tests confirmed the following behavior.

Synthetic labels resolve correctly

All three tested synthetic labels—ja4, request_id, and ip—resolved successfully.

Interpolation in the Location header also produced a working redirect.

Multiple labels resolve to a comma-separated list

The two labels resolved as:

one,two

In a real Bot Control deployment, for example, if a single request receives both signal:non_browser_user_agent and signal:automated_browser, then ${...signal:} resolves to:

non_browser_user_agent,automated_browser

A namespace with no matches still inserts the header with an empty value

AWS WAF does not omit the header entirely. The receiving component does not need to test whether the header exists; it only needs to check whether the value is empty.

Headers inserted by AWS WAF are visible to CloudFront Functions on `viewer-request`

The probe itself ran as a CloudFront Function, so the fact that these headers appeared in its output directly demonstrates that the function could access them.

This last finding significantly expands the available design space.

Because the order is AWS WAF evaluation followed by CloudFront Functions, AWS WAF can pass JA4 to the function without an origin request policy. Bot Control category labels can also drive branching logic in the function—for example, selecting different levels of challenge difficulty.

The JA4 value used for clearance-cookie validation can be delivered through the same path.

As a bonus, I compared JA4 values over HTTP/1.1 and HTTP/2. The results were t13d4907h1_... and t13d4907h2_...: only the single ALPN(Application-Layer Protocol Negotiation) character differed, while the rest of the fingerprint remained identical.

This is a neat real-world demonstration of how ALPN is encoded in the a section of the JA4 format.

Summary

Dynamic label interpolation lets AWS WAF resolve classification signals from ordinary labels, along with synthetic values such as request_id, IP address, JA3, and JA4, into headers and response bodies at evaluation time.
Adding ${awswaf:request_id:} to a block page turns false-positive investigation into a single log search. Because false positives cannot be eliminated completely, design for lower recovery cost.
Interpolation in the Location header can carry a fingerprint into the challenge page. Because query-string values can be tampered with, use them only for logging and reacquire the authoritative value during verification.
Binding and signing a clearance cookie to JA4 creates a challenge architecture that cannot be bypassed merely by stealing the cookie.
Headers inserted by AWS WAF are visible to CloudFront Functions on viewer-request. This lets you pass JA4 and AWS WAF classification signals to an edge function without an origin request policy.
Account for the constraints up front: Block actions cannot insert request headers, inserted headers receive the x-amzn-waf- prefix, each string allows at most 10 placeholders, custom labels require fully qualified interpolation names, and unmatched namespaces resolve to an empty string.

Adding a Request ID to an existing Web ACL’s block page takes about five minutes. That is a great place to start.

Used effectively, dynamic label interpolation could move us toward a future where false positives are no longer something we have to fear when operating bot detection with AWS WAF. Give it a try.

Implementing a JA4H-Equivalent Fingerprint with Amazon CloudFront Functions to Mitigate Bot Traffic

nishikawaakira — Tue, 14 Jul 2026 23:11:40 +0000

JA3 and JA4 fingerprints have been showing up more and more often in discussions about bot mitigation and client identification. Amazon CloudFront exposes TLS-based JA4 as a CloudFront-generated header, but it does not provide the HTTP-request-based JA4H fingerprint.

That made me wonder: “Why not implement it ourselves with CloudFront Functions?” So I did. There are a few gotchas and design considerations you need to be aware of, and I’ll cover those as well.

In this article, I’ll first demonstrate the limitation through hands-on testing, then work around it with the CloudFront-Viewer-Header-Order header and show how to calculate a JA4H-equivalent fingerprint entirely within CloudFront Functions.

What Is JA4?

JA4+ is a suite of network fingerprints published by FoxIO and positioned as a successor to JA3. The best-known member is JA4, which is calculated from the TLS ClientHello. It generates a short string that is nearly unique to a particular client implementation, based on factors such as the TLS version, whether SNI is present, cipher suites, and extensions.

The key idea behind JA4 is that the same implementation tends to produce the same value. Chrome, curl, and Python’s requests, for example, each have distinct characteristics in their TLS stacks and therefore produce different JA4 fingerprints.

A User-Agent string can be spoofed freely, but accurately reproducing every detail of a TLS handshake is considerably harder. This makes it possible to detect inconsistencies such as a client claiming to be Chrome in its User-Agent while presenting a JA4 fingerprint associated with Python.

In addition to TLS-based JA4, the JA4+ suite includes several other variants, such as JA4H, which is calculated from HTTP request headers, and JA4S, which fingerprints the server side of a TLS connection.

Amazon CloudFront, JA4, and CloudFront KVS

CloudFront announced support for JA3 in 2022 and JA4 in October 2024. By adding CloudFront-Viewer-JA4-Fingerprint to an origin request policy, you can receive the precomputed JA4 value as a request header.

This header is also available to a CloudFront Function running on the viewer-request event. Combined with CloudFront KeyValueStore (KVS), it lets you operate a blocklist of known malicious fingerprints entirely at the edge.

import cf from 'cloudfront';
const kvs = cf.kvs();

async function handler(event) {
    const request = event.request;
    const ja4 = request.headers['cloudfront-viewer-ja4-fingerprint'];
    if (ja4) {
        try {
            const action = await kvs.get(ja4.value); // Example: "block"
            if (action === 'block') {
                return { statusCode: 403, statusDescription: 'Forbidden' };
            }
        } catch (e) {
            // get() throws when the key does not exist.
            // An unregistered fingerprint is not known to be malicious, so do nothing.
        }
    }
    return request;
}

KVS can be updated immediately through the console or API. For example, you can analyze suspicious requests in existing logs, register their fingerprint values in KVS, and begin blocking them without redeploying the function.

What Is JA4H?

JA4H is a fingerprint calculated from the HTTP request itself. It consists of four parts joined by underscores:

JA4H = <a>_<b>_<c>_<d>
Example: ge11cn05enus_974ebe531c03_000000000000_000000000000

JA4H_a: The first two characters of the HTTP method + two digits representing the HTTP version + whether a Cookie is present (c/n) + whether a Referer is present (r/n) + a two-digit header count excluding Cookie and Referer + the first four characters derived from Accept-Language
JA4H_b: The first 12 hexadecimal characters of a SHA-256 hash over the comma-separated header names in their original transmission order, excluding Cookie and Referer
JA4H_c: A hash of the sorted, comma-separated Cookie names
JA4H_d: A hash of the sorted, comma-separated Cookie name=value pairs

The most important part is JA4H_b. Browsers and HTTP clients have implementation-specific habits in the order in which they send headers, so that order becomes useful identifying information.

Conversely, calculating JA4H accurately requires both the original header order and header information that has not been rewritten along the way.

Implementing JA4H in CloudFront Functions

Recovering header order and original casing with `CloudFront-Viewer-Header-Order`

It turns out that the CloudFront Functions event object alone is not enough to calculate JA4H.

As the official documentation states, “Header names are converted to ASCII-lowercase in the event object.” In addition, headers is an object keyed by header name, so it does not expose the order in which headers were sent. I confirmed this experimentally: changing the transmission order did not change the order visible in the event object.

This is where the CloudFront request header CloudFront-Viewer-Header-Order comes in.

Contains the viewer's header names in the order requested, separated by a colon.

CloudFront-Viewer-Header-Order contains the header names sent by the viewer, in the order CloudFront received them, separated by colons. The value is not affected by the event object’s lowercase normalization. In my tests, it contained the information required for JA4H_b:

$ curl -s --http1.1 ... -H "X-Test-ZZZ: 1" -H "x-test-aaa: 2"
→ Host:User-Agent:Accept:X-Test-ZZZ:x-test-aaa

$ curl -s --http1.1 ... -H "x-test-aaa: 2" -H "X-Test-ZZZ: 1"
→ Host:User-Agent:Accept:x-test-aaa:X-Test-ZZZ

$ curl -s --http1.1 ... -H "x-dup: 1" -H "X-Test-ZZZ: 1" -H "x-dup: 2"
→ Host:User-Agent:Accept:x-dup:X-Test-ZZZ:x-dup

When the request is sent over HTTP/2, the value becomes fully lowercase, such as host:user-agent:accept:.... That is expected because HTTP/2 requires header field names to be lowercase.

CloudFront-Viewer-Header-Order is not included in the managed AllViewerAndCloudFrontHeaders-2022-06 origin request policy, so you need to create a custom policy and add it explicitly. You should also add CloudFront-Viewer-Http-Version, because the HTTP version required for JA4H_a is not included in the event object.

aws cloudfront create-origin-request-policy --origin-request-policy-config '{
  "Name": "ja4h-policy",
  "HeadersConfig": {
    "HeaderBehavior": "allViewerAndWhitelistCloudFront",
    "Headers": {"Quantity": 2, "Items": [
      "CloudFront-Viewer-Header-Order",
      "CloudFront-Viewer-Http-Version"]}
  },
  "CookiesConfig": {"CookieBehavior": "all"},
  "QueryStringsConfig": {"QueryStringBehavior": "all"}
}'

There are two caveats.

First, the header value is truncated at 7,680 characters, so the resulting JA4H value may be inaccurate for requests containing an extreme number of headers.

Second, the preservation of header-name casing is behavior I observed experimentally; it is not explicitly guaranteed in the documentation. Keep that assumption in mind when relying on it.

Implementation

CloudFront Functions runtime 2.0 includes the crypto module, so SHA-256 can be calculated directly inside the function.

// JA4H for CloudFront Functions (runtime: cloudfront-js-2.0)
// Requires CloudFront-Viewer-Header-Order and
// CloudFront-Viewer-Http-Version in the origin request policy.
var crypto = require('crypto');
var ZERO12 = '000000000000';

function sha12(s) {
    return crypto.createHash('sha256').update(s).digest('hex').slice(0, 12);
}

function handler(event) {
    var req = event.request;
    var h = req.headers;

    var order = h['cloudfront-viewer-header-order']
        ? h['cloudfront-viewer-header-order'].value : '';
    var httpVer = h['cloudfront-viewer-http-version']
        ? h['cloudfront-viewer-http-version'].value : '1.1';

    // Exclude Cookie and Referer while preserving transmission order,
    // casing, and duplicate header names.
    var filtered = (order ? order.split(':') : []).filter(function (n) {
        var l = n.toLowerCase();
        return l !== 'cookie' && l !== 'referer';
    });

    // ---- JA4H_a ----
    var method = req.method.toLowerCase().slice(0, 2);   // GET -> ge
    var ver = httpVer.replace('.', '').slice(0, 2);      // 1.1 -> 11, 2.0 -> 20
    if (ver.length === 1) ver += '0';
    var cookieKeys = Object.keys(req.cookies);
    var hasCookie = cookieKeys.length > 0 ? 'c' : 'n';
    var hasReferer = h.referer ? 'r' : 'n';
    var count = Math.min(filtered.length, 99);
    var countStr = (count < 10 ? '0' : '') + count;
    var lang = '0000';
    if (h['accept-language']) {
        var l = h['accept-language'].value
            .split(',')[0].split(';')[0].toLowerCase().replace(/-/g, '');
        lang = (l + '0000').slice(0, 4);
    }
    var a = method + ver + hasCookie + hasReferer + countStr + lang;

    // ---- JA4H_b: hash header names in transmission order ----
    var b = filtered.length ? sha12(filtered.join(',')) : ZERO12;

    // ---- JA4H_c / JA4H_d: sort and hash Cookie names / name=value pairs ----
    var cnames = [], cpairs = [];
    cookieKeys.forEach(function (n) {
        var c = req.cookies[n];
        if (c.multiValue) {
            c.multiValue.forEach(function (m) {
                cnames.push(n); cpairs.push(n + '=' + m.value);
            });
        } else {
            cnames.push(n); cpairs.push(n + '=' + c.value);
        }
    });
    cnames.sort(); cpairs.sort();
    var c12 = cnames.length ? sha12(cnames.join(',')) : ZERO12;
    var d12 = cpairs.length ? sha12(cpairs.join(',')) : ZERO12;

    req.headers['x-ja4h'] = { value: a + '_' + b + '_' + c12 + '_' + d12 };
    return req;
}

Duplicate Cookies can be retrieved from the multiValue array. Because JA4H_c and JA4H_d hash sorted values, their original order is not needed.

Comparing the Output with the Reference Implementation

Some details of JA4H_a—such as exactly which headers are included in the count and how Accept-Language is normalized—are described only briefly in the FoxIO specification. That makes differences between implementations relatively easy to introduce.

Before deploying this in production, compare the output with FoxIO’s reference implementation. The repository includes a Rust CLI named ja4 that analyzes pcap files and emits the various JA4+ fingerprints. It uses tshark internally, and prebuilt binaries are available from the repository’s Releases page.

The important point is that JA4H requires plaintext HTTP headers. An HTTPS packet capture cannot be analyzed as-is because the headers are encrypted.

A convenient workaround is to send an equivalent request over plaintext HTTP to a local server and capture it there. curl sends the same header names when invoked with the same command-line options. The Host value will differ, but that does not affect JA4H_b because it hashes header names rather than values.

# Install tshark and obtain the ja4 binary (macOS example)
brew install --cask wireshark
sudo ln -s /Applications/Wireshark.app/Contents/MacOS/tshark /usr/local/bin/tshark

# Start a local plaintext HTTP server and capture traffic
python3 -m http.server 8000 &
sudo tcpdump -i lo0 -w /tmp/ja4h.pcap 'port 8000' &

# Send a request with the same method, HTTP version, headers, and Cookies
# as the request sent to CloudFront
curl --http1.1 http://localhost:8000/ \
  -H "Accept-Language: ja" -H "X-Test-ZZZ: 1" -b "session=abc"

# Extract JA4H and compare it with x-ja4h from CloudFront Functions
./ja4 /tmp/ja4h.pcap

When the results differ, it helps to add temporary debug output to the function that exposes JA4H_a and b_input, the string before hashing. That makes it much easier to identify which component is responsible for the mismatch.

To validate an HTTPS request without recreating it over plaintext HTTP, another option is to record session keys with SSLKEYLOGFILE, decrypt the capture in Wireshark, and inspect it with the JA4 plugin.

A quick licensing note: TLS-based JA4 is licensed under the BSD 3-Clause License, while JA4+ methods including JA4H use the FoxIO License 1.1. Internal use for protecting your own services is permitted, but offering the functionality as part of a commercial product requires an OEM license.

Reducing False Positives with a Challenge Page

Immediately blocking every request that matches a JA4 or JA4H fingerprint can be risky.

Security products, VPNs, and proxies may reorder headers. When that order differs from normal browser behavior, a legitimate user’s fingerprint may no longer match the fingerprint normally produced by their browser, leading to false positives or false negatives.

JA4H also intentionally groups clients using the same implementation. As a result, many legitimate users running the same browser version may share the same fingerprint. A mistake in blocklist management could therefore block every one of them at once.

Instead of returning a 403 immediately, I recommend redirecting suspicious JA4H fingerprints to a challenge page. A human user can complete the verification step, and requests carrying proof of successful completion can then pass through normally.

The action for each fingerprint can be stored in KVS, with the viewer-request function deciding how to handle it:

import cf from 'cloudfront';
const kvs = cf.kvs();

async function handler(event) {
    const request = event.request;
    const ja4h = computeJa4h(event); // JA4H calculation logic

    // Validate an expiring, HMAC-signed clearance Cookie.
    if (hasValidClearance(request, ja4h)) {
        request.headers['x-ja4h'] = { value: ja4h };
        return request;
    }

    let action = 'allow';
    try {
        action = await kvs.get(ja4h);
    } catch (e) { /* Unregistered = allow */ }

    if (action === 'challenge') {
        return {
            statusCode: 302,
            headers: {
                'location': { value: '/challenge?return=' + encodeURIComponent(request.uri) },
                'cache-control': { value: 'no-store' }
            }
        };
    }
    if (action === 'block') {
        return { statusCode: 403, statusDescription: 'Forbidden' };
    }

    request.headers['x-ja4h'] = { value: ja4h };
    return request;
}

The contents of /challenge depend on your requirements. The simplest option is a JavaScript challenge that merely confirms the client can execute JavaScript, because many basic bots cannot.

For stronger verification, validate Cloudflare Turnstile or reCAPTCHA at the origin and issue an HMAC-signed clearance Cookie after successful completion. Runtime 2.0’s crypto module also supports HMAC, so subsequent Cookie validation can remain entirely at the edge.

You might be wondering whether AWS WAF’s Challenge or CAPTCHA actions could handle this instead. On CloudFront, however, WAF evaluation runs before CloudFront Functions. That means a WAF rule cannot use an x-ja4h header added by the function during the same request.

When routing decisions must be based on JA4H, the function itself also needs to perform the challenge redirect. As an aside, AWS WAF has a HeaderOrder match component, so WAF alone can still perform checks based only on header order.

A practical rollout would look like this:

Observe JA4H values for all requests by recording x-ja4h in the origin access logs.
Identify fingerprints that appear disproportionately in attack traffic.
Register those fingerprints in KVS with the challenge action.
Promote only fingerprints that are clearly malicious to block.

Summary

CloudFront-Viewer-Header-Order lets you recover header order, casing, and duplicate names with high fidelity. The event object alone cannot do this because it lowercases header names and loses their transmission order.
Combined with CloudFront-Viewer-Http-Version, it allows a JA4H-equivalent fingerprint to be calculated inline inside CloudFront Functions.
Because legitimate users can share the same JA4H value, a staged response using KVS and a challenge page is safer than blocking immediately.

CloudFront may eventually expose JA4H as another generated viewer header. Until then, this is one way to implement comparable fingerprinting yourself.

Give it a try—and, as always with fingerprints, observe first and block carefully.

Implementing Impossible Location Detection with Amazon CloudFront Functions + KVS

nishikawaakira — Tue, 07 Jul 2026 21:20:28 +0000

This article is the CloudFront Functions + CloudFront KeyValueStore (KVS) version of the previous article, Implementing Impossible Location Detection Without Application Changes Using Amazon CloudFront + Lambda@Edge.

If you have not read the Lambda@Edge version yet, I recommend reading it first. It will make the differences in this article much easier to understand.

Why CloudFront Functions?

In the previous Lambda@Edge version, I implemented Impossible Location detection without modifying the application.

However, Lambda@Edge has several limitations.

Lambda@Edge limitation	CloudFront Functions version
`CloudFront-Viewer-Country` is not available in Viewer Request	Available in Viewer Request, with the right Origin Request Policy
`CachingDisabled` is required for protected paths	Cacheable responses can still be protected
Deployment to `us-east-1` is required	No Lambda@Edge regional deployment constraint
Lambda@Edge costs $0.60 per 1 million requests	CloudFront Functions cost $0.10 per 1 million requests

However, CloudFront Functions also require one important trade-off.

With this approach, the application needs to write location information to CloudFront KeyValueStore when login succeeds.

In other words, unlike the Lambda@Edge version, this version requires a small application-side change.

How It Works

In the Lambda@Edge version, an Origin Response Lambda automatically detected successful login responses and set a signed cookie.

In the CloudFront Functions version, the application writes the viewer’s country code and ASN to CloudFront KeyValueStore (KVS) when login succeeds.

After that, a CloudFront Function checks the KVS entry on each protected request.

At Login

When login succeeds, the application reads the CloudFront-Viewer-Country and CloudFront-Viewer-ASN headers and writes the session hash, country, and ASN to KVS.

This is the main difference from the Lambda@Edge version.

In the Lambda@Edge version, the edge layer automatically detects successful login responses.
In this version, the application explicitly writes the login-time location to KVS.

When Accessing Protected Pages

The biggest advantage is that verification is completed at Viewer Request.

CloudFront Functions can access CloudFront-Viewer-Country during the Viewer Request phase, so we do not need to wait until Origin Request.

This means CachingDisabled is no longer required for protected cache behaviors.

That is a major advantage.

Architecture Difference from the Lambda@Edge Version

The difference between the two versions can be summarized like this:

The Lambda@Edge version is useful when you cannot modify the application.

The CloudFront Functions + KVS version is useful when you can add a small amount of login-side logic and want better cost, latency, and cache compatibility.

Origin Request Policy Is Still Required

There is one important catch.

For CloudFront Functions to read CloudFront-Viewer-Country and CloudFront-Viewer-ASN at Viewer Request, the behavior must have an Origin Request Policy that includes these headers.

If the Origin Request Policy is not configured correctly, the headers will not be available to the CloudFront Function.

Depending on how you implement error handling, this may result in either:

fail open, where requests are allowed without validation
fail closed, where all users are blocked or redirected

Also, CloudFront-Viewer-ASN cannot be added through a Cache Policy. It must be handled through an Origin Request Policy.

In this sample, I use the managed policy:

AllViewerExceptHostHeader
b689b0a8-53d0-40ab-baf2-68738e2966ac

In CloudFront Functions runtime 2.0, these headers can be accessed like this:

function handler(event) {
  var h = event.request.headers;

  console.log(
    'country: ' +
      (h['cloudfront-viewer-country']
        ? h['cloudfront-viewer-country'].value
        : 'undefined')
  );

  console.log(
    'asn: ' +
      (h['cloudfront-viewer-asn']
        ? h['cloudfront-viewer-asn'].value
        : 'undefined')
  );

  return event.request;
}

After deployment, I recommend testing header delivery with a small validation function like this before enabling the full protection logic.

Default Protection Mode

This implementation uses a default protection model.

Instead of listing every protected path, we list only public paths.

module "ilg" {
  source       = "your-org/impossible-location-guard-cf/aws"
  public_paths = ["/login", "/assets/*"]
}

Everything else is protected by default.

This follows the same principle as “default deny” in firewall design.

New pages are automatically protected unless they are explicitly listed as public paths.

Important Implementation Notes

Handling SPA and API Requests

Returning 302 redirects for API calls can break SPA behavior.

If the frontend uses fetch or XHR, it may receive the login page HTML and then fail when trying to parse it as JSON.

Recommended approach:

Return 302 for browser page requests
Return 401 for API requests

For example, requests with Accept: application/json or paths under /api/* should usually receive 401 Unauthorized instead of a redirect.

Validate KVS Writes Carefully

Writing to KVS is the responsibility of the application.

Therefore, the application must write to KVS only after login succeeds.

If the application writes location data on failed login attempts, an attacker may be able to poison session data.

The rule is simple:

Only write to KVS after successful authentication.

Using ASN As Well

ASN validation can also be enabled.

module "ilg" {
  source    = "your-org/impossible-location-guard-cf/aws"
  check_asn = true
}

Country-level detection is useful, but it is not always enough.

For example, an attacker may access the application from the same country as the victim by using a cloud provider or proxy in that country.

By also checking ASN, you may be able to detect suspicious access even when the country code is the same.

However, ASN changes can also happen during legitimate usage, such as when a user switches between mobile data and Wi-Fi.

For that reason, check_asn is disabled by default and should be enabled based on your service’s risk tolerance.

Reauthentication Instead of Hard Blocking

As with the Lambda@Edge version, I recommend redirecting users to reauthentication instead of hard-blocking them.

If a legitimate user is completely blocked due to a false positive, they may feel that the service is broken or unreliable.

On the other hand, if they are simply asked to log in again, they may think their session expired.

When suspicious access is detected:

Redirect the user to /login
The user logs in again
The KVS entry is updated with the current country and ASN
Access resumes

One advantage of the KVS version is that the KVS entry can be deleted on logout.

This enables immediate session-level invalidation.

Sample Code

Terraform

In the Lambda@Edge version, protected paths required CachingDisabled.

In the CloudFront Functions version, the function runs at Viewer Request. This means the location check is still executed even when the response is served from cache.

This is one of the biggest advantages of the CloudFront Functions version.

module "ilg" {
  source  = "your-org/impossible-location-guard-cf/aws"
  version = "~> 1.0"

  project_name        = "myapp"
  session_cookie_name = "session_id"
  redirect_path       = "/login"
  public_paths        = ["/login", "/assets/*"]
  check_asn           = true
}

resource "aws_cloudfront_distribution" "main" {
  default_cache_behavior {
    target_origin_id       = "app"
    viewer_protocol_policy = "redirect-to-https"

    allowed_methods = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
    cached_methods  = ["GET", "HEAD"]

    cache_policy_id = "4135ea2d-6df8-44a3-9df3-4b5a84be39ad"

    origin_request_policy_id = "b689b0a8-53d0-40ab-baf2-68738e2966ac"

    function_association {
      event_type   = "viewer-request"
      function_arn = module.ilg.cloudfront_function_arn
    }
  }

  ordered_cache_behavior {
    path_pattern           = "/assets/*"
    target_origin_id       = "s3"
    viewer_protocol_policy = "redirect-to-https"

    allowed_methods = ["GET", "HEAD"]
    cached_methods  = ["GET", "HEAD"]

    cache_policy_id = "658327ea-f89d-4fab-a63d-7e88639e58f6"
  }
}

The application runtime role also needs permission to write to KVS.

resource "aws_iam_role_policy_attachment" "app_kvs_write" {
  role       = aws_iam_role.app.name
  policy_arn = module.ilg.kvs_write_policy_arn
}

Application-Side KVS Write

Here is an example using the AWS SDK for JavaScript v3.

import {
  CloudFrontKeyValueStoreClient,
  DescribeKeyValueStoreCommand,
  PutKeyCommand,
} from '@aws-sdk/client-cloudfront-keyvaluestore';

import { createHash } from 'crypto';

const client = new CloudFrontKeyValueStoreClient({
  region: 'us-east-1',
});

const KVS_ARN = process.env.ILG_KVS_ARN;

function sessionKey(sessionId) {
  return createHash('sha256').update(sessionId).digest('hex');
}

async function registerLocation(sessionId, req, retries = 3) {
  const country = req.headers['cloudfront-viewer-country'] || '';
  const asn = req.headers['cloudfront-viewer-asn'] || '';

  for (let i = 0; i < retries; i++) {
    const { ETag } = await client.send(
      new DescribeKeyValueStoreCommand({
        KvsARN: KVS_ARN,
      })
    );

    try {
      await client.send(
        new PutKeyCommand({
          KvsARN: KVS_ARN,
          Key: sessionKey(sessionId),
          Value: `${country}:${asn}`,
          IfMatch: ETag,
        })
      );

      return;
    } catch (e) {
      if (i === retries - 1) {
        throw e;
      }
    }
  }
}

The session ID should not be used directly as the KVS key.

If someone has permission to read KVS entries, using the raw session ID as the key would expose session IDs.

Hashing the session ID reduces that risk.

Login Flow Example

app.post('/login', async (req, res) => {
  const result = await authenticate(req.body);

  if (result.ok) {
    await registerLocation(result.sessionId, req);

    res.cookie('session_id', result.sessionId, {
      httpOnly: true,
      secure: true,
      sameSite: 'lax',
    });

    res.redirect('/dashboard');
  } else {
    res.status(401).render('login', {
      error: 'Authentication failed',
    });
  }
});

If you use an external identity provider, such as an OIDC provider, this approach can still work as long as the callback URL goes through CloudFront.

The request flow would be:

Browser -> CloudFront -> application callback endpoint

CloudFront adds CloudFront-Viewer-Country and CloudFront-Viewer-ASN, and the callback handler can call registerLocation.

Logout Handling

The KVS version can delete the session’s location entry when the user logs out.

import { DeleteKeyCommand } from '@aws-sdk/client-cloudfront-keyvaluestore';

async function onLogout(sessionId) {
  const { ETag } = await client.send(
    new DescribeKeyValueStoreCommand({
      KvsARN: KVS_ARN,
    })
  );

  await client.send(
    new DeleteKeyCommand({
      KvsARN: KVS_ARN,
      Key: sessionKey(sessionId),
      IfMatch: ETag,
    })
  );
}

This is one of the advantages of the KVS version.

It enables immediate invalidation at the session level.

BFF Architecture

This approach also works with a BFF, or Backend for Frontend, architecture.

If the BFF calls a downstream authentication API, make sure the CloudFront behavior for the BFF uses an Origin Request Policy such as AllViewerExceptHostHeader.

That way, CloudFront-Viewer-Country and CloudFront-Viewer-ASN are forwarded from CloudFront to the BFF.

The BFF then writes to KVS.

app.post('/api/auth/login', async (req, res) => {
  const result = await authApi.login(req.body);

  if (result.ok) {
    await registerLocation(result.sessionId, req);

    // ...
  }
});

One important point:

You should trust cloudfront-viewer-country and cloudfront-viewer-asn only when they are received directly from CloudFront.

KVS writes should be done by the process that directly receives these headers from CloudFront.

If you really need to relay those headers to another service, you should protect their integrity using mechanisms such as request signing, mTLS, private network controls, or strict origin access restrictions.

When the Authentication System Uses a Different Domain

Suppose your architecture uses separate subdomains, such as:

auth.example.com
api.example.com

In the Lambda@Edge version, you needed to share cookies across subdomains and associate Lambda@Edge functions with multiple distributions.

In the KVS version, the backend writes directly to KVS, so you do not need to associate Lambda functions across distributions in the same way.

However, the login request must go through CloudFront.

The country and ASN written to KVS come from CloudFront headers. If login does not pass through CloudFront, the application cannot obtain the same viewer location information used by the CloudFront Function.

Using your own GeoIP lookup instead may cause false positives because your GeoIP database may not match CloudFront’s GeoIP database.

A typical flow would be:

auth.example.com via CloudFront
-> login API
-> PutKey to KVS

api.example.com CloudFront Function
-> read the same KVS

The session cookie, such as session_id, must be shared with:

Domain=.example.com

Blocking Direct Access to the Origin

This mechanism assumes that the origin can only be accessed through CloudFront.

If attackers can directly access the origin, they can bypass the CloudFront Function entirely by sending requests directly to the origin with the stolen session cookie.

This is not just a header spoofing problem.

If CloudFront is bypassed, the validation logic does not run at all.

Examples of origin access protection include:

For ALB: allow only the CloudFront managed prefix list, com.amazonaws.global.cloudfront.origin-facing, in the security group
For S3: use Origin Access Control (OAC)
For custom origins: add a secret header from CloudFront to the origin and validate it at the origin or with AWS WAF

Origin protection is a prerequisite for this design.

KVS Limitations

CloudFront KVS is suitable for small to medium-sized services.

Before using it for session-level state, you need to understand its limitations.

Capacity

CloudFront KVS has a 5 MB limit for the entire store.

It is suitable for small values such as configuration, feature flags, or in this case, session hash to location mapping.

Depending on the exact key and value size, the practical upper limit is likely on the order of tens of thousands of active sessions.

No TTL

KVS entries do not have a TTL.

If a user’s session expires without logout, the KVS key remains unless you delete it.

Therefore, you need a cleanup mechanism.

Write Rate and ETag Conflicts

PutKey uses optimistic concurrency control with ETags.

The typical flow is:

DescribeKeyValueStore
-> get ETag
-> PutKey with IfMatch

If many users log in at the same time, ETag conflicts may occur.

Retries are required.

Eventual Consistency

CloudFront KVS is eventually consistent.

After PutKey, the value may not be immediately readable from every edge location.

In most cases, propagation is fast, but if your login flow immediately redirects users to a protected page, there is a small chance that legitimate users may be redirected back to login because the KVS entry has not propagated yet.

Possible mitigations include:

showing a short loading screen after login
retrying the protected request
showing a friendly message such as “Please try again”

Why Not DynamoDB?

You may wonder:

Wouldn’t DynamoDB be better for session-level state?

In many ways, yes.

Topic	CloudFront KVS	DynamoDB
Capacity	5 MB limit	Practically unlimited
TTL	No TTL	TTL attribute supported
Writes	ETag conflicts and retries	Simple `PutItem` overwrite
Read latency	A few milliseconds at the edge	Round trip to a region
Authentication	SigV4A, which can be tricky	Standard SigV4

So why use KVS?

The reason is latency and execution location.

KVS is available from CloudFront Functions at the edge. Reads can complete in a few milliseconds.

DynamoDB is regional. Reading from DynamoDB adds a network round trip from the edge to the AWS region.

More importantly, CloudFront Functions cannot call DynamoDB directly.

CloudFront Functions do not allow external network access.

So if you want to use DynamoDB, you would need to move the check to Lambda@Edge, usually at Origin Request.

That means:

CachingDisabled is required again
validation runs at Origin Request instead of Viewer Request
latency increases
Lambda@Edge pricing applies

At that point, the architecture becomes very similar to the Lambda@Edge version.

Architecture Comparison

Topic	Lambda@Edge + Cookie	CloudFront Functions + KVS	Lambda@Edge + DynamoDB
Application change	Not required	KVS write required	DynamoDB write required
Cost per 1M requests	$0.60	$0.10 + KVS $0.03	$0.60 + DynamoDB
Execution phase	Origin Request	Viewer Request	Origin Request
Cache compatibility	`CachingDisabled` required	Cacheable	`CachingDisabled` required
Scale	No practical session-store limit	5 MB / tens of thousands of sessions	Scalable
TTL / cleanup	Cookie expiration	Manual cleanup	DynamoDB TTL
Immediate invalidation	Difficult	`DeleteKey`	`DeleteItem`
Deployment constraint	Lambda@Edge in `us-east-1`	No Lambda@Edge regional constraint	Lambda@Edge in `us-east-1`

As of July 7, 2026.

Summary

CloudFront Functions can access CloudFront-Viewer-Country at Viewer Request, but the correct Origin Request Policy is required.

Using KVS removes the need for CachingDisabled, so cached content can still be protected.

A default protection model, where only public paths are listed, helps avoid accidental exposure of new pages.

ASN checking can help detect suspicious access even within the same country.

KVS is suitable for small to medium-sized services, but it has important limitations such as:

5 MB capacity
no TTL
write rate limits
ETag conflicts
eventual consistency

DynamoDB solves many of these scale and lifecycle problems, but CloudFront Functions cannot call DynamoDB directly. Using DynamoDB would bring the architecture back to Lambda@Edge.

BFF architectures can also use this approach, as long as the BFF writes to KVS using headers received directly from CloudFront.

Blocking direct access to the origin is a prerequisite. If attackers can bypass CloudFront, the entire validation logic can be bypassed.

Also, cloudfront-viewer-* headers should be trusted only by the process that receives them directly from CloudFront. They should not be blindly relayed to downstream services.

When I first thought of this idea, I expected it to be fairly simple.

But once I started considering the security details, there were many more things to think about than I expected.

Whether this is suitable for production depends on the service, traffic volume, authentication flow, and risk tolerance.

Still, I think it is worth considering as one possible way to detect session hijacking at the edge.

Implementing Impossible Location Detection Without Application Changes Using Amazon CloudFront + Lambda@Edge

nishikawaakira — Tue, 07 Jul 2026 21:19:58 +0000

When a session is compromised, where does the attacker access your application from?

For example, if a session cookie is stolen through XSS, an attacker may be able to impersonate the victim simply by setting that cookie in their own browser. In many cases, that access comes from a different country, network, or cloud provider than the legitimate user normally uses.

This is where the idea of Impossible Location comes in.

If a user logs in from Tokyo and then accesses the application from New York five minutes later, that movement is physically impossible. In that case, session hijacking should be considered highly suspicious.

However, I feel that this kind of detection is not always implemented in web applications, especially as a generic protection layer outside the application itself.

In this article, I will introduce an approach for detecting and responding to Impossible Location access using Amazon CloudFront and Lambda@Edge, without modifying the application.

This is only one possible design. I do not think this is the only correct answer, and there may be better architectures depending on your application and authentication flow. Please consider this article as one implementation idea.

Also, this implementation detects a change in country and optionally ASN from the time of login. It does not calculate physical travel speed. For example, even if a legitimate user travels abroad 12 hours after logging in, they may be asked to reauthenticate.

That said, this design redirects users to reauthentication instead of hard-blocking them, so the impact on legitimate users should be relatively small.

This mechanism is designed to help mitigate session hijacking.

It does not prevent password compromise itself. For leaked passwords, MFA is still one of the most effective countermeasures. I recommend using this kind of location-based session protection together with MFA.

This article covers the Lambda@Edge version.

If you can add a small amount of logic to the application during login, another approach using Amazon CloudFront Functions + CloudFront KeyValueStore (KVS) is also possible. That version has advantages in cost and latency, so I will cover it in a separate article.

How It Works

The basic idea is simple.

At login time, we store the viewer’s country information in a signed cookie.

After login, we compare the current viewer location with the location stored at login.

If the country, or optionally the ASN, changes unexpectedly, we redirect the user to the login page and ask them to reauthenticate.

At Login

When the login API returns a successful response, an Origin Response Lambda@Edge function intercepts the response.

The Lambda function reads the CloudFront-Viewer-Country header, signs the value with HMAC-SHA256, and sets it as a cookie.

Because this is done at the CloudFront layer, the application itself does not need to be modified.

When Accessing Protected Pages

For authenticated pages, an Origin Request Lambda@Edge function verifies the signed location cookie.

No external GeoIP database is required.

No external API call is required.

Amazon CloudFront automatically provides the viewer country through the CloudFront-Viewer-Country header. The Lambda@Edge function only needs to compare that value with the signed cookie.

The “Oh, That’s Why!” Moment

At first, I thought the security check should be implemented in a Viewer Request Lambda@Edge function.

That sounds like the ideal place to block suspicious requests, right?

Viewer Request is the earliest event in the CloudFront request lifecycle, so it feels like the best place to reject malicious requests before they go any further.

However, when I actually tested it, the CloudFront-Viewer-Country header was not available in the Viewer Request Lambda.

Even after adding it to the Cache Policy and Origin Request Policy, and even after creating a debug endpoint, the value was always null.

After some investigation, I found the reason in the AWS documentation:

CloudFront adds the CloudFront-Viewer-Country header after the viewer request event.

In other words, CloudFront determines the viewer country after the Viewer Request event.

So at the time the Viewer Request Lambda runs, the CloudFront-Viewer-Country header does not exist yet.

Adding the header to a Cache Policy or Origin Request Policy means that the header can be made available from the Origin Request phase onward. It does not make the header available to Viewer Request.

The same limitation applies even if you configure the policies correctly.

Also, CloudFront-Viewer-ASN cannot be added to a Cache Policy. It can only be included through an Origin Request Policy.

Because of this limitation, I changed the architecture so that the location check runs in an Origin Request Lambda@Edge function.

Why CachingDisabled Is Required

For protected paths, CachingDisabled is required.

This is an important point.

Origin Request Lambda@Edge is invoked only when CloudFront forwards the request to the origin. If CloudFront serves the response from cache, the Origin Request Lambda does not run.

That means if a protected page is cacheable and CloudFront returns a cache hit, the security check can be bypassed.

For authenticated pages, disabling cache is usually expected anyway, so this may not be a big issue in many applications.

However, if you want to protect cacheable content, you need to be careful.

This limitation is one of the reasons why the CloudFront Functions + KVS version can be attractive. CloudFront Functions run at Viewer Request, so they can run even when the response is served from cache.

Choosing the Origin Request Policy

To receive CloudFront-Viewer-Country and CloudFront-Viewer-ASN in an Origin Request Lambda, the CloudFront behavior must use an Origin Request Policy that forwards those headers.

One thing to be careful about is the Host header.

The managed policy AllViewerAndCloudFrontHeaders-2022-06 includes CloudFront headers, but it also forwards the viewer’s original Host header.

This can cause problems with origins such as API Gateway, Lambda Function URLs, or S3 with OAC.

For example, API Gateway and Lambda Function URLs expect the origin domain name in the Host header. If CloudFront forwards the viewer-facing host instead, the origin may return a 403 error.

For S3 with OAC, forwarding the wrong Host header may also cause a signature mismatch.

On the other hand, the managed policy AllViewerExceptHostHeader excludes the viewer’s Host header. This makes it safer to use with API Gateway, Lambda Function URLs, and S3 origins.

The AWS documentation says that this policy includes CloudFront viewer location headers such as CloudFront-Viewer-Country, although the documentation is a little inconsistent because the detailed list does not clearly show every CloudFront header.

In my testing, I confirmed that both CloudFront-Viewer-Country and CloudFront-Viewer-ASN were available in the Origin Request Lambda when using AllViewerExceptHostHeader.

I also confirmed that the Host header was replaced with the S3 origin domain name, so it did not break OAC signing.

{
  "country": [{"key": "CloudFront-Viewer-Country", "value": "JP"}],
  "asn":     [{"key": "CloudFront-Viewer-ASN",     "value": "17676"}],
  "host":    [{"key": "Host", "value": "xxx.s3.ap-northeast-1.amazonaws.com"}]
}

Because the documentation can be slightly confusing here, I recommend validating header delivery with a small debug Lambda before enabling this mechanism in production.

exports.handler = async (event) => {
  const headers = event.Records[0].cf.request.headers;

  console.log(
    'country:',
    JSON.stringify(headers['cloudfront-viewer-country'])
  );

  console.log(
    'asn:',
    JSON.stringify(headers['cloudfront-viewer-asn'])
  );

  return event.Records[0].cf.request;
};

Default Protection Mode

In this sample design, I use a default protection model.

Instead of listing every path that should be protected, we list only public paths.

For example:

module "impossible_location_guard" {
  source       = "your-org/impossible-location-guard/aws"
  login_paths  = ["/api/auth/login"]
  public_paths = ["/", "/login"]
}

Everything except the listed public paths is protected.

This is similar to the “default deny” approach in firewall design.

The reason is simple: it is easy to forget to add newly created pages to a protected path list. If that happens, the new page may accidentally become unprotected.

By listing only public paths, new pages are protected by default.

Important Implementation Notes

Include the Session ID in the HMAC Signature

The signed cookie should not contain only the country and ASN.

If the HMAC payload only includes country and ASN, a replacement attack may become possible.

For example, an attacker could:

Log in with their own account
Obtain a valid _ilg_loc cookie signed for the attacker’s country
Steal a victim’s session cookie
Combine the victim’s session cookie with the attacker’s valid location cookie

To prevent this, the signed payload should include a value derived from the session ID, such as a hash of the session ID.

For example:

{
  "country": "JP",
  "asn": "12345",
  "sid": "sha256(sessionId)",
  "iat": 1234567890,
  "exp": 1234654290
}

This binds the location cookie to the actual session.

To verify this value, the Origin Request Lambda needs to know the name of the session cookie. In the sample module, this is configured through session_cookie_name.

Set the Location Cookie Only on Successful Login

Origin Response Lambda@Edge runs for all origin responses, including error responses such as 400 or 401.

If the Lambda sets the location cookie without checking the response status code, even a failed login attempt could receive a valid location cookie.

That is not what we want.

In this sample implementation, the cookie is set only when the origin returns a successful status code, such as 200 or 201.

For example, the module has a success_statuses setting with a default value like:

["200", "201"]

Manage the HMAC Secret Carefully

Lambda@Edge does not support environment variables in the same way as normal Lambda functions.

In this sample, the HMAC secret is bundled into the Lambda package as config.json at Terraform build time.

const config = require('./config.json');

if (!config.HMAC_SECRET) {
  throw new Error('HMAC_SECRET is not configured');
}

Object.assign(process.env, config);

If the secret is missing, the function should fail closed.

Failing open would mean allowing requests without a valid security check, which is dangerous.

When sharing this mechanism across subdomains, Lambda functions generated from the same module can share the same HMAC secret.

Recommended Cookie Attributes

The location cookie should have secure attributes.

I recommend at least the following:

Secure
HttpOnly
SameSite=Lax

Secure ensures the cookie is sent only over HTTPS.

HttpOnly prevents JavaScript from reading or modifying the cookie, which helps reduce the impact of XSS-based tampering attempts.

SameSite=Lax helps mitigate CSRF in many common cases.

Handling SPA and API Requests

If your frontend is an SPA, it may call APIs using fetch or XHR.

In that case, returning a 302 redirect for an API request can be inconvenient. The frontend may receive HTML from the login page and then fail when trying to parse it as JSON.

A more practical approach is:

Return 302 for normal browser page requests
Return 401 for API requests

For example, if the request path starts with /api/ or the Accept header includes application/json, returning 401 Unauthorized may be better than redirecting to /login.

Why ASN Can Help

Country-based detection is useful, but it is not always enough.

For example, in a large country such as the United States, an attacker may access the application from the same country as the victim.

The same can happen in Japan.

A legitimate user may log in from a home ISP or an office network, while an attacker may use a cloud provider in the same country. In both cases, the country code may be JP.

If we only compare the country code, that attack may not be detected.

To improve detection, we can also compare the ASN.

CloudFront provides the CloudFront-Viewer-ASN header, so the Origin Request Lambda can use it in the same way as the country header.

module "impossible_location_guard" {
  source    = "your-org/impossible-location-guard/aws"
  check_asn = true
}

In my sample design, check_asn is disabled by default.

This is because ASN changes can happen during legitimate usage. For example, a user may switch between mobile data and Wi-Fi, which can result in a different ASN.

So ASN checking is a trade-off.

For some applications, country-level detection may be enough. For other applications, especially those with higher security requirements, ASN checking may be worth enabling.

Reauthentication Instead of Hard Blocking

My recommendation is to redirect users to reauthentication instead of hard-blocking them.

If a legitimate user is mistakenly blocked, they may feel that the service is broken or unreliable.

On the other hand, if they are asked to log in again, they may simply think that their session expired.

This is often a more acceptable user experience.

When a suspicious location change is detected, the behavior is:

Redirect the user to redirect_path, such as /login
The user logs in again
The location cookie is overwritten with the current country and ASN
Access is restored

This means that legitimate users who travel abroad or use a VPN only need to log in again.

An attacker who only has the stolen session cookie cannot continue unless they also have valid authentication credentials.

Sample Terraform Configuration

The application does not need to be modified.

You only need to add the module and associate the Lambda@Edge functions with the appropriate CloudFront cache behaviors.

# -----------------------------------------------
# impossible-location-guard module
# -----------------------------------------------
module "impossible_location_guard" {
  source  = "your-org/impossible-location-guard/aws"
  version = "~> 1.0"

  providers = {
    aws.us_east_1 = aws.us_east_1
  }

  project_name  = "myapp"
  login_paths   = ["/api/auth/login"]
  redirect_path = "/login"
  public_paths  = ["/", "/login"]
  check_asn     = true
  cookie_domain = ".example.com"

  create_cloudfront_distribution = false
}

Lambda@Edge must be deployed in us-east-1, so the module requires a provider for that region.

Here is an example of adding the functions to an existing CloudFront distribution.

resource "aws_cloudfront_distribution" "main" {
  # ... existing origin configuration ...

  default_cache_behavior {
    target_origin_id       = "s3"
    viewer_protocol_policy = "redirect-to-https"

    allowed_methods = ["GET", "HEAD"]
    cached_methods  = ["GET", "HEAD"]

    cache_policy_id = "4135ea2d-6df8-44a3-9df3-4b5a84be39ad" # CachingDisabled

    origin_request_policy_id = "b689b0a8-53d0-40ab-baf2-68738e2966ac" # AllViewerExceptHostHeader

    lambda_function_association {
      event_type   = "origin-request"
      lambda_arn   = module.impossible_location_guard.origin_request_lambda_arn
      include_body = false
    }
  }

  ordered_cache_behavior {
    path_pattern           = "/assets/*"
    target_origin_id       = "s3"
    viewer_protocol_policy = "redirect-to-https"

    allowed_methods = ["GET", "HEAD"]
    cached_methods  = ["GET", "HEAD"]

    cache_policy_id = "658327ea-f89d-4fab-a63d-7e88639e58f6" # CachingOptimized
  }

  ordered_cache_behavior {
    path_pattern           = "/api/auth/login"
    target_origin_id       = "api"
    viewer_protocol_policy = "redirect-to-https"

    allowed_methods = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
    cached_methods  = ["GET", "HEAD"]

    cache_policy_id = "4135ea2d-6df8-44a3-9df3-4b5a84be39ad" # CachingDisabled

    origin_request_policy_id = "b689b0a8-53d0-40ab-baf2-68738e2966ac" # AllViewerExceptHostHeader

    lambda_function_association {
      event_type   = "origin-response"
      lambda_arn   = module.impossible_location_guard.origin_response_lambda_arn
      include_body = false
    }
  }

  # Note:
  # If you have other API paths such as /api/users,
  # add a separate ordered_cache_behavior for /api/*.
  #
  # That behavior should use the API origin,
  # allow the required HTTP methods,
  # and use the origin-request Lambda for protection.

  # ... restrictions, viewer_certificate ...
}

When the Authentication System Uses a Different Domain

One case that requires additional consideration is when the authentication system and application use different domains.

For example:

auth.example.com
api.example.com

Because this mechanism stores location information in a cookie, the cookie must be shared between subdomains.

In that case, you can set:

cookie_domain = ".example.com"

If the CloudFront distributions are also separate, the Lambda@Edge functions must be associated with the appropriate distributions.

For example:

# Distribution for auth.example.com
# Set the cookie in the login response
lambda_function_association {
  event_type = "origin-response"
  lambda_arn = module.ilg.origin_response_lambda_arn
}

# Distribution for api.example.com
# Verify the location cookie on protected requests
lambda_function_association {
  event_type = "origin-request"
  lambda_arn = module.ilg.origin_request_lambda_arn
}

Because both Lambda functions are generated from the same module, they can share the same HMAC secret.

This allows the cookie set on the authentication side to be verified on the application side.

However, in real environments, the authentication system and the application may belong to different AWS accounts or different teams. In that case, coordination is required.

Also, each application that relies on this protection must be configured properly. Otherwise, some paths or applications may remain unprotected.

Summary

In this article, I introduced one possible way to implement Impossible Location detection using Amazon CloudFront and Lambda@Edge without modifying the application.

The key points are:

CloudFront can provide viewer location information through headers such as CloudFront-Viewer-Country
CloudFront-Viewer-Country is not available in Viewer Request Lambda@Edge
The location check must run in Origin Request Lambda@Edge
Protected paths must use CachingDisabled, otherwise cache hits can bypass the Origin Request Lambda
Signing the location cookie with HMAC is important
The signed payload should be bound to the session ID
ASN checking can help detect suspicious access from the same country
Reauthentication is usually more user-friendly than hard blocking

The term “Impossible Location” may be familiar, but concrete implementation examples are not always easy to find.

That is why I built this as one possible approach.

I hope this article helps someone design a better implementation or think more deeply about session hijacking detection at the edge.

In the next article, I will cover another version using Amazon CloudFront Functions + CloudFront KeyValueStore.

That approach requires a small application-side change during login, but it can run at Viewer Request, avoid CachingDisabled, and provide better cost and latency characteristics.

What did our VPC look like at 22:14 (Tue, 2026-05-20) — building clew, a CLI for navigating AWS Config snapshots

nishikawaakira — Thu, 21 May 2026 21:50:35 +0000

It's 2am. Production is on fire. Someone in the war room asks, "what did the VPC actually look like at 22:14, when this started?", and the only honest answer is, "give me twenty minutes with jq."

That moment, repeated enough times, is why I started writing the tool I want to talk about today: clew, a Go CLI that ingests AWS Config Configuration Snapshots into a local DuckDB and renders an interactive topology you can actually read.

▎ https://github.com/nishikawaakira/clew

This post is the story of why it exists and how to use it during an incident.

The problem: "the moment-in-time configuration" is a real artifact you can't easily see

A scenario you might recognize:

It's 22:14. Targets behind an ALB start going UnHealthy, but only some of them. CloudWatch shows the symptom but not the cause. People in the war room start floating theories:

"Maybe someone tightened a security group rule."
"Maybe a route table was modified and Private Subnet traffic is now going out the wrong gateway."
"Maybe a subnet's route table association silently changed."

All plausible. But each of them needs the same piece of evidence: what the topology actually looked like at 22:14, ideally next to what it looked like at 18:00 when things were still fine. The AWS Console only shows you "right now," which is precisely the moment you don't care about anymore.

The good news: AWS Config has been quietly dropping a full Configuration Snapshot of every tracked resource into S3 every six hours. The artifact exists. The bad news is that the artifact ships as:

A <account>_Config_<region>_ConfigSnapshot_<timestamp>_<snapshot-id>.json.gz file
Containing a flat configurationItems array, mixed across resource types
Where "this EC2 uses this security group" lives under configuration.networkInterfaces[].groups[].groupId
And "this VPC contains these subnets, which contain these instances" is purely implicit — you reconstruct it in your head from the relationships[] field

jq at 2am is a poor incident-response interface. And drawing the VPC topology on paper while pagers are going off is worse.

Existing tooling, and where it fell short for me

I'm not pretending nothing else exists. The usual suspects:

AWS Config Aggregator + Advanced Queries (SQL-ish querying from the console)
CloudFormation StackSets with drift detection
Commercial CMDB / IaC visualizers (Lucidchart's AWS importer, Hava, etc.)
Rolling your own jq library and committing it to the team's snippet repo

What I couldn't find was something that hit all of:

Works against an arbitrary historical snapshot (any S3 object, not just "now")
Local-first, no SaaS round trip — incident artifacts shouldn't leave the responder's laptop
Produces a single self-contained HTML file I can paste into a Slack thread or a postmortem doc
Lets me stack multiple snapshots in the same store and compare across time

So I started writing what I wished existed.

What clew does

Three commands, one data model:

The DuckDB file holds three tables:

`config_items`

Stores one row per imported configurationItem, including the original configuration, relationships, tags, and capture_time.

`graph_nodes`

Stores one row per resource, including placeholder rows for resources referenced by relationships but not yet imported.

`graph_edges`

Stores resource-to-resource edges extracted from both relationships[] and the configuration body.

The default render --format html output is the part most worth showing off. It produces an interactive topology with compound nodes — VPCs are drawn as outer boxes containing subnet boxes containing EC2 / ENI nodes — the same nesting you'd draw on a whiteboard during incident response, except generated from the snapshot you just imported.

The generated HTML is interactive: you can pan and zoom, click nodes to inspect their type, resource ID, ARN, and placeholder status, toggle edge labels, switch layout direction, and choose between orthogonal and bezier edges.

The file is fully self-contained — copy it anywhere, open it in any browser.

Walkthrough: using clew in incident-response mode

Step 0: Install

# Requires Go 1.24+ and a C compiler — go-duckdb is CGO-bound.
go install github.com/nishikawaakira/clew@v0.1.0

This assumes AWS Config is already enabled and delivering configuration snapshots to S3.

Step 1: Pull the snapshot(s) closest to the incident from S3

AWS Config writes keys with unpadded month/day (.../2026/5/20/...), so dancing around BSD-vs-GNU date is a waste of energy. Listing recursively and filtering by name is the safer path:

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
REGION=<incident-region>
BUCKET=<your-config-bucket>

aws s3 ls "s3://${BUCKET}/AWSLogs/${ACCOUNT_ID}/Config/${REGION}/" --recursive | grep ConfigSnapshot | sort

# Grab the two snapshots straddling the incident window and `aws s3 cp` them down.

If you need one right now and don't want to wait for the next scheduled delivery:

aws configservice deliver-config-snapshot --delivery-channel-name default

In my experience, the S3 object usually shows up within 10–60 seconds.

Step 2: Import everything into a single DuckDB

clew import --input snapshot-2026-05-20T22-00.json.gz --db incident.duckdb
clew import --input snapshot-2026-05-20T18-00.json.gz --db incident.duckdb

You can keep stacking snapshots into the same incident.duckdb. config_items.item_id is a PRIMARY KEY of account:region:type:resource_id:captureTime, combined with ON CONFLICT (item_id) DO NOTHING on insert.

The practical guarantees:

Re-importing the same snapshot is a true no-op (the inserts collide on item_id).
Re-importing a snapshot taken at a different capture time keeps both rows for the same resource — history is preserved, not overwritten.

graph_nodes / graph_edges always reflect the latest state, so the rendered topology is always "the most recent snapshot you imported," but the historical detail still lives in config_items.

Step 3: Render the topology

clew render --db incident.duckdb --view vpc --format html --output vpc.html
open vpc.html

If you want it for a Slack thread:

clew render --db incident.duckdb --view vpc --format png --output vpc.png

The raster output is fine for a quick share, but it doesn't scale well to large topologies — once you have more than a couple of dozen resources, the nodes get cramped and labels become hard to read. For anything larger, the interactive HTML is the better artifact to share with the team, because reviewers can open it locally and pan/zoom.

If you want to embed it in a postmortem Markdown:

clew render --db incident.duckdb --view vpc --format mermaid --output vpc.md

Step 4: Zoom in on a suspect

When you have a specific theory — "the ALB stopped reaching this instance" — the global view is too much. query runs a bidirectional BFS (breadth-first search) from one resource:

# Two hops out from a specific instance, as interactive HTML.
clew query --db incident.duckdb --resource-id i-0abc... --depth 2 \
 --format html --output i-0abc.html

# Or a text summary in the terminal when you just want to confirm a hunch.
clew query --db incident.duckdb --resource-id sg-12345 --depth 1 --format text

The text format is intentionally boring and grep-friendly:

Nodes:
  - AWS::EC2::Instance/i-0abc...
  - AWS::EC2::SecurityGroup/sg-12345
  - AWS::EC2::Subnet/subnet-pub
  ...
Edges:
  - <node-id> ==[Uses security group]==> <node-id>
  ...

Step 5: Diff across time, with plain SQL

Because every snapshot lands as its own row in config_items, you can ask DuckDB directly:

duckdb incident.duckdb

SELECT capture_time, configuration_json
FROM config_items
WHERE resource_id = 'sg-12345'
ORDER BY capture_time;

Comparing the 22:00 vs. 22:14 configuration_json of a single security group is now a diff between two rows. The whole point of putting the data in a real database was to make the ad-hoc questions stop requiring custom code.

What clew doesn't do yet

Being honest about scope:

Only the vpc view is implemented. The internal model is type-agnostic, so adding iam, org, kms, or network (peering/TGW) views is a matter of writing the type list and the configuration-edge extractors, not a redesign.
The HTML output pulls Cytoscape.js / dagre / cytoscape-dagre from a CDN at view time. Useful in 95% of cases, useless on a fully air-gapped laptop. An --embed-js mode using go:embed is the obvious follow-up.
No special tuning for very large snapshots. Inserts are straightforward prepared statements. For tens of thousands of resources you'd want the DuckDB Appender API or parallel ingest.
Cross-account / cross-region edges only exist if AWS Config explicitly listed them. Reconstructing organization-wide topology needs more wiring (likely an Organizations + Config Aggregator integration).

Why "clew"?

clew is the Old English word for "ball of thread" — and the literal etymological root of the modern word clue. In Greek mythology it's the thread Ariadne gave Theseus so he could find his way back out of the Labyrinth.

Production AWS environments tend to drift toward labyrinth shape, especially after years of "just one more security group / one more subnet / one more peering connection." Most of the time it's fine. Then 2am happens, and the same environment that felt familiar yesterday looks like a maze.

clew is named for the thread you wish you had on the way in.

Try it

go install github.com/nishikawaakira/clew@v0.1.0
clew --help

Repository: https://github.com/nishikawaakira/clew (MIT)

If you want to see the output without setting up real AWS Config, the repo ships a testdata/sample_snapshot.json that exercises every piece of the rendering pipeline:

clew import --input testdata/sample_snapshot.json --db /tmp/demo.duckdb
clew render --db /tmp/demo.duckdb --view vpc --format html --output /tmp/demo.html
open /tmp/demo.html

This is still a PoC — there are sharp edges and obvious gaps. Issues, PRs and "here's the view I actually need" feature requests are all welcome.

Thanks for reading. If this means one fewer engineer is writing jq queries at 2am next month, the project has paid for itself.

Automating Phishing Site Reporting and Takedowns with AWS Lambda + Amazon Bedrock

nishikawaakira — Fri, 03 Apr 2026 00:51:06 +0000

Introduction

"Your account has been suspended." "Please update your payment information." — Phishing SMS and emails like these have become a daily occurrence in Japan.

As a security engineer, I used to manually report every phishing site I came across, but the workload per report was simply too much to keep up with:

Look up the domain's IP address
Identify the hosting provider via WHOIS
Find the abuse contact email address
Write a report email in English
Take a screenshot and attach it
Send it, then check whether the site was taken down

15 to 30 minutes per report. Doing this for multiple sites every day just isn't realistic.

So I built a system on AWS that automates all of the above with a single URL submission. In this article, I'll share the architecture and the lessons learned during development.

System Overview

curl -X POST https://xxx.execute-api.us-east-1.amazonaws.com/prod/report-auto \
  -d '{"url": "https://phishing-site.example.com"}'

This single curl command triggers the following automated workflow:

Capturing a screenshot of the site
Using Bedrock (Claude) to analyze the page and infer the impersonated brand
Looking up technical information such as hosting provider and abuse contact
Drafting and sending a report email with supporting evidence
Submitting reports to services such as Google Safe Browsing
Monitoring DNS changes afterward to help confirm whether the site has been taken down

To reduce false reports, the system stores reporting history, keeps a registry of known legitimate sites, and relies on multiple pieces of evidence before proceeding.

Architecture Diagram

AWS Services Used

Service	Purpose
API Gateway (HTTP API)	REST endpoints (4 routes)
Lambda (Zip x3)	Report processing, reply handling, takedown monitoring
Lambda (Container x1)	Playwright screenshots + form auto-submission
DynamoDB	Abuse contact cache, report history, legitimate site registry
S3	Screenshot storage
ECR	Container image for Screenshot Lambda
Bedrock (Claude)	Email generation, screenshot analysis, brand detection
EventBridge	Daily takedown monitoring schedule
Route 53	Email domain DNS (SPF/DKIM/DMARC)

All infrastructure is managed with Terraform — a single terraform apply deploys everything.

Interesting Technical Challenges

1. Collecting Usable Screenshots from Phishing Sites

Screenshots are important evidence in abuse reports. In practice, however, phishing sites often make automated access difficult, and a straightforward screenshot attempt may fail.

To improve reliability, the system uses multiple approaches to collect screenshots, including third-party services such as urlscan.io when appropriate.

In addition to helping with screenshot collection, third-party scan results can also serve as supporting evidence when reporting a site.

2. Three Uses of Bedrock (Claude)

This system leverages Claude in three different contexts:

a) Screenshot Quality Assessment

Determines whether the captured screenshot shows actual phishing content, rather than a bot detection page, 404 error, or blank page.

b) Automatic Brand Detection (/report-auto)

The URL-only endpoint uses screenshots and HTML to determine which brand the phishing site is impersonating.

c) Report Email Generation

Based on technical information such as redirect chains, page HTML, and screenshots, Claude automatically generates professional emails for hosting provider abuse teams. It captures technical details that templates can't convey.

3. A Multi-Layered Reporting Strategy

Reporting a phishing site to only one destination is often not enough.

That is why the system can notify multiple relevant parties for a single phishing site:

Hosting provider abuse contacts
Domain registrar abuse contacts
Google Safe Browsing

These channels serve different purposes.

For example, hosting providers may take action against the server itself, while registrars may suspend the domain. Browser warning services can also help protect users by displaying alerts even if the site remains online for some time.

This layered approach improves the chance of reducing harm, even when one reporting path does not immediately lead to action.

Cost

Because the system is built on serverless services, the monthly cost has been relatively low in my current usage:

Lambda: Pay-per-use
DynamoDB: On-demand capacity
S3: Screenshot storage
Bedrock (Claude): the main variable cost
Resend: Email sending
urlscan.io: public scans within the free tier

In my current setup and usage volume, the total cost has been roughly $5–10 per month, though this can vary depending on report volume and model usage.

Future Plans

A reporting analytics dashboard to visualize response times by hosting provider and impersonated brand trends
Expanding support for additional browser warning services such as Microsoft SmartScreen

Conclusion

Reporting phishing sites is repetitive and time-consuming work, especially when handled one case at a time.

By combining AWS serverless services with Bedrock (Claude), I built a system that streamlines much of that process — from screenshot collection to reporting and follow-up monitoring — from a single URL submission.

There is still plenty of room to improve how we respond to phishing at scale, but even small automation can make this work more sustainable. I hope this article provides a useful reference for others working on similar problems.

AWS Security Hub notifications made actionable using Amazon Bedrock

nishikawaakira — Sat, 28 Dec 2024 05:23:43 +0000

There were many Generative AI sessions at AWS re:Invent. Although I didn’t attend most of them, participating in a Generative AI GameDay made me realize that Generative AI isn’t as difficult as I thought. This inspired me to work on making Security Hub notifications more actionable, so that any engineer can handle them. This is the background behind writing this blog.

Who Should Read This?

Engineers who don’t have dedicated security engineers and feel unsure about what to do with Security Hub notifications.
Security engineers who send out Security Hub notifications but struggle to get others to take action.

Architecture

The architecture is very simple:
Security Hub detection -> EventBridge -> Lambda (invoking Amazon Bedrock).
While the setup is straightforward, there are some potential pitfalls, and I’d like to share those considerations with you.

Step-by-Step Guide (Amazon Bedrock)

First and foremost, you need to prepare to use Bedrock. Let’s start by submitting a request.

You can apply for access by navigating to the Bedrock page and going to the Model access section.

I used Claude 3.5 Sonnet. In my environment, access was already granted, but if you need to request access, click on "Available to request."

After clicking, a popup will appear. Select "Request model access" and proceed. You’ll then see a screen where you can select the models you want to use. Choose the desired model and click Next.

If this is your first request, you’ll need to provide information such as your company name and the intended use case during the application process. Fill in the required details and submit your request. In my case, access was granted in about 10 minutes. With that, the Bedrock setup is complete.

Even while waiting for approval, you can proceed with the following setup steps, so let’s keep going.

Note: In this blog, I will also introduce the Lambda code, assuming the use of Claude 3.5 Sonnet. Please be aware that the interface might vary slightly depending on the model. If you’re using a different model, you may need to make adjustments accordingly.

Step-by-Step Guide (AWS Lambda)

Let’s start by writing the code. The example is in Python. Make sure to adjust settings such as the region and the Slack Webhook URL as needed.

import json
import boto3
import requests

bedrock_client = boto3.client(service_name='bedrock-runtime', region_name="ap-northeast-1")

SLACK_WEBHOOK_URL = ""

def lambda_handler(event, context):
    try:

        # Retrieve Security Hub findings
        findings = event.get('detail', {}).get('findings', [])
        if not findings:
            print("No findings received.")
            return

        # Summarize Findings (Bedrock API call)
        summary = summarize_findings_with_bedrock(findings)

        send_to_slack(summary)

        return {
            'statusCode': 200,
            'body': json.dumps('Notification sent successfully!')
        }

    except Exception as e:
        print(f"Error processing findings: {str(e)}")
        return {
            'statusCode': 500,
            'body': json.dumps(f"Error: {str(e)}")
        }

def summarize_findings_with_bedrock(findings):
    # Findings are summarized and converted to text
    findings_text = "\n".join([
        f"Id: {finding.get('Id')}\nDescription: {finding.get('Description')}"
        for finding in findings
    ])

    prompt = f"""
    {findings_text}

    Please provide clear instructions and example terraform code on why and how to respond so that everyone can respond when they receive the above Security Hub findings notification.
    """ 

    body = json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 2048,
        "messages": [{"role": "user", "content": prompt}],
        "temperature": 0.7
    })

    response = bedrock_client.invoke_model(
        body=body,
        modelId='anthropic.claude-3-5-sonnet-20240620-v1:0',
        contentType="application/json",
        accept="application/json"
    )

    response_body = json.loads(response['body'].read())
    return findings_text + response_body['content'][0]['text']    

def send_to_slack(message):
    slack_message = {
        "text": f"Security Hub Findings Summary:\n{message}"
    }

    response = requests.post(
        SLACK_WEBHOOK_URL,
        headers={"Content-Type": "application/json"},
        data=json.dumps(slack_message)
    )

    if response.status_code != 200:
        raise ValueError(f"Failed to send message to Slack: {response.status_code}, {response.text}")

Here, we provide Terraform code as a sample. However, feel free to modify it to suit your organization's needs. If it hasn't been integrated into your IaC process, remove any unnecessary prompts accordingly.

The anthropic_version is included in the body of the request, but this is only required when using Anthropic models. It might not be necessary for some Anthropic models, though this hasn’t been thoroughly investigated. Additionally, the structure of messages and the content passed as a prompt can vary depending on the model, which can be a potential stumbling block. If you encounter issues when using a different model, it’s a good idea to check these aspects.

Settings and adding the layer

I set the timeout to around 1 minute. If it's set to something like 10 seconds, there’s a chance the response won’t return. At the very least, the default 3 seconds for Lambda is definitely not sufficient, so it needs to be increased.

Add an inline policy to allow Lambda to invoke Bedrock. Click on the role name displayed below to configure the role.

From the Add permissions section, click Create inline policy.

Select JSON and enter the content below. For Bedrock actions, only InvokeModel is needed.

For reference, I’ll also provide the text version.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "bedrock:InvokeModel",
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

Next, add a Layer to the Lambda function.

Since we’re using requests and boto3, we’ll create it quickly. Follow the steps below to create a ZIP file containing the required Python libraries. Note that the latest version of boto3 is required, so make sure to follow this procedure.

mkdir libraries
pip3 install requests -t libraries/
pip3 install boto3 -t libraries/
pip3 install botocore -t libraries/
zip -r layer.zip libraries/

Once the above steps are complete, go to Layers and click Create layer.

Enter an appropriate name and simply upload the ZIP file you created earlier.

After the layer is created, go to its details page and copy the ARN.

Return to the Lambda function you created earlier and click Add a layer.

Select Specify an ARN, paste the ARN you copied earlier, and click the Add button to complete the process.

Setup Guide (Amazon EventBridge)

Finally, navigate to the EventBridge page, go to Buses, click on Rules, and create a rule by selecting Create rule.

Enter an appropriate name for the rule and select any desired Event bus. Then, choose Rule with an event pattern and click Next.

Keep most of the default settings, focusing only on selecting the Event pattern. For AWS service, select Security Hub, and for Event type, choose Security Hub Findings - Imported.

Next, configure the notification targets. To avoid excessive notifications, limit the findings to HIGH and CRITICAL severity levels. Additionally, to target only newly created findings, select NEW for the workflow status.

Proceed to the next page and specify the Lambda function you created earlier.

If no additional tags or settings are needed, go ahead and click Create rule. That’s it — the setup is complete!

Let Security Hub detect it

The easiest way to test is by creating an open Security Group. It's extremely useful for validation!

Enter a suitable name and description, select a VPC, and add the following settings to the Inbound rules. Click the Create security group button, and then just wait for it to be detected.

One final note: if the detection frequency in your AWS Config settings is set to Daily, detection may not happen immediately. In that case, you’ll just need to wait. There likely isn’t any workaround other than temporarily changing the frequency. If the setting is configured for continuous detection, it was detected within around 5 minutes in my experience.

The actual content of the notification

Security Hub Findings Summary:

Id: arn:aws:securityhub:ap-northeast-1:637423304033:security-control/EC2.18/finding/9e0e7000-0e27-435f-9f59-e5cc716e561b

Description: This control checks whether an Amazon EC2 security group permits unrestricted incoming traffic from unauthorized ports. The control status is determined as follows: If you use the default value for 'authorizedTcpPorts', the control fails if the security group permits unrestricted incoming traffic from any port other than ports 80 and 443; If you provide custom values for 'authorizedTcpPorts' or 'authorizedUdpPorts', the control fails if the security group permits unrestricted incoming traffic from any unlisted port; If no parameter is used, the control fails for any security group that has an unrestricted inbound traffic rule.Certainly! I'll provide an explanation of the finding and how to address it using Terraform code.

Explanation:
This Security Hub finding (EC2.18) is alerting you about potentially insecure configurations in your EC2 security groups. The control checks for unrestricted incoming traffic on unauthorized ports, which could expose your instances to unnecessary risks.

Why it's important:
Limiting inbound traffic to only necessary ports reduces the attack surface of your EC2 instances, enhancing overall security.

How to respond:

Review your security group rules.
Identify which ports are necessary for your application.
Update your security group rules to allow traffic only on required ports.
Use CIDR blocks to restrict incoming traffic to known IP ranges when possible. Here's an example Terraform code to address this issue:

hcl
resource "aws_security_group" "example" {
  name        = "example-sg"
  description = "Example security group with restricted inbound rules"
  vpc_id      = aws_vpc.main.id

  # Allow incoming HTTPS traffic
  ingress {
    description = "HTTPS from anywhere"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow incoming HTTP traffic
  ingress {
    description = "HTTP from anywhere"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow SSH access from a specific IP range
  ingress {
    description = "SSH from corporate network"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]  # Replace with your corporate network CIDR
  }

  # Allow outbound traffic to anywhere
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "example-sg"
  }
}

This example:

Allows inbound HTTPS (443) and HTTP (80) traffic from anywhere.
Restricts SSH (22) access to a specific IP range (replace with your actual range).
Allows all outbound traffic. To use this:
Replace aws_vpc.main.id with your actual VPC ID or reference.
Adjust the ingress rules based on your specific needs.
Update the CIDR blocks to match your required IP ranges.

Remember:

Always use the principle of least privilege.
Regularly review and update your security group rules.
Consider using Security Group references instead of CIDR blocks for internal resources. By implementing these changes, you should resolve the Security Hub finding and improve your EC2 instance security.

Conclusion

What did you think? By reviewing the notifications this way, it’s now much clearer why detections occur and what actions need to be taken. From the next time on, it seems likely that more attention will be paid to the configurations. While the notification content of Security Hub findings can be quite hard to understand as is, passing them through Generative AI makes them significantly easier to interpret.

Additionally, if your infrastructure is managed as code, you could even pass the source code itself to Generative AI and ask directly what needs to be changed. That could be a great approach as well.

The possibilities for improvements seem endless, don’t they? Thank you for reading to the end!

Unlocking the Potential of Amazon CloudFront with VPC Origins: Overcoming WAF Bypass Challenges

nishikawaakira — Sat, 28 Dec 2024 03:44:32 +0000

Amazon CloudFront VPC Origins was announced on November 20, 2024. Have you had a chance to try it yet? Today, I’d like to explore why this feature is exciting from a security perspective and discuss the challenges it addresses when this feature is not in use.

Why is Amazon CloudFront with VPC Origins exciting?

One of the significant advantages of this feature is the elimination of direct access to ALB or EC2 instances. These resources can now reside in private subnets, making them inaccessible directly from external sources. Access is strictly limited to routes through CloudFront within the same AWS account. Moreover, when WAF is configured on CloudFront, it ensures that origin access cannot bypass the WAF, adding an extra layer of security.

The structure is as shown in the following diagram.

How does it differ from previous setups?

In the architecture shown above, direct access to the ALB was possible if no additional configurations were applied. Similarly, if EC2 instances were deployed in public subnets, they could also be accessed directly. This meant that even with WAF configured on CloudFront, it couldn’t function effectively in this scenario.

To mitigate these risks and block direct access to origins, it was necessary to implement additional measures. These included configuring CloudFront's managed prefix list on the ALB or adding custom headers in CloudFront and validating them at the ALB, as demonstrated below:

*Example: Configuring the managed prefix list.

*Setting and verifying custom headers

While effective, these configurations could be surprisingly tedious. Ideally, CloudFront should have been the sole entry point from the start. The new VPC Origins feature eliminates the need to worry about inadvertent external access caused by misconfigurations.

Limitations of ALB-Based Validation

As mentioned earlier, preventing origin access previously relied on measures like CloudFront's managed prefix list or custom header validation on the ALB. However, these methods could still be bypassed.

Relying solely on CloudFront's managed prefix list is particularly insufficient. If an attacker knows the domain of the ALB, they can reference it from a different AWS account using their own CloudFront distribution. In other words, cross-account access is still possible.

In such cases, requests can still reach the ALB from CloudFront's IP addresses. The problem here is that while the legitimate CloudFront may have WAF configured, the attacker’s CloudFront would not. As a result, even the most robust WAF rules can be bypassed entirely.

For this reason, it’s generally recommended to validate custom headers alongside using the managed prefix list. However, this issue is completely resolved with CloudFront VPC Origins—a game-changing improvement.

How can the ALB domain be exposed?

There are scenarios where the ALB domain becomes discoverable. For instance, when enabling HTTPS access from CloudFront to the ALB, it’s common to assign a subdomain to the ALB. If the domain assigned to CloudFront is example.com, the ALB might use a subdomain like alb.example.com.

In such cases, bypassing the legitimate CloudFront becomes relatively straightforward. Additionally, this information could potentially leak through former employees. Rotating credentials or domains to mitigate such risks can be both time-consuming and cumbersome. This is why VPC Origins, which can guard against such threats, is an incredibly valuable feature.

Conclusion

What do you think? Have you been relying solely on a managed prefix list? As this post highlights, there are potential pitfalls to that approach. Let’s take advantage of CloudFront VPC Origins to build a more secure and robust environment!

How to Transition AWS WAF from COUNT Mode to BLOCK Mode

nishikawaakira — Wed, 02 Oct 2024 19:37:26 +0000

In this article, I will share my experience after a colleague asked me, “I've been running WAF in COUNT mode for a while, but how do I determine which rules should be switched to BLOCK mode?”

Although I initially thought it would be straightforward, I couldn't easily explain it, so I created a procedure. This article outlines how to search logs in Amazon CloudWatch Logs, analyze them, and determine when to switch to BLOCK mode. Even if you're using a different WAF, the same logic should apply when transitioning to BLOCK mode.

Since this article assumes prior knowledge, I won’t explain basic concepts like “What is WAF?” or the specifications of AWS WAF’s managed rules.

COUNT Mode vs BLOCK Mode

WAF typically has two modes: COUNT and BLOCK. Although there is also an ALLOW mode, it’s less commonly used as a default setting.

When first providing a service, you use COUNT mode because starting with BLOCK mode might accidentally block legitimate requests. After running in COUNT mode, you assess the logs to decide whether to switch to BLOCK mode.

This article aims to share the know-how of analyzing logs. The general idea is that the rule can be switched to BLOCK if legitimate requests aren't recorded under COUNT mode.

The truth is, the decision of whether or not to block also depends on the service we are providing.
For example, it fluctuates depending on the following factors.

Does the service require authentication?
Is it offered internationally?
Does it provide APIs that third parties can call?
Is it B2C or B2B?
This article focuses on general SaaS services and how to proceed.

This article summarizes the content of what you should look for in general SaaS.

Also, you need to pay attention to the logs output by AWS WAF, so let's examine those first.

Viewing AWS WAF Logs

Here, we will look at the logs using CloudWatch Logs Insights.
However, you will only use CloudWatch Logs Insights the first time to download the COUNT logs.
Because the AWS WAF logs are complex and the detection details are written in arrays, it is extremely difficult for me to analyze them using a query as they are, and depending on the number of logs, trial and error can end up costing a lot of money. Furthermore, when you want to search for User-Agent and user-agent at the same time, you can't even write a regular expression, so I chose jq. However, of course, there are cases where it is not possible to download the logs for governance reasons. In that case, I personally think it is better to output the logs to Amazon S3 and use Amazon Athena.

First of all, we need to understand the structure of the log, so let's take a look. It looks like this.

{

    "timestamp":1533689070589,                            
    "formatVersion":1,                                   
    "webaclId":"385cb038-3a6f-4f2f-ac64-09ab912af590",  
    "terminatingRuleId":"Default_Action",                
    "terminatingRuleType":"REGULAR",                     
    "action":"ALLOW",                                    
    "httpSourceName":"CF",                               
    "httpSourceId":"i-123",                             
    "ruleGroupList":[                                    
     {  
        "ruleGroupId":"41f4eb08-4e1b-2985-92b5-e8abf434fad3",
        "terminatingRule":null,    
        "nonTerminatingMatchingRules":[                  
            {"action" : "COUNT", "ruleId" : "4659b169-2083-4a91-bbd4-08851a9aaf74"}       
        ],
        "excludedRules":[
            {"exclusionType" : "EXCLUDED_AS_COUNT", "ruleId" : "5432a230-0113-5b83-bbb2-89375c5bfa98"}
        ]                          
     }
    ],
    "rateBasedRuleList":[                                 
     {  
        "rateBasedRuleId":"7c968ef6-32ec-4fee-96cc-51198e412e7f",   
        "limitKey":"IP",
        "maxRateAllowed":100                                                                                           
     },
     {  
        "rateBasedRuleId":"462b169-2083-4a93-bbd4-08851a9aaf30",
        "limitKey":"IP",
        "maxRateAllowed":100
     }
    ],      
    "nonTerminatingMatchingRules":[                                
        {"action" : "COUNT",  "ruleId" : "4659b181-2011-4a91-bbd4-08851a9aaf52"}    
    ],                                  
    "httpRequest":{                                                             
        "clientIp":"192.10.23.23",                                           
        "country":"US",                                                         
        "headers":[                                                                 
            {  
                "name":"Host",
                "value":"127.0.0.1:1989"
             },
             {  
                "name":"User-Agent",
                "value":"curl/7.51.2"
             },
             {  
                 "name":"Accept",
                 "value":"*/*"
             }
        ],
        "uri":"REDACTED",                                                
        "args":"usernam=abc",                                         
        "httpVersion":"HTTP/1.1",
        "httpMethod":"GET",
        "requestId":"cloud front Request id"                    
    }
}

Reference: https://docs.aws.amazon.com/waf/latest/developerguide/classic-logging.html

In the case of AWS WAF, the field to look at in COUNT mode is called nonTerminatingMatchingRules.
If the rule is set to ALLOW or BLOCK mode, you need to look at the TerminatingMatchingRules field, which ends processing when a match is found, but COUNT mode is a non-terminating process, and it evaluates whether or not other rules match until the end. Therefore, you need to look at notTerminatingMatchingRules.

Analyzing Logs

You can extract the COUNT log by executing the following query.

fields @timestamp, @message 
| filter @message like /"action":"COUNT"/ 
| sort @timestamp desc 
| display @timestamp, @message, httpRequest.clientIp, httpRequest.uri, httpRequest.country

The above results can be downloaded in JSON format. We recommend a minimum period of one month, but you should be aware that CloudWatch Logs Insights can only retrieve up to 10,000 items at a time.

Once you've downloaded it, you can use jq to analyze it.

Determining if the Request is Legitimate

Now that we've come this far, we'll finally start to judge whether or not the request is legitimate, but we'll continue on the assumption that the SaaS has authentication (login).

First, run the following query. As previously mentioned, check the ruleId within the nonTerminatingMatchingRules.

jq -r '.[] | .["@message"].nonTerminatingMatchingRules[] | .ruleId' logs-insights-results.json | sort | uniq -c | sort -nr 

10 AWSManagedRulesAnonymousIpList 
5   AWSManagedRulesCommonRuleSet 
5   AWSManagedRulesBotControlRuleSet 
1   AWSManagedRulesLinuxRuleSet 
1   AWSManagedRulesKnownBadInputsRuleSet

You can confirm these results. It is okay to set the rules that are not displayed here to BLOCK. This is because the fact that they are not recorded in normal use means that they are only recorded when an attack is received.

Next, we will look at the combination of rules and URIs.

jq -r '.[] | .["@message"] as $msg | $msg.nonTerminatingMatchingRules[] | "\(.ruleId) \($msg.httpRequest.uri)"' logs-insights-results.json | sort AWSManagedRulesAnonymousIpList / 

AWSManagedRulesAnonymousIpList / 
AWSManagedRulesAnonymousIpList /.env 
AWSManagedRulesAnonymousIpList /auth/favicon.ico AWSManagedRulesAnonymousIpList /auth/login 
AWSManagedRulesAnonymousIpList /auth/login 
AWSManagedRulesAnonymousIpList /auth/login 
AWSManagedRulesAnonymousIpList /auth/login 
AWSManagedRulesAnonymousIpList /wp-login.php 
AWSManagedRulesAnonymousIpList /wp-login.php 
AWSManagedRulesBotControlRuleSet / 
AWSManagedRulesBotControlRuleSet / 
AWSManagedRulesBotControlRuleSet /auth/favicon.ico AWSManagedRulesBotControlRuleSet /auth/login 
AWSManagedRulesBotControlRuleSet /auth/login 
AWSManagedRulesCommonRuleSet / 
AWSManagedRulesCommonRuleSet /news/12345
AWSManagedRulesCommonRuleSet /news/files 
AWSManagedRulesCommonRuleSet /auth/login 
AWSManagedRulesCommonRuleSet /news/sources/03a0 AWSManagedRulesKnownBadInputsRuleSet /.env 
AWSManagedRulesLinuxRuleSet /.env

In the following cases, it is possible to determine that it is BLOCK.

Detection is only performed for URIs that are not used in the service
- In the above example, the following are targeted
  - AWSManagedRulesKnownBadInputsRuleSet
  - AWSManagedRulesLinuxRuleSet
IP addresses/bot-related rules that are not detected in access after authentication
- If there is no detection even after authentication, it can be seen that it is not legitimate use
  - It means that an unauthorized user logged in and was unable to use it
  - If you don't want to allow bot access in the first place, just BLOCK them
In the example above, the following are targeted
- AWSManagedRulesAnonymousIpList
- AWSManagedRulesBotControlRuleSe

If you are not confident about your decision here, outputting the User-Agent may help you make a decision. You can output the User-Agent as follows (I will omit the results)

jq -r '.[] | .["@message"] as $msg | $msg.nonTerminatingMatchingRules[] | "\(.ruleId) \($msg.httpRequest.uri) \($msg.httpRequest.headers[] | select(.name | test("(?i)user-agent")) | .value)"' logs-insights-results.json | sort

When you look at this, you can see User-Agent that are clearly not your own users, so you can use this as an element to determine that it is not a legitimate request Basically, the rules for BLOCK can be determined from this investigation. For the rest, we recommend continuing to operate in COUNT mode in case anything happens. The reason for BLOCKing up to this point is that there are not many cases where it is okay to change to BLOCK after logging in, and if there is a case where BLOCK should be used, it means that the site has already been attacked, so there is a possibility that incident response will begin.

Notes on detecting bots

AWS WAF has a managed rule called “AWSManagedRulesBotControlRuleSet”. As the name suggests, this is for detecting bot access.
If you BLOCK access because “our service does not allow bot access”,
there may be unexpected pitfalls. When you set this to BLOCK, please keep in mind the E2E test. It is possible that the E2E test will be detected as a Bot access, the test will fail, and the deployment will fail. Of course, you will be able to notice this before it goes live, so it won't be a big problem, but it is possible that the deployment will suddenly fail, and you won't know what the cause is, so I think it would be good to be aware of this. Also, if you are using a Bot for a service that anyone can access, such as a toC service, you may receive many attack scans if you are outputting logs. This may result in a large amount of output and cost you money. Please consider whether or not to enable BotControl, including these points.

Conclusion

This article summarized how to determine which rules can be safely switched to BLOCK mode based on AWS WAF logs. While it may seem straightforward, figuring out how to search logs required some trial and error. Understanding the structure of logs is key.

I hope this article helps, and I’d appreciate any feedback or suggestions. Thank you for reading.

Delete automatic assignment of Public IPv4 addresses to Amazon EC2 instances using the AWS Systems Manager Automation runbook.

nishikawaakira — Thu, 11 Jul 2024 07:49:47 +0000

I recently did something similar using AWS Config -> Amazon EventBridge -> AWS Lambda in another article. another article. In this case, I would like to use an Automation runbook in AWS Systems Manager to automatically delete the public IPv4 addresses of Amazon EC2 instances.

I would like to tell you that you don't need many programming skills to use an Automation runbook to gain control.

Create an AWS Systems Manager Automation runbook

Now, let's go ahead and create an AWS Systems Manager Automation runbook.

Initially, the following screen is opened, with the design tab now selected.

You can create a runbook using the graphical interface in this way, or you can select the {} Code tab and edit YAML or JSON directly.

Writing an Automation runbook

When you visually add parts to the Automation runbook, you will see YAML being described. You can also write Python within this YAML. Take, for example, AWS-BulkDeleteAssociation in the managed runbook.

The following is written in Python, but this is quite difficult without some programming skills. This is not smart, and for the purpose of this article, I want to show that it can be implemented by people with no programming knowledge, so I want to prove that we can do it without using services like AWS Lambda!

First of all, I will create a runbook with only the minimum required elements. Select the "AWS APIs" tab under the search box and enter "modifynetwork" in the search box to find the ModifyNetworkInterfaceAttribute of AWS API to be used this time. Drag and drop it to the middle of the "ModifyNetworkInterfaceAttribute" between Start and End.

{} Open the Code tab. You will see that "ModifyNetworkInterfaceAttribute" is being hit as an API, as shown below.

We want to put arguments here, as you can see from the AWS Lambda code in the previous article. It seems to be sufficient to enter NetworkInterfaceId.　API Reference is here You can also see that you need to set AssociatePublicIpAddress to false to prevent the automatic assignment of Public IPv4 addresses.

Let's describe it as follows. The regular expression is written assuming that NetworkInterfaceId starts with "eni-" and that a combination of alphabets and numbers is entered. Also, entering (Required) in the parameter description will make it a required parameter. It is not mandatory to pass assumeRole as a parameter, but it is always recommended to do so. This is because you may want to use this runbook by assuming it from another AWS account. For example, there are use cases where a runbook is distributed to each account in CloudFormation StackSets, and the runbook can be assumed and executed from an administrative account.

schemaVersion: '0.3'
description: Disable Public IPv4 on EC2.
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  AutomationAssumeRole:
    type: String
    description: (Optional) The ARN of the role that allows Automation to perform the actions on your behalf.
    default: ''
  NetworkInterfaceId:
    type: String
    description: (Required) Network Interface Id
    allowedPattern: ^eni-[a-z0-9]+$
mainSteps:
  - name: ModifyNetworkInterfaceAttribute
    action: aws:executeAwsApi
    isEnd: true
    inputs:
      Service: ec2
      Api: ModifyNetworkInterfaceAttribute
      NetworkInterfaceId: '{{ NetworkInterfaceId }}'
      AssociatePublicIpAddress: false

Now, enter a suitable name in NewRunbook and press "Create runbook".

Test Run Automation runbook

Open the runbook you have created. You can find the runbook you created in the "Owned by me" tab.

Open it and click on Execute automation.

Before you do so, create an EC2 instance. Check the network interface ID of the Amazon EC2 instance.

Try entering a Network Interface ID starting with "eni-" in the "NetworkInterfaceId" field of the Input parameters and click Execute.

Check that the public IP address in the network interface ID on the EC2 instance has been removed. You will see that it has been deleted. We will now see if this is really the end of the process.

AWS Config Settings

As before, I will use the "ec2-instance-no-public-ip" managed rule. Open this Config rule and click on "Manage remediation".

Choose your own AWS Systems Manager Automation runbook.

Notice that only InstanceId can be passed as a Resource ID parameter.

Oops, it seems that the network interface ID cannot be passed here, even though I really want to pass it here. In other words, there seems to be no way to pass the network interface ID dynamically.

Get a List of Network Interface IDs from EC2 Instance ID

We have no choice but to change course. You will find that you need to get the network interface ID from the EC2 instance to pass it on. There are two main methods. The first is to use DescribeInstances to get all EC2 information and extract only the necessary information. The second is to use DescribeNetworkInterfaces to get just the network interface information.

This time, the information on the EC2 instance will hardly be used, so we will hit the DescribeNetworkInterfaces API to get the information on network interfaces only.

So, as shown below, the DescribeNetworkInterfaces API is used to create the part that obtains information on network interfaces.

The code is as follows.

schemaVersion: '0.3'
description: Disable Public IPv4 on EC2.
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  InstanceId:
    type: String
    description: The ID of EC2 instance
  AutomationAssumeRole:
    type: String
    description: (Optional) The ARN of the role that allows Automation to perform the actions on your behalf.
    default: ''
mainSteps:
  - name: DescribeNetworkInterfaces
    action: aws:executeAwsApi
    isEnd: true
    inputs:
      Service: ec2
      Api: DescribeNetworkInterfaces
      Filters:
        - Name: attachment.instance-id
          Values:
            - '{{InstanceId}}'
    outputs:
      - Name: NetworkInterfaceIds
        Selector: $.NetworkInterfaces..NetworkInterfaceId
        Type: StringList

Network interface IDs can now be retrieved as a StringList. There is a caveat here: if you look at the API specification for DescribeNetworkInterfaces, the Request Parameter is written as Filter.N, but at first, it was not clear how to write it in YAML. The answer I arrived at is below, which is closer to the way CLI　is written.

Filters:
- Name: attachment.instance-id
Values:
- '{{InstanceId}}'

Another is the Selector in outputs.

Selector: $.NetworkInterfaces..NetworkInterfaceId

This Selector allows you to specify which values are output and used in the next step. As an EC2 instance may have multiple network interfaces, it is necessary to retrieve them all, but when using Selector: $.NetworkInterfaces, only a MapList (like an associative array) can be specified for Type. In this case, the loop in the runbook cannot be used. Therefore, you need to get the array as a StringList, which can be done by writing "..". By writing this, the list of specified items can be retrieved as a StringList.

Delete the Public IPv4 Address of the Relevant Network Interface ID

Now that you have reached this point, the rest is easy. Create a runbook like the following.

The final code is as follows.

schemaVersion: '0.3'
description: Disable Public IPv4 on EC2.
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  InstanceId:
    type: String
    description: The ID of EC2 instance
  AutomationAssumeRole:
    type: String
    description: (Optional) The ARN of the role that allows Automation to perform the actions on your behalf.
    default: ''
mainSteps:
  - name: DescribeNetworkInterfaces
    action: aws:executeAwsApi
    nextStep: Loop
    isEnd: false
    inputs:
      Service: ec2
      Api: DescribeNetworkInterfaces
      Filters:
        - Name: attachment.instance-id
          Values:
            - '{{InstanceId}}'
    outputs:
      - Name: NetworkInterfaceIds
        Selector: $.NetworkInterfaces..NetworkInterfaceId
        Type: StringList
  - name: Loop
    action: aws:loop
    isEnd: true
    inputs:
      Iterators: '{{ DescribeNetworkInterfaces.NetworkInterfaceIds }}'
      Steps:
        - name: ModifyNetworkInterfaceAttribute
          action: aws:executeAwsApi
          isEnd: true
          inputs:
            Service: ec2
            Api: ModifyNetworkInterfaceAttribute
            NetworkInterfaceId: '{{ Loop.CurrentIteratorValue }}'
            AssociatePublicIpAddress: false

"Create new version", then select "Create new default version" to create a new document.

Before you start testing, launch an EC2 instance and attach several Network Interfaces.

Then open the runbook, click on "Execute automation", enter the InstanceId and press Execute.

Check the previous screen to see if it has been disabled properly. If it is disabled as shown in the image below, you have succeeded.

Conclusion

In this way, control can be exercised without programming knowledge. However, when you write it like this, you might think it's easy to do! And while that is the aim, there are some real quirks in the way YAML is written, and I had a lot of trouble with it. At first, I thought that to get the network interface IDs as a list, I would need to write some Python code. And indeed, the first version of this blog did. While researching, I realized that it could be retrieved using "..".

I'm going to accumulate this kind of runbook writing style and work towards a situation where anyone can control the AWS environment!

Thank you for reading to the end.

Automatically remove automatic IPv4 address assignment to Amazon EC2 instances

nishikawaakira — Wed, 05 Jun 2024 18:49:42 +0000

It is now possible to dynamically remove and add public IPv4 addresses that were recently automatically assigned to an EC2 instance.

Accordingly, this article will try to automatically delete the public IPv4 address that was assigned to EC2 by default.

Configuration

This time, I used the configuration AWS Config -> Amazon EventBridge -> AWS Lambda. Actually, AWS Config -> AWS Systems Manager can also be configured using Automation runbook, which is smarter, but this time I would like to introduce the method using AWS Lambda.

Configure AWS Config

First, configure AWS Config." ec2-instance-no-public-ip". This managed rule, however, does not enable evaluation of provisioned resources. However, the evaluation mode of this managed rule enables evaluation of provisioned resources, and evaluation is performed only after the instance is started. Therefore, if you want to modify it at startup, you need to prepare your own rules. On the other hand, if you want to target EC2 after startup, this rule may be suitable.

That's all there is to AWS Config. It is very easy.

Create AWS Lambda

In fact, here is where I run into a bit of a snag. In this case, I have chosen Python, but in general, if you want to use Python in Lambda to execute APIs, you will need to use a library called Boto3. Lambda comes standard with this library, but if the API specification has just been changed, as in this case, Boto3 is not supported, or the version of Boto3 in Lambda itself is a bit old, and an error will occur.

API Specification and send a request as follows,

Unknown parameter in input: "AssociatePublicIpAddress"
You may see that you have been told, "Unknown parameter in input: "AssociatePublicIpAddress".

So, let's first find out how many versions of Boto3 Lambda has.
Let's run the following in Lambda.

When I ran this, it showed 1.34.42 (as of 5/14/2024).
However, the latest version of Boto3 at this time is 1.34.103. And I see that the ability to dynamically remove and add auto-assigned public IPv4 addresses for this EC2 instance was added in 1.34.91.

I found that it is not possible to run the application as it is, so we need to create a Lambda Layer.

Incidentally, as a side note, the same results were obtained when making API calls with YAML in Systems Manager, so it seems that Systems Manager also takes some time to catch up with the latest API.
So, keep in mind that you will need to wait a few days after a new specification is implemented.

I will not discuss how to create the Lambda Layer, but once it has been created, implement it as follows.

import json
import boto3

def modify_network_interface_attribute(network_interface_id):
    ec2 = boto3.client('ec2')

    try:
        response = ec2.modify_network_interface_attribute(
            NetworkInterfaceId=network_interface_id, # Specify the target Network Interface ID.
            AssociatePublicIpAddress=False # False deletes the public IPv4 address
        )
        print("Network Interface Modified Successfully:")
        print(response)
    except Exception as e:
        print("An error occurred:", e)



def lambda_handler(event, context):

    detail = event['detail']
    # network_interface_id = detail['configurationItem']['configuration']['networkInterfaceId']

    network_interface_ids = []

    # Get a list of resources that have changed
    result = detail.get('newEvaluationResult')
    identifier = result.get('evaluationResultIdentifier')
    configuration_item = identifier.get('evaluationResultQualifier')

    # Check if the resource type is an EC2 instance
    if configuration_item and configuration_item['resourceType'] == 'AWS::EC2::Instance':
        instance_id = configuration_item['resourceId']

        ec2_client = boto3.client('ec2')

        # Get instance details
        response = ec2_client.describe_instances(InstanceIds=[instance_id])
        reservations = response['Reservations']

        # Stop auto-assign of all network interface IDs
        for reservation in reservations:
            for instance in reservation['Instances']:
                for interface in instance['NetworkInterfaces']:
                    network_interface_ids.append(interface['NetworkInterfaceId'])
                    modify_network_interface_attribute(interface['NetworkInterfaceId'])

    print("Network Interface IDs: ", network_interface_ids)

    return {
        'statusCode': 200,
        'body': json.dumps('Success!!')
    }

It is written in a rather crude manner and returns, "Success! but if you just want to remove the public IP address automatically, you can do it with this.

Testing AWS Lambda

The following can be used for testing. Please enter the instance ID you have set up appropriately in resourceId, and then run the test.

{
  "version": "0",
  "id": "ID",
  "detail-type": "Config Rules Compliance Change",
  "source": "aws.config",
  "account": "[AWS Account ID]",
  "time": "2024-05-19T12:19:54Z",
  "region": "ap-northeast-1",
  "resources": [],
  "detail": {
    "resourceId": "[Instance ID]",
    "awsRegion": "ap-northeast-1",
    "awsAccountId": "[AWS Account ID]",
    "configRuleName": "ec2-instance-no-public-ip",
    "recordVersion": "1.0",
    "configRuleARN": "arn:aws:config:ap-northeast-1:[AWS Account ID]:config-rule/config-rule-qx4cpe",
    "messageType": "ComplianceChangeNotification",
    "newEvaluationResult": {
      "evaluationResultIdentifier": {
        "evaluationResultQualifier": {
          "configRuleName": "ec2-instance-no-public-ip",
          "resourceType": "AWS::EC2::Instance",
          "resourceId": "[Instance ID]",
          "evaluationMode": "DETECTIVE"
        },
        "orderingTimestamp": "2024-05-19T00:03:43.749Z"
      },
      "complianceType": "NON_COMPLIANT",
      "resultRecordedTime": "2024-05-19T12:19:53.922Z",
      "configRuleInvokedTime": "2024-05-19T12:19:53.696Z",
      "annotation": "This Amazon EC2 Instance uses a public IP."
    },
    "notificationCreationTime": "2024-05-19T12:19:54.417Z",
    "resourceType": "AWS::EC2::Instance"
  }
}

If it works correctly, the configuration of the instance in question should change as follows.

Configure Amazon Event Bridge

Finally, let's create the rules for EventBridge.

The event pattern is as follows AWS Config is the source and calls Lambda based on Compliance Change for ec2-instance-no-public-ip.

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["ec2-instance-no-public-ip"]
  }
}

Select AWS Lambda function in Target and select AWS Lambda function you just created.

All that remains is to create another instance and confirm that the modifications have been made automatically.
You may want to monitor it to make sure it is working properly.
If it is not working properly, try logging in AWS Lambda function and debugging to see if the Lambda itself is being called properly.

Conclusion

I was able to remove the public IP from EC2 more easily than I expected, but it is not as simple as using AWS Systems Manager Automation runbook (my own subjective opinion), and requires a fair amount of coding knowledge. I'm writing roughly again this time, but we should also pick up error cases more thoroughly, and we need to pay attention to such things.
Next time, I would like to do the same assignment to see how it can be written using AWS Systems Manager Automation runbook.

DEV Community: nishikawaakira

Mitigating Session Hijacking with JA4 Session Binding and AWS WAF Dynamic Label Interpolation

Forwarding JA4 to the Application: A Recap of Article 2

Implementing Session Binding

JA4 Can Change Even for the Same Client

TLS session resumption with a PSK

HTTP/2 (h2) versus HTTP/3 (h3)

Browser updates

Testing the Behavior

1. The b section is relatively stable within the same transport family

2. The variation converges on a small number of values

3. QUIC reduces distinguishing power

Turning the Findings into a Practical Design

Step-Up Authentication with ATP Signals

Conclusion

Building a False-Positive-Resilient Challenge Architecture with AWS WAF Dynamic Label Interpolation

What Is Dynamic Label Interpolation?

Constraints to Understand Before You Design

1. Custom request headers can be inserted only by Allow, Count, CAPTCHA, and Challenge actions

2. Inserted request headers receive the x-amzn-waf- prefix

3. With CAPTCHA and Challenge actions, requests without a valid token are not forwarded to the origin

4. Each string value can contain at most 10 placeholders

5. Interpolating custom labels requires fully qualified names

6. A namespace with no matching labels resolves to an empty string

Use Case 1: Embed request_id in the Block Page to Create a False-Positive Feedback Loop

Use Case 2: Carry the Fingerprint into the Challenge Page

During redirection: interpolate values into the Location header

After success: issue a clearance cookie bound to the fingerprint

The Evaluation-Order Trap

Testing the Actual Behavior

rules.json

Synthetic labels resolve correctly

Multiple labels resolve to a comma-separated list

A namespace with no matches still inserts the header with an empty value

Headers inserted by AWS WAF are visible to CloudFront Functions on viewer-request

Summary

Implementing a JA4H-Equivalent Fingerprint with Amazon CloudFront Functions to Mitigate Bot Traffic

What Is JA4?

Amazon CloudFront, JA4, and CloudFront KVS

What Is JA4H?

Implementing JA4H in CloudFront Functions

Recovering header order and original casing with CloudFront-Viewer-Header-Order

Implementation

Comparing the Output with the Reference Implementation

Reducing False Positives with a Challenge Page

Summary

Implementing Impossible Location Detection with Amazon CloudFront Functions + KVS

Why CloudFront Functions?

How It Works

At Login

When Accessing Protected Pages

Architecture Difference from the Lambda@Edge Version

Origin Request Policy Is Still Required

Default Protection Mode

Important Implementation Notes

Handling SPA and API Requests

Validate KVS Writes Carefully

Using ASN As Well

Reauthentication Instead of Hard Blocking

Sample Code

Terraform

Application-Side KVS Write

Login Flow Example

Logout Handling

BFF Architecture

When the Authentication System Uses a Different Domain

Blocking Direct Access to the Origin

KVS Limitations

Capacity

No TTL

Write Rate and ETag Conflicts

Eventual Consistency

Why Not DynamoDB?

Architecture Comparison

Summary

Implementing Impossible Location Detection Without Application Changes Using Amazon CloudFront + Lambda@Edge

How It Works

At Login

When Accessing Protected Pages

The “Oh, That’s Why!” Moment

HTTP/2 (`h2`) versus HTTP/3 (`h3`)

1. The `b` section is relatively stable within the same transport family

2. Inserted request headers receive the `x-amzn-waf-` prefix

Use Case 1: Embed `request_id` in the Block Page to Create a False-Positive Feedback Loop

During redirection: interpolate values into the `Location` header

`rules.json`

Headers inserted by AWS WAF are visible to CloudFront Functions on `viewer-request`

Recovering header order and original casing with `CloudFront-Viewer-Header-Order`

`config_items`

`graph_nodes`

`graph_edges`