Skip to main content

Configuring the upgraded Firewall Rules

With DiscrimiNAT, the Firewall Rules attached to the applications that need filtered access to the Internet can be annotated with a set of allowed FQDNs. This allows creating least privilege egress policies from the protected workload to the Internet.

No need to create VPC-wide allowlists that allow discrete applications within access to what they needn't.

info

DiscrimiNAT's own Firewall Rules need not be altered.

On this page, we cover the syntax for the Cloud-native Firewall Rules' description fields, where the annotations live.

See-Thru mode​

The see-thru mode is a non-blocking configuration that allows one to build an appropriate allowlist upto a specified date. The annotation is added to the description fields of egress rules of the protected applications to-be.

Syntax​

discriminat:see-thru:YYYY-mm-dd

caution

The rule will automatically stop working after the YYYY-mm-dd date.

Examples​

discriminat:see-thru:2021-08-31

discriminat:see-thru:2022-1-1

Such a rule must allow all protocols, all ports and a destination of 0.0.0.0/ with any mask, so could be 0.0.0.0/0, 0.0.0.0/1 or 0.0.0.0/32.

Configuring this mode in the GCP web console would look like this:

In Terraform, it would be along the lines of:

resource "google_compute_firewall" "some-app" {
  name = "monitor-some-app"

  network = var.network

  direction          = "EGRESS"
  destination_ranges = ["0.0.0.0/0"]
  allow {
    protocol = "all"
  }
  target_tags = ["new-app"]

  description = "discriminat:see-thru:2021-08-31"
}

Logs​

The flow logs at logName="projects/<google-cloud project name>/logs/discriminat-flow" in StackDriver will have three additional fields for traffic from any workload that has a Firewall Rule with a see-thru annotation attached:

  1. see_thru_exerted: true when no tls or ssh protocol rules allowed this connection through and it's only because of the see-thru rule that the connection has been let through. false when a tls or ssh protocol rule would otherwise allow this connection through. The rest of the fields in the log line remain as they would without the see-thru rule, hence indicating which tls or ssh protocol rule matched to let this connection through.

  2. see_thru_gid: The Firewall Rule where the enacted see-thru was found.

  3. see_thru_days_remaining: The number of remaining days this rule will continue to work. Runs into negative if the current date goes past the specified date. These log fields are still emitted if a see-thru rule with any date, past or future, remains specified.

TLS and SSH mode​

The tls and ssh modes are a blocking configuration that will only allow FQDNs set out in the allowlist. Destination protocols and FQDNs are added to the description fields of outbound rules of the protected applications.

Syntax​

discriminat:<protocol>:<fqdn>[,<fqdn>]

  • Valid protocols are ssh and tls only.
  • There can be as many FQDNs as you can fit separated by commas. There cannot be whitespace, though.
  • There can be other text leading and trailing this specification, separated by whitespace.
  • All of it is case insensitive.

Examples​

  • DiscrimiNAT:TLS:api.foo.example.com,downloads.example.net
  • DiscrimiNAT:SSH:sftp.txs.example.org,ssh.github.com
  • discriminat:tls:api-v2.example.com discriminat:tls:www.example.org
  • lorem ipsum discriminat:ssh:ssh.github.com,gitlab.com dolor sit amet

Configuring this mode in the GCP web console would look like this:

  • Direction of traffic must be Egress.
  • Targets must be set to Specified target tags. And then specify the same network tags as on the virtual machines that you'd like this firewall rule to be applied to. Precisely like you would anyway.
    info

    At this time, any interest in All instances in the network as a supported target is being collected. Drop us a line to have your say!

  • Destination filter must be set to IP range and the range set to the narrowest you can think of. Now if you don't have anything narrower than 0.0.0.0/0 that is absolutely fine! The firewall takes care of validating the destination IP address of actual packets in many ways, but the firewall rule at the Google Cloud networking and security level must allow the packet to leave the virtual machine at all. We repeat, 0.0.0.0/0 is a safe choice with the DiscrimiNAT Firewall in the way.
  • Under Protocols and ports, only choose tcp and specify exactly one port number. Ranges, multiple ports, other protocols, and so on are not supported.
  • For your typical HTTPS outbound connection, the port number would be 443.
  • A typical SFTP connection has the port number of 22.
  • Multiple Firewall Rules can be associated with the virtual machines with the use of network tags, and they will all be recognised.

In Terraform, this would be along the lines of:

resource "google_compute_firewall" "acme" {
  name = "acme-reports-upload"

  network = var.network

  direction          = "EGRESS"
  destination_ranges = ["0.0.0.0/0"]
  allow {
    protocol = "tcp"
    ports    = ["443"]
  }
  target_tags = ["acme"]

  description = "discriminat:tls:api.acme.com,auth.acme.com,foo.example.com,bar.example.net"
}

Complete Bypass​

If you would like to discuss alternate protocols or know how to completely bypass the DiscrimiNAT whilst still routing traffic, get in touch with our DevSecOps Support to discuss the best option for your use case.