Hi all, thanks for your comments.


> > What I want to do here is set up a second ExtraNet, - a Secure
> > Server Net which will host the servers providing services for
> > the frontline ExtraNet servers, whether these are for things like
> > SysLog or RADIUS or the backends/Databases for the middleware/web
> > servers on the Public access ExtraNet.
> >
> >
> > Does anyone have any comments on this approach ?
>
>Sure...first, I have a reputation as a pedant to uphold - I don't think 
>ExtraNet is the word you want. An "ExtraNet" is a (stupid, marketing) word

I agree, we actually call it/them PerimNets.  Our external or first tier 
PerimNet is more properly called insecure-net and the inner one or 'SSN' is 
called host-net. Our DMZ is just that - the stretch of wire on which nothing 
should be located between the external router, the Firewall and again 
between Firewall and internal router.

The insecure-net is located off the external router and protected by
a Nokia box.  Hosts on this net include primary web servers, external DNS 
servers and so on.  Staging servers and backends go into the host-net.

>You've got an interesting concept. I think there are two main reasons why
>this design philosophy isn't very widespread.
>
>Firstly, in many cases the second tier servers you describe _are_ "the
>farm". There's no sense protecting anything more than these servers because
>they contain huge, valuable lumps of mission critical, saleable data. As
>many people as we tell people to only have webservers talk to simple,
>read-only databases that run side-channel extracts from the real database
>there are a dozen more that go ahead and hook Cold Fusion into the live
>Oracle back end.
>
>Secondly, it is often a requirement for internal users to have pretty much
>full access to the "service" servers for administration, to add/remove
>content, because they're also used live by a bunch of internal apps, 
>because
>they're Windows Domain Controllers etc etc etc.

Yeh I ageee there.  Fortunately in most cases they are largely
standalone Database hosts and so on.  Where these are Unix its
SSH access, when NT its VNC over Secure Shell.  There are also
some legacy Remotely Possibles there too though.  Secondly we're
in the position to dictate to a degree how things fit into our
architecture, eBusiness projects that get handed to us.  The main
problem I am going to see is when that three-tier architecture
moves on from just that.  Its quite simple at the moment. Internet
client, middleware WWW server, backend host.  I have been informed
that soon that backend will soon include multiple geographically disparate 
business objects - pulling partner data, customer data etc etc.

I wonder also whether other enterprise businesses enforce authenticated 
(SecurID/PKI etc) access from internal nets to their DMZ's for admins and so 
on.  Considering the majority (roughly 2/3'rds) of 'incidents'are from 
internal issues or employees this would seem to make some sense.  As long as 
we can tie the authentication to the SecurID (ACE) server so that NT and 
Unix authentication is sent there instead of being performed local to that
host (and thus avoiding double logon handshakes) this may be preferable.



Given this requirement, the
>divider between the service servers and the rest of the trusted LAN needs 
>to
>be so full of holes that it may as well not be there, from a security point
>of view.

I aim to minimize what we will allow from host-net into internal
networks.  Everything should be inbound from internal networks
or from the insecure-net.




>
>Having said that, the architecture you propose is valid as long as you 
>don't
>run into one of the walls above. I quite like it, actually. The one thing I
>would probably do is to hang the second-tier DMZ sideways from the main DMZ
>- this loses a teeny bit of security but means that all trusted <-->
>external traffic doesn't need to pass through an extra device. I don't do
>ASCII art, but imagine the router that separates the DMZ from the trusted
>LAN with a third interface and the services network living off there.

This is the setup here as things stand.


Internet
  |
  |      Nokia
_|_      ___
|RTR|____|FW1|_______insecure-net   (WWW servers, external DNS)
|___|    |___|
  |
_|_
|FW1|________________host-net   (Staging servers, backends)
|___|
  |
  |
_|_
|RTR|
|___|
  |
  |
Internal Networks


All routers are Firewalling to differing degrees too.

The other advantage of this is that inbound http/domain traffic
isn't going to affect the mainline Firewall-1 box bandwidth wise
and rules on each security device is going to be a lot less com-
plicated.  The problems include points of failure and the fact I
believe 'routers should route and firewalls should firewall'.  With
time hopefully I'll be able to improve on this too.

Any comments on this architecture ?


Cheers,  Tony


>Cheers,
>
>--
>Ben Nagy
>Network Consultant, Volante Solutions
>PGP Key ID: 0x1A86E304  Mobile: +61 414 411 520

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to