Hello Guido,
On Fri, 7 Mar 2025, Guido Trentalancia wrote:
> The support for hostname-based rules (including multiple resolutions of
> an hostname) has been there at least since the following commit:
>
> commit 2ad8dc895ec28a173c629c695c2e11c41b625b6e
> Date: Mon Feb 21 19:10:10 2011 -0500
>
> but probably much earlier, so it's been there for more than 20 years !
>
> Security (and software in general) should not be viewed in absolutistic
> terms, I believe, which is why software has features and options, it
> depends on different circumstances, if an option is there, the user has
> the choice on whether it needs it or not, on whether is convenient or
> not, on whether is safe or not.
>
> It's just a very simple patch to improve an existing feature. It's up
> to you whether to merge it or not, I can't add much more to this
> discussion at this point because it's just looping...
Yes, because it seems you assume hostnames are stored in the iptables
rules when it's not. When the rule is entered, hostnames are resolved
*once* to IP addresses, and the rules with the IP addresses are
transferred to the kernel and used there. Simple example:
# iptables -A FORWARD -d smtp.google.com -j ACCEPT
Does it mean it's a single rule in the kernel with the hostname
smtp.google.com? No, not at all:
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere eg-in-f26.1e100.net
ACCEPT all -- anywhere ef-in-f26.1e100.net
ACCEPT all -- anywhere ed-in-f27.1e100.net
ACCEPT all -- anywhere ef-in-f27.1e100.net
ACCEPT all -- anywhere eg-in-f27.1e100.net
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
At the time when the command was entered smtp.google.com could be resolved
into five IPv4 addresses and that resulted not a single rule with a
hostname, but five rules with IP addresses. The "iptables -L" simply
translates back the IP addresses to the corresponding names in the DNS.
If the name resolution of smtp.google.com *changes* after the rule was
entered, it has no effect whatsoever.
Hostnames in iptables/nftables rules should be avoided, especially for
dynamically changed hostnames.
Best regards,
Jozsef
> On Fri, 07/03/2025 at 21.48 +0100, Reindl Harald wrote:
> >
> > Am 07.03.25 um 21:37 schrieb Guido Trentalancia:
> > > Apart from the case of DNS Round-robin, quite often an hostname
> > > (for
> > > example, a server hostname) is DNS-mapped to a static IP address,
> > > but
> > > over the time (several months or years) that IP address might
> > > change,
> > > even though it's still statically mapped.
> > >
> > > In that case, if a client behind an iptables packet filter does not
> > > use
> > > hostname-based rules, it won't be able to connect to that server
> > > anymore.
> > >
> > > So, there are cases where hostname-based rules give an advantage.
> >
> > sorry, but hostanme based access lists are even on a webserver a bad
> > idea and on a packet filter it's unacceptable
> >
> > if a host changes it's IP rules have to be adjusted - it's as simple
> > as
> > that for the past 20 years in networking and will continue so the
> > next
> > 20 years
> >
> > ------------
> >
> > and frankly if a service partner can't assign a static IP it's the
> > wrong
> > partner to begin with - we are talking about security
> >
> > either you have a static ip or there is a vpn-tunnel with
> > certificates
> > done within seconds with wireguard - the dynamic host is the one to
> > build up the tunnel, case closed
>
>
--
E-mail : kadlec@xxxxxxxxxxxxx, kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxx
Address: Wigner Research Centre for Physics
H-1525 Budapest 114, POB. 49, Hungary
