RE: Any Holes?

GEIS (Adam.Safiergeis.ge.com)
Fri, 19 Sep 1997 15:30:41 -0400

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
• Next message: Paul Ferguson: "Re: How do you fight an attack in progress?"
• Previous message: Andy Howard: "Re: How do you fight an attack in progress?"
• In reply to: Grigorof, Adrian: "How do you fight an attack in progress?"

The CA should not be in the DMZ. If the web server is broken into it
can be used to attack the CA. If the CA is on the internal LAN or
another DMZ it is protected from the web server - you only open up the
CA port from the Web server to the CA so attacks on other ports can't be
launched. Of course you have to trust your internal users......

passwords can be sniffed, guessed etc. How about a one time password
system?

Why encrypt the web server - DB server link? Who are you protecting
from? Firewall should not allow traffic between these two to be seen
outside of network. It's OK if you can afford the overhead - belt and
suspenders. Again, I am trusting the internal network users......

Adam

> -----Original Message-----
> From: Giesinger, Nick HE0 [SMTP:ngiesinghealth.gov.sk.ca]
> Sent: Thursday, September 18, 1997 3:40 PM
> To: 'firewall-wizardsnfr.net'
> Subject: Any Holes?
>
> We have a security requirement to allow third parties to access data.
> The firewall that we originally obtained was act as a proxy server.
> It
> is now being asked to perform this connection.
>
> The firewall has three network cards, Internal, external and dmz.
> Access will not be allowed from external to internal directly. The
> firewall has a bank of IP assigned to the external card when a
> specific
> ip (ie: 100.1.1.1) accessed at a specific port (ie: 4000) the external
> card maps to a different ip ie:(10.2.2.2) and port (ie: 4100) to the
> dmz. On the dmz, the web server will require a logoõÿand password.
> It
> also requires a x.509 certificate. The certificate authority resides
> in
> the dmz as well. Once a connect has been established the webserver,
> through asp pages, proxies to the firewall at a different ip (ie:
> 10.2.2.254) and port (ie: 5000) to which the firewall maps to yet
> another ip (ie: 10.10.2.2) and port (ie: 5001) which is the internal
> network. The internal database server verifies the poxied request
> spawned by the dmz web server and depending on the proxy acc't access
> rights grants the varring database access. The connection between the
> dmz web server and internal database is through the database propriety
> encryption/connection supplied with the db which runs only over ip.
>
> The web server is IIS3.0, the CA is WebCA 1.01, both using NT 4.0 and
> various patches/hot fixes. The firewall is Borderware 4.1 with
> patches.
> The database is MS SQL 6.5
>
> NT 4.0 has no generic acc'ts (except the proxy accounts but these
> reside
> on the internal system not the dmz) and no anonymous logins. No
> routing
> between nic's. The web pages reside on a different physical drive then
> OS. Permissions are only granted to the web drive. Administror has
> access to all. The files system is NTFS. IIS3.0 allows clear text
> login, with x.509 this should be sufficient. ASP pages are the main
> source of request/retrieveals.
>
> We do not have total control over the client computer, but it does
> require a x.509 certificate and user name login.
>
> What have I forgotten?
>
> Nick G.

• Next message: Paul Ferguson: "Re: How do you fight an attack in progress?"
• Previous message: Andy Howard: "Re: How do you fight an attack in progress?"
• In reply to: Grigorof, Adrian: "How do you fight an attack in progress?"

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:08:58 CDT