Ինչպես կարգավորել Elasticsearch-ը, որպեսզի արտահոսքեր տեղի չունենան

Վերջին տարվա ընթացքում շատ արտահոսումներ են տեղի ունեցել բազաներից Elasticsearch (այս, այս և այս). Քանի որ շատ դեպքերում բազայում պահպանվում էին անձնական տվյալներ: Այս արտահոսումները կարելի էր կանխել, եթե բազայի բաշխումից հետո ադմինիստրատորները ջանքեր ներդնեին պարզ որոշումների ստուգման վրա: Այսօր եկեք խոսենք դրանց մասին։

Անհրաժեշտ է նշել, որ մեր պրակտիկայում օգտագործում ենք Elasticsearch՝ տեղեկությունների անվտանգության, ՕՍ և ծրագրային ապահովման մուտքերի և հաշվետվությունների պահպանման ու վերլուծության համար մեր IaaS-platform-ում, որը համապատասխանում է 152-ФЗ պահանջներին, Cloud-152: 

Ինչպես կարգավորել Elasticsearch-ը, որպեսզի արտահոսքեր տեղի չունենան

Ստուգում ենք, թե արդյոք բազան "չէ՞ որ միացում է կատարվում" ինտերնետում

Ծանոթագրելով հայտնի արտահոսումների մեծ մասում (այս, այս) հանցագործը հեշտությամբ և պարզ կերպով ստանում է տվյալների հասանելիություն՝ բազան հրապարակվում է ինտերնետում, և այն կարելի է միացնել առանց վավերացման։  

Առաջին հերթին եկեք քննարկենք բազայի հրապարակումը ինտերնետում։ Ինչու դա տեղի է ունենում: Իրողությունն այն է, որ ավելի ճկուն աշխատանքի համար Elasticsearch recommendation ստեղծում է երեք սերվերներից բաղկացած կլաստեր։ Բազաները միմյանց հետ հաղորդակցվելու համար անհրաժեշտ է բացել պորտեր։ Որպեսզի ադմինիստրատորները որևէ կերպ չսահմանափակեն բազաների հասանելիությունը, նրանք թույլ են տալիս միացմանը դրան՝ ցանկացած տեղից: Ստուգել, թե արդյոք թվային կամաց-կամաց բազայի հասանելիություն կա, հեշտ է։ պարզապես բրաուզերում որակում ենք http://[IP/Elasticsearch Name]:9200/_cat/nodes?v

Եթե կարելի է մուտք գործել, ապա անմիջապես փակեք։

Պաշտպանենք տվյալների բազայի միացմանը

Հիմա անելու ենք այնպես, որ բազային մուտք չլինի մասնավոր ընկերություն առանց վավերացման։

Elasticsearch-ում կա վավերացման մոդուլ, որը սահմանափակում է բազային մուտքը, բայց այն միայն X-Pack-ի վճարովի պլագինի հավաքածուում է (1 ամիս անվճար օգտագործման համար։)

Փորձության լավ նորությունն այն է, որ 2019 թվականի աշնանը Amazon-ը բացեց իր մշակումները, որոնք համընկնում են X-Pack-ի։ Բազայի հետ միանալու վավերացման ֆունկցիան հասանելի է դարձել բաց տողով Elasticsearch-ի 7.3.2 տարբերակի համար, և արդեն աշխատում է նոր թողարկումը Elasticsearch 7.4.0-ի համար։

Այս պլագինը հեշտությամբ կարելի է տեղադրել։ Մուտք ենք գործում սերվերի կոնսոլ և միացնում ռեպոզիտորիան.

RPM հիմունքներով:

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

yum update

yum install opendistro-security


DEB հիմունքներով:

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

Կազմակերպենք սերվերների միջև SSL առնչությունը

Պլագինի տեղադրման ժամանակ փոփոխվում է բազայի միացման պորտի կոնֆիգուրացումը։ Այն ի մի է բերվում SSL-ով և՝ ի տես սերվերներից կլաստերի միջև շարունակական հաղորդակցության՝ անհրաժեշտ է կազմակերպել իրենց միջև SSL-ի միջոցով:

Հյուրատերը կարող է վստահություն հաստատել պաշպանության կենտրոնների միջոցով կամ առանց նրանց։ Առաջին տարբերակում ամեն բան պարզ է՝ պարզապես անհրաժեշտ է դիմել CA մասնագետների։ Այժմ անցվում ենք երկրորդին։

  1. Ստեղծենք փոփոխական լիարժեք տիրույթի անունով:

    export DOMAIN_CN="example.com"

  2. Ստեղծենք անձնական բանալի՝

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

  3. Մեկը ենթադրելու արժեհամակարգի ոսպնյակն է: Պահեք այն իբրև ձեր աչքի գերահայտ գոհար, քանի որ դրա կորուստը կամ վտանգում նշանակում է, որ անհրաժեշտ է վերակարգել վստահությունը բոլոր հոստինգների միջև:

    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

  4. Ստեղծում ենք կառավարիչի բանալի:

    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

  5. Ստեղծում ենք վկայապաշտպանության 요청:

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

  6. Ստեղծում ենք կառավարիչի վկայագիր:

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

  7. Ստեղծում ենք վկայագրեր 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

  8. Ստեղծում ենք ստորագրության请求:

    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

  9. Ստորագրում ենք վկայագիր:

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

  10. Վկայագիրը տարածում ենք Elasticsearch հանգույցների միջեւ հետևյալ папка:

    /etc/elasticsearch/


    նրանց մեզ անհրաժեշտ են файлы:

            node-01-key.pem
    	node-01.pem
    	admin-key.pem
    	admin.pem
    	root-ca.pem

  11. Կարգավորում ենք /etc/elasticsearch/elasticsearch.yml – փոխում ենք վկայագրերի ֆայլերի անունները, որոնք մենք ստեղծել ենք:

    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

Ս əmпովում ենք ներքին օգտվողների զվիճակները

  1. Ս պիտակով բերելով հեշը կոնսոլում:

    sh ${OD_SEC}/tools/hash.sh -p [пароль]

  2. Ս պիտակները փոխում ենք ֆայլում ստացվածի:

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

Անհատային համաձայներ կարգավորելու գործընթացը:

  1. Թույլ ենք տալիս անհատային համաձայներ:

    systemctl enable firewalld

  2. Սկսում ենք այն:

    systemctl start firewalld

  3. Թույլ ենք տալիս կապվել Elasticsearch-ին:

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

  4. Փոխում ենք անհատային համաձայների կանոնները:

    firewall-cmd --reload

  5. Փորձում ենք գործողական կանոնները:

    firewall-cmd --list-all

Միջոցառում ենք բոլոր մեր փոփոխություններն Elasticsearch-ին

  1. Ստեղծում ենք փոփոխություն ամբողջական հասցեով, որտեղ էլեմենտը:

    export OD_SEC="/usr/share/elasticsearch/plugins/opendistro_security/"

  2. Սկսում ենք սկրիպտը, որը կթարմացնի զվիճակները և կտրամադրի կարգավորումները:

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

  3. Ստուգում ենք, արդյոք փոփոխությունները կիրառվել են:

    curl -XGET https://[IP/Elasticsearch_Name]:9200/_cat/nodes?v -u admin:[password] --insecure

Այստեղ ամեն ինչ է, դա նվազագույն կարգավորումներ են, որոնք պաշտպանում են Elasticsearch- ը չհեղինակավորված միացումներից:

Ընտանիք: habr.com

Գնել հուսալի հյուրընկալում DDoS պաշտպանությամբ, VPS VDS սերվերներով 🔥 Գնել հուսալի հյուրընկալում DDoS պաշտպանությամբ, VPS VDS սերվերներով | ProHoster