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

From: Andrew van der Stock (ajv@e-secure.com.au)
Date: 08/29/01 

From: "Andrew van der Stock" <ajv@e-secure.com.au>
To: <Jonathon.Kalaugher@sbg-ap.com>
Subject: RE: Options for securing a Public Webserver and Private Intranet on same server.
Date: Wed, 29 Aug 2001 10:54:08 +1000
Message-ID: <GLEMLPDJLNNLKLDLMOJEAEAMCCAA.ajv@e-secure.com.au>

Well, the only thing I can suggest in your case is that you try to force
some form of strong authentication for the external users (ie, the VPN
client enforces strong authentication (two factor tokens or similar) before
you get access to the IP address).

I would suggest two servers with distinct IP addresses, one public access
for your Internet server, and one that's strongly authenticated via the use
of VPN for outside users and not so much for inside users (be sure to use
anti-spoofing). Things like Code Red prove that security through obscurity
would have found two unpatched servers just as easily as one unpatched
server, but by separating them physically and logically, it makes it harder
to cause both to go under. If strong authentication is forced, then things
like Code Red would have been kept at bay ... as long as your servers
weren't able to talk to each other via the use of decent firewall rule sets
or VPNs with ACLs.

Use the IIS checklist and tools and regularly apply all new security patches
(at least weekly - schedule a maintenance window for it).

Do not allow the web servers to do outbound anything on the firewall
rulesets. Firewall-1 and PIX both allow the idea of inbound connections (and
their replies) as one rule. You do not need an outbound rule for the web
server. Although I temper this with one exception;
windowsupdate.microsoft.com is the easiest way to keep your machine up to
date. If there is significant difficulty in managing the patching (ie
there's no easy way to get patches that you've approved to the web server,
windowsupdate is as at least as good as figuring it out for yourself. The
residual risk of DNS attacks to force you to another site or a very small
probability that a patch on Windows Update kills your machine is far less
than the risk of an unpatched machine. The fix for both issues (and a good
idea anyway) is a verified backup before you perform any updates.

Andrew

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

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