En el último año, ha habido muchas filtraciones de bases de datos. (, y ). En muchos casos, se almacenaban datos personales en la base de datos. Estas filtraciones se podrían haber evitado si, después de desplegar la base de datos, los administradores se hubieran tomado la molestia de verificar algunas configuraciones sencillas. Hoy hablaremos de ellas.
Primero aclaremos que en nuestra práctica utilizamos Elasticsearch para almacenar registros y analizar los logs de los sistemas de protección de información, sistemas operativos y software en nuestra plataforma IaaS, que cumple con los requisitos de la ley 152-FZ, Cloud-152.
Verificamos si la base de datos 'no está expuesta' en internet.
En la mayoría de los casos conocidos de filtraciones (, ) los atacantes accedieron a los datos de manera simple y directa: la base fue publicada en internet, y se podía conectar sin autenticación.
Primero, enfoquémonos en la publicación en internet. ¿Por qué ocurre esto? La razón es que para un funcionamiento más flexible de Elasticsearch se crea un clúster de tres servidores. Para que las bases de datos se comuniquen entre sí, es necesario abrir puertos. Al final, los administradores no limitan de ninguna manera el acceso a la base de datos, y a esta se puede conectar desde cualquier lugar. Comprobar si hay acceso externo a la base de datos es fácil. Simplemente ingresamos en el navegador http://[IP/Nombre de Elasticsearch]:9200/_cat/nodes?v
Si se puede acceder, es necesario cerrar inmediatamente.
Proteger la conexión a la base de datos.
Ahora haremos que no se pueda conectar a la base de datos sin autenticación.
Elasticsearch cuenta con un módulo de autenticación que limita el acceso a la base de datos, pero solo está en el paquete de plugins de pago X-Pack (1 mes de uso gratuito).
Las buenas noticias son que en otoño de 2019, Amazon abrió sus desarrollos que se intersectan con X-Pack. La función de autenticación al conectarse a la base de datos se volvió disponible bajo una licencia libre para la versión 7.3.2 de Elasticsearch, y ya está en desarrollo un nuevo lanzamiento para la versión 7.4.0.
Este plugin se instala fácilmente. Ingresamos a la consola del servidor y conectamos el repositorio:
Basado en RPM:
curl https://d3g5vo6xdbdb9a.cloudfront.net/yum/opendistroforelasticsearch-artifacts.repo -o /etc/yum.repos.d/opendistroforelasticsearch-artifacts.repo
yum update
yum install opendistro-security
Basado en DEB:
wget -qO ‐ https://d3g5vo6xdbdb9a.cloudfront.net/GPG-KEY-opendistroforelasticsearch | sudo apt-key add -Configuramos la interacción entre los servidores a través de SSL.
Al instalar el plugin, se modifica la configuración del puerto de conexión a la base de datos. Se habilita la encriptación SSL en este puerto. Para que los servidores del clúster puedan seguir colaborando, es necesario configurar la interacción entre ellos mediante SSL.
La confianza entre los hosts se puede establecer con o sin una autoridad de certificación propia. Con la primera opción es bastante claro: solo hay que acudir a especialistas en CA. Pasemos directamente a la segunda.
- Creamos una variable con el nombre completo de dominio:
export DOMAIN_CN="example.com" - Creamos una clave privada:
openssl genrsa -out root-ca-key.pem 4096 - Firmamos el certificado raíz. Guárdelo como un tesoro: en caso de pérdida o compromiso, será necesario reconfigurar la confianza entre todos los hosts.
openssl req -new -x509 -sha256 -subj "\/C=RU\/ST=Moscow\/O=Moscow, Inc.\/CN=${DOMAIN_CN}" -key root-ca-key.pem -out root-ca.pem - Creamos la clave del administrador:
openssl genrsa -out admin-key-temp.pem 4096 openssl pkcs8 -inform PEM -outform PEM -in admin-key-temp.pem -topk8 -nocrypt -v1 PBE-SHA1-3DES -out admin-key.pem - Creamos una solicitud para la firma del certificado:
openssl req -new -subj "\/C=RU\/ST=Moscow\/O=Moscow Inc.\/CN=${DOMAIN_CN}\/CN=admin " -key admin-key.pem -out admin.csr - Creamos el certificado del administrador:
openssl x509 -req -extensions usr_cert -in admin.csr -CA root-ca.pem -CAkey root-ca-key.pem -CAcreateserial -sha256 -out admin.pem - Creamos certificados para el nodo de Elasticsearch:
export NODENAME="node-01" openssl genrsa -out ${NODENAME}-key-temp.pem 4096 openssl pkcs8 -inform PEM -outform PEM -in ${NODENAME}-key-temp.pem -topk8 -nocrypt -v1 PBE-SHA1-3DES -out ${NODENAME}-key.pem - Creamos una solicitud para la firma:
openssl req -new -subj "\/C=RU\/ST=Moscow\/O=Moscow Inc.\/CN=${NODENAME}.${DOMAIN_CN}" -addext"subjectAltName=DNS:${NODENAME}.${DOMAIN_CN},DNS:www.${NODENAME}.${DOMAIN_CN}" -key ${NODENAME}-key.pem -out ${NODENAME}.csr - Firmamos el certificado:
openssl x509 -req -in node.csr -CA root-ca.pem -CAkey root-ca-key.pem -CAcreateserial -sha256 -out node.pem - Distribuimos el certificado entre los nodos de Elasticsearch en la carpeta:
/etc/elasticsearch/
Necesitaremos los archivos:node-01-key.pem node-01.pem admin-key.pem admin.pem root-ca.pem - Configuramos /etc/elasticsearch/elasticsearch.yml – cambiamos el nombre de los archivos de los certificados a los generados por nosotros:
opendistro_security.ssl.transport.pemcert_filepath: node-01.pem opendistro_security.ssl.transport.pemkey_filepath: node-01-key.pem opendistro_security.ssl.transport.pemtrustedcas_filepath: root-ca.pem opendistro_security.ssl.transport.enforce_hostname_verification: false opendistro_security.ssl.http.enabled: true opendistro_security.ssl.http.pemcert_filepath: node-01.pem opendistro_security.ssl.http.pemkey_filepath: node-01-key.pem opendistro_security.ssl.http.pemtrustedcas_filepath: root-ca.pem opendistro_security.allow_unsafe_democertificates: false opendistro_security.allow_default_init_securityindex: true opendistro_security.authcz.admin_dn: − CN=admin,CN=example.com,O=Moscú Inc.,ST=Moscú,C=RU opendistro_security.nodes_dn: − CN=node-01.example.com,O=Moscú Inc.,ST=Moscú,C=RU
Cambiamos las contraseñas de los usuarios internos
- Con el siguiente comando, mostramos el hash de la contraseña en la consola:
sh ${OD_SEC}/tools/hash.sh -p [contraseña] - Cambiamos el hash en el archivo por el obtenido:
/usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml
Configuramos el cortafuegos en el sistema operativo
- Permitimos el inicio del cortafuegos:
systemctl enable firewalld - Lo iniciamos:
systemctl start firewalld - Permitimos la conexión a Elasticsearch:
firewall-cmd --set-default-zone work firewall-cmd --zone=work --add-port=9200/TCP --permanent - Reiniciamos las reglas del cortafuegos:
firewall-cmd --reload - Mostrando reglas activas:
firewall-cmd --list-all
Aplicando todos nuestros cambios a Elasticsearch
- Creamos una variable con la ruta completa a la carpeta del plugin:
export OD_SEC="/usr/share/elasticsearch/plugins/opendistro_security/" - Ejecutamos el script que actualizará las contraseñas y verificará la configuración:
${OD_SEC}/tools/securityadmin.sh -cd ${OD_SEC}/securityconfig/ -icl -nhnv -cacert /etc/elasticsearch/root-ca.pem -cert /etc/elasticsearch/admin.pem -key /etc/elasticsearch/admin-key.pem - Verificamos si se aplicaron los cambios:
curl -XGET https://[IP/Nombre Elasticsearch]:9200/_cat/nodes?v -u admin:[contraseña] --insecure
Eso es todo, estas son las configuraciones mínimas que protegen Elasticsearch de conexiones no autorizadas.
Fuente: habr.com
