Re: NAT vs. True Firewalls

From: William Stacey (
Date: 03/08/02

From: "William Stacey" <>
Date: Thu, 7 Mar 2002 21:14:21 -0500

Thanks Jamie. Nice direct answer. Have not seen one of those in awhile.
However, I did get 'kooties' once, even with circles and dots drawn on arms
1) Anyway, your first answer is right on, and IMHO, the most relevant. If
you port forward, that is it. The NAT (by itself) does no other filtering
or inspection - that is the grey goose.
2) Your second one I did not follow. "Second, and a bit more of
general concern, if a would be intruder has, or can gain, access to other
hosts on your NAT's segment, the intruder can masq (or spoof) packets to
appear to originate from within your NATs private segment"
If an intruder gets on the a host on the DMZ (lets say) they can masq
packets to appear as originating from private side? Could you provide an
example to illustrate that? Do you mean something like; ping a host on
public NAT side that is mapped to private IP and make source IP a private
one - now reply will go to other private host, not come back to real source
(i.e. DOS attack ?)
3) "but it could be easily compromised depending on the rule sets you
Yes, but that is true of any security measure. Only as good as the rules
you define and enforce.

Thanks for the info Jamie.

William Stacey, MCSE

"Jamie Beverly" <> wrote in message news:jCTh8.88739$ > > "William Stacey" <> wrote in message > > > Funny, I just had this discussion on a UNIX ng. In my view, a Firewall > does > > not just mean packet filter. A firewall can be made up of one or more > > components that can block or filter protocol traffic between two networks. > > OReilly's "Building Internet Firewalls" says a firewall is "A component or > > set of components that restricts access between a protected network and > the > > Internet." So a NAT can be as much part of a firewall implementation as > the > > packet filter. By this definition, a firewall can contain either a packet > > filter or NAT or both (or other current or future component.) > > > > I think the confusion is what type of NAT are we talking about - simple > NAT > > or NAT with stateful inspection? More UNIX people think of NAT in terms > of > > a simple NAT on a router. Most Windows people are familiar with stateful > > NATs such as the one in w2k's RRAS and Winroute, etc. Both of these > > products, for example, are secure. By default they will not allow any > > traffic to flow passed the NAT router unless you define a port map to > allow > > it. IMO, they do protect the LAN behind them. How do they not? Any > > examples? Specific weaknesses in an implementation (I don't know of any > in > > winroute's or RRAS NAT off top of my head, but I am sure they exist) is > > different. However the concept is as strong as you can get. > > Winroute and RRAS both provide firewall functions, such as packet inspection > and filtering, hence are more than a statefull NAT. > However, to answer your question, there are two possibilities for intrusion > with a statefull nat with no packet filtering whatsoever, ignoring > vulnerabilites of the NAT itself. First, if you port-forward to any service > inside the NAT, and that service has security vulnerabilities, a NAT on its > own provides no means to disallow suspect packets. Second, and a bit more of > general concern, if a would be intruder has, or can gain, access to other > hosts on your NAT's segment, the intruder can masq (or spoof) packets to > appear to originate from within your NATs private segment. A firewall allows > you to specify rules like if a rfc1918 address comes in on the external > iface, drop it on the floor. > > > > > > They do not, however, provide any filtering or protection for the public > > interface/IP they are NATing. For this, you will still need a packet > > filter/firewall. So when you say "a NAT has nothing to do with security > but > > exists to provide more IP addresses", I would tend to disagree with the > > first part because many people are using stateful NAT for both those > > reasons - security and public IP sharing. Look forward to your reply. I > > would like to know if NAT with stateful inspection can be compromised as > we > > should all be aware of this. > > I agree with your statement that many people are using NATs alone for > security. People have also been known to draw a series of circles and dots > on their arms to prevent 'kooties.' Yes a NAT with statefull inspection is > more difficult to comprimise, as it is actualy a simple firewall (statefull > inspection is a firewalling technology) but it could be easily comprimised > depending on the rule sets you define. > > > > Cheers! > > > > -- > > William Stacey, MCSE > > > > > > >

Relevant Pages

  • Re: NAT vs. True Firewalls
    ... The NAT does no other filtering ... >>> not just mean packet filter. ... >>> or NAT with stateful inspection? ... >> and filtering, hence are more than a statefull NAT. ...
  • Re: ipfw/nated stateful rules example
    ... And still does not prove stateful rules work on ... stateful rules don't play nice with NAT. ... > rule, but it accepts the packet and packet processing stops, so it's never ... ipfw add 10 deny ip from to any in via ep0 ...
  • Re: Egress filtering
    ... > packet only with the public IP of the firewall address. ... > The ipfilter has drop/log packet before NAT. ... That is it does filtering before NAT ...
  • Re: WinRoute Pro
    ... the NAT table for I believe. ... packet logging shows some nice information but other times the ... when the connection is torn down from the client side ...
  • Re: RRAS Win2003: Cannot reach public IP reserved hosts behind our NAT
    ... From within our intranet we can access the machines by> their private addresses just fine, as these packets are not> routed to our RRAS box. ... The role of the IP# in Ethernet is only to provide a Layer3 routing> mechanism and to provide a means to resolve the MAC address. ... The> reason intranet host must use the private addresses to access the servers is> because NAT can't make "u-turns". ... When you send a packet to the external> IP# the "NAT" process takes it and creates a situation where the source and> destination MAC addresses in the packet headers are the same address. ...