Accessing a UNIX server through MS Proxy server 2.0
Taylor, Gregory - Open Systems
Fri, 12 Jun 1998 14:46:37 +0100
This brings things full circle to the old chestnut of what is a
firewall?!! Itai has a good point that whatever security you employ it
is only to implement your security policy. Surely you look at what you
have to protect, analyse the external risk and act accordingly. If you
have little of value to the hacker there are plenty of "juicy" sites out
there which will divert their attention. In that case a simpler (and
considerably cheaper!) option can be used. In my case I have to provide
a much tighter protection requiring a full feature firewall.
The problem is that too many people are now seeing a firewall as
some sort of fit and forget device. The problem is that "firewalls"
differ in the protection they provide and by not carrying out a proper
threat analysis, producing a security policy and then intelligently
matching the available mechanisms to that policy people are going to end
up wide open. I am certainly NOT of the opinion that MS Proxy is a
STRONG firewall but properly installed it is one hell of a lot better
than nothing (or perhaps a router with a bit of packet filtering) and
can be appropriate in the right circumstances. Perhaps the term
"firewall" is becoming too wide?
Also in fairness to the product (I am not actually anti-MS
except when my desktop crashes at the wrong moment ;-) it is a very
good web proxy. I am squeezing 40+ users through a 64KB pipe (yes I
know it's not enough but tell that to my finance department) and
response time is now excellent by setting the proxy appropriately. It
has also been relatively stable only having to to reboot once in about 3
Thanks also to Joe for the book recommendation. I am not very
keen on on-line documentation (either my age or the fact my firm won't
buy me a laptop with CD-ROM and at least I can carry a book around with
> Date: Tue, 9 Jun 1998 15:44:10 -0700
> From: "Joe Ippolito - President SVNPA" <firstname.lastname@example.org>
> As long as the UNIX host is a Socks 4.3 client you can use pretty much
> TCP application including telnet. You will need the identd service
> on the proxy box and if you are using the packet filtering you will
> need to
> create a rule (as in any other fire wall) to let it through. You can
> not do
> any applications requiring UDP through the socks proxy or ICMP though
> any of
> the proxy services. If you need to provide complete services to UNIX
> clients try a full service firewall like Firewall-1. If you want to
> make a
> small pipe look really fast for gobs of WinSock clients and have a
> packet-inspection firewall, secure web publishing, etc. etc. for
> cheap use MS Proxy 2.
> A book I can recommend is "MCSE: Proxy Server 2 Study Guide", Erik
> et. al., Sybex Network Press, 1998. It is a bit wordy but quite
> and the price is much more reasonable than MS courseware.
> The documentation provided with MS Proxy is also very well done. You
> to have IE 4 and Index Server installed to use it.
> - -----Original Message-----
> From: email@example.com
> On Behalf Of Itai Dor-on
> Sent: Wednesday, June 03, 1998 12:36 AM
> To: Taylor, Gregory - Open Systems; firstname.lastname@example.org
> Subject: Re: Accessing a UNIX server through MS Proxy server 2.0
> >So, bottom line is you can't proxy telnet (your only alternative is
> >open up to the world!!) and there are some concerns over its FTP
> >If I were you I would buy a firewall ;-)
> I suggest you buy a book on Microsoft Proxy Sever 2.0/1.0 as your
> response clearly shows that you don't understand its architecture.
> You *can* proxy Winsock 1.1 compliant applications (e.g TELNET) using
> MSP Winsock Proxy module.
> As for FTP sessions, you could proxy them using the Web Proxy module
> and do a content scan using ISAPI .
> What makes a product a 'good firewall' is its ability to reinforce the
> security policy and to do it well. If Microsoft Proxy server can do
> that for
> company then it is not a less secure solution than any other firewall
> (e.g Checkpoint, TIS etc.). The tricky part is to know how to define a
> policy and to map it to technical requirements.