-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
resolved: DNS access control and DNS controlled firewalling #17053
Description
Is your feature request related to a problem? Please describe.
It's difficult to make useful firewalls based on filtering IP addresses since the internet operates on DNS domain names but the firewalls actually operate on IP addresses. In simple, static cases it could be possible to resolve the DNS addresses only once at resolver startup (boot etc), but not in general. Especially statically resolving domain names for address pools (e.g. pool.ntp.org) at resolver startup would not work as the DNS servers may give a different address each time the name is resolved.
Describe the solution you'd like
There are two parts in this idea.
- Introduce access control for DNS requests for
systemd-resolved, i.e. resolve only domains approved for the requesting service. For example,systemd-timesyncd.servicecould be allowed to resolve only*.pool.ntp.org, but notfacebook.com(infected service trying to check instructions from botnet C2). - Control firewall tables based on the DNS requests received by
systemd-resolved. As an example for NTP, initially deny all outgoing NTP port access. After a request fromsystemd-timesyncd.serviceforpool.ntp.orghas been resolved to an IP address (but before the DNS reply is given back to caller), update the firewall to allow access for NTP for this IP address. The firewall rules would be removed automatically later based on selected conditions.
Typical firewalls only enforce global rules for the whole system but with SELinux, it's possible to create firewall rules which use SELinux labels (SELinux networking support). Thus optionally systemd-resolved could let SELinux label ntpd_t (systemd-timesyncd.service) to access NTP ports of pool.ntp.org but deny NTP to other services, or allow APT (Debian package tool) to access debian.org but not botnet.org with HTTPS.
For 1., systemd-resolved would need to positively identify the service and for SELinux option of 2., the label of the process making the request (with SO_PEERSEC).
The removal logic probably needs to be selected per service. For some services which resolve the server address only once, or always resolve the address before starting the connection, it would be enough to purge previous firewall entries once there's a new request. Some others may look up several host names and use all of them, so the logic should be to keep the addresses, maybe with configurable timeout.
The benefit would be more secure services and much tighter firewalls. 1. would implement simple DNS based access control for services. It would not block accesses with hard coded IP values. 2. would tighten 1. so that even known IP addresses would be blocked, unless a DNS request (subject to rules of 1.) was made in advance.
Part 1. would be already useful without 2.