|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Security gain from NAT
Also, it is good to control the Internet addressable devices on your network by putting them behind a NAT device. That way you have less devices to concern yourself about that are directly addressable when they most likely need not be. You can argue that you can do the same with a firewall and a default deny policy but it's a hell of a lot easier to sneak packets past a firewall when you have a directly addressable target behind it than when it's all anonymous because it's NATed and the real boxes are on RFC1918.This is patently untrue. Using a firewall such as CheckPoint, which integrates NAT into the object definition, makes it just as likely to accidentally allow traffic to a NAT'd address as it does a real address. Either you are allowing access to the _object_ or you are not. If you start messing with the NAT table directly then you open up another can of worms- namely additional complexity and a greater opportunity for mistakes. So really, those who do not think there is a security gain from NATing don't see the big picture.We see the big picture- we see applications with a ton of extra code to handle NAT- code that may contain mistakes and end up being compromised. We see firewalls that need more code to handle NAT'd applications- code that contains mistakes and can be compromised. We see firewall rule sets that are more complicated and make less than if NAT were not involved. We see security/performance problems that are harder to troubleshoot because we have to dig through a NAT table to figure out which connection is which. Keep it simple. NAT is a terrible terrible hack- and it's sad that it's become so accepted in the maintsream. -Don
|