Introducción a las prácticas recomendadas para la seguridad de 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. Mediante MPX, VPX y SDX, una organización puede implementar la solución flexible o de multitenencia real que optimiza su infraestructura de entrega de aplicaciones web al separar los servicios de red compartida de alto volumen de los servicios específicos de la aplicación intensiva del procesador. Un dispositivo Citrix ADC también proporciona la 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 orientación general de seguridad para ayudarle a decidir una implementación segura adecuada en función de sus requisitos de seguridad específicos.

Importante:

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

Pautas de implementación

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

Prácticas recomendadas de seguridad física

Implementar 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, 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, el material grabado está disponible 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 una 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 VPX, a la consola del 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 UPS también ayuda en la protección contra picos de potencia.

Protección de claves criptográficas

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áctica recomendada 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 versiones de firmware más recientes. Cuando se lleva a cabo de forma remota, Citrix recomienda que los clientes utilicen 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 Boletines de seguridad de Citrix (https://support.citrix.com/securitybulletins) y considere la posibilidad de suscribirse para recibir alertas sobre 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 dispositivo virtual en un dispositivo Citrix ADC SDX.

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

Restablecer la administración de luces 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 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 [Ilumina 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. Mediante la GUI LOM:

    • Vaya a Configuración > Usuarios > Modificar usuario y cambie la contraseña de la cuenta de nsroot superusuario.
    • Vaya a Configuración > Usuarios > Modificar usuario y cree directivas para los usuarios, o enlaza las directivas existentes a ellos.
    • 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 dispositivo Citrix ADC se vuelve a implementar en otro entorno, se retira o se devuelve a Citrix con 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.

Pautas 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 de configuración clave:

  • La interfaz de administrador (NSIP) de Citrix ADC 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 adicionales recomendados.

Consideraciones clave de seguridad de la 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.

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 utilice certificados de una entidad emisora de certificados (CA) de confianza o certificados apropiados de la entidad emisora de certificados de 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 del 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 de Citrix ADC y la interfaz gráfica de usuario, el dispositivo Citrix ADC debe configurarse para usar HTTPS. Siga estos pasos:

  • Cree un par de claves públicas y privadas RSA de 2048 bits o superior y utilice 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 aprovisionadas de fábrica de 512 bits.

  • 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 utilice 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 Citrix ADC GUI mediante la dirección SNIP/MIP del dispositivo.

Otras consideraciones de seguridad de la red

Las siguientes consideraciones de seguridad relacionadas con la red también deben tenerse en cuenta al implementar los dispositivos Citrix ADC:

Inhabilitar el reenvío de puertos SSH:

El reenvío de puertos SSH no es necesario para el dispositivo Citrix ADC. Si no quiere 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 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 donde se requiere un funcionamiento continuo, los dispositivos Citrix ADC se pueden implementar en una configuración de alta disponibilidad. Dicha 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 una comunicación segura entre dispositivos de pares:

Si ha configurado los 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 y habilitar la opción Secure. 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 Acceder a un dispositivo Citrix ADC mediante claves SSH y sin contraseña.

Cambie las contraseñas predeterminadas:

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

Configurar los dominios de seguridad de red y las 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 de Internet fuera
  • 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 es necesario etiquetar VLAN y vincular dos redes a un puerto, debe asegurarse de que las dos redes tengan los mismos niveles de seguridad o similares.

Si las dos redes tienen niveles de seguridad diferentes, 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.

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 utiliza 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 Citrix ADC Citrix Web App Firewall.

Restringir el acceso a aplicaciones que no son de administración: ejecute el siguiente comando para restringir la capacidad de las aplicaciones que no son 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 RPC segura para todas las direcciones IP de Citrix ADC en un clúster de Citrix ADC y una instalació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 Clustering 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 no cifrado 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 utilizar la función 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 de servidor global (GSLB): para cifrar el MEP entre los dispositivos Citrix ADC para GSLB, ejecute el siguiente comando desde NSCLI:

set rpcNode <GSLB Site IP> -secure yes

Proteja la cookie de persistencia del equilibrio de carga:

Citrix recomienda cifrar la cookie de persistencia del 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 del 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 utilizar para proteger el tráfico de paso a través en el dispositivo Citrix ADC. Estas configuraciones de modo de infraestructura proporcionan 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 configuración Protección del 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 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 descartan 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
  • EMPUJAR, PPTP
  • RTSP, RDP
  • SIP_SSL, SIP_TCP
  • SMPP
  • SSL, SSL_BRIDGE, SSL_DIÁMETRO, 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: Activado de forma predeterminada para las cookies insertadas de Citrix ADC, posible a través de Rewrite 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 ejecutar.

El siguiente es 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 VIP SSL. Para VIP que no sean SSL se puede insertar el indicador HttpOnly.

Con Citrix ADC, se pueden incluir únicamente HTTP y banderas 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 del espionaje de conexión.

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

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

    enable feature REWRITE
    
  2. Crear una acción de reescritura (este ejemplo está configurado para establecer los indicadores Secure y HttpOnly. Si falta cualquiera de las 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 desencadenar 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 quiere 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 la seguridad de transporte estricta HTTP (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 incorporada 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, la seguridad de transporte estricta HTTP (HSTS) se puede habilitar creando una directiva de reescritura y vinculando 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 end-to-end 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

Los 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 mediante intercambio de claves (RSA, DHE y ECDHE) y 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 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

Recomendar 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

Recomendar 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

Recomiende suites Cipher en el orden de preferencia:

La siguiente lista de cifrados incluye los 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 todo el resto del tráfico:

Siempre que sea factible contar con VIP SSL para un mejor cifrado de datos, mediante el uso de versiones SSL seguras (TLSV1.1 y TLSV1.2) y cifrados seguros. Debe tenerse en cuenta el rendimiento SSL TPS y SSL mientras se habilita SSL para los VIP y los servicios SSL back-end.

Administración y gestión

Esta sección proporciona 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ículo Configuración recomendada y prácticas recomendadas para una implementación genérica de un dispositivo Citrix ADC.

Cuentas de usuario y sistema

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 del 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 Aceptar.

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 de nsroot superusuario predeterminada.

Para las implementaciones de Citrix ADC SDX, un administrador debe cambiar las credenciales predeterminadas del dispositivo Citrix ADC SDX y su consola de administración 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 Aceptar.

Nota: Desde Citrix ADC versión 11.0 y posterior, los usuarios locales y administradores 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 del diccionario ni una combinación de palabras del diccionario.
  • La contraseña debe incluir al menos una letra mayúscula, una minúscula, un número y un carácter especial.

Las contraseñas seguras se pueden imponer estableciendo dos parámetros, uno para la longitud mínima de 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 donde 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).

Bloquear la cuenta de usuario del sistema para acceder a la administración: el dispositivo Citrix ADC permite bloquear a un usuario del sistema durante 24 horas y denegar el acceso al usuario. El dispositivo Citrix ADC admite la configuración tanto para usuarios del sistema como para usuarios externos. En el símbolo del sistema, escriba:

set aaa parameter –persistentLoginAttempts DISABLED

Ahora, para bloquear una cuenta de usuario, en el símbolo del sistema, escriba:

lock aaa user test

Para obtener información sobre cómo configurar esta función mediante la GUI, consulte Gestión de cuentas de usuario y contraseñas.

Desbloquear una cuenta de usuario del sistema bloqueada para acceder a la administración: los usuarios del sistema y los usuarios externos pueden bloquearse durante 24 horas mediante el comando Bloquear autenticación, autorización y auditoría de usuario. El dispositivo Citrix ADC le permite desbloquear al usuario del sistema bloqueado. En el símbolo del sistema, escriba:

unlock aaa user test Para obtener información sobre cómo configurar esta función mediante la GUI, consulte Gestión de cuentas de usuario y contraseñas.

Inhabilitar el acceso de administración para la cuenta de usuario del sistema: cuando la autenticación externa está configurada en el dispositivo y, como administrador, prefiere denegar el acceso a los usuarios del sistema para iniciar sesión en el acceso de administración, debe inhabilitar la opción LocalAuth en el parámetro del sistema.

Nota: El servidor externo debe estar configurado.

En el símbolo del sistema, escriba lo siguiente:

set system parameter localAuth <ENABLED|DISABLED>

Ejemplo:

set system parameter localAuth DISABLED Para obtener información sobre cómo configurar esta función mediante la GUI, consulte Gestión de cuentas de usuario y contraseñas.

Forzar cambio de contraseña para usuarios administrativos: para la autenticación nsroot segura, el dispositivo Citrix ADC solicita al usuario que cambie la contraseña predeterminada a una nueva si la forcePasswordChange opción está habilitada en el parámetro del sistema. Puede cambiar su nsroot contraseña desde CLI o GUI, en su primer inicio de sesión con las credenciales predeterminadas. En el símbolo del sistema, escriba:

set system parameter -forcePasswordChange ( ENABLED | DISABLED )

Por ejemplo, sobre cómo configurar esta función, consulte Gestión de cuentas de usuario y contraseñas.

Acceda a Citrix ADC mediante claves SSH y sin contraseña: en implementaciones donde exista la necesidad de administrar muchos dispositivos Citrix ADC, considere el uso de claves SSH y Sin contraseña. Para obtener información sobre cómo configurar esta función, consulte Acceder 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 11.0 de Citrix ADC, es necesario crear una clave maestra del sistema para proteger determinados 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 auditoría almacenadas localmente 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. Escriba 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 local no se cifran con KEK).
  • No debe eliminar el archivo KEK. Si tiene acceso a shell y elimina los archivos de fragmento de clave por error, podría resultar en pérdida de configuración, falla de sincronización, error de inicio de sesión. A continuación se presentan 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 encripto/descifrado de datos confidenciales produce un error que a su vez podría resultar en pérdida de configuración, falla de sincronización, error de inicio de sesión.
  • La frase de paso debe tener al menos 8 caracteres.

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 se pueda acceder a él 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 rango 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
  • Para aplicar ACL a los puertos internos, utilice el siguiente comando:
set l3param -implicitACLAllow DISABLED

Nota: El valor predeterminado para el comando ImplicitaclAllow es ENABLED.

  • Para quitar las ACL de los puertos internos, utilice el siguiente comando:
set l3param -implicitACLAllow ENABLED
  • 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 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 funciones o directivas de comandos, 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 comandos 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 cómo configurar usuarios, grupos de usuarios o directivas de comandos, consulte los documentos de Citrix:

Configurar el 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á usando. Para el dispositivo Citrix ADC, el tiempo de espera de 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 pueda configurarse 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 que 1 día o menos de 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á en 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 usuario publicadmin 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 siguiente comando:
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 el protocolo de tiempo de red

Citrix recomienda que el Protocolo de tiempo de red (NTP) esté habilitado en el dispositivo y configurado para utilizar un servidor de hora de red de confianza. La activación de 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 impedir que el servidor NTP divulgue la información en paquetes sensibles.

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 de restricción 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 capacidades 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 a 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 un 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 al administrador hacer referencia al historial de eventos en orden cronológico. El servidor de auditoría es similar al servidor SYSLOG que recopila registros del dispositivo. El servidor de auditoría utiliza las credenciales de administrador para obtener registros de uno o varios 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 de un equipo remoto, instale el servidor de auditoría en ese equipo. A continuación se presentan opciones de ejemplo 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 por el archivo ns.log del dispositivo solamente. Para registrar todos los mensajes syslog, realice los siguientes pasos:

  1. Quite 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 de host de registro o la dirección IP del host syslog remoto, similar a las entradas siguientes:

    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 de instalación local para los mensajes y archivos nsvpn.log al archivo de configuración syslog.conf. Los valores de instalación deben corresponder a los valores configurados en el dispositivo.
  5. El servidor syslog remoto de cualquier equipo basado en UNIX de forma predeterminada no escucha 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 la 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 estén dedicados exclusivamente a un propósito de administración de red y se coloquen 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 estricta comprobación y aplicación 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 incorporado, 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 de ensayo antes de lanzarlo a producción.

La protección contra los ataques de desincronización HTTP está habilitada de forma predeterminada en el perfil de validación HTTP estricto (nshttp_default_strict_validation). Utilice el perfil estricto para todas las entidades orientadas al cliente.

Para obtener más información sobre los ataques de contrabando de solicitudes HTTP y su mitigación, consulte el artículo de soporte técnico Citrix ADC - Guía de referencia de contrabando de solicitudes HTTP.

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 se requiera algún ajuste de 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 valor small_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 que transcurre durante la retransmisión excede 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 sobretensión que se sondean con una sonda KA.

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

Configurar Citrix ADC para defenderse contra ataques de suplantación de 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 de ensayo 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 la notificación cercana

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á finalizando 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. Cualquier dato recibido después de una alerta de cierre se ignora, 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 los eventos de auditoría se capturan 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 aplicar las siguientes recomendaciones a los clientes que utilizan DNSSEC:

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

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

Activar la alarma SNMP para caducidad de claves 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 la Referencia de OID de Citrix ADC SNMP.

Rastre las claves privadas KSK/ZSK antes de que caduque los certificados x.509

En un dispositivo Citrix ADC, puede utilizar los métodos de prepublicación y doble firma para realizar un rollover de la clave de firma de zona y la clave de firma de clave. Para obtener más información, vea 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 tiene autoridad 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 servidor autorizado, realice 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. Agregue 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 Extensión DNSEC en los parámetros globales DNS.

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

Configuración heredada

Configurar Citrix ADC para inhabilitar la redirección SSLv2

Si habilita la función de redirección de 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 segura de SSL

Para configurar Citrix ADC para evitar la renegociación SSL no segura para Citrix ADC versión 9.3e o 10.0, 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 deben seguirse para garantizar que el material criptográfico esté correctamente protegido en el dispositivo Citrix ADC. También proporciona información sobre cómo configurar los dispositivos para que utilicen este material para proteger tanto al propio dispositivo como a los servidores back-end y a 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. Enlazar 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, como scp o WinSCP, transferir el certificado de emisor del servidor (root) 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 certificados de CA raíz de entidades emisoras de certificados que se sepa que son de confianza. Quite todos los demás certificados.

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

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 de 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 menciona en el paso 1 de la sección anterior.

  2. Autenticar en el dispositivo Citrix ADC a través de la CLI como administrador de sistemas 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 Citrix ADC 11.0 en adelante, el archivo PKCS #12 (.PFX) se convierte automáticamente a PEM y todos los certificados se agregan y vinculan a la CA automáticamente.

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

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

  1. Autenticar en Citrix ADC CLI 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 entidad emisora de certificados.

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 entidad emisora de certificados devuelve un certificado válido por correo electrónico, pero esto también puede variar entre las entidades emisoras de certificados empresariales. 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 es un cliente FIPS existente y utiliza un dispositivo Citrix ADC SDX para lograr una multitenencia real, utilice el dispositivo Citrix ADC MPX certificado por FIPS para terminar TLS y reenviar tráfico al dispositivo Citrix ADC SDX. Alternativamente, es posible usar un HSM externo Thales. Cambie las contraseñas de la tarjeta criptográfica FIPS cuando utilice una versión certificada 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 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: Nivel 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.

Almacenar 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 está bloqueado, se convierte en no operativo 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 cómo crear 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 Denegar todo a nivel global para bloquear todas las solicitudes que no coinciden 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 PRIORITY 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 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 directrices 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 tienen que protegerse contra la navegación forzosa.
  • Habilitar formato de campo Comprueba 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 y la coherencia de las cookies. Consistencia del campo de formulario en partes de 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 en el lado de la 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 del 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 denomina “Sesionización”. 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 aloja información crítica en formularios necesitaría la comprobación.

  • Verificación de etiquetado de formularios CSRF: Esta comprobación es para formularios. El etiquetado de formularios de falsificación de solicitudes cruzadas (CSRF) marca cada formulario web enviado por un sitio web protegido a los usuarios con un FormID único e impredecible y, a continuación, examina los formularios web devueltos por los usuarios para asegurarse de que el FormID proporcionado 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

A continuación se detallan los pasos de alto nivel del 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. Implemente las reglas aprendidas para la protección. c. Validar los datos de aprendizaje junto con las firmas aplicadas antes de poner en marcha.

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

Utilizar la 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 servidores LDAP e Interfaz Web. No se recomienda el uso de versiones anteriores de este protocolo, 1.0, 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 ejemplo 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 de información adicional

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 de Citrix ADC MPX, VPX y SDX