FEK日志采集展示平台

整体架构
image
filebeat介绍
“Filebeat是一个日志文件托运工具，在你的服务器上安装客户端后，filebeat会监控日志目录或者指定的日志文件，追踪读取这些文件（追踪文件的变化，不停的读），并且转发这些信息到elasticsearch或者logstarsh中存放。
以下是filebeat的工作流程：当你开启filebeat程序的时候，它会启动一个或多个探测器（prospectors）去检测你指定的日志目录或文件，对于探测器找出的每一个日志文件，filebeat启动收割进程（harvester），每一个收割进程读取一个日志文件的新内容，并发送这些新的日志数据到处理程序（spooler），处理程序会集合这些事件，最后filebeat会发送集合的数据到你指定的地点。
(个人理解，filebeat是一个轻量级的logstash，当你需要收集信息的机器配置或资源并不是特别多时，使用filebeat来收集日志。日常使用中，filebeat十分稳定，笔者没遇到过宕机。)”
部署过程：
1.elasticsearch集群准备
a.download es5
b.配置es5配置文件
c.启动es5集群
2.filebeat
3.kibana
结果：
filebeat

继续阅读 →

Nginx 上配置 HTTP2

为什么需要http2背景

 

前言

从 2015 年 5 月 14 日 HTTP/2 协议正式版的发布到现在已经快有一年了，越来越多的网站部署了 HTTP2，HTTP2 的广泛应用带来了更好的浏览体验，只要是 Modern 浏览器都支持，所以部署 HTTP2 并不会带来太多困扰。

虽然 h2 有 h2c （HTTP/2 Cleartext） 可以通过非加密通道传输，但是支持的浏览器初期还是比较少的，所以目前部署 h2 还是需要走加密的，不过由于 Let’s Encrypt 大力推行免费证书和证书的廉价化，部署 h2 的成本并不高。

介绍

HTTP 2.0即超文本传输协议 2.0，是下一代HTTP协议。是由互联网工程任务组（IETF）的Hypertext Transfer Protocol Bis (httpbis)工作小组进行开发。是自1999年http1.1发布后的首个更新。

HTTP/2 协议是从 SPDY 演变而来，SPDY 已经完成了使命并很快就会退出历史舞台（例如 Chrome 将在「2016 年初结束对 SPDY 的支持」；Nginx、Apache 也已经全面支持 HTTP/2 ，并也不再支持 SPDY）。

一般的大家把 HTTP2 简称为 h2，尽管有些朋友可能不怎么愿意，但是这个简称已经默认化了，特别是体现在浏览器对 HTTP2 都是这个简写的。

 

配置

普通的 HTTPS 网站浏览会比 HTTP 网站稍微慢一些，因为需要处理加密任务，而配置了 h2 的 HTTPS，在低延时的情况下速度会比 HTTP 更快更稳定！

现在电信劫持事件频发，网站部署了 HTTPS 加密后可以杜绝大部分劫持，但不是完全。像电子商务行业对 HTTPS 加密可是标配啊，因此部署 h2 更是势在必行。 继续阅读 →

敏捷开发和迭代开发

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

简单的流量控制系统

流量控制概述

在一个后台系统中，流量控制属于基础组件的功能，其实，在很久之前的通讯时代，流量控制就已经非常成熟了，在路由器交换机上面几乎都有全面的流量控制的解决方案，像QoS这类流量整形的方案，都已经是在网络模型的各个层来进行流量的控制和分发了，可以按照通道，按照端口，IP，MAC，业务类型等各个维度对流量进行整形和控制，比如让语音类的这种高优先级的流量优先通过，而视频聊天这种丢了几帧数据其实没什么影响的低优先级流量慢点通过。对于流量控制，在中后台系统中，一般分成两个类型吧，一种是对连接数进行控制，保证一个机器有可控的连接数，一种是对真实流量的控制，保证机器能通过的流量有多少。流量控制和缓存一样，实际上是对后端的服务起到一个保护的作用，不至于把后端的服务击穿，不同的地方在于缓存保护的主要是读操作，如果用缓存来保护写操作的话，也是一个异步的过程，像下面这个图一样。 继续阅读 →

httpDNS原理

什么是 DNS

DNS（Domain Name System，域名系统），DNS 服务用于在网络请求时，将域名转为 IP 地址。能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 数串。

传统的基于 UDP 协议的公共 DNS 服务极易发生 DNS 劫持，从而造成安全问题。 继续阅读 →

勒索病毒席卷全球！中英同时“沦陷”！大家小心！

由.  于利用“勒索软件”攻击发生在缺乏完善监控的网络空间，对于案件的侦破有一定的难度，因此美国政府建议，针对勒索软件最好的防卫措施便是预防，并建议用户应采用“垃圾邮件过滤”、“防火墙”、杀毒软件、备份数据等方法来进行预防。如果计算机不幸被感染，应该尽快将切断任何网络及关机。

 

如果不幸中毒，五种暂时应对的方法：

1、不要给钱。赎金很贵并且交了之后未必能恢复。

2、未中毒的电脑迅速多次备份数据。已中毒的，重装系统前把硬盘低格，然后安操作系统。

3、安装反勒索防护工具，但仅在病毒侵入前有作用，但对已经中病毒的电脑无能为力，还是要做好重要文档备份工作。不要访问可以网站、不打开可疑邮件和文件

4、关闭电脑包括TCP和UDP协议135和445端口

5、还看不懂的，把网掐了。

如果你是电脑小白，不幸中毒，最好的应对方法估计就是拔掉网线了…

windows多款操作系统受0day攻击工具泄露，包括3389rdp远程等

　北京时间 2017 年 4 月 14 日晚，“Shadow Brokers” 终于忍不住了，在推特上放出了他们当时保留的部分对windows进行远程攻击的文件，解压密码是 “Reeeeeeeeeeeeeee”。‘

　　我们总结了一下：对网维影响最大的是 会导致 开放了 3389 RDP 远程服务，以及开放了445端口等文件共享服务器，被远程入侵攻击。
sklinux总结的暂时解决办法：

　　１，web服务器还在使用iis6的，进行升级最新版本的IIS，或者换其它WEB服务器.

　　２，关闭共享服务(services.msc中的 server 服务停止)，

　　３，关闭３３８９端口，如果一定要使用ＲＤＰ远程，强烈建议更改3389为其它端口，但此举并不能彻底解决此问题。建议更换radmin或者用深蓝三层远程。（深蓝三层远程的3389,radmin等远程穿透不需要外网端口开放，相对安全性更高。）

　　４，关闭和限制 137、139、445,3389  端口的使用，或者用防火墙限制这些端口只能指定的IP或者MAC使用。

　　５，等待微软最新的补丁，并第一时间打上。

　　目前已知受影响的 Windows 版本包括但不限于：Windows NT，Windows 2000（没错，古董也支持）、Windows XP、Windows 2003、Windows Vista、Windows 7、Windows 8，Windows 2008、Windows 2008 R2、Windows Server 2012 SP0。

这次的文件有三个目录，分别为“Windows”、“Swift” 和 “OddJob”，包含一堆令人震撼的黑客工具（几个重要的列举如下）：

  • EXPLODINGCAN 是 IIS 6.0 远程漏洞利用工具
  • ETERNALROMANCE 是 SMB1 的重量级利用，可以攻击开放了 445 端口的 Windows XP, 2003, Vista, 7, Windows 8, 2008, 2008 R2 并提升至系统权限。
  • 除此之外 ERRATICGOPHER 、ETERNALBLUE 、ETERNALSYNERGY 、ETERNALCHAMPION 、EDUCATEDSCHOLAR、 EMERALDTHREAD 等都是 SMB 漏洞利用程序，可以攻击开放了 445 端口的 Windows 机器。
  • ESTEEMAUDIT 是 RDP 服务的远程漏洞利用工具，可以攻击开放了3389 端口的 Windows 机器。
  • FUZZBUNCH 是一个类似 MetaSploit 的漏洞利用平台。
  • ODDJOB 是无法被杀毒软件检测的 Rootkit 利用工具。
  • ESKIMOROLL 是 Kerberos 的漏洞利用攻击，可以攻击 Windows 2000/2003/2008/2008 R2 的域控制器。

    　　不放不要紧，放出来吓坏了一众小伙伴。这些文件包含多个 Windows 神洞的利用工具，只要 Windows 服务器开了135、445、3389 其中的端口之一，有很大概率可以直接被攻击，这相比于当年的 MS08-067 漏洞有过之而无不及啊，如此神洞已经好久没有再江湖上出现过了。

服务器维护应该注意的四点

1、一般客户购买服务器时，服务器托管商会帮客户免费装好操作系统，之后会将服务器权限给到客户手中，而许多客户拿到密码权限之后也不去修改一下，试一下能登录认为就OK了，其实这样的做法非常危险，提醒广大客户在重装系统之后一定要尽快修改服务器密码，最好是定期的更换密码，如果您的服务器放置的数据非常重要，就更加重视密码保护意识，不要太相信网络了。

2、设置服务器防火墙的时，有些客户对防火墙设置并不熟悉，随意进行开启设置远程端口，结果导致服务器无法登录，然后就埋怨机房服务器问题或者是运营商工作人员服务技术不到位，一般情况下，客户服务器租用时服务商都会根据业务对服务器防火墙进行设置，之后客户就不要自己在去随意更改设置了，确实需要修改的时建议在本地电脑上测试好之后再到服务器上操作，避免出现设置错误影响服务器正常使用。

3、部分客户经常会在服务器里面下载东西或者浏览网页甚至是聊天玩游戏等，虽然能够快速响应要求，但服务器并不是台式机，它也不是用来仅仅做以上这些的，而且这样做很有可能把安全隐患带进服务器，导致服务器被入侵，数据被盗等情况，建议不要在服务器上运行可能会带来安全问题的应用程序。

4、服务器数据备份是管理员维护中非常重要的工作之一，事实上许多企业客户和个人客户都没有重视起来，无所谓的随意交给其他人员去做，而这些人员又不知道数据备份的重要性很容易忽视忘记了这个工作任务，也有一些客户把数据备份的工作直接让服务商去做，大部分服务商是不愿意为客户数据进行备份的，因为服务商也难免会遇到备份数据遗漏或者丢失的情况，况且数据存储也是一个比较大的问题。所以建议客户自己要进行不定期的备份数据，重要数据在自己手中掌握不是更放心吗；如今网络攻击不断，难保服务器会遭受入侵攻击的情况，此时有了备份就多了一份保障，所以没有经常备份数据意识的朋友们一定要注重起来，看完本文之后快去备份一下服务器数据！

Google SRE 参会总结

Google SRE 参会总结

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

什么是SRE，职责是什么？

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

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