Le lundi 14 novembre 2011 à 15:43 -0600, -Hammer- a écrit : > There really is no winner or "right way" on this thread. In IPv4 as a > security guy we have often implemented NAT as an extra layer of > obfuscation. In IPv6, that option really isn't there. So it's a cultural > change for me. I'm not shedding any tears. We've talked to our FW > vendors about various 6to6 and 4to6/6to4 options and we may consider it > but given the push in the IPv6 community for native addressing I really > am hesitant to add NAT functionality given that no one really knows what > the IPv6 future holds.
I consider that a good way of looking a things. ;) Cheers, mh > > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > On 11/14/2011 02:55 PM, Jay Ashworth wrote: > > Kill this subject if you're sick of it. > > > > ----- Original Message ----- > > > >> From: "Gabriel McCall"<gabriel.mcc...@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 > >> host. > >> > > > >> 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 > > other ports. > > > > Cheers, > > -- jra > >
