Q新闻丨MongoDB勒索软件已波及上万数据库！配置高性能Elastic

　　

　　编辑｜小智

　　本周要闻：MongoDB讹诈软件已涉及上万数据库！经历总结：配置高性能Elasticsearch集群的9个小贴士。

　　MongoDB讹诈软件已涉及上万数据库

不必身份验证的开放式MongoDB数据库实例正在遭遇多个黑客组织的进攻，被攻破的数据库内容会被加密，受害者必须支付赎金才能够找回自己的数据。

进攻者利用配置存在疏漏的开源MongoDB数据库开展了一系列讹诈举动。此番针对MongoDB的讹诈举动最早是由GDI Foundation的安全研究人员Victor Gevers在2016年12月27日发现的，在这以后影响陆续扩展，如今起码有五个不一样黑客组织控制了上万个数据库实例。

截至如今，最后一个参加此次MongoDB讹诈行动的黑客组织是由安全研究人员Nial Merrigan在1月6日发现的。如今，MongoDB进攻者的身份信息只有用于支付赎金的电子邮件地址，最新参加的黑客组织所用的邮件地址为3lix1r@mail2tor.com，该地址已攻下起码17个MongoDB实例，要求受害者支付0.25个比特币才能够找回数据。

如今在Google Docs上有一个列表，其中列出了参加此次进攻的黑客组织名单，详细数目还在增加中。进攻者所要求支付的金额各别，最低仅0.15个比特币，但也有高达1个比特币的赎金。2017年至今，比特币的价值上下动摇，截止1月6日，详细金额约等于892美元。列表见：

https://docs.google.com/spreadsheets/d/1QonE9oeMOQHVh8heFIyeqrjfKEViL0poLnY8mAakKhM/edit#gid=0

此次针对MongoDB的进攻特别简单，利用了配置有误且可公布拜访的数据库，不必具有相应的管理员凭证便可开展进攻。一旦进攻者登录到开放的数据库，随后会整体牟取控制权并盗取或加密数据库，被讹诈的受害者必须支付赎金才能够找回自己的数据。

许多MongoDB数据库处于开放状态，这类情形早已存在。2015年12月，安全研究人员Chris Vickery就曾应用Shodan搜索工具找到了许多端口开放的MongoDB服务器。当时Vickery甚至找到了一个被Mac OS X工具软件MacKeeper的开发者Kromtech应用的，配置存在疏漏的MongoDB数据库。

Shodan的创始人John Matherly跟进了Vickery的研究结果，并在2015年12月称，当时互联网上共有起码35,000个可公布拜访，不必身份验证的MongoDB实例，一年过去了，直到2017年1月，开放式MongoDB数据库的数目不降反增，估量如今共有多达99,000个数据库处于风险中。

作为应对此次MongoDB安全隐患的有用办法，数据库管理员需求参考MongoDB网站上提供的安全清单进行排查。首先需求“启用拜访控制并强迫进行身份验证”。

安全研究人员对eWEEK表示，MongoDB被进攻者进行讹诈彻底在料想当中。

“考虑到MongoDB的流行度和在生产环境中的普及率，以开源的数据库作为目的其实不会让人惊奇。”Dome9一起创始人兼首席实施官Zohar Alon向eWEEK说到：“通常来说，数据库安排过程当中的配置疏漏和忽视就会致使可被进攻者利用的弱点。”

Alon还添加说，用户的人为错误与不够强的安全意识也会威逼到云环境中运转的工作负载。他建议在应用开源数据库等第三方软件之前，用户应该自学有关知识，掌控最好实践和已知弱点等内容。

“风趣的是，大部分人以为数据库是足够安全的，缘由是能够遭到防火墙和数据中心的保护，”Jean-François Dubé首席技术官RiskVision告知eWEEK：“问题在于进攻者依然能够通过消费者所用的端点和第三方衔接拜访这些服务器并获得信息。”

Dubé建议总的来说，应该按期对数据库进行风险评价。

“应用风险评价工具对数据库进行近乎实时监控的企业，会在加密后的数据分开数据库时更明白地发现这一切，”他说。

Mimecast公司网络安全战略师Matthew Gardiner评论说，此次MongoDB被进攻彻底没有让他觉得意外。

“一处开放的，不必身份验证的，存有宝贵数据的系统，或其他任何重要的系统，被互联网将规模缩小上千倍后，最大的问题在于：进攻者为何比及目前才开始下手？”Gardiner说。

本文翻译已获授权，原文链接：

http://www.eweek.com/security/mongodb-ransomware-impacts-over-10000-databases.html

本文译者：大愚若智

　　配置高性能Elasticsearch集群的9个小贴士

Loggly服务底层的许多核心功能都应用了Elasticsearch作为搜索引擎。就像Jon Gifford（译者注：Loggly博客作者之一）在他近期关于“Elasticsearch vs Solr”的文章中所述，日记管理在搜索技术方面产生了一些刻薄的需求，为满足这些需求，必须能够：

在超大规模数据集上靠得住地进行准实时索引 - 在我们的案例中，每秒有超出100,000个日记事件

与此同时，在该索引上靠得住高效地处置超大批的搜索要求

当时我们正在构建Gen2日记管理服务，想保障应用的一切Elasticsearch配置信息，能够获得最优的索引和搜干脆能。喜剧的是，我们发现想在Elasticsearch文档里找到这样的信息特别困难，缘由是它们不只在一个地方。本文总结了我们的学习经历，可作为一个配置属性的参考检讨单(checklist)用于优化你自己应用中的ES。

https://www.loggly.com/blog/nine-tips-configuring-elasticsearch-for-high-performance/

小贴士1：规划索引、分片 和集群增长情形

ES使得创立大批索引和超大批分片特别地简单，但更重要的是懂得每个索引和分片都是一笔开支。假如拥有太多的索引或分片，单单是管理负荷就会影响到ES集群的性能，潜在地也会影响到可用性方面。这里我们专注于管理负荷，但运转大批的索引/分片依然会特别显著地影响到索引和检干脆能。

我们发现影响管理负荷的最大因素是集群状态数据的大小，缘由是它包括了集群中每个索引的一切mapping数据。我们曾经一度有单个集群拥有超出900MB的集群状态数据。该集群尽管在运转但其实不可用。

让我们通过一些数据来了解到底产生了什么……

假设有一个索引包括50k的mapping数据（我们当时是有700个字段）。假如每小时生成一个索引，那么每天将增加24 x 50k的集群状态数据，或许1.2MB。假如需求在系统中保留一年的数据，那么集群状态数据将高达438MB（和8670个索引，43800个分片）。假如与每天一个索引（18.25MB，365个索引，1825个分片）作比较，会看到每小时的索引战略将会是一个彻底不一样的景况。

荣幸的是，一旦系统中有一些真实数据的话，实际上特别简单做这些猜测。我们应该能够看到集群必须处置多少状态数据和多少索引/分片。在上到生产环境之前真的应该演练一下，以便防止清晨3:00收到集群挂掉的电话告警。

在配置方面，我们完万能够控制系统中有多少索引(和有多少分片)，这将让我们阔别危险地带。

小贴士2：在配置前了解集群的拓扑构造

Loggly通过独自的master节点和data节点来运转ES。这里不议论太多的安排细节（请留心后续博文），但为了做出准确的配置选择，需求先确定安排的拓扑构造。

另外，我们为索引和搜索应用单独的ES client节点。这将减轻data节点的一些负载，更重要的是，这样我们的管道便能够和当地客户端通信，从而与集群的其他节点通信。

可通过设置以下两个属性的值为true或false来创立ES的data节点和master节点：

　　Master node: node.master:true node.data:falseData node: node.master:false node.data:trueClient node: node.master:false node.data:false

以上是相比较简单的部分，目前来看一些值得关注的ES高等属性。对大大部分安排场景来说默许设置已经足够了，但假如你的ES应用情形和我们在log管理中碰到的一样难搞，你将会从下文的建议中受益很多。

小贴士3: 内存设置

Linux把它的物理RAM分成多个内存块，称之为分页。内存调换（swapping）是这样一个过程，它把内存分页复制到事前设定的叫做调换区的硬盘空间上，以此释放内存分页。物理内存和调换区加起来的大小就是虚拟内存的可用额度。

内存调换有个缺陷，跟内存比起来硬盘特别慢。内存的读写速度以纳秒来计算，而硬盘是以毫秒来计算，所以拜访硬盘比拜访内存要慢几万倍。调换次数越多，过程就越慢，所以应该不吝一切价值防止内存调换的产生。

ES的mlockall属性许可ES节点不调换内存。（留意只有Linux/Unix系统可设置。）这个属性能够在yaml文件中设置：

　　bootstrap.mlockall: true

在5.x版本中，已经改成了bootstrap.memory_lock: true.

mlockall默许设置成false，即ES节点许可内存调换。一旦把这个值加到属性文件中，需求重启ES节点才可失效。可通过以下方法来确定该值是不是设置准确：

　　curl http://localhost:9200/_nodes/process?pretty

假如你正在设置这个属性，请应用-DXmx选项或ES_HEAP_SIZE属性来确保ES节点分配了足够的内存。

小贴士4：discovery.zen属性控制ElasticSearch的发现协议

Elasticsearch默许应用服务发现(Zen discovery)作为集群节点间发现和通信的机制。Azure、EC2和GCE也有应用其他的发现机制。服务发现由discovery.zen.*开首的一系列属性控制。

在0.x和1.x版本中同时赞同单播和多播，且默许是多播。所以要在这些版本的ES中应用单播，需求设置属性discovery.zen.ping.multicast.enabled为false。

从2.0开始往后服务发现就仅赞同单播了。

首先需求应用属性discovery.zen.ping.unicast.hosts指定一组通信主机。便利起见，在集群中的一切主机上为该属性设置相同的值，应用集群节点的名称来界说主机列表。

属性discovery.zen.minimum_master_nodes决定了有资格作为master的节点的最小数目，即一个应该“看见”集群范围内运作的节点。假如集群中有2个以上节点，建议设置该值为大于1。一种计算办法是，假设集群中的节点数目为N，那么该属性应该设置为N/2+1。

Data和master节点以两种不一样方法相互探测：

通过master节点ping集群中的其他节点以验证他们处于运转状态通过集群中的其他节点ping master节点以验证他们处于运转状态或许是不是需求初始化一个选举过程

节点探测过程通过discover.zen.fd.ping_timeout属性控制，默许值是30s，决定了节点将会期待呼应多久后超时。当运转一个较慢的或许拥堵的网络时，应该调整这个属性；假如在一个慢速网络中，将该属性调大；其值越大，探测失败的概率就越小。

Loggly的discovery.zen有关属性配置以下：

　　discovery.zen.fd.ping_timeout: 30sdiscovery.zen.minimum_master_nodes: 2discovery.zen.ping.unicast.hosts: [“esmaster01″,”esmaster02″,”esmaster03″]

以上属性配置表示节点探测将在30秒内产生，缘由是设置了discovery.zen.fd.ping_timeout属性。另外，其他节点应该探测到最少两个master节点（我们有3个master）。我们的单播主机是esmaster01、 esmaster02、esmaster03。

小贴士5：小心DELETE _all

必须要了解的一点是，ES的DELETE API许可用户仅仅通过一个要求来删除索引，赞同应用通配符，甚至能够应用_all作为索引名来代表一切索引。例如:

　　curl -XDELETE ‘http://localhost:9200/*/’

这个特征特别有用，但也特别危险，特别是在生产环境中。在我们的一切集群中，已通过设置action.destructive_requires_name:true来禁用了它。

这项配置在1.0版本中开始援用，并代替了0.90版本中应用的配置属性disable_delete_all_indices。

小贴士6：应用Doc Values

2.0及以上版本默许开启Doc Values特征，但在更早的ES版本中必须显式地设置。当进行大规模的排序和聚合操作时，Doc Values对比普通属性有着显著的优势。实质上是将ES转换成一个列式存储，从而使ES的许多分析类特征在性能上远超预期。

为了一探讨竟，我们能够在ES里比较一下Doc Values和普通属性。

当应用一个普通属性去排序或聚应时，该属性会被加载到属性数据缓存中。一个属性初次被缓存时，ES必须分配足够大的堆空间，以便能保留每个值，然后应用每个文档的值慢慢填充。这个过程也许会消耗一些时间，缘由是也许需求从磁盘读取他们的值。一旦这个过程完成，这些数据的任何有关操作都将应用这份缓存数据，而且会很快。

假如试探填充太多的属性到缓存，一些属性将被回收，随后再次应用到这些属性时将会强迫它们重新被加载到缓存，且相同有启动开支。为了更加高效，人们会想到最小化或淘汰，这意味着我们的属性数目将受限于此种方法下的缓存大小。

对比之下，Doc Values属性应用基于硬盘的数据构造，且能被内存映照到过程空间，所以不影响堆应用，同时提供实质上与属性数据缓存一样的性能。当这些属性初次从硬盘读取数据时依然会有较小的启动开支，但这会由操作系统缓存去处置，所以只有真正需求的数据会被实际读取。

Doc Values所以最小化了堆的应用（缘由是垃圾搜集），并施展了操作系统文件缓存的优势，从而可进一步最小化磁盘读操作的压力。

小贴士7：Elasticsearch配额类属性设置指南

分片分配就是分配分片到节点的过程，也许会产生在初始化恢复、副天职配、或许集群再均衡的阶段，甚至产生在处置节点参加或退出的阶段。

cluster.routing.allocation.cluster_concurrent_rebalance决定了许可并发再均衡的分片数目。这个属性需求依据硬件应用情形去恰当地配置，好比CPU个数、IO负载等。假如该属性设置欠妥，将会影响ES的索引性能。

cluster.routing.allocation.cluster_concurrent_rebalance:2

默许值是2，表示随便时刻只许可同时移动2个分片。最好将该属性设置得较小，以便压抑分片再均衡，使其不影响索引。

另外一个分片分配有关属性是cluster.routing.allocation.disk.threshold_enabled。假如该属性设备为true（默许值），在分配分片到一个节点时将会把可用的磁盘空间算入配额内。封闭该属性会致使ES也许分配分片到一个磁盘可用空间缺乏的节点，从而影响分片的增长。

当打开时，分片分配会将两个阀值属性参加配额：低水位和高水位。

低水位界说ES将不再分配新分片到该节点的磁盘应用百分比。（默许是85%）高水位界说分配将开始从该节点迁移走分片的磁盘应用百分比。（默许是90%）

这两个属性都能够被界说为磁盘应用的百分比（好比“80%”表示80%的磁盘空间已应用，或许说还有20%未应用），或许最小可用空间大小（好比“20GB”表示该节点还有20GB的可用空间）。

假若有许多的小分片，那么默许值就特别守旧了。举个例子，假若有一个1TB的硬盘，分片是典范的10GB大小，那么理论上能够在该节点上分配100个分片。在默许设置的情形下，只能分配80个分片到该节点上，以后ES就以为这个节点已经满了。

为获得合适的配置参数，应该看看分片到底在变多大以后会结束他们的生命周期，然后从这里反推，确认包括一个安全系数。在上头的例子中，只有5个分片写入，所以需求一直确保有50GB的可用空间。关于一个1TB的硬盘，这个情形会变为95%的低水位线，而且没有安全系数。额外的，好比一个50%的安全系数，意味着应该确保有75GB的能够空间，或许一个92.5%的低水位线。

小贴士8：Recovery属性许可迅速重启

ES有许多恢复有关的属性，能够提高集群恢复和重启的速度。最好属性设置依附于如今应用的硬件（硬盘和网络是最罕见的瓶颈），我们能给出的最好建议是测试、测试、还是测试。

想控制多少个分片能够在单个节点上同时恢复，应用：

　　cluster.routing.allocation.node_concurrent_recoveries

恢复分片是一个IO特别密集的操作，所以应该谨严调整该值。在5.x版本中，该属性分为了两个：

　　cluster.routing.allocation.node_concurrent_incoming_recoveriescluster.routing.allocation.node_concurrent_outgoing_recoveries

想控制单个节点上的并发初始化主分片数目，应用：

　　cluster.routing.allocation.node_initial_primaries_recoveries

想控制恢复一个分片时打开的并行流数目，应用：

　　indices.recovery.concurrent_streams

与流数目亲密有关的，是用于恢复的总可用网络带宽：

　　indices.recovery.max_bytes_per_sec

除过一切这些属性，最好配置将依附于所应用的硬件。假若有SSD硬盘和万兆光纤网络，那么最好配置将彻底不一样于应用普通磁盘和千兆网卡。

以上一切属性都将在集群重启后失效。

小贴士9：线程池属性防止数据丧失

Elasticsearch节点有许多的线程池，用于提高一个节点中的线程管理效率。

在Loggly，索引时应用了批量操作形式，而且我们发现通过threadpool.bulk.queue_size属性为批量操作的线程池设置准确的大小，关于防止因批量重试而也许引发的数据丧失是极端关键的。

　　threadpool.bulk.queue_size: 5000

这会告知ES,当没有可用线程来实施一个批量要求时，可列队在该节点实施的分片要求的数目。该值应该依据批量要求的负载来设置。假如批量要求数目大于队列大小，就会获得一个下文展现的RemoteTransportException异常。

正如上文所述，一个分片包括一个批量操作队列，所以这个数字需求大于想发送的并发批量要求的数目与这些要求的分片数的乘积。例如，一个单一的批量要求也许包括10个分片的数据，所以即便只发送一个批量要求，队列大小也必须起码为10。这个值设置太高，将会吃掉许多JVM堆空间（而且表示正在推送更多集群没办法轻松索引的数据），但确实能转移一些列队情形到ES，简化了客户端。

既要坚持属性值高于可接纳的负载，又要腻滑地处置客户端代码的RemoteTransportException异常。假如不处置该异常，将会丧失数据。我们模仿应用一个大小为10的队列来发送大于10个的批处置要求，获得了以下所示异常。

　　RemoteTransportException[[<Bantam>][inet[/192.168.76.1:9300]][bulk/shard]]; nested: EsRejectedExecutionException[rejected execution (queue capacity 10) on org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$1@13fe9be];

为2.0版本之前的用户再赠予一个小贴士：最小化Mapping刷新时间

假如你仍在应用2.0版本之前的ES，且常常会更新属性mapping，那么也许会发现集群的任务期待队列有一个较大的refresh_mappings要求数。对它本身来说，这其实不坏，但也许会有滚雪球效应严重影响集群性能。

假如确实碰到这类情形，ES提供了一个可配置参数来帮助应对。可按下述方法应用该参数：

　　indices.cluster.send_refresh_mapping: false

那么，这是怎样个意思，为何能够见效？

当索引中出现一个新的属性时，添加该属性的数据节点会更新它自己的mapping，然后把新的mapping发送给主节点。假如这个新的mapping还在主节点的期待任务队列中，同时主节点公布了自己的下一个集群状态，那么数据节点将接收到一个过时的旧版本mapping。

通常这会让它发送一个更新mapping的要求到主节点，缘由是直到跟该数据节点有关，主节点一直都拥有错误的mapping信息。这是一个蹩脚的默许举动——该节点应该有所行动来保障主节点上拥有准确的mapping信息，而重发新的mapping信息是一个不错的选择。

然而，当有许多的mapping更新产生，而且主节点没办法连续坚持时，会有一个乱序集合(stampeding horde)效应，数据节点发给主节点的刷新消息便也许众多。

参数indices.cluster.send_refresh_mapping能够禁用掉默许举动，所以清除这些从数据节点发送到主节点的refresh_mapping要求，能够让主节点坚持最新。即时没有刷新要求，主节点也最后会看到起初的mapping变更，并会公布一个包括该变更的集群状态更新。

总结：Elasticsearch的可配置属性是其弹性的关键

对Loggly来说Elasticsearch可深度配置的属性是一个庞大的优势，缘由是在我们的应用案例中已经最大限制施展了Elasticsearch的参数威力(有时愈甚)。假如在你自己应用进化的如今阶段ES默许配置工作得足够好了，请放心，跟随应用的发展你还会有很大的优化空间。

　　今天荐文

　　点击下方图片便可浏览

　　

　　2016互联网技术人薪资报告，这一年搬的砖都去哪儿了？

郑重声明：此文内容为本网站转载企业宣传资讯，目的在于传播更多信息，与本站立场无关。仅供读者参考，并请自行核实相关内容。