RE: Options for securing a Public Webserver and Private Intranet on same server.

From: Jonathon.Kalaugher@sbg-ap.com
Date: 08/28/01 

Message-ID: <E48EF4B51A3A47468CEA37E874AA16D831AC89@eidyia.spherebusinessgroup.com>
From: Jonathon.Kalaugher@sbg-ap.com
To: ajv@e-secure.com.au
Subject: RE: Options for securing a Public Webserver and Private Intranet  on same server.
Date: Tue, 28 Aug 2001 18:56:48 +1200

great thanks heaps for the input.

Most appreciated.

A bit more information:

1) We have numerous external dial-up users (dynamic IPs etc) who access
this Intranet server.
Hence the requirement to keep all access on ports 80 and 443 open to
external sources.

2) For various reasons (mostly political) rolling out a VPN client (so
we could restrict access to the Intranet Server to VPN users only) of some
type is not feasible at this stage.

Question:

-Would the Logon dialogue box on the Intranet (which is the first thing
encountered when attempting to access the application) limit the
vulnerabilities the Intranet is susceptible to by "blocking" access to the
server until successful authentication is performed?

Of course we would still ensure all patches are applied in a timely manner,
- just looking for way to tighten security on this important/sensitive
application.

Thanks again

Jon.

-----Original Message-----
From: Andrew van der Stock [mailto:ajv@e-secure.com.au]
Sent: Tuesday, August 28, 2001 1:55 PM
To: Jonathon.Kalaugher@sbg-ap.com
Cc: focus-ms@securityfocus.com
Subject: RE: Options for securing a Public Webserver and Private
Intranet on same server.

First off, you don't state what the value of the Intranet server is. What is
the impact if people from the Internet can see it? What if they change it?
You should try to answer these questions, as it will reflect what path you
choose when it comes to securing the server.

IIS has a long and colorful exploit history, and I don't see this abating
any time soon. If IIS exploits were few and far between, I would recommend
using the virtual hosts feature (using different IP addresses rather than
host headers), and allowing the firewall to restrict access based upon IP
address. However, IIS exploits of significant severity happen with regular
monotony, so I would suggest a seperate server for both functions, and
moving the Intranet server either to a separate internal "servers" zone, or
just to your internal network, depending on your network architecture and
business requirements. If it's in your Internal network, you can enforce NT
login rather than use basic digest (urgh).

In any case, you must keep your IIS servers up to date (within days of patch
release, maximum) or you will suffer server compromise.

good luck!

Andrew van der Stock, MCSE, Senior Security Architect, e-Secure Pty Ltd
"Secure in a Networked World" Phone: (03) 9699 7088 Fax: (03) 9699 7066
Suite 302, 370 St Kilda Rd Mobile: 0412 532 963
Melbourne Victoria Australia Email: ajv@e-secure.com.au
ACN 068 798 194 http://www.e-secure.com.au

-----Original Message-----
From: Jonathon.Kalaugher@sbg-ap.com
[mailto:Jonathon.Kalaugher@sbg-ap.com]
Sent: Tuesday, 28 August 2001 06:45
To: focus-ms@securityfocus.com
Subject: Options for securing a Public Webserver and Private Intranet on
same server.

Hello List,

Background:

Public Website and private Intranet running on same server behind a FW.

The Intranet is accessed via IIS/windows authentication with a "full public
access over port 80" rule on the Firewall to the server in question.

The users access the public website and enter authentication apon hitting
the corporate logon area/box to access the Intranet.

We considering the following steps...

1) Separate both onto separate servers and DMZ's
2) Still Allow full public access to both servers over ports 80/443.

Question.

1) What are the implications of having both the Website and Intranet
residing on the same server? Does the "allow all on ports 80/4443" to the
public website expose the Intranet (on the same server) to any extra
security risks?

2) Would moving the Intranet to a separate server (still accessible to
the public over port 80/443) and only allowing authenticated access to the
application stop (or somehow hinder) it being vulnerable from any IIS
exploits?.

i.e. Would the authentication prompt for Intranet access, block any
unauthorised access to the underlying IIS / Intranet?, as a user is prompted
for sign on before having access to the site.?

Or is it secure to have both the Website and Intranet running on the same
server if certain steps are taken first, as the goal is to maximise security
of the Intranet.

Thanking you all heaps in advance for any feedback at all.

JK.

Relevant Pages