linux防火墙

本帖最后由 spotaku 于 2017-10-2 10:38 编辑


我们知道，linux防火墙本质上就是一个包过滤程序，而我们常用的tcpdump工具可以过滤出来你想要抓取的数据包，tcpdump使用的过滤机制正是bpf所提供的，那么，显然的想法是，能不能直接利用bpf来实现防火墙，决定数据包的DROP or ACCEPT呢？

我曾经想过写一个Netfilter HOOK Function来实现上面的想法，直到我了解到iptables有一个match模块叫做bpf之后，我方才打消了这个想法。不过我知道，至少在iptables 1.4.7版本是不支持这个match的，而这个版本的iptables是CentOS 6.7所自带的版本，而我一直在使用这个版本，所以我没能第一时间看到iptables的Changelog，所以直到我亲自编译了iptables 1.4.21之后，我才发现了这个bpf match，至于2013年时我是怎么接触这么个技术的，可能那时用到了吧，幸亏留下了点印记(这就是写blog的好处…)。

简单说吧，iptables的bpf match非常帅，以我的体验来看，一条使用了bpf match的iptables规则可以替代多条单独的iptables规则，这一点bpf match和ipset match有异曲同工之妙处。举一个简单的例子吧，请看以下的iptables规则：
显然，使用单独的一个bpf match要比配置2条iptables规则简便得多。不过还有另一个选择，那就是使用ipset。首先我们将1.2.3.4和2.2.2.2加入一个set中，然后使用单一的ipset match来进行匹配，凡是目标地址在该set中的，全部DROP。

然而bpf match和ipset还是有差别的，那就是bpf实际上是执行一段程序，具体匹配哪个IP地址或者哪个别的什么字段，是由程序逻辑决定的，而ipset match则完全不同，它只是一个高效的查询结构而已，具体的逻辑依然在iptables本身，iptables会判断IP地址或者哪个别的什么字段在不在这个set中，只是判断的过程非常高效而已，其实所谓的高效也不过就是那些我们熟知的二叉树，哈希等算法，请注意，这些算法是内置的，外部的iptables只有选择权，而没有定义权，换成bpf的话，没有什么内置的算法，全凭你自己的想象。像上面的那个简单的例子，我写出的”5,32 0 0 16,21 1 0 16909060,21 0 1 33686018,6 0 0 1,6 0 0 0“是一个遍历匹配2个IP地址的算法，而在本文的以下部分，我将展示一种使用bpf程序自己定义的一个二叉树匹配算法。

看到bpf match和iptables标准match以及ipset match的差别了吗？如果大致明白了，那么我们开始本文的重点内容。

BPF的意义

极端点说，有了bpf match，iptables便仅仅成了一个框架，所有的匹配逻辑全部分离到了bpf程序中，人们再也不能说由于iptables规则的存在而执行效率低的问题在于iptables了，如果真的效率很低，那么一定是你的bpf程序写得不好！这就好比，我提供了一块CPU，然后你负责写程序，你把CPU给耗尽了还是无法满足你的计算需求，然而有的人就可以，我只能说，你的程序写的不好，而不是我的CPU不好。一样的道理。

我并不是想说这棵树是如何形成的，这不是本文的内容(如果想知道，请参考Linux内核Trie路由树的插入，查找，删除算法，具体文件是：net/ipv4/fib_trie.c)，我的意思是想说，一旦有了这棵树，我如何写一个bpf程序，来在该树上查找特定的IP地址。

我确实成功了，而且这并不难，毕竟Class文件就跟Windows PE和Linux ELF文件一样，都是具有标准的格式的，照着格式去一行一行写，虽然辛苦，但肯定是能成功的。一转眼就10年了，现在的风格依然还是一点没变，上周想了一个iptables前端优化之后，突然觉得可以用iptables的bpf match来模拟实现这个想法，我准备先手写一个bpf程序，然后再一探究竟。

HDWKHGDD-MNHSDHGHY