Avamar: Seguridad de sesión
Summary: En este artículo, se describe qué es la seguridad de sesión en Avamar, cómo funciona y cómo administrarla.
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Instructions
¿Qué es la seguridad de sesión?
Seguridad de sesión: Guía de seguridad de productos
Avamar Client puede utilizar la seguridad de sesión para proteger todas las comunicaciones entre Avamar Server y el software de Avamar Client. Avamar Server proporciona autenticación a Avamar Client y viceversa.
Las características de seguridad de sesión incluyen mejoras de seguridad para las comunicaciones entre los procesos del sistema Avamar.
Avamar protege todas las comunicaciones entre los procesos del sistema Avamar mediante tickets de sesión. Se requiere un ticket de sesión válido antes de que un proceso de Avamar acepte una transmisión de otro proceso de Avamar.
Los tickets de sesión tienen las siguientes características generales:
El sistema Avamar instala la clave pública del certificado de servidor en cada Avamar Client registrado en Avamar Server. Avamar Client utiliza la clave pública para autenticar las transmisiones del sistema Avamar.
En el caso de los clientes que están registrados actualmente, la clave pública del certificado de servidor y otros archivos de certificado necesarios se propagan al cliente dentro de una hora después de la instalación.
El sistema Avamar también comparte automáticamente el certificado de Avamar Server con los nodos de almacenamiento de Avamar. El uso compartido del certificado permite que el nodo de utilidad y los nodos de almacenamiento proporcionen el mismo certificado para la autenticación.
Se genera un certificado de cliente cuando Avamar Server registra un Avamar Client.
Después de generar un certificado de cliente, el sistema Avamar utiliza una conexión cifrada con Avamar Client para instalar el certificado en el cliente. El sistema Avamar también almacena la clave pública del certificado de cliente. La clave pública se utiliza para autenticar al cliente en todas las comunicaciones posteriores.
¿Cómo funciona la seguridad de sesión?
La seguridad de sesión está habilitada en Avamar Server. Cuando está habilitada, los clientes, los proxies y los sistemas Data Domain pasan por un proceso especial de registro de certificados con Avamar.
En un cliente y proxy de Windows o Linux, en el momento del registro, se ve que Avamar Server tiene habilitada la seguridad de sesión. Avamar envía su CA raíz interna al cliente (chain.pem) para que este pueda almacenarla y confiar en ella. El cliente genera una solicitud de firma de certificado (CSR). La CSR (avclient.csr) se enviará del cliente al proceso de MCS de Avamar Server, que la firmará y devolverá un par de claves de certificado al cliente (key.pem y cert.pem).
En un Data Domain, al conectar el Data Domain a Avamar o cuando se actualiza la comunicación SSL, Avamar verá que el Data Domain no tiene un certificado firmado por sí mismo ni por otro Avamar validado (imported-host ddboost). Avamar utilizará la clave privada de SSH de Data Domain para iniciar sesión en Data Domain y ejecutar comandos de SSH a través del shell de Data Domain (ddsh). Avamar extraerá la solicitud de firma de certificado (CSR) de Data Domain mediante SCP y la firmará con su CA raíz interna. Una vez que Data Domain tenga el certificado firmado por Avamar (imported-host ddboost), Avamar importará la CA raíz que firmó el certificado (chain.pem as imported-ca ddboost/login-auth).
Ahora que el cliente/proxy está registrado y tiene los certificados del lado del cliente necesarios para autenticarse con el MCS de Avamar, se intenta realizar un respaldo. Avamar envía una orden de trabajo al cliente de escucha de Avagent del cliente o proxy, el cual la recoge. A continuación, el cliente o proxy valida y verifica la cadena de certificados de Avamar Server mediante la CA raíz de Avamar que Avamar importó al cliente en el momento del registro. Del mismo modo, Avamar autentica al cliente o proxy. En este punto, no se ha transmitido ningún dato.
Una vez que la autenticación se ha realizado correctamente, se inicia la orden de trabajo y su estado cambia de “Waiting-Client” a “Running”.
Ahora, los clientes y los proxies finalmente transfieren los datos a Avamar y Data Domain mediante el binario avtar instalado en ellos. El binario avtar transmitirá algunas marcas que controlan los detalles de cómo se transfieren los datos y qué datos se transfieren.
Cuando avtar en un cliente o proxy se conecta a GSAN de Avamar, debe saber si verifypeer está habilitado. El ajuste verifypeer es un ajuste del servidor GSAN que forma parte de la configuración de seguridad de sesión que controla el conector SSL de GSAN en el puerto 29000 indicándole si se requieren o no certificados de cliente para cada conexión entrante. Afortunadamente, se implementa el protocolo TLS 1.2, que maneja de forma automática la manera en que un cliente o proxy debe presentar sus certificados de cliente a GSAN durante el protocolo de enlace TLS.
La siguiente es una demostración del protocolo de enlace mutuo/bidireccional TLS cuando verifypeer está habilitado.
Desde el punto de vista del cliente o proxy, una flecha que apunta hacia la derecha es una conexión con Avamar Server. Una flecha que apunta hacia la izquierda es una conexión de Avamar Server hacia el cliente.
Lo importante es que el cliente o proxy obtenga los certificados del lado del cliente necesarios para poder realizar un protocolo de enlace TLS mutuo si GSAN así lo requiere.
Esto significa que, si la CA raíz interna de Avamar cambia, el cliente, el proxy o Data Domain deben lograr que la nueva CA raíz firme los certificados por ellos.
Una vez que el cliente o proxy se haya conectado a GSAN correctamente, intentará conectarse a Data Domain.
En el siguiente registro, se muestra un proxy que se conecta a Data Domain con avtar. El ajuste verifypeer está deshabilitado, pero la seguridad de sesión está habilitada (modo autenticado simple).
Dado que verifypeer es un ajuste de servidor GSAN de Avamar, no afecta la forma en que avtar se conecta directamente a Data Domain si la seguridad de sesión está habilitada. Esto significa que se produce un protocolo de enlace TLS mutuo entre el cliente o proxy y Data Domain.
El cliente o proxy puede validar la cadena de certificados de Data Domain debido a que comparte la misma CA raíz interna de Avamar que Avamar importó en el momento del registro del cliente (o en el momento de la edición o la conexión de DD).
Después de la validación del certificado, se completa el protocolo de enlace y los datos de respaldo se transfieren del cliente a Data Domain y Avamar en la red.
Administración de los ajustes de seguridad de sesión
Los dos artículos siguientes se utilizan para administrar los ajustes de seguridad de sesión, ya sea desde la línea de comandos o desde el servicio web Avinstaller.
000222234 | Avamar: Administración de los ajustes de seguridad de sesión desde la CLI
000222279 | Avamar: Administración de los ajustes de seguridad de sesión con el paquete de instalación de Avinstaller (AVP)
Deshabilitado
Ajustes:
Cuando la seguridad de sesión está deshabilitada, los clientes solo se conectan al servicio Avagent de Avamar en el puerto 28001 y los clientes escuchan en el puerto 28002 de Avagent las solicitudes de Avamar.
Un proxy escucha en el puerto 28009.
El puerto 28001 es un conector TCP simple y no realiza protocolos de enlace TLS.
El cliente se conecta a GSAN de Avamar en el puerto 29000 y realiza un protocolo de enlace TLS unidireccional. Esto significa que, incluso cuando la seguridad de sesión está deshabilitada, al transferir datos de respaldo entre el cliente y Avamar, estos se cifran en el acto.
Los certificados para la autenticación con el software Avamar no se intercambian entre Avamar, los proxies, los clientes y Data Domain.
Mixto simple
Ajustes:
El modo mixto simple se utilizaba más cuando la seguridad de sesión se incorporó por primera vez en Avamar 7.3, lo que permitió específicamente que aquellos clientes cuya versión no fuera 7.3 o posterior se registraran y realizaran respaldos en Avamar. Al momento de escribir este artículo, Avamar 19.10 era la última versión y el modo mixto simple es básicamente el mismo que analizaremos a continuación: el modo autenticado simple.
Autenticado simple
Ajustes:
En este modo, la seguridad de sesión está habilitada y los certificados se transmiten entre Avamar, los clientes, los proxies y Data Domain para la autenticación antes de realizar un respaldo.
Ahora, los clientes escuchan en el puerto 30002 las solicitudes de órdenes de trabajo de Avagent desde Avamar, y los proxies escuchan en el puerto 30009. Avamar escucha en los puertos 30001 y 30003 las solicitudes de conexión de clientes y proxies. Estos son conectores SSL que realizan protocolos de enlace TLS.
El modo autenticado simple obliga a todos los clientes a registrarse mediante métodos de seguridad de sesión, a diferencia del modo mixto simple.
Este modo establece verifypeer en GSAN de Avamar como deshabilitado, lo que significa que GSAN no requerirá certificados de cliente de una conexión avtar entrante.
Autenticado doble
Ajustes:
Autenticado simple es lo mismo que autenticado doble, excepto que habilita el ajuste verifypeer en el servicio GSAN de Avamar.
El modo autenticado doble se considera el ajuste más sólido que se puede aplicar a Avamar Server y es la selección predeterminada durante las implementaciones de Avamar.
Visión general: CA raíz autofirmada interna de Avamar
La CA raíz interna de Avamar es una autoridad de certificación de confianza interna para Avamar y los clientes, proxies y Data Domain que Avamar importa.
Avamar es su propia CA interna, ya que emite certificados para solicitudes de firma de certificados (CSR).
Cuando Avamar utiliza su CA raíz a fin de firmar certificados para GSAN, estos se almacenan en la siguiente ubicación:
Si un escáner de seguridad analiza el puerto 29000 en Avamar, informará los certificados autofirmados de ese puerto que procesa los respaldos en GSAN.
En algunos entornos, es posible que esto no sea aceptable, por lo que se recomienda consultar el siguiente artículo de la base de conocimientos para obtener más información sobre el reemplazo de la CA raíz interna de Avamar por una CA raíz interna proporcionada por el usuario.
Artículo 000204629 de la base de conocimientos | Avamar: Instalar/reemplazar la autoridad de certificación (CA) de Avamar por la autoridad de certificación proporcionada por el usuario (CA)
En el proceso, se detalla cómo usar el script importcert.sh para instalar una autoridad de certificación proporcionada por el usuario e interna de su empresa. Es probable que el equipo de seguridad administre la autoridad de certificación proporcionada por el usuario, ya que ninguna autoridad de certificación pública revelará la clave privada de su CA, puesto que es la razón por la que ganan dinero firmando certificados para terceros y manteniendo una cadena de confianza.
Un ejemplo de una CA interna serían los Servicios de certificados de Active Directory de Microsoft.
¿Qué son los Servicios de certificados de Active Directory? | Microsoft Learn
Un ejemplo de una CA pública sería DigiCert.
El reemplazo de la CA raíz interna de Avamar se realiza sustituyendo el par de claves raíz en el almacén de claves de Avamar con el par de claves de CA proporcionado por el usuario. A continuación, GSAN genera una CSR y una clave privada, obtiene la CSR firmada por el nuevo par de claves de CA y se reemplazan los archivos mencionados anteriormente en esta sección. GSAN vuelve a cargar el conector SSL en el puerto 29000 y los clientes nuevos que se conectan a GSAN consultan la CA proporcionada por el usuario.
Los escáneres de seguridad mostrarán los certificados firmados en el puerto, y los clientes, los proxies y Data Domain tendrán que volver a registrarse para obtener la nueva CA.
Limitaciones
Las características de seguridad de sesión de Avamar están sujetas a algunas limitaciones:
Planificación de cambios en la seguridad de sesión
Antes de realizar un cambio en los ajustes de seguridad de sesión, se pueden realizar los siguientes pasos para tener la oportunidad de restaurar la configuración o los certificados anteriores antes de realizar cualquier cambio.
Recuerde que, si se cambia la CA raíz interna de Avamar, los clientes, los proxies y Data Domain deben volver a registrarse. Según el tamaño del entorno (cantidad de clientes, proxies y Data Domain), esta tarea puede resultar engorrosa y durar varios días.
El caso de uso sería que los certificados se regeneren y haya fallas de registro y respaldo.
Suponiendo que los certificados no han vencido ni están a punto de vencer, y que se regeneran tal vez por accidente, los siguientes pasos ofrecen algunas pautas sobre cómo evitar una situación de pérdida o falta de disponibilidad de datos.
Obtenga los ajustes actuales de seguridad de sesión y anótelos:
Haga una copia del almacén de claves de Avamar:
Supongamos que los certificados ahora se regeneran, ya sea utilizando los métodos CLI o AVP de seguridad de sesión.
Esto significa que el almacenamiento de claves de Avamar cambió y los certificados de GSAN se volvieron a firmar.
El almacén de claves original de Avamar se puede volver a colocar en su lugar fácilmente:
Regenerar los certificados de GSAN:
Seguridad de sesión: Guía de seguridad de productos
Avamar Client puede utilizar la seguridad de sesión para proteger todas las comunicaciones entre Avamar Server y el software de Avamar Client. Avamar Server proporciona autenticación a Avamar Client y viceversa.
Las características de seguridad de sesión incluyen mejoras de seguridad para las comunicaciones entre los procesos del sistema Avamar.
Avamar protege todas las comunicaciones entre los procesos del sistema Avamar mediante tickets de sesión. Se requiere un ticket de sesión válido antes de que un proceso de Avamar acepte una transmisión de otro proceso de Avamar.
Los tickets de sesión tienen las siguientes características generales:
- El ticket de sesión está cifrado y firmado para protegerlo contra modificaciones
- El ticket de sesión es válido por poco tiempo
- Cada ticket de sesión contiene una firma única y se asigna a un solo proceso de Avamar
- La integridad de un ticket de sesión se protege mediante cifrado
- Cada nodo del sistema Avamar verifica por separado la firma del ticket de sesión
- Cuando sea necesario, una sesión se puede extender más allá de la vigencia del ticket de sesión
El sistema Avamar instala la clave pública del certificado de servidor en cada Avamar Client registrado en Avamar Server. Avamar Client utiliza la clave pública para autenticar las transmisiones del sistema Avamar.
En el caso de los clientes que están registrados actualmente, la clave pública del certificado de servidor y otros archivos de certificado necesarios se propagan al cliente dentro de una hora después de la instalación.
El sistema Avamar también comparte automáticamente el certificado de Avamar Server con los nodos de almacenamiento de Avamar. El uso compartido del certificado permite que el nodo de utilidad y los nodos de almacenamiento proporcionen el mismo certificado para la autenticación.
Se genera un certificado de cliente cuando Avamar Server registra un Avamar Client.
Después de generar un certificado de cliente, el sistema Avamar utiliza una conexión cifrada con Avamar Client para instalar el certificado en el cliente. El sistema Avamar también almacena la clave pública del certificado de cliente. La clave pública se utiliza para autenticar al cliente en todas las comunicaciones posteriores.
¿Cómo funciona la seguridad de sesión?
La seguridad de sesión está habilitada en Avamar Server. Cuando está habilitada, los clientes, los proxies y los sistemas Data Domain pasan por un proceso especial de registro de certificados con Avamar.
En un cliente y proxy de Windows o Linux, en el momento del registro, se ve que Avamar Server tiene habilitada la seguridad de sesión. Avamar envía su CA raíz interna al cliente (chain.pem) para que este pueda almacenarla y confiar en ella. El cliente genera una solicitud de firma de certificado (CSR). La CSR (avclient.csr) se enviará del cliente al proceso de MCS de Avamar Server, que la firmará y devolverá un par de claves de certificado al cliente (key.pem y cert.pem).
En un Data Domain, al conectar el Data Domain a Avamar o cuando se actualiza la comunicación SSL, Avamar verá que el Data Domain no tiene un certificado firmado por sí mismo ni por otro Avamar validado (imported-host ddboost). Avamar utilizará la clave privada de SSH de Data Domain para iniciar sesión en Data Domain y ejecutar comandos de SSH a través del shell de Data Domain (ddsh). Avamar extraerá la solicitud de firma de certificado (CSR) de Data Domain mediante SCP y la firmará con su CA raíz interna. Una vez que Data Domain tenga el certificado firmado por Avamar (imported-host ddboost), Avamar importará la CA raíz que firmó el certificado (chain.pem as imported-ca ddboost/login-auth).
Ahora que el cliente/proxy está registrado y tiene los certificados del lado del cliente necesarios para autenticarse con el MCS de Avamar, se intenta realizar un respaldo. Avamar envía una orden de trabajo al cliente de escucha de Avagent del cliente o proxy, el cual la recoge. A continuación, el cliente o proxy valida y verifica la cadena de certificados de Avamar Server mediante la CA raíz de Avamar que Avamar importó al cliente en el momento del registro. Del mismo modo, Avamar autentica al cliente o proxy. En este punto, no se ha transmitido ningún dato.
Una vez que la autenticación se ha realizado correctamente, se inicia la orden de trabajo y su estado cambia de “Waiting-Client” a “Running”.
Ahora, los clientes y los proxies finalmente transfieren los datos a Avamar y Data Domain mediante el binario avtar instalado en ellos. El binario avtar transmitirá algunas marcas que controlan los detalles de cómo se transfieren los datos y qué datos se transfieren.
Cuando avtar en un cliente o proxy se conecta a GSAN de Avamar, debe saber si verifypeer está habilitado. El ajuste verifypeer es un ajuste del servidor GSAN que forma parte de la configuración de seguridad de sesión que controla el conector SSL de GSAN en el puerto 29000 indicándole si se requieren o no certificados de cliente para cada conexión entrante. Afortunadamente, se implementa el protocolo TLS 1.2, que maneja de forma automática la manera en que un cliente o proxy debe presentar sus certificados de cliente a GSAN durante el protocolo de enlace TLS.
La siguiente es una demostración del protocolo de enlace mutuo/bidireccional TLS cuando verifypeer está habilitado.
Desde el punto de vista del cliente o proxy, una flecha que apunta hacia la derecha es una conexión con Avamar Server. Una flecha que apunta hacia la izquierda es una conexión de Avamar Server hacia el cliente.
[avtar] --> SSL [avtar] --> TLS 1.2 Handshake, ClientHello [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, ServerHello [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, Certificate [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, ServerKeyExchange [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, CertificateRequest [avtar] <-- TLS 1.2 Handshake, ServerHelloDone [avtar] --> SSL [avtar] --> TLS 1.2 Handshake, Certificate [avtar] --> SSL [avtar] --> TLS 1.2 Handshake, ClientKeyExchange [avtar] --> SSL [avtar] --> TLS 1.2 Handshake, CertificateVerify [avtar] --> SSL [avtar] --> TLS 1.2 ChangeCipherSpec [avtar] --> SSL [avtar] --> TLS 1.2 Handshake, Finished [avtar] <-- SSL [avtar] <-- TLS 1.2 ChangeCipherSpec [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, Finished
Cuando verifypeer está deshabilitado, no es necesario que el cliente envíe un certificado de cliente a GSAN.
[avtar] --> SSL [avtar] --> TLS 1.2 Handshake, ClientHello [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, ServerHello [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, Certificate [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, ServerKeyExchange [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, ServerHelloDone [avtar] --> SSL [avtar] --> TLS 1.2 Handshake, ClientKeyExchange [avtar] --> SSL [avtar] --> TLS 1.2 ChangeCipherSpec [avtar] --> SSL [avtar] --> TLS 1.2 Handshake, Finished [avtar] <-- SSL [avtar] <-- TLS 1.2 ChangeCipherSpec [avtar] <-- SSL [avtar] <-- TLS 1.2 Handshake, Finished
Lo importante es que el cliente o proxy obtenga los certificados del lado del cliente necesarios para poder realizar un protocolo de enlace TLS mutuo si GSAN así lo requiere.
Esto significa que, si la CA raíz interna de Avamar cambia, el cliente, el proxy o Data Domain deben lograr que la nueva CA raíz firme los certificados por ellos.
Una vez que el cliente o proxy se haya conectado a GSAN correctamente, intentará conectarse a Data Domain.
En el siguiente registro, se muestra un proxy que se conecta a Data Domain con avtar. El ajuste verifypeer está deshabilitado, pero la seguridad de sesión está habilitada (modo autenticado simple).
2024-02-22 17:37:32 avtar Info <40058>: - Client connecting to the Avamar Server using authentication, client connecting to the Data Domain system using two-way authentication 2024-02-22 17:37:33 avtar Info <44068>: - Data Domain Engine Set FIPS OFF 2024-02-22 17:37:33 avtar Info <16684>: - Data Domain Engine (7.11.0.0 build 1033042) 2024-02-22 17:37:33 avtar Info <40174>: Multi-stream restore via cloning is enabled. 2024-02-22 17:37:33 avtar Info <10632>: Using Client-ID='6bf19b025be80a12da2e7b932da60079709906ae' 2024-02-22 17:37:33 avtar Info <40062>: GSAN connected via: IPv4, retrieved Data Domain IPv4 hostname = lab.dd.com 2024-02-22 17:37:33 avtar Info <10539>: Connecting to Data Domain Server "lab.dd.com"(1) (LSU: avamar-1704339590) with auth token 2024-02-22 17:37:33 avtar Info <10540>: - Resolved Data Domain Server name "lab.dd.com" to the IP address "10.x.x.x" 2024-02-22 17:37:33 avtar Info <41236>: - Connecting to Data Domain Server name "lab.dd.com" with token:e2602cc64ce8c4782ca877cabe355191042d0fb4 2024-02-22 17:37:33 avtar Info <0000>: - Connecting to: DataDomain: lab.dd.com encryption strength: 2 auth_mode: 2 client_cert /usr/local/avamarclient/etc/cert.pem client_key: /usr/local/avamarclient/etc/key.pem server_cert: /tmp/.tmp_avamar/MOD-1708623043157#1_65d7865c_68ce32dc.pem chain_cert: /usr/local/avamarclient/etc/chain.pem
Dado que verifypeer es un ajuste de servidor GSAN de Avamar, no afecta la forma en que avtar se conecta directamente a Data Domain si la seguridad de sesión está habilitada. Esto significa que se produce un protocolo de enlace TLS mutuo entre el cliente o proxy y Data Domain.
El cliente o proxy puede validar la cadena de certificados de Data Domain debido a que comparte la misma CA raíz interna de Avamar que Avamar importó en el momento del registro del cliente (o en el momento de la edición o la conexión de DD).
Proxy ------ Avamar internal root CA /usr/local/avamarclient/etc/chain.pem Data Domain -------------- Avamar internal root CA run command to view certificate list on DD: adminaccess certificate show imported-ca ddboost /usr/local/avamarclient/etc/chain.pem == imported-ca ddboost
Después de la validación del certificado, se completa el protocolo de enlace y los datos de respaldo se transfieren del cliente a Data Domain y Avamar en la red.
Administración de los ajustes de seguridad de sesión
Los dos artículos siguientes se utilizan para administrar los ajustes de seguridad de sesión, ya sea desde la línea de comandos o desde el servicio web Avinstaller.
000222234 | Avamar: Administración de los ajustes de seguridad de sesión desde la CLI
000222279 | Avamar: Administración de los ajustes de seguridad de sesión con el paquete de instalación de Avinstaller (AVP)
Hay cuatro configuraciones soportadas posibles:
- Deshabilitado
- Mixto simple
- Autenticado simple
- Autenticado doble
Deshabilitado
Ajustes:
Current Session Security Settings ---------------------------------- "encrypt_server_authenticate" ="false" "secure_agent_feature_on" ="false" "session_ticket_feature_on" ="false" "secure_agents_mode" ="unsecure_only" "secure_st_mode" ="unsecure_only" "secure_dd_feature_on" ="false" "verifypeer" ="no"
Cuando la seguridad de sesión está deshabilitada, los clientes solo se conectan al servicio Avagent de Avamar en el puerto 28001 y los clientes escuchan en el puerto 28002 de Avagent las solicitudes de Avamar.
Un proxy escucha en el puerto 28009.
El puerto 28001 es un conector TCP simple y no realiza protocolos de enlace TLS.
El cliente se conecta a GSAN de Avamar en el puerto 29000 y realiza un protocolo de enlace TLS unidireccional. Esto significa que, incluso cuando la seguridad de sesión está deshabilitada, al transferir datos de respaldo entre el cliente y Avamar, estos se cifran en el acto.
Los certificados para la autenticación con el software Avamar no se intercambian entre Avamar, los proxies, los clientes y Data Domain.
Mixto simple
Ajustes:
Current Session Security Settings ---------------------------------- "encrypt_server_authenticate" ="true" "secure_agent_feature_on" ="true" "session_ticket_feature_on" ="true" "secure_agents_mode" ="mixed" "secure_st_mode" ="mixed" "secure_dd_feature_on" ="true" "verifypeer" ="no"
El modo mixto simple se utilizaba más cuando la seguridad de sesión se incorporó por primera vez en Avamar 7.3, lo que permitió específicamente que aquellos clientes cuya versión no fuera 7.3 o posterior se registraran y realizaran respaldos en Avamar. Al momento de escribir este artículo, Avamar 19.10 era la última versión y el modo mixto simple es básicamente el mismo que analizaremos a continuación: el modo autenticado simple.
Autenticado simple
Ajustes:
Current Session Security Settings ---------------------------------- "encrypt_server_authenticate" ="true" "secure_agent_feature_on" ="true" "session_ticket_feature_on" ="true" "secure_agents_mode" ="secure_only" "secure_st_mode" ="secure_only" "secure_dd_feature_on" ="true" "verifypeer" ="no"
En este modo, la seguridad de sesión está habilitada y los certificados se transmiten entre Avamar, los clientes, los proxies y Data Domain para la autenticación antes de realizar un respaldo.
Ahora, los clientes escuchan en el puerto 30002 las solicitudes de órdenes de trabajo de Avagent desde Avamar, y los proxies escuchan en el puerto 30009. Avamar escucha en los puertos 30001 y 30003 las solicitudes de conexión de clientes y proxies. Estos son conectores SSL que realizan protocolos de enlace TLS.
El modo autenticado simple obliga a todos los clientes a registrarse mediante métodos de seguridad de sesión, a diferencia del modo mixto simple.
Este modo establece verifypeer en GSAN de Avamar como deshabilitado, lo que significa que GSAN no requerirá certificados de cliente de una conexión avtar entrante.
Autenticado doble
Ajustes:
Current Session Security Settings ---------------------------------- "encrypt_server_authenticate" ="true" "secure_agent_feature_on" ="true" "session_ticket_feature_on" ="true" "secure_agents_mode" ="secure_only" "secure_st_mode" ="secure_only" "secure_dd_feature_on" ="true" "verifypeer" ="yes"
Autenticado simple es lo mismo que autenticado doble, excepto que habilita el ajuste verifypeer en el servicio GSAN de Avamar.
El modo autenticado doble se considera el ajuste más sólido que se puede aplicar a Avamar Server y es la selección predeterminada durante las implementaciones de Avamar.
Visión general: CA raíz autofirmada interna de Avamar
La CA raíz interna de Avamar es una autoridad de certificación de confianza interna para Avamar y los clientes, proxies y Data Domain que Avamar importa.
Avamar es su propia CA interna, ya que emite certificados para solicitudes de firma de certificados (CSR).
Cuando Avamar utiliza su CA raíz a fin de firmar certificados para GSAN, estos se almacenan en la siguiente ubicación:
/home/admin/chain.pem /home/admin/cert.pem /home/admin/key.pem /usr/local/avamar/etc/chain.pem /usr/local/avamar/etc/cert.pem /usr/local/avamar/etc/key.pem
Si un escáner de seguridad analiza el puerto 29000 en Avamar, informará los certificados autofirmados de ese puerto que procesa los respaldos en GSAN.
En algunos entornos, es posible que esto no sea aceptable, por lo que se recomienda consultar el siguiente artículo de la base de conocimientos para obtener más información sobre el reemplazo de la CA raíz interna de Avamar por una CA raíz interna proporcionada por el usuario.
Artículo 000204629 de la base de conocimientos | Avamar: Instalar/reemplazar la autoridad de certificación (CA) de Avamar por la autoridad de certificación proporcionada por el usuario (CA)
En el proceso, se detalla cómo usar el script importcert.sh para instalar una autoridad de certificación proporcionada por el usuario e interna de su empresa. Es probable que el equipo de seguridad administre la autoridad de certificación proporcionada por el usuario, ya que ninguna autoridad de certificación pública revelará la clave privada de su CA, puesto que es la razón por la que ganan dinero firmando certificados para terceros y manteniendo una cadena de confianza.
Un ejemplo de una CA interna serían los Servicios de certificados de Active Directory de Microsoft.
¿Qué son los Servicios de certificados de Active Directory? | Microsoft Learn
Un ejemplo de una CA pública sería DigiCert.
El reemplazo de la CA raíz interna de Avamar se realiza sustituyendo el par de claves raíz en el almacén de claves de Avamar con el par de claves de CA proporcionado por el usuario. A continuación, GSAN genera una CSR y una clave privada, obtiene la CSR firmada por el nuevo par de claves de CA y se reemplazan los archivos mencionados anteriormente en esta sección. GSAN vuelve a cargar el conector SSL en el puerto 29000 y los clientes nuevos que se conectan a GSAN consultan la CA proporcionada por el usuario.
Los escáneres de seguridad mostrarán los certificados firmados en el puerto, y los clientes, los proxies y Data Domain tendrán que volver a registrarse para obtener la nueva CA.
Limitaciones
Las características de seguridad de sesión de Avamar están sujetas a algunas limitaciones:
- Clientes
- Las características de seguridad de sesión no se pueden utilizar con ninguno de los siguientes Avamar Client:
- Cliente de clúster Avamar para Solaris en Veritas Cluster Server
- Avamar Client para Solaris en clústeres Solaris
- Las características de seguridad de sesión no se pueden utilizar con ninguno de los siguientes Avamar Client:
- Otros productos
- Se recomienda usar la sincronización de hora NTP de Avamar Server, Avamar Client y el sistema Data Domain (si corresponde). Si no se sincroniza la hora, podría producirse una falla en el registro y el respaldo o la restauración debido a los tiempos de validez y vencimiento del certificado. Cambiar la zona horaria en un host puede tener un impacto similar y requerir la regeneración de certificados.
- Token seguro
- La autenticación con token seguro no funciona en las siguientes condiciones:
- El equipo cliente está detrás de un dispositivo de firewall de traducción de direcciones de Network Address Translation
- El nombre de host del cliente es un nombre virtual diferente del FQDN resuelto a partir de su dirección IP
- El equipo cliente tiene varias interfaces IP y cada una se resuelve en un nombre de dominio completo (FQDN) diferente. Consulte el siguiente artículo de la base de conocimientos para obtener más información: Artículo 000056252 de la base de conocimientos | Avamar: El respaldo en Data Domain falló con el mensaje “DDR_GET_AUTH_TOKEN” debido a demasiadas direcciones IP
- La autenticación con token seguro no funciona en las siguientes condiciones:
Planificación de cambios en la seguridad de sesión
Antes de realizar un cambio en los ajustes de seguridad de sesión, se pueden realizar los siguientes pasos para tener la oportunidad de restaurar la configuración o los certificados anteriores antes de realizar cualquier cambio.
Recuerde que, si se cambia la CA raíz interna de Avamar, los clientes, los proxies y Data Domain deben volver a registrarse. Según el tamaño del entorno (cantidad de clientes, proxies y Data Domain), esta tarea puede resultar engorrosa y durar varios días.
El caso de uso sería que los certificados se regeneren y haya fallas de registro y respaldo.
Suponiendo que los certificados no han vencido ni están a punto de vencer, y que se regeneran tal vez por accidente, los siguientes pasos ofrecen algunas pautas sobre cómo evitar una situación de pérdida o falta de disponibilidad de datos.
Obtenga los ajustes actuales de seguridad de sesión y anótelos:
enable_secure_config.sh --showconfig
Haga una copia del almacén de claves de Avamar:
cp -p /usr/local/avamar/lib/avamar_keystore /usr/local/avamar/lib/x-avamar_keystore-original
Supongamos que los certificados ahora se regeneran, ya sea utilizando los métodos CLI o AVP de seguridad de sesión.
Esto significa que el almacenamiento de claves de Avamar cambió y los certificados de GSAN se volvieron a firmar.
El almacén de claves original de Avamar se puede volver a colocar en su lugar fácilmente:
cp -p /usr/local/avamar/lib/x-avamar_keystore-original /usr/local/avamar/lib/avamar_keystore
Regenerar los certificados de GSAN:
enable_secure_config.sh --certs
Reiniciar MCS y el programador de respaldo:
mcserver.sh --restart --force dpnctl start sched
Esto restablece la CA raíz interna de Avamar original en la que los clientes, los proxies y Data Domain ya confiaban.
Solución de problemas
La mayoría de las veces, cambiar los ajustes de seguridad de sesión o regenerar los certificados es sencillo.
En esta sección, se explica cómo hacer que todo vuelva a funcionar después de regenerar los certificados o cambiar los ajustes.
Vaciados locales
En el caso en el que verifypeer está habilitado, cuando se regeneran todos los certificados de Avamar, los certificados de cliente que usan avtar y avmgr de Avamar Server no se actualizan de inmediato.
Esto significa que, cuando MCS ejecuta un vaciado programado (respaldo de la configuración de MCS en GSAN), este fallará debido a un error en el protocolo de enlace TLS. Esto se debe a que los certificados de cliente para avtar que se ejecutan en Avamar Server aún no reciben la CA raíz interna de Avamar actualizada ni el nuevo conjunto de certificados de cliente firmados.
Consulte el siguiente artículo de la base de conocimientos para obtener más información:
000214340 | Avamar: Avtar no se puede conectar al servicio GSAN de Avamar: “Fatal server connection problem, aborting initialization. Verify correct server address and login credentials”.
Replicación
En el caso de que verifypeer esté habilitado en el destino de replicación y los certificados se regeneren en el destino, se debe adoptar un enfoque similar al de la sección “Vaciados locales” anterior.
En primer lugar, asegúrese de que el Avagent de destino de replicación esté registrado para que pueda aceptar órdenes de trabajo de replicación.
En el destino, compruebe el registro de Avagent en la siguiente ubicación:
/usr/local/avamar/var/client/avagent.log
Un registro en buen estado podría verse de la siguiente manera:
2024-02-22 15:31:57 avagent Info <5964>: Requesting work from avamar.lab 2024-02-22 15:31:57 avagent Info <5264>: Workorder received: sleep 2024-02-22 15:31:57 avagent Info <5996>: Sleeping 15 seconds 2024-02-22 15:32:12 avagent Info <40019>: Checking certificate status. 2024-02-22 15:32:12 avagent Info <43701>: agent_message::resolve_client_ip ping to MCS avamar.lab:10.x.x.x using local IP:10.x.x.x failed, timed out on receive 2024-02-22 15:32:12 avagent Info <5964>: Requesting work from avamar.lab 2024-02-22 15:32:12 avagent Info <5264>: Workorder received: sleep 2024-02-22 15:32:12 avagent Info <5996>: Sleeping 15 seconds
Si se retrocede en el registro, es posible que haya un nuevo registro reciente que se haya realizado correctamente:
2024-02-22 15:09:00 avagent Info <7502>: Registration of client /MC_SYSTEM/avamar.lab with MCS avamar.lab:30001 successful. 2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1008 Replicate successful. 2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1038 vmir successful. 2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1046 Migrate successful. 2024-02-22 15:09:00 avagent Info <5928>: Registration of plugin 1051 Tiering successful. 2024-02-22 15:09:00 avagent Info <5619>: Registration of client and plugins complete. 2024-02-22 15:09:00 avagent Info <5996>: Sleeping 60 seconds
Un registro en mal estado con problemas de registro causados por cambios de certificado puede verse así:
2024-02-22 15:04:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure 2024-02-22 15:04:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001. 2024-02-22 15:04:57 avagent Info <5059>: unable to connect, sleep(60) then retrying 2024-02-22 15:05:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure 2024-02-22 15:05:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001. 2024-02-22 15:05:57 avagent Info <5059>: unable to connect, sleep(60) then retrying 2024-02-22 15:06:57 avagent Error <40012>: Avamar server certificate verification error 7 at depth 0: certificate signature failure 2024-02-22 15:06:57 avagent Error <5365>: Cannot connect to 10.x.x.x:30001.
En esta instancia, para volver a registrar Avagent con MCS de inmediato y de manera forzada, se deben realizar los siguientes pasos:
Obtenga el nombre de cuenta MC_SYSTEM, que probablemente será el FQDN de Avamar:
mccli client show --domain=/MC_SYSTEM | grep MC_SYSTEM | awk '{print $1}'
example:
root@avamar:/usr/local/avamar/lib/#: mccli client show --domain=/MC_SYSTEM | grep MC_SYSTEM | awk '{print $1}'
avamar.lab
Desactive la cuenta MC_SYSTEM:
mccli client edit --name=/MC_SYSTEM/<avamar_fqdn> --activated=false example: mccli client edit --name=/MC_SYSTEM/avamar.lab --activated=false
Vuelva a registrar la cuenta MC_SYSTEM:
/etc/init.d/avagent register <avamar_fqdn> /MC_SYSTEM example: /etc/init.d/avagent register avamar.lab /MC_SYSTEM
Una vez que el registro se realiza correctamente, Avagent puede aceptar la replicación en el destino.
Ahora, en el Avamar de origen, si verifypeer está habilitado en el Avamar de destino de replicación, debemos regenerar los certificados de cliente utilizados para conectarse al Avamar de destino.
Este caso es similar al del artículo 000214340 de la base de conocimientos | Avamar: Avtar no se puede conectar al servicio GSAN de Avamar: “Fatal server connection problem, aborting initialization. Verify correct server address and login credentials”.
Elimine la carpeta de certificados del Avamar de destino existente de la sesión de SSH del Avamar de origen:
rm -r /usr/local/avamar/etc/<destination_avamar_ip_address> rm -r /usr/local/avamar/etc/client/<destination_avamar_ip_address>
Regenere los certificados de cliente:
/usr/local/avamar/bin/avagent.bin --gencerts=true --mcsaddr=<destination_avamar_ip_address> /usr/local/avamar/bin/avagent.bin --gencerts=true --mcsaddr=<destination_avamar_ip_address> --sysdir=/usr/local/avamar/etc/client
La comunicación con el Avamar de destino se puede probar desde la línea de comandos de SSH del Avamar de origen:
avmgr logn --id=repluser --ap=<destination_repluser_password> --hfsaddr=<destination_avamar_ip_address> --debug --x19=1024 --x30=8192
Registro del cliente
Los respaldos se pueden intentar después de cambiar los ajustes de seguridad de sesión o de regenerar los certificados.
Esto puede provocar que muchos clientes basados en agentes se encuentren en el estado “Waiting-Client” hasta que se produzca un error en el respaldo con el mensaje “Timed-Out Start”.
Una vez que se regeneran los nuevos certificados, el cliente debería tardar aproximadamente 23 horas en intentar volver a registrarse automáticamente.
El siguiente comando se puede utilizar en Avamar Server para enviar una invitación a los clientes basados en agentes a fin de que se vuelvan a registrar en el MCS de Avamar.
mccli client re-register-all
El comando puede tardar algún tiempo según la cantidad de clientes, ya que envía una invitación a cada uno en orden secuencial. Considere la posibilidad de ejecutar el comando en segundo plano en caso de que se agote el tiempo de espera de la sesión de SSH.
nohup mccli client re-register-all &
Tenga en cuenta que es posible que esto no funcione para volver a registrar todos los clientes basados en agentes y que algunos deban volver a registrarse manualmente.
El proceso manual para volver a registrar un cliente en Windows sería el siguiente:
- Eliminar el contenido del siguiente directorio que contiene los certificados de cliente antiguos:
-
"C:\Program Files\avs\etc"
-
- Reiniciar el servicio “Backup Agent”
- Eliminar el contenido del siguiente directorio que contiene los certificados de cliente antiguos:
-
/usr/local/avamar/etc
-
- Reiniciar el servicio Avagent:
-
service avagent restart
-
También se puede reiniciar el equipo cliente para intentar activar un nuevo registro completo.
Tenga en cuenta que la resolución de nombres juega un papel importante en el registro de clientes cuando la seguridad de sesión está habilitada. Asegúrese de que los clientes puedan realizar una búsqueda directa e inversa de DNS en Avamar Server y viceversa. Esto se puede lograr mediante la configuración de registros A de DNS o entradas de host en el cliente.
Avamar no proporciona ningún tipo de script que pueda comunicarse con todos los clientes conectados para realizar un nuevo registro manual; el comando de MCCLI mencionado anteriormente es lo más parecido.
Registro de proxy
Las máquinas virtuales que se respaldan en Avamar mediante proxies tienen cierta ventaja cuando se trata de cambios de seguridad posteriores a la sesión, ya que suele haber muchos menos proxies que clientes basados en agentes.
Los proxies también deberían intentar volver a registrarse automáticamente dentro de 23 horas, pero puede ser más fácil y rápido volver a registrarlos de inmediato.
Hay algunas opciones disponibles para intentar forzar un nuevo registro en los proxies.
La primera opción puede ser reiniciar los proxies con el siguiente comando:
mccli mcs reboot-proxy --all
La segunda opción sería usar la herramienta Goav para administrar los proxies.
Configure la contraseña de proxy para que la herramienta Goav pueda iniciar sesión en los proxies cuando sea necesario. El siguiente comando no cambia la contraseña del sistema operativo del proxy; simplemente almacena la contraseña cifrada para que la herramienta Goav pueda usarla a fin de iniciar sesión en el proxy cada vez que deba hacerlo mediante SSH.
./goav proxy set-password
Realice un reinicio de Avagent en todos los proxies conectados:
./goav proxy exec "service avagent restart"
Para comprobar el registro de Avagent en el proxy y ver si se volvió a registrar correctamente, ejecute el siguiente comando:
./goav proxy exec "grep -i registration /usr/local/avamarclient/var/avagent.log"
Es posible que la salida correcta sea como se muestra a continuación:
============== proxy.lab.emc.com ========================= Executing grep -i registration /usr/local/avamarclient/var/avagent.log on proxy.lab.emc.com 2024-02-23 17:54:06 avagent Info <18918>: Registration: Processing secure registration with the MCS. 2024-02-23 17:54:06 avagent Info <18923>: Registration: Certificate files are present. 2024-02-23 17:54:09 avagent Info <5470>: Updating registration information with the MCS (10.x.x.x), paging enabled 2024-02-23 17:54:09 avagent Info <7501>: Client registration updated 3cbe29134da771ac547b7105743e66633ff12d40 10.x.x.x(1704339590) 2024-02-23 17:54:09 avagent Info <7502>: Registration of client /clients/proxy.lab.emc.com with MCS 10.x.x.x:30001 successful. 2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1019 vmwfilel successful. 2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 3019 vmwfilew successful. 2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1016 vmimagel successful. 2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 3016 vmimagew successful. 2024-02-23 17:54:09 avagent Info <5928>: Registration of plugin 1001 Unix successful. 2024-02-23 17:54:09 avagent Info <5619>: Registration of client and plugins complete.
La tercera opción es acceder al proxy mediante SSH y ejecutar el script de inicialización:
/usr/local/avamarclient/etc/initproxyappliance.sh start
Sincronización de Data Domain
Después de cambiar los ajustes de seguridad de sesión o de regenerar los certificados en Avamar, será necesario volver a sincronizar Data Domain o restablecer la conexión SSL.
En el siguiente artículo de la base de conocimientos, se aborda este caso y cómo intercambiar los certificados nuevos con Data Domain.
000197106 | Integración de Avamar y Data Domain: DD se muestra en rojo en la AUI de Avamar o en la ruta de resolución de la interfaz de usuario
Se recomienda enfáticamente solucionar los problemas de SSL de Avamar y Data Domain con la herramienta Goav.
Con Goav, la conexión SSL de Data Domain con Avamar se puede diagnosticar y resolver automáticamente. Consulte el siguiente artículo de la base de conocimientos para obtener más información:
000215679 | Avamar: Información sobre la característica dd check-ssl de Goav
Ejecute el siguiente comando para reparar automáticamente los certificados de Avamar y Data Domain:
./goav dd check-ssl --fix
Affected Products
Avamar, Data DomainArticle Properties
Article Number: 000222278
Article Type: How To
Last Modified: 06 Feb 2025
Version: 3
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.