偶也来谈谈linux的核心堆栈!!!

Netfilter是Linux 2.4内核的一个子系统，Netfiler使得诸如数据包过滤、网络地址转换(NAT)以及网络连接跟踪等技巧成为可能，这些功能仅通过使用内核网络代码提供的各式各样的hook既可以完成。这些hook位于内核代码中，要么是静态链接的，要么是以动态加载的模块的形式存在。可以为指定的网络事件注册相应的回调函数，数据包的接收就是这样一个例子。


Hook 调用的时机
NF_IP_PRE_ROUTING 在完整性校验之后，选路确定之前
NF_IP_LOCAL_IN 在选路确定之后，且数据包的目的是本地主机
NF_IP_FORWARD 目的地是其它主机地数据包
NF_IP_LOCAL_OUT 来自本机进程的数据包在其离开本地主机的过程中
NF_IP_POST_ROUTING 在数据包离开本地主机“上线”之前

NF_IP_PRE_ROUTING这个hook是数据包被接收到之后调用的第一个hook，这个hook既是稍后将要描述的模块所用到的。当然，其它的hook同样非常有用，但是在这里，我们的焦点是在NF_IP_PRE_ROUTING这个hook上。

在hook函数完成了对数据包所需的任何的操作之后，它们必须返回下列预定义的Netfilter返回值中的一个：



返回值 含义
NF_DROP 丢弃该数据包
NF_ACCEPT 保留该数据包
NF_STOLEN 忘掉该数据包
NF_QUEUE 将该数据包插入到用户空间
NF_REPEAT 再次调用该hook函数

NF_DROP这个返回值的含义是该数据包将被完全的丢弃，所有为它分配的资源都应当被释放。NF_ACCEPT这个返回值告诉Netfilter：到目前为止，该数据包还是被接受的并且该数据包应当被递交到网络堆栈的下一个阶段。NF_STOLEN是一个有趣的返回值，因为它告诉Netfilter， “忘掉”这个数据包。这里告诉Netfilter的是：该hook函数将从此开始对数据包的处理，并且Netfilter应当放弃对该数据包做任何的处理。但是，这并不意味着该数据包的资源已经被释放。这个数据包以及它独自的sk_buff数据结构仍然有效，只是hook函数从Netfilter获取了该数据包的所有权。不幸的是，我还不是完全的清楚NF_QUEUE到底是如果工作的，因此在这里我不讨论它。最后一个返回值NF_REPEAT请求 Netfilter再次调用这个hook函数。显然，使用者应当谨慎使用NF_REPEAT这个返回值，以免造成死循环。

下面是注册和实现函数:

#define __KERNEL__
#define MODULE

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/netfilter.h>
#include <linux/netfilter_ipv4.h>

/* 用于注册我们的函数的数据结构 */
static struct nf_hook_ops nfho;

/* 注册的hook函数的实现 */
unsigned int hook_func(unsigned int hooknum,
struct sk_buff **skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
return NF_DROP; /* 丢弃所有的数据包 */
}

/* 初始化程序 */
int init_module()
{
/* 填充我们的hook数据结构 */
nfho.hook = hook_func; /* 处理函数 */
nfho.hooknum = NF_IP_PRE_ROUTING; /* 使用IPv4的第一个hook */
nfho.pf = PF_INET;
nfho.priority = NF_IP_PRI_FIRST; /* 让我们的函数首先执行 */

nf_register_hook(&nfho);

return 0;
}

/* 清除程序 */
void cleanup_module()
{
nf_unregister_hook(&nfho);
}

这就是全部内容，从示例代码1中，你可以看到，注销一个Netfilter hook是一件很简单事情，只需要调用nf_unregister_hook()函数，并且以你之前用于注册这个hook时用到的相同的数据结构的地址作为参


续谈(Netfilter 基本的数据报过滤技术)......................

支持，继续

好啊,那我就接着发给大家!



Netfilter 基本的数据报过滤技术
- 深入hook函数

现在是到了看看什么数据被传递到hook函数中以及这些数据如何被用于做过滤选择的时候了。那么，让我们更深入的看看nf_hookfn函数的原型吧。这个函数原型在linux/netfilter.h中给出，如下：

typedef unsigned int nf_hookfn(unsigned int hooknum,
struct sk_buff **skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *));

nf_hookfn函数的第一个参数用于指定表1中给出的hook类型中的一个。第二个参数更加有趣，它是一个指向指针的指针，该指针指向的指针指向一个 sk_buff数据结构，网络堆栈用sk_buff数据结构来描述数据包。这个数据结构在linux/skbuff.h中定义，由于它的内容太多，在这里我将仅列出其中有意义的部分。

sk_buff数据结构中最有用的部分可能就是那三个描述传输层包头（例如：UDP, TCP, ICMP, SPX）、网络层包头（例如：IPv4/6, IPX, RAW）以及链路层包头（例如：以太网或者RAW）的联合(union)了。这三个联合的名字分别是h、nh以及mac。这些联合包含了几个结构，依赖于具体的数据包中使用的协议。使用者应当注意：传输层包头和网络层包头可能是指向内存中的同一个位置。这是TCP数据包可能出现的情况，其中h和nh都应当被看作是指向IP头结构的指针。这意味着尝试通过h->th获取一个值，并认为该指针指向一个TCP头，将会得到错误的结果。因为h->th 实际上是指向的IP头，与nh->iph得到的结果相同。

接下来让我们感兴趣的其它部分是len和data这两个域。len指定了从data开始的数据包中的数据的总长度。好了，现在我们知道如何在sk_buff数据结构中分别访问协议头和数据包中的数据了。Netfilter hook函数中有用的信息中其它的有趣的部分是什么呢？

紧跟在skb之后的两个参数是指向net_device数据结构的指针，net_device数据结构被Linux内核用于描述所有类型的网络接口。这两个参数中的第一个――in，用于描述数据包到达的接口，毫无疑问，参数out用于描述数据包离开的接口。必须明白，在通常情况下，这两个参数中将只有一个被提供。例如：参数in只用于NF_IP_PRE_ROUTING和NF_IP_LOCAL_IN hook，参数out只用于NF_IP_LOCAL_OUT和NF_IP_POST_ROUTING hook。在这一个阶段中，我还没有测试对于NF_IP_FORWARD hook，这两个参数中哪些是有效的，但是如果你能在使用之前先确定这些指针是非空的，那么你是非常优秀的！

最后，传递给hook函数的最后一个参数是一个命名为okfn函数指针，该函数以一个sk_buff数据结构作为它唯一的参数，并且返回一个整型的值。我不是很确定这个函数是干什么用的，在net/core/netfilter.c中查看，有两个地方调用了这个okfn函数。这两个地方是分别在函数 nf_hook_slow()中以及函数nf_reinject()中，在其中的某个位置，当Netfilter hook的返回值为NF_ACCEPT时被调用。如果任何人有更多的关于okfn函数的信息，请务必告知。

** 译注：Linux核心网络堆栈中有一个全局变量 : struct list_head nf_hooks[NPROTO][NF_MAX_HOOKS]，该变量是一个二维数组，其中第一维用于指定协议族，第二维用于指定hook的类型（表1中定义的类型）。注册一个Netfilter hook实际就是在由协议族和hook类型确定的链表中添加一个新的节点。

以下代码摘自 net/core/netfilter，nf_register_hook()函数的实现：
int nf_register_hook(struct nf_hook_ops *reg)
{
struct list_head *i;

br_write_lock_bh(BR_NETPROTO_LOCK);
for (i = nf_hooks[reg->pf][reg->hooknum].next;
i != &nf_hooks[reg->pf][reg->hooknum];
i = i->next) {
if (reg->priority < ((struct nf_hook_ops *)i)->priority)
break;
}
list_add(&reg->list, i->prev);
br_write_unlock_bh(BR_NETPROTO_LOCK);
return 0;
}

Netfilter中定义了一个宏NF_HOOK，作者在前面提到的nf_hook_slow()函数实际上就是NF_HOOK宏定义替换的对象，在 NF_HOOK中执行注册的hook函数。NF_HOOK在Linux核心网络堆栈的适当的地方以适当的参数调用。例如，在ip_rcv()函数(位于 net/ipv4/ip_input.c)的最后部分，调用NF_HOOK函数，执行NF_IP_PRE_ROUTING类型的hook。ip_rcv ()是Linux核心网络堆栈中用于接收IPv4数据包的主要函数。在NF_HOOK的参数中，页包含一个okfn函数指针，该函数是用于数据包被接收后完成后续的操作，例如在ip_rcv中调用的NF_HOOK中的okfn函数指针指向ip_rcv_finish()函数(位于 net/ipv4/ip_input.c)，该函数用于IP数据包被接收后的诸如IP选项处理等后续处理。

如果在内核编译参数中取消CONFIG_NETFILTER宏定义，NF_HOOK宏定义直接被替换为okfn，内核代码中的相关部分如下(linux/netfilter.h)：

#ifdef CONFIG_NETFILTER
...
#ifdef CONFIG_NETFILTER_DEBUG
#define NF_HOOK nf_hook_slow
#else
#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \
(list_empty(&nf_hooks[(pf)][(hook)]) \
? (okfn)(skb) \
: nf_hook_slow((pf), (hook), (skb), (indev), (outdev), (okfn)))
#endif
...
#else /* !CONFIG_NETFILTER */
#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) (okfn)(skb)
#endif /*CONFIG_NETFILTER*/

可见okfn函数是必不可少的，当Netfilter被启用时，它用于完成接收的数据包后的后续操作，如果不启用Netfilter做数据包过滤，则所有的数据包都被接受，直接调用该函数做后续操作。

** 译注完

现在，我们已经了解了我们的hook函数接收到的信息中最有趣和最有用的部分，是该看看我们如何以各种各样的方式来利用这些信息来过滤数据包的时候了！

下面是:: 基于源接口的数据包过滤
         基于地址进行过滤
         基于数据包源地址的过滤
         基于TCP端口进行过滤






- 基于接口进行过滤

这应该是我们能做的最简单的过滤技术了。还记得我们的hook函数接收的参数中的那些net_device数据结构吗？使用相应的net_device数据结构的name这个成员，你就可以根据数据包的源接口和目的接口来选择是否丢弃它。如果想丢弃所有到达接口eth0的数据包，所有你需要做的仅仅是将 in->name的值与"eth0"做比较，如果名字匹配，那么hook函数简单的返回NF_DROP即可，数据包会被自动销毁。就是这么简单！完成该功能的示例代码见如下的示例代码2。注意，Light-Weight FireWall模块将会提供所有的本文提到的过滤方法的简单示例。它还包含了一个IOCTL接口以及用于动态改变其特性的应用程序。

示例代码2 : 基于源接口的数据包过滤
/*
* 安装一个丢弃所有进入我们指定接口的数据包的Netfilter hook函数的示例代码
*/

#define __KERNEL__
#define MODULE
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/netdevice.h>
#include <linux/netfilter.h>
#include <linux/netfilter_ipv4.h>
/* 用于注册我们的函数的数据结构 */
static struct nf_hook_ops nfho;

/* 我们丢弃的数据包来自的接口的名字 */
static char *drop_if = "lo";

/* 注册的hook函数的实现 */
unsigned int hook_func(unsigned int hooknum,
struct sk_buff **skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
if (strcmp(in->name, drop_if) == 0) {
printk("Dropped packet on %s...\n", drop_if);
return NF_DROP;
} else {
return NF_ACCEPT;
}
}

/* 初始化程序 */
int init_module()
{
/* 填充我们的hook数据结构 */
nfho.hook = hook_func; /* 处理函数 */
nfho.hooknum = NF_IP_PRE_ROUTING; /* 使用IPv4的第一个hook */
nfho.pf = PF_INET;
nfho.priority = NF_IP_PRI_FIRST; /* 让我们的函数首先执行 */

nf_register_hook(&nfho);

return 0;
}

/* 清除程序 */
void cleanup_module()
{
nf_unregister_hook(&nfho);
}

是不是很简单？接下来，让我们看看基于IP地址的过滤。


基于地址进行过滤


与根据数据包的接口进行过滤类似，基于数据包的源或目的IP地址进行过滤同样简单。这次我们感兴趣的是sk_buff数据结构。还记得skb参数是一个指向sk_buff数据结构的指针的指针吗？为了避免犯错误，声明一个另外的指向skb_buff数据结构的指针并且将skb指针指向的指针赋值给这个新的指针是一个好习惯，就像这样：

struct sk_buff *sb = *skb; /* Remove 1 level of indirection* /

这样，你访问这个数据结构的元素时只需要反引用一次就可以了。获取一个数据包的IP头通过使用sk_buff数据结构中的网络层包头来完成。这个头位于一个联合中，可以通过sk_buff->nh.iph这样的方式来访问。示例代码3中的函数演示了当得到一个数据包的sk_buff数据结构时，如何利用它来检查收到的数据包的源IP地址与被禁止的地址是否相同。这些代码是直接从LWFW中取出来的，唯一不同的是LWFW统计的更新被移除。

示例代码3 : 检查收到的数据包的源IP

unsigned char *deny_ip = "\x7f\x00\x00\x01"; /* 127.0.0.1 */

...

static int check_ip_packet(struct sk_buff *skb)
{
/* We don't want any NULL pointers in the chain to
* the IP header. */
if (!skb )return NF_ACCEPT;
if (!(skb->nh.iph)) return NF_ACCEPT;

if (skb->nh.iph->saddr == *(unsigned int *)deny_ip) {
return NF_DROP;
}

return NF_ACCEPT;
}

这样，如果数据包的源地址与我们设定的丢弃数据包的地址匹配，那么该数据包将被丢弃。为了使这个函数能按预期的方式工作，deny_ip的值应当以网络字节序(Big-endian，与Intel相反)存放。虽然这个函数不太可能以一个空的指针作为参数来调用，带一点点偏执狂从来不会有什么坏处。当然，如果错误确实发生了，那么该函数将会返回NF_ACCEPT。这样Netfilter可以继续处理这个数据包。示例代码4展现了用于演示将基于接口的过滤略做修改以丢弃匹配给定IP地址的数据包的简单模块。

示例代码4 : 基于数据包源地址的过滤
/* 安装丢弃所有来自指定IP地址的数据包的Netfilter hook的示例代码 */

#define __KERNEL__
#define MODULE

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/skbuff.h>
#include <linux/ip.h> /* For IP header */
#include <linux/netfilter.h>
#include <linux/netfilter_ipv4.h>

/* 用于注册我们的函数的数据结构 */
static struct nf_hook_ops nfho;

/* 我们要丢弃的数据包来自的地址，网络字节序 */
static unsigned char *drop_ip = "\x7f\x00\x00\x01";

/* 注册的hook函数的实现 */
unsigned int hook_func(unsigned int hooknum,
struct sk_buff **skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
struct sk_buff *sb = *skb;

// 译注：作者提供的代码中比较地址是否相同的方法是错误的，见注释掉的部分
if (sb->nh.iph->saddr == *(unsigned int *)drop_ip) {
// if (sb->nh.iph->saddr == drop_ip) {
printk("Dropped packet from... %d.%d.%d.%d\n",
*drop_ip, *(drop_ip + 1),
*(drop_ip + 2), *(drop_ip + 3));
return NF_DROP;
} else {
return NF_ACCEPT;
}
}

/* 初始化程序 */
int init_module()
{
/* 填充我们的hook数据结构 */
nfho.hook = hook_func; /* 处理函数 */
nfho.hooknum = NF_IP_PRE_ROUTING; /* 使用IPv4的第一个hook */
nfho.pf = PF_INET;
nfho.priority = NF_IP_PRI_FIRST; /* 让我们的函数首先执行 */

nf_register_hook(&nfho);

return 0;
}

/* 清除程序 */
void cleanup_module()
{
nf_unregister_hook(&nfho);
}


- 基于TCP端口进行过滤

另一个要实现的简单规则是基于数据包的TCP目的端口进行过滤。这只比检查IP地址的要求要高一点点，因为我们需要自己创建一个TCP头的指针。还记得我们前面讨论的关于传输层包头与网络层包头的内容吗？获取一个TCP头的指针是一件简单的事情――分配一个tcphdr数据结构(在linux/tcp.h 中定义)的指针，并将它指向我们的数据包中IP头之后的数据。或许一个例子的帮助会更大一些，示例代码5给出了检查数据包的TCP目的端口是否与某个我们要丢弃数据包的端口匹配的代码。与示例代码3一样，这些代码摘自LWFW。

示例代码5 : 检查收到的数据包的TCP目的端口
unsigned char *deny_port = "\x00\x19"; /* port 25 */

...

static int check_tcp_packet(struct sk_buff *skb)
{
struct tcphdr *thead;

/* We don't want any NULL pointers in the chain
* to the IP header. */
if (!skb ) return NF_ACCEPT;
if (!(skb->nh.iph)) return NF_ACCEPT;

/* Be sure this is a TCP packet first */
if (skb->nh.iph->protocol != IPPROTO_TCP) {
return NF_ACCEPT;
}

thead = (struct tcphdr *)(skb->data +
(skb->nh.iph->ihl * 4));

/* Now check the destination port */
if ((thead->dest) == *(unsigned short *)deny_port) {
return NF_DROP;
}

return NF_ACCEPT;
}

确实很简单！不要忘了，要让这个函数工作，deny_port必须是网络字节序。这就是数据包过滤的基础了，你应当已经清楚的理解了对于一个特定的数据包，如何获取你想要的信息。现在，是该进入更有趣的内容的时候了！




还有一些是:Netfilter hook的其它可能用法
有需要的话,我可以接着发给大家.

ding！！！
请问分析内核网络，使用什么参考书

使用:<<Linux内核技术内幕>>

- Netfilter hook的其它可能用法

在这里，我将提出其它很酷的利用Netfilter hook的点子，5.1节将简单的给出精神食粮，而5.2节将讨论和给出可以工作的基于内核的FTP密码嗅探器的代码，它的远程密码获取功能是确实可用的。事实上，它工作的令我吃惊的好，并且我编写了它。

- 隐藏后门的守护进程

核心模块编程也许是Linux开发中最有趣的部分之一了，在内核中编写代码意味着你在一个仅受限于你的想象力的地方写代码。以恶意的观点来看，你可以隐藏文件、进程，并且做各式各样很酷的，任何的rootkit能够做的事情。那么，以不太恶意的观点来看（是的，持这中观点人们的确存在），你可以隐藏文件、进程以及干各式各样的事情。内核真是一个迷人的乐园！

有了赋予内核级程序员的强大力量，很多事情成为可能。其中最有趣的（也是让系统管理员恐慌的）一个就是嵌入到内核中的后门。毕竟，如果后门不作为一个进程运行，那么我们怎么知道它的运行？当然，还是有办法让你的内核揪出这样的后门来，但是它们可不像运行ps命令一样容易和简单。现今，将后门代码放到内核中去的点子已经并不新鲜了。但是，我在这里所提出的是安放一个用作内核后门的简单的网络服务。你猜对了，正是Netfilter hook！

如果你已经具备必要的技能并且情愿以做试验的名义使你的内核崩溃，那么你就可以构建简单但是有用的，完全位于内核中的，可以远程访问的网络服务了。基本上一个Netfilter hook可以通过观察收到的数据包来查找一个“魔法”数据包，并且当接收到这个“魔法”数据包时干指定的事情。结果可以通过Netfilter hook来发送。并且该hook函数可以返回NF_STOLEN，以使得收到的“魔法”数据包可以走得更远。但是要注意，当以这种方式来发送时，输出数据包对于输出Netfilter hook仍然是可见的。因此用户空间完全不知道这个“魔法”数据包的曾经到达，但是它们还是能看到你送所出的。当心！因为在泄密主机上的嗅探器不能看到这个包并不意味着在其它中间宿主主机上的嗅探器也看不到这个包。

kossak与lifeline曾为Phrack写了一篇精彩的文章，该文描述了如何通过注册数据包类型处理器来完成这样的功能。虽然本文涉及的是Netfilter hook，我仍然建议阅读他们的这篇文章（第55期，文件12），因为它是一篇给出了一些非常有趣的点子的有趣读物。

那么，后门Netfilter hook可以干些什么工作呢？以下是一些建议：
-- 远程访问击键记录器(key-logger)。模块记录击键，并且当远程主机发送一个PING请求时，结果被送到该主机。这样，可以生成一个类似于稳定的（非洪水的）PING应答流的击键信息的流。当然，你可能想要实现一个简单的加密，这样，ASCII键不会立即暴露它们自己，并且某些警觉的系统管理员会想：“坚持，我以前都是通过我的SSH会话来键入那些的！Oh mailto:$%@T&!”。
-- 各种简单的管理员任务，例如获取当前登录到主机的用户的列表或责获取打开的网络连接的信息。
-- 并非一个真正的后门，而是位于网络边界的模块，并且阻挡任何被疑为来自特洛伊木马、ICMP隐蔽通道或者像KaZaa这样的文件共享工具的通信。
-- 文件传输“服务器”。我最近已经实现了这个主意，由此引起的Linux核心编程是数小时的乐趣
-- 数据包跳跃。重定向目的为木马主机指定端口的数据包到其它的IP主机和端口，并且从那台主机发回数据包到发起者。没有进程被派生，并且最妙的是，没有网络套接字被打开。
-- 上面描述的数据包跳跃用于与网络中的关键系统以半隐蔽方式通信。例如：配置路由器等。
-- FTP/POP3/Telnet密码嗅探器。嗅探输出的密码并保存相关信息，直到进入的“魔法”数据包要求获取它们。

以上只是一些想法的简短的列表，其中最后一个想法是我们在接下来的一节中将要真正详细讨论的。它
提供了一个很好的了解更多的深藏于核心网络代码中的函数的机会。

- 基于内核的FTP密码嗅探器

在这里展现的是一个简单的，原理性的，用做Netfilter后门的模块。该模块嗅探输出的FTP数据包，查找对于一个FTP服务器一个USER于 PASS命令对。当这样一个命令对被发现后，该模块接下来将等待一个“魔法”ICMP ECHO(ping)数据包，该数据包应当足够大，使其能返回服务器的IP地址、用户名以及密码。同时提供了一个快速的发送一个“魔法”数据包，获取返回然后打印返回信息的技巧。一旦用户名/密码对从模块读取后，模块将接着查找下一对。注意，模块每次只保存一个对。以上是简要的浏览，是该展示更多的细节，来看模块如何做到这些的时候了。

当模块加载时，模块的init_module()函数简单的注册了两个Netfilter hook。第一个用于查看输入的数据包(在NF_IP_PRE_ROUTING处)，尝试发现“魔法”ICMP数据包。接下来的一个用于查看离开该模块被安装的主机的数据包(在NF_IP_POST_ROUTING处)，这个函数正是搜索和捕获FTP的USER和PASS数据包的地方。 cleanup_module()函数只是简单的注销这两个hook。

watch_out()是用于hook NF_IP_POST_ROUTING的函数，查看这个函数你可以看到，它的执行的操作非常简单。当一个数据包进入这个函数过后，将经过各种检查，以确定它是一个FTP数据包。如果它不是一个FTP数据包，那么立即返回NF_ACCEPT。如果它是一个FTP数据包，那么该模块进行检查是否已经存在一个用户名/密码对。如果存在（以have_pair的非零值标识），那么返回NF_ACCEPT，该数据包最终能够离开该系统。否则，check_ftp() 函数被调用，这是密码提取实际发生的地方。如果没有先前的数据包已经被接收，那么target_ip和target_port变量应当被清除。

check_ftp()开始于从数据包的开始查找"USER"，"PASS"或"QUIT"。注意直到USER命令处理之后才处理PASS命令。这样做的目的是为了防止在某些情况下PASS命令先于USER命令被接收到以及在USER到达之前连接中断而导致的死锁的发生。同样，如果QUIT命令到达时仅有用户名被捕获，那么将重置操作，开始嗅探一个新的连接。当一个USER或者PASS命令到达时，如果必要完整性校验通过，则记录下命令的参数。正常运行下，在check_ftp()函数完成之前，检查是否已经有了一个有效的用户名和密码串。如果是，则设置have_pair的值为非零并且在当前的用户名 /密码对被获取之前不会再抓取其它的用户名或密码。

到目前为止你已经看到了该模块如何安装它自己以及如何开始搜寻待记录的用户名和密码。接下来你将看到当指定的“魔法”数据包到达时会发生什么。在此需特别注意，因为这是在整个开发过程中出现的最大难题。如果我没记错的话，共遭遇了16个核心错误。当数据包进安装该模块的主机时，watch_in()检查每一个数据包以查看其是否是一个“魔法”数据包。如果数据包不能提供足以证明它是一个“魔法”数据包的信息，那么它将被被watch_in()忽略，简单的返回一个NF_ACCEPT。注意“魔法”数据包的标准之一是它们必须有足够的空间来存放IP地址以及用户名和密码串。这使得发送应答更加容易。当然，可以重新分配一个新的sk_buff，但是正确的获取所有必要的域得值可能会比较困难，并且你还必须得正确的获取它们！因此，与其为我们的应答数据包创建一个新的数据结构，不如简单的调整请求数据包的数据结构。为了成功的返回数据包，需要做几个改动。首先，交换IP地址，并且sk_buff数据结构中描述数据包类型的域(pkt_type)应当被换成PACKET_OUTGOING，这些宏在linux/if_packet.h中定义。接下来应当小心的是确定包含了任意的链路层头。我们接收到的数据包的sk_buff数据结构的数据域指向链路层头之后，并且它是指向被发送的数据包的数据的开始的数据域。那么对于需要链路层包头（以太网及环回和点对点的raw）的接口，我们将数据域指向mac.ethernet或者mac.raw结构。为确定这个数据包来自的什么类型的接口你可以查看sb->dev->type的值，其中sb是一个指向sk_buff数据结构的指针。这个域的有效值可以在 linux/if_arp.h中找到，但其中最有用的几个在下面的表3中列出。

表3 : 接口类型的常用值

类型代码 接口类型
ARPHRD_ETHER 以太网
ARPHRD_LOOPBACK 环回设备
ARPHRD_PPP 点对点（例如拨号）

最后，我们要做的是真正的复制我们想在的应答中送出的数据。到送出数据包的时候了，dev_queue_xmit()函数以一个指向sk_buff数据结构的指针作为它唯一的参数，在“好的错误”情况下，返回一个负的错误代码。我所说的“好的错误”是什么意思呢？如果你给函数dev_queue_xmit ()一个错误构造的套接字缓冲，那么你就会得到一个伴随着内核错误和内核堆栈的dump信息的“不太好的错误”。看看在这里错误如何能被分成两组？最后， watch_in()返回NF_STOLEN，以告诉Netfilter忘掉它曾经见到过这个数据包。如果你已经调用了dev_queue_xmit ()，不要返回NF_DROP！这是因为dev_queue_xmit()将释放传递进来的套接字缓冲，而Netfilter会尝试对被NF_DROP的数据包做同样的操作。好了。对于代码的讨论已经足够了，请看具体的代码。