> My point is that the NAT concept is a transport concept. The security only
> results from NAT implementations because/when they need to manage
sessions,
> and what concidence, stateful filtering is based on sessions.
I will admit that the security offered by a NAT solution is as a result of a
design coincidence, not necessarily because of an original intent. However,
that doesn't negate its existence.
> so you configure NAT to map the 10.* class to a global address (1.2.3.10
> for example).
This is where my comment about "modern nat" and Linux's IP masquerading in
particular come in. In Linux, with masquerading, these mappings are not
done on a multi-multi address mapping basis, they are made on a
multi-(source IP + port) to a single source IP with a dynamic port. To
re-state your scenario, if:
a packet comes from 10.0.0.1 to the NAT,
it is sent as being from 1.2.3.4, the address of the nat device, and
assigned a dynamic source port number
> now, when a packet comes from the internet, your NAT will check whether it
> corresponds to a NAT session
The packet must be destined for the NAT itself, and it must be to a specific
port, and (if so configured) be from the address that the original mapping
was to. This establishes a session very similar to a stateful inspector
(except that "intelligent" stateful firewalls often have more options as
well).
> This means NAT should not reject packets just because they are not part of
a
> mapping. As a result, NAT does not filter flow.
How do you mean that the NAT does not filter flow?
> Besides, there is no modern NAT (NAT is NAT). What you are referring to is
> a "suit" [sic] that does both NAT and filtering. so it is a solution that
implements
All the IP masquerading code does is a _modern_ version of NAT.
Old NAT (to me) is internal source IP to dynamic/static external source IP
mapping, on a multi-multi basis.
Modern NATs allow multiple internal source IPs to all be mapped to one
external IP and do so by keeping some state information. This makes the
internal network machines effectively invisible*
* There are still ways to gather some information ... see insecure.org
--
Michael T. Babcock
CTO, FibreSpeed
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
