Mazhechao

一家技术创业公司，初创团队全部是技术背景，他们面对最大的挑战是什么？ By 刘少壮

netsniff-ng is is a free, performant Linux network sniffer for packet inspection. The gain of performance is reached by 'zero-copy' mechanisms, so that the kernel does not need to copy packets from kernelspace to userspace. For this purpose netsniff-ng is libpcap independent, but nevertheless supports the pcap file format for capturing, replaying and performing offline-analysis of pcap dumps. netsniff-ng can be used for protocol analysis, reverse engineering and network debugging.

 

看不到图的请点击这里：

http://mp.weixin.qq.com/mp/appmsg/show?__biz=MjM5NzA4ODc0MQ==&appmsgid=10000410&itemidx=1&sign=eaabd0c9ad2a30756e3ccb7979fc0d38#wechat_redirect 

 

前天请大家推荐一些鲜有人知的度假、旅游胜地，然后说好今天整理大家的推荐。之所以是今天贴出来，是因为我昨天在高铁上，不方便整理。

 

我可不是出门玩去了，也不是回杭州了，我是回武汉了。老婆孩子目前都在武汉娘家呢，这次回来就是接她们去北京的，周一、周二我会开两天的高速，开车很辛苦，想来也是不能更新了。预计下周会很忙，因为周四、周五还要去内蒙参加国家互联网应急中心召开的年会，所以我只能说，如果我在内蒙吃到好吃的羊肉串了，一定会告诉你们！

 

另外还有一件事情要告诉大家，想必大家也都看见了，今天一次更新了两篇文章。我决定开辟一个叫“黑客讲坛”的小栏目，用来发表一些黑客技术相关的有趣的小文章，接受白帽子、黑帽子们的投稿，你们可以在这里获得一个展示自己想法的舞台。“黑客讲坛”将不定期发布，有就发，没有就不发。

 

—— 我是万恶的分割线 ——

 

请大家推荐一些小众的好玩的地方后，发现大多数朋友都只回复了一个地名或一句话，我看到后傻眼了。然后决定根据我自己的直觉，筛选一部分，并到网上为每个我筛选出来的地方，找一张照片。因为篇幅有限，肯定会有些朋友推荐的地方没有写到，敬请谅解。如果你坚持认为自己推荐的地方很棒，不应该漏掉，也可以再给我发消息，并最好附上一张照片。

 

下面是我筛选出来的地方，还是我自己先开始吧。

 

国内：

 

@道哥：

青海的祁连镇。

 

同样是我在08年环青海湖时路过，在镇上歇了一夜。当时主要是冲着它的牛心山（又称阿米东嗦）去的，在镇上的旅馆推开窗就能看到这座神山，周边的旅游资源也很丰富。但镇上的旅游业却并不发达，或者说根本没怎么好好开发过。

 

@杨廷峰：

新疆的江布拉克、科桑溶洞。

 

感受与内地不一样的天山风光。

@王资寒

拍摄于北京延庆，去年十月半。

 

@小龙chawu

贵州镇远古镇。

 

相比其他古镇它处于西部，商业化缓慢而更真实；舞阳河穿城而过，水质真的是碧绿；盛夏的夜晚还可悠闲坐在河边一边享受着爽爽贵州天气一边品尝风味独特的美食；顺道看看西江千户苗寨。欢迎道哥来贵州做客。

@k

广东台山的上下川岛（上和下两个），国家四星级旅游胜地，东方夏威夷，本人就是台山的，推荐一下……

 

@凝望

鲁朗小镇。

 

骑过滇藏川藏线的骑友都知道，很美很宁静的一个小镇。现在正在开发成国际小镇，建议趁早去，之后人多了环境也该变味了。

 

@幸福羊头

推荐云南的喜洲。

 

没有开发过度，近洱海，有个朋友在那儿待了一个月舍不得走。民风朴实，有个老外开的客栈很出名，还上过杂志。

 

@李智

新疆博尔塔拉的赛里木湖，高山湖泊，湖水清澈见底，湖周围青山环抱。湖边牛羊成群，最好的季节是6月份，是那里的春天，一个花开季节，漫山遍野的都是野花，最重要的那是我的家乡。

 

@风扬水浪

新疆的赛里木湖，不是特别小众，但也并不太热门，我觉得比新疆最有名的喀纳斯湖更美。雪山、湖水、草原还有成群的牛羊，美极了。只是我是十年前去的，听说现在破坏很严重，如果真是，那太遗憾了！

 

 

@晓辉

广东省始兴县是中国最美小城之一，特美，真心值得前往，去了才知道什么叫山清水秀

 

@钰

搁船尖。

 

安徽黄山市歙县金川乡，能看到我生平最大最美的夕阳和最近的星星

 

@小贤

青海互助北山森林地质公园。

 

山好，水好，有瀑布，无污染，人很少，可以露营，也有农家。喝点青海酸奶和青稞酒。

 

@charles

七藏沟。

 

就在九寨沟附近，海拔平均3500~4500，有几个很漂亮的海子，是一条很好的3~5天徒步路线，如果你想腐败就包马队进沟，不用自己背帐篷了。最关键是没人，我去年十一去的，一山之隔的九寨沟都爆仓了，这边恍如无人区。

 

@Young

东极岛。

 

在舟山，避世圣地。看海垂钓吹风在爽不过来了，估计不久后就会成为下一个鼓浪屿。顺便说句，岛上石屋群很多，很多屋主都想卖，问了下价格整屋30万~  海景房哦~

 

—— 我是万恶的分割线 ——

 

编辑这些景点的资料累死道哥了，和重新做一遍攻略没什么区别。

 

为避免图片太多，流量太大，国内篇就先整理这些吧。下次送上国外篇。

 

今天的题图是一个叫“乱海子”的地方，也是我08年环青海湖时拍的。

请大家推荐这些地方，是因为我关注过知乎上一个类似的问题，点击“阅读原文”可以查看知乎上的这个话题：你去过哪些不出名但很棒的地方？

http://www.zhihu.com/question/20372253

如果本文有帮助，可点击右上角分享。

 

=== 道哥的黑板报，微信ID：taosay ===

 

微博（新浪、腾讯）ID：aullik5

 

交流、提问可直接回复消息。

回复m查看推荐文章。

所有文章地址：http://taosay.net

下厨房是国内知名的美食社区，在Alexa的全球排名达到6,469，国内排名为769，国内注册用户160多万人。6月26日，由于技术人员操作失误，导致近两个月数据丢失，到昨天为止，他们找回了99%丢失的数据。技术团队在他们的博客上分析了本次事故的经过。 By 郑柯

 

过去的两天在开高速，从武汉到北京，开了将近1200公里，旅途劳顿，所以没有更新黑板报。之前的文章里提到过这件事情，可能很多朋友没看到，所以后台收到不少消息，问道哥出啥事了。

 

幸运的是旅途上一路平安。我带着三个女人：老婆、女儿、老妈，在濮阳歇了一晚，第二天下午抵达北京。路上没遇上大雨也没遇上车祸，只见到了几个爆胎的车辆，我都小心的绕过了。

 

濮阳当地民风淳朴，路面也很干净，让我们眼前一亮。当地物价也非常低，点了一大桌子菜人均才30，而我昨天在北京的晚餐，人均则到了60。同样的，我住在濮阳当地的速8酒店，标间一晚是100元整，而在北京中关村地带，速8酒店同样的房间却要300。

 

在濮阳的一晚，小城市生活的慢节奏和幸福感油然而生。在北京这样的大城市，你很难感受到这种幸福感。这与赚钱多少无关，只与城市的大小和生活环境有关。

 

我前些天去探望了一位长辈，他所住的小城市是湖南的一个小县城。他跟我说，他始终觉得还是家乡好。以前也去外面闯荡过，但在哪里都住不习惯，最后还是回了老家，陪在年迈的父母身边，现在过的很好。他有很多同学，也是在广州、深圳创业，很辛苦，赚到了钱，但却没有幸福感。有一次他在老家请一位同学吃饭，同学说：老家真好，真幸福，但自己已经停不下来了。

 

我觉得我和他这位同学的处境真的很相似：在外闯荡，追求事业，很忙碌，心中向往平静的生活，但却已经停不下来了。

 

他问我以后会不会回湖南老家生活，他认为我还是应该回去。我笑着摇了摇头，什么都没有说。

 

老家的互联网行业并不发达，这也是我为什么从杭州举家迁来北京的一个原因。从事互联网行业，如果没有在北京工作个几年，仿佛就像是在美国从事互联网行业，却没有去硅谷工作过一样，心中总会留下些许遗憾。

 

我大四毕业时，当时最想去的公司，是北京的绿盟，当时绿盟汇聚了这个行业里最出色的安全专家，是所有从事信息安全行业的应届毕业生心中的圣地。但我还没来得及投出简历，就收到了阿里的一份不错的Offer，征求父母的意见后，就来了杭州。

 

我当时并不知道这个选择对我来说意味着什么，也许父母也不知道，他们也不懂阿里是一家什么样的公司，他们在意的只是我找到了一份不错的工作，他们心满意足了。但我知道，我错过了北京，而且没想到这一错过，就是7年。

 

后来我在杭州买了房，算是把家安在了杭州。但我却并不认为一套房子就能约束住我，因为在杭州，除了阿里外，选择并不多。我知道我迟早有一天会离开阿里，那就意味着可能会离开杭州。

 

我最终还是来北京了。这个选择对我的家人来说是一个巨大的变化。都说由俭入奢易，由奢入俭难，我这么折腾的抛弃了在杭州宽敞而舒适的房子，拖家带口的挤在北京的一个租来的房子里，女儿才几个月大，老婆不甚满意。

 

北京这个城市太大了，大到每个人都会觉得自己活的很渺小。

 

现在每天上下班都要花两个小时在地铁上，在老家的长辈则是开车20分钟到单位都会嫌路太长。北京的气候干燥，空气污染严重，我两个月前刚来时，鼻腔粘膜就破裂了，而一回杭州，当天就好了。

 

我把车开来了北京，但杭州牌照的车在工作日却几乎没法在市内开。进城的那天我刚好限行，一路上都像做贼一样担心会被交警拦下，当时心里特不痛快，想着老子开了一千多公里来北京，你要罚就罚吧，老子进定城了！北京在第一天就开始对外地人摆出了一副排斥的嘴脸。

 

北京并不适合生活，但北京的社会资源和客户资源都非常丰富，无论想做什么都更容易做大。正如我前些时去街边理发，发现一家小小的理发店，居然也有能力做自己的模特T台秀和宣传片，这在小城市是很难想象的事情。

 

但我仍然没有爱上北京这个城市，也许北京只会是我生命中的一个驿站。

 

至于未来？想过，但没在意过。规划太长远的未来没有意义，因为变化太多、太快。走一步，看一步更适合人生的节奏。

 

谁知道十年后我会在哪儿呢！

 

如果本文有帮助，可点击右上角分享。

 

=== 道哥的黑板报，微信ID：taosay ===

 

微博（新浪、腾讯）ID：aullik5

 

交流、提问可直接回复消息。

回复m查看推荐文章。

所有文章地址：http://taosay.net

同态加密允许对密文进行特定的代数运算得到仍然是加密的结果，与对明文进行同样的运算再将结果加密一样。这项技术可以在加密的数据中进行检索、比较等操作，整个处理过程中无需对数据进行解密。同态加密技术从根本上解决将数据及其操作委托给第三方时的保密问题。2009年9月Craig Gentry发表论文从数学上提出了“全同态加密”的可行方法，朝正确方向前进了一步，但问题是同态加密非常低效，需要密集计算。过去几年的一系列改进让同态加密在合适的情况下具有实用性。现在，IBM T J Watson研究中心的Victor Shoup和Shai Halevi发布了开源的C++同态加密库，代码托管在 Github上，采用GPL许可证。同态加密库整合了大量优化，使对密文的操作运行速度更快。

HI:)

今天夜里，我们开放知道创宇的研发技能表，这个Checklist里大体总结了在知道创宇做研发工作所需具备的技能，包括我们的安全研究员。这份技能表给出了许多的“点”，而“面”需要靠自己，否则如何证明自己具备牛逼的学习能力？

技能都样样掌握好的没多少，大家基本都是覆盖面广，而有自己的专长，有如三国杀里每个角色都有自己的专长技能:)

我一直保持一种信念：以一人之力，挑起大梁。这在工作中非常有利，我能够在工作上反应迅速，有不足的，很快能跟上，我崇尚Geek的能量，在我眼里，Geek必须具备创造性，如果一个人的技能太过狭隘，是不可能具备创造性，只能跟在别人之后，同时，这样的人不可能在一个足够牛逼的团队里，这个团队也不可能形成令人羡慕的工程师文化！

我经历过前两年的几个小失败教训后，我深刻意识到一个团队必须拥有一流素质的人才，这样才能防止笨蛋爆炸，二流的人不太可能招到一流的人，有时候我会遐想那些海盗般的小团队，这样团队的作战能力是非常强悍的，这样的团队在业务上创造的价值非常大，团队里的每个人都是多面手，而且具备绝好的职业素养。

在工作上，职业素养太关键了。

这份技能表分了两大块：通用技能+专业技能。

通用技能也是我上面说的“职业素养”，这个在任何有Geek文化、有人性的公司里都适用，这样的公司不太可能形成所谓的“厚黑学”文化，如果这样搞，真的就离死亡不远了。如果你是有抱负的人，赶紧从这样的公司里离开吧。

专业技能是我们技术层面上的技能，掌握这些技术，能在我们这样的团队里吃得很香，当然在其他很多团队也行，毕竟：它们都是通的:)

我希望这次发布了这个比较完整的技能表后，喜欢知道创宇，想加入我们的同学能深刻地悟悟，如果你做到了，我相信你会超越很多很多人。

即使不加入我们也没事，希望这样的技能表发布后，能让更多人少走些弯路，不要让自己在如此激烈的竞争中被淘汰，或者一直是埋没。

08年的时候，我们公司还是小团队的时候，我们都有个别名：

西盟吹雪
东方海啸
欧阳余弦
上官丹
慕容堃
司马虎
独孤老杨
南宫晶
诸葛小记
皇甫小皓
太叔埃希
瑞木严川
公孙帅
夏侯凯
令狐潘

有2个同学已经离开我们了，祝福他们:)，剩下的，这么多年，我们团队已经比较大了，知道创宇的文化从创始者：ic/yang等开始，到我们几个，奠基着非常好，这两年又吸收了各路猛将！他们坚守在广州、上海、成都、香港等地，为了一股气，这股气很霸道:)

技能表：

http://blog.knownsec.com/Knownsec_RD_Checklist/v2.1.html

本文由知道创宇安全研究团队-余弦撰写。

-------------------------分割线--------------------------

这里的文章会首发在我们的官方微信：网站安全中心（ID：wangzhan_anquan）。我们会持续性的进行安全科普，大家有什么问题可以在微信里给我们留言，我们会认真对待每份留言，并在下次发文时进行必要的解答。如果大家有什么安全八卦也欢迎投稿给我们。

HTTP stands for Hypertext Transfer Protocol. It’s a stateless, application-layer protocol for communicating between distributed systems, and is the foundation of the modern web. As a web developer, we all must have a strong understanding of this protocol.

Let’s review this powerful protocol through the lens of a web developer. We’ll tackle the topic in two parts. In this first entry, we’ll cover the basics and outline the various request and response headers. In the follow-up article, we’ll review specific pieces of HTTP – namely caching, connection handling and authentication.

Although I’ll mention some details related to headers, it’s best to instead consult the RFC (RFC 2616) for in-depth coverage. I will be pointing to specific parts of the RFC throughout the article.

---

HTTP Basics

HTTP allows for communication between a variety of hosts and clients, and supports a mixture of network configurations.

To make this possible, it assumes very little about a particular system, and does not keep state between different message exchanges.

This makes HTTP a stateless protocol. The communication usually takes place over TCP/IP, but any reliable transport can be used. The default port for TCP/IP is 80, but other ports can also be used.

Custom headers can also be created and sent by the client.

Communication between a host and a client occurs, via a request/response pair. The client initiates an HTTP request message, which is serviced through a HTTP response message in return. We will look at this fundamental message-pair in the next section.

The current version of the protocol is HTTP/1.1, which adds a few extra features to the previous 1.0 version. The most important of these, in my opinion, includes persistent connections, chunked transfer-coding and fine-grained caching headers. We’ll briefly touch upon these features in this article; in-depth coverage will be provided in part two.

URLs

At the heart of web communications is the request message, which are sent via Uniform Resource Locators (URLs). I’m sure you are already familiar with URLs, but for completeness sake, I’ll include it here. URLs have a simple structure that consists of the following components:

The protocol is typically http, but it can also be https for secure communications. The default port is 80, but one can be set explicitly, as illustrated in the above image. The resource path is the local path to the resource on the server.

Verbs

There are also web debugging proxies, like Fiddler on Windows and Charles Proxy for OSX.

URLs reveal the identity of the particular host with which we want to communicate, but the action that should be performed on the host is specified via HTTP verbs. Of course, there are several actions that a client would like the host to perform. HTTP has formalized on a few that capture the essentials that are universally applicable for all kinds of applications.

These request verbs are:

• GET: fetch an existing resource. The URL contains all the necessary information the server needs to locate and return the resource.
• POST: create a new resource. POST requests usually carry a payload that specifies the data for the new resource.
• PUT: update an existing resource. The payload may contain the updated data for the resource.
• DELETE: delete an existing resource.

The above four verbs are the most popular, and most tools and frameworks explicitly expose these request verbs. PUT and DELETE are sometimes considered specialized versions of the POST verb, and they may be packaged as POST requests with the payload containing the exact action: create, update or delete.

There are some lesser used verbs that HTTP also supports:

• HEAD: this is similar to GET, but without the message body. It’s used to retrieve the server headers for a particular resource, generally to check if the resource has changed, via timestamps.
• TRACE: used to retrieve the hops that a request takes to round trip from the server. Each intermediate proxy or gateway would inject its IP or DNS name into the Via header field. This can be used for diagnostic purposes.
• OPTIONS: used to retrieve the server capabilities. On the client-side, it can be used to modify the request based on what the server can support.

Status Codes

With URLs and verbs, the client can initiate requests to the server. In return, the server responds with status codes and message payloads. The status code is important and tells the client how to interpret the server response. The HTTP spec defines certain number ranges for specific types of responses:

1xx: Informational Messages

All HTTP/1.1 clients are required to accept the Transfer-Encoding header.

This class of codes was introduced in HTTP/1.1 and is purely provisional. The server can send a Expect: 100-continue message, telling the client to continue sending the remainder of the request, or ignore if it has already sent it. HTTP/1.0 clients are supposed to ignore this header.

2xx: Successful

This tells the client that the request was successfully processed. The most common code is 200 OK. For a GET request, the server sends the resource in the message body. There are other less frequently used codes:

• 202 Accepted: the request was accepted but may not include the resource in the response. This is useful for async processing on the server side. The server may choose to send information for monitoring.
• 204 No Content: there is no message body in the response.
• 205 Reset Content: indicates to the client to reset its document view.
• 206 Partial Content: indicates that the response only contains partial content. Additional headers indicate the exact range and content expiration information.

3xx: Redirection

404 indicates that the resource is invalid and does not exist on the server.

This requires the client to take additional action. The most common use-case is to jump to a different URL in order to fetch the resource.

• 301 Moved Permanently: the resource is now located at a new URL.
• 303 See Other: the resource is temporarily located at a new URL. The Location response header contains the temporary URL.
• 304 Not Modified: the server has determined that the resource has not changed and the client should use its cached copy. This relies on the fact that the client is sending ETag (Enttity Tag) information that is a hash of the content. The server compares this with its own computed ETag to check for modifications.

4xx: Client Error

These codes are used when the server thinks that the client is at fault, either by requesting an invalid resource or making a bad request. The most popular code in this class is 404 Not Found, which I think everyone will identify with. 404 indicates that the resource is invalid and does not exist on the server. The other codes in this class include:

• 400 Bad Request: the request was malformed.
• 401 Unauthorized: request requires authentication. The client can repeat the request with the Authorization header. If the client already included the Authorization header, then the credentials were wrong.
• 403 Forbidden: server has denied access to the resource.
• 405 Method Not Allowed: invalid HTTP verb used in the request line, or the server does not support that verb.
• 409 Conflict: the server could not complete the request because the client is trying to modify a resource that is newer than the client’s timestamp. Conflicts arise mostly for PUT requests during collaborative edits on a resource.

5xx: Server Error

This class of codes are used to indicate a server failure while processing the request. The most commonly used error code is 500 Internal Server Error. The others in this class are:

• 501 Not Implemented: the server does not yet support the requested functionality.
• 503 Service Unavailable: this could happen if an internal system on the server has failed or the server is overloaded. Typically, the server won’t even respond and the request will timeout.

Request and Response Message Formats

So far, we’ve seen that URLs, verbs and status codes make up the fundamental pieces of an HTTP request/response pair.

Let’s now look at the content of these messages. The HTTP specification states that a request or response message has the following generic structure:

message = <start-line>
          *(<message-header>)
          CRLF
          [<message-body>]

<start-line> = Request-Line | Status-Line 
<message-header> = Field-Name ':' Field-Value

It’s mandatory to place a new line between the message headers and body. The message can contain one or more headers, of which are broadly classified into:

• general headers: that are applicable for both request and response messages.
• request specific headers.
• response specific headers.
• entity headers.

The message body may contain the complete entity data, or it may be piecemeal if the chunked encoding (Transfer-Encoding: chunked) is used. All HTTP/1.1 clients are required to accept the Transfer-Encoding header.

General Headers

There are a few headers (general headers) that are shared by both request and response messages:

general-header = Cache-Control            
               | Connection        
               | Date              
               | Pragma            
               | Trailer           
               | Transfer-Encoding 
               | Upgrade           
               | Via               
               | Warning

We have already seen some of these headers, specifically Via and Transfer-Encoding. We will cover Cache-Control and Connection in part two.

The status code is important and tells the client how to interpret the server response.

• Via header is used in a TRACE message and updated by all intermittent proxies and gateways
• Pragma is considered a custom header and may be used to include implementation-specific headers. The most commonly used pragma-directive is Pragma: no-cache, which really is Cache-Control: no-cache under HTTP/1.1. This will be covered in Part 2 of the article.
• The Date header field is used to timestamp the request/response message
• Upgrade is used to switch protocols and allow a smooth transition to a newer protocol.
• Transfer-Encoding is generally used to break the response into smaller parts with the Transfer-Encoding: chunked value. This is a new header in HTTP/1.1 and allows for streaming of response to the client instead of one big payload.

Entity headers

Request and Response messages may also include entity headers to provide meta-information about the the content (aka Message Body or Entity). These headers include:

entity-header  = Allow                    
               | Content-Encoding  
               | Content-Language  
               | Content-Length    
               | Content-Location  
               | Content-MD5       
               | Content-Range     
               | Content-Type      
               | Expires           
               | Last-Modified  

All of the Content- prefixed headers provide information about the structure, encoding and size of the message body. Some of these headers need to be present if the entity is part of the message.

The Expires header indicates a timestamp of whent he entity expires. Interestingly, a “never expires” entity is sent with a timestamp of one year into the future. The Last-Modified header indicates the last modification timestamp for the entity.

Custom headers can also be created and sent by the client; they will be treated as entity headers by the HTTP protocol.

This is really an extension mechanism, and some client-server implementations may choose to communicate specifically over these extension headers. Although HTTP supports custom headers, what it really looks for are the request and response headers, which we cover next.

Request Format

The request message has the same generic structure as above, except for the request line which looks like:

Request-Line = Method SP URI SP HTTP-Version CRLF
Method = "OPTIONS"
       | "HEAD"  
       | "GET"  
       | "POST"  
       | "PUT"  
       | "DELETE"  
       | "TRACE"

SP is the space separator between the tokens. HTTP-Version is specified as “HTTP/1.1″ and then followed by a new line. Thus, a typical request message might look like:

GET /articles/http-basics HTTP/1.1
Host: www.articles.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Note the request line followed by many request headers. The Host header is mandatory for HTTP/1.1 clients. GET requests do not have a message body, but POST requests can contain the post data in the body.

The request headers act as modifiers of the request message. The complete list of known request headers is not too long, and is provided below. Unknown headers are treated as entity-header fields.

request-header = Accept                   
               | Accept-Charset    
               | Accept-Encoding   
               | Accept-Language   
               | Authorization     
               | Expect            
               | From              
               | Host              
               | If-Match          
               | If-Modified-Since 
               | If-None-Match     
               | If-Range          
               | If-Unmodified-Since
               | Max-Forwards       
               | Proxy-Authorization
               | Range              
               | Referer            
               | TE                 
               | User-Agent

The Accept prefixed headers indicate the acceptable media-types, languages and character sets on the client. From, Host, Referer and User-Agent identify details about the client that initiated the request. The If- prefixed headers are used to make a request more conditional, and the server returns the resource only if the condition matches. Otherwise, it returns a 304 Not Modified. The condition can be based on a timestamp or an ETag (a hash of the entity).

Response Format

The response format is similar to the request message, except for the status line and headers. The status line has the following structure:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

• HTTP-Version is sent as HTTP/1.1
• The Status-Code is one of the many statuses discussed earlier.
• The Reason-Phrase is a human-readable version of the status code.

A typical status line for a successful response might look like so:

HTTP/1.1 200 OK

The response headers are also fairly limited, and the full set is given below:

 response-header = Accept-Ranges
                 | Age
                 | ETag              
                 | Location          
                 | Proxy-Authenticate
                 | Retry-After       
                 | Server            
                 | Vary              
                 | WWW-Authenticate

• Age is the time in seconds since the message was generated on the server.
• ETag is the MD5 hash of the entity and used to check for modifications.
• Location is used when sending a redirection and contains the new URL.
• Server identifies the server generating the message.

It’s been a lot of theory upto this point, so I won’t blame you for drowsy eyes. In the next sections, we will get more practical and take a survey of the tools, frameworks and libraries.

---

Tools to View HTTP Traffic

There are a number of tools available to monitor HTTP communication. Here, we list some of the more popular tools.

Undoubtedly, the Chrome/Webkit inspector is a favorite amongst web developers:

There are also web debugging proxies, like Fiddler on Windows and Charles Proxy for OSX. My colleague, Rey Bango wrote an excellent article on this topic.

For the command line, we have utilities like curl, tcpdump and tshark for monitoring HTTP traffic.

---

Using HTTP in Web Frameworks and Libraries

Now that we have looked at the request/response messages, it’s time that we learn how libraries and frameworks expose it in the form of an API. We’ll use ExpressJS for Node, Ruby on Rails, and jQuery Ajax as our examples.

ExpressJS

If you are building web servers in NodeJS, chances are high that you’ve considered ExpressJS. ExpressJS was originally inspired by a Ruby Web framework, called Sinatra. As expected, the API is also equally influenced.

Because we are dealing with a server-side framework, there are two primary tasks when dealing with HTTP messages:

• Read URL fragments and request headers.
• Write response headers and body

Understanding HTTP is crucial for having a clean, simple and RESTful interface between two endpoints.

ExpressJS provides a simple API for doing just that. We won’t cover the details of the API. Instead, we will provide links to the detailed documentation on ExpressJS guides. The methods in the API are self-explanatory in most cases. A sampling of the request-related API is below:

• req.body: get the request body.
• req.query: get the query fragment of the URL.
• req.originalUrl
• req.host: reads the Host header field.
• req.accepts: reads the acceptable MIME-types on the client side.
• req.get OR req.header: read any header field passed as argument.

On the way out to the client, ExpressJS provides the following response API:

• res.status: set an explicit status code.
• res.set: set a specific response header.
• res.send: send HTML, JSON or an octet-stream.
• res.sendFile: transfer a file to the client.
• res.render: render an express view template.
• res.redirect: redirect to a different route. Express automatically adds the default redirection code of 302.

Ruby on Rails

The request and response messages are mostly the same, except for the first line and message headers.

In Rails, the ActionController and ActionDispatch modules provide the API for handling request and response messages.

ActionController provides a high level API to read the request URL, render output and redirect to a different end-point. An end-point (aka route) is handled as an action method. Most of the necessary context information inside an action-method is provided via the request, response and params objects.

• params: gives access to the URL parameters and POST data.
• request: contains information about the client, headers and URL.
• response: used to set headers and status codes.
• render: render views by expanding templates.
• redirect_to: redirect to a different action-method or URL.

ActionDispatch provides fine-grained access to the request/response messages, via the ActionDispatch::Request and ActionDispatch::Response classes. It exposes a set of query methods to check the type of request (get?(), post?(), head?(), local?()). Request headers can be directly accessed via the request.headers() method.

On the response side, it provides methods to set cookies(), location=() and status=(). If you feel adventurous, you can also set the body=() and bypass the Rails rendering system.

jQuery Ajax

Because jQuery is primarily a client-side library, its Ajax API provides the opposite of a server-side framework. In other words, it allows you to read response messages and modify request messages. jQuery exposes a simple API via jQuery.ajax(settings):

By passing a settings object with the beforeSend callback, we can modify the request headers. The callback receives the jqXHR (jQuery XMLHttpRequest) object that exposes a method, called setRequestHeader() to set headers.

$.ajax({
    url: 'http://www.articles.com/latest',
    type: 'GET',
    beforeSend: function (jqXHR) {
      jqXHR.setRequestHeader('Accepts-Language', 'en-US,en');
    }
  });

• The jqXHR object can also be used to read the response headers with the jqXHR.getResponseHeader().
• If you want to take specific actions for various status codes, you can use the statusCode callback:

$.ajax({
  statusCode: {
    404: function() {
      alert("page not found");
    }
  }
});

---

Summary

So that sums up our quick tour of the HTTP protocol.

We reviewed URL structure, verbs and status codes: the three pillars of HTTP communication.

The request and response messages are mostly the same, except for the first line and message headers. Finally, we reviewed how you can modify the request and response headers in web frameworks and libraries.

Understanding HTTP is crucial for having a clean, simple, and RESTful interface between two endpoints. On a larger scale, it also helps when designing your network infrastructure and providing a great experience to your end users.

In part two, we’ll review connection handling, authentication and caching! See you then.

---

References

• HTTP specification
• HTTP Definitive Guide

【摘要】以前看过一点刘未鹏的文章，去年买了刘未鹏的《暗时间》，但是一直没看，最近睡觉前没什么可供催眠的闲书，就把它拿出来翻翻，恩，虽然基本都是以前博客上发表过的东西，但是看了还是有些启发的。1、这本书讲了什么？因为都是来自他的博客的文章，他说写博客的一个很重要的目的是帮自己进行总结，用文字记录当时的想法，反复提炼，以期获得新的东西。因此本书主要是介绍他自己看到的，想到的东西。2、印象较深的东西。有三点：（1）他在多篇文章中提到自己多年来养成的习惯，即“走路、吃饭也在想某个问题”，充分利用点滴时间。（看来他很看重这一点，所以书的名字才叫《暗时间》。）（2）关于好的论文的评价标准。次一点的论文只是告诉你. 阅读全文

//本文转载自http://www.wsmlby.info/wordpress/?p=54 ，欢迎大家到此页面上讨论！

作为一个铁杆Google 粉，先表个态： 就这样关闭Google Reader是Google重大的错误。但是抛去愤怒和失望，我觉得应该仔细想想这个事件背后的事情。

 

首先先听我从我寒假前的一个事情扯起。

 

话说我是一个非常喜欢为自己写工具的人.磨刀不误砍柴工。哪怕最后柴没砍到，可能已经搞出了好几套新版柴刀了。

作为大四学生，毕业论文是马上要面临的问题。

作为一个伪文艺Geek，写论文内容什么不重要，显然先要装X使用Latex. 可是寒假在即，回家又不想带电脑。如果只是用Word就直接放在Google Drive或者Dropbox里面然后回去同步一下就可以了。可是Latex的话，难道我回家在家里还要安装一套庞大的Latex? 出于很自然的想法，我在我的EC2服务器上写了一套在线Latex编译环境。登录自己的Dropbox，选择一个目录和一个.tex主文件，系统就会自己把整个目录下载下来并且编译然后返回一个PDF。

 

好了，这样一个在线（云）latex编译环境搭建好了。我可以用了。

可是如果别人也想用呢？

在这里我不会公布我开发的这个系统的网址。因为我的服务器太弱了扛不住大家去访问的。我使用的是Amazon的Ec2云服务，是按照计算能力付费的。本人穷Dios一个，买不起大服务器啊。

 

问题是，为什么我开发的系统我让大家用，我却要为大家使用的计算资源付费呢？

 

这是我要说的重点。

如果我是一家公司，并且我能为这套在线Latex编译环境找到一个商业模式，那没问题。但是我自己一个人写出来玩的东西，我根本没有将它变成一个能够盈利的玩意的抱负。说的绝一点，我自己做出来给自己用的，我自己觉得好就行了，为什么要让大家用呢？我基于分享精神放出来给大家用，我为什么还要为此付出代价呢？

 

好了，现在回到Google Reader事件上来。Google作为一家企业，花费人力物力去开发一个Google Reader这样的服务给大家用，已经算是仁至义尽了，为什么还要为大家使用的这大量的计算资源买单呢？

 

合理的情况是，开发者开发了这样一套云端软件，大家购买这样的软件并在自己/云端的服务器上运行，享用相应的结果，并为付出的计算资源付费。

 

要把这个问题讲清楚，我还是再扯点关于云计算的看法吧。

 

云计算

 

我一直认为，要理解云计算，最好的方式是把计算资源看做电力一样的资源来思考。

曾经，世界上只有很少的人能用上电，需要用电的人就得自己买一套发电机，然后为去买与这些发电机配套的电器。 后来，大家发现每人都来维护发电机太复杂了，而且不同发电机上配套的电器也不完全相同，实在很麻烦。于是大家就建起了发电厂，再后来有了电网，甚至很大规模的国家级电网。 电网可以由不同的几家公司运行，但是电器是通用的，大家也只需为用的电付费，而不需要再自己造发电机了。（虽然有的地方为了保证绝对可靠，自己也配备了临时的发电机，但没有人会长期使用自己发电机的。）

 

现在再想想云计算。计算资源（主要是CPU资源，也可以按照一定比例将带宽、存储等兑换过去）就像电，而应用就是电器。我们的个人计算机的处理能力相当有限，比如搜索或者Google Reader这样的服务，可能我们自己未必做的起（Reader也许做的起，但是GR对于天朝人民的价值应该不在于计算能力吧？大家懂的）。我们也需要有电厂，而这电厂就是各个云服务厂商。

 

现在说说Google Reader，像前面说的，应用/服务是电器，计算资源是电。 即使我们买了一台海尔冰箱，我们也没法要求海尔负担这个冰箱运行所需要的所有电能吧？ 然而我们在这件事情上不单要求 Google 开发的Reader型冰箱帮我们存好吃的冰淇淋，还要求Google 永远的为我们提供这些冰箱所需要的电力， 甚至还要求在整个这个过程中不许收费？！？！

 

好的我想现在说清我的观点， 杀掉Google Reader的，是不愿为此付费的用户们。 当然，Google 甚至根本就没有提供付费并保留这个服务的选项，这自然是Google的问题了。这是Google极大的战略失误，本身这可以成为Google重新定义互联网云服务产业的一个契机。

 

云服务应有的未来

现在设想这样一个情况。云服务厂商，Google/Amazon/Microsoft/And More，联合成立了一个平台，比如就叫做

银河系计算资源总公司

我们用 CPU小时 来作为度量计算资源的单位。不同的公司可以有不同的定价，就像不同地区电价可以不一样。这里我们假设每CPU小时1美元。

应用开发者开发出了一个应用。比如一个视频处理系统。这个系统每处理1小时的视频要消耗 2CPU小时 的计算资源。现在，应用开发者可以将这个服务发布，并且可以选择免费发布还是收费发布。

先说免费发布：

免费发布后，开发者自己和其他用户一样，如果想用这个服务，就从银河系计算资源总公司那里使用计算资源，并只需要为这些计算资源付费。每处理1小时的视频，用户只需要为自己占用的这 2CPU小时的 计算资源付出2美元的价格。

这样，开发者选择了免费发布，没有收益，但也没有损失。银河系计算资源总公司卖出了计算资源，有一定收益，所以银河系计算资源总公司会支持这样的模式。而用户，可以随时使用这样的服务，而并不需要长期维护这样计算资源所需要的硬件，对用户也是有利的。

更重要的优势是，即使每年只有一个人使用这样的服务，银河系计算资源总公司/开发者也不需要为此关闭这项服务。由于现在存储成本的急剧下降，加上一直以来服务代码本身所占用的存储都是很小的，存储这样的应用可以认为没有任何消耗。同时，整个服务的运行都在银河系计算资源总公司处，而且有使用服务的用户为服务直接支付费用，开发者完全没有任何压力（不像现在只要有一个人用为了不让他/她/它失望开发者都得维护整个服务器的运转）。

 

再说收费发布。

收费发布就更简单了。比如开发者发现为了让大家处理视频更方便，每天，他需要消耗1CPU小时的计算资源算出一些辅助数据。这样，免费发布的话开发者就亏了。

开发者可以选择每处理1小时的视频收取3美元。其中2美元像原来一样支付给银河系计算资源总公司，用于计算资源的使用。剩下的1美元，开发者可以和银河系计算资源总公司分成，比如云服务公司3%，开发者97%。 开发者拿这剩下的0.97美元，一部分作为均摊支付每天计算辅助数据的计算资源消耗，一部分就收到了自己的腰包。这样，开发者就更有动力去提供优质的服务，而银河系计算资源总公司也愿意配合开发者提供更优质服务来提高自己计算资源的销量。

更进一步，配合开发者银河系计算资源总公司完全可以通过技术手段计算出每个用户使用时的均摊部分的消耗，进而直接将这些算作用户的开销，这样即使开发者完全将这样的服务免费，这种有均摊的服务也是可以维持运转的。

 

这样的云计算，才是应有的模式。

 

有人一想说，不对啊。这样一来，本身免费的服务怎么都收费了呢？？？？？

讲一个故事吧：比如现在有了一家做搜索引擎的实验室，比如叫 MarcoHard， 他们开发了史无前例的NB搜索引擎Bang，它有非常NB的功能，可以知道宇宙生命以及一切的答案，但是每次搜索需要耗费1000CPU小时。

因为是一个实验室项目，没有盈利模式。 在以前，这样消耗大量计算资源而且没有盈利的服务我们是不会看到的。 但现在不一样，对于那些有需求的人来说，他们可以开始付费并使用这样的服务Bang It了！

后来，这群NB的人突然想到了一个NB的盈利模式。于是他们出来，组建了MarcoHard公司，并将服务费从$1000/次 直接调为0！也就是，搜索的所有CPU开销都由公司来出负担，而公司，开始卖广告了！

 

如果这个商业模式可行，那么人们得到的将是一套免费而且知道宇宙生命以及一切的答案的搜索引擎。

如果这个商业模式后来发现失败了，那么MarcoHard公司可以宣布停止运营Bang服务，而由于银河系计算资源总公司的存在，人们仍然可以以1000$/次的价格使用这样NB的搜索引擎。

更进一步，比电厂更好的是，银河系计算资源总公司 觉得可以每月给每人提供10CPU小时的免费配额。大家是不是更高兴了？ 更进一步，如果自己家里恰好有几台NB的机器，一直放着也是浪费，我们甚至可以把计算资源卖回给

银河系计算资源总公司！

这样的模式一旦存在，Google Reader这样的悲剧就可以不再发生了。而且这样的事情不是科幻，我们这一代就可以做到的。

 

欢迎大家讨论。

Concurrent股份有限公司是一家企业级大数据应用平台公司，该公司近期发布了Lingual，它是一个开源项目，它能够使Apache Hadoop上的大数据应用开发可以快速、简单地使用SQL。 By Boris Lublinsky (译者： 夏雪)

卡巴斯基实验室的安全研究人员报告发现了对西藏和维吾尔活动人士发动针对性攻击的Android木马。 3月24日，一位知名西藏活动人士的电子邮件帐户遭黑客入侵，攻击者随后向邮件联系人列表中的用户发动了钓鱼攻击，发送的钓鱼邮件包含了Android可执行附件（APK文件）。邮件正文伪装来自世界维吾尔代表大会（WUC），附件名称是“WUC's Conference.apk”。如果接收者安装了附件，其Android设备桌面上会出现名叫Conference的应用，启动该应用，会出现有关即将举行的WUC会议的信息（攻击者错误将世界的英文World拼写成了Word）。当受害者阅读信息的同时，木马会悄悄向命令控制服务器发送感染报告，然后开始收集信息，窃取联系人、呼叫日志、短信和地理位置数据。命令控制服务器所在的数据中心位于美国洛杉矶，托管公司叫Emagine Concept Inc，但机器运行的是中文配置的Windows Server 2003系统，其使用的域名DlmDocumentsExchange.com是在3月8日注册的，注册服务商是上海美橙科技信息发展有限公司。

浅谈Ddos攻击攻击与防御

EMail: jianxin#80sec.com
Site: http://www.80sec.com
Date: 2011-2-10
From: http://www.80sec.com/

[ 目录 ]
一 背景
二 应急响应
三 常见ddos攻击及防御
四 根源及反击
五 总结

一 背景

在前几天，我们运营的某网站遭受了一次ddos攻击，我们的网站是一个公益性质的网站，为各个厂商和白帽子之间搭建一个平台以传递安全问题等信息，我们并不清楚因为什么原因会遭遇这种无耻的攻击。因为我们本身并不从事这种类型的攻击，这种攻击技术一般也是比较粗糙的，所以讨论得比较少，但是既然发生了这样的攻击我们觉得分享攻击发生后我们在这个过程中学到得东西，以及针对这种攻击我们的想法才能让这次攻击产生真正的价值，而并不是这样的攻击仅仅浪费大家的时间而已。
另外，我们发现大型的企业都有遭受攻击的案例，但是大家遭受攻击之后的应对措施及学到的经验却分享都比较少，这导致各家都是自行的摸索经验，依然停留在一家企业对抗整个互联网的攻击的局面，而对于攻击者却是此次攻击针对你，下次攻击却是针对他了，而且攻击之后无论是技术还是资源都没有任何的损耗，这也是导致这种攻击频繁并且肆无忌惮的原因。
我们来尝试做一些改变：）

二 应急响应

在攻击发生后，第一个现象是我们的网站上不去了，但是依然可以访问到管理界面，我们登陆上去简单执行了命令：

netstat -antp

我们看到有大量的链接存在着，并且都是ESTABLISHED状态，正常状态下我们的网站访问量没有这么高，如果有这么高我们相信中国的信息安全就有希望了，对于这样的情况其实处理就比较简单，这是一次四层的攻击，也就是所有ip都是真实的，由于目前为止只是消耗了webserver的网络连接资源，所以我们只需要简单的将这些ip在网络层封禁就可以，很简单，用下面的命令即可：

for i in `netstat -an | grep -i ‘:80 ‘|grep ‘EST’ | awk ‘{print $5}’ | cut -d : -f 1 | sort | uniq -c | awk ‘{if($1 > 50) {print $2}}’`
echo $i
echo $i >> /tmp/banip
/sbin/iptables -A INPUT -p tcp -j DROP -s $i
done

然后作为计划任务一分钟执行一次即可，很快，iptables的封禁列表就充斥了大量的封禁ip，我们简单的统计了下连接数最大的一些ip发现都来自韩国。为了保证系统的性能，我们调大了系统的可接受的连接数以及对Nginx进行了每个连接能够进行的请求速率，系统于是恢复了正常的运行。
正常状态一直持续到第二天，但是到中午之后我们发现访问又出现了问题，网络很慢，使用ping发现大概出现了70%左右的丢包，在艰难的登陆到系统上之后，发现系统已经很少有TCP的正常连接，为了查明原因，我们对系统进行了抓包：

tcpdump -w tmp.pcap port not 22
tcpdump -r tmp.pcap -nnA

我们发现攻击已经从应用层的攻击调整到了网络层的攻击，大量的目标端口是80的udp和icmp包以极快的速度充满了网络，一个包大小大概在1k左右，这次占据的资源纯粹是带宽资源了，即使在系统上做限制也解决不了这个问题，不过也没有关系，对于网络层的问题我们可以在网络层上做限制，我们只需要在网络上把到达我们ip的非TCP的所有包如UDP和ICMP等协议都禁止掉即可，但是我们没有自己的服务器也缺乏对网络设备的控制权，目前是由工信部CERT提供支持的，由于临时无法协调进行相应的操作，后果如大家看到，我们的服务很慢，基本上停止了服务，在一段时间之后攻击者停止了攻击，服务才进行了恢复，很憋屈是么？但是同时我们得到了很多热心朋友的帮助，得到了更好的网络和服务器资源，在网络资源方面的能力得到了很大的提升，缓解了这方面的问题，这里对他们表示感谢。

三 常见ddos攻击及防御

继续秉承80sec的”Know it then hack it”，这里简单谈一下ddos攻击和防御方面的问题。ddos的全称是分布式拒绝服务攻击，既然是拒绝服务一定是因为某些原因而停止服务的，其中最重要的也是最常用的原因就是利用服务端方面资源的有限性，这种服务端的资源范围很广，可以简单的梳理一个请求正常完成的过程：

1 用户在客户端浏览器输入请求的地址
2 浏览器解析该请求，包括分析其中的dns以明确需要到达的远程服务器地址
3 明确地址后浏览器和服务器的服务尝试建立连接，尝试建立连接的数据包通过本地网络，中间路由最终艰苦到达目标网络再到达目标服务器
4 网络连接建立完成之后浏览器根据请求建立不同的数据包并且将数据包发送到服务器某个端口
5 端口映射到进程，进程接受到数据包之后进行内部的解析
6 请求服务器内部的各种不同的资源，包括后端的API以及一些数据库或者文件等
7 在逻辑处理完成之后数据包按照之前建立的通道返回到用户浏览器，浏览器完成解析，请求完成。

上面各个点都可以被用来进行ddos攻击，包括：

1 某些著名的客户端劫持病毒，还记得访问百度跳搜狗的事情么？：）
2 某个大型互联网公司发生的dns劫持事件，或者直接大量的dns请求直接攻击dns服务器，这里可以使用一些专业的第三方dns服务来缓解这个问题，如Dnspod
3 利用建立网络连接需要的网络资源攻击服务器带宽使得正常数据包无法到达如udp的洪水攻击，消耗前端设备的cpu资源以使得数据包不能有效转发如icmp和一些碎片包的洪水攻击，消耗服务器方建立正常连接需要的资源如syn flood或者就是占用大量的连接使得正常的连接无法发起，譬如这次的TCP flood
4 利用webserver的一些特点进行攻击，相比nginx来说，apache处理一个请求的过程就比较笨重。
5 利用应用程序内部的一些特性攻击程序内部的资源如mysql，后端消耗资源大的接口等等，这也就是传统意义上的CC攻击。

这里涉及到攻防的概念，但是实际上如果了解对方的攻击点和攻击手法，防御会变成简单的一个拼资源的过程，不要用你最弱的地方去抗人家最强的地方，应该从最合适的地方入手把问题解决掉，譬如在路由器等设备上解决应用层攻击就不是一个好的办法，同理，在应用层尝试解决网络层的问题也是不可能的，简单来说，目标是只让正常的数据和请求进入到我们的服务，一个完善的防御体系应该考虑如下几个层面：

1 作为用户请求的入口，必须有良好的dns防御
2 与你的价值相匹配的带宽资源，并且在核心节点上布置好应用层的防御策略，只允许你的正常应用的网络数据包能够进入，譬如封杀除了80以外的所有数据包
3 有支持你的服务价值的机器集群来抵抗应用层的压力，有必要的话需要将一个http请求继续分解，将连接建立的过程压力分解到其他的集群里，这里似乎已经有一般的硬件防火墙能做这个事情，甚至将正常的http请求解析过程都进行分解，保证到达后端的是正常的请求，剔除掉畸形的请求，将正常的请求的请求频度等行为进行记录和监控，一旦发生异常就在这里进行应用层的封杀

每个公司都有自己对自己价值的评估从而决定安全投入上的大小，每一次攻击也会涉及到利益的存在，正如防御因为种种原因譬如投入上的不足和实施过程中的不完美，有着天生的弱点一样，攻击也是有着天生的弱点的，因为每一次攻击涉及到不同的环节，每个环节都可能由不同水平的人完成，他所拥有的资源，他使用的工具和技术都不会是完美的，所以才有可能进行防御，另外，我相信进行DDOS攻击的人是一个固定的行业，会有一些固定的人群，对于其中使用的技术，工具，资源和利益链都是比较固定的，与之相对的是各个企业却缺乏相应的沟通，以个人企业对抗一个产业自然是比较困难，而如果每一个企业都能将自己遭受攻击时的经验分享出来，包括僵尸网络的大小及IP分布，攻击工具的特征，甚至有能力的可以去分析背后的利益点及操作者，那么每一次攻击都能让大家的整体防御能力上升，让攻击者的攻击能力有损失，我们很愿意来做这个事情。

四 根源及反击

我困惑的是一点，攻击我们并不能得到实际的好处为什么还是有人来攻击，而且听说其他公司都有被攻击的情况，我觉得有一点原因就是攻击我们的确得不到什么好处，但是实际上攻击者也并不损失什么，无论是资源上还是法律风险上，他不会因为一次攻击而损失太多，而相比之下，服务提供者损失的东西却太多了，这从经济学角度来讲就是不平衡的，我们处于弱势。
一般而言，的确对于作恶者是没有什么惩罚措施，但是这次，我们觉得我们是可以做一些事情的，我们尝试挖掘背后的攻击者，甚至清除这个僵尸网络。
首先这次攻击起源于应用层的攻击，所以所有的ip都是真实的，经过与CERT沟通，也发现这些ip都是韩国的，并且控制端不在国内，因为期间没有与国内有过通讯，即使在后面换成了udp+icmp的flood，但是依然是那些韩国的ip，这很有意思，正常情况下udp+icmp的数据包是可以伪造的，但是这里居然没有伪造，这在后面大概被我们证实了原因。
这些ip是真实存在的ip，而且这些ip肯定在攻击完我们之后一定依然跟攻击者保持着联系，而一般的联系方式因为需要控制的方便都是dns域名，既然如此，如果我们能挖掘到这个dns域名我们就可能间接的挖掘出真正幕后黑手在哪里。首先，我们迅速的找出了这次攻击ip中开放了80端口的机器，因为我们对80端口上的安全问题比较自信，应该很快可以获知这些ip背后的细节（80sec名称由来），我们发现大部分是一些路由器和一些web的vpn设备，我们猜测这次攻击的主要是韩国的个人用户，而个人用户的机器操作系统一般是windows所以在较高版本上发送数据包方面可能有着比较大的限制，这也解释了为什么即使是udp+icmp的攻击我们看到的大都是真实ip。发现这些路由设备之后我们尝试深入得更多，很快用一些弱口令譬如admin/admin登陆进去，果然全世界的网民都一样，admin/admin是天生的入口。
登陆进去一些路由之后我们发现这些路由器里面存在一个功能是设置自己的dns，这意味着这下面的所有dns请求都可以被定向到我们自己设置的dns服务器，这对于我们去了解内部网络的细节会很有用，于是我们建立了一个自己的dns服务器，并且开启了dns请求的日志功能以记录所有请求的细节。我们大约控制了20台路由器的dns指向，并且都成功重定向到我们自己的服务器。
剩下的就是简单的数据分析，在这之前我们可以对僵尸网络的控制域名做如下的猜测：

1 这个dns应该为了灵活的控制域名的缓存时间TTL一般不会特别长
2 这个dns应该是定期的被请求，所以会在dns请求里有较大的出现比例
3 这个dns应该是为了控制而存在的，所以域名不应该在搜索引擎以及其他地方获得较高的访问指数，这与2中的规则配合起来会比较好确定，是一个天生的矛盾。
4 这个dns应该在各个路由下面都会被请求

这些通过简单的统计就很容易得出答案，我们发现了一些3322的通用恶意软件域名但是发现它并不是我们需要的，因为只有少数机器去访问到，经过一些时间之后最后我们发现一个域名访问量与naver（韩国的一个门户）的访问量持平，workgroup001.snow****.net，看起来似乎对自己的僵尸网络管理很好嘛，大概有18台机器访问过这个域名，这个域名的主机托管在新加坡，生存时间TTL在1800也就是半小时，这个域名在所有的搜索引擎中都不存在记录，是一个韩国人在godady一年前才注册的，同时我们访问这个域名指向主机的3389，简单的通过5下shift就判断出它上面存在着一个典型的windows后门，似乎我们找到它了，不是么？经过后续的观察，一段时间后这个域名指向到了127.0.0.1，我们确信了我们的答案,workgroup001.snow****.net，看起来似乎对自己的僵尸网络管理很好嘛：）
这是一次典型的ddos攻击，攻击之后我们获得了参与攻击的主机列表和控制端的域名及ip，相信中国和韩国的cert对于清理这次的攻击源很有兴趣，我们是有一些损失，但是攻击者也有损失了（大概包括一个僵尸网络及一个控制端域名，甚至可能包括一次内部的法律调查），我们不再是不平等的了，不是么？

五 总结

正如一个朋友所讲的，所有的防御是不完美的正如攻击是不完美的一样，好的防御者在提升自己的防御能力趋于完美的同时也要善于寻找攻击者的不完美，寻找一次攻击中的漏洞，不要对攻击心生恐惧，对于Ddos攻击而言，发起一次攻击一样是存在漏洞的，如果我们都能够擅长利用其中的漏洞并且抓住后面的攻击者那么相信以后的ddos攻击案例将会减少很多，在针对目标发起攻击之前攻击者也会做更多的权衡，损失，利益和法律。