Subject: Re: Is it better to use squid or squid-gw to hide a webserver

From: Hank Leininger <[email-masked]>
Date: Wed, 19 Jul 2000 12:44:44 -0400

[To be removed from this list send the message "unsubscribe fwtk-users" in the
BODY of a mail message to [email-masked].]

On 2000-07-17, "Hermann Reimer" <[email-masked]> wrote:

> Is it a good idea to use squid on the firewall or is it unsecure ?

> Is it a better idea to use squid-gw on the firewall and put a
> squid-proxy server in the the same local lan as the webserver ? 
> Webserver is NT, firewall is SuSE Linux with two network cards and fwtk
> running. 
> I favorite this opinion because the webserver could be managed in the
> local lan, without any restrictions. In an DMZ the different authors of
> the web ( in the local lan) could only use ftp to manage their
> websites, so it's not so comfortable. 

Hm.  Consider this: If your webserver gets compromised, how will that
happen?  Given that you'll be able to disable and/or block all other
services, it'll happen via HTTP or HTTPS, of course.  Particularly given
your choice (perhaps not _your_ choice, but something you're required to
do) of Windows NT as the webserver, it's a losing proposition to expect
*any* kind of firewall/proxy setup to protect the webserver from the IIS
bug-of-the-week.

If you're an attractive target (and even if not, and you just get unlucky)
the webserver will eventually be compromised via some TCP port 80,
valid-HTTP-looking attack.  At that point, would you rather that the rest
of your network (inside the firewall) is exposed to attacks launched from
the webserver, or would you rather the webserver be in a playpen by itself?
(Note, I'm somewhat MS-bashing here, but the principle would still apply
even if your webserver were an OpenBSD box running publicfile.)

I'd probably recommend putting a third NIC in the firewall, and setting the
webserver (and possibly other DMZ boxes) up on a dedicated network segment.
The firewall could be expected to filter all-but-web-requests INTO the
webserver, and also all-but-web-responses OUT of the webserver.  Of course,
any/all DMZ hosts should be locked down so that they "shouldn't" be
compromisable -- but even if they are, you've now limited the collateral
damage possible.

Since sneakernet is probably unacceptable for webpage management, etc, and
you are quite right that FTP wouldn't be desirable, you could use Stunnel
on webserver to wrap SMB within SSL.  Configure Netbios to bind (only) to a
localhost/loopback IP address on the NT box (and/or do the odd "dummy NIC
just for Netbios" hack).  Configure Stunnel to require client certificates
on inbound connections on some port you choose, forwarding to
localhost:139.  Of course the webserver should have local accounts, not be
part of a domain.  Configure the firewall to allow (only) inside hosts to
access the stunnel-server port on the webserver, issue client certs and
install stunnel on the workstations of users on the inside network.

This means work, and new things to learn (BTW: stunnel lives at
http://mike.daewoo.com.pl/computer/stunnel/ or www.stunnel.org, which
appears to be down at the moment; we also archive their mailing list at
http://marc.theaimsgroup.com/?l=stunnel-users&r=1&w=2), but the additional
infrastructure is exactly one NIC and a crossover cable or hub, and all the
software's free.  Once set up it shouldn't place any extra burden on you to
run, and not much for the users (just make  "click here" batchfile that
does the appropriate stunnel-client invokation and net use commands),
although the overhead of SSL will make file management Not Fast But
Usable[TM].

...Then stay up nights sweating because your web developers save their
passphrase in a textfile on their desktop box, and install PCAnywhere with
no password on their box and plug the FAX machine's phone line into their
modem...

--
Hank Leininger <[email-masked]>