Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Citrix Security and Nfuse 1
- Thread starter GBorrer
- Start date
DomainMaster
Technical User
how is your firewall configured ?
Jon. ----------------------------------------
To be is to do (Sartre)
To do is to be (Casmus)
Do be do be do (Sinatra)
----------------------------------------
Jon. ----------------------------------------
To be is to do (Sartre)
To do is to be (Casmus)
Do be do be do (Sinatra)
----------------------------------------
- Thread starter
- #3
DomainMaster
Technical User
are you trying to connect via NFuse from the internet, or from within your LAN ?
Jon. ----------------------------------------
To be is to do (Sartre)
To do is to be (Casmus)
Do be do be do (Sinatra)
----------------------------------------
Jon. ----------------------------------------
To be is to do (Sartre)
To do is to be (Casmus)
Do be do be do (Sinatra)
----------------------------------------
- Thread starter
- #5
We are connecting via internet, Nfuse is on the IS server , and Citrix located on another . The port open for the citrix box is 1494, and we have used the altaddr command to make it function like this. problem is that we only want people that authenticate through the Nfuse box to be able to access the Citrix server. Well right now you can bypass the Nfuse and directly connect to Citrix, this is not acceptable due to security issues...
NFUSE is mearly an authentication portal used for Citrix. It authenticates the user's NT/W2K credentials, and then queries the Citrix box for the list of applications that the user has access to. From there it dynamically generates the app list that the user is presented with, and returns application specific info required to run the app, including the IP address of the Citrix box that the application is published on. NFuse does not actually run the apps. It merely provides a simplified way to access the applications on the Citrix boxes through a web browser. Once you click on a published application that is listed on the Nfuse page, your workstation establishes a direct connection to the citrix box and runs the app. You must have direct access from your workstation to the Citrix box through an ICA client for the NFUSE concept to work. To secure your Citrix box, you must implement alternate methods (i.e VPN, data encryption, etc).
Da Ruster
Da Ruster
- Thread starter
- #7
How about SecureID , any methods to help with security using this in conjunction with our Nfuse box.
The user currentley logs in with SecureID then with User/Pass, then selects published app, .
The Citrix server then looks at the security info used to login to NFuse and then launches the application based on this, The only thing is that it is only the User/Pass and not the SecureID data at all; meaning that simple or easy user name and passwords could be cracked via direct connection to Citrix without having connecting to NFuse with SecureID authentication.
There has got to be a way to get this secure, any help greatley appreciated.
The user currentley logs in with SecureID then with User/Pass, then selects published app, .
The Citrix server then looks at the security info used to login to NFuse and then launches the application based on this, The only thing is that it is only the User/Pass and not the SecureID data at all; meaning that simple or easy user name and passwords could be cracked via direct connection to Citrix without having connecting to NFuse with SecureID authentication.
There has got to be a way to get this secure, any help greatley appreciated.
DomainMaster
Technical User
Is the user connecting to any old ISP, then connecting to your homepage ?
Unless your gateway/webserver/firewall is a bit skewed, you shouldn't be able to connect directly to the ip address of the citrix server. you should have to go through the nfuse portal, which 'passes on' all your details.
The secureID and stuff before NFuse is only for network identification isn't it ?
Jon. ----------------------------------------
To be is to do (Sartre)
To do is to be (Casmus)
Do be do be do (Sinatra)
----------------------------------------
Unless your gateway/webserver/firewall is a bit skewed, you shouldn't be able to connect directly to the ip address of the citrix server. you should have to go through the nfuse portal, which 'passes on' all your details.
The secureID and stuff before NFuse is only for network identification isn't it ?
Jon. ----------------------------------------
To be is to do (Sartre)
To do is to be (Casmus)
Do be do be do (Sinatra)
----------------------------------------
- Thread starter
- #9
SecureId is network identification yes.
Heres a list of the boxs that are in question.
Server InternalIP ExternalIP
Nfuse 192.168.0.1 10.10.10.1 <~~Webserver
Citrix 192.168.0.2 10.10.10.2 port 1494 only
Citrix is using the altaddr function to allow published apps to be accessed outside our local intranet.
Nfuse box is using SecureID also to help insure that only the proper people gain access.
I was hoping that with the way Nfuse transfers the logon info to Citrix when you select a Published App that I could install the SecureID client on Citrix and have Nfuse send that data as well making it a little more diffucult for would be intruders....
Heres a list of the boxs that are in question.
Server InternalIP ExternalIP
Nfuse 192.168.0.1 10.10.10.1 <~~Webserver
Citrix 192.168.0.2 10.10.10.2 port 1494 only
Citrix is using the altaddr function to allow published apps to be accessed outside our local intranet.
Nfuse box is using SecureID also to help insure that only the proper people gain access.
I was hoping that with the way Nfuse transfers the logon info to Citrix when you select a Published App that I could install the SecureID client on Citrix and have Nfuse send that data as well making it a little more diffucult for would be intruders....
Did you see the new Citrix Secure Gateway product? If my interpretation is correct, you can wrap Nfuse and all ICA traffic in SSL. This should mean that you won't need 1494 open which will halt direct ICA access to your servers. Best thing is that it is free if you have the subscription.
Al
atc-computing@home.com
Al
atc-computing@home.com
Guest_imported
New member
- Jan 1, 1970
- 0
- 0
- 0
As ruster said 'NFUSE is mearly an authentication portal used for Citrix.' and SecureID could be used to increase the authentication security, but will not solve the problem with port 1494 open to the internet on the Citrix server.
I would suggest you to put the PassThrough client on the NFUSE server (and secure the NFUSE server with Secure ID). This way the internal Citrix server will not be directly accessible from the internet and the NFUSE box will be secured with Secure ID.
I would suggest you to put the PassThrough client on the NFUSE server (and secure the NFUSE server with Secure ID). This way the internal Citrix server will not be directly accessible from the internet and the NFUSE box will be secured with Secure ID.
-
1
- #12
GBorror,
We have almost exactly as you describe, SecureID and Nfuse on a Metaframe 1.8 Server running W2K. With Nfuse on the Citrix server itself, it means I have 443 and my ICA port exposed through the firewall.
NFuse does not require SecureID to retrieve published applications, which we brought to the attention of Citrix. They dismissed it saying because local access required Token authentication it did not matter if username/password was cracked (I of coarse disagreed), afterall token would block any access to the server, and auditing would show signs of dictionary attacks.
We also brought to thier attention the whole 1494 is open and if they know the public IP address they can custom an ICA file to bypass Nfuse. They admitted this, and as others have told you Nfuse does not serve as a security boundry to prevent direct connection.
Secure Gateway is supposed to be thier answer to all of this, making it so that 1494 is not open directly to the internet. Only problem with that from our perspective is that Secure Gateway requires Metaframe XP from what I understand, which means our Metaframe 1.8 box would have to be upgraded to use this feature. We are supposed to begin testing in Jan. so I can let you know what we find.
Bottom line, you will stay exposed, and SecureID is your first line of defense. Best practices for a Citrix server with sensitive information (I am in the Health/Medical industry) almost requires you to make sure that all access to the server is with SecureID. For example, we require all ICA connections to be only for the SDLocal group, which requires any authenticated user to have a SecureID token for authentication. Then we just put all of our application groups in the SDLocal group.
Other best practices include publishing applications only with ICA connnections, deny any RDP, lock the server down tight with permissions, use appsec.exe from the resource Kit, and set up a strong Group Policy that locks down as much as you can get away with. Why lock down the desktop if you only allow published applications? Because even if you require published applications in ICA properties a savy user can still easily get to the desktop.
Because you are directly on the web with 1494, SecureID is your first and best defense. You are using AD to protect your servers on the DMZ right? Securing Citrix on the DMZ almost requires W2K with AD, and is a real pain in the *#@ without it (I know from experience).
There is one last thing you can do, you can change the default ICA port or the Metaframe server, and of coarse change the settings in NFUSE to reflect the port change. While changing the port # still leaves the server exposed to the net, at least you require extra work for the hacker to determine what service is using the exposed port.
To change the default ICA port on Metaframe use the ICAPORT command line utility. To configure a new port, type icaport from the command line on the metaframe server and you will see all the available options. To change the port in NFUSE you will need to use the Customizing_NFuse.pdf supplied with NFUSE. It will address a couple ways to do it, depending upon how customized your NFUSE is and what is the best way for you.
More security help for this issue can be found at the following links:
Let me know if this helps.
Galrahn
galrahn@galrahn.com
We have almost exactly as you describe, SecureID and Nfuse on a Metaframe 1.8 Server running W2K. With Nfuse on the Citrix server itself, it means I have 443 and my ICA port exposed through the firewall.
NFuse does not require SecureID to retrieve published applications, which we brought to the attention of Citrix. They dismissed it saying because local access required Token authentication it did not matter if username/password was cracked (I of coarse disagreed), afterall token would block any access to the server, and auditing would show signs of dictionary attacks.
We also brought to thier attention the whole 1494 is open and if they know the public IP address they can custom an ICA file to bypass Nfuse. They admitted this, and as others have told you Nfuse does not serve as a security boundry to prevent direct connection.
Secure Gateway is supposed to be thier answer to all of this, making it so that 1494 is not open directly to the internet. Only problem with that from our perspective is that Secure Gateway requires Metaframe XP from what I understand, which means our Metaframe 1.8 box would have to be upgraded to use this feature. We are supposed to begin testing in Jan. so I can let you know what we find.
Bottom line, you will stay exposed, and SecureID is your first line of defense. Best practices for a Citrix server with sensitive information (I am in the Health/Medical industry) almost requires you to make sure that all access to the server is with SecureID. For example, we require all ICA connections to be only for the SDLocal group, which requires any authenticated user to have a SecureID token for authentication. Then we just put all of our application groups in the SDLocal group.
Other best practices include publishing applications only with ICA connnections, deny any RDP, lock the server down tight with permissions, use appsec.exe from the resource Kit, and set up a strong Group Policy that locks down as much as you can get away with. Why lock down the desktop if you only allow published applications? Because even if you require published applications in ICA properties a savy user can still easily get to the desktop.
Because you are directly on the web with 1494, SecureID is your first and best defense. You are using AD to protect your servers on the DMZ right? Securing Citrix on the DMZ almost requires W2K with AD, and is a real pain in the *#@ without it (I know from experience).
There is one last thing you can do, you can change the default ICA port or the Metaframe server, and of coarse change the settings in NFUSE to reflect the port change. While changing the port # still leaves the server exposed to the net, at least you require extra work for the hacker to determine what service is using the exposed port.
To change the default ICA port on Metaframe use the ICAPORT command line utility. To configure a new port, type icaport from the command line on the metaframe server and you will see all the available options. To change the port in NFUSE you will need to use the Customizing_NFuse.pdf supplied with NFUSE. It will address a couple ways to do it, depending upon how customized your NFUSE is and what is the best way for you.
More security help for this issue can be found at the following links:
Let me know if this helps.
Galrahn
galrahn@galrahn.com
Hi,
in a standard NFuse deployment, the ICA client must still directly connect to the Citrix Metaframe server. That's exactly the reason why Citrix had developed Citrix Secure Gateway (
A very good presentation about the pros and cons of Nfuse and CSG can be found at
Hope this helps...
Stefaan
in a standard NFuse deployment, the ICA client must still directly connect to the Citrix Metaframe server. That's exactly the reason why Citrix had developed Citrix Secure Gateway (
A very good presentation about the pros and cons of Nfuse and CSG can be found at
Hope this helps...
Stefaan
- Status
Similar threads
- Locked
- Question