分类存档: IT圈热闻

僵尸网络 Mirai 新变种来袭,企业成新目标

臭名昭著的 IoT/Linux 僵尸网络 Mirai 出现新变种,杀伤力更强。

安全团队 Unit 42 近日发布报告披露了 Mirai 的新变种病毒,研究者在样本中发现了该病毒的 27 种漏洞利用方式,其中 11 种是 Mirai 中没遇到过的。

Mirai 是去年肆虐的僵尸网络病毒,其通过感染存在漏洞的 IoT 设备,并下载 Telnet 扫描其它潜在 Mirai 僵尸宿主机,将其感染,连结成网,在需要时对目标系统发起攻击。Mirai 先后进行 DDoS 导致了美国的、德国大断网,并针对全球最大动态 DNS 提供商 DYN 与网络托管服务提供商 OVH 等进行攻击,带来了极其恶劣的影响。

同时 Mirai 作者将其源码公布,这使得更多人可以更加方便地对该病毒进行变种创作,此次发现的新变种正是其中之一。

Unit 42 安全人员指出,此次新变种针对不同嵌入式设备,如路由器、网络存储设备与网络摄像机等,利用这些设备存在的漏洞进行大面积攻击。报告中特别指出,该变种僵尸网络会针对 WePresent WiPG-1000 无线演示系统和 LG Supersign 电视,这两款设备都是企业级产品,并且它们存在的漏洞早在去年就公开了。

报告认为这表明该变种有将 Mirai 攻击从公共基础设施转向企业目标的趋势。

研究人员表示目前该变种僵尸网络还在通过不断感染更多设备,并添加更多用于对设备进行暴力破解的密码扩大其攻击面,而利用企业应用漏洞使得攻击具有更大的网络带宽,DDoS 能力大大提高。

此外,该变种还有其它特性,比如它使用与 Mirai 特征相同的加密方案,表密钥为 0xbeafdead;它使用域 epicrustserver[.]cf 在端口 3933 进行 C2 通信;除了扫描其它易受感染的设备,它还可以进行 HTTP Flood DDoS 攻击。

报告中还提到了一个具有讽刺意味的案例,该变种病毒的 shell 脚本攻击负载植入在一个用于“电子安全、集成和报警监控”业务的网站上。

那么,如此疯狂的僵尸网络冲着企业而来,企业可以怎么办呢?

  • 了解网络上的 IoT 设备、更换默认密码,确保设备更新补丁
  • 无法修补的设备直接从网络中去掉

详情查看报告:https://unit42.paloaltonetworks.com/new-mirai-variant-targets-enterprise-wireless-presentation-display-systems

Chrome 将警告用户不再支持 Flash Player

Adobe 计划在 2020 年淘汰 Flash Player,这将是万维网历史上的一个关键点。全世界都在为这个关键时刻做准备,其中就包括浏览器开发公司。谷歌正在尽可能顺利地完成 Flash Player 的过渡,即将推出的 Chrome 76 也将在这方面迈出这关键的一步

新版本浏览器将完全禁用 Flash Player,但谷歌希望启用此功能的用户亲自在设置中完成所有操作。浏览器明显的变化是启动时显示的警告,不过谷歌可能在未来的几周对这个显示做进一步的调整。

据 9to5google 报告,最近 Chromium 的开发人员在讨论中提供了显示警告的早期视图,该警告将在浏览器顶部作为信息栏显示。“2020年12月之后 Flash Player 将不再受支持”,通知中写道,并在末尾附上了链接,方便用户了解通知详情。

目前,Canary 版 Google Chrome 尚未加入此警告。据 Chromium 的代码提交,警告的显示已在进行中,晚些将与功能标志一起添加到新版浏览器。

Chrome 即将加入的这个警告显示,可以让用户提前得知 Flash Player 支持的即将结束,使得浏览器取消支持 Flash Player 的整个转换过程更加顺畅。

Gradle 5.0 正式版发布!史上最快、最安全和最强大的版本

Gradle 5.0 正式版发布了!官方表示这是史上最快、最安全,最强大的版本。

改进的增量编译和增量注释处理构建在已经具有构建缓存和最新检查功能的可靠性能基础之上。

依赖约束 —— 依赖对齐和版本锁定提供了可扩展且灵活的依赖管理模型。

通过新的性能和依赖关系管理、日志记录和弃用的 API 使用检查,构建扫描得到了显著的改进。

静态类型的 Kotlin DSL 可在创建构建逻辑时提供代码完成、重构和其他的 IDE 辅助。

主要改进可分为以下几类:

最后,可以了解如何进一步升级到 Gradle 5.0

值得关注的新特性:

apollo配置中心增加环境的方法

Apollo(阿波罗)是携程框架部门研发的开源配置管理中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性。

Apollo支持4个维度管理Key-Value格式的配置:

  1. application (应用)
  2. environment (环境)
  3. cluster (集群)
  4. namespace (命名空间)

 

配置结构图为:

apollo配置架构
一、portal启动参数如下: 继续阅读 »

为什么前后端分离了,你比从前更痛苦?—转载

你有没有遇到过:

  • 前端代码刚写完,后端的接口又变了。
  • 接口文档永远都是不对的。
  • 测试工作永远只能临近上线才能开始。

为什么前后端分离了,你比从前更痛苦?

  前后端分离早已经不是新闻,当真正分离之后确遇到了更多问题。要想解决现在的痛,就要知道痛的原因:

为什么接口会频繁变动?

  设计之初没有想好。 这需要提高需求的理解能力和接口设计能力。

  变动的成本较低。

  德国有句谚语:“朝汤里吐口水。” 只有这样,才能让人们放弃那碗汤,停止不合理的行为。前后端同学坐在一起工作的时候效率会有提升,当后端同学接口变化时,只需要口头上通知一下即可,我们没有文档,我们很敏捷啊。没错,我们需要承认这样配合开发的效率会很高,但是频繁的变动会导致不断返工,造成了另一种浪费,这种浪费是可以被减少,甚至是被消除的。

为什么接口文档永远都是不对的?

  接口文档在定接口时起到一定作用,写完接口就没有用了。后面接口的频繁变化,文档必定会永远落后于实际接口,维护文档的带来了一定的成本却没能带来价值。除非对外提供的接口,否则文档谁来看呢?没人看,用处又在哪?

  有些公司干脆丢掉接口文档,说我们要拥抱敏捷。

  所以接口文档落后的原因在于没有给我们带来价值

为什么测试工作永远只能临近上线才能开始?

继续阅读 »

虚拟货币管好它可以成为利器

这些年炒来炒去引起金融混乱的虚拟货币除了捣蛋金融市场还有没有用?日本金融厅首度认定虚拟货币的融资功能,虚拟货币进入金融体系,被当做类似于有价证券同等属性。此外,金融厅放权给自治组织,不仅上币审核,连牌照发放都能直接影响。日本通过自主制约与法律的结合,保证虚拟货币市场的健康发展,非常值得借鉴。

日本走在前列

在十一假期期间,日本金融厅召开了第六次《虚拟货币交易业者研讨会》。会议结果如下:

第一,金融厅首次认定虚拟货币的融资功能;

第二,承认虚拟货币拥有证券属性;

第三,金融厅通过法律和自治协会管理虚拟货币交易。

这次研讨会,在虚拟货币发展史上写下了重要一笔。尤其是在融资功能上,已经确定相关法律规定,ICO将在日本进一步合法化。 继续阅读 »

关于https证书的类型

关于https证书

https协议需要到ca申请证书,一般免费证书很少,需要交费。
http是超文本传输协议,信息是明文传输,https 则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。
目前大部分网站都在忘https上转,Chrome也将https作为浏览器的默认连接,如果网站没采用https的话,就会出现!的标识。

苹果宣布了一个最后期限:到2017年1月1日 App Store中的所有应用都必须启用 App Transport Security安全功能。App Transport Security(ATS)是苹果在iOS 9中引入的一项隐私保护功能,屏蔽明文HTTP资源加载,连接必须经过更安全的HTTPS。苹果目前允许开发者暂时关闭ATS,可以继续使用HTTP连接,但到年底所有官方商店的应用都必须强制性使用ATS。

所以,推行https是整个互联网行业的趋势。

证书

目前主流的SSL证书主要分为DV SSL 、 OV SSL 、EV SSL。

DV SSL

DV SSL证书是只验证网站域名所有权的简易型(Class 1级)SSL证书,可10分钟快速颁发,能起到加密传输的作用,但无法向用户证明网站的真实身份。

目前市面上的免费证书都是这个类型的,只是提供了对数据的加密,但是对提供证书的个人和机构的身份不做验证。

OV SSL

OV SSL,提供加密功能,对申请者做严格的身份审核验证,提供可信身份证明。

和DV SSL的区别在于,OV SSL 提供了对个人或者机构的审核,能确认对方的身份,安全性更高。

所以这部分的证书申请是收费的~

EV SSL

超安=EV=最安全、最严格 超安EV SSL证书遵循全球统一的严格身份验证标准,是目前业界安全级别最高的顶级 (Class 4级)SSL证书。

金融证券、银行、第三方支付、网上商城等,重点强调网站安全、企业可信形象的网站,涉及交易支付、客户隐私信息和账号密码的传输。

这部分的验证要求最高,申请费用也是最贵的。

 

敏捷开发和迭代开发

在这敏捷开发横行的时代中,人人都在谈敏捷,人人都在谈迭代,似乎大家好像都尝到了敏捷带来的甜头,记得有一次跟朋友吃饭,说他们现在的项目用敏捷开发,每个迭代都能看到不断完善的产品,非常有成就感,客户的满意度也提升了不少;另一个朋友说,我们用迭代开发,也是这样,而且客户想加什么需求就加什么,直接按照优先级排到迭代周期就行,也不用为改需求而烦躁。当时我就想,敏捷开发不就是分迭代周期的吗,他俩好像说的是一回事吧。回去过了好长一段时间,突然想起这件事了,在网上一查,还真不是一回事… 继续阅读 »

Google SRE 参会总结

Google SRE 参会总结

近期有幸参加了一个小型的运维会议,同《SRE:Google 运维解密》的译者进行面对面的沟通,收益匪浅。会议上大家的讨论非常热烈,话题主要集中在以下几个方面:

什么是SRE,职责是什么?

SRE全称Site Reliability Engineering,是Google内部的一个运维职位,主要职责是保障服务的可靠性和性能,同时负责数据中心资源分配,为重要服务预留资源,该职位不负责某个具体业务的上线和部署。

SRE分为产品SRE和平台SRE。产品SRE负责某个具体产品相关的所有组件的运维,而平台SRE则负责诸如主机计算能力,数据库资源等PaaS资源。按照我个人的简单理解,前者是以业务为单位的纵深管理,后者是以平台为基础的横向管理。不论何种SRE,在我看来,这个职位都对个人能力有较高的要求,非传说中的全栈工程师莫属。
继续阅读 »

Google SRE:运维还能如此高逼格?

SRE是Site Reliability Engineer的简称,从名字可以看出Google的SRE不只是做Operation方面的工作,更多是保障整个Google服务的稳定性。SWE是SoftWare Egineer的简称,即软件工程师(负责软件服务的开发、测试、发布)。SWE更新的程序代码(下文称为server),只有在SRE同意后才能上线发布。因此,SRE在Google工程师团队中地位非常高!

Google SRE:运维还能如此高逼格?

SRE是Site Reliability Engineer的简称,从名字可以看出Google的SRE不只是做Operation方面的工作,更多是保障整个Google服务的稳定性。SWE是SoftWare Egineer的简称,即软件工程师(负责软件服务的开发、测试、发布)。SWE更新的程序代码(下文称为server),只有在SRE同意后才能上线发布。因此,SRE在Google工程师团队中地位非常高!

作者:王璞来源:高效运维|2015-07-27 17:21

 

嘉宾介绍

王璞,数人科技创始人。2002年获得北京航空航天大学力学学士学位,2007年获得北京大学计算机硕士学位,2011年获得美国George Mason University计算机博士学位,研究方向机器学习,发表十余篇机器学习以及数据挖掘相关论文。毕业后在硅谷先后供职StumbleUpon、Groupon和Google三家公司,负责海量数据处理、分布式计算以及大规模机器学习相关工作。2014年回国创办数人科技,基于Mesos和Docker构建分布式计算平台,为企业客户提供高性能分布式PaaS解决方案。

引言

SRE是Site Reliability Engineer的简称,从名字可以看出Google的SRE不只是做Operation方面的工作,更多是保障整个Google服务的稳定性。SRE不接触底层硬件如服务器,这也是高逼格的由来:

Google 数据中心的硬件层面的维护工作是交给technician来做的,technician一般不需要有大学学历。

SWE是SoftWare Egineer的简称,即软件工程师(负责软件服务的开发、测试、发布)。

SWE更新的程序代码(下文称为server),只有在SRE同意后才能上线发布。因此,SRE在Google工程师团队中地位非常高!我们下面将分别介绍。

备注:我本人是SWE,本文是从SWE的角度看SRE,我的老朋友@孙宇聪同学是原Google SRE,他会从另一个角度来阐述此主题,敬请期待哦!

1. SRE 职责

SRE在Google不负责某个服务的上线、部署,SRE主要是保障服务的可靠性和性能,同时负责数据中心资源分配,为重要服务预留资源。

如上文所受,和SRE想对应的是SWE(软件开发工程师),负责具体的开发工作。

举个例子,我之前在Google的互联网广告部门,我们team负责的server是收集用户数据用于广告精准投放,这个server的开发、测试、上线部署等工作,都是由SWE来完成。

SRE不负责server的具体实现,SRE主要负责在server出现宕机等紧急事故时,做出快速响应,尽快恢复server,减少服务掉线带来的损失。

备注:这里的server是指服务器端程序,而不是物理服务器。在Google,SWE和SRE都无权接触物理服务器。

2. SRE 要求

因为SRE的职责是保障服务的稳定和性能,所以在SRE接手某个server之前,对server的性能和稳定性都有一定的要求,比如server出现报警的次数不能超过一定的频率,server对CPU、内存的消耗不能超过预设的指标。

只有server完全满足SRE的要求以后,SRE才会接手这个server:

当server出现问题时,SRE会先紧急修复,恢复服务,然后SRE会和SWE沟通,最终SWE来彻底修复server的bug。

同时,对server的重大更新,SWE都要提前通知SRE,做好各种准备工作,才能发布新版server:

为了能让SRE能接手server,SWE要根据SRE的要求,对server做大量的调优。首先SRE会给出各种性能指标,比如,服务响应延迟、资源使用量等等,再者SRE会要求SWE给出一些server评测结果,诸如压力测试结果、端到端测试结果等等,同时,SRE也会帮助SWE做一些性能问题排查。

所以SRE在Google地位很高,SWE为了让server成功上线,都想法跟SRE保持好关系。

我举个具体的例子来说明,在Google,SWE是如何跟SRE配合工作来上线server的。

我们team对所负责的server进行了代码重构,重构之后,要经过SRE同意,才能够上线重构后的server。

为此,我们team的SWE要向SRE证明,重构后的server对资源的开销没有增加,即CPU、内存、硬盘、带宽消耗没有增加,重构后的server性能没有降低,即端到端服务响应延迟、QPS、对压力测试的响应等这些性能指标没有降低:

当时对server代码重构之后,server有个性能指标一直达不到SRE的要求。这个指标是contention,也就是多线程情况下,对竞争资源的等待延迟。重构server之后,contention这项指标变得很高,说明多线程情况下,对竞争资源的等待变长。

我们排查很久找不到具体原因,因为SWE没有在代码中显式使用很多mutex,然后请SRE出面帮忙。

SRE使用Google内部的图形化profiling工具,cpprof,帮我们查找原因。

找到两个方面的原因:

  • tc_malloc在多线程情况下频繁请求内存,造成contention变高;
  • 大量使用hash_map,hash_map没有预先分配足够内存空间,造成对底层tc_malloc调用过多。

3. SRE 工作内容

简而言之,Google的SRE不是做底层硬件维护,而是负责Google各种服务的性能和稳定性。换句话说,Google的SRE保证软件层面的性能和稳定性,包括软件基础构架和应用服务。

SRE需要对Google内部各种软件基础构架(Infrastructure)非常了解,而且SRE一般具有很强的排查问题、debug、快速恢复server的能力。

我列举一些常见的Google软件基础构架的例子:

  • Borg:分布式任务管理系统;
  • Borgmon:强大的监控报警系统;
  • BigTable:分布式Key/Value存储系统;
  • Google File System:分布式文件系统;
  • PubSub:分布式消息队列系统;
  • MapReduce:分布式大数据批处理系统;
  • F1:分布式数据库;
  • ECatcher:日志收集检索系统;
  • Stubby:Google的RPC实现;
  • Proto Buffer:数据序列化存储协议以及RPC协议;
  • Chubby:提供类似Zookeeper的服务。

Google还有更多的软件基础构架系统:Megastore、Spanner、Mustang等等,我没有用过,所以不熟悉。

4. 运维未来发展方向

我个人觉得,在云计算时代,运维工程师会慢慢向Google的SRE这种角色发展,远离底层硬件,更多靠近软件基础架构层面,帮助企业客户打造强大的软件基础构架。

企业客户有了强大的软件基础构架以后,能够更好应对业务的复杂多变的需求,帮助企业客户快速发展业务。

另外我个人观点,为什么Google的产品给人感觉技术含量高?

并不见得是Google的SWE比其他Microsoft、LinkedIn、Facebook的工程师能力强多少,主要是因为Google的软件基础构架(详见上文)非常强大,有了很强大的基础构架,再做出强大的产品就很方便了。

Google内部各种软件基础构架,基本上满足了各种常见分布式功能需求,极大地方便了SWE做业务开发。

换句话说,在Google做开发,SWE基本上是专注业务逻辑,应用服务系统(server)的性能主要由底层软件基础构架来保证。

————我是分割线————

下面就是本次分享的互动环节整理(真的非常精彩哦:)。

问题1:SRE参与软件基础项目的开发吗?

SRE一般不做开发。比如Google的BigTable有专门的开发团队,也有专门的SRE团队保障BigTable server的性能和稳定性。

问题2:一般运维工具,或者监控,告警工具,哪个团队开发?

SRE用的大型管理工具应该是专门的团队开发,比如Borgmon是Google的监控报警工具,很复杂,应该是专门的团队开发,SRE会大量使用Borgmon。

问题3:基础软件架构有可以参考的开源产品吗?

Google内部常见的软件基础构架都有开源对应的版本,比如Zookeeper对应Chubby,HDFS对应Google File System,HBase对应BigTable,Hadoop对应MapReduce,等等。

问题4:还有SRE会约束一些项目的性能指标,比如CPU和内存的使用阈值,这些值是从哪里得来的?或者说根据哪些规则来定制的?

SRE负责Google的数据中心资源分配,所以一些重要server的资源是SRE预留分配好的。对CPU、内存等资源的分配,SRE按照历史经验以及server的业务增长预期来制定。

此外Google数据中心里运行的任务有优先级,高优先级的任务会抢占低优先级任务的资源,重要的server一般优先级很高,离线任务优先级比较低,个人开发测试任务优先级最低。