#FORMAT IRC I'm going to talk this evening about netfilter netfilter is the packet filtering / packet mangling / NAT framework of the Linux 2.4 kernel series Some slides and a script for this talk are avaliable at http://www.gnumonks.org/papers/netfilter-lk2000 I expect the autitorium to be familiar with TCP/IP basics, as well as being familiar with iptables and packet filtering in general oops... ipchains of course :) in other words: You should know how the 2.2 packet filtering (ipchains) works ;) first a bit of an introduction: What is netfilter? Netfilter is a generalized framework of hooks in the network stack any kernel module can plug into one or more of these hooks an will receive each packet traversing this hook the netfilter hooks are currently implemented for IPv4, IPv6 and DECnet. (i've heared recently, that somebody wants to implement them for IPX, too) these hooks are placed in well-chosen points of the protocol stack. The traditional packet filtering, as well as all kinds of network address translation and packet mangling are implemented on top of these hooks. so netfilter is definitely more than a firewalling subsystem - it's a superset of that. The next introductory question is: Why did we need netfilter? Because the old 2.2 code was way too complex it was scattered around the whole IPv4 code there were about 25 places in the IPv4 code, where we had a #ifdef CONFIG_IP_FIREWALL ... #else ... #endif which is quite bad. furthermore, all packet handling had to be done in kernel masquerading was a hack to the packet filtering code and the filtering rules are bound to interface addresses. The 2.2 code was not very extensible, you could only write masquerading helper modules like ip_masq_irc / ip_masq_ftp / ... ... now to the last part of the introduction: Who did netfilter? The main part of netfilter design and implementation was done by Rusty Russel Rusty is also the co-author of ipchains and Linux Kernel Firewall Maintainer for the last years. He got sponsored for one year to concentrate on the firewalling code - and the result was netfilter Some other people joined him in different stages of the development: Marc Boucher, James Morris and the last one is myswelf. The 'formal' core team consists out of us four people. Of course there are numoerous other contributors, you can see them at http://netfilter.kernelnotes.org/scoreboard.html So let's begin the main part of this presentation: PART 1 - netfilter basics I was talking about these hooks at particular points in the network stack. I'm going to concentrate on IPv4, as this seems to be the most important case :) --->[1]--->[ROUTE]--->[3]--->[4]---> | ^ | | | [ROUTE] v | [2] [5] | ^ | | v | on the left hand, you have incoming packets, coming from the network on the right hand, outgoing packets are leaving to the network on the bottom of the picture is our local machine, the local userspace processes. the 5 hooks are called: 1 NF_IP_PRE_ROUTING 2 NF_IP_LOCAL_IN 3 NF_IP_FORWARD 4 NF_IP_POST_ROUTING 5 NF_IP_LOCAL_OUT so let's view at the path a packet goes while being forwarded by our machine: Firs it comes off the wire, it passes hook #1. The routing decision is made, it passes hook #3 (forward), passes hook #4 (post_routing) and leaves off to the network again. If we look on packets which have a local destionation (are locally terminated an are not routed), the following path: packet comes off the wire packet hits hoo #1 (pre_routing) routing decision decides that packet is local packet hits hook #2 (local_in) packet hits local process If we look at a locally-originated packet: packet is generated by local process at the bottom packet hits hook #5 (local_out) routing code decides where to route the packet packet passes hook #4 (post_routing) packet hits the wire of the network (btw: i want to concentrate on the talk and handle questions after the talk, this way i can concentrate on the talk...) (anyway, you can collect the questions at #qc, if you want) Now we know how packets traverse the netfilter hooks As I said, any kernel module may register on one or more of these hooks, and a callback-function is called for each packet passing this particular hook the module may then return a verdict about the packet's future: NF_ACCEPT = continue traversal as normal NF_DROP = drop the packet silently, do not continue NF_STOLEN = I (as the hook-registered module) have taken over the packet, do not continue NF_QUEUE = enqueue packet to userspace (i'm going to say more about this later) NF_REPEAT = please call this hook again packet filtering / NAT / packet mangling is implemented using IP tables on each of these netfilter hooks. IP TABLES: IP tables are tables of rules, which a packet traverses from top to bottom each rule in an IP table consists out of matches, which specify how the packet must look like, if it is to match this rule and one target, which tells us what to do if this particular rule matches. IP tables are implemented as reusable component - in fact, netfilter it self uses currently three instances of IP tables. But any other kernel module may also use IP tables (for example as an IPsec SPDB) The three tables implemented in netfilter itself are: 'filter', 'nat' and 'mangle' Connectiontracking: Connection tracking is another part, which is implemented on top of the netfileter hooks. conntrack enables us to do stateful firewalling. That is: Decide upon the fate of a packet not only by data from this packet, but also by information about the state of the connection the packet belongs to. i'm going to say more about connection tracking later. First I want to talk about the three IP tables: PART II - packet filtering Packet filtering is implemented using the three hooks NF_IP_LOCAL_IN NF_IP_FORWAD and NF_IP_LOCAL_OUT each packet passes only one of these three hooks: locally originated packets traverse only NF_IP_LOCAL_OUT locally terminated packets traverse only NF_IP_LOCAL_IN and forwarded packets traverse only NF_IP_FORWARD the 'filter' table connects one chain to each of these three hooks: NF_IP_LOCAL_IN = INPUT chain NF_IP_LOCAL_OUT = OUTPUT chian NF_IP_FORWARD = FORWARD chain (the names are the same as in 2.2 - only uppercase) but BE AWARE: the behaviour which packet traverses which chain has changed from the 2.2 behaviour i.e. a forwarded packet only hits the FORWARD chain, _not_ INPUT and OUTPUT also to know how we insert filtering rules in the chains of the 'filter' table, we have to examine the IP tables a bit further As I said, the IP tables are implemented very generic, so there's one userspace tool, which is able to configure/modify all kindes of tables/chains each rule in a chain consists out of - match(es) which specify things like source address, destination address, port numbers, ... - target (what to do if this rule matches) To configure these rules, we have the tool called 'iptables' I'm going to explain some of the iptables commands: To fully specify an iptables command, we need the following information: - which table to work on - which chain in this table to use - the operation (append, insert , delete, modify, ) - at least one match - and exactly one target the syntax is something like: iptables - t table -Operation chain -j target match(es) to give a very basic example: iptables -t filter -A INPUT -j ACCEPT -p tcp --dport smtp which -A(ppend)s a rule to the INPUT chain of the 'filter' table and the rule itself ACCEPTs all tcp packets which have a destination port of 25 (smtp) now we have to know what matches and targets we have available as targets, we have : ACCEPT - accept the packet DROP - silently drop the packet (this is the 2.2 DENY) QUEUE - queue the packet to an userspace process RETURN - return to previous (calling) chain foobar - jump to an userdefined chain REJECT - drop the packet and inform the sender about it LOG - log the packet via syslog, continue traversal ULOG - send the packet to an userspace logging process MIRROR - change source/destination IP and resend the packet (for testing purpose) now the available matches: -p protocol (tcp/udp/icmp/...) -s source address -d destination address -i incoming interface -o outgoing interface --dport destination port --sport source port --state (NEW,ESTABLISHED,RELATED,INVALID) (i'm comming back to that) --mac-source source MAC address --mark nfmark value --tos TOS value of the packet --ttl ttl value of the packet --limit (limit the rate of this packet to a certain amount of pkts/timeframe) knowing about the matches and targets, you are now able to configure your packet filter. I'm coming back to the connection tracking stuff this is a real advantage of the new 2.4 code: stateful firewalling the connection tracking code keeps track of all current connections going through our router/firewall each packet is assigned one of the state values: NEW (packet would establish a new connection, if we let it pass) ESTABLISHED (packet is part of an already established connection) RELATED (packet is somehow related to an already established connection) INVALID (packet is multicast or something else whe really don't know what it is so now we could do something like: iptables -A FORWARD -j ACCEPT -m state --state ESTABLISHED,RELATED which lets only all packets belonging to an already established connection and the related ones pass. if we now block all NEW packets from the 'outer' interface (internet) and allow NEW packets from the inside interface, we'll have the basic config of most firewalls so how does this differ from blocking packets which have the SYN flag set? connection tracking is generic and currently handles TCP, UDP and ICMP so for example we don't accept icmp echo replies, if we didn't send an icmp echo request before the connection tracking is extensible in two ways: - application helper modules (like ip_conntrack_ftp, ip_conntrack_irc) for specific protocols - protocol helper modules (for tracking the state of other protocols than tcp/udp/icmp) the ip_contrack_ftp for example marks all incoming ftp data connections as RELATED now we can do active ftp through a firewall which doesn't have to accept all connections to internal ip's with ports > 1024 anymore! ok... time for the next parT: PART III - NAT in 2.2 we only had the masquerading code, which deals with a special case of NAT (network address translation) in 2.4 we have all kinds of differnet nat: SNAT (source address NAT), and MASQUERADE as a special case of that DNAT (destination address NAT), and REDIRECT as a special case source nat is done at the POST_ROUTING hook destination nat is done at the PRE_ROUTING hook i'll begin with a small example of SNAT: iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.4 -o eth0 this will NAT all packets to be sent out on eth0 to the new source address of 1.2.3.4 (it of course does the inverse mapping for the reply packets) SNAT is useful for NAT cases, where you have a statically assigned IP address. If your outgoing interfaces has a dynamically assigned IP address, you may use the MASQUERADE target. iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0 is an example for masqing all traffic on interface ppp0. the address to which the packets are nat'ed is the interface address of ppp0 it's always the current address of ppp0, so IP address changes don't need any special handling. The next part is DNAT: small example: iptables -t nat -A PREROUTING -j DNAT --to-destination 1.2.3.4:8080 -t tcp --dport 80 -i eth0 which NAT's all tcp packets, coming through interface eth0 and going to a webserver to 1.2.3.4:808 8080 of coruse this is quite useful if you want to do transparent www proxying REDIRECT is a special case of DNAT: iptables -t nat -A PREROUTING -j REDIRECT --to-port 3128 -i eth1 -p tcp --dport 80 all tcp packets from eth1 going to any webserver on port 80 are redirected to a proxy running on the local machine PART IV - Packet mangling this is something really new, which 2.2.x code didn't have at all the 'mangle' table lets you mangle any arbitrary information inside the packets while they pass our local machine currently we have only three targets implemented: TOS - change the TOS bit field in the header TTL - change the TTL field in the header (increment/decrement/set) MARK - set the packet's skb->nfmark fielt to a particular value of course you can again use all the matches available for packet filtering and nat. a simple example: iptables -t mangle -A PREROUITING -j MARK --set-mark 10 -p tcp --dport 80 which set's the nfmark field of each packet's skb to 10, if it is tcp and has a destination port of 9- 80 all matches and targets are implemented as separate modules, so you can at any time write new match and/or target modules There are two more 'advanced concepts' of netfilter, I want to introduce: - Queuing if you have a rule, which has the target QUEUE, the packet is inserted into a special queue inside netfilter the packets in this queue are transmitted over a netlink socket to a userspace process. this userspace process can now do whatever it wans with the packet (including its data) and re-inject it at exactly the place it came from the process can (of course) also set the verdict of this packet (like: DROP this packet, ACCEPT the other one) this enables people to write some firewalling code in userspace, and (hopefully) keeps the kernel clean from too complex code. - Userspace logging Very similar to queuing, although it is unidirectional if you insert a rule with the ULOG target, the packet is copied and sent through a netlink multicast socket one or more userspace processes may listen to this netlink multicast socket and receive the copy of the packet the userspace process may now gather all information it needs and log it to a logfile/database/whatever we've already implemented ulogd, which is a plugin-extensible logging daemon attaching to the ULOG target So.... we are heading the end of my talk.... last chapter: Current development and future: - full TCP sequence number tracking - port more matches/targets to IPv6 - support for more application protocol helpers for NAT (RPC, SMB, SNMP, ...) - more matches (like 'accept all packets as long as the number of connections to this port doesn't raise about N) - multicast support - infrastructure for having conntrack and nat helpers in userspace At the end some useful links: This presentation: http://www.gnumonks.org/papers/netfilter-lk2000 netfilter homepage: http://netfilter.kernelnotes.org links to the mailinglist(s) and the archives, as well as the iptables userspace tool are on the netfilter homepage we also have a bunch of documents you might be interested in: The 2.4 packet filtering howto, the 2.4 NAT howto, the netfilter hacking howto, and some more stuff everything should be linked from the netfilter homepage Thank you, it was very informative :) Thanks for your interest in this talk... I'll deal with questions now ---- CategoryDocs