vulnerability assessment of Citrix Netscaler NS7000 using Nessus

I used Nessus on the latest Pentoo Linux live cd to assess the Citrix Netscaler NS7000. For the ports

• The BGP port should really not be there, since it is not enabled. The connection was closed immediately. however, it shouldn't allow connection at all.
• HTTPS server allows SSL V2 ciphers which can give administrators false sense of security if they happen to use aged browser.
• UDP in general: Traceroute is enabled. bad. bad.
• TCP in general:

The remote host does not discard TCP SYN packets which
have the FIN flag set.

Depending on the kind of firewall you are using, an
attacker may use this flaw to bypass its rules.

See also : http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html
           http://www.kb.cert.org/vuls/id/464113
    
Solution : Contact your vendor for a patch
Risk factor : Medium
BID : 7487

====================================================================

The remote host accepts loose source routed IP packets.
The feature was designed for testing purpose.
An attacker may use it to circumvent poorly designed IP filtering
and exploit another flaw. However, it is not dangerous by itself.

Solution : drop source routed packets on this host or on other ingress
routers or firewalls.  


Risk factor : Low

Citrix Netscaler NS7000 : how to create a content switched load balanced farm/service (Part I)

The Netscaler (now Citrix) load balancer has pretty clear conceptual, logical, and work flow. That is, well, to a system/network engineer like me anyway. To touch it off visually by a GUI, all this is neatly grouped under the 'load balancing' leaf node and the 'content switching' leaf node on the left pane of the Applet or Web Start GUI.

• define servers. A server is created by a pair of server name and its physical IP address: node8/192.168.88.8 node9/192.168.88.9 ... node100/192.168.88.100.
  
• define services. A service is created by binding the server IP address with a service port (port number and protocol, e.g. TCP/80, UDP/53, UDP/123).
  

• Take web service for example, a service named "prod_web_node1" can be created by binding TCP/80 with node1's IP address.

• Custom and default health monitored can be applied to the service.
• Multiple monitors can be applied a service with different weight and such.
• Web service is the most popular for an application switch or a load balancer. In fact, it is the only protocol rendered capable of content-switching by the Citrix Netscaler series.
  
• create a load-balancing "virtual server" (From CLI, it is 'add lb vserver'.) to front a group of services to be load-balanced.
  
  • weight can be applied to each LB member service.
    
  • load balancing algorithm can be chosen (many variations of round-robin, least connection, LTRM, etc.)
    
  • advanced setting can be adjusted here, such as timeout values for an idle server or an idle client.
    

Any 'lb vserver' can be utilized in two different ways:

• As a public service by itself. It can be exposed to clients as a service by assigning a virtual IP:Port. In other words, the load balanced service group becomes a service usable by the clients (directly). If load balancing is all you need, your work is done here.
• As a private service to a Content Switching (CS) virtual server (vserver). No IP:port is assigned to it. In other words, the load balanced service group won't be a service usable by the clients (directly). It can only be accessed/referenced by its name, as an internal object, from within the Netscaler running context (aka, by the the content switching engine we'll discuss in Part II of this post) in the latter case. That's right, it is more like a call-by-reference.