Re: [TCLUG:10864] IP Masquerading

[Scott Dier - dieman <dieman@ringworld.org>]

On Mon, 6 Dec 1999, Ben Kochie wrote:

> yes, you can with ipchains forward a single port connetion, or an entire
> IP through the masq to the 'inside' network... HOWEVER, this is really bad
> firewall policy.  the linux firewall at my company only allows outgoing

Agreed.  Proper policy would dictate not to do this.

> connections, so that if a service were to have a discovered exploit,
> someone would not be able to get access to a box on the 'inside' of my
> network.

Heh, you have problems with non-secured boxes? :)  run nmap on a weekly or
less basis and perhaps even diff certian service responses.  There are
perl scripts out there to detect public ftp/http/smtp servers that are
very nice too.  cron jobs are your friend.

> for our internet services, email, web, etc.  I have a single system
> outside the network that contains all the sendmail/apache config.  and all
> users get their email via outgoing connections through the
> firewall..  that way there is no way to compomise the internal network

I would suggest a different approach.  Have a box with three interfaces,
One to the outside world, one to your "internet servers", and one to your
"clients".  (add a fourth if you want to firewall the "servers" away from
the "clients" on top of the "outside world" and the "internet servers")
Now mind you, keep this all PCI and on a decent box, cause its gonna have
a ton of ipchains rules to parse per packet.

Set up ipchains to keep the client boxes away from all incoming
connetions.  Let the internet servers have very few ports open to the
"outside world" (ssh/http) and perhaps add ftp access or some sort of
sambamount access for "clients" or, alternatevly nfsmount the website on a
"server" so clients dont need special access to the "internet servers".
Allow the servers to have access to the "internet servers" and the
"clients", but no "outside world" connectivity.  Mail also gets a clean
setup where mail would go outside->internet servers->servers->client, with
a virus check somewhere in that transaction, probally at the "internet
server" level.  outgoing mail would do the reverse. 

"clients" could be restricted to all internet access and be forced to use
a "proxy" that could be in the "internet servers" area, or in an area all
its own.. depending on sensitivity.

Nothing beats a good router (linux or otherwise .. like a cisco) and real
seprate physical networks with a good packet filtering and routing setup.
:)

Hell. make all the clients and servers non-internet-routables too.  Wow.
there goes a *ton* of security hazards.  Make everything hit a proxy
(socks/squid/etc) and gain immense security gains.  The mail routing would
still work too.  Isn't that swift?

YMMV

---
Scott Dier <dieman@ringworld.org> #nicnac@efnet 612.301.0265
      destiny's admin       | The first thing we do,
 http://www.ringworld.org   |  let's kill all the lawyers.
finger me for gnupg/pgp key |   -- Wm. Shakespere, "Henry VI"