Software Dev Archives - Anuj Varma, Hands-On Technology Architect, Clean Air Activist

Is Ethereum Deflationary?

Anuj Varma — Mon, 16 Feb 2026 14:35:14 +0000

Ethereum Staking vs Bitcoin Halving Model

1. Is Ethereum Staking Inflationary Long Term?

Post-Merge, Ethereum operates under a Proof-of-Stake model.
New ETH is issued to validators who stake capital to secure the network.

A. New ETH Issuance

Issued to validators as staking rewards
Issuance rate adjusts based on total ETH staked
Current gross issuance: ~0.5%–0.7% annually

B. Fee Burning (EIP-1559)

Base transaction fees are permanently burned
Higher network activity → more ETH burned

Net Supply Outcome

Network Activity	Net Supply Effect
Low activity	Mildly inflationary
Moderate activity	Near neutral
High activity	Deflationary

Ethereum’s long-term supply is activity-dependent.

2. Comparison to Bitcoin’s Halving Model

Bitcoin Monetary Structure

Fixed maximum supply: 21 million
Block rewards halve approximately every 4 years
Issuance is time-based and deterministic
Eventually reaches zero new issuance

Ethereum Monetary Structure

No fixed supply cap
Issuance varies based on staking participation
Transaction fees are burned
Net supply depends on network demand

Core Differences

Feature	Ethereum	Bitcoin
Supply Cap	No fixed cap	21M hard cap
Issuance Driver	Staking participation	Time-based halving
Fee Handling	Fees burned	Fees paid to miners
Deflationary Potential	Yes, activity-dependent	Disinflationary only
Monetary Policy	Adaptive	Fixed

Summary

Bitcoin: Digital gold model

Absolute scarcity
Predictable issuance
Monetary rigidity

Ethereum: Productive digital asset model

Capital-secured network
Supply reacts to economic usage
Monetary flexibility

Conclusion

Bitcoin provides predictable, capped scarcity.
Ethereum provides adaptive, activity-based monetary dynamics.

The post Is Ethereum Deflationary? appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

ISO/IEC 27001 vs. NIST SP 800-171

Anuj Varma — Wed, 17 Dec 2025 05:38:17 +0000

ISO/IEC 27001 vs NIST SP 800-171

Executive Summary
ISO/IEC 27001 and NIST SP 800-171 serve different but complementary purposes.
ISO/IEC 27001 focuses on enterprise-wide information security governance,
while NIST SP 800-171 defines prescriptive security requirements for protecting
U.S. government Controlled Unclassified Information (CUI).

High-Level Comparison

Dimension	ISO/IEC 27001	NIST SP 800-171
Primary Purpose	Enterprise-wide information security management	Protection of Controlled Unclassified Information (CUI)
Nature	International, certifiable standard	U.S. government compliance standard
Scope	Organization-wide	Systems handling CUI
Governance Depth	Very strong	Moderate
Technical Prescriptiveness	Moderate (risk-based)	High (requirement-based)
Certification	Yes (third-party audit)	No (self-attestation / assessments)
Compliance Driver	Customers, regulators, board assurance	Federal contracts (DFARS, CMMC)
Primary Audience	Executives, risk leaders, auditors	Federal contractors, security teams

ISO/IEC 27001 Overview

What It Is

ISO/IEC 27001 is an international standard for establishing, implementing,
operating, monitoring, and continually improving an
Information Security Management System (ISMS).

Core Focus Areas

Risk management and risk treatment
Policy and control governance
Defined ownership and accountability
Continuous improvement using the PDCA cycle

Strengths

Strong board and executive credibility
Globally recognized and regulator-friendly
Flexible and technology-agnostic
Maps well to SOC 2, HIPAA, GDPR, and NIST frameworks

Limitations

Not prescriptive at the technical implementation level
Requires supplementary standards for detailed control execution

NIST SP 800-171 Overview

What It Is

NIST SP 800-171 defines mandatory security requirements for protecting
Controlled Unclassified Information (CUI) in
non-federal systems and organizations.

Where It Applies

Defense Industrial Base (DIB)
Federal contractors and subcontractors
Organizations subject to DFARS and CMMC

Structure

14 security control families
110 specific security requirements
Derived from NIST SP 800-53

Strengths

Clear, testable, and auditable requirements
High degree of technical specificity
Contractually enforceable

Limitations

Narrow scope focused solely on CUI
No overarching management system
Limited applicability outside U.S. federal contracting

Purpose Alignment

Question	ISO/IEC 27001	NIST SP 800-171
Do we manage security risk enterprise-wide?	Yes	No
Are we compliant with U.S. federal CUI requirements?	No	Yes
Is this globally recognized?	Yes	No
Is this technically prescriptive?	Partially	Yes
Can this satisfy auditors and customers?	Yes	Yes (within scope)

How They Are Used Together (Best Practice)

ISO/IEC 27001
(Enterprise ISMS & Risk Governance)
↓
Risk Treatment Decisions
↓
NIST SP 800-171
(CUI-Specific Security Requirements)

In mature organizations, ISO/IEC 27001 provides the governance and risk
management foundation, while NIST SP 800-171 defines the concrete control
requirements for CUI environments.

Consulting Recommendation

Use ISO/IEC 27001 to establish enterprise-wide security
governance, external assurance, and executive accountability.
Use NIST SP 800-171 where contractually required to protect
U.S. government CUI and demonstrate DFARS or CMMC compliance.

ISO/IEC 27001 answers “Are we managing information security correctly as an
organization?”
NIST SP 800-171 answers “Are we meeting our federal CUI obligations?”

The post ISO/IEC 27001 vs. NIST SP 800-171 appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

AES ciphertext length close to plaintext length – leakage

Anuj Varma — Wed, 03 Dec 2025 04:04:27 +0000

AES Ciphertext Length Leakage

Does AES Ciphertext Length Leak Information?

1️⃣ What Can Be Leaked

Even though AES encryption is strong, some metadata can still be inferred from ciphertext:

Length of the plaintext:
For example, if a hacker sees a 128-byte ciphertext, they know the plaintext was roughly 128 bytes (or slightly less if padding was used).
This can give clues about the type of data (e.g., a 16-byte message might be a password or ID).
Patterns in block modes without randomness:
ECB mode is particularly vulnerable: identical plaintext blocks produce identical ciphertext blocks, revealing repeating patterns.
CBC/CTR/GCM modes mitigate this by using IVs or counters to randomize encryption.

2️⃣ How Cryptography Mitigates This

Even though ciphertext length is observable, attackers generally cannot decrypt without the key. Strategies to reduce leakage include:

Random padding:
Add extra random bytes beyond block padding to make messages appear uniform in length.
Authenticated encryption modes (GCM, CCM):
Include random IVs or nonces for each encryption → ciphertext is randomized even for identical plaintext.
Message encapsulation:
In protocols like TLS or S/MIME, ciphertext is wrapped in frames of fixed or variable size to hide exact lengths.
Traffic analysis countermeasures:
Padding can be added at the protocol level to prevent attackers from guessing content size (common in VPNs, messaging apps).

3️⃣ Key Takeaways

AES itself is secure — knowing ciphertext length does not allow decryption.
Length leakage is a minor information leak.
Using secure modes with IVs/nonces and optional padding mitigates this risk.
For maximum security (e.g., hiding message lengths), consider padding all messages to a uniform length.

The post AES ciphertext length close to plaintext length – leakage appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

AES 256 Ciphertext Length versus Input String length

Anuj Varma — Wed, 03 Dec 2025 04:01:39 +0000

AES Ciphertext Length Explanation

AES Ciphertext Length Explained

1⃣ AES Block Size

AES always operates on 128-bit blocks (16 bytes). The key size (128/192/256 bits) does not affect the block size.
AES encrypts data in multiples of 16 bytes.

2⃣ Padding

If your plaintext is not a multiple of 16 bytes, AES must pad it before encryption.

PKCS#7 padding is common
If plaintext = 20 bytes → pad with 12 bytes → total = 32 bytes
If plaintext = 32 bytes → add 16 bytes padding → total = 48 bytes

So the ciphertext length is usually ≥ plaintext length, rounded up to the next 16-byte block.

3⃣ Modes of Operation

Mode	Ciphertext length vs plaintext	Notes
ECB / CBC	Multiple of 16 bytes (padding applied)	Deterministic / requires IV for CBC
CTR / GCM	Same length as plaintext	Stream cipher mode, no padding needed
CFB / OFB	Same length as plaintext	Operates like a stream cipher

Note: CBC and ECB require padding → ciphertext may be longer. CTR, GCM, CFB, OFB → ciphertext = plaintext length (excluding authentication tag in GCM).

4⃣ Example

Plaintext: Hello world! (12 bytes)
AES-256-CBC → padded to 16 bytes → ciphertext = 16 bytes
AES-256-CTR → ciphertext = 12 bytes

Note: For AES-GCM, an authentication tag (usually 16 bytes) is appended to the ciphertext.

Summary

AES block size = 16 bytes, ciphertext = multiples of 16 bytes if using block modes with padding.
Stream modes (CTR/GCM) → ciphertext ≈ plaintext length (tag aside).

The post AES 256 Ciphertext Length versus Input String length appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

JSON payload – security checklist

Anuj Varma — Wed, 26 Nov 2025 20:51:35 +0000

JSON Security Checklist

1. Input Validation

Validate JSON structure: Use strict schemas (JSON Schema, OpenAPI, protobuf). Reject unknown fields.
Enforce types: Ensure all fields match expected types; avoid implicit type coercion.
Size limits: Set max body size to prevent DoS via large payloads.
Depth and recursion limits: Limit nesting depth to prevent parser abuse or stack overflows.

2. Parsing Safety

Safe parsers only: Use secure JSON parsers; never use eval() or unsafe parsing.
Disable or sanitize special tokens: Block keys such as __proto__, constructor, and prototype to prevent prototype pollution.
UTF-8 normalization: Normalize Unicode to avoid homoglyph or invisible character attacks.

3. Injection Protection

Avoid dynamic code execution: Never evaluate JSON values as code.
Sanitize text fields: When embedding JSON into SQL, logs, HTML, or command contexts, sanitize properly.
NoSQL injection prevention: Whitelist operators and fields when JSON is used to build NoSQL queries.

4. Access Control & Authentication

Validate authorization: Never trust roles, permissions, or identity fields from JSON clients.
Remove sensitive fields from client input: Strip values such as isAdmin, role, or priceOverride.

5. Data Sanitization

Strip unexpected fields: Use allowlists; reject or drop extras.
Output sanitization: Escape JSON when embedding inside HTML.
Canonicalize before processing: Normalize the JSON prior to business logic validation.

6. Security Headers & Transport

HTTPS required: Enforce TLS for all JSON API communication.
Content-Type header: Require application/json for requests.
Accept header strictness: Reject ambiguous or multipart request types.

7. Logging & Telemetry

Avoid sensitive data in logs: Do not log secrets, tokens, or PII in JSON bodies.
Log rejections: Record schema validation errors and malformed JSON attempts.

8. Protection Against Common Attacks

Prototype pollution mitigation: Block __proto__, prototype, and constructor keys.
XXE prevention: Do not parse JSON using XML-based libraries.
CORS controls: Apply strict CORS policies to JSON endpoints.
CSRF prevention: Use CSRF tokens or SameSite cookies for authenticated JSON APIs.
Rate limiting: Throttle requests by IP, user, or token to prevent brute-force attacks.

9. Sensitive Data Handling

Encrypt at rest: Encrypt systems storing JSON with sensitive data.
Token/secrets hygiene: Reject JSON that includes secrets unless required.
Response filtering: Return minimal fields to the client (least privilege).

10. Output Encoding

Escape for HTML contexts: Prevent XSS by escaping JSON before placing it in HTML.
Avoid JSONP: Disable JSONP endpoints as they are inherently unsafe.

The post JSON payload – security checklist appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Multisig Inheritance Plan

Anuj Varma — Fri, 21 Nov 2025 15:16:48 +0000

multisig inheritance

2-of-3 Multisig Inheritance Plan — Diagram & Full Guide

This HTML document contains a complete explanation (from earlier responses) plus a clear diagram illustrating a 2-of-3 multisig Bitcoin inheritance setup, secure storage advice, and recommended trust language & operational details.

Why cryptographic keys maintain integrity (short recap)

In decentralized systems like Bitcoin there is no central authority — cryptographic keys and digital signatures enforce ownership and ledger integrity. Possession of the private key equals control of funds; public keys / addresses let others send funds; signatures verify spenders without revealing secrets.

Multisig & inheritance — the concept

A multisignature (multisig) wallet holds multiple public keys and requires a threshold (e.g., 2 of 3) of corresponding private keys to authorize a spend. For inheritance: you can hold one key, a trusted attorney/executor holds another, and the heir holds the third. Any two keys can move funds.

Diagram — 2-of-3 Multisig Workflow

Interactive diagram (SVG) below. It shows the three key-holders, the multisig wallet, and how any two keys combine to authorize spending.

Key A (You)
Hardware wallet / offline key
Primary owner

Key B (Attorney / Executor)
Trusted professional / custodian
Activation after verification

Key C (Heir)
Primary beneficiary’s key share
Held securely or released on condition

2-of-3 Multisig Wallet
Any 2 keys required to sign a transaction

Threshold: 2 of 3

If You + Attorney sign → funds move
If Attorney + Heir sign → funds move
If You + Heir sign → funds move

You (Key A)

— keep offline in hardware wallet

Attorney (Key B)

— custodian for post-death access

Heir (Key C)

— beneficiary key or share

Detailed 2-of-3 plan (step-by-step)

Choose platforms: Pick hardware wallets (Coldcard, Trezor, Ledger) and multisig-compatible software (Electrum, Sparrow, Blockstream Green, Unchained). Consider custodial multisig services (Casa, Unchained) if you want managed support.
Generate keys securely: Prefer offline creation. Create Key A (you), Key B (attorney/executor), Key C (heir). Each on its own hardware or offline environment.
Create the multisig wallet: Combine public keys in the wallet software to create the 2-of-3 multisig descriptor / address. Fund with a small test amount first.
Test recovery: Perform a test spend that requires two keys to ensure everyone knows the process.
Backups & duplication: Store at least one encrypted backup of each key’s seed/backup in a different physical location (safe deposit box, secondary safe).

Key storage recommendations

Key A (You): Hardware wallet in a home fireproof safe; backup seed in a bank safe deposit box or second safe. Consider an encrypted digital backup stored offline on an air-gapped storage device.

Key B (Attorney/Executor): Stored by the professional in their secure custody solution or vault. Ensure their agreement (written) to only release under the conditions you define (e.g., certified death certificate + ID verification).

Key C (Heir): Can be held by the heir but with instructions limiting spending before conditions are met. Alternatively, keep Key C with a trusted third party until distribution.

What to put in the trust & supporting documents

Do not put actual private keys or seed phrases in the trust document. Instead include:

Beneficiary designations: Name who receives the crypto assets.
High-level wallet description: Explain it is a 2-of-3 multisig and identify the key-holders by role (not by revealing keys).
Location & access process: Reference a separate secured “Crypto Instruction Letter” that explains where seeds/backups are stored and step-by-step recovery instructions.
Executor powers: Give the trustee authority to coordinate signing or to work with a professional custodian to consolidate and transfer assets.
Conditions for release: E.g., proof of death, multi-factor verification, or court order if necessary.
Replacement & update instructions: How to rotate keys or replace a key-holder if someone dies or becomes incapacitated.

Practical tips & gotchas

Never store seed phrases in plain text inside a will — that document becomes public during probate in many jurisdictions.
Perform a regular review (annual or biennial) to ensure key-holders, attorney, and heirs are still appropriate and able to carry out duties.
Consider a small training session with the heir and attorney so they know the signing workflow and how to access the multisig wallet when needed.
Test the recovery at least once (with a small amount) to ensure processes are followed correctly.

Example language snippets

Trust clause (high-level example):

"The Trustee shall, upon presentation of acceptable proof of the Settlor's death, take custody of the Settlor's digital asset holdings and follow the Settlor's separate Crypto Instruction Letter to effectuate transfer of the assets to the named Beneficiaries. The Crypto Instruction Letter is incorporated by reference but shall not be recorded in public filings. The Trustee is authorized to engage qualified technical and custodial professionals to assist in recovery and transfer."

Crypto Instruction Letter (items it should contain, kept separately):

Name of multisig wallet software and version.
Public keys / wallet descriptor (OK to include public information).
Physical locations of hardware wallets and backup seed phrases (encrypted), and the locations of safe deposit boxes.
Step-by-step steps for reconstituting the wallet, including contact details for the attorney and any service providers.
Any PINs or passphrases required — encrypted or stored in a way that only the executor can decrypt (e.g., sealed envelope with instructions only to open upon death).

The post Multisig Inheritance Plan appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Copying formula values in Excel

Anuj Varma — Thu, 20 Nov 2025 20:05:42 +0000

How to copy cells that contain formulas (Excel)

Below are concise options depending on whether you want to copy formulas as formulas, copy the literal formula text, or paste only the resulting values.

1. Copy formulas and keep them as formulas

Select the cells that contain the formulas.
Press Ctrl+C to copy.
Go to the destination and press Ctrl+V to paste.

Excel will adjust relative references automatically (e.g., =A1+B1 becomes relative to the new location).

2. Copy formulas exactly (don’t let Excel adjust references)

Use one of these methods depending on your needs:

Make references absolute: change references like A1 → $A$1 before copying so they don’t shift.
Copy from the Formula Bar:
1. Select the cell.
2. Click the formula bar, select the full formula text, then Ctrl+C.
3. Paste the formula text where you want it (for example into another cell’s formula bar or a text editor).
Show formulas and copy:
1. Press Ctrl+` (backtick) to toggle “Show Formulas” mode.
2. Copy the displayed cells and paste them where needed.
3. Press Ctrl+` again to return to normal view.

3. Copy formulas but paste only the resulting values

Select and copy the cells (Ctrl+C).
Right-click the destination cell > choose Paste Special > Values, or use the Paste menu and click the 123 icon (Paste Values).
Alternatively: after copying, press Alt, E, S, then V (classic keyboard sequence for Paste Special → Values) and Enter.

4. Copy formulas to another workbook without breaking references

If formulas reference other sheets or workbooks, copy using the regular method and then use Paste Formulas at the destination (Paste → Formulas) so Excel attempts to preserve links.
If the references point to external workbooks, keep both files open while copying so references update correctly.

Quick examples

// Original cell A2 contains:
=SUM(B2:D2)

// If you copy A2 to A3:
=SUM(B3:D3)   // relative copy

// If you change to:
=SUM($B$2:$D$2)  // absolute, it remains the same after copy

Note: Keyboard shortcuts can vary on macOS (use ⌘ instead of Ctrl). The backtick (`) toggle for “Show Formulas” works in most Windows Excel versions.

The post Copying formula values in Excel appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Second Factor Options – Google Auth, Yubi Keys, Security Questions…

Anuj Varma — Fri, 24 Oct 2025 16:59:16 +0000

Second Factor in MFA: YubiKeys vs Security Questions vs SMS Texts vs TOTP Apps

1) YubiKeys (Hardware Security Keys — FIDO2/U2F)

Strongest protection: public-key crypto; resistant to phishing, SIM-swaps, and replay.
Hardware bound: requires physical possession; ideal for admins/high-value accounts.
Fast & reliable: tap/insert; no codes; works offline once registered.
Broad support: major IdPs (Google, Microsoft, Okta), browsers, and OSes.

Cost: typically $40–$70 per key; teams need spares.
Loss/rotation: must plan backup keys and recovery flow.
Setup/compatibility: legacy apps may lack FIDO support; onboarding non-technical users can take guidance.

2) Security Questions

Simple: no hardware/app required; familiar to end users.
Offline fallback: can be used for account recovery where nothing else is available.

Weak assurance: answers are guessable, researchable, or reused; easy to phish.
Static “secrets”: once exposed, provide ongoing risk; often poorly stored/validated.
Deprecated pattern: increasingly discouraged by modern identity standards.

3) SMS Text Messages (One-Time Codes)

Ubiquitous: works on any phone; near-universal service support.
Low friction: easy onboarding; no extra apps or hardware.

Susceptible to takeovers: SIM-swaps, number-port-out fraud, SS7 flaws, insider abuse.
Coverage dependent: no signal ⇒ no code; delivery can be delayed.
Phishable: users can be tricked into reading codes to attackers or entering on fake sites.

4) TOTP App Codes (e.g., Google Authenticator, Authy, Microsoft Authenticator)

Time-based One-Time Password (RFC 6238)

Stronger than SMS: offline after setup; not tied to phone number or carrier.
Widely supported & free: works with most services; multiple accounts per app.
Reasonable usability: 6-digit code every ~30s; no special hardware to buy.

Still phishable: attacker-in-the-middle can relay codes in real time.
Seed/backup risk: losing device without backups/export of secrets can lock users out; seed theft compromises factor.
Device management: multi-device sync varies by app; requires secure backup practices.

Summary Comparison

Factor Type	Security Strength	Phishing Resistance	Cost	Ease of Use	Reliability	Best Fit
YubiKey (Hardware)	★★★★★ (Highest)	High ( Origin-bound, challenge-response )	$$ (hardware purchase)	Medium (simple once issued)	Very High (no network needed)	Admins, executives, developers, finance, privileged access
TOTP App Codes	★★★★	Medium-Low (codes can be phished)	$ (free apps)	Medium (manual code entry)	High (offline; time-sync required)	General workforce; good balance of security & cost
SMS Codes	★★	Low (SIM-swap/relay risk)	$	Easy	Medium (coverage & delivery issues)	Low-risk users; temporary fallback only
Security Questions	★ (Lowest)	Very Low	$	Easy	Low	Legacy recovery scenarios (avoid for MFA)

Practical Recommendations

Primary for high-value access: YubiKeys (with at least one backup key and a documented recovery process).
Default for most users: TOTP app codes (enable secure backup/export of seeds or use enterprise-managed authenticators).
Fallback only: SMS (use for emergency recovery; monitor for SIM-swap attempts; restrict for admins).
Avoid as MFA: Security questions (if used at all, limit to secondary recovery with strong KBA controls).

The post Second Factor Options – Google Auth, Yubi Keys, Security Questions… appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Blocking or Allowing entire countries in Cloudflare

Anuj Varma — Thu, 18 Sep 2025 18:34:08 +0000

Blocking Entire Countries with Cloudflare Geoblocking (Step-by-Step Guide)

Blocking Entire Countries with Cloudflare Geoblocking

Yes—Cloudflare can block (or challenge) all traffic from a selected country. Here’s how to do it safely, with alternatives and automation tips.

What Is Geoblocking?

Geoblocking uses the visitor’s IP geolocation (Cloudflare’s CF-IPCountry) to take an action—such as Block, Challenge (CAPTCHA), or JS Challenge—for traffic coming from one or more countries.

Action	Typical Use Case
Block	Fully deny traffic from specified countries.
Challenge	Allow only human traffic to pass via CAPTCHA.
JS Challenge	Mitigate bots with a background browser check.

Heads-up: Country blocks affect all users in those regions, including legitimate ones. If possible, scope rules to admin areas or risky endpoints rather than your entire site.

Option A: Set It Up in the Cloudflare Dashboard

Open your zone in the Cloudflare dashboard.
Navigate to Security → WAF → Firewall Rules.
Click Create rule.
Add a descriptive name (e.g., Block CN & RU (Global)).
In the expression builder, choose:
- Field: ip.geoip.country
- Operator: in
- Value: pick countries (e.g., CN, RU)
Set the Action to Block (or Challenge/JS Challenge).
Save and deploy.

Example Firewall Expression

(ip.geoip.country in {"CN" "RU" "KP"})

Scope to critical paths: To protect sign-in or admin areas without blocking the full site, combine conditions:

(ip.geoip.country in {"CN" "RU"}) and (http.request.uri.path starts_with "/admin")

Account-Wide vs. Single Zone

If you administer multiple sites, you can either:

Repeat the same Firewall Rule per zone, or
Use IP Access Rules or Account-level WAF (available on certain plans) to apply country-based actions across all zones.

Option B: Automate with the Cloudflare API

Create a firewall rule via API for repeatable deployments or CI/CD.

1) Create a Filter

The post Blocking or Allowing entire countries in Cloudflare appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Locking down UAT Environments

Anuj Varma — Wed, 17 Sep 2025 14:48:53 +0000

Locking Down UAT Egress: What to Whitelist for External APIs

When your UAT environment needs to call third-party APIs, give it only the network access it truly needs — nothing more. This checklist and the sample rules help you keep UAT safe, compliant, and predictable.

UAT
Egress
Zero Trust
Firewall
API Security

Quick Checklist: What to Whitelist

Item	Examples	Notes
Primary API domains	`api.stripe.com`, `graph.microsoft.com`, `api.sendgrid.com`	Prefer FQDN allow-lists. If vendor provides IP ranges, subscribe to their feed but expect changes.
Auth/token endpoints	`login.microsoftonline.com`, `oauth2.googleapis.com`	Many APIs require separate OAuth hosts. Don’t forget device code or JWKS endpoints if applicable.
Supporting services	Vendor CDNs (`*.cloudfront.net`), telemetry (`dc.services.visualstudio.com`)	Only if strictly required by the SDK. Block generic wildcards where possible.
Ports & protocols	`tcp/443` (HTTPS)	Deny `80`, `25`, `22` unless explicitly needed. Enforce TLS1.2+.
DNS resolution	Resolver: internal or approved forwarder	Restrict DNS so UAT can’t resolve arbitrary domains. Log queries.
Outbound identity	UAT API keys, UAT OAuth apps	Never reuse prod secrets. Store in a vault. Rotate regularly.
Egress source IPs	NAT gateway / firewall public IPs	Pin vendor allow-lists to these IPs. Keep UAT egress distinct from prod.
Quotas & rate limits	Per-destination throttling	Prevents runaway tests from DDoS’ing a vendor or incurring costs.

Principle: Deny by default. Explicitly allow only the exact FQDNs and ports your UAT calls need. Log every egress connection; alert on anything outside the list.

Architecture Patterns

1) Egress via NAT/Firewall + FQDN Rules

All UAT subnets route 0.0.0.0/0 to a centralized egress (NAT/Firewall).
Firewall policy allows only HTTPS to approved FQDNs.
DNS resolution flows through an internal resolver you control/log.

2) Explicit Web Proxy

UAT workloads are forced to use an authenticated proxy.
Proxy enforces domain allow-lists and injects identity headers only where required.
Single choke point for content filtering, TLS inspection (where permitted), and logging.

Sample Rules

Azure: Firewall Policy (FQDN-based)

{
  "ruleCollectionGroups": [{
    "name": "uat-egress",
    "priority": 200,
    "ruleCollections": [{
      "name": "allow-apis",
      "priority": 100,
      "action": { "type": "Allow" },
      "rules": [{
        "name": "allow-stripe",
        "ruleType": "ApplicationRule",
        "protocols": [{ "protocolType": "Https", "port": 443 }],
        "sourceAddresses": ["10.20.0.0/16"],
        "targetFqdns": ["api.stripe.com"]
      },{
        "name": "allow-msft-graph",
        "ruleType": "ApplicationRule",
        "protocols": [{ "protocolType": "Https", "port": 443 }],
        "sourceAddresses": ["10.20.0.0/16"],
        "targetFqdns": ["graph.microsoft.com", "login.microsoftonline.com"]
      }]
    },{
      "name": "deny-all",
      "priority": 900,
      "action": { "type": "Deny" },
      "rules": [{
        "name": "block-rest",
        "ruleType": "ApplicationRule",
        "protocols": [{ "protocolType": "Http", "port": 80 }, { "protocolType": "Https", "port": 443 }],
        "sourceAddresses": ["10.20.0.0/16"],
        "targetFqdns": ["*"]
      }]
    }]
  }]
}

AWS: VPC + Security Group (egress tighten)

Security Groups don’t support FQDNs; pair them with a NAT Gateway + Network Firewall for domain rules. At minimum, restrict SG egress to 443 and route through the firewall.

# Security Group (egress only to 443)
aws ec2 authorize-security-group-egress \
  --group-id sg-XXXX \
  --ip-permissions '[
    {"IpProtocol":"tcp","FromPort":443,"ToPort":443,"IpRanges":[{"CidrIp":"0.0.0.0/0"}]}
  ]'

# AWS Network Firewall (domain list) snippet via Suricata-style rules
pass tls $HOME_NET any -> $EXTERNAL_NET 443 (tls.sni; content:"api.stripe.com"; endswith; msg:"allow stripe"; sid:100001;)
pass tls $HOME_NET any -> $EXTERNAL_NET 443 (tls.sni; content:"graph.microsoft.com"; endswith; msg:"allow graph"; sid:100002;)
drop tls $HOME_NET any -> $EXTERNAL_NET 443 (msg:"deny unknown domains"; sid:199999;)

Proxy (Squid) Domain Allow-List

# /etc/squid/whitelist.txt
api.stripe.com
graph.microsoft.com
login.microsoftonline.com

# /etc/squid/squid.conf (excerpt)
acl allowed dstdomain "/etc/squid/whitelist.txt"
http_access allow allowed
http_access deny all
acl HTTPS_ports port 443
acl CONNECT method CONNECT
http_access allow CONNECT HTTPS_ports

Operational Controls

Separate UAT credentials: distinct OAuth apps/API keys from prod; scope to least privilege.
Secret handling: use a vault; never embed in code or images. Rotate regularly.
DNS controls: internal resolver, logging, and (optionally) domain filtering.
Monitoring: centralize egress logs; alert on connections to non-approved hosts.
Change management: any new third-party API requires a ticketed update to the allow-list.
Rate limiting: throttle UAT to avoid vendor abuse and surprise bills.
Segregation: different egress IPs and rulesets for UAT vs prod; no shared service accounts.

Summary

Deny by default, allow the exact FQDNs and ports your tests need, and log everything. Pair tight network policy with proper identity, secret hygiene, and rate limits. UAT stays useful for testing — without becoming an easy path for data leaks or lateral movement.

The post Locking down UAT Environments appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.