Seguridad EJBCA
La seguridad es fundamental para una CA, y la protección de su clave privada es esencial. Comprometer la clave privada de la CA permite a cualquiera emitir certificados falsos, que luego pueden utilizarse para acceder a sistemas que dependen de la CA para la autenticación y otros servicios de seguridad.
Estudie las siguientes secciones y adopte un enfoque pragmático hacia la seguridad, adecuado a su política, aplicación y entorno.
Puertos de firewall necesarios
Solo es necesario abrir unos pocos puertos al exterior para permitir una instalación funcional de EJBCA:
Puerto | Descripción | Uso |
8080 | Puerto HTTP público y no cifrado de su servidor de aplicaciones. | Se utiliza para que los clientes accedan a la información web pública. No se debe usar para la inscripción, ya que no está cifrado. |
8442 | Puerto HTTPS público (solo TLS del lado del servidor) de su servidor de aplicaciones. | Se utiliza para que los clientes accedan a una funcionalidad pública, pero segura, como la inscripción web de EJBCA RA con un usuario público. |
8443 | Puerto HTTPS con protección TLS. Este puerto requiere un certificado de cliente para acceder. | Se utiliza para acceder a la funcionalidad restringida de EJBCA, como la web de administración y los protocolos de inscripción. |
La Web pública está obsoleta a partir de EJBCA 7.9 y ya no será compatible a partir de la próxima versión principal de EJBCA.Dependiendo de sus necesidades, puede elegir tener abiertos tanto el puerto 8080 como el 8442, o solo uno de ellos.
Para otorgar ciertas funciones a los puertos 8080 y 8442, se puede crear un rol de administrador que coincida con el "Token de Autenticación de Acceso Público" correspondiente y aplicarle las reglas de acceso deseadas. Por ejemplo, se podría permitir la inscripción a través de la web de RA sin requerir un certificado de cliente. ¡Use esta función con precaución!
Los puertos adicionales que podría necesitar abrir son SSH, SMTP saliente, LDAP saliente, etc., según su configuración y los servicios utilizados. No necesita SMTP saliente si no utiliza notificaciones por correo electrónico, por ejemplo.
Localmente en el host, se utilizan varios puertos para que su servidor de aplicaciones funcione.
Servidor front-end y filtrado de URL
Al exponer EJBCA (o cualquier aplicación web) a una red no confiable (como Internet), es recomendable y común usar un servidor front-end que realice un filtrado adicional. Por ejemplo, si solo OCSP debe estar disponible en Internet, y no la interfaz de administración, SCEP, EST, etc., se puede permitir el acceso únicamente a esas URL desde la red no confiable. Otras URL pueden ser accesibles desde otras redes internas. Los servidores front-end típicos son Apache y Nginx.
A continuación se muestra un ejemplo de Apache mod_ajp para EJBCA para pasar únicamente las URL de EJBCA desde el front-end de Apache al servidor JBoss/WildFly donde se ejecuta EJBCA:
ProxyPass /ejbca/ ajp: //ejbca_app:8009/ejbca/ keepalive=On ping=500ms retry=1 timeout=300ProxyPass /.well-known/ ajp: //ejbca_app:8009/.well-known/ keepalive=On ping=500ms retry=1 timeout=300Para ver un ejemplo de configuración de Apache para pasar URL OCSP genéricas, como http://ocsp.example.com/, a EJBCA pero descartando solicitudes no deseadas, consulte OCSP GET .
Protección de JBoss/WildFly
Configuración de seguridad
La forma más sencilla de mantener la instalación segura es bloquear todos los puertos JBOSS predeterminados (1099, 1476, 4444, 8082, 8083) desde el exterior y permitir únicamente el tráfico a los puertos Tomcat (8442 y 8443). Esto se debe a que las acciones públicas del usuario final se pueden realizar a través de los servlets públicos, mientras que las tareas de administración se realizan directamente en los beans. EJBCA incluye un script listo para usar para configurar IPTables en Linux, disponible en docs/howto/ejbcafirewall.sh.
Para obtener información sobre los puertos utilizados en JBoss y sobre cómo configurar TLS con JBOSS, consulte la documentación en jboss.org .
Protección de las interfaces de administración de JBoss
Además de los servicios que ofrecen los servidores de aplicaciones en ejecución, JBoss también ofrece dos interfaces de administración que permiten a los clientes remotos conectarse para administrar la instalación de JBoss en ejecución. Para obtener información sobre cómo se utilizan estas interfaces y cómo protegerlas, consulte la documentación de jboss.org sobre dominios de seguridad (WildFly 10) o cómo configurar la seguridad del servidor (JBoss EAP 7.0).
Para eliminar la consola JMX por completo, elimine lo siguiente del archivo standalone.xml :
<subsystem xmlns= "urn:jboss:domain:jmx:1.3" ><expose-resolved-model/><expose-expression-model/><remoting-connector/></subsystem>Para eliminar las páginas de bienvenida, elimine lo siguiente:
<location name= "/" handler= "welcome-content" />De manera predeterminada, la consola web de administración solo es accesible si configura el acceso de los usuarios a ella, y no está configurada de manera predeterminada.
Deshabilitar métodos HTTP específicos
EJBCA limita de manera predeterminada el uso de PUT|DELETE|TRACE|OPTIONS en sus aplicaciones web, pero si no está seguro puede aplicarlo aún más.
Puede utilizar un front-end Apache o puede utilizar un RewriteValve en standalone.xml según el siguiente ejemplo:
<subsystem xmlns= "urn:jboss:domain:web:1.1" default -virtual-server= "default-host" native = "false" ><connector name= "http" protocol= "HTTP/1.1" scheme= "http" socket-binding= "http" /><virtual-server name= "default-host" enable-welcome-root= "true" ><rewrite pattern= ".*" substitution= "-" flags= "F" ><condition test= "%{REQUEST_METHOD}" pattern= "^(PUT|DELETE|TRACE|OPTIONS)$" flags= "NC" /></rewrite></virtual-server></subsystem> Política de seguridad de contenido
La CSP se implementa en los navegadores para mitigar los ataques de secuencias de comandos entre sitios. Para más información, consulte la Referencia de la Política de Seguridad de Contenido y Red de Desarrolladores de Mozilla .
Se ha agregado CSP a las interfaces web EJBCA a partir de ECA-3519 en EJBCA 6.2.0.
Para implementar CSP globalmente si usa un front-end Apache con mod_headers:
<IfModule mod_headers.c>Header set Content-Security-Policy "default-src 'self'"</IfModule>La configuración de Apache anterior es solo un ejemplo y probablemente no funcione correctamente. Consulte los encabezados devueltos por EJBCA para ver una configuración funcional.
Implementación con protección contra escritura
Tras implementar EJBCA, puede proteger contra escritura el directorio standalone/deployments. En tiempo de ejecución, los archivos solo se leen desde este directorio, y protegerlo contra escritura (pertenece al usuario root; JBoss se ejecuta como usuario jboss) puede evitar la implementación de código malicioso.
Para obtener más información sobre cómo proteger una instalación predeterminada de JBoss, consulte la documentación de JBoss en Cómo proteger el servidor de aplicaciones JBoss .
También debe asegurarse de que los archivos confidenciales (como el archivo server.xml que almacena las contraseñas para los almacenes de claves TLS) solo puedan ser leídos por el usuario de JBoss.
Configuración de TLS
Para configurar la comunicación TLS para todo el tráfico HTTP al servidor, siga las instrucciones para instalar EJBCA; esto configurará HTTPS para la interfaz de usuario de CA automáticamente.
<p >Esto configurará un puerto TLS abierto para el público en 8442 y un puerto TLS que requiere un certificado de cliente para acceder a la interfaz de usuario de CA en 8443.Permisos de archivo
El servidor de aplicaciones debe ejecutarse como un usuario especial. Los archivos deben estar protegidos para que solo el usuario que ejecuta el servidor de aplicaciones pueda acceder a ellos.
Lo más probable es que JBoss se descomprima con acceso de lectura para todos los archivos por defecto. Para que solo el usuario de JBoss pueda leer los archivos, ejecute lo siguiente en el directorio JBOSS_HOME para que este sea también el permiso predeterminado para los archivos copiados a esta ubicación:
umask 077chmod -R go-rwx *Si se generan archivos PKCS12 para los usuarios, el subdirectorio (p12) donde se almacenan y los archivos generados deben protegerse de la misma manera.
Cifrado de contraseñas de fuentes de datos
Con JBoss/WildFly, puede configurar el cifrado de las contraseñas de las fuentes de datos para que no sean legibles en el archivo standalone.xml . En muchos sentidos, esto es más enmascaramiento que el cifrado de alta seguridad, pero aun así vale la pena considerarlo, y también puede integrarlo con sistemas externos de gestión de secretos.
Desde la introducción del subsistema Elytron en JBoss EAP 7.x, la principal forma de cifrar las contraseñas de las fuentes de datos es mediante un almacén de credenciales , que incluso puede ser compatible con FIPS. Para obtener más información, consulte la documentación de JBoss sobre el almacenamiento seguro de credenciales . También existen métodos más antiguos, como usar un almacén o una contraseña codificada en un archivo, referenciado por un dominio de seguridad. Para obtener más información, consulte el tutorial de WildFly " Cómo cifrar la contraseña de la fuente de datos de WildFly" .
Uso de claves Diffie-Hellman efímeras de 2048 bits
De forma predeterminada, Java 8 utiliza claves Diffie-Hellman efímeras de 1024 bits. Algunas auditorías y certificaciones requieren el uso de claves más grandes. Puede personalizar el tamaño de la clave en Java, como se documenta en la Guía de referencia de JSSE: Personalización del tamaño de las claves Diffie-Hellman efímeras .
En JBoss/WildFly, agregue lo siguiente a su bin/standalone.conf, en la sección donde especifica las opciones para pasar a la máquina virtual Java.
JAVA_OPTS= "$JAVA_OPTS -Djdk.tls.ephemeralDHKeySize=2048" No se expone la IP/nombre de host interno en la cookie JSESSIONID
Como en la mayoría de las aplicaciones web, las sesiones del navegador se gestionan mediante cookies JSESSIONID. Por defecto, JBoss/WildFly establece una cookie como:
Cookie: JSESSIONID=AxpTtbt42hlB95sk51DrvNJHr0LiT-BTRLGatXh0.ip-172-31-19-190Cuando ejecuta JBoss detrás de un proxy, como Apache o Nginx, la IP al final de la cookie expone la IP interna de su servidor.
Para modificar el valor predeterminado de JSESSIONID que, de manera predeterminada, agrega el nombre de host (y/o el nombre del grupo de servidores), defina un atributo instance-id en el subsistema Undertow en standalone.xml (y/o domain.xml).
<subsystem xmlns="urn:jboss:domain:undertow:3.1" instance-id="${mynodename}"><buffer-cache name="default"/><server name="default-server"><http-listener name="default" socket-binding="http" redirect-socket="https"/>...</subsystem><system-properties><property name="mynodename" value="myvalue"/></system-properties>Después de realizar los cambios, el valor de JSESSION en modo independiente\dominio será como:
JSESSIONID=FsYvt_nZcyDV2gKpQ_4ZsSYeu41JycphvMdHcYeT.myvalue Autenticación de usuario
La autenticación de usuario predeterminada para la inscripción en EJBCA se realiza mediante un esquema de contraseña de un solo uso. Cuando un usuario se inscribe para obtener un certificado, su estado se establece en GENERADO y la contraseña no se puede volver a utilizar para inscribirse en un nuevo certificado. Un administrador debe restablecer el estado del usuario y, preferiblemente, establecer una nueva contraseña.
Si está exponiendo sus páginas web públicas a un público más amplio, puede utilizar las siguientes funciones para contrarrestar amenazas percibidas, como ataques de fuerza bruta:
Habilite la caducidad de contraseñas mediante el Servicio de Caducidad de Contraseñas de Usuario . Si un usuario olvida usar su contraseña de un solo uso, esta se deshabilitará automáticamente. Para más información, consulte el Servicio de Caducidad de Contraseñas de Usuario en Servicios .
Utilice la caducidad de contraseña con la configuración "Número máximo de intentos fallidos de inicio de sesión" al registrar usuarios. Para obtener más información, consulte "Finalizar operaciones de perfil de entidad" .
Aumentar el número de rondas de BCrypt, lo que ralentiza el hash de contraseñas. Consulte la configuración de ejbca.passwordlogrounds en conf/ejbca.properties.sample.
Si implementa otros escenarios de autenticación de usuarios, recuerde que la autenticación con certificado es más segura que la autenticación con contraseña (por ejemplo, LDAP). Si los usuarios de EJBCA se autentican con otra contraseña (no de un solo uso) en lugar de la contraseña de un solo uso habitual, se construirá un mecanismo de autenticación seguro sobre uno más débil.
Contraseñas definidas al configurar EJBCA
Los archivos de configuración (en $EJBCA_HOME/conf) contienen algunas contraseñas. No se considera un riesgo de seguridad declarar todas estas contraseñas en texto plano. Cualquier persona que inicie sesión en el servidor con EJBCA puede, además de leer estos archivos, hacer lo que desee con la CLI de EJBCA. Si una persona no autorizada puede usar la CLI, esto representa un grave riesgo de seguridad. El acceso a estas contraseñas no supone un gran problema, ya que no tienen uso fuera del servidor (excepto password.encryption.key , que puede usarse para descifrar contraseñas cifradas almacenadas en otro lugar, por ejemplo, en un servidor de bases de datos externo).
Es fundamental restringir el acceso al servidor a un número muy reducido de personas de confianza y promover la separación de funciones y el principio del mínimo privilegio. Por ejemplo, un administrador de bases de datos (DBA) no debería tener acceso al servidor de aplicaciones y, por lo tanto (si se ha personalizado password.encryption.key en el servidor de aplicaciones) no podrá descifrar las contraseñas almacenadas en la base de datos a la que tiene acceso.
Si desea hacer algo con estas contraseñas, las subsecciones de esta sección describen lo que se debe hacer:
Contraseñas utilizadas por EJBCA extraídas de archivos de propiedad
Algunas contraseñas son utilizadas directamente por el código EJBCA. Todas estas contraseñas pueden configurarse cifradas de la misma forma que los PIN utilizados para la activación automática (excepto password.encryption.key , que se utiliza para cifrar las demás contraseñas). Para más información, consulte Activación automática de tokens criptográficos en módulos de seguridad de hardware (HSM) .
Lista de estas contraseñas en varios archivos de configuración:
contraseña.clave de cifrado
ca.contraseña de token
ca.keystorepass
ca.cmskeystorepass
protección de base de datos.tokenpin
Contraseñas utilizadas por el servidor de aplicaciones
Algunas contraseñas no las utiliza EJBCA, sino el servidor de aplicaciones. Si estas contraseñas deben cifrarse, debe ser de forma que el servidor de aplicaciones pueda descifrarlas. Consulte la documentación del servidor de aplicaciones para saber cómo cifrarlas (por ejemplo, la contraseña de la fuente de datos en JBoss).
Estas contraseñas son:
contraseña del servidor de correo electrónico
No es necesario establecer la contraseña del servidor de correo en mail.properties en EJBCA.
Tenga en cuenta que la contraseña del servidor de correo se configura en JBoss/WildFly durante la instalación (solo es necesaria si se deben habilitar las notificaciones por correo electrónico).
contraseña de la base de datos
No es necesario establecer la contraseña de la base de datos en database.properties para que se ejecute EJBCA, se puede omitir en la compilación del servidor EJBCA.
La contraseña en database.properties es necesaria para la CLI de la base de datos EJBCA local.
Tenga en cuenta que la contraseña de la base de datos se configura en JBoss/WildFly durante la instalación.
Contraseñas solicitadas por 'ant install'
Si no define superadmin.password en web.properties, ant install lo solicitará. Dado que EJBCA no necesita conocer esta contraseña tras la creación del token de superadministrador, no se guardará en ningún archivo tras la instalación.
Las contraseñas java.trustpassword y httpsserver.password, también en web.properties, se utilizan para generar archivos de almacén de claves en ant install . Si alguna de estas contraseñas no está predefinida, se solicitará durante la implementación y la instalación.
Si permite que 'ant' solicite estas contraseñas, debe configurarlas (cifradas, si es posible) en la configuración del servidor de aplicaciones. El archivo del servidor de aplicaciones se copia en ant web-configure (p. ej., jboss-5.1.0.GA/server/default/deploy/jbossweb.sar/server.xml). A continuación, debe sustituir manualmente las cadenas 'changeThisToThePassword' en el archivo de configuración por texto sin cifrar o, si es posible, contraseñas cifradas (específicas del servidor de aplicaciones).
Protección de la integridad de la base de datos
La protección de la integridad de la base de datos consta de una columna rowProtection adicional en todas las tablas protegidas.
Para mayor flexibilidad, las versiones y el ID de clave se integran en la línea rowProtection. Las versiones permiten modificar las tablas de forma segura, ya que la clase de entidad puede crear la "versión 2" de la cadena de protección con nuevos campos, pero verificar las filas de la "versión 1" y otras versiones anteriores sin el campo adicional. ProtectData puede actualizar el algoritmo utilizado, etc., iterando el número de versión. La clave de protección se puede cambiar, ya que el usuario define el ID de clave del token criptográfico y siempre verifica con un ID de clave específico. Los ID de clave se especifican en la configuración y varios ID de clave pueden estar activos en cualquier momento.
Configuración
La protección de la integridad de la base de datos debe configurarse antes de instalar y usar EJBCA por primera vez; de lo contrario, se insertarán datos sin protección en la base de datos. Una vez configurado el sistema para la protección de la base de datos, su uso fallará. La protección de la base de datos se configura en el archivo conf/databaseprotection.properties.
Limitaciones
Una limitación de la aplicación que utiliza este esquema de protección es que ya no se pueden realizar actualizaciones masivas mediante una consulta JPQ con UPDATE donde xyz. Esto se debe a que los eventos @Pre/Post no se activan para los beans JPA al hacerlo. Esta limitación puede ser grave en instalaciones muy grandes.
No podemos realizar actualizaciones directas de la base de datos, esa es por supuesto la idea central de la protección de la base de datos, pero de todos modos también es una limitación;
Al utilizar un HSM para la protección, actualmente solo está disponible la protección de firma digital, no HMAC.
Auditoría de seguridad con integridad protegida
La implementación de auditoría de seguridad de IntegrityProtectedDevice almacena las entradas de registro en la base de datos y se basa en la Protección de Integridad de la Base de Datos de EJBCA para proteger la autenticidad de los eventos de registro. Cada evento de registro recibe un identificador compuesto por un "nodeId" y un "sequenceNumber" que forma parte de los datos protegidos por la integridad. El nodeId es configurable y debe ser único para cada JVM en un clúster con acceso compartido a la base de datos. El "sequenceNumber" es único para cada nodeId y comienza en 0. El sequenceNumber de un nodo (JVM) se lee cuando se escribe la primera entrada de registro en este dispositivo y se guarda en memoria durante la vida útil de la JVM.
La seguridad de esta implementación depende de:
Token de protección de integridad de la base de datos.
El número de secuencia en la memoria para cada nodo (JVM).
El uso de un número de secuencia evitará que se elimine una sola entrada del registro sin que sea posible detectarla. Mantener el número de secuencia en la JVM evitará que se eliminen todas las entradas del registro hasta un momento anterior sin que sea posible detectarlas.
Esta implementación no puede detectar:
Eliminación de todas las últimas entradas de registro de un nodo hasta un punto anterior en el tiempo si la JVM del nodo no se está ejecutando.
Entradas de registro falsificadas si el token de protección de integridad de la base de datos se ve comprometido.
La motivación de este diseño es que cada nodo (JVM) no tiene que esperar a otros nodos en un clúster (solo para bases de datos compartidas). Internamente, en cada JVM, el único bloqueo entre subprocesos ocurre cuando el número de secuencia se actualiza automáticamente. Esto permitirá un escalamiento horizontal muy alto sin necesidad de comunicación entre JVM cuando la base de datos compartida admita el bloqueo de filas.
Al utilizar esta implementación, la integridad de cada entrada de registro obtenida siempre se valida cuando se carga desde la base de datos, pero no se realiza una validación completa con verificaciones de números de secuencia faltantes.
La configuración del dispositivo de registro de integridad protegida se encuentra en los archivos:
conf/cesecore.propertiesconf/databaseprotection.propertiesCon la herramienta CLI de Base de Datos Local , puede verificar una tabla completa. La herramienta indica si una fila de la tabla no se puede verificar. En el caso de la tabla AuditRecordData, también se comprobará mediante el número de secuencia que no falte ninguna fila. Para obtener más información sobre la herramienta CLI de Base de Datos Local, consulte Interfaces de Línea de Comandos .
Reparación de brechas de secuencia
El número de secuencia del registro de auditoría por nodo es un contador. Siempre que sea necesario escribir un registro de auditoría, el contador se recupera y se incrementa (como una operación atómica). Si la escritura en la base de datos falla:
El contador no se reducirá (dado que varios subprocesos pueden estar operando en él, no hay forma de saber cuál es la entrada faltante).
Habrá una brecha de secuencia en el registro.
Esto también podría ocurrir si un atacante ha eliminado ciertas entradas de la base de datos para ocultar su rastro. Dado que no escribir el registro de auditoría en la base de datos revertirá la transacción que inició el evento de seguridad, este no se ejecutará. Lo más probable es que se pueda correlacionar esto con los registros del servidor del momento en que esto ocurrió y descubrir que la base de datos no estaba disponible por razones técnicas.
Por ejemplo, un clúster MariaDB+Galera que está en proceso de reformar un quórum podría experimentar algunas transacciones fallidas antes de volver a estar operativo.
Actualmente no existe una manera sencilla de "reparar" dicha secuencia, pero debería documentarse por qué ocurrió (o más bien, que la causa fue técnica y no maliciosa).
Una forma no fácil de usar para reparar brechas de secuencia sigue este principio:
En una copia de la base de datos, elimine todos los registros excepto 1 (o tantos como huecos tenga)
Actualice el(los) registro(s), usando SQL para cambiar sequenceNumber por los que faltan y primaryKey por algo único
Ejecute ejbca-db-cli export desde la base de datos de copia. Esto generará un volcado con solo estos registros, que coinciden con los espacios vacíos en la base de datos original.
Ejecute ejbca-db-cli import para importar este volcado en la base de datos original. Esto insertará los números de secuencia faltantes, utilizando la protección de base de datos configurada en ejbca-db-cli.
Firma de registros externos
La firma de registros a medida que se archivan (rotan) se puede realizar de varias maneras, por ejemplo:
Los registros se envían a syslog y la rotación de syslog puede firmar archivos cuando se rotan, utilizando OpenSSL o un servidor de marca de tiempo (TSA).
Los registros se almacenan mediante JBoss y se puede utilizar un appender log4j especial para firmar archivos cuando se rotan, utilizando un servidor de marca de tiempo (TSA).
Firma de registros mediante Logrotate y OpenSSL
Guarde y habilite la siguiente configuración de logrotate para syslog, que normalmente se almacena como el archivo syslog en el directorio /etc/logrotate.d. Si ya existe una configuración de syslog, elimínela y combine los cambios si es necesario. Syslog no suele rotarse en la mayoría de las distribuciones de Linux.
Después de habilitar la configuración, asegúrese de que logrotate se ejecute con la frecuencia necesaria. Normalmente, logrotate se ejecuta todas las noches, pero para una mayor frecuencia para syslog, agregue una entrada en el crontab para ejecutarlotate cada hora, por ejemplo. Llame a logrotate con el archivo de configuración especificado: logrotate syslog.conf .
/var/log/syslog {rotate 5postrotate/usr/bin/killall -HUP syslogdendscriptlastactionOPENSSL=/usr/bin/opensslLOGFILE=/var/log/syslogFILE= "$LOGFILE.`date +%F.%H:%M:%S`.log"SIGNATUREFILE= "$FILE.sign"1 cp $LOGFILE. "$FILE"PRIVATEKEY= "/etc/logsigner/qc1.priv"$OPENSSL dgst -sign $PRIVATEKEY -sha1 $FILE > $SIGNATUREFILEendscript}Tenga en cuenta que cuando se almacena en logrotate.d, la configuración de syslog se llamará cuando logrotate se ejecute normalmente. qc1.priv es la clave privada utilizada para firmar el archivo de registro.
A continuación se muestra un script de shell simple para firmar y verificar usando OpenSSL, así como para convertir un archivo pkcs12 en archivos de clave pública y clave privada que usa OpenSSL.
Para verificar, puede emitir el comando: log-sign.sh verify qc1.pub logfile.log lofile.log.sign .
#!/bin/bash# Openssl command for signing and verifying#openssl dgst -sign superadmin.key -sha1 test.txt > test.txt.sign#openssl dgst -verify superadmin.pubkey -signature test.txt.sign -sha1 test.txt# Openssl command to convert a p12 file to cert and key files in pem# First cert:#openssl pkcs12 -in qc1.p12 -nodes -nokeys -clcerts -out qc1.pem# Then key public#openssl x509 -in qc1.pem -pubkey -noout > qc1.pub# Then clave private key:#openssl pkcs12 -in qc1.p12 -nodes -nocerts -out qc1.privOPENSSL=/usr/bin/opensslSCRIPTNAME=`basename $ 0 `OPTION=$ 1DATE=`date + "%Y-%m-%d" `if [ "$OPTION" = "sign" ]; thenPRIVATEKEY= "$2"FILE= "$3"SIGNATUREFILE= "$4"$OPENSSL dgst -sign $PRIVATEKEY -sha1 $FILE > $SIGNATUREFILEexit 0elif [ "$OPTION" = "verify" ]; thenPUBLICKEY= "$2"FILE= "$3"SIGNATUREFILE= "$4"$OPENSSL dgst -verify $PUBLICKEY -signature $SIGNATUREFILE -sha1 $FILEexit 0elseecho "Usage:"echo "To sign files you have to edit the script and add the files you want signed."echo "$SCRIPTNAME sign "echo "$SCRIPTNAME verify "exit 0fi Firma de registros con Logrotate y TSA
Se utiliza el mismo enfoque para el sellado de tiempo mediante un servidor de Autoridad de Sellado de Tiempo (TSA) en lugar de OpenSSL. El siguiente ejemplo utiliza la CLI del cliente SignClient y la TSA de SignServer .
La nueva configuración de logrotate:
/var/log/syslog {rotate 5postrotate/usr/bin/killall -HUP syslogdendscriptlastactionTSACLIENTDIR=/opt/signserverLOGFILE=/var/log/syslogFILE= "$LOGFILE.`date +%F.%H:%M:%S`.log"SIGNATUREFILE= "$FILE.sign"1 cp $LOGFILE. "$FILE"$TSACLIENTDIR/bin/signclient timestamp -url "http://127.0.0.1:8080/signserver/tsa?signerId=1" -infile $FILE -outrep $SIGNATUREFILE -base64endscript}Reemplace la dirección IP y el puerto (127.0.0.1:8080) con la IP y el puerto de su TSA actual y el nuevo script de shell para verificación (o firma manual), log-sign-tsa.sh:
#!/bin/bashTSACLIENTDIR=/opt/signserverSCRIPTNAME=`basename $ 0 `OPTION=$ 1DATE=`date + "%Y-%m-%d" ` if [ "$OPTION" = "sign" ]; thenFILE= "$2"SIGNATUREFILE= "$3"TSAURL= "$4"$TSACLIENTDIR/bin/signclient timestamp -url $TSAURL -infile $FILE -outrep $SIGNATUREFILE -base64exit 0elif [ "$OPTION" = "verify" ]; thenPUBLICKEY= "$2"FILE= "$3"SIGNATUREFILE= "$4"$TSACLIENTDIR/bin/signclient timestamp -verify -inrep $SIGNATUREFILE -signerfile $PUBLICKEYsha1sum $FILEexit 0elseecho "Usage:"echo "To sign files you have to edit the script and add the files you want signed" echo "$SCRIPTNAME sign"echo "$SCRIPTNAME verify"exit 0fiAl verificar el token de marca de tiempo, se imprime el hash SHA1 del token de marca de tiempo (firmado) y el hash SHA1 calculado del archivo. Debe compararlos manualmente.
Firma de registros mediante script externo en JBoss
Tenga en cuenta que PrimeKey ya no admite activamente esta operación.
Existe una implementación que ejecuta un script externo cuando se renuevan los archivos de registro de JBoss. Esto puede ocurrir cada hora, por ejemplo.
Detener JBoss
Emita el comando: ant jbosslogsigning
Copiar dist/ejbcalogsigning.jar a jboss.home/standalone/lib
Configure jboss.home/server/default/conf/log4j.xml, según lo siguiente
Cree el script que se va a ejecutar (ver ejemplo a continuación)
Iniciar JBoss
Para utilizar ScriptrunningDailyRollingFileAppender, reemplace la sección de registro en standalone.xml con algo como lo siguiente:
<!-- A time/date based rolling appender that signs rolled over log files using TSA --><appender name= "FILE" class = "org.ejbca.appserver.jboss.ScriptrunningDailyRollingFileAppender" ><errorHandler class = "org.jboss.logging.util.OnlyOnceErrorHandler" /><param name= "File" value= "${jboss.server.log.dir}/server.log" /><param name= "Append" value= "false" /><param name= "Script" value= "/home/jboss/log-sign-tsa-jboss.sh" /><!-- Rollover at midnight each day --><param name= "DatePattern" value= "'.'yyyy-MM-dd" /><!-- Rollover at the top of each hour<param name= "DatePattern" value= "'.'yyyy-MM-dd-HH" />--><!-- Rollover at the beginning of every minute<param name= "DatePattern" value= "'.'yyyy-MM-dd-HH-mm" />--><layout class de diseño = "org.apache.log4j.PatternLayout" ><!-- The patrón default pattern: Date Priority [Category] Message\n --><param name= "ConversionPattern" value= "%d %-5p [%c] %m%n" /><!-- The full pattern: Date MS Priority [Category] (Thread:NDC) Message\n<param name= "ConversionPattern" value= "%d %-5r %-5p [%c] (%t:%x) %m" />--></layout></appender>
Donde /opt/log-sign-tsa-jboss.sh es el script que debe ejecutarse para realizar la firma:
#!/bin/bashTSACLIENTDIR=/opt/signserverTSAURL= "http://127.0.0.1:8080/signserver/tsa?signerId=1"SCRIPTNAME=`basename $ 0 `FILE= "$1"SIGNATUREFILE= "$FILE.tsa"$TSACLIENTDIR/bin/signclient timestamp -url $TSAURL -infile $FILE -outfile $SIGNATUREFILEexit 0
Puede verificar las marcas de tiempo con un cliente de marca de tiempo, por ejemplo el que viene con SignServer TSA:
bin/signclient timestamp -verify -signerfile tsa1.pem -inrep server.logToken was validated successfully.Token was generated on: Fri Jul 28 de julio 18 CEST 00 : 59 : 2006Token hash alg: SHA1MessageDigest=1a02dc7e05d06df45d2e0f74da502513852064d5 sha1sum server.log. 2006 - 07 - 28 - 18 - 581a02dc7e05d06df45d2e0f74da502513852064d5 *server.log. 2006 - 07 - 28 - 18 - 58Si los hashes del token de marca de tiempo (MessageDigest) coinciden con el hash de sha1sum, el archivo se verifica, es decir, no se ha modificado desde que se generó el token de marca de tiempo.
Privilegios de la base de datos
Para que JBoss pueda crear las tablas de base de datos necesarias durante la instalación de EJBCA, el usuario de la base de datos de EJBCA necesita privilegios CREATE TABLE. Durante las actualizaciones, EJBCA necesita privilegios CREATE y ALTER TABLE, además de los privilegios SELECT, UPDATE, INSERT y DELETE.
Tras instalar EJCBA, solo se necesitan los comandos SELECT, UPDATE, INSERT y DELETE durante las operaciones normales. La tabla LogEntryData solo se usará con SELECT e INSERT.
En lugar de cambiar los privilegios del usuario EJBCA, se recomienda tener los siguientes dos usuarios:
ejbca: Se utiliza para operaciones regulares.
ejbca-admin: para la instalación y las actualizaciones, EJBCA se vuelve a implementar con ejbca-admin configurado en conf/database.properties .
El script doc/howto/mysql-privileges.sh crea un script SQL que se ejecuta para limitar los privilegios en una base de datos MySQL. El script establece privilegios restringidos para cada tabla de la base de datos EJBCA. Consulte el script para obtener la documentación en línea.
Denegación de servicio
Debido a grandes paquetes de datos o conexiones lentas
No hay forma de limitar los paquetes de datos que llegan a JBoss mediante una solicitud HTTP desde dentro de JBoss. Esto se debe al funcionamiento del protocolo TCP. La mejor manera de evitar este tipo de ataques de denegación de servicio (DoS) es usar un firewall o proxy que limite el tamaño de la solicitud y lo configure correctamente. Por ejemplo, se puede usar mod_reqtimeout en un proxy de Apache.
Conexiones SSL en MariaDB
Para obtener información sobre el uso de la conexión SSL para la conexión de la base de datos, consulte la documentación de MariaDB sobre Conexiones seguras .
Otras precauciones
Cambiar al modo de producción
Cambiar al modo de producción (predeterminado) configurando ejbca.productionmode en conf/ejbca.properties evitará que ant inicie pruebas JUnit e implemente la compilación de CA en un respondedor OCSP y viceversa.
Registros de transacciones de bases de datos en MySQL
Para obtener más información, consulte Manual de referencia de MySQL: El registro binario .
Contabilidad del sistema en Linux
Consulte su distribución para obtener detalles sobre el paquete o consulte información general sobre seguridad de Linux: contabilidad de usuarios, sistemas y procesos.