阿里云盾Web应用防火墙的IP地址

若您的服务器正在使用其他防火墙,请关闭或将Web应用防火墙的地址加入其白名单,避免误拦。

Web应用防火墙的地址

121.43.18.0/24
120.25.115.0/24
101.200.106.0/24
120.55.177.0/24
120.27.173.0/24
120.55.107.0/24
118.178.15.0/24
123.57.117.0/24
120.76.16.0/24
182.92.253.32/27
60.205.193.64/27
60.205.193.96/27
120.78.44.128/26
118.178.15.224/27
39.106.237.192/26
106.15.101.96/27
47.101.16.64/27
47.106.31.128/26
112.124.159.192/27
112.124.159.96/27
112.124.159.128/27
47.106.31.192/26
47.98.74.0/25
47.97.242.96/27

GET / HTTP/1.1
Host: test.pentesterlab.cn
User-Agent: curl/7.55.1
X-True-IP: ip
X-Real-IP: ip
Web-Server-Type: nginx
WL-Proxy-Client-IP: ip
X-Forwarded-For: ip
X-Forwarded-Proto: http
X-Forwarded-Cluster: waf,
EagleEye-TraceId: 65c86a0c15350941582235809e785f
Accept: */*
eagleeye-rpcid: 0.1

X-Forwarded-For: 127.0.0.1
X-True-IP: 127.0.0.1
X-Real-IP: 127.0.0.1
WL-Proxy-Client-IP: 127.0.0.1
Ali-Cdn-Real-Ip: 127.0.0.1

各种App Engine的简单比较

前段时间想要申请看一下新版的ACE,但是ACE的工程师不给我邀请码,说等到正式公开测试的时候亲自给我邀请码,然后我就信了~~~

但是,看到新版的ACE上面明明写的可以发邮件申请嘛~于是就发了封邮件;

下面简单的对比一下GAE和国内各种App Engine的特点;

GAE:GAE近来刚加入对PHP的支持,可以自行配置PHP.INI,有少量的禁用函数,相对来说使用起来还是非常灵活的。GAE的SQL是GOOGLE自己的CLOUD SQL,使用起来也比较方便;GAE PHP提供一定量的免费配额,CLOUD SQL是收费的。同时GAE PHP也继续支持了java所支持的TASKQUEUE memcache等,使用起来都比较方便,只是在国内需要绑定域名才能正常访问。
SAE:国内发展较早的APP ENGINE,开始的时候基本模仿GAE的一些特性,率先支持PHP;支持PHP是走在了GAE的前面,非常的不错。继承有来自GAE的特性如:MC,TASKQUEUE,CRON等也有自己的许多特色服务比如KVDB;而且支持mysql(RDC),这是GAE所未支持的
BAE:虽然走在了SAE的后面,但也是发展迅速,从正式对外公测到现在将近一年半的时间,发展成为一个较为不错的app engine;拥有memcache,taskqueue,消息服务,mysql(RDS),等等;还有BAE周边的一些服务,比如BCS,这个相对于SAE的Storage来说还是较为强大的
ACE:之前先是公测,后来不知道为什么改为了内测,现在还是内测;现在拿到了邀请码,发现功能还不是非常多,可能还正在进一步的开发和测试中吧。
上面的GAE,SAE,BAE都对本地写有限制,SAE做出了一个云商店,支持本地写,BAE做了一个类似远程磁盘(NFS)的解决方案,支持本地暂时写和永久写,但是都不是非常好的解决方案,也很期待ACE能够在本地写上面有一个非常好的解决方案。

PHP进行子域名探测

因为不会bash,所以只好用PHP了,因为发现阿里云数据库可能存在的漏洞,这个脚本就是用来探测阿里云数据库所有的子域名。

<?php

/*
 * @author:CplusHua
 * @date:2013-4-27
 * @version:1.0.0
 * @URI:http://www.219.me
 */
$code=Array();
$j=48;
$bool=TRUE;
for($i=0;$i<36;$i++){
    $code[$i]=  chr($j++);
    if($j>57&&$bool){
        $j=97;
        $bool=FALSE;
    } 
}
print_r($code);
$arr=Array('0','0','0','0','0','0','0','0','0','0','0','0','0','0','0');
$domain='';
while(1){
    $domain='';

    for($s=0;$s<15;$s++){
        $domain.=$code[$arr[$s]];
    }
    $host=$domain.".mysql.aliyun.com";
    //echo $host;

    ping($host);
    $arr[0]++;
    for($i=0;$i<14;$i++){
        if($arr[$i]>35){
            $arr[$i]=0;
            $arr[$i+1]++;
        } 
    }
     if(10==$arr[14]){
            break;
      }
}
function ping($host){
    return system('ping -c 1 '.$host.">> ping.txt 2>>/dev/null");
}

?>

快速切换Nginx作为网站前端代理服务器

Nginx比起Apache的高性能高并发特性已经被广泛的应用于生产环境中,如果网站原来使用的是Apache,那如何快速的将Nginx作为前端代理服务器来提供服务呢?

使用一个非常简单的配置文件配置即可。这里摒弃复杂的切换,和生产环境中要考虑的其他诸多因素,单纯简单讲解实现方法。

找到Nginx配置文件,一般位于/usr/local/nginx/conf中,名字为nginx.conf,为了测试,先不改动Apache的任何配置,将Nginx服务在81端口。

找到server配置,修改为以下配置,其中的website.com是网站的域名

server {
        listen       81;
        server_name  website.com;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            proxy_pass http://website.com;
            #root   html;
            #index  index.html index.htm;
        }

为了安全,我们可以先测试一下配置文件是否有语法错误

执行下面的命令测试语法是否正确

sudo /usr/local/nginx/sbin/nginx -t

如果正确将会显示类似下面的内容

nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful

为什么一定要测试配置文件是否正确呢?

1.Nginx配置文件的每一行后面都有一个分号,许多初次使用者会忘记添加分号,此时可能会出现一些莫名其妙的错误,比如提示缺少括号 }
2.Nginx运行时配置文件错误的载入可能会导致进程不受控制,即使使用stop命令都无法停止进程,所以一定要先测试配置文件是否正确
(ps:如果真的不受控制了,那只好强制杀死进程了,可以使用这条命令杀死进程 sudo killall nginx )

配置文件测试正确之后,reload配置文件即可使配置生效

sudo  /etc/init.d/nginx reload

配置文件已经成功载入
打开浏览器,输入上面配置的网站的域名(原来网站的域名)+端口号81,例如配置文件中给出的website.com,可以使用http://website.com:81来访问,这样之后就将Nginx设置为前端代理服务器了。
如果是Chrome浏览器,可以打开控制台,找到Network,查看加载的第一个文件的Response Header是否已经是Nginx
这里是我的截图,可以看到Server行已经变成Nginx

nginx-proxy

 

 

移动飞信接收消息类掉线问题

之前写过一个飞信接收消息的类(http://www.219.me/posts/1098),这个类能够接收飞信消息并做处理(其实其中写了许多的方法,基本能够实现所有飞信的功能),但是这个类的实例总是每半个小时掉线一次,排查了很久没有发现逻辑上存在问题,而且使用相同的cookie再次提取消息没有提示cookie不允许。也就是说cookie是有效的,但是没有办法提取消息了。

经过连续长时间的观察发现,中国移动对用户端的验证还是比较多的,消息中存在拉取group和分组好友的过程,本以为这个过程不会对登陆有影响,但是也正是因为缺少了这个过程,导致飞信无法保持在线,会在半小时后掉线。

最后加入拉取Group和List的过程,能够保持较长时间的在线状态,但是几个小时之后还是会掉线,所以又采取了一些措施,使用Cookie每个小时重新退出登录一次,目前已经测试两天,一个账号已经能够保持每小时登录一次,天天在线,另外一个账号会在退出登录的时候无法再次登录,原因目前未知。两个账号一个账号放在阿里云云服务器,另一个放到SAE。SAE的比较正常一些,阿里云的会掉线。

有人会说现在不是已经有微信了吗?是的,但是某些时候还是会有飞信的需求,而且据我所知,目前许多大学生班级的通知都是使用飞信通知,但许多同学不是移动的号码,所以不能接收到飞信短信,但是有了飞信在线接收消息的类,我们就可以在自己的服务器上开着cron挂着飞信,将飞信消息转发到自己的邮箱或者其他能够通知到自己的地方。
目前已经将飞信与小黄鸡对接,实现飞信机器人的功能,但是小黄鸡API没有有使用量的限制,所以会在一定的对话后失效,这里给出一个飞信机器人的测试账号,如果账号不在线就是无法使用了,如果是手机在线就是机器人在线了,账号是:293609988