2017-10-12
I'm looking forward to using systemd's new IP access control features
These days, my reaction to hearing about new systemd features is usually somewhere between indifference and irritation (I'm going to avoid giving examples, for various reasons). The new IP access lists feature is a rare exception; as a sysadmin, I'm actually reasonably enthused about it. What makes systemd's version of IP access restrictions special and interesting is that they can be be imposed per service, not just globally (and socket units having different IP access restrictions than the service implementing them adds extra possibilities).
As a sysadmin, I not infrequently deal with services that either use random ports by default (such as many NFS related programs) or which have an irritating habit of opening up 'control' ports that provide extra access to themselves (looking at what processes are listening on what ports on a typical modern machine can be eye-opening and alarming, especially since many programs don't document their port usage). Dealing with this with general iptables rules is generally too much work to be worth it, even when things don't go wrong; you have to chase down programs, try to configure some of them to use specific ports, hope that the other ports you're blocking are fixed and aren't going to change, and so on.
Because systemd can do these IP access controls on a per service
basis, it promises a way out from all of this hassle. With per-service
IP access controls, I can easily configure my NFS services so that
regardless of what ports they decide to wander off and use, they're
only going to be accessible to our NFS clients (or servers, for
client machines). Other services can be locked down so that even
if they go wild and decide to open up random control ports, nothing
is going to happen because no one can talk to them. And the ability
to set separate IP access controls on .socket units and .service
units opens up the possibility of doing something close to per-port
access control for specific services. CUPS already uses socket
activation on our Ubuntu 16.04 machines, so we could configure the
IPP
port to be generally accessible but then lock down the CUPS .service
and daemon so we don't have to worry that someday it will sprout
an accessible control port somewhere.
(There are also uses for denying outbound traffic to some or many destinations but only for some services. This is much harder to do with iptables, and sometimes not possible at all.)