服务器|云|数据中心

服务器|云主机|vps|站群

分类目录新闻快讯

你对Facebook新的加密货币Libra和数字钱包Calibra知多少?

acebook周二透露了计划开发一种名为Libra的加密货币。它将由其他公司投资者和非营利成员组成的一个协会运营,预计2020年上半年推出。

以下是一些细节:

加密货币

Libra是实际资产(包括银行存款和短期政府证券)储备支持的一种数字货币,由托管人网络持有。

这种结构旨在促进信任并稳定价格。

据该项目的信息显示,虽然Libra的价格可能并不总是与底层资产相一致,持有人应该享有“高度保证”:他们可以根据汇率将加密货币转换成传统货币。

Libra将在Facebook未明确的交易所网络上进行交易。

技术

Libra交易将由区块链驱动和记录,区块链是由计算机网络维护的共享交易账本。

Libra区块链将被许可,这意味着只有治理协会授权的实体才能运行计算机。它的治理不同于比特币,后者没有负责实体。

软件将是“开源的”,这意味着协会外面的公司可以在其上面开发应用。

协会计划在Libra推出后五年内改用无许可的区块链。

协会

Libra协会是一个28名成员组成的独立非营利组织,总部设在瑞士日内瓦。它将监管有关该数字货币的重大决定。

成员包括:万事达卡、维萨、Spotify、PayPal、eBay、优步和沃达丰,还有知名风投公司安德森•霍洛维茨基金会和Thrive Capital。

除了金融包容性组织Kiva等非营利成员外,起码要投资1000万美元才能加入。该协会旨在推出时有100个成员。

每个成员对重要问题都有一张选票。Facebook将通过Calibra成为成员,Calibra是一家刚成立的子公司,为Libra提供数字钱包。

钱包

个人和商户能够使用Calibra来存储、发送和接收Libras。

它将作为智能手机上的独立应用程序来提供,或者作为Facebook的Messenger和WhatsApp这两个产品中的按钮。

Facebook最终希望将Calibra用于其一系列应用中的交易,比如Instagram上用于购物的数字结账。

公司高管设想用户通过该应用购买Libra,无论是通过关联银行账户,还是对于没有银行账户的人​​,在现金转账公司或便利店等实体店来购买。

Calibra的工程师参与了区块链的建设,不过Facebook表示打算将加密货币和钱包交由不同的实体保管。

Calibra拥有约100名员工,大多数在Facebook位于加利福尼亚州门洛帕克的总部以及以色列特拉维夫。Calibra的高管Kevin Weil告诉路透社,他预计员工队伍不会大幅扩张。

隐私和安全

每个使用Calibra的人都要走一遍“了解你的客户”流程,该流程验证用户身份以防止金融犯罪。

这意味着任何注册的人都要共享政府ID及其他个人信息。

Facebook表示,Calibra将为丢失手机或密码的客户提供支持;如果客户的Libra被骗子窃取,会退款给客户。

据声明显示,Calibra只有在获得客户同意的情况下或者在其他“有限的情况下”(比如执法部门要求提供信息),才会与母公司Facebook和第三方共享用户数据。

Facebook承诺不会使用Calibra数据来改善广告投放。

Weil告诉路透社,企业会看到用Libra付款的客户方面的信息,就像它们会看到用信用卡付款的客户的信息那样。

导致企业端点安全问题的五个原因

1. 不了解端点安全

当然,这是许多端点安全问题的根源。企业决策者常常将现代的下一代端点安全与早期的计算机保护程序混为一谈。这种关联一度是正确的,但现在不再是这样。

那么,端点安全是什么?简而言之,端点安全可以保护连接到企业网络的所有设备。

端点安全

当然,端点安全确实包含反恶意软件和防火墙,这是早期计算机保护的原始功能。然而那些功能尽管很重要,但都只是端点安全功能的表层。

毕竟,连接到贵公司网络的每个设备(每个端点)是进入IT基础设施的潜在入口。数据流量进出端点,甚至可能最终存储在端点上。此外,应用程序一直与这些端点进行交互,若不加以监测,这可能会造成安全漏洞。

因此,你的端点安全还必须包括:

  • 端口控制
  • 应用程序控制
  • 终点检测和响应(EDR)。
  • 数据丢失预防
  • 沙箱
  • 安全电子邮件网关
  • 云边界安全

因此,你需要了解下一代端点保护平台的好处。此外,你应该熟悉贵企业的使用场合,以了解需要优先关注哪些功能。

2. 忽视端点保护演进方面的趋势

知名技术研究公司Gartner在魔力象限报告中特别提到了端点保护平台的成熟度。然而,成熟度并不等同于静态。终端安全在不断发展,以便最有效地抵御和阻挡黑客的战术。然而,企业常常忽视这些变化,从长远来看导致端点安全的问题得不到消除。

端点保护平台的最新趋势包括机器学习的好处;这些AI算法帮助安全团队紧跟日益自动化的数字威胁。

此外,现代数字边界必须包括防范无文件恶意软件的机制。这种新型恶意软件的行为与其他较传统的攻击全然不同;无文件恶意软件钻原生进程的空子,而不是恶意软件将文件下载到你的端点上。

这么一来,无文件恶意软件在进行恶意攻击时隐藏起来,不被典型的检测系统发现。只有下一代解决方案才能抵御这种威胁。

最后,现代EPP必须针对物联网。企业将物联网设备整合到网络中,而不先问问它们是否含有任何安全机制。它们常常不会这么做;即使这么做,这种安全也很少容易修补。

作为改善贵公司端点安全问题的一方面,你要及时了解功能和威胁方面的最新趋势。拥有多个威胁情报源有所帮助。

3. 端点安全过于复杂化

这是个常见的谬误:网络安全系统越多,贵企业就越安全。

其实,情况往往恰好相反;实际上,端点保护平台越精简且集成,你的数字资产就越安全。

据Absolute声称,端点上每增加一个安全工具,只会加大失败的可能性。但平均而言,企业每个设备使用10个安全代理,这可能包括加密、反恶意软件和补丁管理代理。

安全代理越多,集成问题和安全漏洞就越多。此外,每个代理都需要给予关注和监控,这常常导致代理易被疏忽。

部署集中式端点安全解决方案可以解决此问题。毕竟,下一代解决方案应包括一个套件中的所有代理,同时包括集中式管理。这可以帮助IT安全团队有效监控你的能力。

4. 缺乏问责制

你的端点安全问题不是靠购买EPP解决方案就能神奇解决的。因此,你需要落实某种系统以确保贵公司受益于网络安全并获得最佳保护。因此,贵企业应落实一套系统来确保问责制。理想情况下,该计划应回答以下问题:

  • 谁负责选择EPP?
  • 将如何部署解决方案?这要花多久?
  • 你将采用哪些策略来教育用户,让他们面对、而不是规避解决方案?
  • 你将如何密切关注其成功?如何定义成功?
  • 你将在哪里获得威胁情报,将如何整合威胁情报?

5. 注重反恶意软件而不是其他功能

最后,继续依赖反恶意软件是最常见的企业端点安全问题之一。企业决策者常常认为,单单反恶意软件可以解决其网络安全问题;毕竟,过去几年是这么解决这类问题的。

然而,正如我们上面讨论的,反恶意软件只处理贵公司面临的一些问题。你需要其他功能才能对付外部威胁分子。然而,恶意软件仍然是一种威胁,但恶意数据流量和漏洞百出的边界同样是威胁。

最有可能的是,贵企业面临独特的端点安全问题。处理这类问题应成为IT安全团队和整个公司的首要任务。

中国域名根服务器新增7台 域名管理不再受制于人

近日,工信部批复中国互联网络信息中心、北京市工程研究中心有限公司设立7台域名根服务器,其中中国互联网络信息中心维护的中国域名根服务器为JX0001F、JX0002F、JX0003I、JX0004K、JX0005L、JX0006L,北京市工程研究中心有限公司维护的中国域名根服务器为JX0007L。

根域名服务器介绍

根域名服务器”的作用是解析DNS,而所谓的“DNS”,好比邮政编码。投递员(根域名服务器)通过邮政编码(DNS),能快速分拣信件,投递到各地分局。在正常情况下,根域名服务器解析DNS是准确无误的。

根服务器主要用来管理互联网的主目录,全世界IPv4根服务器只有13台(这13台IPv4根域名服务器名字分别为“A”至“M”),1个为主根服务器在美国。其余12个均为辅根服务器,其中9个在美国,欧洲2个,位于英国和瑞典,亚洲1个位于日本。

根域名服务器是架构因特网所必须的基础设施。在国外,许多计算机科学家将根域名服务器称作“真理”(TRUTH),足见其重要性。换句话说——攻击整个因特网最有力、最直接,也是最致命的方法恐怕就是攻击根域名服务器了。

中国根域名服务器危机

曾有报告显示,我国境内权威服务器平均安全指标较低,大部分域名权威服务器安全状态较差。有业内专家则认为,我国对域名系统安全的认识不够,完善域名系统安全联动机制,特别是快速响应和处理机制迫在眉睫。专家表示“特别是根域名服务器全在美国以及日本和欧洲,如果根域名出现问题,将影响我们所有域名解析和网站访问,因此,需要建立一套完善的对DNS监控及灾备系统,同时尽快在国内建立根域名目录服务器。”

多位专家建议,加大对国家域名系统基础设施建设的投入。同时,尽快完善域名系统安全联动机制,特别是快速响应和处理机制,通过协调联动在网络带宽、运行保障、应急协调等方面确保充足的资源支撑,加大对域名技术研究和各环节故障处理能力,确保网络安全。

中国根域名服务器发展

在与现有IPv4根服务器体系架构充分兼容基础上,中国主导“雪人计划”于2016年在全球16个国家完成25台IPv6根服务器架设,事实上形成了13台原有根加25台IPv6根的新格局,为建立多边、民主、透明的国际互联网治理体系打下坚实基础。中国部署了其中的4台,由1台主根服务器和3台辅根服务器组成,打破了中国过去没有根服务器的困境。

2019年6月24日连续批复中国互联网络信息中心、北京市工程研究中心有限公司设立7台域名根服务器,为应对域名根服务器受制于人做出有力部署,优化域名解析协议,推进国家级域名服务器P2P解析。

以下是两份批文原文

工业和信息化部关于同意中国互联网络信息中心设立域名根服务器(F、I、K、L根镜像服务器)及域名根服务器运行机构的批复

中国互联网络信息中心:

你中心关于设立域名根服务器(F、I、K、L根镜像服务器)及域名根服务器运行机构的申请收悉。根据《互联网域名管理办法》(工业和信息化部令第43号)有关规定,经审查,现批复如下:

一、同意你中心设立域名根服务器(F、I、K、L根镜像服务器)及成为域名根服务器运行机构,负责运行、维护和管理编号分别为JX0001F、JX0002F、JX0003I、JX0004K、JX0005L、JX0006L的域名根服务器。

二、你中心应严格遵守《互联网域名管理办法》《通信网络安全防护管理办法》及相关法律法规、行政规章及行业管理规定,接受我部的管理和监督检查,建立符合我部要求的信息管理系统并与我部指定的管理系统对接,保证域名根服务器安全、可靠运行,为用户提供安全、方便的域名服务,保障服务质量,保护用户个人信息安全,维护国家利益和用户权益。

三、你中心应当制定并不断完善域名根服务器及域名根服务器运行机构的管理制度;指定专门人员负责域名根服务器的运行、维护和管理工作,建立固定的联系机制;选择具备资质的网络接入服务提供者为域名根服务器提供接入服务;域名根服务器机房地址、互联网协议(IP)地址和自治域(AS)号码等信息发生变更时,应当在变更之日前15日以书面形式报送我部。

四、你中心应配置必要的网络资源以及网络和通信应急设备,制定切实有效的网络通信保障和网络与信息安全应急预案,设立、配备专职网络与信息安全管理机构和人员,建立健全网络与信息安全制度与保障措施,建立相应的业务与安全管理系统,建设监测预警、应急处置、数据备份等必要的技术手段,定期报送信息,服从我部的统一指挥与协调,配合开展相关测试和演练,遵守相应的管理要求。

五、你中心应当在每季度结束后的5个工作日内将域名根服务器上一季度的业务开展情况、安全运行情况等信息报送我部(传真:010-66037097;电子邮件:domain@miit.gov.cn)。

六、你中心在运行、维护和管理域名根服务器过程中遇到问题,需及时以书面形式报送我部。

七、此批复自发布之日起生效,有效期为5年。

此复。

工业和信息化部

2019年6月24日

工业和信息化部关于同意互联网域名系统北京市工程研究中心有限公司设立域名根服务器(L根镜像服务器)及域名根服务器运行机构的批复

互联网域名系统北京市工程研究中心有限公司:你公司关于设立域名根服务器(L根镜像服务器)及域名根服务器运行机构的申请收悉。根据《互联网域名管理办法》(工业和信息化部令第43号)有关规定,经审查,现批复如下:

一、同意你公司设立域名根服务器(L根镜像服务器)及成为域名根服务器运行机构,负责运行、维护和管理编号分别为JX0007L的域名根服务器。

二、你公司应严格遵守《互联网域名管理办法》《通信网络安全防护管理办法》及相关法律法规、行政规章及行业管理规定,接受我部的管理和监督检查,建立符合我部要求的信息管理系统并与我部指定的管理系统对接,保证域名根服务器安全、可靠运行,为用户提供安全、方便的域名服务,保障服务质量,保护用户个人信息安全,维护国家利益和用户权益。

三、你公司应当制定并不断完善域名根服务器及域名根服务器运行机构的管理制度;指定专门人员负责域名根服务器的运行、维护和管理工作,建立固定的联系机制;选择具备资质的网络接入服务提供者为域名根服务器提供接入服务;域名根服务器机房地址、互联网协议(IP)地址和自治域(AS)号码等信息发生变更时,应当在变更之日前15日以书面形式报送我部。

四、你公司应配置必要的网络资源以及网络和通信应急设备,制定切实有效的网络通信保障和网络与信息安全应急预案,设立、配备专职网络与信息安全管理机构和人员,建立健全网络与信息安全制度与保障措施,建立相应的业务与安全管理系统,建设监测预警、应急处置、数据备份等必要的技术手段,定期报送信息,服从我部的统一指挥与协调,配合开展相关测试和演练,遵守相应的管理要求。

五、你公司应当在每季度结束后的5个工作日内将域名根服务器上一季度的业务开展情况、安全运行情况等信息报送我部(传真:010-66037097;电子邮件:domain@miit.gov.cn)。

六、你公司在运行、维护和管理域名根服务器过程中遇到问题,需及时以书面形式报送我部。

七、此批复自发布之日起生效,有效期为5年。

此复。

工业和信息化部

2019年6月24日

【漏洞预警】Linux 内核TCP SACK机制远程拒绝服务漏洞

【漏洞预警】Linux 内核TCP SACK机制远程拒绝服务漏洞

2019年6月18日,国外某安全研究组织披露Linux 内核TCP SACK机制存在缺陷,可导致远程拒绝服务。CVE编号为CVE-2019-11477、CVE-2019-11478和CVE-2019-11479。

 

漏洞描述
Linux 内核2.6.29及之后版本在处理TCP SACK机制时存在缺陷,导致整数溢出漏洞,攻击者可以构造特定的SACK包,远程触发Linux服务器内核模块溢出漏洞,实现远程拒绝服务攻击。 这个不会导致机器被黑,只是会弄到服务器突然间不能使用,因为CPU/内存资源被堵满

 

漏洞评级
CVE-2019-11477 高危
CVE-2019-11478 中危
CVE-2019-11479 中危

 

 

安全修复建议
注:以下任意一种修复方式都有可能造成业务不可用

 

一、禁用SACK机制功能,执行如下命令(目前暂时这个是最好的方式):
echo 0 > /proc/sys/net/ipv4/tcp_sack
sysctl -w net.ipv4.tcp_sack=0

 

 

二、升级Linux安全补丁(需要重启服务器, 请注意,目前CENTOS 和UBUNTU 还没跟新KERNEL,所以一下方案还不能使用,需要等CENTOS/UBUNTU 有了新KERNEL 才能升级)
Ubuntu 系列:apt-get update && sudo apt-get install linux-image-generic
Centos 系列:yum update kernel

宕机的阿里云们正在杀死运维行业吗?

云计算正在杀死运维吗?

近年来,“去运维”的相关讨论甚嚣尘上,但似乎没有引起程序员的过多关注或者大范围讨论。近日,程序员论坛 V2EX 上出现一个热议话题“阿里云正在缓慢而稳步地杀死运维行业”,这似乎表明运维人员最终还是感受到了来自云计算发展带来的巨大压力。发帖者认为,“当容器服务集群、跨地域监控与容灾 / 保活、DBA、代码托管与 CI/CD 都能全部依托阿里云产品时,运维已经被踢出 IT 行业”。

一石激起千层浪,有人认为这只是杞人忧天,并反问“阿里云自己都刚宕机,还想说不需要运维吗?”,有人则认为英雄所见略同,还有人进一步将未来的运维阐述成“云维”。

技术的发展不能缺少埋头苦干的人,但也少不了抬头看路的人。针对这个问题,我们想跟大家聊聊,究竟云计算的发展,是否会造成运维岗位的消亡?

2没有运维的 Netflix 和运维转研发的阿里巴巴Netflix 的运维模式

Netflix 从一开始就强调开发人员进行自助化运维,他们的理念是:谁构建,谁运维。其运维工作全部由开发人员完成,只保留极少的 Core SRE 角色专门响应和处理严重等级的故障。

类似的还有亚马逊,无论是电商业务还是 AWS 公有云业务,都由开发负责。

在 Netflix 看来,建立起独立运维团队的主要助益,在于当一切进展顺利时,开发人员不致因运维任务的介入而分神。然而,当工作进展遭遇阻碍时,成本就会快速叠加起来。开发人员与 SRE 之间的沟通与知识转移往往存在严重损耗,且需要额外的往来以实现问题调试或解答合作伙伴的疑问。

由于运维团队对需要部署的变更本身缺少直接了解,因此问题部署通过会带来更长的检测与解决周期。当时在代码完成到部署之间的时间断档要远远长于当前,发布时长往往需要数周而非数天。这方面反馈主要来源运维人员,他们大多亲身经历过诸如警报 / 监控缺失或者性能问题以及延迟增加等挑战,而这些问题最终又会被转移至开发人员手中。

为此,Netflix 从 DevOps 运动的基本原则中汲取灵感,提出了“谁构建,谁运维”这一理念,旨在鼓励系统开发团队同时负责系统的运维与支持工作,从而真正将 DevOps 引入实践。

阿里巴巴的运维模式

阿里技术团队在 2016 年左右开始了一次大的组织架构调整,即把日常的运维工作交给研发做。原来的 PE(Production Engineer)要么转岗去做工具平台开发,要么作为运维专家做产品规划和设计,还有一部分无法适应的只能黯然离开。

这是阿里运维从工具化到自动化最重要的一个过程。集团性公司支撑的 BU 一般非常多,导致运维团队基本都是在干脏活、杂活。从组织层面上做出这样的调整后,运维团队的大多数人更多的时间是投入在研发工作上,而不是投入在日常的杂事上。这是 DevOps 真正意义上被彻底执行。

随着公司规模的逐渐扩大,从人肉运维到工具化运维再到自动化运维乃至 AI 时代的智能化运维,对于运维能力的要求是越来越高,对于运维人手的要求却越来越小。无怪乎有人发出这种论断:云计算(AI)正在杀死运维!

3所以,运维如何逃过这场“追杀”?

随着自动化的逐步完善,单个 PE 能够支持的业务变得越来越多,很多事情似乎都可以通过自助完成,很多公司可能在潜移默化中就降低了对应用运维岗位的需求,逐渐以一种类似阿里的发展方式运行,似乎用不了多久,运维岗位就会被普遍“杀死”,运维人员应该如何做好转型和过渡呢?

运维人员如何做好转型?

根据科技发展的历史,每次技术革新都会丢掉一部分旧工作,并带来更多更有价值的新职位,某位圈内云计算专家在接受 InfoQ 采访时表示:

云厂商确实在运维层面做了很多工作,但这部分工作并不是运维最看重的。换句话说,这些工作都不能体现运维人员的核心竞争力。过去,运维相当于黄包车车夫,累死累活半天可能也就绕着二环跑了两圈;现在,云平台可以免押金租给他们一辆汽车,轻松一天往返五次机场,你觉得哪种司机挣得多呢?

在云时代,运维人员并不是没有价值,而是会变得更加重要。云计算承诺高弹性、高可用、高性能、智能化,但公有云的 SLA 真不是目前的 AIOps 和运维自动化工具可以独立承担的。

专家认为,运维团队的实力也是云计算服务商的核心竞争力,云计算要求更高的运维能力,能够保障大规模基础设施和业务稳定运行。对于企业用户而言,底层基础设施的运维工作确实可以甩给第三方公有云服务商统一负责,但上层应用的运维工作还需要企业自己来承担,比如环境配置,不过更多的是 DevOps。

因此,运维人员必须学会适当的角色转变。今后,运维领域的发展倾向于具备开发能力,尤其是产品能力,足以设计好的运维工具和平台的技术人才,这种观点也基本得到运维领域技术专家的认可。

采访中,某一线互联网公司运维负责人表示:

未来,运维岗位不会被淡化,相反会发展的越来越好。现在,之所以会有很多人担忧运维的未来,是因为如今大多数公司的运维其实就是打杂的,这主要归因于基础设施不够完善,需要运维手工补齐短板,所以运维需要承担很多脏活、累活。当基础设施短板补齐,运维可以在上面做更多业务侧的工作。从大公司和公有云角度来看,他们确实不需要这么多运维,但是市场体量将会变大,运维人员的需求也会随之增加。

当企业逐渐云化,运维岗位可能会适当精简,但是不会被完全取代,企业仍然需要人员负责资源管理、应用部署升级、监控和故障处理。按照 DevOps 理论来说,可能所有这些都可以由开发人员完成。当然,最理想的情况可能就是运维团队开发工具和平台,开发人员自己运维。

无论如何,应用运维可能都需要适当转型,极客时间《赵成的运维体系管理课》的专栏作者赵成曾在文章中提及:

无论是做运维转型还是做其他技术转型,具备代码开发能力都已经成为一项必备技能。

他建议:

如果对开发工作缺乏自信,可以先从 Python、PHP 和 Go 这些上手比较简单的语言开始,这不是指写脚本,而是一定要能够实现完整的业务功能或流程;

其次,需要提升产品意识,这并不是要求所有运维同事都成为优秀的产品经理,或者具备很强的产品设计能力,而是一定 要有产品意识,这一点小转变就可能带来很大不同;

最后,提升技术运营意识,简单来说就是可以根据需求把承载标准化和规范体系的工具平台真正落地应用。在这个过程中,通过问题收集和一定数据分析,再回到产品设计和需求流程中进行改进,从而形成良性闭环。

留给运维人员的时间还有多少?

好在,目前这项进程的转变步伐不算很快。一位与传统大型企业打了十多年交道的技术专家认为:

虽然云计算以及人工智能吸引了很多企业尝鲜,但目前并没有看到这些新服务真正落地并为传统企业带来很大价值,大部分应用还停留在表层,这项技术所能带来的潜力还没有被最大化挖掘。就实际应用而言,目前市场上的公有云服务成本依旧普遍偏高,易用性也不足以达到单凭传统企业的技术能力就可以短时间内学会的程度。

因此,虽然云计算和人工智能是未来的重要发展趋势,但短期内还存在很多问题需要解决,企业需要具备专业的技术团队来更好得将云服务落地,并保证服务的可用性和可靠性。目前,很多企业尚处于混合云阶段,数据的流转、计算等环节都需要技术和运维人员的存在。短期内,运维人员仍然在公司中具有重要地位。

另一方面,我们必须承认云计算和人工智能所带来的挑战。如今,企业已经从单纯选用 IaaS 服务向 PaaS 和 SaaS 层过渡,这些产品基本都在公有云平台内部经历了长时间的磨练和运行,这让不少新兴企业只需要专注业务逻辑,而无需自研纯技术产品。这种情况下,企业非但不需要应用运维这些基础岗位,就连门槛较高的分布式中间件研发岗位可能也会大量缩减。

面对这些改变,运维人员唯一的办法就是不断学习和提升自己的技能,保持自身的与时俱进,及时做出相应调整和改变,这才是应万变的根本之道。

2025年,全球超大规模IDC市场将超过650亿美元

最近,全球市场观察(Globla Market Insights)发布了蓬勃兴起的超大规模数据中心市场的新数据。

图片4

根据这项研究,2018年,该市场的价值略高于200亿美元,到2025年将升至650亿美元。

这是由分布式计算环境中对大数据云计算解决方案的持续需求驱动的。对于组织需要存储、管理和检索的海量数据来说,数据流量的快速增长是一个主要挑战。因此他们越来越多地采用云计算的解决方案,优势包括灵活性、减少费用、可伸缩性、协作效率和访问大量数据的自动更新和存储等。

Global Market Insights称,在超大规模数据中心市场运营的主要企业包括(按字母顺序排列)亚马逊、博通、思科、戴尔、Facebook、谷歌、华为、IBM、英特尔、联想、微软、英伟达、Sandisk LLC和施耐德电气等。

1550028423

在谷歌最近的活动中可以看到一个超规模投资的例子,包括它计划扩大其新加坡数据中心的产能,此外还拨款6亿美元扩大其南卡罗来纳州的设施。

基于机架的配电单元(PDU)由于其高可用性和高功率等级的特点,在超大规模数据中心市场上的需求正在迅速增长。这些PDU可以与所有类型的机架设备相结合,而不会中断电源。

预计亚太地区对云服务的采用增加,以及智能手机和社交媒体用户的快速增长,将推动该市场的规模。到2025年,智能手机用户数量预计将超过60亿,其中印度、中国、韩国、中国台湾和印度尼西亚将成为主要贡献者。

Global Market Insights表示,该地区的企业越来越多地采用数据密集型应用,如物联网、数据分析和人工智能服务,这些应用需要大量数据和巨额资本投资,而一些公司正在建设超大规模的设施,以减少资本和运营成本。

在超大规模的数据中心市场中,IT和电信行业占据了行业份额的45%以上,由于数据生成和存储需求的增加,大型基础设施的使用率很高。

西欧和北欧市场对超大规模数据中心的需求很大,原因是可再生能源、土地开发、税收优惠、加强光纤连接和降低电力成本等。

传华为要美国运营商Verizon付专利费 金额超10亿美元

据路透社援引知情人士在周三透露的消息报道称,华为日前已要求美国运营商Verizon为230多个专利支付许可费,总计超过10亿美元。

据美国《华尔街日报》先前报道,一名华为的知识产权许可执行管理人员在2月份的时候写道,Verizon应支付“用来解决专利许可问题”的费用。这些专利涵盖Verizon的20多家供应商的网络设备,其中包括美国主要的科技公司。这位知情人士又表示,Verizon可向这些供应商寻求赔偿。他还称,华为已经直接与部分供应商公司有过接洽。

10345158789277683543

据《华尔街日报》报道,上述提及的专利范围涉及核心网络设备、有线基础设施以及物联网技术等等。该知情人士说,华为寻求的230多项专利使用许可费一共高达10亿多美元。

上周,华为与Verizon的代表在纽约会面,商议一些存在问题的专利,以及Verizon使用的某些来自其它公司的设备是否存在侵犯华为专利的可能性。

Verizon发言人里奇·扬(Rich Young)拒绝“就该具体问题”发表评论,理由是“这是一个潜在的法律问题”。

但是,扬又说:“这些问题不仅仅关乎Verizon。考虑到国际大背景,任何与华为有关的问题都会对我们这整个行业产生影响,同时引发国内外的关注。”

华为、美国无线运营商T-Mobile和AT&T均尚未回复路透社的评论请求。Sprint拒绝发表评论。

密码管理:你的密码安全吗?

互联网时代,密码与我们的生活息息相关。如何提高密码安全系数成为用户个人以及公司的关注重点。

虽然现在身份验证技术已经更加成熟,但是密码仍然是保护我们最敏感信息的主要途径。密码是防御潜在入侵者试图模仿另一个用户的第一道防线,但这样的防护往往比较弱。用户通常想创建易于记忆的密码,使用出生日期或纪念日,甚至写下来。开发人员则想尽可能少地投入密码管理策略中。毕竟,研发新功能比密码管理和存储更令人兴奋、更有趣。

许多密码本身安全性非常弱,很容易猜得到,攻击者就会有机可乘。最糟糕的是,我们信任的密码存储系统和其它关键信息的系统也面临着许多安全挑战。黑客会反复尝试密码数据库进行盗窃,攻击者同伙经常会破坏那些保护数据的模式。

我们探讨一下公司在密码管理策略方面做出的一些常见错误。让在下面的讨论中,我们将提到“在线攻击”和“离线攻击”。在线攻击是对应用程序登录页面的攻击,攻击者试图猜测用户的密码;离线攻击是攻击者获取密码数据库副本,并尝试计算存储在其中的用户密码的攻击。

密码管理:你的密码安全吗?
您已限制用户可以使用的字符数量或种类

推理

安全人员反复告诉开发人员验证所有输入以防止各种攻击(例如,注入攻击)。因此,根据某些规则来制定验证密码的规则必然是一个好主意,对吧?

攻击:

限制密码中字符数量或种类的问题是减少了可能的密码总数。这使得在线和离线攻击更容易。如果我知道只允许在密码中使用特殊字符!和@,那也就是我知道用户密码都没有包含#,$,%,<和>等字符。此外,如果我知道只允许长度为8到12个字符的密码,我也就知道所有用户都没有使用13个字符或更长的密码。如果我想猜测用户的密码,这些规则可以让我的工作变得更轻松。

但是SQL注入、跨站点脚本,命令注入和其它形式的注入攻击呢?如果遵循密码存储最佳做法,您将在收到密码后立即计算密码的哈希值。然后,您将只处理哈希密码,不必担心注入攻击。

防御:

允许用户选择包含任意字符的密码。指定最小密码长度为8个字符,但在可行的情况下允许任意长度的密码(例如,将它们限制为256个字符)。

您在使用密码组合规则

推理:

大多数用户选择容易猜到的密码。我们可以通过让用户选择包含几种不同类型字符的密码,以强制用户选择难以猜测的密码。

攻击:

安全专业人员曾经认为,让用户选择包含各种字符类型的密码会增强密码的安全性。不幸的是,研究表明这通常没有帮助。 “Password1!”和“P @ ssw0rd”可能遵循了许多密码组合规则,但这些密码并不比“password”更强。密码组合规则只会让用户难以记住密码;它们不会让攻击者的工作变得更加困难。

防御:

摆脱密码组成规则。在应用程序中添加密码复杂性检查功能,告诉用户他们的密码选择是否明显强度偏弱。但是,不要强制用户在其密码中添加数字、特殊字符等。稍后,我们将讨论如何使应用程序更安全,以防止安全性弱的用户密码。

密码管理:你的密码安全吗?
您没有安全地存储密码

推理:

加密哈希函数是单向函数。因此,存储哈希密码应该可以防止攻击者计算出它们。

攻击:

与前面讨论过的两个问题不同,这个问题通常只与离线攻击有关。许多企业和组织的密码数据库都被盗了。当掌握了被盗密码库和强大的计算能力,攻击者通常可以计算出许多用户的密码。

存储密码的常用方法是使用加密哈希函数,对密码进行哈希处理。如果最终用户选择完全随机的20+字符密码,这种方法将是完美的。例如密码设成:/K`x}x4%(_.C5S^7gMw)。不幸的是,人们很难记住这些密码。如果简单地对密码进行哈希处理,则使用彩虹表攻击就很容易猜到用户选择的典型密码。

阻止彩虹表攻击通常需要在对每个密码进行散列之前添加随机“盐”。“盐”可以与密码一起存储在清除中。不幸的是,加盐的哈希并没有多大帮助。 GPU非常擅长快速计算加盐哈希值。能够访问大量加盐哈希和GPU的攻击者将能够使用暴力破解和字典攻击等攻击合理且快速地猜测到密码。

有太多不安全的密码存储机制,值得专门写篇文章去探讨。不过,我们先来看看您应该如何存储密码。

防御:

有两种主要机制可以防止攻击者:一种是使哈希计算更加昂贵,另一种是向哈希添加一些不可估测的东西。

为了使哈希计算更加昂贵,请使用自适应哈希函数或单向密钥派生函数,而不是密码哈希函数来进行密码存储。加密哈希函数的一个特性是它们可以被计算出来;这个属性导致它们不适合用于密码存储。攻击者可以简单地猜测密码并快速散列以查看生成的哈希值是否与密码数据库中的任何内容匹配。

另一方面,自适应哈希函数和单向密钥导出函数具有可配置的参数,这些参数可用于使哈希计算更加资源密集。如果使用得当,它们可以有助于充分减缓离线攻击,以确保您有时间对正在受到攻击的密码数据库做出反应。

这种方法的问题在于,每次要对用户进行身份验证时,都必须自己计算这些哈希值。这会给服务器带来额外负担,并可能使应用程序更容易受到DoS(拒绝服务)攻击。

或者,您可以添加一些不可猜测的密码哈希值。例如,如果要生成一个长随机密钥,将其添加到密码哈希值以及唯一的随机盐,并且稳妥地保护密钥,那么被盗密码数据库对攻击者来说将毫无用处。攻击者需要窃取密码数据库以及能够使用离线攻击计算出用户密码的密钥。当然,这也产生了一个需要解决的非常重要的密钥管理问题。

您完全依赖密码

推理

密码必须是验证用户身份的好方法。其他人都在使用它们!

攻击:

即使用户执行上述所有操作,以使在线和离线攻击更加困难,也无法阻止其它应用程序/网站执行不恰当的操作。用户经常在许多站点上重复使用相同的密码。攻击者经常会在某平台尝试从其它平台盗取密码。

此外,用户成为网络钓鱼攻击的受害者,因为一些用户无论密码要求如何都会选择安全性弱的密码,等等。

防御:

要求用户使用多因素身份验证登录。请记住多因素身份验证的含义:使用至少两种不同因素进行身份验证(典型因素是您知道的事情、拥有的物品、以及生物识别等等)。使用两种不同的密码(例如,密码+安全问题的答案)不是多因素身份验证。同时使用密码和动态口令属于多因素验证的一种。此外,请记住,某些多因素身份验证机制比其它多因素身份验证机制更安全(例如,加密设备比基于SMS的一次性密码更安全)。无论如何,使用某种形式的多因素身份验证总是比仅依靠密码更安全。

如果必须仅使用密码进行身份验证,用户则还必须采取某种类型的设备身份验证。这可能涉及设备/浏览器指纹识别,检测用户是否从不寻常的IP地址登录,或类似的方式。

密码管理:你的密码安全吗?
结论

如您所见,处理用户密码时需要考虑很多事项。我们还没有谈到密码轮换策略、帐户锁定、帐户恢复、速率限制,防止反向暴力攻击等等。

有一个很重要的问题需要考虑:您是否可以将用户身份验证转给其他人?如果你是一家金融机构,答案可能是否定的;如果您要把最新的猫咪宠物视频给别人看,在此之前需要验证,那这种情况下答案应该是可以的;如果您正在开发面向企业员工内部使用的应用程序,请考虑基于SAML的身份验证或LDAP集成;如果您正在开发面向公众的应用程序,请考虑使用社交登录(即使用Google,Facebook等登录)。许多社交网站已经投入大量精力来保护其身份验证机制,并为用户提供各种身份验证选项。您不需要全盘重来。

在不必要的情况下实施用户身份验证会给企业和用户都带来麻烦,甚至有潜在危险。创建安全的用户验证机制困难且耗时。可您是真的想要处理被盗用的密码数据库,还是攻击者在身份验证机制中发现漏洞?而且用户有更重要的事情要做,而不是记住另一个密码!

RDP服务器的梦魇——GoldBrute僵尸网络

      最近的网络攻击活动中,可能要数BlueKeep漏洞的讨论热度最高了。但近日研究人员警告称,新发现的GoldBrute僵尸网络目前对Windows系统构成了不亚于BlueKeep带来的威胁。

僵尸网络

1. 概览

安全研究人员已经发现了一个持续复杂的僵尸网络活动,该活动目前在互联网上暴力攻击了超过150万台可公开访问的Windows RDP(远程桌面协议)服务器。GoldBrute僵尸网络由一个C2(命令和控制)服务器控制,与位于美国新泽西州的IP地址(104.156.249.231)相关联。

全球RDP服务器分布

全球RDP服务器分布

      这个被称为GoldBrute的僵尸网络能够通过不断添加新的破解系统,从而进一步寻找新的可用RDP服务器,然后破解它们。为了躲避安全工具和恶意软件分析师的检测,此恶意活动背后的威胁行为者命令其僵尸网络中每台受感染的设备使用唯一的用户名和密码组合,使得目标服务器接收来自不同IP地址的暴力破解尝试。

2. 攻击流程

由网络安全机构Morphus Labs的首席研究员Renato Marinho发现的该恶意活动,其具体流程如下图所示:

全球RDP服务器分布

第一步:在成功暴力破解RDP服务器后,攻击者会在此设备上安装一个基于Java的GoldBrute僵尸网络恶意软件。

第二步:为了控制受感染的设备,攻击者利用一个固定集中的C2(命令和控制)服务器,通过AES加密的WebSocket连接交换命令和数据。

第三、四步:随后,每台受感染的设备都会收到第一条任务指令,即扫描并报告至少80台可公开访问的新RDP服务器列表,这些服务器可以被暴力破解。

第五、六步:攻击者为每台受感染设备分配一组特定的用户名和密码,作为其第二条任务指令,它们需要针对上述列表中的RDP服务器进行破解尝试。

第七步:在成功破解后,受感染设备会自动向C2服务器上传登录凭据。

目前还不清楚到底有多少台RDP服务器已经遭到破坏,并参与了针对互联网上其他RDP服务器的暴力攻击。

彼时,研究员通过快速Shodan搜索显示,大约240万台Windows RDP服务器可以在互联网上公开访问,其中可能有一半以上的服务器正在遭遇暴力破解攻击。

如何保护网络远离微软NTLM协议中的安全漏洞?

微软的NTLM(NT LAN Manager)是一种较旧且现已过时的安全协议,用于对Windows域中的用户登录信息进行身份验证。虽然微软早已将NTLM换成Kerberos、作为Active Directory的默认验证方法,但该公司仍然支持这种旧协议,同时建议客户改而采用Kerberos。

如何保护网络远离微软NTLM协议中的安全漏洞?

众所周知,即使一种技术或协议陈旧、过时或不再被推荐,这并不意味着企业组织不再使用它。问题是,NTLM一直受到安全漏洞的困扰。在周二发布的一份报告中,安全提供商Preempt描述了最新的漏洞,并就如何保护网络远离这些漏洞给出了忠告。

Preempt在报告中表示,它最近基于NTLM中的三个逻辑漏洞发现了两个关键的微软漏洞。这些漏洞可能让攻击者可以在任何Windows计算机上远程执行恶意代码,或者通过身份验证,连接到支持Windows Integrated Authentication(WIA)的任何Web服务器,比如Exchange或ADFS。Preempt的研究表明,所有版本的Windows都容易受到这些漏洞的影响。

报告特别指出,NTLM的一大缺陷是它容易受到转发攻击(relay attack),这个过程让攻击者可以在一台服务器上获取身份验证,然后将其转发到另一台服务器,从而让他们可以使用那些同样的登录信息来控制远程服务器。

微软已开发了几个修复程序来防止NTLM转发攻击,但攻击者可以通过以下三个逻辑漏洞找到绕过它们的方法:

  • 消息完整性代码(MIC)字段试图防止攻击者篡改NTLM消息。然而Preempt的研究人员发现,攻击者可以删除MIC保护机制,并更改NTLM验证使用的某些字段。
  • SMB会话签名可防止攻击者转发NTLM身份验证消息,以此建立SMB会话和DCE/RPC会话。但Preempt发现攻击者可以将NTLM身份验证请求转发到域中的任何一台服务器(包括域控制器),并创建签名会话以便在远程计算机上执行代码。如果转发的身份验证含有特权用户的登录信息,整个域可能岌岌可危。
  • 增强的身份验证保护(EPA)可防止攻击者将NTLM消息转发到TLS会话。但是Preempt发现攻击者可以篡改NTLM消息,以生成合法的通道绑定信息。然后这类攻击者可以使用用户的登录信息,连接到域中的Web服务器,从而得以通过转发到Outlook Web Access服务器或通过转发到(ADFS)Active Directory Federation Services服务器以连接到云资源,读取用户的电子邮件。

周二微软将发布两个补丁,试图堵住NTLM中这些最新的安全漏洞。除了敦促企业组织给高危系统打上这些新的补丁外,Preempt还给出了其他建议。

补丁

确保给所有工作站和服务器打上了微软的最新补丁。寻找微软在6月11日星期二的CVE-2019-1040和CVE-2019-1019补丁。据Preempt声称,光打补丁本身并不够,它还建议在配置方面进行几处调整。

配置

  • 实施SMB签名机制。想防止攻击者发起较简单的NTLM转发攻击,请在所有联网计算机上启用SMB签名机制。
  • 阻止NTLMv1。由于NTLMv1被认为不安全,Preempt建议企业组织通过适当的组策略设置完全阻止它。
  • 实施LDAP/S签名机制。想防止LDAP中的NTLM转发,请对域控制器实施LDAP签名和LDAPS通道绑定机制。
  • 实施EPA。想防止Web服务器上的NTLM转发,请加固所有Web服务器(OWA和ADFS),只接受采用EPA的请求。

Preempt的首席技术官兼联合创始人Roman Blachman在一份新闻稿中说:“尽管NTLM 转发攻击是一种老套的手法,企业却无法彻底消除使用这种协议,因为这会破坏许多应用程序。因此它仍给企业带来了巨大的风险,尤其是在新漏洞不断被发现的情况下。公司需要先确保所有Windows系统都已打上补丁、安全配置。此外,企业组织可以通过了解网络NTLM的情况,进一步保护环境。”