前言

当我们使用haproxy 做负载均衡器的时候,负载均衡多个后端服务器,但是有一个问题,负载均衡后端的服务器的是需要占用haproxy机端口的.
tcp的端口一共65535个除去保留端口,基本也就64k可用的样子.

那么f5之类套着硬件皮的负载均衡器是怎么做到的可以负载几十万的连接数的?

其实f5机本身自己使用了多个内网ip地址,一个f5上的内网ip地址拥有连接后端64k连接的能力.

那么haproxy支持这样的功能么,从而负载更高的连接数么?

经过灿哥的分享,我们知道是可以的,只要给haproxy机配置多个lan内网ip,haproxy机可以通过多个lan内网ip去负载均衡后端服务器.

一个内网ip去负载一台后端服务,这样一个haproxy内网ip就有了长64k连接的负载能力了.

配置haproxy 用多个lan内网ip做负载均衡,以突破haproxy机只支持64k连接(突破单ip 65535端口限制)

配置例子
haproxy负载均衡机
外网ip: 8.8.8.8
haproxy内网ip1: 10.8.8.2
haproxy内网ip2: 10.8.8.3
haproxy内网ip3: 10.8.8.4

后端web1内网ip: 10.8.8.10
后端web2内网ip: 10.8.8.11
后端web3内网ip: 10.8.8.12

server web1 10.8.8.10 : 80 check source 10.8.8.2 : 1025 – 65000
server web2 10.8.8.11 : 80 check source 10.8.8.3 : 1025 – 65000
server web3 10.8.8.12 : 80 check source 10.8.8.4 : 1025 – 65000

如果haproxy机只有一个内网ip 10.8.8.2 去反向代理所有后端,总连接数就只有64k,如果这样配置利用了多个ip去链接后端那么一个haproxy就可以64k连接
从而让haproxy机支持甚至几十w的连接数了.

haproxy官方手册相关

haproxy 手册位置

source <addr>[:<pl>[-<ph>]] [usesrc { <addr2>[:<port2>] | client | clientip } ]
source <addr>[:<port>] [usesrc { <addr2>[:<port2>] | hdr_ip(<hdr>[,<occ>]) } ]
source <addr>[:<pl>[-<ph>]] [interface <name>] ...
The "source" parameter sets the source address which will be used when
connecting to the server. It follows the exact same parameters and principle
as the backend "source" keyword, except that it only applies to the server
referencing it. Please consult the "source" keyword for details.

Additionally, the "source" statement on a server line allows one to specify a
source port range by indicating the lower and higher bounds delimited by a
dash ('-'). Some operating systems might require a valid IP address when a
source port range is specified. It is permitted to have the same IP/range for
several servers. Doing so makes it possible to bypass the maximum of 64k
total concurrent connections. The limit will then reach 64k connections per
server.

Supported in default-server: No

Doing so makes it possible to bypass the maximum of 64k total concurrent connections. The limit will then reach 64k connections per server.

这样做可以绕过64 k的最大并发连接。限制将达到64 k每台后端服务器的连接。也就是说我3台web后端每台64k,haproxy机上就是 64k * 3 = 192k

0x00 用flash URLLoader 支持跨域提交

除了IOS外全支持

0x01 用CORS支持跨域提交

需要浏览器IE8+

ox02 用jsonp支持跨域提交

只支持get方式

 

参考文献

W3C标准 Cross-Origin Resource Sharing

Adobe 了解跨域资源共享 (CORS)

whitenegro关于AJAX/javascript 跨域访问的解决办法及 CORS(Cross-Origin Resource Sharing) 简单介绍

javascript最全的10种跨域共享的方法

0x00 实验目的

根据文章”PHP绕过open_basedir列目录的研究”通过测试不同的配置验证本文的绕过basedir的方法是否有效,从而安全配置php open_basedir的目的.
文中后面几个方法都是windwos下采用枚举的方式列出目录,linux下需要做暴力猜解的方式才可以,所以不做测试.

测试”DirectoryIterator + Glob”方式是否可以绕过open_basedir
测试webshell工具”菜刀”是否可以绕过open_basedir

0x01 实验环境

nginx + PHP 5.6.7 fastcgi模式, centos7 linux
目前配置open_basedir有三处地方php-fpm.conf,nginx fastcgi_param,php.ini
下面逐一测试

0x02 测试详细

只在php-fpm.conf中配置

php_admin_value[open_basedir]=/home/wwwroot/:/proc/:/tmp/

结果

open_basedir的目录以外不能读,不能写,不过DirectoryIterator + Glob 可以成功列出全盘文件

当前open_basedir
open_basedir : /home/wwwroot/:/proc/:/tmp/

-- DirectoryIterator + Glob --.
..
.autorelabel
bin
boot
dev
etc
home
lib
lib64
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
vagrant
var

菜刀不可跨出basedir

 

只在nginx的fastcgi_param配置

# set php open_basedir
fastcgi_param PHP_ADMIN_VALUE "open_basedir=$document_root/:/tmp/:/proc/";

这里的”$document_root”是nginx中的变量,为nginx的每个server里的root目录
比如server www.iamle.com配置的root目录为/home/wwwroot/www.iamle.com

认真读php手册有下面这段话
PHP配置值通过 php_value 或者 php_flag 设置,并且会覆盖以前的值。
请注意 disable_functions 或者 disable_classes 在 php.ini 之中定义的值不会被覆盖掉,但是会将新的设置附加在原有值的后面。
使用 php_admin_value 或者 php_admin_flag 定义的值,不能被 PHP
代码中的 ini_set() 覆盖。自 5.3.3 起,也可以通过 web 服务器设置
PHP 的设定。也就是nignx中fastcgi_param配置php的配置
php_flag用来专门设置布尔值,如on, off, 1, 0, true, false, yes, no,
而php_value用来设置所有类型的值

结果和上面一样

open_basedir的目录以外不能读,不能写,不过DirectoryIterator + Glob 可以成功列出全盘文件

菜刀不可跨出basedir

 

只在php.ini配置

[HOST=www.iamle.com]
open_basedir=/home/wwwroot/www.iamle.com/:/proc/:/tmp/
[PATH=/home/wwwroot/www.iamle.com/]
open_basedir=/home/wwwroot/www.iamle.com/:/proc/:/tmp/

意思是当HOST=www.iamle.com设置open_basedir,当PATH=/home/wwwroot/www.iamle.com/

设置open_basedir,我测试的时候2个任意设置一个都是有效的

结果和上面一样

open_basedir的目录以外不能读,不能写,不过DirectoryIterator + Glob 可以成功列出全盘文件

菜刀不可跨出basedir

 

0x03 个人结论

DirectoryIterator + Glob的方式可以列出php服务器上所有文件,看似没什么危害,实际上对于长期的APT绝对有帮助.
open_basedir不是想象的那么安全,说不定别人手上有甚至有能读写open_basedir的0day

0x04 个人推荐的nginx + php(fastcgi fpm-php)(lnmp) open_basedir的配置

先设置fpm-php中pool池中的总open_basedir这叫顶层设计,有个总限制,比如统一限制到/home/wwwroot/这样的web目录下
再对nginx中单个server 通过 fastcgi_param PHP_ADMIN_VALUE 设置
再对php.ini设置 [HOST=XXX] [PATH=XXX]
三管齐下妈妈再也不用担心我的php open_basedir了(希望吧)
虽然很啰嗦,但是这样岂不是更放心
总而言之就是下面的结果,我就是下面这种啰嗦的配置

 

#在php-fpm.conf对应的pool池中行尾配置
php_admin_value[open_basedir]=/home/wwwroot/:/proc/:/tmp/

#在nginx fastcgi fastcgi_param配置
#这里用$document_root是一种取巧的方法,也可以设置绝对路径
# set php open_basedir
fastcgi_param PHP_ADMIN_VALUE "open_basedir=$document_root/:/tmp/:/proc/";

#在php.ini行尾配置
[HOST=www.iamle.com]
open_basedir=/home/wwwroot/www.iamle.com/:/proc/:/tmp/
[PATH=/home/wwwroot/www.iamle.com/]
open_basedir=/home/wwwroot/www.iamle.com/:/proc/:/tmp/

 

测试中还发现这三个地方配置的优先级如下

“php.ini” > “nginx fastcgi fastcgi_param” > “php-fpm.conf”

 

如果有错误欢迎大家留言斧正,感谢!

 

0x05 参考文档

PHP绕过open_basedir列目录的研究
open_basedir bypass exploit
php-fpm.conf 全局配置段
php.ini HOST PATH配置

缘由

当我用vagrant做开发环境的时候,windows上的svn版本为1.8.x,而vagrant管理的centos7虚拟机中的svn版本为1.7.x的版本.

这样会导致svn低版本不能管理svn高版本管理的仓库.需要把svn版本升级到1.8.x的版本.

centos7.x官方仓库中subversion(svn)的版本号为 1.7.x尝试了RepoForge,EPEL三方源也还是svn 1.7.x的版本~

所以需要源码编译安装svn1.8.x版本

安装svn需要的依赖库说明

centos7 linux系统要支持svn需要包 apr apr-util zlib serf
subversion1.8.x须要应用serf软件包支撑http和https访问svn的版本库
serf编译安装又需要scons.
所以zlib、scons通过yum安装,arp、apr-util、serf通过源码编译安装

还需要更新sqlite版本sqlite-amalgamation,在shell脚本中体现

安装shell

#移除老版本svn以及支持库
yum -y remove apr apr-util subversion subversion-libs

#安装svn依赖库
yum install -y zlib scons
wget https://dist.apache.org/repos/dist/release/apr/apr-1.5.1.tar.gz
wget https://dist.apache.org/repos/dist/release/apr/apr-util-1.5.4.tar.gz
tar zxvf apr-1.5.1.tar.gz 
cd apr-1.5.1
./configure 
make && make install
cd ..
tar zxvf apr-util-1.5.4.tar.gz 
cd apr-util-1.5.4
./configure --with-apr=/usr/local/apr
make && make install
cd ..

wget http://pkgs.fedoraproject.org/repo/pkgs/libserf/serf-1.3.3.tar.bz2/8375cf4fe2a89773c7d6dbf0d540ed27/serf-1.3.3.tar.bz2
tar xjfv serf-1.3.3.tar.bz2 
cd serf-1.3.3
scons PREFIX=/usr/local/serf APR=/usr/local/apr APU=/usr/local/apr
scons install

#复制serf库文件否则会报以下错误的
#svn: error while loading shared libraries: libserf-1.so.1: cannot open shared object file: No such file or directory
cp libserf-1.so* /usr/local/lib/
scons -c
cd ..

#安装svn
wget http://mirrors.cnnic.cn/apache/subversion/subversion-1.8.13.tar.gz
tar zxvf subversion-1.8.13.tar.gz 
cd subversion-1.8.13
#更新sqlite
wget http://www.sqlite.org/sqlite-amalgamation-3071501.zip
unzip sqlite-amalgamation-3071501.zip 
mv sqlite-amalgamation-3071501 sqlite-amalgamation
./configure  --with-apr=/usr/local/apr  --with-apr-util=/usr/local/apr --with-serf=/usr/local/serf
make && make install
svn help

 

 

前言

警惕在某种特定的场景下iMessage(iMessage是什么?)垃圾信息可能会让你的手机号码永久停机!只能换号!

我的一个使用了8年的移动手机号,被永久停用了,是的10086打爆了都无法恢复,营业厅也是不能恢复的。

这个号永久被封禁!

缘由

事情经过是这样的。

我有2个手机一个旧的 iPhone4s 159号(用了8年,现在被永久封禁停机了),一个魅族MX4 170号。

平时使用的是 魅族MX4 170号 ,但是我所有网站,手机应用,银行卡都是绑定的 iPhone4s 159号。

所以我在旧手机iPhone4s 159号上设置了:

1、电话转接, 无条件来电转接到 魅族MX4 170号;

2、短信自动转发,用软件biteSMS 转发所有接收到的短信到 魅族MX4 170号,方便我不用带着2部手机;

 

事情来了今天注册一个手机APP突然发现 iPhone4s 159号 不能够转发短信了。然后检查了发现停机了。

1、检查话费余额是充足的。

2、登录移动网上营业厅系统,发现被停机了,尝试开通失败。

3、联系10086问我手机号的情况,10086客服无法处理恢复,转到其他同事。

4、移动的工作人员联系我说我这个159号发送了国家禁止的垃圾短信,具体内容不清楚需要自己查。

本号码被永久停机,且不能恢复。我一再的询问是否有什么办法恢复,结果是不能,这个号算是永久废了。

我立即检查 iPhone4s 159号 的短信列表,发现了如下图的东西,一个非常非常长的通过iMessage发来的垃圾短信

(图片打码了还是敏感细心已删除)

iPhone4s 159号收到这条非常长的垃圾iMessage短信后,会拆分成多条70字长的短信发送到 魅族MX4 170号手机。

可以非常确定了,就是这样一个非常长的垃圾短信,多次触发了移动的过滤系统导致我的手机号码被永久禁用。

也不排除历史上也有累计转发过垃圾iMessage短信。

结论

手机短信如果发送一些违规,违法的的文本是会被永久停机掉这个手机号的!

我这里就是因为收到了垃圾iMessage短信又开了短信自动转发,无辜躺枪了!fuck!fuck!fuck!

事情经过就是这样,结果是用了8年的号,就这样不能用了。

事已至此,下一步就是修改各种网站,软件等的绑定,修改银行卡的预留号码绑定。

防止发生类似的事情

1、不要发垃圾短信,违规违法的短信内容。

2、开了手机短信自动转发的朋友,千万注意要关闭iMessage,防止类似的杯具再次发生。

 

处理结果

经过微博上 @中国移动10086官方微博  的对接处理, 鉴于我这倒霉的特殊情况,帮我恢复了手机号码的使用,感谢大家的关注,和出主义.