19885
Comment:
|
17917
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
<La``Forge> I'm going to talk this evening about netfilter [[BR]] <La``Forge> netfilter is the packet filtering / packet mangling / NAT framework of the Linux 2.4 kernel series[[BR]] <La``Forge> Some slides and a script for this talk are avaliable at [http://www.gnumonks.org/papers/netfilter-lk2000][[BR]] <La``Forge> I expect the autitorium to be familiar with TCP/IP basics, as well as being familiar with iptables and packet filtering in general[[BR]] <La``Forge> oops... ipchains of course :)[[BR]] <La``Forge> in other words: You should know how the 2.2 packet filtering (ipchains) works ;)[[BR]] <La``Forge> first a bit of an introduction:[[BR]] <La``Forge> What is netfilter?[[BR]] <La``Forge> Netfilter is a generalized framework of hooks in the network stack[[BR]] <La``Forge> any kernel module can plug into one or more of these hooks an will receive each packet traversing this hook[[BR]] <La``Forge> the netfilter hooks are currently implemented for IPv4, IPv6 and DECnet.[[BR]] <La``Forge> (i've heared recently, that somebody wants to implement them for IPX, too)[[BR]] <La``Forge> these hooks are placed in well-chosen points of the protocol stack.[[BR]] <La``Forge> The traditional packet filtering, as well as all kinds of network address translation and packet mangling are implemented on top of these hooks.[[BR]] <La``Forge> so netfilter is definitely more than a firewalling subsystem - it's a superset of that.[[BR]] <La``Forge> The next introductory question is: [[BR]] <La``Forge> Why did we need netfilter?[[BR]] <La``Forge> Because the old 2.2 code was way too complex[[BR]] <La``Forge> it was scattered around the whole IPv4 code[[BR]] <La``Forge> there were about 25 places in the IPv4 code, where we had a #ifdef CONFIG_IP_FIREWALL ... #else ... #endif [[BR]] <La``Forge> which is quite bad.[[BR]] <La``Forge> furthermore, all packet handling had to be done in kernel[[BR]] <La``Forge> masquerading was a hack to the packet filtering code[[BR]] <La``Forge> and the filtering rules are bound to interface addresses.[[BR]] <La``Forge> The 2.2 code was not very extensible, you could only write masquerading helper modules like ip_masq_irc / ip_masq_ftp / ...[[BR]] <La``Forge> ... now to the last part of the introduction:[[BR]] <La``Forge> Who did netfilter?[[BR]] <La``Forge> The main part of netfilter design and implementation was done by Rusty Russel[[BR]] <La``Forge> Rusty is also the co-author of ipchains and Linux Kernel Firewall Maintainer for the last years.[[BR]] <La``Forge> He got sponsored for one year to concentrate on the firewalling code - and the result was netfilter[[BR]] <La``Forge> Some other people joined him in different stages of the development: Marc Boucher, James Morris and the last one is myswelf.[[BR]] <La``Forge> 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][[BR]] <La``Forge> So let's begin the main part of this presentation:[[BR]] <La``Forge> PART 1 - netfilter basics[[BR]] <La``Forge> I was talking about these hooks at particular points in the network stack.[[BR]] <La``Forge> I'm going to concentrate on IPv4, as this seems to be the most important case :)[[BR]] <La``Forge> --->[1]--->[ROUTE]--->[3]--->[4]--->[[BR]] <La``Forge> | ^[[BR]] <La``Forge> | |[[BR]] <La``Forge> | [ROUTE][[BR]] <La``Forge> v |[[BR]] <La``Forge> [2] [5][[BR]] <La``Forge> | ^[[BR]] <La``Forge> | |[[BR]] <La``Forge> v |[[BR]] <La``Forge> [[BR]] <La``Forge> on the left hand, you have incoming packets, coming from the network[[BR]] <La``Forge> on the right hand, outgoing packets are leaving to the network[[BR]] <La``Forge> on the bottom of the picture is our local machine, the local userspace processes.[[BR]] <La``Forge> the 5 hooks are called:[[BR]] <La``Forge> 1 NF_IP_PRE_ROUTING[[BR]] <La``Forge> 2 NF_IP_LOCAL_IN[[BR]] <La``Forge> 3 NF_IP_FORWARD[[BR]] <La``Forge> 4 NF_IP_POST_ROUTING[[BR]] <La``Forge> 5 NF_IP_LOCAL_OUT[[BR]] <La``Forge> so let's view at the path a packet goes while being forwarded by our machine:[[BR]] <La``Forge> Firs it comes off the wire, it passes hook #1. The routing decision is made,[[BR]] <La``Forge> it passes hook #3 (forward), passes hook #4 (post_routing) and leaves off to the network again.[[BR]] <La``Forge> If we look on packets which have a local destionation (are locally terminated an are not routed), the following path:[[BR]] <La``Forge> packet comes off the wire[[BR]] <La``Forge> packet hits hoo #1 (pre_routing)[[BR]] <La``Forge> routing decision decides that packet is local[[BR]] <La``Forge> packet hits hook #2 (local_in)[[BR]] <La``Forge> packet hits local process[[BR]] <La``Forge> [[BR]] <La``Forge> If we look at a locally-originated packet:[[BR]] <La``Forge> packet is generated by local process at the bottom[[BR]] <La``Forge> packet hits hook #5 (local_out)[[BR]] <La``Forge> routing code decides where to route the packet[[BR]] <La``Forge> packet passes hook #4 (post_routing)[[BR]] <La``Forge> packet hits the wire of the network[[BR]] <La``Forge> (btw: i want to concentrate on the talk and handle questions after the talk, this way i can concentrate on the talk...)[[BR]] <La``Forge> (anyway, you can collect the questions at #qc, if you want)[[BR]] <La``Forge> Now we know how packets traverse the netfilter hooks[[BR]] <La``Forge> 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[[BR]] <La``Forge> the module may then return a verdict about the packet's future:[[BR]] <La``Forge> NF_ACCEPT = continue traversal as normal[[BR]] <La``Forge> NF_DROP = drop the packet silently, do not continue[[BR]] <La``Forge> NF_STOLEN = I (as the hook-registered module) have taken over the packet, do not continue[[BR]] <La``Forge> NF_QUEUE = enqueue packet to userspace (i'm going to say more about this later)[[BR]] <La``Forge> NF_REPEAT = please call this hook again[[BR]] <La``Forge> packet filtering / NAT / packet mangling is implemented using IP tables on each of these netfilter hooks.[[BR]] <La``Forge> IP TABLES:[[BR]] <La``Forge> IP tables are tables of rules, which a packet traverses from top to bottom[[BR]] <La``Forge> 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[[BR]] <La``Forge> and one target, which tells us what to do if this particular rule matches.[[BR]] <La``Forge> IP tables are implemented as reusable component - in fact, netfilter it self uses currently three instances of IP tables.[[BR]] <La``Forge> But any other kernel module may also use IP tables (for example as an IPsec SPDB)[[BR]] <La``Forge> The three tables implemented in netfilter itself are: 'filter', 'nat' and 'mangle'[[BR]] <La``Forge> Connectiontracking:[[BR]] <La``Forge> Connection tracking is another part, which is implemented on top of the netfileter hooks.[[BR]] <La``Forge> 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.[[BR]] <La``Forge> i'm going to say more about connection tracking later.[[BR]] <La``Forge> First I want to talk about the three IP tables:[[BR]] <La``Forge> PART II - packet filtering[[BR]] <La``Forge> Packet filtering is implemented using the three hooks NF_IP_LOCAL_IN[[BR]] <La``Forge> NF_IP_FORWAD and NF_IP_LOCAL_OUT[[BR]] <La``Forge> each packet passes only one of these three hooks:[[BR]] <La``Forge> locally originated packets traverse only NF_IP_LOCAL_OUT[[BR]] <La``Forge> locally terminated packets traverse only NF_IP_LOCAL_IN[[BR]] <La``Forge> and forwarded packets traverse only NF_IP_FORWARD[[BR]] <La``Forge> the 'filter' table connects one chain to each of these three hooks:[[BR]] <La``Forge> NF_IP_LOCAL_IN = INPUT chain[[BR]] <La``Forge> NF_IP_LOCAL_OUT = OUTPUT chian[[BR]] <La``Forge> NF_IP_FORWARD = FORWARD chain[[BR]] <La``Forge> (the names are the same as in 2.2 - only uppercase)[[BR]] <La``Forge> but BE AWARE: the behaviour which packet traverses which chain has changed from the 2.2 behaviour[[BR]] <La``Forge> i.e. a forwarded packet only hits the FORWARD chain, _not_ INPUT and OUTPUT also[[BR]] <La``Forge> to know how we insert filtering rules in the chains of the 'filter' table, we have to examine the IP tables a bit further[[BR]] <La``Forge> 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[[BR]] <La``Forge> each rule in a chain consists out of [[BR]] <La``Forge> - match(es) which specify things like source address, destination address, port numbers, ...[[BR]] <La``Forge> - target (what to do if this rule matches)[[BR]] <La``Forge> To configure these rules, we have the tool called 'iptables'[[BR]] <La``Forge> I'm going to explain some of the iptables commands:[[BR]] <La``Forge> To fully specify an iptables command, we need the following information:[[BR]] <La``Forge> - which table to work on[[BR]] <La``Forge> - which chain in this table to use[[BR]] <La``Forge> - the operation (append, insert , delete, modify, )[[BR]] <La``Forge> - at least one match [[BR]] <La``Forge> - and exactly one target[[BR]] <La``Forge> the syntax is something like:[[BR]] <La``Forge> iptables - t table -Operation chain -j target match(es)[[BR]] <La``Forge> to give a very basic example:[[BR]] <La``Forge> iptables -t filter -A INPUT -j ACCEPT -p tcp --dport smtp[[BR]] <La``Forge> which -A(ppend)s a rule to the INPUT chain of the 'filter' table [[BR]] <La``Forge> and the rule itself ACCEPTs all tcp packets which have a destination port of 25 (smtp)[[BR]] <La``Forge> now we have to know what matches and targets we have available[[BR]] <La``Forge> as targets, we have :[[BR]] <La``Forge> ACCEPT - accept the packet[[BR]] <La``Forge> DROP - silently drop the packet (this is the 2.2 DENY)[[BR]] <La``Forge> QUEUE - queue the packet to an userspace process [[BR]] <La``Forge> RETURN - return to previous (calling) chain[[BR]] <La``Forge> foobar - jump to an userdefined chain[[BR]] <La``Forge> REJECT - drop the packet and inform the sender about it[[BR]] <La``Forge> LOG - log the packet via syslog, continue traversal[[BR]] <La``Forge> ULOG - send the packet to an userspace logging process [[BR]] <La``Forge> MIRROR - change source/destination IP and resend the packet (for testing purpose)[[BR]] <La``Forge> now the available matches:[[BR]] <La``Forge> -p protocol (tcp/udp/icmp/...)[[BR]] <La``Forge> -s source address[[BR]] <La``Forge> -d destination address[[BR]] <La``Forge> -i incoming interface[[BR]] <La``Forge> -o outgoing interface[[BR]] <La``Forge> --dport destination port[[BR]] <La``Forge> --sport source port[[BR]] <La``Forge> --state (NEW,ESTABLISHED,RELATED,INVALID) (i'm comming back to that)[[BR]] <La``Forge> --mac-source source MAC address[[BR]] <La``Forge> --mark nfmark value[[BR]] <La``Forge> --tos TOS value of the packet[[BR]] <La``Forge> --ttl ttl value of the packet[[BR]] <La``Forge> --limit (limit the rate of this packet to a certain amount of pkts/timeframe)[[BR]] <La``Forge> [[BR]] <La``Forge> knowing about the matches and targets, you are now able to configure your packet filter.[[BR]] <La``Forge> I'm coming back to the connection tracking stuff[[BR]] <La``Forge> this is a real advantage of the new 2.4 code:[[BR]] <La``Forge> stateful firewalling[[BR]] <La``Forge> the connection tracking code keeps track of all current connections going through our router/firewall[[BR]] <La``Forge> each packet is assigned one of the state values:[[BR]] <La``Forge> NEW (packet would establish a new connection, if we let it pass)[[BR]] <La``Forge> ESTABLISHED (packet is part of an already established connection)[[BR]] <La``Forge> RELATED (packet is somehow related to an already established connection)[[BR]] <La``Forge> INVALID (packet is multicast or something else whe really don't know what it is[[BR]] <La``Forge> so now we could do something like:[[BR]] <La``Forge> iptables -A FORWARD -j ACCEPT -m state --state ESTABLISHED,RELATED[[BR]] <La``Forge> which lets only all packets belonging to an already established connection and the related ones pass.[[BR]] <La``Forge> if we now block all NEW packets from the 'outer' interface (internet)[[BR]] <La``Forge> and allow NEW packets from the inside interface, we'll have the basic config of most firewalls[[BR]] <La``Forge> so how does this differ from blocking packets which have the SYN flag set?[[BR]] <La``Forge> connection tracking is generic and currently handles TCP, UDP and ICMP[[BR]] <La``Forge> so for example we don't accept icmp echo replies, if we didn't send an icmp echo request before[[BR]] <La``Forge> the connection tracking is extensible in two ways:[[BR]] <La``Forge> - application helper modules (like ip_conntrack_ftp, ip_conntrack_irc) for specific protocols[[BR]] <La``Forge> - protocol helper modules (for tracking the state of other protocols than tcp/udp/icmp)[[BR]] <La``Forge> the ip_contrack_ftp for example marks all incoming ftp data connections as RELATED[[BR]] <La``Forge> 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![[BR]] <La``Forge> ok... time for the next parT:[[BR]] <La``Forge> PART III - NAT[[BR]] <La``Forge> in 2.2 we only had the masquerading code, which deals with a special case of NAT (network address translation)[[BR]] <La``Forge> in 2.4 we have all kinds of differnet nat:[[BR]] <La``Forge> SNAT (source address NAT), and MASQUERADE as a special case of that[[BR]] <La``Forge> DNAT (destination address NAT), and REDIRECT as a special case [[BR]] <La``Forge> source nat is done at the POST_ROUTING hook[[BR]] <La``Forge> destination nat is done at the PRE_ROUTING hook[[BR]] <La``Forge> i'll begin with a small example of SNAT:[[BR]] <La``Forge> iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.4 -o eth0[[BR]] <La``Forge> this will NAT all packets to be sent out on eth0 to the new source address of 1.2.3.4[[BR]] <La``Forge> (it of course does the inverse mapping for the reply packets)[[BR]] <La``Forge> SNAT is useful for NAT cases, where you have a statically assigned IP address.[[BR]] <La``Forge> If your outgoing interfaces has a dynamically assigned IP address, you may use the MASQUERADE target.[[BR]] <La``Forge> iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0[[BR]] <La``Forge> is an example for masqing all traffic on interface ppp0.[[BR]] <La``Forge> the address to which the packets are nat'ed is the interface address of ppp0[[BR]] <La``Forge> it's always the current address of ppp0, so IP address changes don't need any special handling.[[BR]] <La``Forge> The next part is DNAT:[[BR]] <La``Forge> small example:[[BR]] <La``Forge> iptables -t nat -A PREROUTING -j DNAT --to-destination 1.2.3.4:8080 -t tcp --dport 80 -i eth0[[BR]] <La``Forge> which NAT's all tcp packets, coming through interface eth0 and going to a webserver to 1.2.3.4:808[[BR]] <La``Forge> 8080 of coruse[[BR]] <La``Forge> this is quite useful if you want to do transparent www proxying[[BR]] <La``Forge> REDIRECT is a special case of DNAT:[[BR]] <La``Forge> iptables -t nat -A PREROUTING -j REDIRECT --to-port 3128 -i eth1 -p tcp --dport 80[[BR]] <La``Forge> all tcp packets from eth1 going to any webserver on port 80 are redirected to a proxy running on the local machine[[BR]] <La``Forge> PART IV - Packet mangling[[BR]] <La``Forge> this is something really new, which 2.2.x code didn't have at all[[BR]] <La``Forge> the 'mangle' table lets you mangle any arbitrary information inside the packets while they pass our local machine[[BR]] <La``Forge> currently we have only three targets implemented:[[BR]] <La``Forge> TOS - change the TOS bit field in the header[[BR]] <La``Forge> TTL - change the TTL field in the header (increment/decrement/set)[[BR]] <La``Forge> MARK - set the packet's skb->nfmark fielt to a particular value[[BR]] <La``Forge> of course you can again use all the matches available for packet filtering and nat.[[BR]] <La``Forge> a simple example:[[BR]] <La``Forge> iptables -t mangle -A PREROUITING -j MARK --set-mark 10 -p tcp --dport 80[[BR]] <La``Forge> which set's the nfmark field of each packet's skb to 10, if it is tcp and has a destination port of 9-[[BR]] <La``Forge> 80[[BR]] <La``Forge> all matches and targets are implemented as separate modules, so you can at any time write new match and/or target modules [[BR]] <La``Forge> There are two more 'advanced concepts' of netfilter, I want to introduce:[[BR]] <La``Forge> - Queuing[[BR]] <La``Forge> if you have a rule, which has the target QUEUE, the packet is inserted into a special queue inside netfilter[[BR]] <La``Forge> the packets in this queue are transmitted over a netlink socket to a userspace process.[[BR]] <La``Forge> 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[[BR]] <La``Forge> the process can (of course) also set the verdict of this packet (like: DROP this packet, ACCEPT the other one)[[BR]] <La``Forge> this enables people to write some firewalling code in userspace, and (hopefully) keeps the kernel clean from too complex code.[[BR]] <La``Forge> - Userspace logging[[BR]] <La``Forge> Very similar to queuing, although it is unidirectional[[BR]] <La``Forge> if you insert a rule with the ULOG target, the packet is copied and sent through a netlink multicast socket[[BR]] <La``Forge> one or more userspace processes may listen to this netlink multicast socket and receive the copy of the packet[[BR]] <La``Forge> the userspace process may now gather all information it needs and log it to a logfile/database/whatever[[BR]] <La``Forge> we've already implemented ulogd, which is a plugin-extensible logging daemon attaching to the ULOG target[[BR]] <La``Forge> So.... we are heading the end of my talk.... last chapter:[[BR]] <La``Forge> Current development and future:[[BR]] <La``Forge> - full TCP sequence number tracking[[BR]] <La``Forge> - port more matches/targets to IPv6[[BR]] <La``Forge> - support for more application protocol helpers for NAT (RPC, SMB, SNMP, ...)[[BR]] <La``Forge> - more matches (like 'accept all packets as long as the number of connections to this port doesn't raise about N)[[BR]] <La``Forge> - multicast support[[BR]] <La``Forge> - infrastructure for having conntrack and nat helpers in userspace[[BR]] <La``Forge> [[BR]] <La``Forge> At the end some useful links:[[BR]] <La``Forge> This presentation: [[BR]] <La``Forge> [http://www.gnumonks.org/papers/netfilter-lk2000][[BR]] <La``Forge> netfilter homepage: [http://netfilter.kernelnotes.org][[BR]] <La``Forge> links to the mailinglist(s) and the archives, as well as the iptables userspace tool are on the netfilter homepage[[BR]] <La``Forge> 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[[BR]] <La``Forge> everything should be linked from the netfilter homepage[[BR]] <Blu3> Thank you, it was very informative :)[[BR]] <La``Forge> Thanks for your interest in this talk... I'll deal with questions now[[BR]] |
#FORMAT IRC <LaForge> I'm going to talk this evening about netfilter <LaForge> netfilter is the packet filtering / packet mangling / NAT framework of the Linux 2.4 kernel series <LaForge> Some slides and a script for this talk are avaliable at http://www.gnumonks.org/papers/netfilter-lk2000 <LaForge> I expect the autitorium to be familiar with TCP/IP basics, as well as being familiar with iptables and packet filtering in general <LaForge> oops... ipchains of course :) <LaForge> in other words: You should know how the 2.2 packet filtering (ipchains) works ;) <LaForge> first a bit of an introduction: <LaForge> What is netfilter? <LaForge> Netfilter is a generalized framework of hooks in the network stack <LaForge> any kernel module can plug into one or more of these hooks an will receive each packet traversing this hook <LaForge> the netfilter hooks are currently implemented for IPv4, IPv6 and DECnet. <LaForge> (i've heared recently, that somebody wants to implement them for IPX, too) <LaForge> these hooks are placed in well-chosen points of the protocol stack. <LaForge> The traditional packet filtering, as well as all kinds of network address translation and packet mangling are implemented on top of these hooks. <LaForge> so netfilter is definitely more than a firewalling subsystem - it's a superset of that. <LaForge> The next introductory question is: <LaForge> Why did we need netfilter? <LaForge> Because the old 2.2 code was way too complex <LaForge> it was scattered around the whole IPv4 code <LaForge> there were about 25 places in the IPv4 code, where we had a #ifdef CONFIG_IP_FIREWALL ... #else ... #endif <LaForge> which is quite bad. <LaForge> furthermore, all packet handling had to be done in kernel <LaForge> masquerading was a hack to the packet filtering code <LaForge> and the filtering rules are bound to interface addresses. <LaForge> The 2.2 code was not very extensible, you could only write masquerading helper modules like ip_masq_irc / ip_masq_ftp / ... <LaForge> ... now to the last part of the introduction: <LaForge> Who did netfilter? <LaForge> The main part of netfilter design and implementation was done by Rusty Russel <LaForge> Rusty is also the co-author of ipchains and Linux Kernel Firewall Maintainer for the last years. <LaForge> He got sponsored for one year to concentrate on the firewalling code - and the result was netfilter <LaForge> Some other people joined him in different stages of the development: Marc Boucher, James Morris and the last one is myself. <LaForge> 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 <LaForge> So let's begin the main part of this presentation: <LaForge> PART 1 - netfilter basics <LaForge> I was talking about these hooks at particular points in the network stack. <LaForge> I'm going to concentrate on IPv4, as this seems to be the most important case :) <LaForge> --->[1]--->[ROUTE]--->[3]--->[4]---> <LaForge> | ^ <LaForge> | | <LaForge> | [ROUTE] <LaForge> v | <LaForge> [2] [5] <LaForge> | ^ <LaForge> | | <LaForge> v | <LaForge> <LaForge> on the left hand, you have incoming packets, coming from the network <LaForge> on the right hand, outgoing packets are leaving to the network <LaForge> on the bottom of the picture is our local machine, the local userspace processes. <LaForge> the 5 hooks are called: <LaForge> 1 NF_IP_PRE_ROUTING <LaForge> 2 NF_IP_LOCAL_IN <LaForge> 3 NF_IP_FORWARD <LaForge> 4 NF_IP_POST_ROUTING <LaForge> 5 NF_IP_LOCAL_OUT <LaForge> so let's view at the path a packet goes while being forwarded by our machine: <LaForge> Firs it comes off the wire, it passes hook #1. The routing decision is made, <LaForge> it passes hook #3 (forward), passes hook #4 (post_routing) and leaves off to the network again. <LaForge> If we look on packets which have a local destionation (are locally terminated an are not routed), the following path: <LaForge> packet comes off the wire <LaForge> packet hits hook #1 (pre_routing) <LaForge> routing decision decides that packet is local <LaForge> packet hits hook #2 (local_in) <LaForge> packet hits local process <LaForge> <LaForge> If we look at a locally-originated packet: <LaForge> packet is generated by local process at the bottom <LaForge> packet hits hook #5 (local_out) <LaForge> routing code decides where to route the packet <LaForge> packet passes hook #4 (post_routing) <LaForge> packet hits the wire of the network <LaForge> (btw: i want to concentrate on the talk and handle questions after the talk, this way i can concentrate on the talk...) <LaForge> (anyway, you can collect the questions at #qc, if you want) <LaForge> Now we know how packets traverse the netfilter hooks <LaForge> 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 <LaForge> the module may then return a verdict about the packet's future: <LaForge> NF_ACCEPT = continue traversal as normal <LaForge> NF_DROP = drop the packet silently, do not continue <LaForge> NF_STOLEN = I (as the hook-registered module) have taken over the packet, do not continue <LaForge> NF_QUEUE = enqueue packet to userspace (i'm going to say more about this later) <LaForge> NF_REPEAT = please call this hook again <LaForge> packet filtering / NAT / packet mangling is implemented using IP tables on each of these netfilter hooks. <LaForge> IP TABLES: <LaForge> IP tables are tables of rules, which a packet traverses from top to bottom <LaForge> 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 <LaForge> and one target, which tells us what to do if this particular rule matches. <LaForge> IP tables are implemented as reusable component - in fact, netfilter it self uses currently three instances of IP tables. <LaForge> But any other kernel module may also use IP tables (for example as an IPsec SPDB) <LaForge> The three tables implemented in netfilter itself are: 'filter', 'nat' and 'mangle' <LaForge> Connectiontracking: <LaForge> Connection tracking is another part, which is implemented on top of the netfileter hooks. <LaForge> 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. <LaForge> i'm going to say more about connection tracking later. <LaForge> First I want to talk about the three IP tables: <LaForge> PART II - packet filtering <LaForge> Packet filtering is implemented using the three hooks NF_IP_LOCAL_IN <LaForge> NF_IP_FORWAD and NF_IP_LOCAL_OUT <LaForge> each packet passes only one of these three hooks: <LaForge> locally originated packets traverse only NF_IP_LOCAL_OUT <LaForge> locally terminated packets traverse only NF_IP_LOCAL_IN <LaForge> and forwarded packets traverse only NF_IP_FORWARD <LaForge> the 'filter' table connects one chain to each of these three hooks: <LaForge> NF_IP_LOCAL_IN = INPUT chain <LaForge> NF_IP_LOCAL_OUT = OUTPUT chian <LaForge> NF_IP_FORWARD = FORWARD chain <LaForge> (the names are the same as in 2.2 - only uppercase) <LaForge> but BE AWARE: the behaviour which packet traverses which chain has changed from the 2.2 behaviour <LaForge> i.e. a forwarded packet only hits the FORWARD chain, _not_ INPUT and OUTPUT also <LaForge> to know how we insert filtering rules in the chains of the 'filter' table, we have to examine the IP tables a bit further <LaForge> 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 <LaForge> each rule in a chain consists out of <LaForge> - match(es) which specify things like source address, destination address, port numbers, ... <LaForge> - target (what to do if this rule matches) <LaForge> To configure these rules, we have the tool called 'iptables' <LaForge> I'm going to explain some of the iptables commands: <LaForge> To fully specify an iptables command, we need the following information: <LaForge> - which table to work on <LaForge> - which chain in this table to use <LaForge> - the operation (append, insert , delete, modify, ) <LaForge> - at least one match <LaForge> - and exactly one target <LaForge> the syntax is something like: <LaForge> iptables - t table -Operation chain -j target match(es) <LaForge> to give a very basic example: <LaForge> iptables -t filter -A INPUT -j ACCEPT -p tcp --dport smtp <LaForge> which -A(ppend)s a rule to the INPUT chain of the 'filter' table <LaForge> and the rule itself ACCEPTs all tcp packets which have a destination port of 25 (smtp) <LaForge> now we have to know what matches and targets we have available <LaForge> as targets, we have : <LaForge> ACCEPT - accept the packet <LaForge> DROP - silently drop the packet (this is the 2.2 DENY) <LaForge> QUEUE - queue the packet to an userspace process <LaForge> RETURN - return to previous (calling) chain <LaForge> foobar - jump to an userdefined chain <LaForge> REJECT - drop the packet and inform the sender about it <LaForge> LOG - log the packet via syslog, continue traversal <LaForge> ULOG - send the packet to an userspace logging process <LaForge> MIRROR - change source/destination IP and resend the packet (for testing purpose) <LaForge> now the available matches: <LaForge> -p protocol (tcp/udp/icmp/...) <LaForge> -s source address <LaForge> -d destination address <LaForge> -i incoming interface <LaForge> -o outgoing interface <LaForge> --dport destination port <LaForge> --sport source port <LaForge> --state (NEW,ESTABLISHED,RELATED,INVALID) (i'm comming back to that) <LaForge> --mac-source source MAC address <LaForge> --mark nfmark value <LaForge> --tos TOS value of the packet <LaForge> --ttl ttl value of the packet <LaForge> --limit (limit the rate of this packet to a certain amount of pkts/timeframe) <LaForge> <LaForge> knowing about the matches and targets, you are now able to configure your packet filter. <LaForge> I'm coming back to the connection tracking stuff <LaForge> this is a real advantage of the new 2.4 code: <LaForge> stateful firewalling <LaForge> the connection tracking code keeps track of all current connections going through our router/firewall <LaForge> each packet is assigned one of the state values: <LaForge> NEW (packet would establish a new connection, if we let it pass) <LaForge> ESTABLISHED (packet is part of an already established connection) <LaForge> RELATED (packet is somehow related to an already established connection) <LaForge> INVALID (packet is multicast or something else whe really don't know what it is <LaForge> so now we could do something like: <LaForge> iptables -A FORWARD -j ACCEPT -m state --state ESTABLISHED,RELATED <LaForge> which lets only all packets belonging to an already established connection and the related ones pass. <LaForge> if we now block all NEW packets from the 'outer' interface (internet) <LaForge> and allow NEW packets from the inside interface, we'll have the basic config of most firewalls <LaForge> so how does this differ from blocking packets which have the SYN flag set? <LaForge> connection tracking is generic and currently handles TCP, UDP and ICMP <LaForge> so for example we don't accept icmp echo replies, if we didn't send an icmp echo request before <LaForge> the connection tracking is extensible in two ways: <LaForge> - application helper modules (like ip_conntrack_ftp, ip_conntrack_irc) for specific protocols <LaForge> - protocol helper modules (for tracking the state of other protocols than tcp/udp/icmp) <LaForge> the ip_contrack_ftp for example marks all incoming ftp data connections as RELATED <LaForge> 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! <LaForge> ok... time for the next parT: <LaForge> PART III - NAT <LaForge> in 2.2 we only had the masquerading code, which deals with a special case of NAT (network address translation) <LaForge> in 2.4 we have all kinds of differnet nat: <LaForge> SNAT (source address NAT), and MASQUERADE as a special case of that <LaForge> DNAT (destination address NAT), and REDIRECT as a special case <LaForge> source nat is done at the POST_ROUTING hook <LaForge> destination nat is done at the PRE_ROUTING hook <LaForge> i'll begin with a small example of SNAT: <LaForge> iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.4 -o eth0 <LaForge> this will NAT all packets to be sent out on eth0 to the new source address of 1.2.3.4 <LaForge> (it of course does the inverse mapping for the reply packets) <LaForge> SNAT is useful for NAT cases, where you have a statically assigned IP address. <LaForge> If your outgoing interfaces has a dynamically assigned IP address, you may use the MASQUERADE target. <LaForge> iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0 <LaForge> is an example for masqing all traffic on interface ppp0. <LaForge> the address to which the packets are nat'ed is the interface address of ppp0 <LaForge> it's always the current address of ppp0, so IP address changes don't need any special handling. <LaForge> The next part is DNAT: <LaForge> small example: <LaForge> iptables -t nat -A PREROUTING -j DNAT --to-destination 1.2.3.4:8080 -t tcp --dport 80 -i eth0 <LaForge> which NAT's all tcp packets, coming through interface eth0 and going to a webserver to 1.2.3.4:808 <LaForge> 8080 of coruse <LaForge> this is quite useful if you want to do transparent www proxying <LaForge> REDIRECT is a special case of DNAT: <LaForge> iptables -t nat -A PREROUTING -j REDIRECT --to-port 3128 -i eth1 -p tcp --dport 80 <LaForge> all tcp packets from eth1 going to any webserver on port 80 are redirected to a proxy running on the local machine <LaForge> PART IV - Packet mangling <LaForge> this is something really new, which 2.2.x code didn't have at all <LaForge> the 'mangle' table lets you mangle any arbitrary information inside the packets while they pass our local machine <LaForge> currently we have only three targets implemented: <LaForge> TOS - change the TOS bit field in the header <LaForge> TTL - change the TTL field in the header (increment/decrement/set) <LaForge> MARK - set the packet's skb->nfmark fielt to a particular value <LaForge> of course you can again use all the matches available for packet filtering and nat. <LaForge> a simple example: <LaForge> iptables -t mangle -A PREROUITING -j MARK --set-mark 10 -p tcp --dport 80 <LaForge> which set's the nfmark field of each packet's skb to 10, if it is tcp and has a destination port of 9- <LaForge> 80 <LaForge> all matches and targets are implemented as separate modules, so you can at any time write new match and/or target modules <LaForge> There are two more 'advanced concepts' of netfilter, I want to introduce: <LaForge> - Queuing <LaForge> if you have a rule, which has the target QUEUE, the packet is inserted into a special queue inside netfilter <LaForge> the packets in this queue are transmitted over a netlink socket to a userspace process. <LaForge> 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 <LaForge> the process can (of course) also set the verdict of this packet (like: DROP this packet, ACCEPT the other one) <LaForge> this enables people to write some firewalling code in userspace, and (hopefully) keeps the kernel clean from too complex code. <LaForge> - Userspace logging <LaForge> Very similar to queuing, although it is unidirectional <LaForge> if you insert a rule with the ULOG target, the packet is copied and sent through a netlink multicast socket <LaForge> one or more userspace processes may listen to this netlink multicast socket and receive the copy of the packet <LaForge> the userspace process may now gather all information it needs and log it to a logfile/database/whatever <LaForge> we've already implemented ulogd, which is a plugin-extensible logging daemon attaching to the ULOG target <LaForge> So.... we are heading the end of my talk.... last chapter: <LaForge> Current development and future: <LaForge> - full TCP sequence number tracking <LaForge> - port more matches/targets to IPv6 <LaForge> - support for more application protocol helpers for NAT (RPC, SMB, SNMP, ...) <LaForge> - more matches (like 'accept all packets as long as the number of connections to this port doesn't raise about N) <LaForge> - multicast support <LaForge> - infrastructure for having conntrack and nat helpers in userspace <LaForge> <LaForge> At the end some useful links: <LaForge> This presentation: <LaForge> http://www.gnumonks.org/papers/netfilter-lk2000 <LaForge> netfilter homepage: http://netfilter.kernelnotes.org <LaForge> links to the mailinglist(s) and the archives, as well as the iptables userspace tool are on the netfilter homepage <LaForge> 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 <LaForge> everything should be linked from the netfilter homepage <Blu3> Thank you, it was very informative :) <LaForge> Thanks for your interest in this talk... I'll deal with questions now |
1 <LaForge> I'm going to talk this evening about netfilter
2 <LaForge> netfilter is the packet filtering / packet mangling / NAT framework of the Linux 2.4 kernel series
3 <LaForge> Some slides and a script for this talk are avaliable at http://www.gnumonks.org/papers/netfilter-lk2000
4 <LaForge> I expect the autitorium to be familiar with TCP/IP basics, as well as being familiar with iptables and packet filtering in general
5 <LaForge> oops... ipchains of course :)
6 <LaForge> in other words: You should know how the 2.2 packet filtering (ipchains) works ;)
7 <LaForge> first a bit of an introduction:
8 <LaForge> What is netfilter?
9 <LaForge> Netfilter is a generalized framework of hooks in the network stack
10 <LaForge> any kernel module can plug into one or more of these hooks an will receive each packet traversing this hook
11 <LaForge> the netfilter hooks are currently implemented for IPv4, IPv6 and DECnet.
12 <LaForge> (i've heared recently, that somebody wants to implement them for IPX, too)
13 <LaForge> these hooks are placed in well-chosen points of the protocol stack.
14 <LaForge> The traditional packet filtering, as well as all kinds of network address translation and packet mangling are implemented on top of these hooks.
15 <LaForge> so netfilter is definitely more than a firewalling subsystem - it's a superset of that.
16 <LaForge> The next introductory question is:
17 <LaForge> Why did we need netfilter?
18 <LaForge> Because the old 2.2 code was way too complex
19 <LaForge> it was scattered around the whole IPv4 code
20 <LaForge> there were about 25 places in the IPv4 code, where we had a #ifdef CONFIG_IP_FIREWALL ... #else ... #endif
21 <LaForge> which is quite bad.
22 <LaForge> furthermore, all packet handling had to be done in kernel
23 <LaForge> masquerading was a hack to the packet filtering code
24 <LaForge> and the filtering rules are bound to interface addresses.
25 <LaForge> The 2.2 code was not very extensible, you could only write masquerading helper modules like ip_masq_irc / ip_masq_ftp / ...
26 <LaForge> ... now to the last part of the introduction:
27 <LaForge> Who did netfilter?
28 <LaForge> The main part of netfilter design and implementation was done by Rusty Russel
29 <LaForge> Rusty is also the co-author of ipchains and Linux Kernel Firewall Maintainer for the last years.
30 <LaForge> He got sponsored for one year to concentrate on the firewalling code - and the result was netfilter
31 <LaForge> Some other people joined him in different stages of the development: Marc Boucher, James Morris and the last one is myself.
32 <LaForge> 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
33 <LaForge> So let's begin the main part of this presentation:
34 <LaForge> PART 1 - netfilter basics
35 <LaForge> I was talking about these hooks at particular points in the network stack.
36 <LaForge> I'm going to concentrate on IPv4, as this seems to be the most important case :)
37 <LaForge> --->[1]--->[ROUTE]--->[3]--->[4]--->
38 <LaForge> | ^
39 <LaForge> | |
40 <LaForge> | [ROUTE]
41 <LaForge> v |
42 <LaForge> [2] [5]
43 <LaForge> | ^
44 <LaForge> | |
45 <LaForge> v |
46 <LaForge>
47 <LaForge> on the left hand, you have incoming packets, coming from the network
48 <LaForge> on the right hand, outgoing packets are leaving to the network
49 <LaForge> on the bottom of the picture is our local machine, the local userspace processes.
50 <LaForge> the 5 hooks are called:
51 <LaForge> 1 NF_IP_PRE_ROUTING
52 <LaForge> 2 NF_IP_LOCAL_IN
53 <LaForge> 3 NF_IP_FORWARD
54 <LaForge> 4 NF_IP_POST_ROUTING
55 <LaForge> 5 NF_IP_LOCAL_OUT
56 <LaForge> so let's view at the path a packet goes while being forwarded by our machine:
57 <LaForge> Firs it comes off the wire, it passes hook #1. The routing decision is made,
58 <LaForge> it passes hook #3 (forward), passes hook #4 (post_routing) and leaves off to the network again.
59 <LaForge> If we look on packets which have a local destionation (are locally terminated an are not routed), the following path:
60 <LaForge> packet comes off the wire
61 <LaForge> packet hits hook #1 (pre_routing)
62 <LaForge> routing decision decides that packet is local
63 <LaForge> packet hits hook #2 (local_in)
64 <LaForge> packet hits local process
65 <LaForge>
66 <LaForge> If we look at a locally-originated packet:
67 <LaForge> packet is generated by local process at the bottom
68 <LaForge> packet hits hook #5 (local_out)
69 <LaForge> routing code decides where to route the packet
70 <LaForge> packet passes hook #4 (post_routing)
71 <LaForge> packet hits the wire of the network
72 <LaForge> (btw: i want to concentrate on the talk and handle questions after the talk, this way i can concentrate on the talk...)
73 <LaForge> (anyway, you can collect the questions at #qc, if you want)
74 <LaForge> Now we know how packets traverse the netfilter hooks
75 <LaForge> 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
76 <LaForge> the module may then return a verdict about the packet's future:
77 <LaForge> NF_ACCEPT = continue traversal as normal
78 <LaForge> NF_DROP = drop the packet silently, do not continue
79 <LaForge> NF_STOLEN = I (as the hook-registered module) have taken over the packet, do not continue
80 <LaForge> NF_QUEUE = enqueue packet to userspace (i'm going to say more about this later)
81 <LaForge> NF_REPEAT = please call this hook again
82 <LaForge> packet filtering / NAT / packet mangling is implemented using IP tables on each of these netfilter hooks.
83 <LaForge> IP TABLES:
84 <LaForge> IP tables are tables of rules, which a packet traverses from top to bottom
85 <LaForge> 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
86 <LaForge> and one target, which tells us what to do if this particular rule matches.
87 <LaForge> IP tables are implemented as reusable component - in fact, netfilter it self uses currently three instances of IP tables.
88 <LaForge> But any other kernel module may also use IP tables (for example as an IPsec SPDB)
89 <LaForge> The three tables implemented in netfilter itself are: 'filter', 'nat' and 'mangle'
90 <LaForge> Connectiontracking:
91 <LaForge> Connection tracking is another part, which is implemented on top of the netfileter hooks.
92 <LaForge> 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.
93 <LaForge> i'm going to say more about connection tracking later.
94 <LaForge> First I want to talk about the three IP tables:
95 <LaForge> PART II - packet filtering
96 <LaForge> Packet filtering is implemented using the three hooks NF_IP_LOCAL_IN
97 <LaForge> NF_IP_FORWAD and NF_IP_LOCAL_OUT
98 <LaForge> each packet passes only one of these three hooks:
99 <LaForge> locally originated packets traverse only NF_IP_LOCAL_OUT
100 <LaForge> locally terminated packets traverse only NF_IP_LOCAL_IN
101 <LaForge> and forwarded packets traverse only NF_IP_FORWARD
102 <LaForge> the 'filter' table connects one chain to each of these three hooks:
103 <LaForge> NF_IP_LOCAL_IN = INPUT chain
104 <LaForge> NF_IP_LOCAL_OUT = OUTPUT chian
105 <LaForge> NF_IP_FORWARD = FORWARD chain
106 <LaForge> (the names are the same as in 2.2 - only uppercase)
107 <LaForge> but BE AWARE: the behaviour which packet traverses which chain has changed from the 2.2 behaviour
108 <LaForge> i.e. a forwarded packet only hits the FORWARD chain, _not_ INPUT and OUTPUT also
109 <LaForge> to know how we insert filtering rules in the chains of the 'filter' table, we have to examine the IP tables a bit further
110 <LaForge> 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
111 <LaForge> each rule in a chain consists out of
112 <LaForge> - match(es) which specify things like source address, destination address, port numbers, ...
113 <LaForge> - target (what to do if this rule matches)
114 <LaForge> To configure these rules, we have the tool called 'iptables'
115 <LaForge> I'm going to explain some of the iptables commands:
116 <LaForge> To fully specify an iptables command, we need the following information:
117 <LaForge> - which table to work on
118 <LaForge> - which chain in this table to use
119 <LaForge> - the operation (append, insert , delete, modify, )
120 <LaForge> - at least one match
121 <LaForge> - and exactly one target
122 <LaForge> the syntax is something like:
123 <LaForge> iptables - t table -Operation chain -j target match(es)
124 <LaForge> to give a very basic example:
125 <LaForge> iptables -t filter -A INPUT -j ACCEPT -p tcp --dport smtp
126 <LaForge> which -A(ppend)s a rule to the INPUT chain of the 'filter' table
127 <LaForge> and the rule itself ACCEPTs all tcp packets which have a destination port of 25 (smtp)
128 <LaForge> now we have to know what matches and targets we have available
129 <LaForge> as targets, we have :
130 <LaForge> ACCEPT - accept the packet
131 <LaForge> DROP - silently drop the packet (this is the 2.2 DENY)
132 <LaForge> QUEUE - queue the packet to an userspace process
133 <LaForge> RETURN - return to previous (calling) chain
134 <LaForge> foobar - jump to an userdefined chain
135 <LaForge> REJECT - drop the packet and inform the sender about it
136 <LaForge> LOG - log the packet via syslog, continue traversal
137 <LaForge> ULOG - send the packet to an userspace logging process
138 <LaForge> MIRROR - change source/destination IP and resend the packet (for testing purpose)
139 <LaForge> now the available matches:
140 <LaForge> -p protocol (tcp/udp/icmp/...)
141 <LaForge> -s source address
142 <LaForge> -d destination address
143 <LaForge> -i incoming interface
144 <LaForge> -o outgoing interface
145 <LaForge> --dport destination port
146 <LaForge> --sport source port
147 <LaForge> --state (NEW,ESTABLISHED,RELATED,INVALID) (i'm comming back to that)
148 <LaForge> --mac-source source MAC address
149 <LaForge> --mark nfmark value
150 <LaForge> --tos TOS value of the packet
151 <LaForge> --ttl ttl value of the packet
152 <LaForge> --limit (limit the rate of this packet to a certain amount of pkts/timeframe)
153 <LaForge>
154 <LaForge> knowing about the matches and targets, you are now able to configure your packet filter.
155 <LaForge> I'm coming back to the connection tracking stuff
156 <LaForge> this is a real advantage of the new 2.4 code:
157 <LaForge> stateful firewalling
158 <LaForge> the connection tracking code keeps track of all current connections going through our router/firewall
159 <LaForge> each packet is assigned one of the state values:
160 <LaForge> NEW (packet would establish a new connection, if we let it pass)
161 <LaForge> ESTABLISHED (packet is part of an already established connection)
162 <LaForge> RELATED (packet is somehow related to an already established connection)
163 <LaForge> INVALID (packet is multicast or something else whe really don't know what it is
164 <LaForge> so now we could do something like:
165 <LaForge> iptables -A FORWARD -j ACCEPT -m state --state ESTABLISHED,RELATED
166 <LaForge> which lets only all packets belonging to an already established connection and the related ones pass.
167 <LaForge> if we now block all NEW packets from the 'outer' interface (internet)
168 <LaForge> and allow NEW packets from the inside interface, we'll have the basic config of most firewalls
169 <LaForge> so how does this differ from blocking packets which have the SYN flag set?
170 <LaForge> connection tracking is generic and currently handles TCP, UDP and ICMP
171 <LaForge> so for example we don't accept icmp echo replies, if we didn't send an icmp echo request before
172 <LaForge> the connection tracking is extensible in two ways:
173 <LaForge> - application helper modules (like ip_conntrack_ftp, ip_conntrack_irc) for specific protocols
174 <LaForge> - protocol helper modules (for tracking the state of other protocols than tcp/udp/icmp)
175 <LaForge> the ip_contrack_ftp for example marks all incoming ftp data connections as RELATED
176 <LaForge> 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!
177 <LaForge> ok... time for the next parT:
178 <LaForge> PART III - NAT
179 <LaForge> in 2.2 we only had the masquerading code, which deals with a special case of NAT (network address translation)
180 <LaForge> in 2.4 we have all kinds of differnet nat:
181 <LaForge> SNAT (source address NAT), and MASQUERADE as a special case of that
182 <LaForge> DNAT (destination address NAT), and REDIRECT as a special case
183 <LaForge> source nat is done at the POST_ROUTING hook
184 <LaForge> destination nat is done at the PRE_ROUTING hook
185 <LaForge> i'll begin with a small example of SNAT:
186 <LaForge> iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.4 -o eth0
187 <LaForge> this will NAT all packets to be sent out on eth0 to the new source address of 1.2.3.4
188 <LaForge> (it of course does the inverse mapping for the reply packets)
189 <LaForge> SNAT is useful for NAT cases, where you have a statically assigned IP address.
190 <LaForge> If your outgoing interfaces has a dynamically assigned IP address, you may use the MASQUERADE target.
191 <LaForge> iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0
192 <LaForge> is an example for masqing all traffic on interface ppp0.
193 <LaForge> the address to which the packets are nat'ed is the interface address of ppp0
194 <LaForge> it's always the current address of ppp0, so IP address changes don't need any special handling.
195 <LaForge> The next part is DNAT:
196 <LaForge> small example:
197 <LaForge> iptables -t nat -A PREROUTING -j DNAT --to-destination 1.2.3.4:8080 -t tcp --dport 80 -i eth0
198 <LaForge> which NAT's all tcp packets, coming through interface eth0 and going to a webserver to 1.2.3.4:808
199 <LaForge> 8080 of coruse
200 <LaForge> this is quite useful if you want to do transparent www proxying
201 <LaForge> REDIRECT is a special case of DNAT:
202 <LaForge> iptables -t nat -A PREROUTING -j REDIRECT --to-port 3128 -i eth1 -p tcp --dport 80
203 <LaForge> all tcp packets from eth1 going to any webserver on port 80 are redirected to a proxy running on the local machine
204 <LaForge> PART IV - Packet mangling
205 <LaForge> this is something really new, which 2.2.x code didn't have at all
206 <LaForge> the 'mangle' table lets you mangle any arbitrary information inside the packets while they pass our local machine
207 <LaForge> currently we have only three targets implemented:
208 <LaForge> TOS - change the TOS bit field in the header
209 <LaForge> TTL - change the TTL field in the header (increment/decrement/set)
210 <LaForge> MARK - set the packet's skb->nfmark fielt to a particular value
211 <LaForge> of course you can again use all the matches available for packet filtering and nat.
212 <LaForge> a simple example:
213 <LaForge> iptables -t mangle -A PREROUITING -j MARK --set-mark 10 -p tcp --dport 80
214 <LaForge> which set's the nfmark field of each packet's skb to 10, if it is tcp and has a destination port of 9-
215 <LaForge> 80
216 <LaForge> all matches and targets are implemented as separate modules, so you can at any time write new match and/or target modules
217 <LaForge> There are two more 'advanced concepts' of netfilter, I want to introduce:
218 <LaForge> - Queuing
219 <LaForge> if you have a rule, which has the target QUEUE, the packet is inserted into a special queue inside netfilter
220 <LaForge> the packets in this queue are transmitted over a netlink socket to a userspace process.
221 <LaForge> 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
222 <LaForge> the process can (of course) also set the verdict of this packet (like: DROP this packet, ACCEPT the other one)
223 <LaForge> this enables people to write some firewalling code in userspace, and (hopefully) keeps the kernel clean from too complex code.
224 <LaForge> - Userspace logging
225 <LaForge> Very similar to queuing, although it is unidirectional
226 <LaForge> if you insert a rule with the ULOG target, the packet is copied and sent through a netlink multicast socket
227 <LaForge> one or more userspace processes may listen to this netlink multicast socket and receive the copy of the packet
228 <LaForge> the userspace process may now gather all information it needs and log it to a logfile/database/whatever
229 <LaForge> we've already implemented ulogd, which is a plugin-extensible logging daemon attaching to the ULOG target
230 <LaForge> So.... we are heading the end of my talk.... last chapter:
231 <LaForge> Current development and future:
232 <LaForge> - full TCP sequence number tracking
233 <LaForge> - port more matches/targets to IPv6
234 <LaForge> - support for more application protocol helpers for NAT (RPC, SMB, SNMP, ...)
235 <LaForge> - more matches (like 'accept all packets as long as the number of connections to this port doesn't raise about N)
236 <LaForge> - multicast support
237 <LaForge> - infrastructure for having conntrack and nat helpers in userspace
238 <LaForge>
239 <LaForge> At the end some useful links:
240 <LaForge> This presentation:
241 <LaForge> http://www.gnumonks.org/papers/netfilter-lk2000
242 <LaForge> netfilter homepage: http://netfilter.kernelnotes.org
243 <LaForge> links to the mailinglist(s) and the archives, as well as the iptables userspace tool are on the netfilter homepage
244 <LaForge> 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
245 <LaForge> everything should be linked from the netfilter homepage
246 <Blu3> Thank you, it was very informative :)
247 <LaForge> Thanks for your interest in this talk... I'll deal with questions now
248 ----
249 CategoryDocs
250