[THIN] Re: STA port number change?
- From: Carlos Sanabria <csanabria@xxxxxxx>
- To: thin@xxxxxxxxxxxxx
- Date: Tue, 15 Apr 2003 11:13:06 -0500
Alexander,
I really like your reasoning, you make a very good point, but you
mentioned:
> Even with single MetaFrame server it is advisable to have separate
> server that will serve HTTP(S) requests that are stateless in nature
(NFuse
> and STA) versus "permanent" connections such as Client-CSG-MetaFrame.
Could you explain this a little bit further? Honestly, my HTTP knowledge
is rather limited :-)
You also started your argument by mentioning this very interesting fact:
> There is very little compelling reason to drop STA on a "trusted"
network
> behind the DMZ at the time when most people either:
> 1. Do not have DMZ (just a firewall)
> 2. Do not encrypt XML traffic between NFuse and MetaFrame
> 3. Use non-encrypted traffic between NFuse-STA-CSG.
1. If you don't have a DMZ just put everything on the Trusted network
and distribute among your hadware as you please. End of Story. So for
argument's sake, we're assuming we have a DMZ.
2. Although most people don't encrypt XML traffic between Nfuse and
MetaFrame, I find it a bad practice.
3. This is actually the issue that started the whole thing. Although I
have never done it, it would be a sound practice to encrypt all traffic
to the STA using SSL. (And actually getting something good out of having
to install IIS rather than having a stand-alone STA).
Another point I wanted to make: installing the STAs on the same MF
servers gives you instant load balancing (of course, assuming you have
more than 1 MF box) I hate having to install IIS just to support STA
(and of course having to close the whole thing, via IISLockDown +
URLScan, ACLs, etc.)
Singing off for the day,
Carlos Sanabria, CCA, MCSA
IT Consultant
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On
Behalf Of Alexander Danilychev
Sent: Sunday, April 13, 2003 6:02 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: STA port number change?
Carlos,
Excellent point!
Design of any object, i.e. network, hardware, software etc. always
weighs
features and performance versus cost effectiveness. This also applies
when
we put together such contraption as MetaFrame/NFuse/CSG/STA/Firewall.
There is very little compelling reason to drop STA on a "trusted"
network
behind the DMZ at the time when most people either:
1. Do not have DMZ (just a firewall)
2. Do not encrypt XML traffic between NFuse and MetaFrame
3. Use non-encrypted traffic between NFuse-STA-CSG.
Let's review a reasonable compromise between cost and security (this
question was discussed via this group for about a year).
So, how many servers should we use? The common answer is 3:
1. NFuse/STA
2. CSG
3. MetaFrame (one or more servers in the Farm)
Reasons? Even with single MetaFrame server it is advisable to have
separate
server that will serve HTTP(S) requests that are stateless in nature
(NFuse
and STA) versus "permanent" connections such as Client-CSG-MetaFrame.
So, it is not advisable to mix CSG/NFuse contrary to your suggestion.
And
yes, we can save some money by not deploying separate STA box, but we
should
not try to jeopardize stability of CSG connection by grouping CSG and
NFuse
on the same hardware.
Now regarding the question of security. Let's say we have money to
deploy
DMZ and are planning on securing access to MetaFrame through CSG and
NFuse.
What are the risks?
Secure NFuse logins via SSL. If we are paranoid we should also deploy
client
certificates and/or tokens such as SecureID. By the way a complete SSL
solution ASSUMES client certificates not just server certificates!
Encrypt XML traffic between MetaFrame and NFuse. This can be
accomplished
via Citrix SSL Relay or IIS (preferred method by people that have done
both). Note that most deployments do not encrypt XML which is a PRIMARY
SECURITY RISK with this deployment (assuming NFuse password encryption
is
always implemented).
Assure that STA is not visible from outside the DMZ (including "trusted"
network behind DMZ). The main and probably the only risk of exposure for
STA
is denial of service attack, unless original STA DLL is replaced with
hostile code.
So, dropping STA behind DMZ on a trusted network and communication with
NFuse and CSG via unencrypted HTTP connection (which is default setting
per
original implementation diagram) is worse as compared to STA on DMZ but
protected with SSL.
Please note that internal SSL certificates (IIS or SSL Relay and STA)
can be
"home-grown" and thus free ($0.00), since there is no burden of
distributing
certificate from the internal certificate authority to hundreds of
clients.
What if we have extra money to spend and the cost for a standalone STA
box
is not an issue? Deploy additional load balanced NFuse boxes with
multi-homed provisioning for additional STAs on the same hardware!
What if user count is small and we do not have the budget for extra
servers?
My answer to that is deployment of NFuse and CSG on PC-class machines
($500
each)! This is better as compared to a single "real" server with
NFuse/CSG
on the same box. For adventures minds single MetaFrame/CSG/NFuse/STA
will
also work. Just make sure you do not remap to non-standard ports, employ
multi-homing and get ready for baby-sitting.
ALEX
>From: Carlos Sanabria <csanabria@xxxxxxx>
>Reply-To: thin@xxxxxxxxxxxxx
>To: thin@xxxxxxxxxxxxx
>Subject: [THIN] Re: STA port number change?
>Date: Sat, 12 Apr 2003 09:16:55 -0500
>
>
>Alexander,
>
>I differ from your opinion of installing the STA on the DMZ. The whole
>idea of Citrix Secure Gateway (assuming we're not dealing here with
>Relay Mode) is to have a ticket generator in the Trusted network so
>that it cannot be hacked or tampered with. For extra security configure
>your firewall so that only the Nfuse box and the CSG box (which, could
>be the same in case you're tight on hardware) can access the STA from
>the DMZ. And yes, you could also secure the XML service using Citrix
>SSL Relay, and the STA using IIS SSL.
>
>Just my .02
>
>Carlos Sanabria, CCA, MCSA
>IT Consultant
>
>-----Original Message-----
>From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On
>Behalf Of Alexander Danilychev
>Sent: Friday, April 11, 2003 12:04 PM
>To: thin@xxxxxxxxxxxxx
>Subject: [THIN] Re: STA port number change?
>
>
>
>Your steps are absolutely correct.
>If you keep STA behind DMZ -- use SSL, i.e. port 443 to please your
>firewall=20 folks.
>
>Some people from this group suggested using the same IIS that is used
>in
>
>conjunction with XML service, i.e. drop STA on MetaFrame.
>
>I personal like my STAs "rock solid", so scenario with MetaFrame
>deployment=20 of STA does not fit the bill (for single MetaFrame box it
>is probably OK).
>
>I always deploy STA within DMZ paying attention to secure STA from
>outside=20 access. Again SSL is not important -- only denial of service
>attacks if STA=20
>is downed or busy.
>If you like to save some money =96 drop STA on a multi-homed NFuse box
=
>(it
>
>will support independent load balancing for STAs and NFuse). DO NOT
>deploy=20 STA on CSG box!
>
>I will pay more attention to XML service and MAKE SURE that it is not
>on
>
>default port 80, but protected with SSL (free home-grown certificates
>are=20 OK)!
>
>ALEX
>
>
> >From: "Raffensberger, Stephen D (Stephen) %" <raff@xxxxxxxxx>
> >Reply-To: thin@xxxxxxxxxxxxx
> >To: <thin@xxxxxxxxxxxxx>
> >Subject: [THIN] STA port number change?
> >Date: Fri, 11 Apr 2003 09:53:05 -0400
> >
> >
> >I'm building a standard Nfuse 1.7/CSG/STA configuration according
> >to=20 the =3D Citrix docs. My firewall folks are concerned about port
> >80=20 traffic initiated in the =3D DMZ (Nfuse &
> >CSG) and destined for the STA in the intranet. They want me to change
>it =3D
> >to another
> >port for improved security.
> >
> >I imagine it's pretty simple to do.
> >
> >1. On the STA server, change the port to 999 in IIS.
> >2. On the Nfuse server, change the NFuse_CSG_STA_URL to
> > http://X.X.X.X:999/Scripts/CtxSta.dll
> >3. On the CSG server, change Port to 999 in
> > HKLM\CCS\Services\CtsSecGwy\TicketAuthorities\STA01
> >
> >Has anyone actually done this? Is it as big a security problem as my
> >=
>=3D=20
> >guys perceive? It seems like Citrix doesn't think so. It's not in
> >any=20 of the =3D installation or config settings. Also it looks like
> >it's incompatible with SSL which means
>that =3D
> >I can't
> >really secure it at all.
> >
> >Steve Raffensberger
> >Computer Aid serving Agere Systems
> >Mailto: raff@xxxxxxxxx
> >(610) 712-6819
> >
> >********************************************************
> >This Week's Sponsor - ThinPrint
> >Simply the best print solution for
> >Microsoft Terminal Services
> >and Citrix Metaframe.
> >http://www.thinprint.com/
> >**********************************************************
> >
> >For Archives, to Unsubscribe, Subscribe or
> >set Digest or Vacation mode use the below link:=20
> >http://thethin.net/citrixlist.cfm
>
>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE* =20
>http://join.msn.com/?page=3Dfeatures/virus
>
>********************************************************
>This Week's Sponsor - ThinPrint
>Simply the best print solution for
>Microsoft Terminal Services=20
>and Citrix Metaframe.
>http://www.thinprint.com/
>**********************************************************
>
>For Archives, to Unsubscribe, Subscribe or=20
>set Digest or Vacation mode use the below link:
>http://thethin.net/citrixlist.cfm
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.463 / Virus Database: 262 - Release Date: 3/17/2003 =20
>
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.463 / Virus Database: 262 - Release Date: 3/17/2003 =20
>
>********************************************************
>This Week's Sponsor - ThinPrint
>Simply the best print solution for
>Microsoft Terminal Services
>and Citrix Metaframe.
>http://www.thinprint.com/
>**********************************************************
>
>For Archives, to Unsubscribe, Subscribe or
>set Digest or Vacation mode use the below link:
>http://thethin.net/citrixlist.cfm
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
********************************************************
This Week's Sponsor - ThinPrint
Simply the best print solution for
Microsoft Terminal Services
and Citrix Metaframe.
http://www.thinprint.com/
**********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thethin.net/citrixlist.cfm
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.463 / Virus Database: 262 - Release Date: 3/17/2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.463 / Virus Database: 262 - Release Date: 3/17/2003
********************************************************
This Week's Sponsor - ThinPrint
Simply the best print solution for
Microsoft Terminal Services
and Citrix Metaframe.
http://www.thinprint.com/
**********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thethin.net/citrixlist.cfm
Other related posts:
