On 2/16/24 5:05 PM, William Herrin wrote:
On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas <m...@mtcc.com> wrote:
If you know which subnets need to be NAT'd don't you also know which
ones shouldn't exposed to incoming connections (or conversely, which
should be permitted)? It seems to me that all you're doing is moving
around where that knowledge is stored? Ie, DHCP so it can give it
private address rather than at the firewall knowing which subnets not to
allow access? Yes, DHCP can be easily configured to make everything
private, but DHCP for static reachable addresses is pretty handy too.
Hi Mike,
Suppose I have a firewall at 2602:815:6000::1 with an internal network
of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a
switch that accepts telnet connections with a user/password of
admin/admin. On the firewall, I program it to disallow all Internet
packets to 2602:815:6001::/64 that are not part of an established
connection.
Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.
Now, I make a mistake on my firewall. I insert a rule intended to
allow packets outbound from 2602:815:6001::4 but I fat-finger it and
so it allows them inbound to that address instead. Someone tries to
telnet to 2602:815:6001::4. What happens? Hacked.
Yes, but if the DHCP database has a mistake it's pretty much the same
situation since it could be numbered with a public address. For both you
can have the default as "reject" or "accept" -- that's just a default
and depends on how you want to manage your network.
NAT is not without its own set of problems, so if this boils down to a
subnet management issue there are obviously ways to deal with that to
avoid NAT's problems. Both DHCP and firewall configs don't have to be
the ultimate source of truth about any of this. And that's likely a Good
Thing since you want them to be pretty much as fungible and replaceable
as possible. If you're exposed to fat fingers for either, you're
probably already in trouble. Something in the management plain is far
more likely to care about this kind of thing than hardware vendors who
see that as a cost center with predictably shitty implementations.
Mike
