Skip to main content

· 9 min read

Welcome Wildcards!​

From v2.8.0, DiscrimiNAT Firewall supports use of wildcards in an FQDN allowlist.

Last updated: January 10, 2025 to incorporate v2.9.0 improvements

tip

If you're in an operations role (SRE, DevOps, etc) the Operation section will be of particular interest to you.

Syntax​

➟ The character _ (or even ? on GCP) may be used to substitute exactly one wild character in an FQDN to be allowed.

➟ Each _ (or ?) character must match one domain name permissible letter. It cannot match zero or more than one characters.

➟ The character * (or %) may be used to substitute any number of characters.

➟ The set of wild characters is from a to z, 0 to 9 and the - (hyphen or minus) only.

➟ The . (period, dot or full stop) character is not included.

➟ You may use any number of wildcards in a single FQDN address (in the allowlist). See examples below.

· 6 min read
lie

It's actually 5 less problems. But that wouldn't have made a catchy title.

The DiscrimiNAT Firewall now integrates with AWS' Gateway Load Balancer. Deploying this version alleviates five distinct problems.

  1. Exfiltration and Command & Control TTPs
  2. Discovery and maintenance of outbound FQDNs' allowlists
  3. High Availability
  4. Load Balancing
  5. Auto Scaling

Read on for more details.

· 8 min read
learning

Test driving the Log4Shell vulnerability with various versions of Java and observing the network egress connections

Log4Shell in a nutshell​

➟ An attacker is able to conduct a completely unauthenticated Remote Code Execution on a publicly-exposed service.

➟ If a JVM-based service (Java, Scala, etc.) is using the log4j logging library (very popular), the service is vulnerable.

➟ A patched version of the log4j library, version 2.15.0, that fixes this issue was released on 06 Dec 2021.

➟ log4j 2.16.0 was released at 13 Dec 22:28 with the following note:

· 10 min read
learning

Identify and protect GitHub Actions' permissible network egress, with leak detection

Story of pipeline nobody would like to see develop a leak.

GitHub Actions Pipeline Leak with Secrets and Snowflake Data

It runs in a self-hosted GitHub Actions Runner, spun up on AWS spot instances by philips-labs' terraform-aws-github-runner, connecting to Snowflake – with 'secrets' stored in GitHub itself.

🏗 we build the normal list of FQDNs such a pipeline accesses when run
🔒 enforce it via the DiscrimiNAT Firewall
🔇 introduce an unobtrusive curl command, like in the Codecov Uploader breach
🚫 see it fail in exfiltrating any data from the CI environment
🔎 detect the attempt in flow logs

· 9 min read
Last updated: Mar 20, 2023

The week before the pentest

The situation is nothing to write home about. C2 malware, supply-chain risk, ransomware, cryptomining, unsolicited telemetry, plaintext protocols across the Internet, escalating data egress charges – you name it – this one unplugged gap in the Cloud, the outbound connections originating from your deployments, keeps on giving (or taking.)

With no human-readable visibility on any egress flows, not much you can do with all those IP addresses in the flow logs. Talk about flying blind. It's time to install a filtering proxy, and Squid is the word on the grapevine.

Let's take a deep-dive 🔎

· 7 min read

Why do we seek IP addresses in the Cloud-first world?

  • Is it the mindset leftover from the bygone era of procured hardware & CIDR blocks?
  • Is it the availability of published IP ranges that makes you want to utilise them?
  • Or is it a hard bit of how the internet works to detach from?

Let's consider the case of Datadog Agent v7.32.3, the endpoint for which, as per official docs, would simply be 7-32-3-app.agent.datadoghq.com. This is the contract Datadog will fulfil, and we shouldn't assume more.

But first, Datadog IP ranges at present...

· 7 min read
learning

A closer look at what data is sent to entropy.ubuntu.com on Cloud instance boot

Routine Test​

At Chaser, we routinely test a variety of real-world setups through the DiscrimiNAT Firewall. It helps keep on top of implementation subtleties by different vendors and identify any regressions early as we improve the product.

FQDN filter for Ubuntu on GCP egress, shall we?

So we fire up Ubuntu Bionic Beaver LTS this time, with egress allowed to 0.0.0.0/0 on all ports.

· 3 min read
learning

Observation of traffic from a Windows Server 2019 instance with a firewall restricting its egress, and a CloudWatch exercise in filtering and aggregation

Routine Test​

At Chaser, we routinely test a variety of real-world setups through the DiscrimiNAT Firewall. It helps keep on top of implementation subtleties by different vendors and identify any regressions early as we improve the product.

FQDN filter for Windows on AWS egress, shall we?

So we fire up the latest and greatest Windows this time, with outbound allowed to 0.0.0.0/0 on all ports.