Guía de implementación segura de Citrix ADC

Mejores prácticas para la seguridad de Citrix ADC MPX, VPX y SDX

December 6, 2022

Contribución de:

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 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, incluidos 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 multiarrendatario 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 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 todo el ciclo de vida de la implementación, Citrix recomienda revisar las siguientes consideraciones para:

Seguridad física
Seguridad de dispositivos
Seguridad de red
Administración y Gestión

Las distintas implementaciones pueden requerir distintas consideraciones de seguridad. Este documento proporciona una guía de seguridad general para ayudarlo 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 de software 12.1, NetScaler pasa a llamarse Citrix ADC. Para obtener más información, consulte https://www.citrix.com/about/citrix-product-guide/.

Pautas de implementación

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

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, 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. Si hay CCTV, las grabaciones 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 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 una implementación de VPX, a la consola 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 adecuada. En caso de corte de energía, la fuente de alimentación ininterrumpida garantiza el funcionamiento continuo del dispositivo o permite un apagado controlado de Citrix ADC físicos o virtuales. El uso de una fuente de alimentación ininterrumpida también ayuda a proteger contra picos de energía.

Protección de claves criptográficas

Si se requiere protección adicional para las claves criptográficas de su implementación, considere el uso de un dispositivo compatible con FIPS 140-2 Level 2. La plataforma FIPS utiliza un módulo de seguridad de hardware para proteger las claves criptográficas críticas del dispositivo frente a un 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 últimas versiones de firmware. 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 Boletines de seguridad de Citrix https://support.citrix.com/securitybulletins y considere suscribirse para recibir alertas de boletines nuevos y actualizados https://support.citrix.com/user/alerts.

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 un control de acceso basado en roles y una sólida administración de contraseñas. Además, el servidor debe actualizarse con los últimos parches de seguridad para el sistema operativo cuando estén disponibles e implementar un software antivirus actualizado en el servidor, si corresponde 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 apagadas (LOM) de Citrix ADC

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.

En el símbolo del shell de Citrix ADC, ejecute el siguiente comando:
```
>ipmitool raw 0x30 0x41 0x1

```
Nota: Al ejecutar 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 sobre cómo volver a configurar el puerto LOM, consulte Puerto de administración de luces fuera del dispositivo Citrix ADC MPX.
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 LOM:
- Vaya a Configuración > Usuarios > Modificar usuario y cambie la contraseña de la cuenta de superusuario nsroot.
- Vaya a Configuración > Usuarios > Modificar usuario y cree directivas para los usuarios o vincule las directivas existentes a los usuarios.
- Vaya a Configuración > Control de acceso IP > Agregar y configure 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 sobre 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 eliminen correctamente del dispositivo.

Para obtener más información sobre este proceso, consulte Borrar los datos antes de enviar el dispositivo ADC a Citrix.

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:

No exponga la interfaz de administrador de Citrix ADC (NSIP) a Internet.
Debe reemplazarse el certificado SSL predeterminado de Citrix ADC.
Se debe usar HTTPS (HTTP sobre TLS) al acceder a la GUI y la interfaz HTTP predeterminada está inhabilitada.

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

Consideraciones clave de seguridad de red

No exponga el NSIP a Internet:

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

Reemplace el certificado TLS predeterminado de Citrix ADC:

Durante la configuración inicial de un dispositivo Citrix ADC, se crean los 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 usen certificados de una entidad de certificación (CA) de confianza o certificados apropiados de la entidad de certificación 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 Citrix ADC predeterminado 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 las conexiones al servidor web. Para obtener más información sobre 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 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 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 sólidos y cambie el conjunto ‘DEFAULT’ de conjuntos de cifrado por 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 use 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 de Knowledge Center: How to Secure SSH Access to the Citrix ADC Appliance with Public Key Authentication y la documentación de productos Citrix: SSH key based authentication for local system users
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
<!--NeedCopy-->

Para obtener más información sobre cómo configurar el acceso seguro a la GUI de administración, consulte el artículo CTX111531 de Knowledge Center: 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 la red

Limitar el acceso al shell VPX de los administradores VPX en los que no se confía en administrar el SDX:

En situaciones en las que es deseable que una persona diferente administre un VPX al de la SVM, el administrador de SVM debe crear un usuario administrador de VPX que tenga acceso de shell limitado en el VPX y que solo proporcione la cuenta de usuario administrador restringida al administrador de VPX.

Algunas operaciones pueden requerir acceso de shell (como la administración de certificados SSL). Sin embargo, solo las personas en las que se confía para administrar la SVM deben tener acceso al shell de instancia VPX. Los comandos de nivel RBAC, enumerados más adelante en esta sección, se pueden asignar a esas cuentas. Estas recomendaciones se aplican a todos los flujos de trabajo de administración SVM-IP/VPX-NSIP (L2/L3) y deben seguirse para fines de auditoría de acceso seguro.

Los siguientes pasos se pueden utilizar para eliminar el acceso al shell de un administrador de VPX.

Protección de instancias VPX existentes:

Inicie sesión en la CLI de VPX como nsroot o superusuario.

Citrix recomienda no usar la cuenta nsroot y, en su lugar, crear una cuenta de superusuario. Al usar la cuenta nsroot, asegúrese de que las contraseñas sean seguras con caracteres especiales. Para obtener más información sobre contraseñas seguras, consulte Administración y administración.
- Cree un usuario y una directiva de RBAC en una instancia VPX del sistema SDX.
- Vincular a ese usuario a la directiva.
```
    > add system user userabc
    Enter password:
    Confirm password:
    Done
    > bind system user userabc superuser 2
    Done
    > add system cmdpolicy shell deny (shell)
    Done
    > bind system user userabc shell 1
    Done

```
Nota: En este ejemplo, el sistema cmdpolicy (por ejemplo, cmdpolicy name: shell) se crea para denegar el acceso de shell. Esta directiva está vinculada al usuario creado userabc) con prioridad alta. El superusuario predeterminado cmdpolicy también está vinculado como prioridad más baja al usuario del sistema. Con esta configuración, el usuario del sistema creado tiene directivas RBAC de superusuario pero se deniega el acceso al shell.

Inicie sesión como usuario creado y lleve a cabo lo siguiente.

Compruebe que el usuario actual ha aplicado las directivas de RBAC.
Ejecute todos los comandos para los que el usuario esté autorizado. (por ejemplo, show system cmdpolicy)
Ejecute el shell cmd para verificar que el acceso al shell esté restringido.

iniciar sesión como: userabc

Mensaje de banner de autenticación previa desde el servidor:

| #############################################################################
> ##
| #
>  #
| #        WARNING: Access to this system is for authorized users only
>  #
| #         Disconnect IMMEDIATELY if you are not an authorized user!
>  #
| #
>  #
| #############################################################################
> ##
|
End of banner message from server
Keyboard-interactive authentication prompts from server:
| Password:
End of keyboard-interactive prompts from server
Last login: Thu May 13 04:11:15 2021 from 10.10.1.1
Done
<!--NeedCopy-->

> whoami
    UserName:  userabc        LoggedIn:  "Thu May 13 04:18:50 2021"
Done
<!--NeedCopy-->

En la consola de ese VPX, inicie sesión como ese usuario y asegúrese de que el acceso al shell no esté permitido para este usuario:
```
> shell
ERROR: Not authorized to execute this command [shell]

```

Inicie sesión como usuario administrador normal (nsroot) y asegúrese de que se permite el acceso de shell:

> shell
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.

root@Zela-40G-10#
<!--NeedCopy-->

Protección de una nueva instancia VPX:

Cuando se crea una nueva instancia VPX a partir de la GUI de SVM, cree un usuario de INSTANCE ADMIN y desactive la casilla de verificación Acceso Shell/SFTP/SCP. Al deshabilitar el acceso al shell, svm_access_policy (action DENY) se vincula explícitamente al usuario administrador de la instancia especificado.
Proporcione esta información de usuario al ADMIN de VPX. SDX ADMIN debe conservar esta contraseña de administrador nsroot y no debe compartirla con el administrador de VPX.

Nota:

Para cambiar la contraseña nsroot, inicie sesión en SVM, seleccione la instancia y cambie la contraseña. No cambie nunca la contraseña nsroot de la CLI de VPX.
Para obtener información detallada sobre los usuarios de RBAC, consulte Usuario, grupos de usuarios y directivas de comandos.
Para modificar la contraseña del dispositivo Citrix ADC desde SVM, consulte Modificar una instancia de Citrix ADC.
Para aprovisionar el dispositivo Citrix ADC con administración de instancias, consulte Agregar una instancia de Citrix ADC.

Inhabilitar el reenvío de puertos SSH:

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

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

AllowTcpForwarding no
Guarde el archivo y cópielo en /nsconfig para que los cambios sean persistentes en caso de que reinicie durante las pruebas.
Reinicie el proceso sshd mediante el siguiente comando:
```
kill -HUP `cat /var/run/sshd.pid`

```

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 Alta disponibilidad > Configuración de alta disponibilidad en Citrix Docs y Cómo configurar un par de alta disponibilidad en Citrix ADC.

Configure una comunicación segura entre dispositivos homólogos:

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 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 una 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 Acceso 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 de administrador y de la cuenta de usuario interna o del nodo RPC para implementaciones locales y en la nube. Es aconsejable cambiar las contraseñas con frecuencia.

Contraseña de administrador: consulte Cambiar contraseña de administrador.
Cuenta de usuario interna o contraseña de nodo RPC: consulte Cambiar la contraseña de un nodo RPC.

Nota

Citrix también recomienda inhabilitar la cuenta de usuario interna y, en su lugar, utilizar la autenticación basada en claves.

Configurar los dominios de seguridad de red y las VLAN:

Citrix recomienda encarecidamente que el tráfico de red hacia 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 externa
VLAN de administración
VLAN de 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 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 usar 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 la posibilidad de utilizar Citrix Web App Firewall: Un dispositivo con licencia Citrix ADC Premium Edition proporciona un Citrix Web App Firewall integrado que utiliza un modelo de seguridad positivo y aprende automáticamente el comportamiento adecuado de la aplicación para protegerse contra amenazas como inyección de comandos, inyección de SQL y uso de scripts en varios 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 Introducción al firewall de aplicaciones web de Citrix.

Restringir el acceso a aplicaciones no administrativas: 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
<!--NeedCopy-->

Implementación segura de clústeres: si los nodos del clúster de Citrix ADC se distribuyen fuera del centro de datos, Citrix recomienda encarecidamente el uso de un 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
<!--NeedCopy-->

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

Cuando se implementa en una implementación de clúster L3, los paquetes entre los 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 utilizar el clúster sobre la función 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
<!--NeedCopy-->

Use Secure MEP for global server load balancing (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
<!--NeedCopy-->

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 cookie HTTP.

Parámetro Helloverifyrequest para mitigar el ataque de amplificación DDoS DTLS:

A partir de Citrix ADC versión 12.1, compilación 62.x, y versión 13.0, compilación 79.x, el parámetro helloverifyrequest está habilitado de forma predeterminada. Habilitar el parámetro helloverifyrequest en el perfil DTLS ayuda a mitigar el riesgo de que un atacante o bots abruman el rendimiento de la red, lo que podría provocar un agotamiento del ancho de banda saliente. Es decir, ayuda a mitigar el ataque de amplificación DDoS DTLS.

Para ver el estado de los parámetros helloverifyrequest, en la solicitud de la CLI de ADC, escriba;

show dtlsProfile
<!--NeedCopy-->

Protección del tráfico de transferencia 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 utilizar para proteger el tráfico de transferencia 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
Se prefiere SSL de extremo a extremo (TLS 1.2 y TLS 1.1)
Proxy HTTPS//Denegar el resto del tráfico

Protección del estado de la 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 la sesión está habilitada de forma predeterminada y no requiere una 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 o servicio virtual configurado 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 caen en esta máquina de estado. Los demás 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
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á ENABLED)

Protección de fijación de sesión (al habilitar la marca HttpOnly o al agregar 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 etiqueta una cookie con el indicador HttpOnly, indica al explorador que solo el servidor debe acceder a esta cookie. Queda terminantemente prohibido intentar acceder a la cookie desde el script del cliente. 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.

A continuación se muestra un ejemplo de una cookie con la marca HttpOnly configurada:

Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/; HttpOnly
<!--NeedCopy-->

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 se puede procesar por script y no debe revelarse a la aplicación cliente. Por lo tanto, el script del lado del cliente no puede acceder a la cookie y el cliente no es susceptible a la creación de 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)  
<!--NeedCopy-->

Usar la directiva de reescritura para insertar Secure y HttpOnly para las 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 los VIP que no son SSL, se puede insertar el indicador HttpOnly.

Con Citrix ADC, se pueden incluir solo HTTP y marcas seguras para las cookies configuradas por el servidor.

HttpOnly: esta opción en una cookie hace que los exploradores web devuelvan la cookie solo utilizando el protocolo HTTP (o HTTPS); los métodos que no son HTTP, como las referencias de document.cookie de JavaScript, no pueden acceder a la cookie. Esta opción ayuda a evitar el robo de cookies debido al uso de 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 está 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:

Habilite la función Reescritura, si aún no está habilitada.
```
enable feature REWRITE

```

Cree una acción de reescritura (este ejemplo está configurado para establecer indicadores Secure y HttpOnly). Si falta alguno de ellos, 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
<!--NeedCopy-->

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=/)!)"

or

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
<!--NeedCopy-->

Nota: A partir de la versión 13.1 de Citrix ADC, el parámetro bypassSafetyCheck no es aplicable. Sin embargo, para las versiones anteriores a la 13.1, se admite este parámetro.

Cree una directiva de reescritura para desencadenar la acción.

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

Ejemplo:

add rewrite policy rw_force_secure_cookie "http.RES.HEADER("Set-Cookie").EXISTS" act_cookie_Secure
<!--NeedCopy-->

Enlazar la directiva de reescritura al servidor virtual que se va a proteger (si se usa la opción Secure, se debe usar un servidor virtual SSL).

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

Ejemplo:

bind lb vserver mySSLVServer -policyName rw_force_secure_cookie -priority 100 -gotoPriorityExpression NEXT -type RESPONSE
<!--NeedCopy-->

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

HSTS (habilite la seguridad de transporte estricta HTTP (HSTS)):

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)
<!--NeedCopy-->

O BIEN:

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

Para obtener más información, consulte los siguientes temas.

Autenticación sólida:

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 aplicaciones confidenciales para la autenticación multifactor, consulte Autenticación multifactor (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 reportado vulnerabilidades de seguridad. Solo puede tener habilitados TLS 1.1 y TLS 1.2. Si es posible, tenga solo la versión TLS 1.2 en el cliente frente a direcciones VIP. Se puede hacer a nivel de entidad SSL o a nivel de perfil y todas las entidades SSL heredan la configuración de SSL del perfil.

Para inhabilitar las 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   -tls11   DISABLED

set ssl service <vServiceName> -ssl2 DISABLED   -ssl3  DISABLED   -tls1   DISABLED   -tls11   DISABLED
<!--NeedCopy-->

Si el perfil SSL está habilitado, use el siguiente comando:

set ssl profile <frontend profile> -ssl3  DISABLED   -tls1   DISABLED  -tls11  DISABLED

set ssl profile <backend profile> -ssl3  DISABLED   -tls1   DISABLED  -tls11  DISABLED
<!--NeedCopy-->

Los conjuntos de cifrado recomendados por Citrix ADC:

Los siguientes cifrados compatibles con 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:

Recomiende los 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 las suites 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 las suites 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 las suites Cipher 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.

TLS1.2-AES128-GCM-SHA256
TLS1.2-AES-128-SHA256
TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
TLS1.2-ECDHE-RSA-AES-128-SHA256
TLS1-ECDHE-RSA-AES128-SHA
TLS1.2-DHE-RSA-AES128-GCM-SHA256
TLS1.2-DHE-RSA-AES-128-SHA256
TLS1-DHE-RSA-AES-128-CBC-SHA
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 (TLS 1.1 y TLS 1.2) y cifrados seguros. Se debe tener en cuenta el rendimiento SSL TPS y SSL al habilitar 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 la contraseña de la cuenta de superusuario: no puede eliminar el superusuario administrador integrado (nsroot). Por lo tanto, cambie la contraseña predeterminada de esa cuenta por una contraseña segura. Para cambiar la contraseña predeterminada del usuario administrador, lleve a cabo los siguientes pasos:

Inicie sesión como superusuario y abra la utilidad de configuración.
En el panel de navegación, expanda el nodo Sistemas.
Seleccione el nodo Usuarios.
En la página Usuarios del sistema, seleccione el usuario nsroot.
Selecciona Cambiar contraseña.
Escriba la contraseña requerida en los campos Contraseña y Confirmar contraseña.
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
<!--NeedCopy-->

Use esta cuenta de superusuario en lugar de la cuenta de superusuario nsroot predeterminada.

Para 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, lleve a cabo los siguientes pasos:

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

Contraseña segura para usuario del sistema:

Citrix recomienda usar una contraseña segura para las cuentas de usuarios del sistema creadas en Citrix ADC. A continuación se muestran algunos ejemplos de requisitos de complejidad de contraseñas:

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 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 -minpasswordlen <positive_integer> -
-strongpassword ( ENABLED | DISABLED )
<!--NeedCopy-->

En implementaciones en las que se requieren varios administradores, considere la posibilidad de utilizar un método de autenticación externo para autenticar a los usuarios, por ejemplo, RADIUS, TACACS+ o LDAP (S). Para obtener más información, consulte Autenticación de usuarios externos.

Bloquear la cuenta de usuario del sistema para el acceso de administración: el dispositivo Citrix ADC le 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 interfaz gráfica de usuario, consulte Administració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 interfaz gráfica de usuario, consulte Administració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, prefiera 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 interfaz gráfica de usuario, consulte Administración de cuentas de usuario y contraseñas.

Forzar cambio de contraseña para usuarios administrativos: Para la autenticación segura nsroot, el dispositivo Citrix ADC solicita al usuario que cambie la contraseña predeterminada a una nueva si la opción forcePasswordChange está habilitada en el parámetro del sistema. Puede cambiar su contraseña nsroot desde la CLI o la 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 )

Para ver un ejemplo de cómo configurar esta función, consulte Administració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 Acceso a un dispositivo Citrix ADC mediante claves SSH y sin contraseña.

Cree la clave principal del sistema para la protección de datos: desde Citrix ADC 12.1 hasta Citrix ADC 13.0—71.44, es necesario crear una clave principal del sistema para proteger ciertos parámetros de seguridad, como las contraseñas de las cuentas de servicio necesarias para la autenticación LDAP y las cuentas de usuario de autenticación, autorización y auditoría almacenadas localmente.

Nota: A partir de las versiones 13.0—76.31 de Citrix y posteriores, se crea automáticamente una clave principal del sistema aleatoria con el proceso de actualización.

Para crear la clave principal del sistema:

Con la interfaz de línea de comandos, inicie sesión como administrador del sistema.
Escriba el siguiente comando:

create kek <passphrase>
<!--NeedCopy-->

Nota:

Después de ejecutar el comando create system kek, se usa KEK para la mayoría de los cifrados de contraseñas (las contraseñas de los usuarios locales no se cifran con KEK).
No debe eliminar el archivo KEK. Si tiene acceso de shell y elimina los archivos de fragmentos de clave por error, puede provocar una pérdida de configuración, un error de sincronización o un 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 desactualizar; 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 fragmentos de clave se pierde o se daña, el cifrado/descifrado de datos confidenciales produce un error que, a su vez, puede provocar la pérdida de la configuración, el error de sincronización o el error de inicio de sesión.
La frase de contraseña debe tener al menos 8 caracteres.

Use listas de control de acceso:

De forma predeterminada, se puede acceder a todos los protocolos y puertos, incluidas la GUI y SSH, en un dispositivo Citrix ADC. Las listas de control de acceso (ACL) pueden ayudarlo a administrar el dispositivo de forma segura al permitir que solo los usuarios especificados explícitamente accedan a los 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 direcciones IP de confianza para acceder a estos puertos.

Esta directiva se puede ampliar para su uso con el intervalo 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
<!--NeedCopy-->

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
<!--NeedCopy-->

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

Puede habilitar las funciones de administración en las direcciones NSIP y SNIP. 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 modo que no se pueda acceder a él con el comando ping.

Open Shortest Path First (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
<!--NeedCopy-->

Si se utiliza un servicio web XML-API, realice 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 permitir que los hosts del rango de direcciones IP 10.0.0.1-20 y 172.16.0.1-20 accedan 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
<!--NeedCopy-->

Para aplicar las ACL a los puertos internos, use el siguiente comando:

set l3param -implicitACLAllow DISABLED
<!--NeedCopy-->

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
<!--NeedCopy-->

Puede lograr una seguridad adicional mediante el uso de un certificado del lado del cliente. Para obtener más información sobre los certificados del lado del cliente y la autenticación de clientes, consulte Autenticación de clientes o el artículo de Knowledge Center CTX214874: Cómo crear y usar certificados de cliente en el dispositivo Citrix ADC con firmware 10.1 y superior.

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

El dispositivo Citrix ADC incluye cuatro directivas o roles 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
<!--NeedCopy-->

Para obtener más información sobre la configuración de usuarios, grupos de usuarios o directivas de comandos, consulte Directivas de usuarios, grupos de usuarios y comandos.

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á usando. 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 a 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 el símbolo del sistema, introduzca el siguiente comando:

set system user <name> -timeout <secs>
<!--NeedCopy-->

Tiempo de espera a 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 el símbolo del sistema, introduzca el siguiente comando:

set system group <groupName> -timeout <secs>
<!--NeedCopy-->

Tiempo de espera del sistema global. Aplicable a todos los usuarios y usuarios de grupos que no tienen configurado un tiempo de espera.

GUI: Vaya a Sistema > Configuración, haga clic en Establecer parámetros globales del sistemay establezca el parámetro CUALQUIER tiempo de inactividad del cliente (segundos). CLI: En el símbolo del sistema, introduzca el siguiente comando:

set system parameter -timeout <secs>
<!--NeedCopy-->

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 tiene en cuenta 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 tiene en cuenta el valor de tiempo de espera configurado globalmente. Si el tiempo de espera no se configura en ningún nivel, el valor predeterminado de 900 segundos se establece como el tiempo de espera de la sesión del sistema.

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

GUI: vaya a Sistema > Configuración, haga clic en Establecer parámetros globales del sistemay seleccione el campo Tiempo de espera restringido.
CLI: En el símbolo del sistema, introduzca el siguiente comando:

set system parameter -restrictedtimeout <ENABLED/DISABLED>
<!--NeedCopy-->

Cuando el usuario habilita el parámetro RestrictedTimeout y si el valor de tiempo de espera ya está configurado en un valor superior a 1 día o inferior a 5 minutos, se le notifica al usuario que cambie el valor del 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 la duración del tiempo de espera para cada una de las interfaces a las que accede. 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 el valor de tiempo de espera que está dentro de los 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>
<!--NeedCopy-->

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 usar un servidor de tiempo de red de confianza. La habilitació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 la red.

Al configurar NTP, se debe modificar el archivo ntp.conf para impedir 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
<!--NeedCopy-->

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 comando find . –name ntp.conf desde la solicitud de 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, como la autenticación, el control de acceso y las comprobaciones de integridad de los datos. Para obtener más información, consulte Configurar Citrix ADC para consultas SNMPv3.

Nota:

Citrix recomienda utilizar SNMPv3 en lugar de SNMPv1 y SNMPv2.

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 de SNMP y restringir este comportamiento:

add snmp manager <IP_address>
<!--NeedCopy-->

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

set ns ip <IP_Address> -snmp disabled
<!--NeedCopy-->

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 a un administrador ver el 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 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 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
<!--NeedCopy-->

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

Elimine las especificaciones del archivo de registro del archivo /nsconfig/syslog.conf para las instalaciones locales.
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 siguientes entradas:

local0.* @10.100.3.53

local1.* @10.100.3.53
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.
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 los archivos nsvpn.log al archivo de configuración syslog.conf. Los valores de las instalaciones deben corresponder a los valores configurados en el dispositivo.
El servidor syslog remoto de 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
<!--NeedCopy-->

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) de un 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 esté en la misma LAN o VLAN física 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 las interfaces de administración de LOM y los 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.
Defina 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 el dispositivo Citrix ADC para eliminar o pasar el encabezado de actualización

Se agrega un nuevo parámetro passProtocolUpgrade al perfil HTTP para evitar ataques a los servidores del back-end. Según el estado de este parámetro, el encabezado de actualización se pasa a la solicitud enviada al back-end o se elimina antes de enviar la solicitud.

Si el parámetro passProtocolUpgrade está activado, el encabezado de actualización se pasa al back-end. El servidor acepta la solicitud de actualización y la notifica en su respuesta.
Si este parámetro está inhabilitado, se elimina el encabezado de actualización y la solicitud restante se envía al back-end.

El parámetro passProtocolUpgrade se agrega a los siguientes perfiles.

nshttp_default_profile: Habilitado de forma predeterminada
nshttp_default_strict_validation: Inhabilitado de forma predeterminada
nshttp_default_internal_apps: Inhabilitado de forma predeterminada
nshttp_default_http_quic_profile: Habilitado de forma predeterminada

Citrix recomienda configurar el parámetro PassProtocolUpgrade como deshabilitado.

Establezca el parámetro passProtocolUpgrade mediante la CLI:

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

set ns httpProfile <name> [-passProtocolUpgrade ( ENABLED | DISABLED )]

Establezca el parámetro passProtocolUpgrade mediante la GUI:

Vaya a Sistema -> Perfiles -> Perfiles HTTP.
Cree o modifique un perfil HTTP.
Marque la casilla Aprobar la actualización del protocolo.

Configurar Citrix ADC para eliminar solicitudes HTTP no válidas

Citrix recomienda encarecidamente que el dispositivo Citrix ADC esté configurado con una verificació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 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
<!--NeedCopy-->

Citrix recomienda que los clientes que utilicen esta opción prueben los cambios en un entorno provisional 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 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 los ataques de denegación de servicio HTTP, incluidos los ataques de tipo “lectura lenta”. Puede configurar estas funciones mediante la utilidad nsapimgr del símbolo del shell del dispositivo:

small_window_threshold (por defecto = 1)
small_window_idle_timeout (predeterminado = 7 segundos)
small_window_cleanthresh (predeterminado = 100)
small_window_protection (predeterminado = 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 propiedad small_window_threshold hacia arriba mediante este comando nsapimgr del indicador de 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 rastrea el 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 provisional antes de lanzarlo a producción.

Configurar Citrix ADC para que se defienda de los ataques de suplantación de TCP

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

set ns tcpProfile profile1 -rstWindowAttenuate ENABLED -spoofSynDrop ENABLED

Done

set lb vserver lbvserver1 -tcpProfileName profile1

Done
<!--NeedCopy-->

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 el dispositivo 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 de reescritura global envía solo tráfico de red con encabezados como Host, Accept y test al servidor:

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
<!--NeedCopy-->

Configuración de notificación de cierre

Una notificación cercana es un mensaje seguro que indica el final de la transmisión de datos SSL. Conforme con RFC 5246: El cliente y el servidor deben compartir el conocimiento de que la conexión está finalizando para evitar el 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. Se ignoran todos los datos recibidos después de una alerta de cierre, a menos que se haya transmitido alguna otra alerta grave, 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 los eventos de terminación de TLS, inicie sesión en la CLI como superusuario o administrador del sistema y ejecute los siguientes comandos:

set ssl parameter -sendCloseNotify y

save ns config
<!--NeedCopy-->

Interfaz gráfica de usuario de administración segura, API de NITRO y comunicación RPC

Para proteger la GUI de administración, la API de NITRO y la comunicación RPC en los dispositivos Citrix ADC y Citrix Gateway, el parámetro maxclientForHttpdInternalService se agrega en los dispositivos. Este parámetro está inhabilitado de forma predeterminada. Debe habilitar el parámetro para proteger la GUI de administración, la API de NITRO y la comunicación RPC.

También se recomienda establecer que maxclientForHttpdInternalService coincida con el valor de MaxClients en /etc/httpd.conf mediante el siguiente comando de Shell. El valor predeterminado de MaxClients es 30.

nsapimgr_wr.sh -ys maxclientForHttpdInternalService=<val>
<!--NeedCopy-->

Para obtener más información sobre cómo configurar el valor maxclientForHttpdInternalService y las versiones de Citrix ADC que admiten esta configuración, consulte https://support.citrix.com/article/CTX331588.

Recomendaciones de seguridad de DNSSEC

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

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

El NIST recomienda que los administradores de DNS mantengan RSA/SHA-1 o RSA/SHA-256 ZSKs de 1024 bits hasta el 1 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.

Pase el cursor sobre las claves privadas KSK/ZSK antes de que caduquen los certificados x.509

En un dispositivo Citrix ADC, puede utilizar los métodos de prepublicación y doble firma para realizar una sustitución 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 Citrix Docs.

Servidor ADNS seguro de DNSSEC

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 un servidor autoritativo, lleve a cabo los siguientes pasos:

Agregue un servicio ADNS.

Por ejemplo:

add service s1 <ip address> adns 53`
<!--NeedCopy-->

Crea claves DNS.

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

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

create dns key -zoneName com -keytype zsk -algorithm rsASHA512 -keysize 3000 -fileNamePrefix com.zsk.rsasha1.3000
<!--NeedCopy-->

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

Agrega 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
<!--NeedCopy-->

Agregue registros NS y SOA para la zona com 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
<!--NeedCopy-->

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

Para obtener más información sobre la configuración de Citrix ADC como servidor de nombres de dominio autoritativo, consulte el tema Sistema de nombres de dominio > Configuración de Citrix ADC como servidor ADNS en Citrix Docs.

Configuración heredada

Configurar Citrix ADC para inhabilitar la redirección SSLv2

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

Ejecute el siguiente comando para inhabilitar la redirección SSLv2:

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

Configurar Citrix ADC para evitar la renegociación de SSL no segura

Ejecute el siguiente comando para deshabilitar la renegociación de SSL:

set ssl parameter -denySSLReneg ALL
<!--NeedCopy-->

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

set ssl parameter -denySSLReneg NONSECURE
<!--NeedCopy-->

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

Configurar la verificación del certificado de cumplimiento del NDCPP

La comprobación del certificado de conformidad de NDCPP se aplica cuando el dispositivo actúa como cliente (conexión back-end). Durante la verificación del certificado, ignore el nombre común si la SAN está presente en el certificado SSL.

En el símbolo del sistema, escriba los siguientes comandos para configurar el atributo “ndcppComplianceCertCheck” en el parámetro SSL:

set ssl parameter [-quantumSize <quantumSize>] [-crlMemorySizeMB <positive_integer>] [-strictCAChecks (YES | NO)] [-sslTriggerTimeout <positive_integer>] [-sendCloseNotify (YES | NO)] [-encryptTriggerPktCount <positive_integer>] [-denySSLReneg <denySSLReneg>] [-insertionEncoding (Unicode|UTF-8)] [-ocspCacheSize <positive_integer>][- pushFlag <positive_integer>] [- dropReqWithNoHostHeader (YES | NO)] [-pushEncTriggerTimeout <positive_integer>] [-ndcppComplianceCertCheck ( YES | NO)] [-heterogeneousSSLHW (ENABLED | DISABLED )]
<!--NeedCopy-->

Ejemplo:

set ssl parameter -quantumSize 8 -crlMemorySizeMB 256 -strictCAChecks no -ssltriggerTimeout 100 -sendClosenotify no -encryptTriggerPktCount 45 -denySSLReneg NONSECURE -insertionEncoding unicode -ocspCacheSize 10 -pushFlag 3 -dropReqWithNoHostHeader YES  -pushEncTriggerTimeout 100 ms -ndcppComplianceCertCheck YES
<!--NeedCopy-->

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é protegido correctamente en el dispositivo Citrix ADC. También proporciona información sobre cómo configurar los 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 nDCPP

Los siguientes conjuntos de cifrado TLS son compatibles con las implementaciones de nDCPP.

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Para ver la lista de cifrados compatibles con el MPX-14000 FIPS, consulte https://docs.citrix.com/en-us/citrix-adc/downloads/cipher-support-on-a-citrix-mpx-sdx-14000-fips-appliance.pdf.

Para asegurarse de que solo los conjuntos de cifrado aprobados estén configurados en el dispositivo, complete los siguientes pasos de configuración de la CLI:

Desenlazar todos los cifrados del servidor virtual

unbind ssl vs v1 –cipherName FIPS
<!--NeedCopy-->

Enlazar solo TLS1-AES-256-CBC-SHA y, a continuación, TLS1-AES-128-CBC-SHA con el comando:

bind ssl vs v1 –cipherName <cipher>

bind ssl vs v1 -cipherName TLS1-AES-256-CBC-SHA
<!--NeedCopy-->

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

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

Autenticarse en la CLI de Citrix ADC como administrador del sistema o superusuario.

Crea una clave privada RSA.

create fipsKey m1 -keytype RSA -modulus 2048 -exponent F4
<!--NeedCopy-->

Cree la solicitud de firma de certificado (CSR):

create certreq csr_1 -fipsKeyName m1 -countryName IN -stateName BA -organizationName citrix
<!--NeedCopy-->

Envíe la CSR a la entidad de certificación.

Para la mayoría de las CA comerciales y empresariales, la CSR se envía en una solicitud por 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 las CA 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 administrador de sistemas 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 multiarrendatario real, utilice el dispositivo Citrix ADC MPX certificado por FIPS para terminar TLS y reenviar tráfico al dispositivo Citrix ADC SDX. Como alternativa, es posible utilizar un HSM externo de 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
<!--NeedCopy-->

Nivel de inicialización FIPS. El dispositivo admite actualmente el nivel 2 (FIPS 140-2). Se trata de 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.

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

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 y la información sobre la creación de varios niveles o seguridad. Esta sección también contiene información sobre los detalles de configuración cuando se utiliza Citrix ADC o Citrix Gateway como SP SAML o IdP SAML o ambos.

Recomendaciones de seguridad de Citrix Web App Firewall

Para las comprobaciones de cumplimiento de RFC, se recomienda mantener “APPFW_RFC_BLOCK” como valor predeterminado rfcprofile para el perfil WAF.
WAF admite la inserción del valor de atributo de cookie Samesite, y la cookie se puede restringir al contexto del mismo sitio o entre sitios seleccionando valores “Estricto” o “Laxo”.

Implemente el dispositivo en el modo de dos brazos

Con una instalación en modo de dos brazos, el dispositivo está ubicado físicamente entre los usuarios y los servidores web que el dispositivo protege. Las conexiones deben pasar por el dispositivo. Esta disposición minimiza las posibilidades de encontrar una ruta alrededor del dispositivo.

Utilizar 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 true default_deny_profile

bind appfw global default_deny_policy <PRIORITY>
<!--NeedCopy-->

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).

El software Citrix ADC incluye perfiles predeterminados, como appfw_block, que cuando se configuran bloquean las solicitudes 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
<!--NeedCopy-->

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

Las siguientes pautas lo ayudan a crear varios niveles de seguridad según su entorno y las aplicaciones compatibles.

Configure un valor diferente para el parámetro sessionCookieName en cada nivel.

set appfw settings -sessionCookieName "citrix_ns_id_1"
<!--NeedCopy-->

Primer nivel de seguridad

Para crear el primer nivel de seguridad, lleve a cabo lo siguiente:

Habilite el desbordamiento de búfer, la inyección de SQL y los scripts.
La URL de inicio es necesaria cuando la aplicación es específica en la que se debe acceder a las URL y deben protegerse contra la navegación forzada.
Habilite las comprobaciones de formato de campo si su aplicación espera entradas en un campo de formulario.

La comprobación de scripts entre sitios puede generar falsos positivos, ya que muchas empresas tienen una gran base instalada de contenido web mejorado con JavaScript que infringe la misma regla de origen. Si habilita la comprobación de scripts de sitios HTML en un sitio de este tipo, debe generar las excepciones apropiadas para que la comprobación no bloquee la actividad legítima.

Implemente el primer nivel, busque falsos positivos, implemente 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, lleve a cabo lo siguiente:

Habilite las firmas en el perfil además de desbordamiento de búfer, inyección SQL y uso de 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.

Implemente el segundo nivel, busque falsos positivos, implemente 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, lleve a cabo lo siguiente:

En función de las necesidades de la aplicación, habilite las comprobaciones de seguridad avanzada de perfiles, como el etiquetado CSRF y la coherencia de 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 del lado de la respuesta, debe recordar la información que se envía a cada cliente individual. Por ejemplo, si un formulario está protegido por Citrix Web App Firewall, la información del campo del formulario enviada en la respuesta se conserva en la memoria. Cuando el cliente envía el formulario en la siguiente solicitud posterior, se verifica si hay incoherencias antes de enviar la información al servidor web. Este concepto se conoce como 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 la verificación de coherencia de campos de formulario: esta verificación es necesaria para verificar si el cliente no modificó los formularios web de manera inapropiada. Una aplicación que sirve y aloja información crítica en formularios necesitaría la verificación.
Verificación de etiquetado de formularios CSRF: Este cheque es para formularios. La comprobación de etiquetado de formularios de falsificación entre sitios (CSRF) etiqueta cada formulario web enviado por un sitio web protegido a los usuarios con un formulario único e impredecible y, a continuación, examina los formularios web devueltos por los usuarios para asegurarse de que el ID de formulario proporcionado es correcto. Esta comprobación protege contra los ataques de falsificación de solicitudes entre sitios. Esta comprobación debe estar habilitada si la aplicación tiene formularios basados en la web. Esta comprobación requiere una capacidad de procesamiento de la CPU relativamente pequeña en comparación con otras comprobaciones de seguridad que analizan los formularios web en profundidad. Por lo tanto, es capaz de gestionar ataques de gran volumen sin degradar gravemente el rendimiento del sitio web protegido o del propio Citrix Web App Firewall.

Pasos del flujo de Citrix Web App Firewall

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

Pasos del flujo de Citrix Web App Firewall

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

Configure el perfil de seguridad.
Aplica firmas para todas las amenazas conocidas, el modelo negativo.
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 por el 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. Siga estos pasos:

Configure la infraestructura de aprendizaje.
Implemente las reglas aprendidas para la protección.
Validar los datos de aprendizaje junto con las firmas aplicadas antes de poner en marcha.

Recomendaciones de seguridad de Citrix Gateway

Utilizar 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 permitir 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 usar el comando show defaultAuthorizationAction en la CLI para verificar la configuración. Para establecer el parámetro de modo que deniegue todos los recursos en el nivel global, ejecute el siguiente comando desde la CLI:

set vpn parameter -defaultAuthorizationAction DENY
<!--NeedCopy-->

Usar 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 los servidores LDAP y de Interfaz Web. No se recomienda el uso de versiones anteriores de este protocolo, 1.0 y SSLv3 y anteriores.

Utilice la función “Aplicaciones de intranet” Use aplicaciones de intranet para definir qué redes intercepta el plug-in de Citrix Gateway y qué redes se envían a la puerta de enlace. 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
<!--NeedCopy-->

Recomendaciones de seguridad de autenticación, autorización y auditoría

Si un Citrix ADC o un dispositivo Citrix Gateway están configurados como SP SAML o IdP SAML o ambos, consulte el artículo https://support.citrix.com/article/CTX316577 para obtener detalles de configuración recomendados.

Para obtener más información sobre la autenticación SAML, consulte Autenticación SAML.

Recursos de información adicional

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

Portal de seguridad de Citrix: http://www.citrix.com/security
Documentación del producto Citrix ADC

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

La versión oficial de este contenido está en inglés. Para mayor comodidad, parte del contenido de la documentación de Citrix solo tiene traducción automática. Citrix no puede controlar el contenido con traducción automática, que puede contener errores, imprecisiones o un lenguaje inadecuado. No se ofrece ninguna garantía, ni implícita ni explícita, en cuanto a la exactitud, la fiabilidad, la idoneidad o la precisión de las traducciones realizadas del original en inglés a cualquier otro idioma, o que su producto o servicio de Citrix se ajusten a cualquier contenido con traducción automática, y cualquier garantía provista bajo el contrato de licencia del usuario final o las condiciones de servicio, o cualquier otro contrato con Citrix, de que el producto o el servicio se ajusten a la documentación no se aplicará en cuanto dicha documentación se ha traducido automáticamente. Citrix no se hace responsable de los daños o los problemas que puedan surgir del uso del contenido traducido automáticamente.

¿Le ha resultado útil?

Mejores prácticas para la seguridad de Citrix ADC MPX, VPX y SDX

December 6, 2022

Contribución de:

December 6, 2022

Contribución de:

En este artículo

Pautas de implementación
Pautas de configuración
Administración y gestión
Recomendaciones criptográficas de Citrix ADC
Otras funciones
Recursos de información adicional

¿Le ha resultado útil?