[svlug] NAT !~ DHCP, comparing NAT to Masquerading to Firewalls -- Re: Routing Software

Bryan -TheBS- Smith thebs at theseus.com
Wed May 10 10:59:57 PDT 2000


On Wed, 10 May 2000, Andy Hilal wrote:
> I'd prefer NAT to DHCP, just because it seems to be 
> simpler for the Mac/Win clients to have one fixed
> (if phony) IP address than to get a dynamic one each time.

NAT !~ DHCP ...

Er, I think you are comparing apples and oranges here.  NAT is a
many to one translation/filter.  DHCP is a IP address issuing
protocol.

Although you could simply NAT all private subnets to accomodate
any box (therefore accomodating any private IP any system may be
using), that is irrespective of whether or not you use static or
DHCP assigned IPs anyway.  I always set up a DHCP block for each
subnet regardless (usually using high numbers in the last octet,
which most people never seem to use).

NAT vs. Masquerading ...

BTW, from my understanding, NAT is just IP translation that does
not do any filtering and forwards/receives everything nasty. 
Masquerading is more complex, which can add basic filtering, but
breaks a lot of sessions (which can be worked around with
additional support and configurations).

Given that difference let's look at what common black box as
well as common OSes do (please correct me where necessary) ...

Windows 98 Internet Connection Sharing:  NAT-only (NO filtering)
Windows NT Wolfpack Routing:  NAT-only or w/some masq/filtering?
Linux 2.0:  Masquerading with some filtering (IPMasq)
          + separate Firewalling and advanced filtering (IPFW)
Linux 2.2:  NAT + Masquerading/Filtering incl optional
            firewall and TOS packet filtering (IPChains)
FreeBSD 2/3/4:  NAT with NO (or basic) filtering (NATd)
          + separate Firewalling and filtering (IPFW)
Black Box Modem/Cable/DSL Firewalls/Routers: 
          Various methods from NON-filtering NAT devices
          (*WRONGLY* marketed as IP firewalls) to full
          blown ICSA-certified, low-cost boxes (e.g.,
          SonicWall)

Again, many people think NAT protects them.  It does NOT.  Even
though the packets on the network use private IPs, you can still
scan them.  That's exactly what one sysadmin did with our SV office
(which has been since corrected by me ;-), the public IP traffic
and private IP traffic were going over the same Ethernet wire (and
just used NT/Wolfpack on the network to do NAT).

> I haven't purchased the Linux box yet, so any distributions with 
> bundled tools would be good to know of.

Most people I talk to and work with on using Linux 2.2's IPChains
instantly become frustrated with the level of configuration
required to get various protocols/ports, mainly on-line gaming and
other programs, to work.  Instead, they go buy a box that
"magically" works out of the box (or a few have even used FreeBSD's
basic NAT daemon instead of dealing with Linux's IPChains).

What they do not realize is that Linux's built-in filtering deals
with many more security holes by default and just needs to be
tinkered to allow though what you want.  In the case of using those
boxes, a lot of poorly designed protocols are let through a lot of
crap you don't want.  Sure, they block the NetBIOS/SMB ports, but
there is still a lot than can get through.

Security is always an easy versus capability issue.

-- TheBS 

P.S.  If you haven't guessed, I'm not an expert on understanding
everything here.  I've only been doing IPChains for ~12 months
(shortly after 2.2.5 and RedHat 6.0 came out) and it hasn't been a
serious effort either.

-- 
 Bryan "TheBS" Smith -- Engineer, IT Professional and Hacker
      E-mail:  mailto:thebs at theseus.com,b.j.smith at ieee.org
  Disclaimer:  http://www.SmithConcepts.com/legal.html
*************************************************************
  TheBS ... Serving E-mail filters to /dev/null since 1989






More information about the svlug mailing list