你好，欢迎来到老张的博客,张素杰

Varnish 简介

Varnish 是一款高性能且开源的反向代理服务器和 HTTP 加速器，其采用全新的软件体系机构，和现在的硬件体系紧密配合，与传统的 squid 相比，varnish 具有性能更高、速度更快、管理更加方便等诸多优点，很多大型的网站都开始尝试使用 varnish 来替换squid，这些都促进 varnish 迅速发展起来。挪威的最大的在线报纸 Verdens Gang(vg.no) 使用 3 台 Varnish 代替了原来的 12 台 Squid，性能比以前更好，这是 Varnish 最成功的应用案例

Varnish 文件缓存的工作流程

Varnish 与一般服务器软件类似，分为 master 进程和 child 进程。Master 进程读入存储配置文件，调用合适的存储类型，然后创建 / 读入相应大小的缓存文件，接着 master 初始化管理该存储空间的结构体，然后 fork并监控 child 进程。Child 进程在主线程的初始化的过程中，将前面打开的存储文件整个 mmap到内存中，此时创建并初始化空闲结构体，挂到存储管理结构体，以待分配。Child 进程分配若干线程进行工作，主要包括一些管理线程和很多worker 线程。

接着，开始真正的工作，varnish 的某个负责接收新 HTTP 连接线程开始等待用户，如果有新的 HTTP连接过来，它总负责接收，然后唤醒某个等待中的线程，并把具体的处理过程交给它。Worker 线程读入 HTTP 请求的 URI，查找已有的 object，如果命中则直接返回并回复用户。如果没有命中，则需要将所请求的内容，从后端服务器中取过来，存到缓存中，然后再回复。

分配缓存的过程是这样的：它根据所读到 object 的大小，创建相应大小的缓存文件。为了读写方便，程序会把每个 object 的大小变为最接近其大小的内存页面倍数。然后从现有的空闲存储结构体中查找，找到最合适的大小的空闲存储块，分配给它。如果空闲块没有用完，就把多余的内存另外组成一个空闲存储块，挂到管理结构体上。如果缓存已满，就根据 LRU 机制，把最旧的 object 释放掉。

释放缓存的过程是这样的：有一个超时线程，检测缓存中所有 object 的生存期，如果超初设定的 TTL（Time To Live）没有被访问，就删除之，并且释放相应的结构体及存储内存。注意释放时会检查该存储内存块前面或后面的空闲内存块，如果前面或后面的空闲内存和该释放内存是连续的，就将它们合并成更大一块内存。

整个文件缓存的管理，没有考虑文件与内存的关系，实际上是将所有的 object 都考虑是在内存中，如果系统内存不足，系统会自动将其换到 swap 空间，而不需要 varnish 程序去控制。

安装 varnish

和其他软件一样，直接

./configure --prefix=/usr/local/varnish  	
 make 
 make install

Varnish 配置

VCL 简介

VCL（varnish configuration language）是 varnish 配置语言，其用来定义 varnish 的存取策略。VCL 语法比较简单，跟 C 和 Perl 比较相似。主要有以下几点：

• 块是由花括号分隔，语句以分号结束，使用‘ # ’符号可以添加注释。

• VCL 使用指定运算符“=”、比较运算符“==”、逻辑运算符“!,&&,!!”等形式，还支持正则表达式和用“~”进行 ACL 匹配运算。

• VCL 没有用户自己定义的变量，你可以在 backend、request 或 object 上设置变量值，采用 set 关键字进行设置。例如 set req.backend = director_employeeui;

• 两个字符串的连接，他们之间没有任何运算符。代码如清单 5 所示：

清单 5. 字符串连接代码

 set req.http.X-hit = " hit" "it";

• \”字符在 VCL 里没有特别的含义，这点与其他语言略有不同。

• VCL 可以使用 set 关键字设置任何 HTTP 头，可以使用 remove 或是 unset 关键字移除 HTTP 头。

• VCL 有 if/else 的判断语句，但是没有循环语句。

VCL backend

声明并初始化一个后端对象，代码如清单 6 所示

清单 6. backend 声明代码

	 backend www { 
	   .host = "www.example.com"; 
	   .port = "9082"; 
	 }

后端对象的使用，代码如清单 7 所示

清单 7. backend 的使用代码

	 if (req.http.host ~ "^(www.)?example.com$") { 
	    set req.backend = www; 
	 }

VCL 后端的集合 director

VCL 可以把多个 backends 聚合成一个组，这些组被叫做 director，这样可以增强性能和弹力，当组里一个 backend 挂掉后，可以选择另一个健康的 backend。VCL 有多种 director，不同的 director 采用不同的算法选择 backend，主要有以下几种：

• The random director

Random director 会根据所设置的权值（weight）来选择 backend，.retries 参数表示尝试找到一个 backend 的最大次数，.weight 参数表示权值

• The round-robin director

Round-robin director 在选择 backend 时，会采用循环的方式依次选择。

• The client director

Client director 根据 client.identity 来选择 backend，您可以设置 client.identity 的值为 session cookie 来标识 backend。

backend probes

VCL 可以设置 probe 来检测一个 backend 是否健康，定义一个 backend probes 代码如清单 8 所示：

清单 8. 定义 backend probes 代码

	 backend www { 
	  .host = "www.example.com"; 
	  .port = "9082"; 
	  .probe = { 
	    .url = "/test.jpg";// 哪个 url 需要 varnish 请求
	    .timeout = 1 s;// 等待多长时间超时
	    .interval = 5s// 检查的时间间隔
             .window = 5;// 维持 5 个 sliding window 的结果
	    .threshold = 3;// 至少有三次 window 是成功的，就宣告 backend 健康
	  } 
	 }

ACL

ACL 可创建一个客户端的访问控制列表，你可以使用 ACL 控制哪些客户端可以访问，哪些客户端禁止访问。定义 ACL 代码如清单 9 所示：

清单 9. ACL 定义代码

	 Acl local{ 
	   "localhost"; 
	   "192.0.2.0"/24; 
	   !"192.0.2.23";// 除去该 IP 
	 }

VCL 内置函数

vcl_recv 函数

用于接收和处理请求。当请求到达并成功接收后被调用，通过判断请求的数据来决定如何处理请求。例如如何响应、怎么响应、使用哪个后端服务器等。

此函数一般以如下几个关键字结束。

pass：表示进入 pass 模式，把请求控制权交给 vcl_pass 函数。

pipe：表示进入 pipe 模式，把请求控制权交给 vcl_pipe 函数。

lookup：表示进入 lookup 模式，把请求控制权交给 lookup 指令处理，在缓存中查找被请求的对象，并且根据查找的结果把控制权交给函数 vcl_hit 或函数 vcl_miss。

error code [reason]：表示返回“code”给客户端，并放弃处理该请求。“code”是错误标识，例如 200 和 405 等。“reason”是错误提示信息。

vcl_pipe 函数

此函数在进入 pipe 模式时被调用，用于将请求直接传递至后端主机，在请求和返回的内容没有改变的情况下，将不变的内容返回给客户端，直到这个连接被关闭。

此函数一般以如下几个关键字结束。

error code [reason]。

pipe。

vcl_pass 函数

此函数在进入 pass 模式时被调用，用于将请求直接传递至后端主机。后端主机在应答数据后将应答数据发送给客户端，但不进行任何缓存，在当前连接下每次都返回最新的内容。

此函数一般以如下几个关键字结束。

error code [reason]。

pass。

restart 重新启动流程，增加启动次数，如果重新启动次数高于 max_restarts 发出一个错误警告

vcl_hash

当您想把一个数据添加到 hash 上时，调用此函数。

此函数一般以如下几个关键字结束。

Hash。

vcl_hit 函数

在执行 lookup 指令后，在缓存中找到请求的内容后将自动调用该函数。

此函数一般以如下几个关键字结束。

deliver：表示将找到的内容发送给客户端，并把控制权交给函数 vcl_deliver。

error code [reason] 。

pass。

restart 重新启动流程，增加启动次数，如果重新启动次数高于 max_restarts 发出一个错误警告

vcl_miss 函数

在执行 lookup 指令后，在缓存中没有找到请求的内容时自动调用该方法。此函数可用于判断是否需要从后端服务器获取内容。

此函数一般以如下几个关键字结束。

fetch：表示从后端获取请求的内容，并把控制权交给 vcl_fetch 函数。

error code [reason] 。

pass。

vcl_fetch 函数

在后端主机更新缓存并且获取内容后调用该方法，接着，通过判断获取的内容来决定是将内容放入缓存，还是直接返回给客户端。

此函数一般以如下几个关键字结束。

error code [reason]。

pass。

deliver。

esi。

restart 重新启动流程，增加启动次数，如果重新启动次数高于 max_restarts 发出一个错误警告

vcl_deliver 函数

将在缓存中找到请求的内容发送给客户端前调用此方法。

此函数一般以如下几个关键字结束。

error code [reason]。

deliver。

restart 重新启动流程，增加启动次数，如果重新启动次数高于 max_restarts 发出一个错误警告

vcl_error

出现错误时调用此函数。

此函数一般以如下几个关键字结束。

deliver。

restart。

VCL 处理流程

VCL 处理的流程图如图 1 所示

图 1.VCL 处理流程

Varnish 处理 HTTP 请求的过程大致分为如下几个步骤。

• Receive 状态（vcl_recv）。也就是请求处理的入口状态，根据 VCL 规则判断该请求应该 pass（vcl_pass）或是 pipe（vcl_pipe），还是进入 lookup（本地查询）。

• Lookup 状态。进入该状态后，会在 hash 表中查找数据，若找到，则进入 hit（vcl_hit）状态，否则进入 miss（vcl_miss）状态。

• Pass（vcl_pass）状态。在此状态下，会直接进入后端请求，即进入 fetch（vcl_fetch）状态

• Fetch（vcl_fetch）状态。在 fetch 状态下，对请求进行后端获取，发送请求，获得数据，并根据设置进行本地存储。

• Deliver（vcl_deliver）状态。将获取到的数据发给客户端，然后完成本次请求。

VCL 内置公共变量

VCL 内置的公共变量可以用在不同的 VCL 函数中，下面根据使用的不同阶段进行介绍

当请求到达时，可以使用的公共变量表 1 所示

表 1. 请求到达时可用公共变量

Varnish 在向后端主机请求时，可是用的公共变量如表 2 所示

表 2. 向后端主机请求时可用公共变量

从 cache 或是后端主机获取内容后，可以使用的公共变量如表 3 所示

表 3. 后端主机获取内容时可使用公共变量

对客户端应答时，可以使用的公共变量如表 4 所示

表 4. 对客户端相应时可使用公共变量

VCL 调试

VCL 为配置文件语言，无法像 c/c++ 那样进行单步调试，当 VCL 运行的效果和预期效果不一样时，很难发现哪出现逻辑错误，这时除了查看代码查找错误外，我们还可以采用内置 C 语言和浏览器查看返回对象中的状态来查找逻辑的错误。

我们可以采用内置 C 语言来打印相应的信息，例如我们可以在相应的地方打印信息，来查看 VCL 流程的执行是否正确。内置 C 语言打印信息代码如清单 10 所示：

清单 10. 打印信息代码

      C{ 
	    #include<syslog.h>// 首先要包含头文件
      }C 
      C{ 
	    Syslog(LOG_INFO,"VCL run here in function xxx in line xxx"); 
      }C

启动 varnish 后，我们可以采用 tail -f /var/log/messages 命令在 /var/log/messages 中查看相应的打印信息。查看的打印信息如图 2 所示：

图 2. varnish 打印信息

我们还可以将某些变量的值设置到返回给浏览器的对象上，然后在浏览器中查看该变量的值。设置变量值代码如清单 11 所示：

清单 11. varnish 变量设置代码

 set beresp.http.X-Cookie-Debug-req-cookie = req.http.Cookie;

在 chrome 浏览器中查看 beresp.http.X-Cookie-Debug-req-cookie 的值，结果如图 3 所示：

图 3. 在浏览器中查看 varnish 变量的值

小结

本文介简单介绍了 varnish，并对其工作流程、安装以及配置进行了详细讲解。通过本文，可以很快的掌握 varnish。

转载：http://www.ibm.com/developerworks/cn/opensource/os-cn-varnish-intro/

why is it termed as penny loafer
miranda lambert weight loss The Best Vitamins for Hair Loss

前言

大家好，我们是OpenCDN团队的Twwy。这次我们来讲讲如何通过简单的配置文件来实现nginx防御攻击的效果。

其实很多时候，各种防攻击的思路我们都明白，比如限制IP啊，过滤攻击字符串啊，识别攻击指纹啦。可是要如何去实现它呢？用守护脚本吗？用PHP在外面包
一层过滤？还是直接加防火墙吗？这些都是防御手段。不过本文将要介绍的是直接通过nginx的普通模块和配置文件的组合来达到一定的防御效果。

验证浏览器行为

简易版

我们先来做个比喻。

社区在搞福利，在广场上给大家派发红包。而坏人派了一批人形的机器人(没有语言模块)来冒领红包，聪明工作人员需要想出办法来防止红包被冒领。

于是工作人员在发红包之前，会给领取者一张纸，上面写着“红包拿来”，如果那人能念出纸上的字，那么就是人，给红包，如果你不能念出来，那么请自觉。于是机器人便被识破，灰溜溜地回来了。

是的，在这个比喻中，人就是浏览器，机器人就是攻击器，我们可以通过鉴别cookie功能(念纸上的字)的方式来鉴别他们。下面就是nginx的配置文件写法。

if ($cookie_say != "hbnl"){ add_header Set-Cookie "say=hbnl"; rewrite .* "$scheme://$host$uri" redirect; }

让我们看下这几行的意思，当cookie中say为空时，给一个设置cookie
say为hbnl的302重定向包，如果访问者能够在第二个包中携带上cookie值，那么就能正常访问网站了，如果不能的话，那他永远活在了302中。
你也可以测试一下，用CC攻击器或者webbench或者直接curl发包做测试，他们都活在了302世界中。

当然，这么简单就能防住了？当然没有那么简单。

增强版

仔细的你一定会发现配置文件这样写还是有缺陷。如果攻击者设置cookie为say=hbnl（CC攻击器上就可以这么设置），那么这个防御就形同虚设了。我们继续拿刚刚那个比喻来说明问题。

坏人发现这个规律后，给每个机器人安上了扬声器，一直重复着“红包拿来，红包拿来”，浩浩荡荡地又来领红包了。

这时，工作人员的对策是这样做的，要求领取者出示有自己名字的户口本，并且念出自己的名字，“我是xxx，红包拿来”。于是一群只会嗡嗡叫着“红包拿来”的机器人又被撵回去了。

当然，为了配合说明问题，每个机器人是有户口本的，被赶回去的原因是不会念自己的名字，虽然这个有点荒诞，唉。

然后，我们来看下这种方式的配置文件写法

if ($cookie_say != "hbnl$remote_addr"){ add_header Set-Cookie "say=hbnl$remote_addr"; rewrite .* "$scheme://$host$uri" redirect; }

这样的写法和前面的区别是，不同IP的请求cookie值是不一样的，比如IP是1.2.3.4，那么需要设置的cookie是
say=hbnl1.2.3.4。于是攻击者便无法通过设置一样的cookie(比如CC攻击器)来绕过这种限制。你可以继续用CC攻击器来测试下，你会
发现CC攻击器打出的流量已经全部进入302世界中。

不过大家也能感觉到，这似乎也不是一个万全之计，因为攻击者如果研究了网站的机制之后，总有办法测出并预先伪造cookie值的设置方法。因为我们做差异
化的数据源正是他们本身的一些信息（IP、user agent等）。攻击者花点时间也是可以做出专门针对网站的攻击脚本的。

完美版

那么要如何根据他们自身的信息得出他们又得出他们算不出的数值？

我想，聪明的你一定已经猜到了，用salt加散列。比如md5(“opencdn$remote_addr”)，虽然攻击者知道可以自己IP，但是他无法
得知如何用他的IP来计算出这个散列，因为他是逆不出这个散列的。当然，如果你不放心的话，怕cmd5.com万一能查出来的话，可以加一些特殊字符，然
后多散几次。

很可惜，nginx默认是无法进行字符串散列的，于是我们借助nginx_lua模块来进行实现。

rewrite_by_lua '
    local say = ngx.md5("opencdn" .. ngx.var.remote_addr)
    if (ngx.var.cookie_say ~= say) then
        ngx.header["Set-Cookie"] = "say=" .. say
        return ngx.redirect(ngx.var.scheme .. "://" .. ngx.var.host .. ngx.var.uri)
    end
';

通过这样的配置，攻击者便无法事先计算这个cookie中的say值，于是攻击流量(代理型CC和低级发包型CC)便在302地狱无法自拔了。

大家可以看到，除了借用了md5这个函数外，其他的逻辑和上面的写法是一模一样的。因此如果可以的话，你完全可以安装一个nginx的计算散列的第三方模块来完成，可能效率会更高一些。

这段配置是可以被放在任意的location里面，如果你的网站有对外提供API功能的话，建议API一定不能加入这段，因为API的调用也是没有浏览器行为的，会被当做攻击流量处理。并且，有些弱一点爬虫也会陷在302之中，这个需要注意。

同时，如果你觉得set-cookie这个动作似乎攻击者也有可能通过解析字符串模拟出来的话，你可以把上述的通过header来设置cookie的操作，变成通过高端大气的js完成，发回一个含有doument.cookie=…的文本即可。

那么，攻击是不是完全被挡住了呢？只能说那些低级的攻击已经被挡住而来，如果攻击者必须花很大代价给每个攻击器加上webkit模块来解析js和执行
set-cookie才行，那么他也是可以逃脱302地狱的，在nginx看来，确实攻击流量和普通浏览流量是一样的。那么如何防御呢？下节会告诉你答
案。

 请求频率限制

不得不说，很多防CC的措施是直接在请求频率上做限制来实现的，但是，很多都存在着一定的问题。

那么是哪些问题呢？

首先，如果通过IP来限制请求频率，容易导致一些误杀，比如我一个地方出口IP就那么几个，而访问者一多的话，请求频率很容易到上限，那么那个地方的用户就都访问不了你的网站了。

于是你会说，我用SESSION来限制就有这个问题了。嗯，你的SESSION为攻击者敞开了一道大门。为什么呢？看了上文的你可能已经大致知道了，因为
就像那个“红包拿来”的扬声器一样，很多语言或者框架中的SESSION是能够伪造的。以PHP为例，你可以在浏览器中的cookie看到
PHPSESSIONID，这个ID不同的话，session也就不同了，然后如果你杜撰一个PHPSESSIONID过去的话，你会发现，服务器也认可
了这个ID，为这个ID初始化了一个会话。那么，攻击者只需要每次发完包就构造一个新的SESSIONID就可以很轻松地躲过这种在session上的请
求次数限制。

那么我们要如何来做这个请求频率的限制呢？

首先，我们先要一个攻击者无法杜撰的sessionID，一种方式是用个池子记录下每次给出的ID，然后在请求来的时候进行查询，如果没有的话，就拒绝请
求。这种方式我们不推荐，首先一个网站已经有了session池，这样再做个无疑有些浪费，而且还需要进行池中的遍历比较查询，太消耗性能。我们希望的是
一种可以无状态性的sessionID，可以吗？可以的。

rewrite_by_lua '

    local random = ngx.var.cookie_random

    if(random == nil) then
        random = math.random(999999)
    end

    local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)
    if (ngx.var.cookie_token ~= token) then
        ngx.header["Set-Cookie"] = {"token=" .. token, "random=" .. random}
        return ngx.redirect(ngx.var.scheme .. "://" .. ngx.var.host .. ngx.var.uri)
    end

';

大家是不是觉得好像有些眼熟？是的，这个就是上节的完美版的配置再加个随机数，为的是让同一个IP的用户也能有不同的token。同样的，只要有nginx的第三方模块提供散列和随机数功能，这个配置也可以不用lua直接用纯配置文件完成。

有了这个token之后，相当于每个访客有一个无法伪造的并且独一无二的token，这种情况下，进行请求限制才有意义。

由于有了token做铺垫，我们可以不做什么白名单、黑名单，直接通过limit模块来完成。

http{ ... limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s; }

然后我们只需要在上面的token配置后面中加入

limit_req zone=session_limit burst=5;

于是，又是两行配置便让nginx在session层解决了请求频率的限制。不过似乎还是有缺陷，因为攻击者可以通过一直获取token来突破请求频率限制，如果能限制一个IP获取token的频率就更完美了。可以做到吗？可以。

http{ ... limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s; limit_req_zone $binary_remote_addr $uri zone=auth_limit:3m rate=1r/m; }

location /{ limit_req zone=session_limit burst=5; rewrite_by_lua '
        local random = ngx.var.cookie_random
        if (random == nil) then
            return ngx.redirect("/auth?url=" .. ngx.var.request_uri)
        end
        local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)
        if (ngx.var.cookie_token ~= token) then
            return ngx.redirect("/auth?url=".. ngx.var.request_uri)
        end
    '; } location /auth { limit_req zone=auth_limit burst=1; if ($arg_url = "") { return 403; } access_by_lua '
            local random = math.random(9999)
            local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)
            if (ngx.var.cookie_token ~= token) then
                ngx.header["Set-Cookie"] = {"token=" .. token, "random=" .. random}
                return ngx.redirect(ngx.var.arg_url)
            end
        '; }

我想大家也应该已经猜到，这段配置文件的原理就是：把本来的发token的功能分离到一个auth页面，然后用limit对这个auth页面进行频率限制即可。这边的频率是1个IP每分钟授权1个token。当然，这个数量可以根据业务需要进行调整。

需要注意的是，这个auth部分我lua采用的是access_by_lua，原因在于limit模块是在rewrite阶段后执行的，如果在
rewrite阶段302的话，limit将会失效。因此，这段lua配置我不能保证可以用原生的配置文件实现，因为不知道如何用配置文件在
rewrite阶段后进行302跳转，也求大牛能够指点一下啊。

当然，你如果还不满足于这种限制的话，想要做到某个IP如果一天到达上限超过几次之后就直接封IP的话，也是可以的，你可以用类似的思路再做个错误页面，
然后到达上限之后不返回503而是跳转到那个错误页面，然后错误页面也做个请求次数限制，比如每天只能访问100次，那么当超过报错超过100次(请求错
误页面100次)之后，那天这个IP就不能再访问这个网站了。

于是，通过这些配置我们便实现了一个网站访问频率限制。不过，这样的配置也不是说可以完全防止了攻击，只能说让攻击者的成本变高，让网站的扛攻击能力变
强，当然，前提是nginx能够扛得住这些流量，然后带宽不被堵死。如果你家门被堵了，你还想开门营业，那真心没有办法了。

然后，做完流量上的防护，让我们来看看对于扫描器之类的攻击的防御。

防扫描

ngx_lua_waf模块

这个是一个不错的waf模块，这块我们也就不再重复造轮子了。可以直接用这个模块来做防护，当然也完全可以再配合limit模块，用上文的思路来做到一个封IP或者封session的效果。

本文旨在达到抛砖引玉的作用，我们并不希望你直接单纯的复制我们的这些例子中的配置，而是希望根据你的自身业务需要，写出适合自身站点的配置文件。另外这样做，会对爬虫不友好，需要特别处理！

转载：http://lcx.cc/?i=4041

Victoria has a wonderful outlook on life
quick weight loss the Deputy Editor of GQ

什么是CC攻击?CC攻击就是利用大量代理服务器对目标计算机发起大量连接，导致目标服务器资源枯竭造成拒绝服务。那么如何判断查询CC攻击呢?本文主要介绍了一些Linux下判断CC攻击的命令。

查看所有80端口的连接数

netstat -nat|grep -i “80″|wc -l

对连接的IP按连接数量进行排序

netstat -anp | grep ‘tcp\|udp’ | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -n

netstat -ntu | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -n

netstat -ntu | awk ‘{print $5}’ | egrep -o “[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}” | sort | uniq -c | sort -nr

查看TCP连接状态

netstat -nat |awk ‘{print $6}’|sort|uniq -c|sort -rn

netstat -n | awk ‘/^tcp/ {print $NF}’|sort|uniq -c|sort -rn

netstat -n | awk ‘/^tcp/ {++S[$NF]};END {for(a in S) print a, S[a]}’

netstat -n | awk ‘/^tcp/ {++state[$NF]}; END {for(key in state) print key,”\t”,state[key]}’

netstat -n | awk ‘/^tcp/ {++arr[$NF]};END {for(k in arr) print k,”\t”,arr[k]}’

netstat -ant | awk ‘{print $NF}’ | grep -v ‘[a-z]‘ | sort | uniq -c

查看80端口连接数最多的20个IP

cat /www/web_logs/waitalone.cn_access.log|awk ‘{print $1}’|sort|uniq -c|sort -nr|head -100

tail -n 10000 /www/web_logs/waitalone.cn_access.log|awk ‘{print $1}’|sort|uniq -c|sort -nr|head -100

cat /www/web_logs/waitalone.cn_access.log|awk ‘{print $1}’|sort|uniq -c|sort -nr|head -100

netstat -anlp|grep 80|grep tcp|awk ‘{print $5}’|awk -F: ‘{print $1}’|sort|uniq -c|sort -nr|head -n20

netstat -ant |awk ‘/:80/{split($5,ip,”:”);++A[ip[1]]}END{for(i in A) print A,i}’ |sort -rn|head -n20

用tcpdump嗅探80端口的访问看看谁最高

tcpdump -i eth0 -tnn dst port 80 -c 1000 | awk -F”.” ‘{print $1″.”$2″.”$3″.”$4}’ | sort | uniq -c | sort -nr |head -20

查找较多time_wait连接

netstat -n|grep TIME_WAIT|awk ‘{print $5}’|sort|uniq -c|sort -rn|head -n20

查找较多的SYN连接

netstat -an | grep SYN | awk ‘{print $5}’ | awk -F: ‘{print $1}’ | sort | uniq -c | sort -nr | more

linux下实用iptables封ip段的一些常见命令：

封单个IP的命令是：

iptables -I INPUT -s 211.1.0.0 -j DROP

封IP段的命令是：

iptables -I INPUT -s 211.1.0.0/16 -j DROP

iptables -I INPUT -s 211.2.0.0/16 -j DROP

iptables -I INPUT -s 211.3.0.0/16 -j DROP

封整个段的命令是：

iptables -I INPUT -s 211.0.0.0/8 -j DROP

封几个段的命令是：

iptables -I INPUT -s 61.37.80.0/24 -j DROP

iptables -I INPUT -s 61.37.81.0/24 -j DROP

想在服务器启动自运行的话有三个方法：

1、把它加到/etc/rc.local中

2、iptables-save >/etc/sysconfig/iptables可以把你当前的iptables规则放到/etc/sysconfig/iptables中，系统启动iptables时自动执行。

3、service iptables save 也可以把你当前的iptables规则放/etc/sysconfig/iptables中，系统启动iptables时自动执行。

后两种更好此，一般iptables服务会在network服务之前启来，更安全。

解封的话：

iptables -D INPUT -s IP地址 -j REJECT

iptables -F 全清掉了

转载自：http://netsecurity.51cto.com/art/201305/393377.htm

6 natural green manner labeling
quick weight loss 4 men’s fashion trends for Winter 2013