Kill this subject if you're sick of it.
From: "Gabriel McCall" <Gabriel.McCall@thyssenkrupp.com>
If your firewall is working
properly, then having public addresses behind it is no less secure
than private. And if your firewall is not working properly, then
having private addresses behind it is no more secure than public.
This assertion is frequently made -- it was made a couple other times
this morning -- but I continue to think that it doesn't hold much water,
primarly because it doesn't take into account *the probability of various
potential failure modes in a firewall*.
The basic assertion made by proponents of this theory, when analyzed,
amounts to "the probability that a firewall between a publicly routable
internal network and the internet will fail in such a fashion as to pass
packets addressed to internal machines is of the same close order as the
probability that a DNAT router will fail in such a fashion as to allow
people outside it to address packets to *arbitrary* internal machine IP
addresses (assuming they have any way to determine what those are)."
Hopefully, my rephrasing makes it clearer why those of us who believe that
there is, in fact, *some* extra security contributed by RFC 1918 and DNAT
in the over all stack tend not to buy the arguments of those who say that
in fact, it contributes none: they never show their work, so we cannot
evaluate their assertions.
But in fact, as someone pointed out this morning in the original thread:
even if you happen to *know* the internal 1918 IP of the NATted target,
the default failure mode of the NAT box is "stop forwarding packets into
private network at all".
Certainly, individual NAT boxes can have other failure modes, but each of
those extra layers adds at least another 0 to the probability p-number,
in my not-a-mathematician estimation.
On the other hand, since a firewall's job is to stop packets you don't want,
if it stops doing it's just as a firewall, it's likely to keep on doing it's
other job: passing packets. It certainly depends on the fundamental design
of the firewall, which I can't speak to generally... but you proponents of
"NAT contributes no security" can't, either.
That makes sense, but I'm wondering if that should be considered correct
behavior. Obviously a non-consumer grade router can have rules defining
what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
everything coming from the outside in to either a) match up with
something in the translation table, b) be a service the router itself is hosting
(http, etc), or c) be a port it explicitly forwards to the same inside
Anything not matching one of those 3 categories you'd think could be
dropped. Routing without translating ports and addresses seems like
the root of the issue.
It is. And IME, the people who think NAT provides no security rarely if
ever seem to address that aspect of the issue.
And, for what it's worth, I'm discussing the common case: 1-to-many incoming
DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on