[arin-ppml] IPv6 Non-connected networks

[Chris Engel]

Michael K. Smith wrote:

> I'm not sure I understand how NAT fixes this any more than
> properly applied firewall rules would.  If I want to block
> incoming traffic or, more specifically, only allow specific
> traffic to and through an IP address, I can do that as
> readily with an ACL as I can with the inclusion of a static
> mapping.  I appreciate your belief that NAT helps limit
> operator error, but using any technology in replacement of
> proper policies in procedures is not a good idea, security or no.

Michael,

I certainly don't consider NAT as a replacement for good policies and procedures. It's usefull as an adjunct for them to provide a bit of a safety net when things aren't setup as they should have been.


> Me: "Hi, we just got scanned/DDOS'd/spammed from <your PAT
> address> at 1:00 local"
> You: "Wow, that's when everybody got back from lunch, so it
> will take me
> a month to go through the translation logs to       find out how sent
> that traffic."
> Me: Plonk


Yeah...there is a trade off here....as there is with pretty much every other implimentation of technology. Personaly I don't think it should be that difficult to search through a set of logs to find some troublesome traffic if you know the destination address...the rough time and something about the nature of the traffic.... at least if you have decent logging software... I mean it's not like the Admin needs to search through each line by hand... how difficult is typing into a filter "destination address = (whatever address got hit), time frame = 12:30 - 1:30 " and hitting enter?


> No, that would be an improperly applied ACL.  If you want to
> block traffic to an address, block that traffic.  Again, it's
> a matter of proper procedure.  Your compensating control is
> in the verification that a policy was applied correctly.

Michael,

I'm all for audits...but they tend to catch things at some point after the problem has occured. So unless you are having a 2nd Engineer go through and verify every piece of work that one of your Engineers does immediately after he does it... then it's not a replacement for NAT. If you have that kind of spare man-power to devote...then god bless you... and are you hiring?
Most orginizations I know can't afford to do anything remotely close to that.

You are right that procedure is very, very important and so is verifying what you do. I don't know about you...but I know that I personaly have been guilty of setting some configuration, staring at it to make sure I had it right, remember triple checking it....and still come back the next day to find that I had done something wrong...even though at the time things seemed to be working as I thought they should. Some-times the mind and eyes do strange things at the end of an 18 hour shift.


> That's certainly one opinion.  As with any technology NAT is
> like any other, with good and bad characteristics.  One of
> the main issues is that NAT is used ubiquitously in almost
> all consumer devices and touted as a panacea for keeping out
> the bad guys.  The number of bad guys that get in due to
> uninitiated outside traffic pales in comparison to the number
> who are invited in by the user through an application-based vector.

Well, I'm right there with you with in tearing apart the guys that tout NAT as a panacea solution. In my book those guys are as bad or worse as the ones that claim NAT has absolutely no value. NAT is just one tool in our toolkit. Sometimes is a good fit to be deployed in the package of tools we deploy to secure an environment....other times not. I would never rely on it in isolution of other tools.... but it CAN help as one supporting piece in the overall structure we build.




Christopher Engel