nettrust: Dynamic Outbound Firewall Authorizer

by do son · March 28, 2022

NetTrust: Dynamic Outbound Firewall Authorizer

NetTrust is a Dynamic Outbound Firewall Authorizer. It uses a DNS as a source of truth to allow/deny outbound requests

Overview

The idea is that we want to grant network access only to networks or hosts that we trust. Trusted networks and hosts are whitelisted in Output Netfilter Hook, while all others are rejected.

To increase security or privacy, we usually want to block outbound traffic to:

Blocked DNS Queries
Direct Network Communication (Static IP, no Query made)

The first item in the list is known as DNS Black hole and is a secure way to narrow down network communication only to trusted domains. However, not all processes (or javascript functions for example) use DNS Queries. There are many who use static IPs to communicate with the outside world. For example, a javascript function could dynamically fetch a list of hosts during render and forward traffic to them. For such a case, DNS Blackholes are worthless.

Firewalls normally allow outbound access to all hosts but restrict inbound access to a selected few

They allow all to the public but filter inbound works well with servers. There we trust the services that we run and we control components in a more strict way

But what happens when we want to filter and increase security on hosts that are not as restricted as servers or on hosts that may do many things, like personal computers. We install packages often, visit different websites which exposes us to different kinds of tracking (telemetries, etc) and risks (hostile apps, bad javascript functions sending traffic to hosts we can not easily stop)

The problem here is is that it is hard to filter all good hosts due to:

a big number of public IPs. The total number of IPv4 addresses may be small for the world, but is really huge to filter it in a list
hosts usually change IPs, which makes the management of a whitelist even harder

A workaround for this issue (up to a way, because as always everything has its weaknesses), is to use DNS for traffic authorization.

DNS Authorizer

DNS Authorizers are normal DNS hosts that we trust a lot. For example, a local DNS service that we have configured to blacklist certain domains, or block all except some domains

With DNS Authorizer we can:

Use them to filter our unwanted domains (most common, needs a list of bad hosts)
Use them to filter in only wanted domains (most secure, needs a lot more work )

By using a DNS Authorizer we have the pros of a DNS Blackhole + easy filtering of IPs. All we need is to block all outbound traffic and then allow only the traffic that DNS answers in the queries

This is how NetTrust works. It is a small dns proxy with Netfilter management capabilities.

In the above diagram, queries are sent to NetTrust, and from there NetTrust forwards them to the DNS Server that either knows the question or has been configured to forward queries.

Once NetTrust receives a query response, it checks if there are any answers (hosts resolved). If there are, it proceeds by updating firewall rules (e.g. nftables) in order to allow network access to the resolved hosts. If there is no answer, or if the answer is 0.0.0.0, no action is taken. In all cases, the dns reply is sent back to the requestor process after a firewall decision has been made (if any).

Authorized hosts TTL

NetTrust by default does not enable TTL on authorized hosts. The max authorized time a host can get is the time that NetTrust runs. Once NetTrust exits gracefully, it will clear the authorized hosts.

We can enable however TTL on authorized hosts. By adding a TTL, NetTrust will allow communication to that host for as long as TTL is set. Once a host is expired and no session is active (see Conntrack section below), it will be removed from the authorized list and will be expected by the process that wants to continue communication to resolve the host via the DNS again.

Conntrack: Session liveness and TTL

All sessions that have TTL enabled will be checked against two rules. The first rule is the TTL itself. If the host has not expired, nothing happens, if it has expired, then conntrack will be checked to ensure that no connection with the specific host is active. If a tuple contains the host, either in the src or dst, then the TTL will be renewed and the host will be checked again in the next expiration. If the host is not part of any conntrack connection, then the host will be removed from the cache and the firewall’s authorized hosts set