Well, give the junky little NAT boxes their due.  Grubby little home networks running windoze on one or a few computers cause a lot less trouble in the world when there is a junky little NAT box between the house LAN and the big world outside.  Better ways to do it?  Absolutely!  Easier, cheaper and more widely methods that at least squelch a good bit of the crap?  Maybe not...
<br><br>
<div><span class="gmail_quote">On 6/4/07, <b class="gmail_sendername">Donald Stahl</b> <<a href="mailto:don@calis.blacksun.org">don@calis.blacksun.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>> Also, it is good to control the Internet addressable devices on your network<br>> by putting them behind a NAT device. That way you have less devices to
<br>> concern yourself about that are directly addressable when they most likely<br>> need not be. You can argue that you can do the same with a firewall and a<br>> default deny policy but it's a hell of a lot easier to sneak packets past a
<br>> firewall when you have a directly addressable target behind it than when<br>> it's all anonymous because it's NATed and the real boxes are on RFC1918.<br>This is patently untrue. Using a firewall such as CheckPoint, which
<br>integrates NAT into the object definition, makes it just as likely to<br>accidentally allow traffic to a NAT'd address as it does a real address.<br>Either you are allowing access to the _object_ or you are not.<br>
<br>If you start messing with the NAT table directly then you open up another<br>can of worms- namely additional complexity and a greater opportunity for<br>mistakes.<br><br>> So really, those who do not think there is a security gain from NATing don't
<br>> see the big picture.<br>We see the big picture- we see applications with a ton of extra code to<br>handle NAT- code that may contain mistakes and end up being compromised.<br><br>We see firewalls that need more code to handle NAT'd applications- code
<br>that contains mistakes and can be compromised.<br><br>We see firewall rule sets that are more complicated and make less than if<br>NAT were not involved.<br><br>We see security/performance problems that are harder to troubleshoot
<br>because we have to dig through a NAT table to figure out which connection<br>is which.<br><br>Keep it simple. NAT is a terrible terrible hack- and it's sad that it's<br>become so accepted in the maintsream.<br>
<br>-Don<br></blockquote></div><br>