On Thu, 18 Sep 1997, Chris Lonvick wrote:
> Addressing your last question: I do not consider NAT to be a security
> feature. It would be similar to thinking that your house is better
> protected against break-ins because you have the shades and curtains
> closed. In reality, a theif wouldn't know precisely what is inside,
> (until he got in) but he won't be slowed because he can't see inside.
> (Here's the old adage:) Security through obscurity doesn't work.
> I think you're on the right track with your other questions and
> concerns about using NAT in network links.
Chris, you are so right.
The way I like thinking about it is that devices which use NAT
for a security policy are using NAT to enhance the security
policy, but NAT alone is just Network Address Translation and nothing else.
In a nutshell, that NAT device takes away the end-to-end L3 (Layer 3)
knowledge from the client and server, and puts it
in the hands of the NAT device. The Firewall designer
can use this to his/her advantage when designing the technical
implementation of the network security policy.
[thinking off the top of my bald head]
Pure NAT:
Just translate L3 information on the Interfaces.
Pure Packet Filtering:
Apply a L3/L4 security policy based on source and dest. on each
interface.
Packet Filtering on Routers withOUT NAT:
A router's job is to route packets based on its connected
interfaces and IP forwarding table. This alone is a router's job.
Packet filtering sets a finer policy on its job.
The players in the security game (without NAT) are: Interfaces,
IP forwarding table, and Packet filters.
Packet filters apply a policy to those packets when they reach
the interface (or as they leave the Interface) but if you were to
get the packet filter rule wrong,
the router will do its job and route based on the IP forwarding
table and L3 (Network Layer) information of the packet.
**The end to end information is held throughout the L3 path**.
The client end knows the same L3 information as the server end (and so
does every intermediate point at L3) and knew this information when it
sent the packet.
Packet Filtering on Routers with NAT:
A router that has packet filtering and a NAT feature set
differs from the normal packet filtering because the client's
L3 perspective is not the same as the server's L3 view of the
end to end connectivity.
The players are now: Interfaces, NAT feature, IP forwarding table
and Packet filters. The L3 SourceIP and DestIP of the client
and server only have end-to-end context via the NAT device
in the middle.
Without the help of the NAT feature, sourceIP and destIP L3
information would be determined by the client or the server
(the end points). It is at this critical "Intermediate"
point where policy can be set. One could say that NAT technology
can strengthen the policy making at this Intermediate point.
The designer then uses Packet filtering and NAT functions to
implement the network security policy.
A good Network Security designer wants functions that even
go beyond packet filtering and NATs. Stateful packet
inspection, NAT'ing of L3 information held in upper-layers,
secure remote administration of the network device(s), a solid
audit trail and staff to audit events in a timely manner,
blah blah blah...
Nail down the policy, identify technology that fits,
drink coffee and be paranoid. :-)
BIG DISCLAIMER: The designer can ALWAYS set things up wrong
and open large network security holes but that is a given.
I hope that this contributes some food for thought that is
not based on some marketing campaign.
--blast
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\ Tim Keanini | "The limits of my language, /
/ | are the limits of my world." \
\ blast @
broder .
com | --Ludwig Wittgenstein /
\ +================================================/
|Key fingerprint = 7B 68 88 41 A8 74 AB EC F0 37 98 4C 37 F7 40 D6 |
/ PUB KEY: http://www-swiss.ai.mit.edu/~bal/pks-commands.html \
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
References:
|
|
