🥇Comment configurer Elasticsearch pour éviter les fuites

Au cours de la dernière année, de nombreuses fuites de bases de données ont eu lieu. Elasticsearch (voici, voici et voici). Dans de nombreux cas, des données personnelles étaient stockées dans la base. Ces fuites auraient pu être évitées si, après le déploiement de la base, les administrateurs avaient pris le temps de vérifier quelques réglages simples. Aujourd'hui, nous allons en parler.

Nous précisons tout de suite qu'en pratique, nous utilisons Elasticsearch pour le stockage des journaux et l'analyse des journaux de sécurité de l'information, des systèmes d'exploitation et des logiciels dans notre plateforme IaaS, conforme aux exigences de la loi 152-FZ, Cloud-152.

Vérifions si la base de données n'est pas exposée sur Internet.

Dans la plupart des cas de fuite connus (voici, voici) l'attaquant a accédé aux données de manière simple et évidente : la base a été publiée sur Internet et pouvait être connectée sans authentification.

Commençons par parler de la publication sur Internet. Pourquoi cela se produit-il ? En effet, pour un fonctionnement plus flexible d'Elasticsearch, il est recommandé il est nécessaire de créer un cluster de trois serveurs. Pour que les bases de données communiquent entre elles, il faut ouvrir des ports. En fin de compte, les administrateurs ne limitent pas l'accès à la base, et il est possible de se connecter à la base de données de partout. Vérifier s'il y a un accès externe à la base est facile. Il suffit de saisir dans le navigateur : http://[IP/Nom Elasticsearch]:9200/_cat/nodes?v

Si vous pouvez y accéder, alors dépêchez-vous de le fermer.

Nous protégeons la connexion à la base de données.

Maintenant, nous allons faire en sorte qu'il ne soit pas possible de se connecter à la base sans authentification.

Elasticsearch dispose d'un module d'authentification qui limite l'accès à la base, mais il est uniquement dans le package payant de plugins X-Pack (1 mois d'utilisation gratuite).

La bonne nouvelle est qu'à l'automne 2019, Amazon a ouvert ses développements qui se recoupent avec X-Pack. La fonction d'authentification lors de la connexion à la base est devenue disponible sous licence libre pour la version Elasticsearch 7.3.2, et une nouvelle version pour Elasticsearch 7.4.0 est déjà en cours.

Ce plugin s'installe facilement. Accédez à la console du serveur et connectez-vous au référentiel :

Basé sur RPM :

curl https://d3g5vo6xdbdb9a.cloudfront.net/yum/opendistroforelasticsearch-artifacts.repo -o /etc/yum.repos.d/opendistroforelasticsearch-artifacts.repo

yum update

yum install opendistro-security

Basé sur DEB :

wget -qO - https://d3g5vo6xdbdb9a.cloudfront.net/GPG-KEY-opendistroforelasticsearch | sudo apt-key add -

Nous configurons l'interaction entre les serveurs via SSL.

Lors de l'installation du plugin, la configuration du port de connexion à la base de données est modifiée. Le chiffrement SSL est activé dessus. Pour que les serveurs du cluster puissent continuer à communiquer entre eux, il est nécessaire de configurer l'interaction entre eux via SSL.

La confiance entre les hôtes peut être établie à l'aide d'une autorité de certification (CA) propre ou non. Avec la première méthode, c'est simple : il suffit de s'adresser à des spécialistes en CA. Passons directement à la seconde.

Créons une variable avec le nom complet du domaine :
```
export DOMAIN_CN="example.com"
```

Créons une clé privée :

openssl genrsa -out root-ca-key.pem 4096

Signons le certificat racine. Gardez-le comme la prunelle de vos yeux : en cas de perte ou de compromission, la confiance entre tous les hôtes devra être réétablie.
```
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
```

Créons une clé d'administrateur :

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

Créons une demande de signature de certificat :

openssl req -new -subj "\/C=RU\/ST=Moscow\/O=Moscow Inc.\/CN=${DOMAIN_CN}\/CN=admin " 
-key admin-key.pem -out admin.csr

Créons le certificat de l'administrateur :

openssl x509 -req -extensions usr_cert -in admin.csr -CA root-ca.pem 
-CAkey root-ca-key.pem -CAcreateserial -sha256 -out admin.pem

Créons des certificats pour le nœud 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

Créons une demande de signature :

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

Signons le certificat :

openssl x509 -req -in node.csr -CA root-ca.pem -CAkey root-ca-key.pem -CAcreateserial 
-sha256 -out node.pem

Disposons le certificat entre les nœuds Elasticsearch dans le dossier :
```
/etc/elasticsearch/
```
nous aurons besoin des fichiers :
```
        node-01-key.pem
	node-01.pem
	admin-key.pem
	admin.pem
	root-ca.pem
```

Configurer /etc/elasticsearch/elasticsearch.yml – renommez les fichiers des certificats avec ceux que nous avons générés :

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=Moscow Inc.,ST=Moscow,C=RU
	opendistro_security.nodes_dn:
	  − CN=node-01.example.com,O=Moscow Inc.,ST=Moscow,C=RU

Modifier les mots de passe des utilisateurs internes

Avec la commande ci-dessous, nous affichons le hachage du mot de passe dans la console :
```
sh ${OD_SEC}/tools/hash.sh -p [mot de passe]
```

Nous remplaçons le hachage dans le fichier par celui obtenu :

/usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml

Configurer le pare-feu dans le système d'exploitation

Autoriser le démarrage du pare-feu :
```
systemctl enable firewalld
```
Nous le démarrons :
```
systemctl start firewalld
```

Autoriser la connexion à Elasticsearch :

firewall-cmd --set-default-zone work
firewall-cmd --zone=work --add-port=9200/TCP --permanent

Redémarrer les règles du pare-feu :
```
firewall-cmd --reload
```
Affichons les règles en cours d'exécution :
```
firewall-cmd --list-all
```

Appliquons tous nos changements à Elasticsearch

Créons une variable avec le chemin complet vers le dossier contenant le plugin :
```
export OD_SEC="/usr/share/elasticsearch/plugins/opendistro_security/"
```

Lançons le script qui mettra à jour les mots de passe et vérifiera les configurations :

${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

Vérifions si les modifications ont été appliquées :

curl -XGET https://[IP/Nom Elasticsearch]:9200/_cat/nodes?v -u admin:[mot de passe] --insecure

Voilà, ce sont les configurations minimales qui protègent Elasticsearch contre les connexions non autorisées.

Source : habr.com