Introducción a las prácticas recomendadas para la seguridad Citrix ADC MPX, VPX y SDX

Un dispositivo Citrix ADC MPX es un Controller de entrega de aplicaciones que acelera los sitios web, proporciona administración del tráfico L4-L7, ofrece Citrix Web App Firewall integrado y descarga servidores. Una instancia de Citrix ADC VPX es un dispositivo virtual que tiene todas las funciones de un dispositivo Citrix ADC MPX, se ejecuta en servidores estándar y proporciona una mayor disponibilidad para aplicaciones web, como Citrix XenDesktop y XenApp. Un dispositivo Citrix ADC SDX proporciona virtualización avanzada para toda la flexibilidad de VPX con el rendimiento de MPX. Con MPX, VPX y SDX, una organización puede implementar la solución flexible o multitenancy verdadera que optimiza su infraestructura de entrega de aplicaciones web al separar los servicios de red compartidos de alto volumen de los servicios específicos de aplicaciones y que requieren un uso intensivo de procesadores. Un dispositivo Citrix ADC también proporciona una integración perfecta con Citrix OpenCloud Access que puede ampliar el centro de datos con la potencia de la nube.

Para mantener la seguridad durante el ciclo de vida de la implementación, Citrix recomienda revisar las siguientes consideraciones para:

  • Seguridad física
  • Seguridad del dispositivo
  • Seguridad de red
  • Administración y Gestión

Diferentes implementaciones pueden requerir diferentes consideraciones de seguridad. Este documento proporciona instrucciones generales de seguridad para ayudarle a decidir sobre una implementación segura adecuada en función de sus requisitos de seguridad específicos.

Importante:

A partir de la versión 12.1 del software, NetScaler cambia de nombre a Citrix ADC. Para obtener más información, consulte https://www.citrix.com/about/citrix-product-guide/.

Directrices de implementación

Al implementar un Citrix ADC, tenga en cuenta las siguientes prácticas recomendadas de seguridad física y del dispositivo:

Prácticas recomendadas de seguridad física

Implemente el dispositivo Citrix ADC en una ubicación segura

Los dispositivos Citrix ADC deben implementarse en una ubicación segura con suficientes controles de acceso físico para proteger los dispositivos del acceso no autorizado. Como mínimo, el acceso a la sala de servidores debe controlarse con una cerradura, un lector de tarjetas electrónicas u otros métodos físicos similares.

Otras medidas pueden incluir el uso de un sistema de vigilancia electrónica, por ejemplo, CCTV, para monitorear continuamente la actividad de la sala. En caso de intrusión no autorizada, la salida de este sistema debe notificar al personal de seguridad. En el caso de CCTV, las imágenes grabadas están disponibles para fines de auditoría.

Acceso seguro al panel frontal del dispositivo y al puerto de la consola

El dispositivo Citrix ADC o el servidor de alojamiento VPX deben implementarse en un rack o jaula que se pueda bloquear con una clave adecuada u otros métodos físicos. El bloqueo impide el acceso a los puertos físicos del dispositivo Citrix ADC o, en el caso de una implementación de VPX, a la consola de host de virtualización.

Protección de la fuente de alimentación

El dispositivo Citrix ADC (o servidor de alojamiento) debe estar protegido con una fuente de alimentación ininterrumpida (UPS) adecuada. En caso de que se produzca un corte de energía, UPS garantiza el funcionamiento continuo del dispositivo o permite un apagado controlado de los ADC físicos o virtuales de Citrix. El uso de un SAI también ayuda en la protección contra picos de potencia.

Protección de clave criptográfica

Si se requiere protección adicional para las claves criptográficas de la implementación, considere el uso de un dispositivo compatible con FIPS 140-2 Nivel 2. La plataforma FIPS utiliza un módulo de seguridad de hardware para proteger las claves criptográficas críticas del dispositivo contra el acceso no autorizado.

Prácticas recomendadas de seguridad del dispositivo Citrix ADC

Realizar actualizaciones de software del dispositivo

Citrix recomienda encarecidamente que, antes de la implementación, los clientes se aseguren de que sus dispositivos se hayan actualizado con las últimas versiones de firmware. Cuando se lleva a cabo de forma remota, Citrix recomienda que los clientes usen un protocolo seguro, como SFTP o HTTPS, para actualizar el dispositivo.

También se recomienda a los clientes que revisen los boletines de seguridad relacionados con sus productos Citrix. Para obtener información sobre boletines de seguridad nuevos y actualizados, consulte la página web de los boletines de seguridad de Citrix (https://support.citrix.com/securitybulletins) y considere la posibilidad de registrarse para recibir alertas en boletines nuevos y actualizados.

Proteja el sistema operativo de los servidores que alojan un dispositivo Citrix ADC VPX

Un dispositivo Citrix ADC VPX puede ejecutar un dispositivo virtual en un servidor de virtualización estándar o como un dispositivo virtual en un Citrix ADC SDX.

Además de aplicar procedimientos de seguridad física normales, debe proteger el acceso al host de virtualización con un control de acceso basado en roles y una administración segura de contraseñas. Además, el servidor debe actualizarse con las revisiones de seguridad más recientes para el sistema operativo cuando estén disponibles, e implementar software antivirus actualizado en el servidor, si corresponde al tipo de virtualización. Los clientes que utilicen la plataforma Citrix ADC SDX para hospedar Citrix ADC VPX deben asegurarse de que están utilizando la última versión de firmware para su Citrix ADC SDX.

Restablecer la administración de luces apagadas de Citrix ADC (LOM)

Citrix recomienda que, antes de configurar la LOM para su uso en una implementación de producción, realice un restablecimiento de fábrica de la LOM para restaurar la configuración predeterminada.

  1. En el símbolo del sistema de shell de Citrix ADC, ejecute el siguiente comando:

    >ipmitool raw 0x30 0x41 0x1
    

    Nota: Alejecutar el comando anterior se restablece la LOM a la configuración predeterminada de fábrica y se eliminan todos los certificados SSL. Para obtener instrucciones acerca de cómo volver a configurar el puerto LOM, consulte [Apague el puerto de administración del dispositivo Citrix ADC MPX](/en-us/netscaler-hardware-platforms/mpx/netscaler-mpx-lights-out-management-port-lom.html

  2. En la GUI de LOM, vaya a Configuración > Certificación SSL y agregue un certificado y una clave privada.

    Además, Citrix recomienda encarecidamente que se lleve a cabo la siguiente configuración de usuario. Uso de la GUI de LOM:

    • Vaya a Configuración > Usuarios > Modificar usuario y cambie la contraseña de la cuenta densroot superusuario.
    • Vaya a Configuración > Usuarios > Modificar usuario y cree directivas para los usuarios o vincule las directivas existentes.
    • Vaya a Configuración > Control de acceso IP > Agregar y configurar el control de acceso IP para permitir el acceso al rango conocido de direcciones IP.
    • Vaya a Configuración > Usuarios > Modificar usuario, cree una cuenta de superusuario alternativa y vincule directivas a esta cuenta.

    Para obtener más información acerca de la configuración de LOM, consulte Configuración de LOM.

Mantenimiento y eliminación de datos persistentes

Si un Citrix ADC se vuelve a implementar en otro entorno, se retira o se devuelve a Citrix bajo RMA, asegúrese de que los datos persistentes se eliminan correctamente del dispositivo.

Para obtener más información acerca de este proceso, consulte las siguientes preguntas frecuentes: https://www.citrix.com/support/programs/faqs.html.

Directrices de configuración

Seguridad de red

Al implementar un dispositivo Citrix ADC en un entorno de producción, Citrix recomienda encarecidamente que se realicen los siguientes cambios clave de configuración:

  • La interfaz de administrador de Citrix ADC (NSIP) no debe estar expuesta a Internet.
  • Debe reemplazarse el certificado SSL predeterminado de Citrix ADC.
  • Se debe utilizar HTTPS (HTTP sobre TLS) al acceder a la GUI y la interfaz HTTP predeterminada inhabilitada.

En la siguiente sección se proporciona más información sobre estas consideraciones clave, además de los cambios que se recomiendan.

Consideraciones clave de seguridad de red

No exponga el NSIP a Internet:

Citrix recomienda encarecidamente que la IP de administración de Citrix ADC (NSIP) no esté expuesta a Internet pública y se implemente detrás de un firewall de inspección de paquetes (SPI) adecuado con estado.

Reemplace el certificado TLS predeterminado de Citrix ADC:

Durante la configuración inicial de un dispositivo Citrix ADC, se crean certificados TLS predeterminados. Estos certificados no están diseñados para su uso en implementaciones de producción y deben reemplazarse.

Citrix recomienda que los clientes configuren el dispositivo Citrix ADC para que use certificados de una entidad de certificación (CA) de confianza o certificados apropiados de la entidad emisora de certificados de su empresa.

Cuando se enlaza a un servidor virtual público, un certificado TLS válido de una CA de confianza simplifica la experiencia del usuario para aplicaciones web orientadas a Internet; los exploradores web de usuario no requieren interacción del usuario al iniciar una comunicación segura con el servidor web. Para reemplazar el certificado predeterminado de Citrix ADC por un certificado de CA de confianza, consulte el artículo CTX122521 de Knowledge Center: ““Cómo reemplazar el certificado predeterminado de un dispositivo Citrix ADC por un certificado de CA de confianza que coincida con el nombre de host del dispositivo.

Alternativamente, es posible crear y utilizar certificados TLS personalizados y claves privadas. Si bien esto puede proporcionar un nivel equivalente de seguridad de la capa de transporte, requiere que los certificados TLS se distribuyan a los usuarios y requiere la interacción del usuario al iniciar conexiones con el servidor web. Para obtener más información acerca de cómo crear certificados personalizados, consulte el artículo CTX121617 de Knowledge Center:Cómo crear e instalar certificados autofirmados en Citrix ADC Appliance.

Puede encontrar más información sobre la administración y configuración de certificados TLS en la sección “Recomendaciones de TLS de Citrix ADC” de esta guía.

Inhabilite el acceso HTTP a la interfaz de administrador:

Para proteger el tráfico a la interfaz administrativa y la GUI de Citrix ADC, el dispositivo Citrix ADC debe estar configurado para usar HTTPS. Siga estos pasos:

  • Cree un par de claves públicas y privadas RSA de 2048 bits o superior y use las claves para HTTPS y SSH para acceder a la dirección IP de Citrix ADC, reemplazando el par de claves públicas y privadas RSA de 512 bits aprovisionado de fábrica.

  • Configure el dispositivo para que utilice solo conjuntos de cifrado seguro y cambie el conjunto ‘DEFAULT’ de conjuntos de cifrado a conjuntos de cifrado sólidos en el dispositivo. Se recomienda utilizar la lista de conjuntos de cifrado TLS aprobados en la sección 3.3 de la publicación especial 800-52 de NIST (Revisión 1). Este documento se puede encontrar en el sitio web del NIST en la siguiente dirección: https://www.nist.gov/publications/guidelines-selection-configuration-and-use-transport-layer-security-tls-implementations?pub_id=915295

  • Configure el dispositivo para que utilice la autenticación de clave pública SSH para acceder a la interfaz de administrador. No utilice las claves predeterminadas de Citrix ADC. Cree y use su propio par de claves públicas y privadas RSA de 2048 bits. Para obtener más información, consulte el artículo CTX109011 del Centro de conocimiento: Cómo proteger el acceso SSH al dispositivo Citrix ADC con autenticación de clave pública.

  • Una vez configurado Citrix ADC para usar estos nuevos certificados, el acceso HTTP a la interfaz de administración de GUI se puede inhabilitar con el siguiente comando:

set ns ip <NSIP> -gui SECUREONLY

Para obtener más información acerca de cómo configurar el acceso seguro a la GUI de administración, consulte el artículo CTX111531 del Centro de conocimiento: Cómo habilitar el acceso seguro a la GUI de Citrix ADC mediante la dirección SNIP/MIP del dispositivo.

Otras consideraciones de seguridad de red

También se deben tener en cuenta las siguientes consideraciones de seguridad relacionadas con la red al implementar los dispositivos Citrix ADC:

Inhabilitar el reenvío de puertos SSH:

El dispositivo Citrix ADC no requiere el reenvío de puertos SSH. Si no desea usar esta funcionalidad, Citrix recomienda inhabilitarla siguiendo los pasos siguientes:

  1. Modifique el archivo /etc/sshd_config agregando la siguiente línea.

    AllowTCPForwarding no

  2. Guarde el archivo y cópielo en /nsconfig para que los cambios sean persistentes en caso de que se reinicie durante las pruebas.

Matar el proceso mediante el comando kill -SIGHUP <sshdpid> o reiniciar el sistema.

Configure el dispositivo Citrix ADC con alta disponibilidad:

En implementaciones en las que se requiere una operación continua, los dispositivos Citrix ADC se pueden implementar en una configuración de alta disponibilidad. Esta configuración proporciona un funcionamiento continuo si uno de los dispositivos deja de funcionar o requiere una actualización sin conexión.

Para obtener información sobre cómo configurar la configuración de alta disponibilidad, consulte el tema High Availability > Configuring High Availability en Documentos de Citrix y Cómo configurar un par de alta disponibilidad en Citrix ADC.

En implementaciones en las que no se requiere alta disponibilidad, esta función debe estar inhabilitada.

Configurar la comunicación segura entre dispositivos del mismo nivel:

Si ha configurado sus dispositivos Citrix ADC en una configuración de alta disponibilidad, clúster o GSLB, proteja la comunicación entre los dispositivos.

Para proteger la comunicación entre los dispositivos, Citrix recomienda cambiar la cuenta de usuario interna o la contraseña del nodo RPC. Los nodos RPC son entidades internas del sistema utilizadas para la comunicación de información de configuración y sesión de sistema a sistema.

Las funciones del dispositivo Citrix ADC también pueden utilizar la autenticación basada en clave SSH para la comunicación interna cuando la cuenta de usuario interna está inhabilitada. En tales casos, el nombre de la clave debe establecerse como “ns_comm_key”. Para obtener más información, consulte Acceda a un dispositivo Citrix ADC mediante claves SSH y sin contraseña.

Cambie las contraseñas predeterminadas:

Para mejorar la seguridad, Citrix recomienda cambiar las contraseñas del administrador y de la cuenta de usuario interna o del nodo RPC. Es aconsejable cambiar las contraseñas con frecuencia.

Configurar dominios de seguridad de red y VLAN:

Citrix recomienda encarecidamente que el tráfico de red a la interfaz de administración del dispositivo Citrix ADC esté separado, física o lógicamente, del tráfico de red normal. La mejor práctica recomendada es tener tres VLAN:

  • VLAN externa a Internet
  • VLAN de administración
  • VLAN del servidor interno

Citrix recomienda configurar la red para que el puerto LOM forme parte de la VLAN de administración.

Al implementar un dispositivo Citrix ADC en modo de dos brazos, dedique un puerto específico a una red específica. Si se requiere el etiquetado de VLAN y el enlace de dos redes a un puerto, debe asegurarse de que las dos redes tienen los mismos niveles de seguridad o similares.

Si las dos redes tienen diferentes niveles de seguridad, no se debe utilizar el etiquetado de VLAN. En su lugar, considere la posibilidad de dedicar un puerto para cada red específica y utilizar VLAN independientes distribuidas a través de los puertos del dispositivo.

Nota: Los dispositivos Citrix ADC VPX no admiten VLAN etiquetadas.

Considere el uso de Citrix Web App Firewall: un dispositivo con licencia Citrix ADC Platinum Edition proporciona un Citrix Web App Firewall integrado que utiliza un modelo de seguridad positivo y aprende automáticamente el comportamiento adecuado de las aplicaciones para protegerse frente a amenazas como la inyección de comandos, Inyección SQL y scripts entre sitios.

Cuando usa Citrix Web App Firewall, los usuarios pueden agregar seguridad adicional a la aplicación web sin cambios de código y con pocos cambios en la configuración. Para obtener más información, consulte la página web de Citrix ADC Citrix Web App Firewall.

Restringir el acceso a aplicaciones que no sean de administración: ejecute el siguiente comando para restringir la capacidad de las aplicaciones que no sean de administración para acceder a un dispositivo Citrix ADC.

set ns ip <NSIP> -restrictAccess enabled

Implementación segura de clústeres: si los nodos de clúster de Citrix ADC se distribuyen fuera del centro de datos, Citrix recomienda encarecidamente el uso de RPC seguro para la mensajería de nodo a nodo (NNM), AppNNM y la configuración de alta disponibilidad.

Para habilitar la función Secure RPC para todas las direcciones IP de Citrix ADC en un clúster de Citrix ADC y una configuración de alta disponibilidad, ejecute el siguiente comando:

set rpcnode <ip> -secure on

Nota: Es posible que se requiera otra configuración. Para obtener más información, consulte los temas de creación de clústeres en el sitio de Citrix Docs.

Cuando se implementa en una implementación de clúster L3, los paquetes entre nodos de Citrix ADC se intercambian a través de un túnel GRE sin cifrar que utiliza las direcciones NSIP de los nodos de origen y destino para el enrutamiento. Cuando el intercambio se produce a través de Internet, en ausencia de un túnel IPsec, los NSIP se exponen en Internet. Esto no se recomienda ya que no cumple con las prácticas recomendadas de seguridad para Citrix ADC.

Citrix recomienda encarecidamente que los clientes establezcan su propia solución IPSec para usar la función de clúster sobre L3.

Si la función de reenvío IP no está en uso, utilice el siguiente comando para inhabilitar el modo L3:

disable ns mode L3

Usar MEP seguro para el equilibrio de carga global del servidor (GSLB): Para cifrar el MEP entre dispositivos Citrix ADC para GSLB, ejecute el siguiente comando desde NSCLI:

set rpcNode <GSLB Site IP> -secure yes

Proteja la cookie de persistencia de equilibrio de carga:

Citrix recomienda cifrar la cookie de persistencia de equilibrio de carga además del canal SSL/TLS. Para obtener más información sobre cómo hacerlo, consulte persistencia de cookies HTTP.

Proteger el tráfico de paso a través en el dispositivo Citrix ADC mediante la configuración del modo de infraestructura

La configuración del modo de infraestructura de Citrix Web App Firewall se puede usar para proteger el tráfico de paso a través en el dispositivo Citrix ADC. Esta configuración del modo de infraestructura proporciona un nivel básico de seguridad sin romper ninguna aplicación. La siguiente lista resume la configuración del modo de infraestructura disponible.

  • Protección del estado de sesión
  • Protección de fijación de sesión (habilitar solo HTTP)
  • HSTS (habilitar la seguridad de transporte estricta HTTP (HSTS))
  • Autenticación sólida
  • SSL de extremo a extremo preferido (TLS 1.2 y TLS 1.1)
  • Proxy HTTPS/Denegar todo el resto del tráfico

Protección del estado de sesión:

Recomendación: Citrix ADC habilitado: Habilitado de forma predeterminada para la mayoría de las entidades

La opción Protección de estado de sesión está habilitada de forma predeterminada y no requiere ninguna configuración específica. Cuando el dispositivo Citrix ADC está configurado para proxy de una conexión. Por ejemplo, cuando el flujo selecciona un servidor virtual configurado o un servicio de tipo TCP o superior, el dispositivo Citrix ADC crea una sesión con estado. El dispositivo Citrix ADC continúa manteniendo el estado de estas conexiones y solo se procesan los paquetes que entran en este equipo de estado. Otros paquetes se eliminan o se restablecen.

Las siguientes entidades de tipo de servicio logran este comportamiento con estado en un dispositivo Citrix ADC.

  • ADNS_TCP
  • DIAMETER, DNS_TCP
  • FTP-C
  • GRE-c
  • HTTP
  • MYSQL, MSSQL
  • NNTP
  • ORACLE
  • PUSH, PPTP
  • RTSP, RDP
  • SIP_SSL, SIP_TCP
  • SMPP
  • SSL, SSL_BRIDGE, SSL_DIAMETER, SSL_PUSH
  • SSL_TCP, SYSLOG_TCP
  • TCP
  • ADNS_TCP
  • RNAT (rnat_tcpproxy está habilitado)

Protección de fijación de sesión (habilitando el indicador HttpOnly o agregando una directiva de reescritura):

Recomendación: Para habilitar HttpOnly para las cookies establecidas por el dispositivo Citrix ADC o el servidor back-end
Citrix ADC: Habilitado de forma predeterminada para las cookies insertadas de Citrix ADC, posible mediante Reescritura para las cookies establecidas por el servidor back-end.

HttpOnly: Cuando etiquetas una cookie con el indicador HttpOnly, indica al explorador que solo el servidor debe acceder a esta cookie. Cualquier intento de acceder a la cookie desde el script del cliente está estrictamente prohibido. Las cookies HttpOnly, si se implementan correctamente, hacen que enormes clases de ataques comunes de scripting entre sitios sean mucho más difíciles de lograr.

A continuación se muestra un ejemplo de una cookie con el indicador HttpOnly establecido:

Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/; HttpOnly

Las cookies insertadas por Citrix ADC para la persistencia de la inserción de cookies, de forma predeterminada, establecen el indicador HttpOnly para indicar que la cookie no es scriptable y no debe revelarse a la aplicación cliente. Por lo tanto, un script del lado del cliente no puede acceder a la cookie, y el cliente no es susceptible a scripts entre sitios.

Para habilitar la configuración del indicador HttpOnly mediante la interfaz de línea de comandos:

En el símbolo del sistema, escriba:

set lb parameter -HttpOnlyCookieFlag (ENABLED)  

Usar la directiva de reescritura para insertar Secure y HttpOnly para cookies:

La directiva de reescritura inserta Secure y HTTP solo para las cookies enviadas por el servidor back-end.

Nota: Las cookies seguras y HttpOnly juntas se pueden hacer para los VIP SSL. Para VIP que no son SSL uno puede insertar el indicador HttpOnly.

Con Citrix ADC, se pueden incluir solo los indicadores HTTP y Secure para las cookies establecidas por el servidor.

  • HttpOnly: Esta opción en una cookie hace que los exploradores web devuelvan la cookie mediante el protocolo HTTP (o HTTPS) solamente; los métodos no HTTP, como las referencias a JavaScript document.cookie no pueden acceder a la Cookie. Esta opción ayuda a prevenir el robo de cookies debido a scripts entre sitios.
  • Seguro: Esta opción en una cookie hace que los exploradores web devuelvan solo el valor de la cookie cuando la transmisión es cifrada por SSL. Esta opción se puede utilizar para evitar el robo de cookies a través de escuchas de conexión.

Para crear una directiva de reescritura mediante la interfaz de línea de comandos:

  1. Habilite la función Reescritura, si aún no está habilitada.

    enable feature REWRITE
    
  2. Cree una acción de reescritura (este ejemplo está configurado para establecer los indicadores Secure y HttpOnly. Si falta alguno de los dos, modifíquelo según sea necesario para otras combinaciones).

    add rewrite action <action name> replace_all http.RES.full_Header ""path=/; Secure; HttpOnly"" -search "regex(re!(path=/\\; Secure; HttpOnly)|(path=/\\; Secure)|(path=/\\; HttpOnly)|(path=/)!)" -bypassSafetyCheck YES
    

    Ejemplo:

    add rewrite action act_cookie_Secure replace_all http.RES.full_Header ""path=/; Secure; HttpOnly"" -search "regex(re!(path=/\\; Secure; HttpOnly)|(path=/\\; Secure)|(path=/\\; HttpOnly)|(path=/)!)" -bypassSafetyCheck YES
    
  3. Cree una directiva de reescritura para activar la acción.

    add rewrite policy <policy name> "http.RES.HEADER("Set-Cookie").EXISTS" <action name>
    

    Ejemplo:

    add rewrite policy rw_force_secure_cookie "http.RES.HEADER("Set-Cookie").EXISTS" act_cookie_Secure
    
  4. Enlazar la directiva de reescritura al servidor virtual que se va a proteger (si se utiliza la opción Secure, se debe utilizar un servidor virtual SSL).

    bind lb vserver <vserver name> - <policy name> -priority <priority number> -gotoPriorityExpression NEXT -type RESPONSE
    

    Ejemplo:

    bind lb vserver mySSLVServer -policyName rw_force_secure_cookie -priority 100 -gotoPriorityExpression NEXT -type RESPONSE
    

    Para obtener más información, consulte https://support.citrix.com/article/CTX138055.

HSTS (habilite HTTP Strict Transport Security (HSTS)):

Recomendación: Citrix ADC habilitado: En la versión 12.0 del software Citrix ADC, esta configuración se puede habilitar mediante la CLI. En las versiones 11.1 y anteriores del software Citrix ADC, esta configuración se puede habilitar mediante la directiva de reescritura.

  • En la versión 12.0 del software Citrix ADC, los dispositivos Citrix ADC admiten la seguridad de transporte estricta HTTP (HSTS) como una opción integrada en perfiles SSL y servidores virtuales SSL.

Para habilitar HSTS mediante la línea de comandos de Citrix ADC:

En el símbolo del sistema, escriba:

add ssl vserver <vServerName> -HSTS ( ENABLED ) maxage <positive_integer> -IncludeSubdomains ( YES | NO)

O

add ssl profile <name> -HSTS ( ENABLED ) -maxage <positive_integer> -IncludeSubdomains ( YES | NO )

Para obtener más información, consulte Configurar la compatibilidad con HTTP estricta seguridad de transporte (HSTS).

  • En las versiones 11.1 y anteriores del software Citrix ADC, se puede habilitar la seguridad estricta de transporte HTTP (HSTS) creando una directiva de reescritura y vinculándola globalmente o al servidor virtual en cuestión.

En el símbolo del sistema, escriba los siguientes comandos:

add rewrite action <action name> insert_http_header Strict-Transport-Security ""max-age=157680000\”"

add rewrite policy <policy name> “true” <action name>

bind lb vserver <vserver name> - <policy name> -priority <priority number> END -type RESPONSE

Ejemplo:

add rewrite action insert_STS_header insert_http_header Strict-Transport-Security ""max-age=157680000\”"

add rewrite policy enforce_STS "true” insert_STS_header

bind lb vserver vs1 -policyName enforce_STS -priority 100 -gotoPriorityExpression END -type RESPONSE

Para obtener más información, consulte estos temas:

https://support.citrix.com/article/CTX205221

https://www.citrix.com/blogs/2010/09/10/strict-transport-security-sts-or-hsts-with-citrix-netscaler-and-access-gateway-enterprise/

Autenticación segura:

La autenticación segura (o autenticación multifactor: MFA) debe estar habilitada para todo el acceso a datos confidenciales, aplicaciones y administración.

Para obtener más información sobre cómo se pueden configurar las aplicaciones confidenciales para la autenticación multifactor, consulte Autenticación de varios factores (nFactor).

SSL de extremo a extremo preferido (TLS 1.2 y TLS 1.1):

Se recomienda tener SSL tanto en el front-end como en el back-end. SSLv3 y TLS v1.0 se pueden inhabilitar en entidades SSL, ya que se han informado vulnerabilidades de seguridad. Solo puede tener TLS 1.1 y TLS 1.2 habilitados. Si es posible, tenga solo la versión de TLS 1.2 en el cliente frente a VIP. Se puede hacer en el nivel de entidad SSL o en el nivel de perfil y todas las entidades SSL heredan la configuración SSL del perfil.

Para inhabilitar entidades SSL mediante la interfaz de línea de comandos:

En el símbolo del sistema, escriba:

set ssl vserver <vServerName> -ssl2 DISABLED   -ssl3  DISABLED   -tls1   DISABLED

set ssl service <vServiceName> -ssl2 DISABLED   -ssl3  DISABLED   -tls1   DISABLED

Conjuntos de cifrado recomendados por Citrix ADC:

Los siguientes cifrados admitidos por Citrix ADC no incluyen ningún componente en la lista de “descartes obligatorios”. Estos cifrados se organizan por intercambio de claves (RSA, DHE y ECDHE) luego colocando los de mayor rendimiento en la parte superior con los de mayor seguridad en la parte inferior:

Recomendar conjuntos de cifrado de intercambio de claves de RSA:

  • TLS1-AES-128-CBC-SHA
  • TLS1-AES-256-CBC-SHA
  • TLS1.2-AES-128-SHA256
  • TLS1.2-AES-256-SHA256
  • TLS1.2-AES128-GCM-SHA256
  • TLS1.2-AES256-GCM-SHA384

Recomendamos conjuntos de cifrado de intercambio de claves DHE:

  • TLS1-DHE-RSA-AES-128-CBC-SHA
  • TLS1-DHE-RSA-AES-256-CBC-SHA
  • TLS1.2-DHE-RSA-AES-128-SHA256
  • TLS1.2-DHE-RSA-AES-256-SHA256
  • TLS1.2-DHE-RSA-AES128-GCM-SHA256
  • TLS1.2-DHE-RSA-AES256-GCM-SHA384

Recomendamos conjuntos de cifrado de intercambio de claves ECDHE:

  • TLS1-ECDHE-RSA-AES128-SHA
  • TLS1-ECDHE-RSA-AES256-SHA
  • TLS1.2-ECDHE-RSA-AES-128-SHA256
  • TLS1.2-ECDHE-RSA-AES-256-SHA384
  • TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
  • TLS1.2-ECDHE-RSA-AES256-GCM-SHA384

Recomendar conjuntos de cifrado en el orden de preferencia:

La siguiente lista de cifrados incluye intercambios de claves RSA, DHE y ECDHE. Proporciona el mejor compromiso entre seguridad, rendimiento y compatibilidad.

  1. TLS1.2-AES128-GCM-SHA256
  2. TLS1.2-AES-128-SHA256
  3. TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
  4. TLS1.2-ECDHE-RSA-AES-128-SHA256
  5. TLS1-ECDHE-RSA-AES128-SHA
  6. TLS1.2-DHE-RSA-AES128-GCM-SHA256
  7. TLS1.2-DHE-RSA-AES-128-SHA256
  8. TLS1-DHE-RSA-AES-128-CBC-SHA
  9. TLS1-AES-128-CBC-SHA

Proxy HTTPS/denegar el resto del tráfico:

Siempre que sea factible tener VIP SSL para un mejor cifrado de datos, mediante el uso de versiones SSL seguras (TLSv1.1 y TLSv1.2) y cifradores seguros. El rendimiento SSL TPS y SSL debe tenerse en cuenta al habilitar SSL para los VIP y los servicios SSL de back-end.

Administración y gestión

En esta sección se proporcionan ejemplos de cambios de configuración específicos que se pueden aplicar para aumentar la seguridad de los dispositivos Citrix ADC y Citrix ADC SDX. Puede encontrar más información sobre las prácticas recomendadas de configuración de Citrix ADC en el artículoConfiguración recomendada y prácticas recomendadas para una implementación genérica de un dispositivo Citrix ADC.

Cuentas del sistema y de usuario

Cambiar contraseña para la cuenta de superusuario: No se puede eliminar el superusuario administrador integrado (nsroot). Por lo tanto, cambie la contraseña predeterminada de esa cuenta a una contraseña segura. Para cambiar la contraseña predeterminada para el usuario administrador, realice los siguientes pasos:

  1. Inicie sesión como superusuario y abra la utilidad de configuración.
  2. En el panel de navegación, expanda el nodo Sistemas.
  3. Seleccione el nodo Usuarios.
  4. En la página Usuarios del sistema, seleccione el nsroot usuario.
  5. Seleccione Cambiar contraseña.
  6. Escriba la contraseña requerida en los campos Contraseña y Confirmar contraseña.
  7. Haga clic en OK.

Crear una cuenta de superusuario alternativa: Para crear una cuenta de superusuario, ejecute los siguientes comandos:

add system user <newuser> <password>

bind system user <newuser> superuser 0

Utilice esta cuenta de superusuario en lugar de la cuenta densroot superusuario predeterminada.

En las implementaciones de Citrix ADC SDX, un administrador debe cambiar las credenciales predeterminadas del dispositivo Citrix ADC SDX y su consola de administración de GUI después de la configuración inicial. Para cambiar la contraseña del usuario predeterminado, realice los siguientes pasos:

  1. Inicie sesión como superusuario y abra la utilidad de configuración.
  2. En el panel de navegación, expanda el nodo Sistemas.
  3. Seleccione el nodo Usuarios.
  4. En la página Usuarios del sistema, seleccione el usuario predeterminado.
  5. Seleccione Modificar.
  6. Escriba la contraseña requerida en los campos Contraseña y Confirmar contraseña.
  7. Haga clic en OK.

Nota: EnCitrix ADC versión 11.0 y posterior, los usuarios y administradores locales deben elegir contraseñas seguras. Ejemplos de requisitos de complejidad de contraseñas son los siguientes:

  • La contraseña debe tener una longitud mínima de ocho caracteres.
  • La contraseña no debe contener palabras de diccionario ni una combinación de palabras de diccionario.
  • La contraseña debe incluir al menos una letra mayúscula, una letra minúscula, un número y un carácter especial.

Las contraseñas seguras se pueden aplicar estableciendo dos parámetros, uno para la longitud mínima de las contraseñas y el otro para imponer la complejidad de las contraseñas:

set system parameter -localAuth ( ENABLED | DISABLED ) -minpasswordlen <positive_integer> -natPcbForceFlushLimit <positive_integer> -natPcbRstOnTimeout ( ENABLED | DISABLED )
-strongpassword ( ENABLED | DISABLED ) -promptString <string> -rbaOnResponse ( ENABLED | DISABLED ) -timeout <secs>

En implementaciones en las que se requieren varios administradores, considere la posibilidad de utilizar un método de autenticación externo para autenticar usuarios, por ejemplo RADIUS, TACACS+ o LDAP (S).

Acceder a Citrix ADC con claves SSH y sin contraseña: en implementaciones en las que se requiere administrar muchos dispositivos Citrix ADC, considere usar claves SSH y Sin contraseña. Para obtener información sobre cómo configurar esta función, consulte Acceda a un dispositivo Citrix ADC mediante claves SSH y sin contraseña.

Crear la clave maestra del sistema para la protección de datos: desde la versión de Citrix ADC 11.0, es necesario crear una clave maestra del sistema para proteger ciertos parámetros de seguridad, como las contraseñas de cuentas de servicio necesarias para la autenticación LDAP y la autenticación, autorización, y auditar cuentas de usuario. Para crear la clave maestra del sistema:

  1. Con la interfaz de línea de comandos, inicie sesión como administrador del sistema.
  2. Introduzca el siguiente comando:
create kek <file name>

Nota:

  • Después de ejecutar el comando create system kek, KEK se utiliza para la mayoría de los cifrados de contraseñas (las contraseñas de usuario locales no se cifran con KEK).
  • No debe eliminar el archivo KEK. Si tiene acceso al shell y elimina los archivos de fragmento de clave por error, puede resultar en pérdida de configuración, error de sincronización, error de inicio de sesión. Los siguientes son algunos de los puntos a tener en cuenta:

    • Utilice siempre un archivo de configuración anterior que coincida con la compilación que se está instalando al degradar; de lo contrario, el inicio de sesión, la configuración de origen, la sincronización y la conmutación por error podrían fallar.
    • Si alguno de los archivos de fragmento de clave se pierde o está dañado, el cifrado /descifrado de datos confidenciales da como resultado un error que a su vez podría resultar en pérdida de configuración, error de sincronización o error de inicio de sesión.
  • La frase de paso debe tener al menos 8 caracteres de longitud.

Usar listas de control de acceso:

De forma predeterminada, se puede acceder a todos los protocolos y puertos, incluidos GUI y SSH, en un dispositivo Citrix ADC. Las listas de control de acceso (ACL) pueden ayudarle a administrar el dispositivo de forma segura al permitir que solo los usuarios especificados explícitamente accedan a puertos y protocolos.

Recomendaciones para controlar el acceso al dispositivo:

  • Considere utilizar Citrix Gateway para limitar el acceso al dispositivo solo a la GUI. Para los administradores que requieren métodos de acceso además de la GUI, Citrix Gateway debe configurarse con una ACL “DENY” predeterminada para los puertos 80, 443 y 3010, pero con un “ALLOW” explícito para que las direcciones IP de confianza tengan acceso a estos puertos.

Esta directiva se puede ampliar para su uso con un rango de direcciones IP de confianza con el siguiente comando NSCLI:

add acl local_access allow -srcip 192.168.0.1-192.168.0.3 -destip 192.168.0.1-192.168.0.3

apply acls
  • Si utiliza SNMP, permita explícitamente el tráfico SNMP con ACL. A continuación se presenta un conjunto de comandos de ejemplo:
add acl snmp1-ssh ALLOW -srcip 10.0.0.1-10.0.0.20 -destip 192.168.0.2-192.168.0.3 -destport 161 -protocol udp

add acl snmp2-ssh ALLOW -srcip 172.16.0.1-172.16.0.20 -destip 192.168.0.2-192.168.0.3 –destport 161 -protocol udp

apply acls

En el ejemplo anterior, el comando proporciona acceso para todas las consultas SNMP a las dos subredes definidas, incluso si las consultas son para la comunidad definida adecuadamente.

Puede habilitar funciones de administración en direcciones NSIP, SNIP y MIP. Si está habilitado, proporcione acceso a las direcciones NSIP, SNIP, con ACL para proteger el acceso a las funciones de administración. El administrador también puede configurar el dispositivo de manera que no sea accesible con el comando ping.

  • Abrir primero la ruta más corta (OSPF) e IPSEC no son un protocolo basado en TCP o UDP. Por lo tanto, si necesita que el dispositivo admita estos protocolos, permita explícitamente el tráfico que utilice estos protocolos mediante una ACL. Ejecute el siguiente comando para definir una ACL para especificar OSPF e IPSEC por números de protocolo:
add acl allow_ospf allow -protocolnumber 89

add acl allow_ipsec allow –protocolnumber 50
  • Si se utiliza el servicio web XML-API, complete las siguientes tareas para proteger la interfaz API:
  • Proporcione permiso al host para acceder a la interfaz mediante una ACL. Por ejemplo, ejecute los siguientes comandos para habilitar los hosts del intervalo de direcciones IP 10.0.0.1-20 y 172.16.0.1-20 para acceder a la interfaz XML-API:
add acl xml-api1 ALLOW -srcip 10.0.0.1-10.0.0.20 -destip 192.168.0.2-192.168.0.3 -destport 80 -protocol tcp

add acl xml-api2 ALLOW -srcip 172.16.0.1-172.16.0.20 -destip 192.168.0.2-192.168.0.3 -destport 80 -protocol tcp

apply acls
  • Especifique el transporte seguro para el servicio web XML-API configurando un servidor front-end HTTPS en el dispositivo con una directiva de respuesta adecuada. Esto es aplicable al dispositivo que ejecuta el software Citrix ADC versión 8.0 o posterior. A continuación se presenta un conjunto de comandos de ejemplo:
enable ns feature responder

add responder policy allow_soap 'HTTP.REQ.URL.STARTSWITH("/soap").NOT' RESET

add lb vserver xml-https ssl 192.168.0.4 443

add server localhost 127.0.0.1

add service xml-service localhost HTTP 80

bind lb vserver xml-https xml-service

bind lb vserver xml-https -policyName allow_soap -type REQUEST -priority 1

add ssl certkey xml-certificate -cert testcert.cert -key testcert.key

bind ssl certkey xml-https xml-certificate

Utilice el control de acceso basado en roles para usuarios administrativos:

El dispositivo Citrix ADC incluye cuatro directivas de comandos o funciones, como operador, solo lectura, red y superusuario. También puede definir directivas de comandos, crear cuentas de administración diferentes para diferentes roles y asignar las directivas de comando necesarias para el rol a las cuentas. A continuación se muestra un conjunto de comandos de ejemplo para restringir el acceso de solo lectura al usuario de solo lectura:

add system user readonlyuser

bind system user readonlyuser read-only 0

Para obtener más información sobre la configuración de usuarios, grupos de usuarios o directivas de comandos, consulte Citrix Docs:

Configurar tiempo de espera de sesión del sistema:

Se proporciona un intervalo de tiempo de espera de sesión para restringir el tiempo durante el que una sesión (GUI, CLI o API) permanece activa cuando no se está utilizando. Para el dispositivo Citrix ADC, el tiempo de espera de la sesión del sistema se puede configurar en los siguientes niveles:

  • Tiempo de espera de nivel de usuario. Aplicable al usuario específico.

GUI: Vaya a Sistema > Administración de usuarios > Usuarios, seleccione un usuario y modifique la configuración de tiempo de espera del usuario. CLI: En la solicitud de comando, escriba el comando siguiente:

set system user <name> -timeout <secs>
  • Tiempo de espera de nivel de grupo de usuarios. Aplicable a todos los usuarios del grupo.

GUI: Vaya a Sistema > Administración de usuarios > Grupos, seleccione un grupo y modifique la configuración de tiempo de espera del grupo. CLI: En la solicitud de comando, escriba el comando siguiente:

set system group <groupName> -timeout <secs>
  • Tiempo de espera global del sistema. Aplicable a todos los usuarios y usuarios de grupos que no tienen un tiempo de espera configurado.

GUI: Vaya a Sistema > Configuración, haga clic en Establecer parámetros globales del sistema y establezca el parámetro ANY Client Idle Time Out (segundos). CLI: En la solicitud de comando, escriba el comando siguiente:

set system parameter -timeout <secs>

El valor de tiempo de espera especificado para un usuario tiene la prioridad más alta. Si el tiempo de espera no está configurado para el usuario, se considera el tiempo de espera configurado para un grupo de miembros. Si no se especifica el tiempo de espera para un grupo (o el usuario no pertenece a un grupo), se tendrá en cuenta el valor de tiempo de espera configurado globalmente. Si el tiempo de espera no está configurado en ningún nivel, el valor predeterminado de 900 segundos se establece como tiempo de espera de la sesión del sistema.

También puede restringir el valor de tiempo de espera para que el valor de tiempo de espera de sesión no se pueda configurar más allá del valor de tiempo de espera configurado por el administrador. Puede restringir el valor de tiempo de espera entre 5 minutos y 1 día. Para restringir el valor de tiempo de espera:

  • GUI: Vaya a Sistema > Configuración, haga clic en Establecer parámetros globales del sistema y seleccione el campo Tiempo de espera restringido.
  • CLI: En la solicitud de comando, escriba el comando siguiente:
set system parameter -restrictedtimeout <ENABLED/DISABLED>

Después de que el usuario habilite el parámetro RestrictedTimeout, y si el valor de tiempo de espera ya está configurado en un valor mayor de 1 día o inferior a 5 minutos, se notificará al usuario que cambie el valor de tiempo de espera. Si el usuario no cambia el valor de tiempo de espera, de forma predeterminada, el valor de tiempo de espera se reconfigurará a 900 segundos (15 minutos) durante el siguiente reinicio.

También puede especificar duraciones de tiempo de espera para cada una de las interfaces a las que está accediendo. Sin embargo, el valor de tiempo de espera especificado para una interfaz específica está restringido al valor de tiempo de espera configurado para el usuario que está accediendo a la interfaz. Por ejemplo, considere que un usuariopublicadmin tiene un valor de tiempo de espera de 20 minutos. Ahora, al acceder a una interfaz, el usuario debe especificar un valor de tiempo de espera que esté dentro de 20 minutos.

Para configurar la duración del tiempo de espera en cada interfaz:

  • CLI: Especifique el valor de tiempo de espera en el símbolo del sistema mediante el comando siguiente:
set cli mode -timeout <secs>
  • API: Especifique el valor de tiempo de espera en la carga de inicio de sesión.

Registro y supervisión

Configurar protocolo de hora de red

Citrix recomienda que el Protocolo de hora de red (NTP) esté habilitado en el dispositivo y configurado para utilizar un servidor de tiempo de red de confianza. Habilitar NTP garantiza que los tiempos registrados para las entradas de registro y los eventos del sistema sean precisos y estén sincronizados con otros recursos de red.

Al configurar NTP, el archivo ntp.conf debe modificarse para restringir que el servidor NTP divulgue la información en paquetes confidenciales.

Puede ejecutar los siguientes comandos para configurar NTP en el dispositivo:

add ntp server <IP_address> 10

enable ntp sync

Modifique el archivo ntp.conf para cada servidor NTP de confianza que agregue. Debe haber una entrada restringida correspondiente para cada entrada del servidor. Puede localizar el archivo ntp.conf ejecutando el find . –name ntp.conf comando desde el símbolo del shell del dispositivo.

Configurar SNMP

El dispositivo Citrix ADC admite la versión 3 del protocolo SNMP. SNMPv3 incorpora funciones de administración y seguridad tales como autenticación, control de acceso y comprobaciones de integridad de datos. Para obtener más información, consulte los temas Sistema > SNMP en Citrix Docs.

Si no configura al menos un administrador SNMP, el dispositivo acepta y responde las consultas SNMP de todas las direcciones IP de la red. Ejecute el siguiente comando para agregar un administrador SNMP y restringir este comportamiento:

add snmp manager <IP_address>

En implementaciones en las que no se requiere SNMP, la funcionalidad debe inhabilitarse con el siguiente comando:

set ns ip <IP_Address> -snmp disabled

Configurar el registro en el host de registro externo de Citrix ADC

Citrix ADC Audit Server registra todos los estados y la información de estado recopilada por diferentes módulos en el kernel y en los demonios de nivel de usuario. El Servidor de auditoría permite a un administrador hacer referencia al historial de eventos en orden cronológico. El Servidor de auditoría es similar al servidor SYSLOG que recopila los registros del dispositivo. El Servidor de auditoría utiliza las credenciales de administrador para obtener registros de uno o más dispositivos.

  • Configuración del servidor de auditoría local

Ejecute el siguiente comando para configurar el registro en el servidor de auditoría local en el dispositivo Citrix ADC: > set audit nslogparams –serverip <hostname> -serverport <port>

  • Configuración del servidor de auditoría remota

Para configurar el registro en el Servidor de auditoría en un equipo remoto, instale el Servidor de auditoría en ese equipo. A continuación se presentan ejemplos de opciones del servidor de auditoría:

./audserver -help
usage : audserver -[cmds] [cmd arguments]
cmds cmd arguments: -f <filename> -d debug
-help - detail help
-start - cmd arguements,[starts audit server]
-stop - stop audit server
-verify - cmd arguments [verifies config file]
-addns - cmd arguments [add a netscaler to conf file]
-version - prints the version info

Esto proporciona funcionalidad para registrar mensajes de auditoría generados únicamente por el archivo ns.log del dispositivo. Para registrar todos los mensajes de syslog, realice los siguientes pasos:

  1. Elimine las especificaciones del archivo de registro del archivo /nsconfig/syslog.conf para las instalaciones locales.
  2. Reemplace las especificaciones del archivo de registro por el nombre del host de registro o la dirección IP del host de syslog remoto, similar a las siguientes entradas:

    local0.* @10.100.3.53

    local1.* @10.100.3.53

  3. Configure el servidor syslog para que acepte entradas de registro de las instalaciones de registro anteriores. Para obtener más información, consulte la documentación del servidor syslog.
  4. Para la mayoría de los servidores basados en UNIX que utilizan el software syslog estándar, debe agregar una entrada de configuración local para los mensajes y los archivos nsvpn.log al archivo de configuración syslog.conf. Los valores de la instalación deben corresponder a los valores configurados en el dispositivo.
  5. El servidor de syslog remoto en cualquier equipo basado en UNIX de forma predeterminada no escucha los registros remotos. Por lo tanto, ejecute el siguiente comando para iniciar el servidor syslog remoto:
syslogd -m 0 –r

Nota: Consulte las opciones equivalentes de la variante syslog que se implementa en el servidor de auditoría.

Configuración de LOM

Citrix recomienda encarecidamente que se tomen las siguientes medidas para proteger la interfaz LOM:

  • No exponga el puerto LOM a Internet.
  • Implemente la LOM detrás de un firewall SPI.
  • Implemente el LOM en un segmento de red que esté separado lógicamente (VLAN independiente) o físicamente (LAN independiente) del tráfico de red que no es de confianza.
  • Establezca diferentes valores de nombre de usuario, contraseña, certificado SSL y clave SSL para los puertos de administración LOM y Citrix ADC.
  • Asegúrese de que los dispositivos utilizados para acceder a la interfaz de administración de LOM se dedican exclusivamente a un propósito de administración de red y se colocan en un segmento de red de administración que se encuentra en la misma LAN física o VLAN que otros puertos de dispositivos de administración.
  • Para identificar y aislar fácilmente las direcciones IP de LOM, reserve direcciones IP especiales (subredes privadas) para interfaces de administración de LOM y servidores de administración. No utilice subredes IP reservadas con interfaces LAN de los dispositivos administrados. No se recomiendan las direcciones IP dinámicas asignadas por DHCP, ya que dificultan la implementación de listas de control de acceso de firewall basadas en una dirección MAC fuera del segmento LAN.
  • Establezca la contraseña para un mínimo de 8 caracteres, con una combinación de caracteres alfanuméricos y especiales. Cambie la contraseña con frecuencia.

Aplicaciones y servicios

Configurar Citrix ADC para eliminar solicitudes HTTP no válidas

Citrix recomienda encarecidamente que el dispositivo Citrix ADC esté configurado con una comprobación y aplicación estrictas de las solicitudes HTTP para evitar que las solicitudes HTTP no válidas pasen a través de servidores virtuales. Esto se puede hacer vinculando un perfil HTTP integrado, nshttp_default_strict_validation, a uno o más servidores virtuales mediante el siguiente comando en la CLI:

show ns httpProfile (Shows the available http profile (default+user configured profiles))

set lb vserver <vserver name> -httpProfileName nshttp_default_strict_validation

Citrix recomienda que los clientes que utilicen esta opción prueben los cambios en un entorno provisional antes de lanzarlo a producción.

Configurar la protección contra ataques de denegación de servicio HTTP

El firmware del dispositivo Citrix ADC admite contramedidas limitadas contra ataques de denegación de servicio HTTP, incluidos ataques de tipo “lectura lenta”. Puede configurar estas funciones mediante la nsapimgr utilidad del símbolo del shell del dispositivo:

  • small_window_threshold (default=1)
  • small_window_idle_timeout (default=7 seg)
  • small_window_cleanthresh (default=100)
  • small_window_protection (default=habilitado)

La configuración predeterminada es adecuada para evitar los ataques de denegación de servicio HTTP, incluidos los ataques de lectura lenta; sin embargo, es posible que sea necesario ajustar los parámetros para otros ataques.

Para protegerse contra tales ataques, ajuste la small_window_threshold propiedad hacia arriba mediante el nsapimgr comando siguiente del símbolo del shell del dispositivo:

$ nsapimgr –ys small_window_threshold=<desired value>

Nota: El valorsmall_window_threshold deseado se puede establecer en función del patrón de tráfico entrante en la implementación. El rango aceptable es de 0 a 2^32.

Puede comprobar la protección contra ataques de denegación de servicio HTTP supervisando los siguientes contadores con el nsconmsg –d stats comando desde el símbolo del shell del dispositivo:

  • nstcp_cur_zero_win_pcbs: Este contador realiza un seguimiento del número de PCB que actualmente tienen un valor de ventana bajo.
  • nstcp_err_conndrop_at_pass: Este contador se incrementa cuando el dispositivo detecta que, al pasar paquetes de un lado a otro, ha superado el valor nscfg_small_window_idletimeout.
  • nstcp_err_conndrop_at_retx: Este contador se incrementa cuando el tiempo transcurrido durante la retransmisión supera el valor nscfg_small_window_idletimeout.
  • nstcp_cur_pcbs_probed_withka: Este contador realiza un seguimiento del número de PCB en la cola de sobretensiones que se sondean con un sondeo KA.

Citrix recomienda que los clientes que utilicen esta opción prueben los cambios en un entorno provisional antes de lanzarlo a producción.

Configurar Citrix ADC para defenderse contra ataques de suplantación TCP

Los siguientes comandos se pueden utilizar para ayudar a proteger los servidores back-end contra ataques de suplantación TCP:

set ns tcpProfile profile1 -rstWindowAttenuate ENABLED -spoofSynDrop ENABLED

Done

set lb vserver lbvserver1 -tcpProfileName profile1

Done

Citrix recomienda que los clientes que utilicen esta opción prueben los cambios en un entorno provisional antes de lanzarlo a producción.

Configurar Citrix ADC para aceptar encabezados HTTP específicos

Es posible configurar Citrix ADC para que acepte solo encabezados HTTP específicos. Esto se puede lograr agregando una acción de reescritura para restringir el tráfico de red con encabezados HTTP específicos y definidos para pasar al servidor back-end.

La siguiente acción global de reescritura envía al servidor solo el tráfico de red con encabezados como Host, Aceptar y probar:

add rewrite action act1 replace_all q/HTTP.REQ.FULL_HEADER.after_str("\r\n")/     q{TARGET.REGEX_SELECT(re/(iu)^(Host|Accept|test):.*\r\n/) ALT ""} -pattern q{re/(U).+:.+r\n/}

add rewrite policy pol1 HTTP.REQ.IS_VALID act1

bind rewrite global pol1 100

Nota: Estos comandos solo se admiten en Citrix ADC versión 10.5 y versiones posteriores.

Configuración de Close-Notify

Una notificación cercana es un mensaje seguro que indica el final de la transmisión de datos SSL. De conformidad con RFC 5246: El cliente y el servidor deben compartir el conocimiento de que la conexión está terminando para evitar un ataque de truncamiento. Cualquiera de las partes puede iniciar el intercambio de mensajes de cierre. Cualquiera de las partes puede iniciar un cierre enviando una alerta close_notify. Todos los datos recibidos después de una alerta de cierre se ignoran, a menos que se haya transmitido alguna otra alerta fatal, cada parte debe enviar una alerta close_notify antes de cerrar el lado de escritura de la conexión. Para asegurarse de que se capturan eventos de auditoría para eventos de terminación TLS, inicie sesión en la CLI como superusuario o sysadmin y ejecute los siguientes comandos:

set ssl parameter -sendCloseNotify y

save ns config

Recomendaciones de seguridad de DNSSEC

Citrix recomienda que se apliquen las siguientes recomendaciones a los clientes que utilizan DNSSEC:

Usar RSA 1024 bits o superior para claves privadas KSK/ZSK

NIST recomienda que los administradores de DNS mantengan ZSKs RSA/SHA-1 y/o RSA/SHA-256 de 1024 bits hasta el 01 de octubre de 2015.

Activar alarma SNMP para la expiración de la clave DNSSEC

De forma predeterminada, la alarma SNMP para la caducidad de la clave DNSSEC está habilitada en un dispositivo Citrix ADC. La notificación de caducidad de la clave se envía a través de una captura SNMP llamada dnskeyExpiry. Se envían tres variables MIB (dnskeyName, y dnskeyUnitsOfExpiry) junto con la captura SNMP dnskeyExpiry. Para obtener más información, consulte Citrix ADC SNMP OID Reference.

Descarte las claves privadas KSK/ZSK antes de que caduquen los certificados x.509

En un dispositivo Citrix ADC, puede usar los métodos de prepublicación y firma doble para realizar un rollover de la clave de firma de zona y la clave de firma de clave. Para obtener más información, consulte el tema Sistema de nombres de dominio > Configuración de DNSSEC en los documentos de Citrix.

Servidor ADNS de DNSSEC seguro

Si el dispositivo está configurado en modo proxy DNSSEC, almacena en caché las respuestas del servidor ADNS back-end y reenvía las respuestas almacenadas en caché a los clientes DNS.

Cuando el dispositivo Citrix ADC es autorizado para una zona determinada, todos los registros de recursos de la zona se configuran en Citrix ADC. Para firmar la zona autorizada, debe crear las claves (la clave de firma de zona y la clave de firma de clave) para la zona, agregar las claves al ADC y, a continuación, firmar la zona

Para configurar Citrix ADC como un servidor autorizado, lleve a cabo los siguientes pasos:

  1. Agregue un servicio de ADNS.

    Por ejemplo:

    add service s1 <ip address> adns 53`
    
  2. Crear claves DNS.

    Por ejemplo, para actuar como un servidor autorizado para el com dominio:

    create dns key -zoneName com -keytype ksK -algorithm rsASHA1 -keysize 3000 -fileNamePrefix com.ksk.rsasha1.3000
    
    create dns key -zoneName com -keytype zsk -algorithm rsASHA1 -keysize 3000 -fileNamePrefix com.zsk.rsasha1.3000
    

    Nota: Debe crear las claves DNS una vez y se guardan en /nsconfig/dns.

  3. Agregar claves DNS.

    Por ejemplo:

    add dns key com.zsk.3000 /nsconfig/dns/com.zsk.rsasha1.3000.key /nsconfig/dns/com.zsk.rsasha1.3000.private
            add dns key com.ksk.3000 /nsconfig/dns/com.ksk.rsasha1.3000.key /nsconfig/dns/com.ksk.rsasha1.3000.private
    
  4. Agregue registros NS y SOA para la com zona y, a continuación, firme la zona.

    add dns soaRec com -originServer n1.com -contact citrix
    add dns nsrec com n1.com
    add dns zone com -proxyMode no
    add dns addRec n1.com 1.1.1.1

    sign dns zone com

Nota: Además, también debe habilitar el parámetro DNSEC Extension en los parámetros globales DNS.

Para obtener más información sobre cómo configurar Citrix ADC como un servidor de nombres de dominio autorizado, consulte el tema Sistema de nombres de dominio > Configurar Citrix ADC como un servidor ADNS en Citrix Docs.

Configuración heredada

Configurar Citrix ADC para inhabilitar la redirección SSLv2

Si habilita la función de redirección SSL v2 en un dispositivo Citrix ADC, el dispositivo realiza el protocolo de enlace SSL y redirige el cliente a la dirección URL configurada. Si esta función está inhabilitada, el dispositivo niega realizar el proceso de protocolo de enlace SSL con clientes SSL v2.

Ejecute el siguiente comando para inhabilitar el redireccionamiento SSLv2:

set ssl vserver <vserver_name> -sslv2redirect DISABLED -cipherredirect DISABLED

Nota: A partir de la versión 9.2 del software Citrix ADC, las funciones de redirección y redirección de cifrado SSLv2 están inhabilitadas de forma predeterminada.

Configurar Citrix ADC versión 10.0 y versiones anteriores para utilizar la renegociación SSL segura

Para configurar Citrix ADC para evitar la renegociación SSL no segura para la versión 9.3e o 10.0 del software Citrix ADC, ejecute el siguiente comando:

set ssl parameter -denySSLReneg NONSECURE

Para versiones anteriores del software Citrix ADC, ejecute el siguiente comando para inhabilitar la renegociación SSL:

set ssl parameter -denySSLReneg ALL

El siguiente comando permite la renegociación solo para clientes y servidores seguros:

set ssl parameter -denySSLReneg NONSECURE

“Para obtener más información, consulte Cómo configurar y utilizar el parámetro -denysslReneg”.

Recomendaciones criptográficas de Citrix ADC

En esta sección se detallan algunos pasos clave que se deben seguir para garantizar que el material criptográfico esté correctamente protegido en el dispositivo Citrix ADC. También proporciona información sobre cómo configurar dispositivos para que utilicen este material para proteger tanto el propio dispositivo, como los servidores back-end y los usuarios finales.

Administración de certificados y claves TLS

Configuración de conjuntos de cifrado TLS para implementaciones de NDPP

Para obtener la lista de conjuntos de cifrado TLS compatibles con implementaciones de NDPP, consulte https://www.citrix.com/content/dam/citrix/en_us/documents/downloads/netscaler-adc/Common-criteria-documents-for-NetScaler-10.5.zip

Para asegurarse de que solo se configuran los conjuntos de cifrado aprobados en el dispositivo, complete los siguientes pasos de configuración desde la CLI:

  1. Desvincular todos los cifrados del servidor virtual

    unbind ssl vs v1 –cipherName FIPS
    
  2. Enlace solo TLS1-AES-256-CBC-SHA y luego TLS1-AES-128-CBC-SHA con el comando:

    bind ssl vs v1 –cipherName <cipher>
    
    bind ssl vs v1 -cipherName TLS1-AES-256-CBC-SHA
    

Importación de un certificado de CA raíz de confianza:

  1. Mediante una utilidad de transferencia segura de archivos, comoscp oWinSCP, transferir el certificado del emisor del servidor (raíz) al directorio /nsconfig/ssl del dispositivo Citrix ADC.

    Nota: Debe autenticarse como superusuario a través de SCP o WinSCP para completar este paso.

  2. Inicie sesión en el dispositivo Citrix ADC como administrador del sistema o superusuario y escriba el siguiente comando:

add ssl certkey <Certificate_Name> –cert <Cert_File_Name>

Nota: Instale únicamente los certificados de CA raíz de entidades emisoras de certificados que se sepa que son de confianza. Elimine todos los demás certificados.

Importación de un archivo de clave y certificado PKCS #12 (.PFX):

Puede encontrar información detallada sobre cómo se pueden importar archivos de certificados y claves en el dispositivo Citrix ADC en los temas de descarga y aceleración SSL > Importación de certificados y claves existentes en la Documentación del producto Citrix.

  1. Transfiera el archivo.pfx al directorio /nsconfig/ssl, como se mencionó en el paso 1 de la sección anterior.

  2. Autenticación en el dispositivo Citrix ADC a través de la CLI como administrador de sistema o superusuario y ejecute el siguiente comando:

    convert ssl pkcs12 Cert-Client-1.pfx -export -certFile Cert-Client-1 -keyFile Key-Client-1
    
  3. Agregue el certificado al dispositivo Citrix ADC de la siguiente manera:

    add ssl certkey Clent-Cert-1 –cert Cert-Client-1
    
  4. Guarde la configuración actual.

    save ns config
    

Nota: A partir de la versión de Citrix ADC 11.0, el archivo PKCS #12 (.PFX) se convierte automáticamente a PEM y todos los certificados se agregan y vinculan automáticamente a la CA.

Instalación de certificados y pares de claves mediante una CA de confianza:

Para obtener un certificado de una entidad emisora de certificados (CA) pública o de empresa, primero debe generar una clave privada y una solicitud de firma de certificados (CSR). Siga estos pasos:

  1. Autenticar en la CLI de Citrix ADC como administrador de sistemas o superusuario.

  2. Cree una clave privada RSA.

    create fipsKey m1 -modulus 2048
    
  3. Cree la solicitud de firma de certificado (CSR):

    create certreq csr_1 -fipsKeyName m1 -countryName IN -stateName BA -organizationName citrix
    
  4. Envíe la CSR a la CA.

Para la mayoría de las CA comerciales y empresariales, la CSR se envía en una solicitud de correo electrónico. Sin embargo, el método de envío puede variar según los entornos de CA empresariales. La CA devuelve un certificado válido por correo electrónico, pero esto también puede variar entre CA de la empresa. Después de recibir el certificado de la CA, cópielo de forma segura en el directorio /nsconfig/ssl.

Inicie sesión como superusuario o sysadmin y ejecute el siguiente comando desde la CLI: > add ssl certKey ck_1 -cert cert1_1 -fipsKey m1

Recomendaciones de Citrix ADC-FIPS

Configuración de Citrix ADC SDX en una implementación basada en FIPS

Si ya es cliente de FIPS y utiliza un dispositivo Citrix ADC SDX para una verdadera multitenancy, utilice el dispositivo Citrix ADC MPX certificado por FIPS para finalizar TLS y reenviar tráfico al dispositivo Citrix ADC SDX. Alternativamente, es posible utilizar un HSM externo Thales. Cambie las contraseñas de la tarjeta criptográfica FIPS cuando use una versión certificada por FIPS de Citrix ADC con un módulo de seguridad de hardware (HSM), cambie el oficial de seguridad (SO) predeterminado y establezca una nueva contraseña de usuario de la siguiente manera. Si no conoce la contraseña SO predeterminada de un dispositivo Citrix ADC habilitado para FIPS, póngase en contacto con el servicio de soporte técnico de Citrix. Nota: Solo un superusuario o administrador de sistema puede llevar a cabo esta tarea.

set ssl fips -initHSM Level-2 <soPassword> <oldSoPassword> <user-Password> [-hsmLabel <string>]

save configuration

initHSM

Nivel de inicialización FIPS. El dispositivo admite actualmente el nivel 2 (FIPS 140-2). Este es un argumento obligatorio. Valores posibles: Level-2

HSMLabel

Etiqueta para identificar el módulo de seguridad de hardware (HSM).

Longitud máxima: 31

Nota: Todos los datos de la tarjeta FIPS se borran con el comando anterior.

Almacene la contraseña de HSM en una ubicación segura

La contraseña del HSM debe almacenarse en una ubicación segura de acuerdo con los procedimientos operativos de su empresa.

Nota: El HSM se bloquea después de tres intentos de inicio de sesión fallidos. Cuando se bloquea, deja de funcionar y no se puede modificar su configuración.

Otras funciones: Citrix Web App Firewall y Citrix Gateway

En esta sección se proporcionan ejemplos de cambios de configuración que se pueden aplicar tanto a Citrix Web App Firewall como a Citrix Gateway para mejorar la seguridad de los dispositivos implementados. Esta sección también contiene información sobre la creación de varios niveles o seguridad.

Recomendaciones de seguridad de Citrix Web App Firewall

Implementar el dispositivo en el modo de dos brazos

Con una instalación en modo de dos brazos, el dispositivo se encuentra físicamente entre los usuarios y los servidores web que protege el dispositivo. Las conexiones deben pasar a través del dispositivo. Esta disposición minimiza las posibilidades de encontrar una ruta alrededor del dispositivo.

Usar una directiva de “Denegación predeterminada”

Citrix recomienda que los administradores configuren Citrix Web App Firewall con una directiva de denegar todo a nivel global para bloquear todas las solicitudes que no coincidan con una directiva de Citrix Web App Firewall. A continuación se muestra un conjunto de comandos de ejemplo para configurar una directiva de “denegar todo” a nivel global:

add appfw profile default_deny_profile –defaults advanced

add appfw policy default_deny_policy NS_TRUE default_deny_profile

bind appfw global default_deny_policy <PRIORITY>

Nota: La configuración PRIORIDAD debe asegurarse de que la directiva predeterminada se evalúa en última instancia (solo si la solicitud no coincide con ninguna otra directiva configurada).

La versión 9.2 del software Citrix ADC incluye perfiles predeterminados, como appfw_block, que cuando se configuran las solicitudes de bloqueo que no coinciden con las directivas de Citrix Web App Firewall. Ejecute el siguiente comando para establecer el perfil predeterminado:

set appfw settings -defaultProfile appfw_block

Citrix Web App Firewall: Creación de varios niveles de seguridad

Las siguientes pautas le ayudan a crear varios niveles de seguridad en función del entorno y de las aplicaciones admitidas.

Primer nivel de seguridad

Para crear el primer nivel de seguridad, realice lo siguiente:

  • Habilite Desbordamiento de búfer, inyección SQL y scripts entre sitios.
  • La URL de inicio es necesaria cuando la aplicación es particular en qué URL se debe acceder y deben protegerse contra la navegación forzosa.
  • Habilitar Comprobaciones de formato de campo si la aplicación espera entradas en un campo de formulario.

La comprobación de scripts entre sitios podría generar falsos positivos, ya que muchas empresas tienen una gran base instalada de contenido web mejorado de JavaScript que infringe la misma regla de origen. Si habilita la comprobación HTML Cross-Site Scripting en dicho sitio, debe generar las excepciones adecuadas para que la comprobación no bloquee la actividad legítima.

Implementación el primer nivel, busque falsos positivos, implementación las excepciones y luego pase al siguiente nivel. Una implementación por etapas ayuda a administrar la implementación de AppFW.

Segundo nivel de seguridad

Para crear el segundo nivel de seguridad, realice lo siguiente:

Habilite Firmas en el perfil además de Desbordamiento de búfer, inyección SQL y scripts entre sitios. Hay más de 1300 firmas. Intente habilitar solo las firmas que sean aplicables para proteger su aplicación, en lugar de habilitar todas las reglas de firma.

Implementación el segundo nivel, busque falsos positivos, implementación las excepciones y luego pase al siguiente nivel. Una implementación por etapas ayuda a administrar la implementación de Citrix Web App Firewall.

Tercer nivel de seguridad

Para crear el tercer nivel de seguridad, realice lo siguiente:

  • En función de las necesidades de la aplicación, habilite las comprobaciones de seguridad avanzada del perfil, como el etiquetado CSRF, la coherencia de las cookies. Consistencia del campo de formulario en las partes de las aplicaciones que lo necesitan.
  • Las comprobaciones de seguridad avanzadas requieren más procesamiento y pueden afectar al rendimiento. A menos que su aplicación necesite seguridad avanzada, es posible que quiera comenzar con un perfil básico y reforzar la seguridad según sea necesario para su aplicación.

Las comprobaciones de seguridad inhabilitadas en el perfil básico de Citrix Web App Firewall funcionan en objetos de la respuesta HTTP. Por lo tanto, estas comprobaciones de seguridad requieren más recursos. Cuando Citrix Web App Firewall realiza protecciones de respuesta, debe recordar la información enviada a cada cliente individual. Por ejemplo, si un formulario está protegido por Citrix Web App Firewall, la información de campo de formulario enviada en la respuesta se conserva en la memoria. Cuando el cliente envía el formulario en la siguiente solicitud posterior, se comprueba si hay incoherencias antes de enviar la información al servidor web. Este concepto se conoce como Sessionization. Las comprobaciones de seguridad como el gabinete de URL dentro de la URL de inicio, la coherencia de las cookies, la coherencia de los campos de formulario y el etiquetado de formularios CSRF implican la sesión. La cantidad de recursos de CPU y memoria utilizados por estas comprobaciones de seguridad aumenta linealmente con el número de solicitudes enviadas a través de Citrix Web App Firewall. Por ejemplo:

  • Habilitar comprobación de coherencia de campos de formulario: Esta comprobación es necesaria para verificar si el cliente no modificó los formularios web de forma inadecuada. Una aplicación que sirva y aloje información crítica en formularios necesitaría la comprobación.

  • Comprobación de etiquetado de formularios CSRF: Esta comprobación es para formularios. El etiquetado de formularios de falsificación de sitios cruzados (CSRF) marca cada formulario web enviado por un sitio web protegido a los usuarios con un ForMID único e impredecible, y luego examina los formularios web devueltos por los usuarios para asegurarse de que el ForMID suministrado es correcto. Esta comprobación protege contra ataques de falsificación de solicitudes entre sitios. Esta comprobación debe estar habilitada si la aplicación tiene formularios basados en web. Esta comprobación requiere relativamente poca capacidad de procesamiento de CPU en comparación con otras comprobaciones de seguridad que analizan los formularios web en profundidad. Por lo tanto, es capaz de manejar ataques de gran volumen sin degradar seriamente el rendimiento del sitio web protegido o del propio Citrix Web App Firewall.

Pasos del flujo de trabajo de Citrix Web App Firewall

El siguiente diagrama ilustra los pasos del flujo de trabajo de Citrix Web App Firewall:

Pasos del flujo de trabajo de Citrix Web App Firewall

Los siguientes son los pasos de alto nivel implicados en el flujo de trabajo de Citrix Web App Firewall:

  1. Configure el perfil de seguridad.
  2. Aplicar firmas para todas las amenazas conocidas: El modelo negativo.
  3. Configure directivas de tráfico que puedan detectar el flujo de tráfico correcto donde se debe activar este perfil de seguridad.

Está listo para que el tráfico de producción pase a través del sistema. Se completa el primer nivel de flujo. Además, configure la infraestructura de aprendizaje. Muchas veces, los clientes quieren aprender en el tráfico de producción, por lo que tener las firmas aplicadas evita cualquier riesgo. Realice los siguientes pasos: a. Configure la infraestructura de aprendizaje. b. Implementar las reglas aprendidas para la protección. c. Validar los datos de aprendizaje junto con las firmas aplicadas antes de empezar a trabajar.

Recomendaciones de seguridad de Citrix Gateway

Usar una directiva de “Denegación predeterminada”

Citrix recomienda que los administradores configuren Citrix Gateway con una directiva de “denegar todo” a nivel global, además del uso de directivas de autorización para habilitar selectivamente el acceso a los recursos en grupo.

De forma predeterminada, el parámetro DefaultAuthorizationAction se establece en DENY. Verifique esta configuración y conceda acceso explícito a cada usuario. Puede utilizar el comando show defaultAuthorizationAction en la CLI para verificar la configuración. Para establecer el parámetro para denegar todos los recursos a nivel global, ejecute el siguiente comando desde la CLI:

set vpn parameter -defaultAuthorizationAction DENY

Usar comunicación TLS1.1/1.2 entre servidores

Citrix recomienda encarecidamente que se utilice TLS1.1/1.2 para los vínculos entre el dispositivo Citrix Gateway y otros servicios, como los servidores de interfaz web y LDAP. No se recomienda el uso de versiones anteriores de este protocolo, 1.0, y SSLv3 y anteriores.

Utilice la función “Aplicaciones de intranet” Usar aplicaciones de intranet para definir qué redes interceptan el complemento Citrix Gateway y se envían a la Gateway. A continuación se presenta un conjunto de ejemplos de comandos para definir la intercepción:

add vpn intranetApplication intra1 ANY 10.217.0.0 -netmask 255.255.0.0 -destPort 1-65535 -interception TRANSPARENT

bind vpn vserver v1 –intranetapp intra1

Recursos adicionales de información

Consulte los siguientes recursos para obtener información de seguridad adicional acerca de los dispositivos Citrix ADC y Citrix Gateway:

Para obtener más ayuda con la configuración de su Citrix ADC, puede enviar una solicitud de soporte en:https://www.citrix.com/support.html

Introducción a las prácticas recomendadas para la seguridad Citrix ADC MPX, VPX y SDX