暗网搜索以及名字服务。Dark net search engine and naming system.

1. What?

Tor 和 I2P 都是目前最常用的低延迟匿名通信系统。

Deep Web: Internet not indexed by traditional search engines.

Dark Net: Private overlay network.

Dark Web: WWW hosted on Dark Nets.

1.1 Hidden Service Popularity

The goal in this post has been published to answer the following questions:

“Approximately how many hidden services are there?” “Approximately how much traffic of the Tor network is going to hidden services?”

2. Who?

Tor: United States Naval Research Laboratory

I2P: Small group of people spread around several continents

3. How?

3.1 Tor

1. Hidden Service (Bob) uses the first 10 bytes of the SHA-1 digest of an ASN.1 encoded version of the RSA public key become the identifier of the hidden service. for example, z.onion where z is the base-32 encoded identifier of the hidden service.
2. Bob chooses a small number of Tor relays as introduction points and establishes new introduction circuit to each one of them.
3. Bob uploads identifier of the hidden service, public key as well as its selected introduction points to the HSDir (Hidden service directory).
4. Alice wants to connect to Bob’s hidden service. She use the z.onion to compute the responsible HSDir and fetches relevant information advertised by the hidden service.
5. Alice learns the introduction points of the hidden service. Alice then selects a rendezvous point and tells the introduction point of her choice as well as DH key etc.
6. Introduction point tells Bob about the DH key parameters as well as the rendezvous point.
7. Bob connects to the rendezvous point and communicate with Alice.

3.2 I2P

I2P hidden service(eepsite) is claimed to be faster than Tor Hidden service. 建立过程也更加简单直接。

1. Hidden service (Bob) 在本地路由搭建匿名服务器
2. Bob 将 Hidden service 的密钥和名字(xyz.i2p)添加进主地址簿
3. 发布过程：Bob 将自己的eepsite的名称(xyz.i2p)和密钥加入到其它网站的I2P地址簿（比如stats.i2p 或no.i2p）
4. Bob 为其Hidden service 维护新的 inbound and outbound tunnel 并将该信息（lease set）告诉NetDB.
5. Alice 想要访问Bob, 如果Bob没有发布自己的eepsite地址，那么Alice将不知道Bob的xyz.i2p就是Bob，假设Alice从各个更新源处获取当前最新的地址簿。Alice则知道xyz.i2p就是Bob的路由，因此Alice从NetDB查找Bob的inbound tunnel.
6. Alice 从 outbound tunnel连接到Bob的inbound tunnel，双方进行通信。

database store message作用:

A delivery status message is sent back to the client router to inform it that the connection has been successful. The database store message, which contains the client’s leaseSet, is used by the server router to determine how to reach the client’s inbound tunnel. This is for optimization, eliminating the need for the server router to look up the netDB for the client’s leaseSet.

4. Tor Directory and I2P NetDB compare

The table below shows what we facilities we have in both network and how we called them in each system.

4.1 Tor Directories

In tor source code or/config.c there are a number of default directories:

These Directory Authorities are run by members of the Tor Project and by trusted outside individuals/groups.

4.2 I2P NetDB

NetDB contains just two types of data: router contact information (RouterInfos) and destination contact information (LeaseSets). Refer to [6] for more information.

5. Tor search engines

On surface web:

Ahmia.fi https://ahmia.fi (Ahmia.fi also works for I2P searches.)

Deep Search http://www.torchtorsearch.com

On deep webs:

duckduckgo http://3g2upl4pq6kufc4m.onion

grams http://grams7enufi7jmdl.onion

Torch http://xmh57jrzrnw6insl.onion/

Not Evil http://hss3uro2hsxfogfq.onion/

5.1 How to index for Hidden service?

Ahmia search engine [7] uses Elasticsearch to index content. Elasticsearch is an Apache Lucene(TM) open sourced search engine。

The .onion addresses are got from those sites in Ahmia crawler for Tor.

class OnionSpider(WebSpider):
    """
    Crawls the tor network.
    """
    name = "ahmia-tor"

    default_start_url = \
    ['http://zqktlwi4fecvo6ri.onion/wiki/index.php/Main_Page',
     'http://tt3j2x4k5ycaa5zt.onion/',
     'http://msydqstlz2kzerdg.onion/address/',
     'http://msydqstlz2kzerdg.onion/add/onionsadded/',
     'https://blockchainbdgpzk.onion/',
     'http://7cbqhjnlkivmigxf.onion/']

The .i2p sites list is shown below.

class InvisibleInternetSpider(WebSpider):
    """
    Crawls the i2p network.
    """
    name = "ahmia-i2p"
    default_start_url = ['http://nekhbet.com/i2p_links.shtml',]

    def get_link_extractor(self):
        return LinkExtractor(allow=r'.i2p',)

So where does these sites get the .onion addresses from?

An attacker can operate several hidden service directories and collect hidden service descriptors over a long period of time [2]. But it is very slow. The author in [2] used the shadow relays to reduce the number of compromised HSDir and the number of collection time. The authors in [8] used 40 servers and ran 160 days. About 80000 unique hidden services were found, in which 45000 are relatively stable.

6. Hidden Service address resolving

6.1 Tor Onion address resolve

Q: Tor 当中没有DNS，如何进行地址解析呢？Tor and I2P has no DNS like the Internet. How to resolve the .onion address in Tor?

A: You only need to compute & find the HSDir that responsible for storing that address. A DHT spread across HSDir relays, this simple DHT is ordered by their node fingerprint. Currently there are approximately 3500 routers flagged with HSDir.

For example, Bob’s service descriptor is calculated as Desc FP then its Desc FP is stored in HSDir_k and so on. Alice wants to connect to Bob, she only needs to find whether the xyz.onion is in that DHT.

6.2 I2P address resolve

Q: I2P 当中没有DNS，如何进行地址解析呢？Tor and I2P has no DNS like the Internet. How to resolve the .i2p address in I2P?

A: DNS in I2P is called ”susidns”, where a hostname is translated into its actual base32- or base64-encoded address, called ”destination”.

All destinations in I2P are 516-byte (or longer) keys.

8ZAW ̃KzGFMUEj0pdchy6GQOOZbuzbqpWtiApEj8LHy2 ̃O ̃58XKxRrA43cA23a9oDpNZDqWhRWEtehSnX
5NoCwJcXWWdO1ksKEUim6cQLP−VpQyuZTIIqwSADwgoe6ikxZG0NGvy5FijgxF4EW9zg39nhUNKRejYN
HhOBZKIX38qYyXoB8XCVJybKg89aMMPsCT884F0CLBKbHeYhpYGmhE4YW ̃aV21c5pebivvxeJPWuTBAO
mYxAIgJE3fFU−fucQn9YyGUFa8F3t−0Vco−9qVNSEWfgrdXOdKT6orr3sfssiKo3ybRWdTpxycZ6wB4q
HWgTSU5A−gOA3ACTCMZBsASN3W5cz6GRZCspQ0HNu ̃R ̃nJ8V06Mmw ̃iVYOu5lDvipmG6−dJky6XRxCed
czxMM1GWFoieQ8Ysfuxq−j8keEtaYmyUQme6TcviCEvQsxyVirr ̃dTC−F8aZ ̃y2AlG5IJz5KD02nO6TR
kI2fgjHhv9OZ9nskh−I2jxAzFP6Is1kyAAAA

If an application (i2ptunnel or the HTTP proxy) wishes to access a destination by name, the router does a very simple local lookup to resolve that name. The check order is private address book, master address book and then public address book.

The address book which contains three parts: public, master and private.

public address book: updated by the I2P software on all clients and therefor offers the possibility to publicly announce a service. Users can share the public address book with others as well.

master and private address book contains personal entries and can be used to store addresses that are not supposed to be publicly known

If not found the entry, the error page is returned. However, I2P offers a jump service that can be queried to and retrieve the destination. Four of them are included in the I2P and the error page includes links to access them: i2host.i2p, stats.i2p, no.i2p and i2pjump.i2p.

参考（Refs）

[1] Protocol-level hidden server discovery Ling Zhen et al. IEEE INFOCOM 2013

[2] Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization Alex Biryukov et al. IEEE Symposium on Security and Privacy 2013

[3] http://idlerpg.i2p.xyz/help/index_zh.html

[4] https://www.virusbulletin.com/virusbulletin/2016/12/vb2015-paper-anonymity-king/

[5] https://ritter.vg/blog-run_your_own_tor_network.html

[6] https://geti2p.net/en/docs/how/network-database

[7] https://ahmia.fi/documentation/indexing/

[8] Owen G, Savage N. Empirical analysis of Tor hidden services[J]. IET Information Security, 2016, 10(3): 113-118.

网络数字隐写技术初探及我的个人感悟。

数字隐写技术和网络数字隐写技术

网络隐写技术的目的就是为了保证数据传输内容的隐蔽性，同时确保通信过程不能被他人发现。

数字隐写技术是关于信息隐藏的技巧与科学。所谓信息隐藏指的是不让除预期的接收者之外的任何人知晓信息的传递事件或者信息的内容[1]。数字隐写技术来源于自然界，例如动物的伪装术。早在古希腊就有隐写术的发展，之后的战争年代又有了隐形墨水的产生。

数字隐写技术自1970年始，已在数字媒体防伪上运用广泛，技术也比较成熟。然而网络数字隐写技术是近年来发展迅猛，目前还是比较年轻的信息隐藏分支研究。网络数字隐写技术相较于数字隐写技术，有两个优点： 1. 网络数字隐写的数据传输能力更强，传统的数字隐写技术传输内容受限于传输媒介（一首歌、一部视频或者一幅图片），然而网络数字隐写技术传输内容可以按需获取。2. 网络数字隐写技术让信息泄露成为可能，通过长时间的少量数据传输，达到泄露信息的目的，例如APT。

网络数字隐写技术timing based 或者 storage based 两种技术，如下图所示。 Timing based主要是利用网络数据包传输时间和数据包间隔时间来写入隐蔽信息，比较常见的是数据包发送率隐写，数据包间隔时间隐写（按一定规律延迟发送），但是上述方法对时间比较敏感，应用起来比较困难。Storage based技术主要利用修改或者增加某字段或者将隐蔽信息直接存储到媒介中。常见的增加字段包括IP hearder option 字段， HTTP header等。

衡量网络数字隐写性能

隐写带宽（steganography bandwidth）: 单位时间内隐写内容传输大小 健壮性（robustness）：隐写技术能承受多大的外界干扰并且不影响隐写内容 隐蔽性（undetectability or invisibility）：隐写技术不能被检测出来

关于隐蔽性，很多文章都声明自己所提出的方法是隐蔽的，但是这些方法大多缺乏理论证明。后续也有工作证明之前提出方法不是隐蔽的[4]，例如Rainbow[5]。

健壮性和隐蔽性两个性能指标是此消彼长的关系，因此这两个指标的衡量最好是一起进行考虑的，而不是像之前的论文中分开进行讨论。

网络数字隐写的应用

1. 流量混淆变形技术，traffic morphing or traffic type obfuscation
2. 隐蔽通信技术，covert communication
3. 溯源技术，traceback techniques i.e. flow watermarking and flow fingerprinting

网络隐写技术可以用于匿名网络追踪溯源。很多方法也被提出用于匿名网络（Tor）溯源，例如DSSS[6]等。这些方法都有个共同假设：假设攻击者可以恰好位于通信的两端，然而事实并非如此。

对于溯源技术来说，storage based的方法一般效果不佳[4]，因为数据包都是加密的，无法修改其内容。因此目前大多数方法是timing based隐写技。尽管论文中给出了较好的溯源效果，但是目前并未具体实践运用。

检测方法

目前的网络隐写技术检测方法没有一个general的方法，大多检测方法是针对某一特定协议进行设计。而且Moskowitz和kang等很多学者认为，几乎不存在某种方法可以检测所有的covert channel。

Flownormalizer的工作原理如下图所示，主要工作原理就是去除数据包或者数据内容的不一致性，让他们变得都和预设规则设定的一样。不足之处是可能会破坏某些协议功能。

网络审计（Network auditting），适用于事后分析和异常检测。

异常检测，通过对比正常的字段内容，检测某些协议header一些比较奇怪的字段内容。

另外，可以利用形式化检测方法来检测协议设计之初是否存在隐藏通道，但是这方面研究很少。

最后，比较有前景的通用检测方法就是机器学习了。但是目前机器学习方法都只适用于某一特定的covert channel。不足之处还在于，需要正常的和隐蔽通信的流量数据，不仅是很难获取而且还很难标记。

结语

网络隐写技术尽管是一个非常有趣的研究方向，但是我感觉这个研究方向研究起来有点新手不友好。因为，我大概搜索了一下现有方法，但是并没有发现这些方法的开源代码。而且现在并没有这些方法的对比和评估实验，很多论文提出的新方法都是没有和别的方法进行对比。所以很难说这些方法到底哪个更好，复现原有方法也比较困难。

参考（Refs）

[1] https://zh.wikipedia.org/wiki/隐写术.

[2] Information hiding in communication network. Wojciech Mazurczyk, Steffen Wendzel, Sebastian Zander, Amir Houmansadr et al. ISBN: 978-1-118-86169-1, February 2016, Wiley-IEEE Press

[3] http://www.garykessler.net/library/steganography.html

[4] Iacovazzi, Alfonso, and Yuval Elovici. “Network Flow Watermarking: A Survey.” IEEE Communications Surveys & Tutorials 19.1 (2017): 512-530.

[5] Houmansadr, Amir, Negar Kiyavash, and Nikita Borisov. “RAINBOW: A Robust And Invisible Non-Blind Watermark for Network Flows.” NDSS. 2009.

[6] Yu, Wei, et al. “DSSS-based flow marking technique for invisible traceback.” Security and Privacy, 2007. SP’07. IEEE Symposium on. IEEE, 2007.

Tor 在自治域（As-level）上面的一些论文阅读和相关知识介绍

引言

近年来越来越多的顶会和文章在做Tor匿名网络相关的攻防工作，其中比较出名的就是Raptor[1]和 Counter Raptor[2] 这两篇文章所讨论的对象是(AS-level)自治域级别上的攻防。自治域上的Tor攻防最早是由[3]在2004年提出的。此后在AS-level上进行攻防研究的论文就很多，本篇就不一一列举了，读者可以翻看论文参考文献和相关工作。这些攻防内容的基本原理不变：

1. AS-level上的攻击的基本原理是：无论采用主动或者被动手段，使得如果Tor选择的链路，用户到入口段和出口到目的地段都在同一个AS内，那么该AS就可以利用流量分析和简单的统计关联技术将用户和目的地关联起来。
2. As-level上的防御基本原理是：既然用户选路在同一个AS内部存在风险，那么就进行As-aware的选路吧，使得用户选择的路径尽量通过不同的AS。

BGP协议的基本概念

BGP协议是运行在AS之间的路由协议，大多数互联网服务提供商（ISP）必须使用BGP来与其他ISP创建路由连接。BGP属于矢量路由协议，采用TCP协议，端口号为179。BGP路由器会周期地发送19字节的保持存活keep-alive消息来维护连接（默认周期为60秒）。在路由协议中，只有BGP使用TCP作为传输层协议。

Raptor

Raptor[1]和之前的AS-level的文章不同，之前AS-level的文章都是假设网络上的的路由都是对称的。这篇文章从asymmetric nature of Internet routing，BGP Churn, BGP Hijack, BGP Interception四种新的方法讨论对Tor的攻击。Raptor攻击的基本思想是，首先利用之前论文的一些方法锁定用户的入口位置（AS号），然后再利用BGP interception或者hijack来进行流关联分析（对比用户到入口和出口到目标网站之间的流量，主要利用TCP ack和sequence number来进行关联对比），最终达到用户关联溯源目的。

非对称性路由

互联网路由的非对称性在该文章中表现在，1）Tor出口节点到网站的所经过的路由可能和网站到出口节点所经过的路由不同。2）用户到入口节点所经过的路由和从入口节点返回Tor用户所经过的路由不同。

Natural Churn

引起Natural Churn的原因是网络底层链路变化，例如，链路失效，增加减少新的路由设备，ISP直接的新合作等等。这些变化可以给恶意AS提供溯源优势，因为可能链路变化后AS之间的传输路径就恰好通过了恶意AS。

作者在文章中是利用某一时期的BGP update数据，以及同一时期的Tor链路数据，进行仿真计算出来链路的变化。

BGP Hijack 和BGP Interception

BGP Hijack可以参考[4]。这里简单总结一下，BGP劫持的基本原理是，BGP协议会选择两种路径作为AS通信的下一跳，第一种是路径最短的，如果路径相同那么就选择一条前缀更具体的链路。 BGP 劫持后，Tor用户会感受到断路，因为Tor用户最后去向的入口节点的数据包会被丢弃。但是BGP劫持攻击已经可以缩小和暴露用户的IP地址集合，从而破坏了匿名性。

BGP Interception本质上类似于中间人攻击，让攻击者能够成为Tor用户到Tor入口节点之间的AS，换句话说就是BGP interception会将traffic重新发送给入口节点，而不会将traffic丢弃，这样攻击方式更隐蔽，因为Tor用户不会体会到断路现象。 BGP Interception 和 BGP攻击原理类似，不同就是恶意AS声明的也是前缀同样具体的自治域。BGP Hijack, BGP Interception还有一点不同就是，BGP Hijack发出的错误路由信息会影响整个网络，从而导致恶意AS不能将traffic重新传送到消息原来发出的地方。值得注意的是，即便声明和自治域相同的前缀也不一定能够部分或者全部截取流量到恶意自治域，这里面考虑的因素包括IGP metrics以及运营商自定义的优先处理规则等，可以参考下图和参考文献[6]。

在[5]中作者比较了BGP Hijack 和BGP Interception成功概率的大小。

上图表现了由于ASes之间的相互关系（Costomer-to-provider, peer, Provider-to-comstomer）在不同层级AS上BGP Hijack 和BGP Interception成功概率。如图所示，最高T1级AS成功概率最大，因为这一级的AS只有peer, Provider-to-comstomer之间的通信关系。文章重要结论之一是：Invalid routes advertised by ASes lower down in the hierarchy wouldn’t have as significant an impact.

Counter Raptor

Counter Raptor的基本思想是，文章提出一个算法来对AS抗攻击属性进行量化，然后利用这个指标来辅佐原来的Tor选路算法进行选路，从而降低链路被BGP hijack或intercetption的概率。具体如何计算的，参考[2]。

Interception检测

检测方法包括检测routing advertisements的错误，判断hop count changes等都不能实时检测Interception。还有其他大多数的方案都是基于前缀劫持的以下两个重要特征来研究相关检测技术[7]：

1. MOAS 冲突:即一个 prefix 匹配多个 origin AS 的行为。这是前缀劫持之于路由控制平面最重要的一个特征
2. IP 地址冲突: 在数据平面层次上,前缀劫持直接导致了一个目的 IP 地址(被劫持的前缀)存在多个不同 的路由目的地的问题.也就是说:假设 16.1.0.0/16 为 AS 1 所有,但被 AS 2 劫持,则目的地址为 16.1.0.0/ 16 的数据包可能分别从 AS 1 和 AS 2 返回.或者,源地址为 16.1.0.0/16 的数据包可能有去无回(返回 数据包被路由到 AS 2).

内部网关协议OSPF和RIP

OSPF协议同时使用单播（Unicast）和组播（Multicast）来发送Hello包和链路状态更新（Link State Updates），使用的组播地址为224.0.0.5和224.0.0.6。与RIP和BGP不同的是，OSPF协议不使用TCP或者UDP协议而是承载在IP协议之上，IP协议号为89，工作在OSI模型的传输层。OSPF协议将不同路由划分为不同区域，相同区域内的所有路由器都维护一份相同的链路状态数据库（LSDB），如果一台路由器属于多个区域，那么它将为每一个区域维护一份LSDB。

RIP是距离向量算法，在实际使用中已经较少适用。RIP使用UDP端口号为520。

这里总结内部网关协议的目的，是为了探索内部选路的是否可以对Tor造成一定影响，不过目前来看好像影响不大，除非用户选路都在同一个AS中的情况或许还有可能进行追踪。

参考（Refs）

[1] Sun Y, Edmundson A, Vanbever L, et al. RAPTOR: Routing Attacks on Privacy in Tor[C]//USENIX Security. 2015: 271-286.

[2] Sun Y, Edmundson A, Feamster N, et al. Counter-RAPTOR: Safeguarding Tor Against Active Routing Attacks[J]. arXiv preprint arXiv:1704.00843, 2017 S&P accepted.

[3] Feamster N, Dingledine R. Location diversity in anonymity networks[C]//Proceedings of the 2004 ACM workshop on Privacy in the electronic society. ACM, 2004: 66-76.

[4] http://www.freebuf.com/articles/network/75305.html

[5] Ballani H, Francis P, Zhang X. A study of prefix hijacking and interception in the Internet[C]//ACM SIGCOMM Computer Communication Review. ACM, 2007, 37(4): 265-276.

[6] http://www.h3c.com.cn/MiniSite/Technology_Circle/Net_Reptile/The_Tthree/Home/Catalog/201010/696835_97665_0.htm

[7]黎松, 诸葛建伟, 李星. BGP 安全研究[J]. 软件学报, 2013, 24(1).

Mac 上重新启动TeamViewer 以及Trouble Shooting。

思路

有些时候出于未知原因，我们无法使用TeamViewer登录远程的Mac计算机。但是我们却可以通过SSH连接到Mac上，这样也可以通过SSH来重新启动和登录TeamViewer。

总结起来就以下一些步骤：

1. 远程SSH到Mac电脑
2. 运用Mac自带的Apple script来重新启动 TeamViewer.
3. 将TeamViewer 显示到第一个窗口（为了防止密码被其他窗口遮挡）
4. 截屏
5. 用SCP 回传截屏图像
6. 用新的临时密码进行TeamViewer登录

具体步骤

具体命令行代码：

停止TeamViewer 
osascript -e 'tell application "TeamViewer" to quit'
启动TeamViewer 
osascript -e 'tell application "TeamViewer" to run'
将TeamViewer移动到第一个窗口
osascript -e 'tell application "TeamViewer" to activate'
将TeamViewer重新打开到第一个窗口
osascript -e 'tell application "TeamViewer" to reopen'
截屏
screencapture xxx.jpg
回传用scp
scp xx@host:(path to xxx.jpg) (path to save jpg)

Trouble Shooting:

有的时候回出现如下的一些情况，比如新弹出的对话框挡住了密码。笔者尝试使用了各种办法来模拟用户单击对话框的“OK”都失败了。

由于权限原因：System Events got an error: osascript is not allowed assistive access.

这个时候可能真需要真人去一趟了。

1. 本文概要

Paper Reading notes on:

1. Online Sketching of Network Flows for Real-Time Stepping-Stone Detection[1]
2. Traffic confirmation attacks despite noise[2]
3. Tracking encrypted VoIP calls via robust hashing of network flow[3]

2. Background

2.1 Stepping stone

直接翻译过来叫做垫脚石攻击，感觉有点奇怪。

垫脚石（Stepping stone）: The intermediate hosts used for traffic laundering are known as stepping stones. 垫脚石就是攻击者利用一系列中间主机作为跳板，为了掩盖攻击者的真实身份和位置的一种攻击方式。

垫脚石攻击的检测：在网络设备中记录流的一些信息。然后根据关联算法，能够找到真正的攻击源。传统的垫脚石攻击检测算法记录流的一些基本特征，例如流的包数量，包间隔时间等等。 但是传统的垫脚石攻击检测对丢包，噪声和网络环境变化并不能很好适用。（However, they provide very limited or no resistance to some of the aforementioned timing perturbations, especially packet drops/retransmissions and chaff.）而且传统的垫脚石攻击检测算法相对于本文的算法保存了更多的信息，不利于大量流量的数据处理，因此流量关联算法的时间复杂度比较高 O（m*n）, m是出去方向的流个数，n是进入方向的流量个数。

2.2切比雪夫不等式（Chebyshev inequality）

若随机变量X的数学期望、方差分别为E(X)及D(X)，则对任何\(\epsilon >0\)，成立

几何解释及意义详见： https://www.zhihu.com/question/27821324

2.3 相关工作

本文所提出的技术与鲁棒散列方案（Robust Hashing）类似。 它们都通过短序列（鲁棒散列）表示输入信号，这个序列的性质可以让其抵抗输入上的小扰动。 在多媒体信号处理的运用中，即便原始信号收到干扰或者变化（例如压缩，次滤波等），鲁棒散列函数仍然能够识别和认证多媒体内容。

3.流量Sketch计算和表示方法

实时的流量关联：在网络边界上，记录出入的active流的信息。active流在文章中设置的是60s的超时时间。如果在时刻\(t\)，出去方向的第\(i\)号流\(E_i (t)\)，和进入方向的第\(j\)号流\(I_j (t)\), 满足\(Diff_t(E_i (t),I_j (t)) < \epsilon \) 那么这两个流就被关联起来了。 Diff方法在文章中采用的汉明距离，然后两个流的sketches都是用binary的形式进行保存的。 采用新的表示方法，节约了保存空间，提高了计算效率。

一个流的Sketch是如何进行计算的呢？这里的high-level idea是将流量的packet-timing 特征进行线性变换，如果两个输入向量相似那么新产生的这两个向量也会相似。 具体做法是将一个流的传输分为k个time slots，每个time slot (t) 统计传输的包的数量 \(V_F(t)\), 然后每个time slot (t)对应一个随机映射函数（也可以是随机数）。 再计算k个累计的包传输数量和 \(C_F(i)\) (i=1,2,…,k), 最后根据\(C_F(i)\) 的符号进行编码（大于0的编码为1，小于等于0的编码为0），最终形成一个长度为k的0，1序列。

一个例子：

最后根据符号函数得到该流的sketch 为 101, 如何后续还有数据包进出的话，那么就在101的基础之上向后同理进行计算，如上图省略号所示。

3.1流量Sketch的基本性质

假设两个Flow，F1和F2相似，那么F1和F2的最后sketch也应相似。但是现实中基本不存在两个流完全一样，那么这两流的sketches的比特错误的概率大小\(P_{e}(F1,F2)\) 应该较低才满足相似的规定。比特错误的引入归根结底是因为\(V_F(t)\)，那么我们定义F1,F2包数量之间的不同为：

带入上式（\(C_F(i)\)的那个）

那么有

最后根据切比雪夫不等式（省略一些步骤）得到一个重要不等式：

注明：web版latex公式上下标有点问题，文中公式有可能存在错误.

4.流量Sketch搜索

本质上文中采用的是空间换时间的方法，将原来的O(mn)算法，降低到 \(O(n +\sqrt{mn})\)， 具体思路还是比较好理解的。这里不再赘述。

5. 流量关联攻击

流量关联攻击可以帮助我们找到两个相似的流。论文[2][3]创新地将[1]的方法运用到追踪溯源中，其具体做法如下图所示。

攻击者是passive listener，在入口和出口处对流量进行Hash(其实和[1]中的流量sketches很类似，有些小不同后面会介绍)，然后找到哪个user访问了target website，从而达到溯源目的。

如何计算流的binary hash呢？

[3]的算法如下：

算法[3]和[2]的不同之处就在于，[3]的B增量是以字节大小表示的，[2]是以包的个数表示的，由于报文填充机制，所以[2]没有利用包的大小信息。

[2]的算法如下：

1. Line 1: 初始化binary hash 向量
2. Line 2: 为每个time window 提取该窗口的包数量
3. Line 3: 对于每个窗口进行计算
4. Line 4~6: 对于第一个窗口，计算稍微有些不同
5. Line 7~10: 对于后续窗口如何进行Hash值计算，Line 8计算和前一个窗口的包数量差，Line 9, 用增量update H。那个加号其实就是向量加法，后面的中括号其实就是随机向量，这里的m应该和H的长度一样才行，也就是说随机数的个数要和binary hash长度一样。
6. Line 11: 符号函数，如果H对应的bit位置的值大于0则编码为1， 如果小于等于0则编码为0。感觉应该可以放到for循环外。

问题：如何得到窗口个数N？ Answer: 对于每个flow，N都是一样的。 N is decided on prior to computation，如果包数量比窗口数量还少，那么丢弃该流。

Refs

[1] Coskun B, Memon N D. Online Sketching of Network Flows for Real-Time Stepping-Stone Detection[C]//ACSAC. 2009: 473-483.

[2]Hayes J. traffic confirmation attacks despite noise[J]. arXiv preprint arXiv:1601.04893, 2016.

[3]Coskun B, Memon N. Tracking encrypted VoIP calls via robust hashing of network flows[C]//Acoustics Speech and Signal Processing (ICASSP), 2010 IEEE International Conference on. IEEE, 2010: 1818-1821.

1. 本文概要

Paper Reading notes on:

Nazca: Detecting Malware Distribution in Large-Scale Networks

2. 传统方法

drive-by download attack 的过程可以被分为3个步骤：

1. 利用阶段（exploitation phase）: 通过利用漏洞让客户机执行shellcode代码
2. 安装阶段（installation phase）: shellcode被执行，开始从远程下载恶意软件
3. 控制阶段 （control phase）: 恶意软件产生流量与控制端进行通信

传统论文方法大多数工作主要是针对阶段1，3进行检测，如检测跨站脚本，挂马网页等，然后就是从主机发出的流量进行检测，如IDS，杀毒软件等。

3. 论文特色

1. 传统恶意软件检测算法主要在检测恶意软件已经被下载到用户电脑上之后产生的流量, 然而很少有研究去检测恶意软件是从哪儿被下载的。(针对阶段2)
2. 提出了Nazca检测系统，detects infections in large scale networks。
3. 利用了图的关联特性，可以检测出未知的malware，0-day

4. Nazca工作原理

通常在阶段2，shellcode会发出HTTP请求，并从远程服务器下载恶意软件。由于是HTTP请求，和其他正常的请求很类似，所以很难被发现。论文的intuition 就是：好吧，少量的恶意软件我可能发现不了，但是很多主机都在请求某个恶意软件，那么就很可疑了。（Instead, when considering many malware downloads together – performed by different hosts, but related to a single campaign – a malware distribution infrastructure becomes visible. ）

Nazca主要负责在一个网络中检测HTTP请求，更具体的是下载可执行软件的HTTP请求。和普通HTTP下载不同的是，恶意软件下载有很多防御技术，1）domain fluxing, 2) malware repackaging 3) malware droppers for multiple installations. 作者表示，其方法可以对上述防御技术兼容。

Nazca检测主要分为两个部分，1）candidate selection（也叫做过滤阶段） 用 4个小节提出的一系列方法检测URIs，这些URIs表现出一些恶意行为。

4.1 节检测文件变异：某网址下载所对应的文件hash值，如果超过n那么就是一个candidate。

4.2 节检测恶意CDN: 通过6个特征（Domain关联度，不同TLD的个数等）学习出的决策树来进行分类。

4.3 节检测dedicated malware host：所谓Dedicated malware host就是专门保存恶意软件的主机，这些主机一般藏在多重redirection之后，并且host的内容相对传统网站内容更少。

4.4 节检测Exploit/Download host: 如果恶意软件作者利用的shellcode从一个hardcoded User-agent进行下载恶意软件，所产生的http请求是特别的：对于一个destination，采用的User-agent是不同于浏览器的User-agent。

2) Detection step, 运用1）产生的URIs，构建恶意邻居图，如果一个节点在恶意邻居图里面，那么这个图的其他节点很有可能也是恶意的。 可以看出1）这个步骤是为了过滤掉正常的，剩下恶意的方便后续分析。

4.1 Nazca检测内容和特征提取

Nazca检查MIME类型¹只要不在白名单中，那么就会提取：

1. 目的IP和源IP
2. 目的端口和源端口
3. URI
4. HTTP头部的User-Agent
5. 解压后文件的前 k 字节的哈希值

论文focuses on HTTP 流量是因为：we observed that it is the protocol of choice for the vast majority of malware in current circulations.

4.2 恶意域名检测

恶意软件为了躲避杀毒软件的查杀，使用不同的技术(malware hosting tries to evade blacklisting by using multiple domains, servers, payloads, file names, and URL paths)，作者在论文中针对恶意软件的：1）server-side polymorphism 2）multiple domains 进行了分析和处理。

所谓 server-side polymorphism就是恶意软件使用不同的加密key对软件进行加密或者攻击者准备多种变种恶意软件，每次下载不同的软件，从而达到绕过杀毒软件的signature库的目的。 作者使用的检测方法是：看一个下载记录与URI的关联情况，以及从URI处下载不同软件的数量。

检测恶意的CDN（区分正常的和恶意的CDN是非常重要的）。

检测步骤：

1. 检测CDNs

如果相同1个文件的hash值对应多个不同的URIs，那么这些URIs的域名就属于一个簇。如果不同的2个簇里面都至少存在一个相同的域名，那么这两个簇就被连接起来。最后形成的这些簇就是CDNs.

1. 区分恶意和正常CDNs

采用方法：机器学习

提取特征：1） 域名关联度: 有些恶意软件作者为了节省开支，用同一个IP来host不同domain names，那么这个特征就是： hosts数目除以domains数。 2） 不同的TLD域名个数：合法的CDN通常使用一个TLD或者一个TLD下面的不同sub domain，恶意的CDN通常使用多个不同的TLD(开源软件镜像除外) 3）匹配的URI和文件个数：合法的CDNs通常为了高效维护，采用的目录结构和文件名都一样。相反恶意软件为了防止blacklisting，通常采用不同的文件名和URI。 4）同一域名下的不同URI数量：恶意软件的网站目录结构复杂性低于其他正常域名（有例外，但很少）。 5）文件类型比例：正常CDNs通常有不同的文件类型，然而恶意的CDN大多数情况下只有可执行文件。

4.3 构建恶意邻居图

恶意邻居图：指关于某个可疑候选者一系列的恶意行为图（无向图）。

节点内容包括：IP地址，域名，FQDN(Fully Qualified Domain Name)s, URLs, URL paths, file names，下载文件的hash值。

初始节点可以是一个恶意的域名，或者恶意的FQDN。当一个新的节点来的时候，要把其加入图中，依据的是节点之间的关系：要么是URL相同，要么是域名相同等等。

论文作者根据这个生成的图，为每个恶意候选者计算一个分数。如果图中的恶意节点（经过阈值判断过）较多的话，那么这个节点很肯能就是恶意的。同时从图的连接性来看，可以关联出不能被其他方法检测出来的未知恶意软件。

4.4 适用范围

论文方法适用于HTTP based malwares。 不能够检测HTTPS，加密协议，不能够检测依赖于其他正常网站（Google Drive, Dropbox等）来发布的恶意软件。

为什么不用HTTPS?

1. 自签名证书，浏览器会报警，降低恶意软件感染率
2. 权威机构对恶意网站前面不感兴趣，会破坏自身声誉
3. 降低恶意软件性能

如何逃过论文方法检测：

1. 采用加密协议
2. 使用Skype等合法软件

Refs

[1] Invernizzi L, Miskovic S, Torres R, et al. Nazca: Detecting Malware Distribution in Large-Scale Networks[C]//NDSS. 2014, 14: 23-26.

本文概要

本文主要介绍Deep learning 和整理我所看到的一些资料，持续更新 (Keep updating, once I have time)。

深度学习的优势与不足

优点：

1. 在研究中可以发现，如果在原有的特征中加入这些自动学习得到的特征可以大大提高精确度，甚至在分类问题中比目前最好的分类算法效果还要好[3]
2. 非监督学习

缺点：

1. 深度学习的一个主要优势在于可以利用海量训练数据（即大数据），但是依赖于反向传播算法，仍然对计算量有很高的要求。
2. 比起统计方法来说 那当然就是模型难以诠释，找出来的 Feature 对人而言并不直观。

Tensorflow

使用Tensorflow需要知道：

The central unit of data in TensorFlow is the tensor. Tensorflow基础数据单元，其rank就是训练数据的维度 (训练数据是几维的)

A computational graph is a series of TensorFlow operations arranged into a graph of nodes. 计算图？

To actually evaluate the nodes, we must run the computational graph within a session. A session encapsulates the control and state of the TensorFlow runtime. 计算评估模型需要一次会话

A placeholder is a promise to provide a value later. 就是说数据现在没有，以后有了再提供 ，先登记一下

A Variable tf.Variable变量， tf.constant常量，变量是没有初始化的，常量是一调用就被初始化了的，然后就不变了。变量如果需要初始化，需要调用

init = tf.global_variables_initializer()
sess.run(init)

Refs

[1] LeCun Y, Bengio Y, Hinton G. Deep learning[J]. Nature, 2015, 521(7553): 436-444.

[2] 将Keras作为tensorflow的精简接口 https://keras-cn.readthedocs.io/en/latest/blog/keras_and_tensorflow/

[3] http://blog.csdn.net/zouxy09/article/details/8775524

[Cuda install guide ] https://www.tensorflow.org/versions/master/get_started/os_setup#optional-install-cuda-gpus-on-linux

1. 本文概要

本文主要介绍Go语言以及Docker的使用，以及整理我所看到的一些资料。

2. 开篇

我们经常听到一句话

其实这个年代你用什么编程语言都可以，只要能够熟练运用。

精通一门语言对于我们学计算机的人来说确实够用了，我们掌握的其实不是语言，而是语言背后的逻辑思想（算法）。但事实上笔者认为在编程语言上还是需要有一定的选择，物尽其用，觉得用什么语言方便实现就用什么语言。本来笔者也是不想学Go编程语言的，但是看到其优越的特性，感觉不学的话会跟不上时代了。

论文The effect of DNS on Tor’s Anonymity 中使用了Go语言进行代码编写。作者搜集Alexa前100万的DNS流量，无论是从数量级还是工程难度来说都是具有一定挑战的。这篇blog就是学习一下大神是如何利用Go的优势的。

3. Go语言

网上说了很多关于Go语言的优劣势分析，稍微谷歌一下就行了。这里我只总结一下我觉得Go语言的优势吧(部分参考[1])。

1. 部署简单。Go 编译生成的是一个静态可执行文件，除了 glibc 外没有其他外部依赖。这让部署变得异常方便：目标机器上只需要一个基础的系统和必要的管理、监控工具，完全不需要操心应用所需的各种包、库的依赖关系，大大减轻了维护的负担。 笔者点评：人生苦短，何必浪费时间搭建环境呢，配置环境变量呢！这个特性无敌
2. 服务器，并发编程实现容易，上手简单。
3. 跨平台支持。在mac上编译的go运用程序，可以跑在各种类型的操作系统上，而且目标操作系统都不需要Go编译环境。 笔者点评：我也非常喜欢这个特性，java还得装jvm才能跨平台

4. DNS 数据搜集

在论文The effect of DNS on Tor’s Anonymity 中， 作者对Alexa top 100 million网站的DNS数据抓取采用了Go+docker的模式来进行。 作者实现了一个server来分任务给位于dockers中的workers. server服务端和docker客户端都采用的Go语言进行编写。 sever负责将alexa 网站地址传给worker，然后通过RPC调用将worker搜集到的pcap返回并保存。

4.1 Docker network traffic dumping

在默认情况下，从docker里面搜集网络数据会是怎么样的呢？我们来试试:

docker exec –privileged -it myubuntu /bin/bash

ifconfig eth0 promisc

从docker 里面 ping 8.8.8.8 并同时开启tcpdump 发现如下结果：

结果发现只有该容器自身的网络数据包。论文作者正是利用了这样的一种网络隔离性，来达到利用多个Docker同时搜集DNS流量的目的。这样做的的好处是可以并发进行数据搜集，加快流量搜集速度。

图示

如果我们可以这样来搜集网络数据包，岂不是很效率，事半功倍。

5. 其他

Docker 上面无需再要我们手工搭建环境了，模拟web请求可以用xvfb-run命令来达到虚拟屏幕输出，这样就可以从命令行访问网站了。xvfb-run好像在ubuntu 16.04上运行不了firefox，论文中作者使用的是Tor browser 5.5.4, 配置Tor browser 使用其他代理

6. Docker 常见命令

清除历史的containers

docker stop $(docker ps -a -q) 

docker rm $(docker ps -a -q)

Reset所有

pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
docker -d

开启Docker sslocal

容器里面抓包需要权限 
docker run --privileged --name sslocal -d jasonzhuo/sslocal2 ./start.sh <IP:Port>
docker run --privileged --name sslocal -it jasonzhuo/sslocal2 /bin/bash

其他常用的

重命名 docker tag server:latest myname/server:latest 
提交修改 docker commit [CONTAINER_ID] test/name
删除镜像 docker rmi xxx 
删除容器 docker rm xx
拷贝到容器 docker cp foo.txt mycontainer:/foo.txt
拷贝到主机 docker cp mycontainer:/foo.txt foo.txt
开一个新的terminal(假设现在在运行的container ID 为12345)
docker exec -it 12345 /bin/bash

Refs

[1] https://www.zhihu.com/question/21409296

我又回来了

之前在忙各种出国手续，写论文，做实验之类的事情，博客从去年8月到现在都没更新过，想想也是太烂龙了。最近翻到一本《精进：如何成为一个很厉害的人》，发现写博客还有如下功效，遂立即开始写作（以后也要坚持才行）：

写博客（写作）是一种典型的知识构建活动，或者更准确的说，是一种对知识的重构活动。

在阅读时，我们对信息的输入和纳入（读论文），常常满足于从一个“浅表”的层面去理解它们。 但是在写作时，也就是进行信息输出的时候，我们必须去分析知识的“深层结构”，观察和调用知识与知识之间的深层关联，不然我们无法自如地将它们组织起来。因为一篇文章要被人读懂、要把人说服，需要缜密的思维、清晰的表达和详实的依据，这些都要求我们队知识的编码和组织达到一个相对较高的水平才行。

自己下来多理解一下才行，开始写！

作者论文的主要贡献

1. 提出了一种找Tor出口节点使用的DNS服务器的方法
2. 提出了名为DefecTor攻击方法，该方法属于关联攻击（correlation attack）的一种，用于溯源
3. 在TorPS上分析了该新攻击方法对Tor用户造成的影响
4. 提出了一种更好的衡量（evaluate）关联攻击的方法

本篇内容主要讲贡献2，后面逐步更新

Tor DNS解析过程

首先Tor的DNS都是从Tor网络中走的，这点是Tor client （web browser）预设值，目的是防止DNS外泄。因为Tor不能够代理UDP流量，所以Tor proxy将DNS request 包装进Tor CELL中。 浏览器将解析地址传给Tor client proxy， 然后Tor client 选择一个可以用的出口节点，并与其建立连接（应该是3跳连接，不是1跳连接，参考Tor spec）, Tor出口节点解析后，才会与目地网站建立TCP连接，成功之后返回Relay_connected cell. 另外一种DNS解析方法是构建Relay_resolve cell, 这个不同在于没有后续的TCP连接。

Tor出口节点会根据其主机配置进行DNS解析，主机的DNS解析一般流程 参考这里：Linux DNS

作者在文章中指出：大约4成的DNS流量都去了谷歌的DNS(8.8.8.8), 第二多的就是去本地DNS服务器解析。

Defctor 攻击模型

文章中的重要假设：

1. 每次网页访问只产生一个DNS请求，不考虑嵌套请求（embedded request）和 DNS caching
2. 出口节点的DNS请求和正常用Tor browser 但不经过Tor 网络访问网站的DNS请求一样（不太清楚）
3. 为了达到最好的关联攻击效果，用户选择的路径（出入口）被攻击者所控制。

如上图，攻击者的位置有两个（需要同时满足）：

1）出口节点和DNS服务器之间（或者攻击者控制了DNS服务器）

2）在用户或者Tor guard之间（或者控制了Tor guard）

关联攻击，同时对比1）和2）处的流量，达到溯源目的是这篇文章的主要思想。不同的是该文章对比的是DNS流量，传统的方法是对比TCP流量。

实验方法

作者在论文中对：1）用户使用Tor访问哪些网站，2）多久访问一次这些网站，进行了统计，3）如何对Tor出口节点的DNS缓存进行了考虑。发现了如下结论：

1）用户访问的网站服从幂律分布

2）作者实验使用的Tor出口节点大概每5分钟发出102次DNS请求（中位数），然后作者根据Tor带宽进行推测，真实网络中Tor出口节点大概每5分钟发出119.3次DNS请求（中位数），一次网站访问大概会平均造成10.3到不同域名的DNS请求，因此得出每十分钟大概可以发现23.2个不同网站。

3）Tor client 会缓存DNS请求，TTL最小为60s,最大为30分钟（目前统一为60s）。作者利用60s的滑动窗口，就可以发现所有的DNS请求，无论它是否缓存过。

作者使用的Tor浏览器来发送DNS请求，但不使流量通过Tor网络，其目的在于为了防止原来有些顶会所讨论的Tor拒绝服务情况。作者意图通过DNS来判断用户所访问的网站，实现了一个Naive classifer, 主要通过unique domains: domains that are unique to a particular website来进行关联。 作者通过对DNS请求进行特征提取（extractdns），主要提取了observed domains, TTLs and IP-addresses这三个特征。然后利用dns2site（Go脚本代码）将生成的dns list map 到 具体的 site（具体算法是利用投票进行的）。

这里总结一下，Naive classifer 主要分类依据是unique domains mapping, 作者使用的数据集是top one million alexa websites 每个主页访问5次的那个数据集。

作者另外还根据DNS请求进行了额外的特征提取，从而可以利用Tao Wang 的 KNN算法进行分类。因此在这个实验中，作者利用了Tao Wang论文中所提出的一些特征，共1225个，然后利用Wa-KNN进行权重训练，最后进行分类。 我感觉作者分了两次来做实验，一次是在出口节点搜集DNS流量，第二次是在入口节点根据Tor log信息（log incoming and outgoing cells）来搜集流量，因此入口节点处采用的是KNN，出口节点采用的是Naive classifer。

这里再总结一下，KNN算法依据的是Wang et al.，作者使用的数据集是1000个（每个100个instances）网页， 和额外的100000个网页（每个1个instance）的数据集。 验证采用的是10折交叉验证方法。

那么问题来了，作者如何是将这两个结果关联起来的呢？ 作者在论文中还提到了一个叫做 hp（high precision） 的attack，这个attack应该就是起到关联作用的。 只有当hp attack成功观察到入口和出口节点有相同网站时，才进行汇报（关联），相当的simple和effective。 在这里因为Naive classifer采用的DNS mapping, 其效果能达到 94.7%的recall和98.4%的precision，因此作者有理由认为，如果我在入口节点看到了一个我检查的网页，并且我在出口处也看到了该网站，那么就有较大的可能性达到了溯源的目的。然而，作者在出口节点观察到的DNS请求并不一定来自该入口节点，有可能别的用户也在同一时间从相同出口处访问了这个网站， 这就有个概率比例问题了（攻击者能观察多少比例的出口流量？）。果然，作者后来又说: We conclude that DefecTor attacks are perfectly precise for unpopular sites（因为popular site 会有很多人访问） because it is unlikely that more than one person is browsing a monitored site within the timeframe determined by the window length. 这个感觉还是有点道理的，看读者怎么想了吧。

分析作者搜集DNS流量的实验平台框架（偏工程）

作者搜集Alexa前100万的DNS流量，无论是从数量级还是工程难度来说都是具有一定挑战的。笔者饶有兴趣的看了一下大神们的做法，将一些要点记录在这里.

Refs

[1] https://nymity.ch/tor-dns/

基于Jnetpcap的Pfring使用，以及网络数据包处理流程机制分析。

1. last update 2016.3.5 修正l句子不通顺的地方。

1.PF ring 简介

PF_RING是Luca Deri发明的提高内核处理数据包效率的网络数据包捕获程序，如Libpcap和TCPDUMP等。PF_RING是一种新型的网络socket，它可以极大的改进包捕获的速度。

####1.1 本文中的一些术语 NAPI: NAPI是Linux新的网卡数据处理API，NAPI是综合中断方式与轮询方式的技术，NAPI 在高负载的情况下可以产生更好的性能，它避免了为每个传入的帧都产生中断。参考这个链接NAPI

Zero copy (ZC): 简单一点来说，零拷贝就是一种避免 CPU 将数据从一块存储拷贝到另外一块存储的技术。

NPU:网络处理器

DMA:直接内存存取, Direct Memory Access, 它允许不同速度的硬件装置来沟通，而不需要依赖于 CPU 的大量中断负载。

Linux 网络栈：如下图所示，它简单地为用户空间的应用程序提供了一种访问内核网络子系统的方法。

2. Libpcap抓包原理

Libpcap的包捕获机制就是在数据链路层加一个旁路处理。当一个数据包到达网络接口时，libpcap首先利用已经创建的Socket从链路层驱动程序中获得该数据包的拷贝，再通过Tap函数将数据包发给BPF过滤器。BPF过滤器根据用户已经定义好的过滤规则对数据包进行逐一匹配，匹配成功则放入内核缓冲区(一次拷贝)，并传递给用户缓冲区（又一次拷贝），匹配失败则直接丢弃。如果没有设置过滤规则，所有数据包都将放入内核缓冲区，并传递给用户层缓冲区。

高速复杂网络环境下libpcap丢包的原因主要有以下两个方面：

1. Cpu处于频繁中断状态，造成接收数据包效率低下。
2. 数据包被多次拷贝，浪费了大量时间和资源。从网卡驱动到内核，再从内核到用户空间。

为啥用Pfring呢

随着信息技术的发展，1 Gbit/s，10 Gbit/s 以及 100 Gbit/s 的网络会越来越普及，那么零拷贝技术也会变得越来越普及，这是因为网络链接的处理能力比 CPU 的处理能力的增长要快得多。高速网络环境下， CPU 就有可能需要花费几乎所有的时间去拷贝要传输的数据，而没有能力再去做别的事情，这就产生了性能瓶颈。

3.PF_RING驱动家族

这些驱动（在PF_RING/driver/PF_RING-aware中可用）设计用于提高数据包捕获，它把 数据包直接放入到PF_RING中，不经过标准Linux数据包分发机制。

3.1 DNA

对于那些希望在CPU利用率为0%（拷贝包到主机）情况下需要最大数据包捕获速度的用户来说，可以使用DNA(Direct NIC Access)驱动，它允许数据直接从网络接口上读取，它以零拷贝的方式同时绕过Linux 内核和 PF_RING模块。

左边这个图解释：Vanilla PF_RING 从NIC上通过Linux NAPI获取数据包拷贝。拷贝到PFring 环状缓存空间。然后用户空间的应用会从环状缓存空间读取数据包。从图中可以看出Vanilla PF_RING 有两次polling操作，一次从NIC到环状缓存空间（Linux 内核里面），另外一次从环状缓存空间到用户程序。

左边这个图，相对于传统的方式来说。首先Application使用的是mmap方式，较标准版本的Libpcap效率更高。Libpcap标准版是目前使用最多的用于从内核拷贝数据包到用户层的库，而libpcap-mmap是libpcap的一个改进版本。传统libpcap使用固定大小的存储缓冲器和保持缓冲器来完成数据包从内核到用户层的传递，而libpcap-mmap设计了一个大小可以配置的循环缓冲器，允许用户程序和内核程序同时对该循环缓冲器的不同数据区域进行直接的读取。其次，PF_ring使用的是NAPI，而不是Libpcap中使用的DMA方式调用系统函数netif_rx()将数据包从网卡拷贝到内核缓存。

右边这个图解释：DNA模式下通过NIC 的NPU(网络处理器)拷贝数据包到网卡上的缓存空间。然后直接通过DMA方式到用户层，同时绕过了PF_RING模块和Linux 内核缓存。官网已经证明了DNA方式能有更快的处理速率Performance。

让人多少有点遗憾的是，该方式并不是可以随意使用的，根据其License，提供免费下载，但是以二进制形式提供测试版本的库（也就是说使用5分钟或者达到一定包的处理数量之后软件就停了），如果需要长期使用，需要购买解锁的代码。

ERROR: You do not seem to have a valid DNA license for eth0 [Intel 1 Gbit e1000e family]. We’re now working in demo mode with packet capture and transmission limited to 0 day(s) 00:05:00

下图展示的是传统数据发送的整个过程，图片引用自ibm.com。

3.2 PF_RING-aware (ZC support)

这个模块在路径 PF_RING/driver/PF_RING-aware下（带有zc后缀）。根据官方手册介绍，An interface in ZC mode provides the same performance as DNA. Zero Copy(ZC)。ZC和DNA实际上都是绕过Linux 内核和 PF_RING模块，这些模式下Linux内核将看不到任何数据包。

3.3 ZC

PF ring 还有一个ZC模块。什么ZC，DNA，pfring-aware是有点乱，不好分清楚。ZC模块可以看做是DNA的后续版本（“It can be considered as the successor of DNA/LibZero that offers a single and consistent API implementing simple building blocks (queue, worker and pool) that can be used from threads, applications and virtual machines.”）。PF_RING ZC comes with a new generation of PF_RING aware drivers。感觉这个ZC新模块与DNA差别不大。

4. Libpfring and Libpcap and Jnetpcap

怎么让我们的其他应用程序使用pfring的高速特性呢？官方文档中说，Legacy statically-linked pcap-based applications need to be recompiled against the new PF_RING-enabled libpcap.a in order to take advantage of PF_RING. Do not expect to use PF_RING without recompiling your existing application. 也就是说需要和 PF_RING-enabled的 libpcap.a 进行重新编译应用程序才能够使用pfring的高速特性。

项目运用中，我打算使用JAVA程序来写一个高速的网络数据包处理程序。由于JAVA采用的是Jnetpcap，Jnetpcap是Libpcap的封装。而原本Libpcap本来不是支持Pfring的。因此，如果要用Java调用Pfring，就必须采用支持Pfring的Libpcap，而不是原本安装的Libpcap。所以，需要把原来的Libpcap卸载，安装Pfring的Libpcap。

rmp -qa libpcap //查看Libpcap
rpm -e libpcap //删除Libpcap

Pfring 的安装过程可以参考这篇文章：Pfring安装

实验所用的服务器是Dell R730，em1,em2是万兆网卡，em3是千兆网卡 先卸载原来的网卡驱动，加载DNA驱动到em2网卡后是这样的：

[root@localhost ~]# ethtool -i em2
driver: ixgbe
version: 4.1.5
firmware-version: 0x800004cf, 15.0.28
bus-info: 0000:01:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

[root@localhost ~]# ethtool -i em3
driver: igb
version: 5.2.13-k
firmware-version: 1.67, 0x80000b89, 15.0.28
bus-info: 0000:06:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

运行我写的基于Jnetpcap的Java程序后，读取的硬件信息是这样的：

1. flags=6, addresses=[[addr=[10], mask=[10], broadcast=null, dstaddr=null], [addr=[INET4:192.168.1.30], mask=[INET4:255.255.255.0], broadcast=[INET4:192.168.1.255], dstaddr=null], [addr=[17], mask=null, broadcast=[17], dstaddr=null]], name=em3, desc=PF_RING
2. flags=6, addresses=[[addr=[17], mask=null, broadcast=[17], dstaddr=null]], name=em2, desc=PF_RING ZC/DNA
3. flags=6, addresses=[[addr=[17], mask=null, broadcast=[17], dstaddr=null]], name=em1, desc=PF_RING ZC/DNA

可以看到，em1,em2由于加载了Pfring的特殊驱动，其描述已经变成了PF_RING ZC/DNA，em3由于还是用的原来的驱动，所以只有Pfring。

使用Java调用PF_RING ZC/DNA，如果没有Lisence, 仍然会出现刚才所讲的错误信息。 需要注意的是调用ZC的时候需要将原来：

Pcap.openlive(device.getName())

改为

Pcap.openlive(“ZC:”+device.getName())

奇怪的是，我用tcpreplay 最高速发送：1479130个包的时候 jnetpcap接收到16655个包之后就没有了，至今不知道原因。 recv=0, drop=0, ifdrop=0 recv=16655, drop=0, ifdrop=0 recv=16655, drop=0, ifdrop=0 recv=16655, drop=0, ifdrop=0

Jnetpcap不使用ZC/DNA特殊驱动的时候，仅用Jnetpcap+ Pfring模块，在高速网络环境下，我们发现丢包仍然很严重。 实验中，我们将em1和em2直接串联，使用Tcpreplay结果：

Actual: 1479130 packets (812472290 bytes) sent in 4.06 seconds.Rated: 200116320.0 bps, 1526.77 Mbps, 364317.72 pps

Statistics for network device: em1

Attempted packets:         1479130

Successful packets:        1479130

Failed packets:            0

Retried packets (ENOBUFS): 0

Retried packets (EAGAIN):  0

使用Jnetpcap抓包结果：

	recv=93179, drop=139931, ifdrop=0
	
	recv=201895, drop=721505, ifdrop=0
	
	recv=338379, drop=736488, ifdrop=0
	
	recv=490772, drop=736488, ifdrop=0
	
	recv=660812, drop=736488, ifdrop=0
	
	recv=663681, drop=736488, ifdrop=0
	
	recv=663681, drop=736488, ifdrop=0

可以发现，仅用Jnetpcap+ Pfring模块，在高速网络环境下，我们发现丢包仍然很严重。达到了50%。

4.1Pf ring 工作模式

PF_RING有3中工作模式： pf_ring有三种透明模式（transparent_mode）。为0时走的是Linux标准的NAPI包处理流程； 为1时，包既走Linux标准包处理流程，也copy给pf_ring一份； 为2时，驱动只将包拷贝给pf_ring，内核则不会接收到这些包，1和2模式需要pf_ring特殊的网卡驱动的支持。

NOTE from other website：

• 默认为transparent=0，数据包通过标准的linux接口接收。任何驱动都可以使用该模式
• transparent=1（使用于vanila和PF_RING-aware驱动程序），数据包分别拷贝到PF_RING和标准linux网络协议栈各一份
• transparent=2（PF_RING-aware驱动程序），数据包近拷贝到PF_RING,而不会拷贝到标准的linux网络协议栈（tcpdump不会看到任何数据包）。
• 不要同时使用模式1和模式2到vanila驱动，否则将会抓到任何数据包。

4.2 Pf ring 包过滤

pf_ring 普通模式下支持传统的BPF过滤器，由于DNA模式下，不再使用NAPI Poll，所以PF_RING的数据包过滤功能就不支持了，目前可以使用硬件层的数据包过滤，但只有intel的 82599网卡支持。Jnetpcap只能在pf_ring 普通模式下工作，因此只能够用BPF过滤器。

Written with StackEdit.