[samwillis]

Sure, on desktop.

But for a server app (which you built and manage) where you are only talking to known endpoints everything else should be blocked, but we don’t do it. We all use platforms for our apps where anything we use could be compromised and connect to the outside world!

[323]

> where you are only talking to known endpoint everything else should be blocked

I just realized that neither the Windows Firewall, nor the Linux one (ufw/iptables at least) allow you to block based on domain names. They only allow IP address rules.

[hxtk]

Netfilter (the kernel backend for the deprecated {ip,arp,ip6,eb}tables and the newer nftables) supports allow/deny by ipsets, and you can configure some DNS resolvers such as dnsmasq to populate an ipset from a DNS name.

This has a few issues, though, such as the fact that it is impossible to allow one site but not another if they are both hosted at the same IP address. After all, DNS names are basically just aliases for IP addresses unless the application layer protocol assigns them some semantic meaning (as is the case with HTTP and TLS).

If that matters, you do have to resort to something protocol-aware like an intercepting HTTP proxy that inspects the Subject Name Indicator for TLS traffic or the Host header for plaintext HTTP traffic. Or a regular HTTP proxy, if your application supports that configuration.

[samwillis]

Exactly, there is a technical limitation (I understand why) of only blocking by IP not hostname, if the IP changes it breaks.

Why has this not been solved in the last 50 years? You should be able to block by hostname, it’s how networks are defined.

We are an industry of problem solvers but this one seems to have been ignored.

[mrweasel]

It is solved, Cisco and other firewalls have no issue blocking or allowing based on FQDN.

[toyg]

Some people do it, but the maintenance effort is nontrivial.