线上站点更新了登录方式，从验证码变成了拼图，但是不知道为什么引发了一个漏洞，导致有人不停的刷登录页面，尝试破解什么的，还好这个人发出的请求频率较高，但是访问源都是一个ip，log如下：

219.146.239.138 - - [18/Mar/2015:10:44:12 +0800] 0 "POST /signin"

219.146.239.138 - - [18/Mar/2015:10:44:12 +0800] 0 "POST /signin"

219.146.239.138 - - [18/Mar/2015:10:44:12 +0800] 0 "POST /signin"

219.146.239.138 - - [18/Mar/2015:10:44:12 +0800] 0 "POST /signin"

219.146.239.138 - - [18/Mar/2015:10:44:12 +0800] 0 "POST /signin"

219.146.239.138 - - [18/Mar/2015:10:44:12 +0800] 0 "POST /signin"

219.146.239.138 - - [18/Mar/2015:10:44:12 +0800] 0 "POST /signin"

一秒钟你刷好几十次这还是一台服务器，判断为非正常，先用Iptables屏蔽掉！

iptables -I INPUT -s 219.146.239.138 -j DROP

看看效果，哎？怎么还访问的那么欢实，突然想起来，这些服务器是 haproxy 转过来的，日志格式里的ip地址是X-Forwarded-For，我总不能跑haproxy上去加iptables吧！

        SetEnvIf X-Forwarded-For "^(219\.146\.239\.138)" Deny1

        Options None

        AllowOverride None

        Order deny,allow

        Deny from all

        Allow from env=Deny1

好了，再看看全部403,这种方法防护小规模的刷洗还是可以的，但是大规模的需要做自动发现和自动添加防护！

以下操作过程是记录在Centos6.4下安装最新版的Redis过程。
 
1、安装epel repo Yum安装源

//32 位

rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm  



//64 位

rpm -Uvh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

2、安装remi Yum安装源

rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

3、制定Yum源安装Redis

yum --enablerepo=remi,remi-test install redis

4、配置

# vim /etc/sysctl.conf

  vm.overcommit_memory=1

# sysctl vm.overcommit_memory=1



# sysctl -w fs.file-max=100000

5、版本确认和添加开机自启

# redis-server --version

Redis server v=3.2.0 sha=00000000:0 malloc=jemalloc-3.6.0 bits=64 build=ae5ce1900d9386a6

# chkconfig --add redis

# chkconfig --level 345 redis on

一、下载devtoolset-3 Yum源

# wget https://copr.fedoraproject.org/coprs/rhscl/devtoolset-3/repo/epel-6/rhscl-devtoolset-3-epel-6.repo && mv ./*.repo /etc/yum.repos.d/

 
二、下载安装gcc gcc-c++

# yum --disablerepo='*' --enablerepo='rhscl-devtoolset-3' install devtoolset-3-gcc devtoolset-3-gcc-c++  -y

国外的源，如果下载失败或者Time-out，只好手动下载rpm包安装,超时如下：

下载rpm包：

https://copr-be.cloud.fedoraproject.org/results/rhscl/devtoolset-3/epel-6-x86_64/devtoolset-3-gcc-4.9.2-6.el6/devtoolset-3-gcc-4.9.2-6.el6.x86_64.rpm

https://copr-be.cloud.fedoraproject.org/results/rhscl/devtoolset-3/epel-6-x86_64/devtoolset-3-gcc-4.9.2-6.el6/devtoolset-3-gcc-c%2B%2B-4.9.2-6.el6.x86_64.rpm

https://copr-be.cloud.fedoraproject.org/results/rhscl/devtoolset-3/epel-6-x86_64/devtoolset-3-gcc-4.9.2-6.el6/devtoolset-3-libstdc%2B%2B-devel-4.9.2-6.el6.x86_64.rpm

利用可以翻墙之后的网络，下载安装包之后，想要安装这些包，还需要安装一些依赖包，如下：

# yum -y install scl-utils

# yum -y install devtoolset-3-runtime

# yum -y install devtoolset-3-binutils

这些依赖包安装完成后，可以安装三个下载的rpm包了：

# rpm -ivh devtoolset-3-libstdc++-devel-4.9.2-6.el6.x86_64.rpm

# rpm -ivh devtoolset-3-gcc-4.9.2-6.el6.x86_64.rpm

# rpm -ivh devtoolset-3-gcc-c++-4.9.2-6.el6.x86_64.rpm

三、安装JsonNet扩展
安装完成后，启用开发环境：

# scl enable devtoolset-3 bash

这样不会破会你之前系统依赖的GCC环境！
 
设置全局变量，启用新Gcc版本，编译软件

# export CC=/opt/rh/devtoolset-3/root/usr/bin/gcc

# export CPP=/opt/rh/devtoolset-3/root/usr/bin/cpp

# export CXX=/opt/rh/devtoolset-3/root/usr/bin/c++

然后下载源码编译安装JsonNet

# wget -O JsonNet.Latest.tar.gz https://pecl.php.net/get/jsonnet

# mkdir JsonNet-PHP && tar -xzvf JsonNet.Latest.tar.gz -C ./JsonNet-PHP

# cd JsonNet-PHP/JsonNet-1.0.0

# phpize

# ./configure

# make && make install

如果中间没有任何error和依赖包的话，我为你感到庆幸，如果你并不这么幸运的话，请挨个解决吧！
最后添加php扩展，检查：

[root@web1 src]# echo 'extension=jsonnet.so' > /etc/php.d/jsonnet.ini

[root@web1 src]# php -m |grep -i jsonnet

JsonNet

恭喜到这终于结束了！

由于gcc 4.8.2不支持C++11的regex库，故需升到4.9.2
首先加载源，导入rpm

centos6系列

# wget https://www.softwarecollections.org/repos/rhscl/devtoolset-3/epel-6-x86_64/noarch/rhscl-devtoolset-3-epel-6-x86_64-1-2.noarch.rpm

# rpm -ivh rhscl-devtoolset-3-epel-6-x86_64-1-2.noarch.rpm

# wget https://copr.fedoraproject.org/coprs/rhscl/devtoolset-3/repo/epel-6/rhscl-devtoolset-3-epel-6.repo && mv ./*.repo /etc/yum.repos.d/

centos7系统

# wget https://www.softwarecollections.org/repos/rhscl/devtoolset-3/epel-7-x86_64/noarch/rhscl-devtoolset-3-epel-7-x86_64-1-2.noarch.rpm

# rpm -ivh rhscl-devtoolset-3-epel-7-x86_64-1-2.noarch.rpm

开始安装

# yum --disablerepo='*' --enablerepo='rhscl-devtoolset-3' install devtoolset-3-gcc devtoolset-3-gcc-c++ devtoolset-3-toolchain -y

安装完成后，启用开发环境：

# scl enable devtoolset-3 bash

这样不会破会你之前系统依赖的GCC环境！
 
设置全局变量，启用新Gcc版本，编译软件

# export CC=/opt/rh/devtoolset-3/root/usr/bin/gcc

# export CPP=/opt/rh/devtoolset-3/root/usr/bin/cpp

# export CXX=/opt/rh/devtoolset-3/root/usr/bin/c++

广泛使用的图像处理软件ImageMagick今日被爆出一个高危漏洞（CVE-2016-3714），攻击者可以通过上传恶意图片文件的方式利用该漏洞，在服务器执行任意代码，完全控制目标服务器。目前已知有Wordpress，Discuz！等知名应用受影响。
影响范围： 
ImageMagick <= 6.9.3-9
漏洞修复： 
    官网下载最新版本的ImageMagick并在本地安装。下载地址

3月1日OpenSSL.org官方发布一个OpenSSL的高危漏洞（CVE-2016-0800，别名"DROWN"）。该漏洞可能被黑客利用进行中间人攻击，窃取HTTPS加密数据的内容。OpenSSL官方已发布修复方案，建议各位用户关注并尽快升级系统修复漏洞！
        详情请查看官方公告：https://www.openssl.org/news/secadv/20160301.txt
        受影响的服务版本：
        Apache: 非2.4.x版本
        Nginx: 0.7.64、0.8.18及更早版本
        Postfix: 早于2.9.14、2.10.8、2.11.6、3.0.2的版本 (2015.07.20之前发布的版本)
        Openssl: 1.0.2a、1.0.1m、1.0.0r、0.9.8zf及更早版本
        OpenSSL版本检测：
        openssl version
        若版本低于修复版本请更新openssl
        针对web server,可通过如下方法检测：

        openssl s_client -connect 待测域名或IP地址:443 -ssl2
        漏洞修复方案：

        对于已经运行的云服务器，UCLOUD软件源已经提供了修复漏洞的openssl软件包，您可以通过手动更新openssl进行修复。
        详细修复方法如下：
        1、CentOS版本：
        yum clean all & yum makecache
        yum -y update openssl
        2、Ubuntu\Debian版本：
        sudo apt-get update
        sudo apt-get install libssl1.0.0
        若不想立即进行升级，您可以禁用sslv2协议，操作方法如下：

        1）Apache禁用sslv2协议：
        在Apache的SSL配置文件中禁用SSLv2协议（建议同时禁用SSLv3），确保SSLProtocol配置项内容如下：
        SSLProtocol All -SSLv2
        配置完毕，重启apache服务。
        2）Nginx禁用sslv2协议：
        修改nginx的SSL配置文件，设置只允许使用TLS协议，确保ssl_protocols配置项内容如下：
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2
        配置完毕，重启nginx服务

近日struts2官方发布了1个远程代码执行漏洞（CVE-2016-3087），该漏洞主要影响Struts 2.3.20 - Struts 2.3.28 (除2.3.20.3、2.3.24.3、2.3.28.1)版本，攻击者可利用该漏洞获取Struts程序的权限远程执行任意命令。

        受影响版本：
        Struts 2.3.20 - Struts 2.3.28 （2.3.20.3、2.3.24.3、2.3.28.1除外）

        漏洞描述：
        使用到REST插件的Struts2应用，在开启动态方法调用（DMI）的情况下，会被攻击者实现远程代码执行攻击。
        https://cwiki.apache.org/confluence/display/WW/S2-033 

        漏洞验证：
        检查Struts2的配置文件struts.xml，确认“struts.enable.DynamicMethodInvocation” 是否为“true"，如为“true"，且版本在受影响版本范围内，则说明受影响，否则不受影响。

        修复方案：
        如果您使用了Struts2并在受影响版本内，我们建议您尽快按照如下方案进行修复：
        1、禁用动态方法调用（DMI），修改Struts2的配置文件struts.xml，将struts.enable.DynamicMethodInvocation设置为“false”；
        2、目前官方已经推出了2.3.20.3、2.3.24.3和2.3.28.1修复这个问题，大家可以针对自己所使用的版本进行升级。下载地址：https://struts.apache.org/download.cgi#struts23281

#!/bin/bash



#增加1G的swap空间

dd if=/dev/zero of=/swapfile bs=1MB count=1024



#制作一个swap文件

mkswap /swapfile



#启动swap分区

swapon /swapfile



#添加开机自启

echo '/swapfile               none                    swap    defaults        0 0'   >>  /etc/fstab

Crazysales是一家典型的跨境电商企业，以澳洲和英国作为主要目标市场，产品大多数由国内供应商提供。Crazysales不但是Amazon、eBay等大型电商平台上的大卖家，同时在澳洲、新西兰建设有自营电商网站，为广大用户提供完整的网购服务。 
 



由于涉及跨国网络部署，不可避免地需要穿过“万里长城”，因此应用架构相对普通电商网站更加复杂，管理成本也自然提升，如何能够及时了解分布在中国、澳洲、英国等地不同业务系统的运行状态，是运维部门最关心的工作。

跨境电商的典型IT架构

Crazysales的核心业务系统及网店系统均搭建在Amazon的AWS平台之上，用Amazon CloudFront进行前端内容分发，而后端的数据维护平台因为供应商在国内，所以也在国内。 系统架构如下图：



目前，我们应用的技术都不是“高大上”的新技术，但稳定性得到很好的保证： 1.传统的PHP＋LINUX＋MYSQL，辅助数据的统计和分析应用mongoDB , 搜索引擎基于Solr。 系统架构做到前后低耦合，前端网站强依赖数据库转变成弱依赖。 2.MYSQL部署了两台slave 和定时静态备份数据，确保数据库的异地备份，和读写分离，为以后的无限扩展搭好基础。 3.通过每个应用层的监控，及时发现系统的瓶颈，针对性地优化。 整套系统都是我们团队经过多年合作开发逐步建立和维护的，所以很难保证统一的代码风格和代码水平，那是可遇不可求的。因此，必须建立合理的监控体系及时发现项目管理的漏洞、测试的漏洞、线上的性能瓶颈，这都让运维的工作在整个系统生命周期里更重要，这也是时下运维开发工程师的工作核心。

跨境电商的最佳监控解决方案

因为使用了Amazon的云服务，所以我们运维工程师不必花费大量时间维护基础硬件设施，而有更多的时间和精力来研究和优化我们的业务系统，其中监控体系是令我们为之骄傲的一部分。 



我们的自建监控系统能够及时、准确的发现部署在AWS上和国内的各个业务系统的运行状况，但对于通过CloudFront分发出去的前端内容，以及主要分布于英国、澳大利亚、新西兰等不同国家的用户的访问体验，则是自建监控系统很难准确感知的。另外我们的开发和运维团队主要在国内，因此需要一款既能准确感知海外用户访问Crazysales网站情况，又能通过手机短信、微信等手段给国内技术团队提供准确告警消息的监控工具。经过多方测试，我们最终采用云智慧的监控宝网站监控和网页性能监控功能，负责网站从CDN到前端浏览器环节的可用性监控。  


 
各个层级设不同的监控点

红色部分使用监控宝的监控系统，绿色是监控宝和自建监控系统混合使用 这是我们目前实施的监控架构： 通过脚本／自建监控系统 ／ 外部监控点（模拟真实客户访问） 多种实时监控数据来监测业务系统的运作状态，根据不同系统的特性来调整数据采样的频率，多维度的监控和及时的告警信息让维护人员及时知道系统的运作情况，保障系统的正常运作和提高异常处理的及时性，最终实现故障出现前预防和故障出现后及时解决的效果。 例如，我们的内部监控系统发现数据库在凌晨4点会出现服务很忙，同时监控宝监控数据显示前台出现等待时间过长（>10s），通过和我们的后台任务调度系统的运行时间进行对比，发现一个JOB需要大量SQL查询，导致数据库CPU占用过多，因此及时调整SQL的查询指向其它Slave，同时优化该SQL。 如下图，马上就看到优化后的效果了：  



监控宝遍布全球的分布式监测点能够模拟真实客户访问，及时了解客户遇到的问题，避免IT团队无法取到第一手材料导致丢失重现系统故障的机会，这是我们设置外部监控点的原因。如果自己购买服务器和节点进行部署的话，维护成本很高，也不专业。监控宝基于SaaS的服务和收费模式，很好的解决了成本和维护的问题，帮助我们掌握在澳洲，英国，中国大陆等地的访问速度，可用性等数据。 监控宝模拟客户端在各个监测点的数据采样频率最高可达到5分钟每次，不但能在第一时间发现故障并给予告警，而且能帮助我们掌握Web页面的性能表现，让开发人员可以针对性进行页面优化。而监控宝在全球范围内不断地增加的监测点数量，也和我们公司不断拓展英语国家业务的发展思路不谋而合。 最后说一下告警方式，众所周知，告警是监控的最后一步，大部分监控平台使用的是邮件和短信告警，但现在最流行的社交应用是微信，也是我们现在用得最多和最及时的平台。因此，我们将多种收集数据的介质通过监控宝转化到微信进行提示，基本上能做到故障发生半分钟内运维同事作出反应。