Hacking the Linux Kernel Network Stack 代码

==Phrack Inc.== Volume 0x0b, Issue 0x3d, Phile #0x0d of 0x0f |=------------=[ Hacking the Linux Kernel Network Stack ]=---------------=| |=-----------------------------------------------------------------------=| |=------------------=[ bioforge <alkerr@yifan.net> ]=--------------------=| 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 Libpcaps 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 fun