Great Circle Associates Firewalls
(December 1997)

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: RE: configuring Ciscos' As proxy
From: Ted Mittelstaedt <tedm @ portsoft . com>
Date: Mon, 29 Dec 1997 18:14:14 -0800
To: Ted Mittelstaedt <tedm @ portsoft . com>, Alan Strassberg <alan @ wj . com>, "'Fyodor'" <fygrave @ freenet . bishkek . su>, "'Randall Kizer'" <rkizer @ guten . sddpc . org>
Cc: "firewalls @ GreatCircle . COM" <firewalls @ GreatCircle . COM>

From:  Randall Kizer[SMTP:rkizer @
 guten .
 sddpc .
Sent:  Wednesday, December 24, 1997 8:09 AM
To:  Ted Mittelstaedt; Alan Strassberg; 'Fyodor'
Cc:  firewalls @
 GreatCircle .
Subject:  RE: configuring Ciscos' As proxy

Your comments regarding NAT may be true, but there is a problem I've seen
regarding many of these don't have enough visibility as to
what is happening within your network.  Since ~75% of all security breaches
occur from within, you also need to have some visibility as to what has
been transported..."was that our shadowed password file I just saw ftp'd
offsite?".    This is an example of a significant problem - someone using
an authorized session to perform unauthorized activities.  Was the person
who just performed that ftp authorized to even access that file?

This is IMHO more of an organizational structural problem than a technical problem.  It's kind of like the old line "treat your employees with respect and they will treat you the same, screw them and they will screw you"

I'm sure that everyone has heard this before but it is simply not possible to protect a workplace against inside penetration, unless you just don't trust anyone with anything.  Certainly some workplaces are like this - like banks - where you have a lot of low-paid people working next to a ton of cash.  However, if they are going to be so horrible as to ftp out a shadow password file, well then putting a network firewall into place is hopeless.  They are just going to copy it off to a floppy or some other thing.  I pity the folks that have to work in an environment like that.  (academics aside - students will usually try to take an arm if you give them a finger, it's just the nature of the beast)  

If you are already using DHCP and are still seriously constrained for IP
addresses, then I could see a need to go the NAT route.  And I certainly
wouldn't go NAT unless I've already converted to DHCP --- anyone who's
tried changing their internal IP addresses for NAT over a weekend on 24/7
production systems know what I'm talking about.

Not true - commercial NATS will convert from a legal range to a legal range and do all the DNS trickery to allow you to stomp other people's address ranges with impunity.

At any rate, it seems to me you are mixing reasoning for running RFC-unassigned-vs-legal numbers with reasoning for running proxy-vs-NAT.

As far as address constrained goes - well that's the future.  Connect to any ISP today and your lucky to get a subnet of a Class C, let alone the entire range.  And, the thought of getting a full B or A range is even more unbelievable.  Using all legal addresses inside is now only the luxury of the people who already have large blocks of legals from years ago.

NAT's for the most part appear to have their greatest advantages in helping
organizations bridge the gap between IPv4 and IPv6.  Again, there are
always requirements which can drive you to make a major change in your
network like NAT.

Besides this, which is a very important one, another benefit is being able to change ISP's without weeks of downtime.  With the competition in ISP's heating up it pays to continuously review Internet connectivity the same as you do long distance.  Internet service is becoming a commodity item.

Proxies may be labor intensive, but they also allow you to see what's
happening in the data streams - a trend I see with most intruders is to
exploit a legitimate session with files, programs, etc. which exploit other
weaknesses.  I prefer to see the whole picture, and not just the IP headers.

It's a tradeoff that is appropriate for some networks, not good for others.  My beef is mainly with people that advocate one solution as the only right one.  I don't care for proxies myself because for the networks I've admined they represent a lot of work with no payoff.  (I don't think I'd be happy bringing connectivity to networks where a proxy would be required)  I don't care much for the FWTK documentation because it appears to ignore NAT and advocate proxies as the only "right" solution.


Indexed By Date Previous: RE: off topic: ssl setup on web server inside firewall
From: Joseph Judge <joej @ ma . ultranet . com>
Next: RE: configuring Ciscos' As proxy
From: Ted Mittelstaedt <tedm @ portsoft . com>
Indexed By Thread Previous: RE: configuring Ciscos' As proxy
From: Ted Mittelstaedt <tedm @ portsoft . com>
Next: RE: configuring Ciscos' As proxy
From: Ted Mittelstaedt <tedm @ portsoft . com>

Search Internet Search