一，准备工作
1，登录进VPS控制面板，准备好随时重启VPS。
2，关闭Web Server先，过高的负载会导致后面的操作很难进行，甚至直接无法登录SSH。
3，以防万一，把设置的Web Server系统启动后自动运行去掉。
（如果已经无法登录进系统，并且重启后负载过高导致刚刚开机就已经无法登录，可联系管理员在母机上封掉VPS的IP或80端口，在母机上用虚拟控制台登录进系统，然后进行2&3的操作，之后解封）
二，找出攻击者IP
1，在网站根目录建立文件ip.php，写入下面的内容。
<?php
$real_ip = getenv('HTTP_X_FORWARDED_FOR');
if(isset($real_ip)){
shell_exec("echo $real_ip >> real_ip.txt");
shell_exec("echo $_SERVER['REMOTE_ADDR'] >> proxy.txt");
}else{
shell_exec("echo $_SERVER['REMOTE_ADDR'] >> ips.txt");
}
echo '服务器受到攻击，正在收集攻击源，请在5分钟后访问本站，5分钟内多次访问本站有可能会被当作攻击源封掉IP。谢谢合作！';
?>
2，设置伪静态，将网站下的所有访问都rewrite到ip.php。
Nginx规则：
rewrite (.*) /ip.php;
Lighttpd规则：
url.rewrite = (
"^/(.+)/?$" => "/ip.php"
)
3，启动Web Server开始收集IP
进行完1和2的设置后，启动Web Server，开始记录IP信息。
收集时间建议为3到5分钟，然后再次关闭Web Server。
real_ip.txt，这个文件中保存的IP有80%以上都相同的，这个IP就是攻击者实施攻击的平台的IP。
proxy.txt，这个文件中保存的是攻击者调用的代理服务器的IP，需要封掉。
ips.txt，这里记录的是未表现出代理服务器特征的IP，根据访问次数判断是否为攻击源。
三，对上一段的补充
如果VPS上启用了WEB日志，可以查看日志文件的增长速度来判断是哪个站点被攻击。
如果没有启用日志，并且站点数量很少，临时启用日志也很方便 。
如果没有启用日志，并且站点数量过多，可以使用临时的Web Server配置文件，不绑定虚拟主机，设置一个默认的站点。然后在ip.php里加入下面一行
shell_exec(“echo $_SERVER['HTTP_HOST'] >> domain.txt”);
domain.txt里将保存被访问过的域名，被CC攻击的站点将在里面占绝大多数。
四，开始封堵IP
建立文件ban.php
<?
$threshold = 10;
$ips = array_count_values(file('ips.txt'));
$ban_num = 0;
foreach($ips as $ip=>$num){
if($num > $threshold){
$ip = trim($ip);
$cmd = "iptables -I INPUT -p tcp --dport 80 -s $ip -j DROP";
shell_exec($cmd);
echo "$ip baned!\n";
$ban_num ++;
}
}
$proxy_arr = array_unique(file('ips.txt'));
foreach($proxy_arr as $proxy){
$proxy = trim($proxy);
$cmd = "iptables -I INPUT -p tcp --dport 80 -s $ip -j DROP";
shell_exec($cmd);
echo "$ip baned!\n";
$ban_num ++;
}
echo "total: $ban_num ips\n";
?>
用下面的命令执行脚本（确保php命令在PATH中）
php ban.php
这个脚本依赖于第二段中ips.txt里保存的结果，当其中记录的IP访问次数超过10次，就被当作攻击源给屏蔽掉。如果是代理服务器，则不判断次数直接 封掉。
封完IP之后，把所有的网站设置恢复正常，站点可以继续正常运行了。
五，一些细节
为保持对操作过程的描述尽量简洁，没有在上面的内容中加入过多的解释，留在这段统一讲述。
1，关于“代理服务器”的一些本质
两个与TCP&HTTP协议相关的值，REMOTE_ADDR和HTTP_X_FORWARDED_FOR。
（1）REMOTE_ADDR总是取离Web服务器最接近的一台主机的IP，如果没有使用代理，这个值就是访问者本身的IP，如果使用了代理，这个值就是 代理服务器的IP，如果通过多个代理服务器进行的连接，这个值就是到达Web服务器前最后一台代理服务器的IP。
REMOTE_ADDR是由TCP/IP层决定的，不能修改不能伪造。
（2）HTTP_X_FORWARDED_FOR，因为这个值是属于HTTP部分，而不是TCP/IP，所以这个值不管是什么，都不影响数据的传 输。事实 上，一般情况下，如果是访问者直接访问Web服务器，这个值为空；通过透明代理的时候，这个值会被代理服务器设置为访问者的IP；通过匿名代理连接时，这 个值可能为代理服务器的IP也可能是空的也有可能是随机的。
HTTP_X_FORWARDED_FOR可以被任意修改。大多数代理服务器都是透明代理，也就是说，会把这个值设置为最原始访问者的IP。
2，关于解决CC攻击的层面问题
按处理效率从高到低排列。
（由于本文是针对VPS服务器所写，而VPS简单来说就是服务器的低端替代品，内存和CPU等资源普遍偏低，当然是处理效率越高越好。）
（1）网络传输层。也就是本文所用的iptables，这个工具本身是工作于系统内核，在建立网络连接时直接把攻击者的连接给否了。在这一层面上将攻击源处理掉后，消耗掉的资源几乎可以忽略不计。
（2）Web Server层，大多数Web Server都可以设置禁止访问的IP。在这一层上解决的意义和上面的差不多，但是效率要差些。
（3）脚本层，从脚本程序上制定适合于本身的策略过滤掉攻击源。网络上有很多流传的在这一层面的解决方案，但是不太适用于VPS，而且设置难度可能要增加几倍或者几十倍。
3，为什么不是从日志收集IP？
主要是考虑两点，一是大多数VPS使用者都因为硬盘空间过小，经常清除日志很麻烦，而直接禁止了日志。
二是如果从日志收集IP，脚本复杂程度要高很多，而且可能要根据情况做些调整，考虑到将要读到本文的人大多数都未必掌握更多的技术，本文的目的就是按部就班的依本文进行操作，即可解决问题。
--------------------------------------------------------
CC攻击（Challenge Collapsar）是DDOS（分布式拒绝服务）的一种，也是一种常见的网站攻击方法，攻击者通过代理服务器或者肉鸡向向受害主机不停地发大量数据包，造成对方服务器资源耗尽，一直到宕机崩溃。
CC攻击的攻击技术含量低，利用工具和一些IP代理，一个初、中级的电脑水平的用户就能够实施攻击。不过，如果了解了CC攻击的原理，那就不难针对CC攻击实施一些有效的防范措施。
通常防止CC攻击的方法有几种，一个是通过防火墙，另外一些网络公司也提供了一些防火墙服务，例如XX网站卫士和XX宝，还有一种方法是自己写程序预防，昨天网站遇到CC攻击，这也让我尝试了一下各种防止CC攻击方法的有效性。
一开始我想使用某某网站卫士来预防攻击，从界面上看，似乎是防止了大量的CC攻击，但登录网站后发现，流量依旧异常，攻击还是依旧，看起来这个网站卫士的效果并没有达到。
网站防止CC攻击的方法
从原理上看，基本上所有的防火墙都会检测并发的TCP/IP连接数目，超过一定数目一定频率就会被认为是Connection-Flood。但如果IP的数量足够大，使得单个IP的连接数较少，那么防火墙未必能阻止CC攻击。
不仅如此，我还发现，启用了某某网站卫士之后，反而更容易被CC攻击，因为这个网站卫士并不能过滤掉CC攻击，攻击的IP经过其加速后，更换成为这个网站卫士的IP，在网站服务器端显示的IP都是相同的，导致服务器端无法过滤这些IP。
实际上，不使用网站卫士类的服务，直接通过分析网站日志，还是很容易分辨出哪个IP是CC攻击的，因为CC攻击毕竟是通过程序来抓取网页，与普通浏览者 的特性区别还是很大的，例如普通浏览者访问一个网页，必定会连续抓取网页的HTML文件、CSS文件、JS文件和图片等一系列相关文件，而CC攻击者仅仅 只会抓取一个URL地址的文件，不会抓取其他类型的文件，其User Agent也大部分和普通浏览者不同，这就可以在服务器上很容易分辨出哪些访问者是CC攻击了，既然可以判断出攻击者的IP，那么预防措施就很简单，只需 要批量将这些IP屏蔽，即可达到防范CC攻击的目的。
最终，我花了半个小时写了一段小程序，运行之后自动屏蔽了数百个IP，网站才算正常，从而证明，防火墙对于CC攻击的防御并不有效，最有效的方法还是在服务器端通过程序自动屏蔽来预防。
看来CC攻击的门槛还真低啊，搞个几百个代理或者肉鸡就能攻击别人了，其成本非常低，但效果比较明显，如果攻击者流量巨大的话，通过耗费带宽资源的方式 都可以进行攻击。但是，CC攻击也有明显的技术缺陷，就是攻击者的IP并不是海量的，通常就是几百数千的级别，并且是真实访问了网站页面，这就使得网站可 以通过程序过滤的方式，轻松获取到这些攻击者IP，批量进行屏蔽，那么这种CC攻击就会得到预防。
来源：http://www.williamlong.info/archives/3181.html
1，登录进VPS控制面板，准备好随时重启VPS。
2，关闭Web Server先，过高的负载会导致后面的操作很难进行，甚至直接无法登录SSH。
3，以防万一，把设置的Web Server系统启动后自动运行去掉。
（如果已经无法登录进系统，并且重启后负载过高导致刚刚开机就已经无法登录，可联系管理员在母机上封掉VPS的IP或80端口，在母机上用虚拟控制台登录进系统，然后进行2&3的操作，之后解封）
二，找出攻击者IP
1，在网站根目录建立文件ip.php，写入下面的内容。
<?php
$real_ip = getenv('HTTP_X_FORWARDED_FOR');
if(isset($real_ip)){
shell_exec("echo $real_ip >> real_ip.txt");
shell_exec("echo $_SERVER['REMOTE_ADDR'] >> proxy.txt");
}else{
shell_exec("echo $_SERVER['REMOTE_ADDR'] >> ips.txt");
}
echo '服务器受到攻击，正在收集攻击源，请在5分钟后访问本站，5分钟内多次访问本站有可能会被当作攻击源封掉IP。谢谢合作！';
?>
2，设置伪静态，将网站下的所有访问都rewrite到ip.php。
Nginx规则：
rewrite (.*) /ip.php;
Lighttpd规则：
url.rewrite = (
"^/(.+)/?$" => "/ip.php"
)
3，启动Web Server开始收集IP
进行完1和2的设置后，启动Web Server，开始记录IP信息。
收集时间建议为3到5分钟，然后再次关闭Web Server。
real_ip.txt，这个文件中保存的IP有80%以上都相同的，这个IP就是攻击者实施攻击的平台的IP。
proxy.txt，这个文件中保存的是攻击者调用的代理服务器的IP，需要封掉。
ips.txt，这里记录的是未表现出代理服务器特征的IP，根据访问次数判断是否为攻击源。
三，对上一段的补充
如果VPS上启用了WEB日志，可以查看日志文件的增长速度来判断是哪个站点被攻击。
如果没有启用日志，并且站点数量很少，临时启用日志也很方便 。
如果没有启用日志，并且站点数量过多，可以使用临时的Web Server配置文件，不绑定虚拟主机，设置一个默认的站点。然后在ip.php里加入下面一行
shell_exec(“echo $_SERVER['HTTP_HOST'] >> domain.txt”);
domain.txt里将保存被访问过的域名，被CC攻击的站点将在里面占绝大多数。
四，开始封堵IP
建立文件ban.php
<?
$threshold = 10;
$ips = array_count_values(file('ips.txt'));
$ban_num = 0;
foreach($ips as $ip=>$num){
if($num > $threshold){
$ip = trim($ip);
$cmd = "iptables -I INPUT -p tcp --dport 80 -s $ip -j DROP";
shell_exec($cmd);
echo "$ip baned!\n";
$ban_num ++;
}
}
$proxy_arr = array_unique(file('ips.txt'));
foreach($proxy_arr as $proxy){
$proxy = trim($proxy);
$cmd = "iptables -I INPUT -p tcp --dport 80 -s $ip -j DROP";
shell_exec($cmd);
echo "$ip baned!\n";
$ban_num ++;
}
echo "total: $ban_num ips\n";
?>
用下面的命令执行脚本（确保php命令在PATH中）
php ban.php
这个脚本依赖于第二段中ips.txt里保存的结果，当其中记录的IP访问次数超过10次，就被当作攻击源给屏蔽掉。如果是代理服务器，则不判断次数直接 封掉。
封完IP之后，把所有的网站设置恢复正常，站点可以继续正常运行了。
五，一些细节
为保持对操作过程的描述尽量简洁，没有在上面的内容中加入过多的解释，留在这段统一讲述。
1，关于“代理服务器”的一些本质
两个与TCP&HTTP协议相关的值，REMOTE_ADDR和HTTP_X_FORWARDED_FOR。
（1）REMOTE_ADDR总是取离Web服务器最接近的一台主机的IP，如果没有使用代理，这个值就是访问者本身的IP，如果使用了代理，这个值就是 代理服务器的IP，如果通过多个代理服务器进行的连接，这个值就是到达Web服务器前最后一台代理服务器的IP。
REMOTE_ADDR是由TCP/IP层决定的，不能修改不能伪造。
（2）HTTP_X_FORWARDED_FOR，因为这个值是属于HTTP部分，而不是TCP/IP，所以这个值不管是什么，都不影响数据的传 输。事实 上，一般情况下，如果是访问者直接访问Web服务器，这个值为空；通过透明代理的时候，这个值会被代理服务器设置为访问者的IP；通过匿名代理连接时，这 个值可能为代理服务器的IP也可能是空的也有可能是随机的。
HTTP_X_FORWARDED_FOR可以被任意修改。大多数代理服务器都是透明代理，也就是说，会把这个值设置为最原始访问者的IP。
2，关于解决CC攻击的层面问题
按处理效率从高到低排列。
（由于本文是针对VPS服务器所写，而VPS简单来说就是服务器的低端替代品，内存和CPU等资源普遍偏低，当然是处理效率越高越好。）
（1）网络传输层。也就是本文所用的iptables，这个工具本身是工作于系统内核，在建立网络连接时直接把攻击者的连接给否了。在这一层面上将攻击源处理掉后，消耗掉的资源几乎可以忽略不计。
（2）Web Server层，大多数Web Server都可以设置禁止访问的IP。在这一层上解决的意义和上面的差不多，但是效率要差些。
（3）脚本层，从脚本程序上制定适合于本身的策略过滤掉攻击源。网络上有很多流传的在这一层面的解决方案，但是不太适用于VPS，而且设置难度可能要增加几倍或者几十倍。
3，为什么不是从日志收集IP？
主要是考虑两点，一是大多数VPS使用者都因为硬盘空间过小，经常清除日志很麻烦，而直接禁止了日志。
二是如果从日志收集IP，脚本复杂程度要高很多，而且可能要根据情况做些调整，考虑到将要读到本文的人大多数都未必掌握更多的技术，本文的目的就是按部就班的依本文进行操作，即可解决问题。
--------------------------------------------------------
网站防止CC攻击的方法
CC攻击（Challenge Collapsar）是DDOS（分布式拒绝服务）的一种，也是一种常见的网站攻击方法，攻击者通过代理服务器或者肉鸡向向受害主机不停地发大量数据包，造成对方服务器资源耗尽，一直到宕机崩溃。
CC攻击的攻击技术含量低，利用工具和一些IP代理，一个初、中级的电脑水平的用户就能够实施攻击。不过，如果了解了CC攻击的原理，那就不难针对CC攻击实施一些有效的防范措施。
通常防止CC攻击的方法有几种，一个是通过防火墙，另外一些网络公司也提供了一些防火墙服务，例如XX网站卫士和XX宝，还有一种方法是自己写程序预防，昨天网站遇到CC攻击，这也让我尝试了一下各种防止CC攻击方法的有效性。
一开始我想使用某某网站卫士来预防攻击，从界面上看，似乎是防止了大量的CC攻击，但登录网站后发现，流量依旧异常，攻击还是依旧，看起来这个网站卫士的效果并没有达到。
网站防止CC攻击的方法
从原理上看，基本上所有的防火墙都会检测并发的TCP/IP连接数目，超过一定数目一定频率就会被认为是Connection-Flood。但如果IP的数量足够大，使得单个IP的连接数较少，那么防火墙未必能阻止CC攻击。
不仅如此，我还发现，启用了某某网站卫士之后，反而更容易被CC攻击，因为这个网站卫士并不能过滤掉CC攻击，攻击的IP经过其加速后，更换成为这个网站卫士的IP，在网站服务器端显示的IP都是相同的，导致服务器端无法过滤这些IP。
实际上，不使用网站卫士类的服务，直接通过分析网站日志，还是很容易分辨出哪个IP是CC攻击的，因为CC攻击毕竟是通过程序来抓取网页，与普通浏览者 的特性区别还是很大的，例如普通浏览者访问一个网页，必定会连续抓取网页的HTML文件、CSS文件、JS文件和图片等一系列相关文件，而CC攻击者仅仅 只会抓取一个URL地址的文件，不会抓取其他类型的文件，其User Agent也大部分和普通浏览者不同，这就可以在服务器上很容易分辨出哪些访问者是CC攻击了，既然可以判断出攻击者的IP，那么预防措施就很简单，只需 要批量将这些IP屏蔽，即可达到防范CC攻击的目的。
最终，我花了半个小时写了一段小程序，运行之后自动屏蔽了数百个IP，网站才算正常，从而证明，防火墙对于CC攻击的防御并不有效，最有效的方法还是在服务器端通过程序自动屏蔽来预防。
看来CC攻击的门槛还真低啊，搞个几百个代理或者肉鸡就能攻击别人了，其成本非常低，但效果比较明显，如果攻击者流量巨大的话，通过耗费带宽资源的方式 都可以进行攻击。但是，CC攻击也有明显的技术缺陷，就是攻击者的IP并不是海量的，通常就是几百数千的级别，并且是真实访问了网站页面，这就使得网站可 以通过程序过滤的方式，轻松获取到这些攻击者IP，批量进行屏蔽，那么这种CC攻击就会得到预防。
来源：http://www.williamlong.info/archives/3181.html
