Charla 1-12-2000

Desarrollo

Log de la conferencia. Se han suprimido las líneas correspondientes a entradas y salidas de diferentes personas en el canal durante la conferencia
This talk can also be read in http://blue-labs.org/lectures/netfilter-2000-12-1.html

TALKING IN #LINUX TALKING IN #QC

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

[20:19] (Blu3) I am building an html representation of the discussion, it will appear on http://www.blue-labs.org/ first and will also appear on Linux.Com's Live! section
[20:19] (HoraPe) Please, ask in #qc, the answers will be here
[20:19] (LaForge) please be a bit patient, there are a lot of questions.
[20:19] (LaForge) 19:19 (arjan) packet = "full IP packet" or a "IP fragment" ?
[20:19] (LaForge) horape: you're welcome
[20:20] (LaForge) the connection tracking code defragments the packets, and they are refragmented before they leave the machine again
[20:20] (LaForge) 19:41 (MbM) is it possible to filter entirely on state? eg: iptables -A
[20:20] (LaForge) input -m state --state ESTABLISHED,RELATED -j ACCEPT ; iptables
[20:20] (LaForge) -A input -j REJECT --reject-with tcp-reset
[20:20] (LaForge) yes, it is possible to filter entirely on state
[20:21] (LaForge) at least as long if you don't use any weird unsupported protocols
[20:21] (LaForge) Gandalf: ok, so the connection tracking takes ftp and dcc into account? (services that require ports >1024 open)
[20:21] (LaForge) yes it does!
[20:22] (LaForge) you don't have to have a single port >1024 open and DCC as well as active ftp work fine!
[20:22] (LaForge) this is what connection tracking is all about :) and if you have another protocol, which needs this kind of incoming connections, you can always write a conntrack application helper module
[20:22] (LaForge) (MbM) how well is the unclean module working?
[20:19] (HoraPe) LaForge: In 1998 i wrote a little text that was the first easy howto for iproute2. A thing i proposed was using ipchains' fwmark to route by port destination (for example, routing web traffic and ssh traffic via different interfaces)
[20:19] (HoraPe) The problem i was most often asked about was that it won't work with locally generated packets because they would hit only the output chain and too late, after having taken the routing decisions.
[20:19] (HoraPe) Does the adding of NF_IP_LOCAL_OUT hook solve this?
[20:19] (MbM) LaForge: what does the unclean filter check for? right now i'm using my own knockoff with "--tcp-option \! 2 -j REJECT" to check for the mss option in the tcp header
[20:20] (foo) what path do packets on localhost follow in the diagram you drew at the beginning?
[20:21] (foo) and is the routing code modular? can routing decisions be taken in userspace?

[20:23] (LaForge) mbm: mmh... sorry. To be honest, I've never tried the unclean match
[20:23] (LaForge) it is supposed to do any possible sanity check on the packet, and discards it if there's anything wrong
[20:23] (LaForge) to know which checks are made, you may have to have a look at the source
[20:24] (LaForge) The problem i was most often asked about was that it won't work with locally generated packets because they would hit only the output chain and too late, after having taken the routing decisions.
[20:25] (LaForge) yes, you can have iproute2 re-route locally generated packets based on the nfmark value set by netfilter
[20:26] (LaForge) (foo) what path do packets on localhost follow in the diagram you drew at the beginning? and is the routing code modular? can routing decisions be taken in userspace?
[20:26] (LaForge) locally generated packets go the same path as if there was an actual network device lo:
[20:27] (LaForge) NF_IP_LOCAL_OUT, NF_IP_POST_ROUTING, NF_IP_PRE_ROUTING, NF_IP_LOCAL_IN
[20:27] (foo) so, local_out, postroute, pre_route, local_in?
[20:27] (foo) ah.
[20:27] (LaForge) the routing code is outside of the scope of netfilter
[20:27] (foo) ok.
[20:27] (LaForge) the whole hooks-framework is to seperate the normal network stack cleanly from all firewalling
[20:28] (LaForge) but using the nfmark field as key, you may set nfmark in netfilter and have the routing code route dependend on the nfmark value
[20:28] (LaForge) (marius) how much overhead does the defragmenting/refragmenting of packets present?
[20:29] (LaForge) mmh... a difficult question. This of course depends on how much fragmented ip traffic you receive. usually pathmtu discovery should prevent ip packets from being fragmented
[20:29] (LaForge) but if you want to do nat, the defrag/refrag step has to happen anyway
[20:29] (LaForge) (and if you are using 2.2 with nat, it also has to do defrag/refrag)
[20:30] (surazal) hm
[20:30] (LaForge) (marius) and also, are they the same fragment size when they are refragmented or is it according to the mtu of the outgoing interface?
[20:30] (LaForge) they are (of course) only fragmented again, if the mtu of the outgoing interface requires it
[20:23] (foo) is anyone working on libpcap support for netfilter? are there any performance comparisons?
[20:24] (MbM) LaForge: just want to use unclean to stop portscans basically
[20:24] (MbM) ohwell, like i said before the tcp header options check catches most of em
[20:24] (LaForge) The problem i was most often asked about was that it won't work with locally generated packets because they would hit only the output chain and too late, after having taken the routing decisions.
[20:24] (MbM) right
[20:25] (marius) how much overhead does the defragmenting/refragmenting of packets present?
[20:25] (marius) and also, are they the same fragment size when they are refragmented or is it according to the mtu of the outgoing interface?
[20:25] (MbM) as for tcp header checking what do you think of my --tcp-options \! 2 -j REJECT? is there a better option to check for?
[20:26] (LaForge) foo what path do packets on localhost follow in the diagram you drew at the beginning? and is the routing code modular? can routing decisions be taken in userspace?

[20:31] (LaForge) (MbM) as for tcp header checking what do you think of my --tcp-options \! 2 -j REJECT? is there a better option to check for?
[20:32] (LaForge) mmh... i wouldn't encourage filtering of tcp options at all... doesn't seem to be neccessary (at least from my point of view)
[20:31] (marius) what i was trying to say was that, say if the fragment size of the incoming packets were lower than the mtu, would it be refragmented to fit the new mtu, or would it keep the old fragment size..

[20:33] (LaForge) (marius) what i was trying to say was that, say if the fragment size of the incoming packets were lower than the mtu, would it be refragmented to fit the new mtu, or would it keep the old fragment size..
[20:33] (MbM) LaForge: simple to check for generated packets which often have minimal or no tcp header options
[20:33] (surazal) LaForge, you said that in Linux 2.2 forwarded packets get thrown in the INPUT, OUTPUT, and FORWARD tables simultaneously, correct? Apparently, on mandrake Linux (according to one of my co-workers), this was not the case. Was there different network filter behaviors across different distributions?
[20:34] (LaForge) i'm not quite sure, but I think the current code would refragment it to fit the new mtu, as we keep no state about how big the fragments were before the fragmentation happened
[20:34] (LaForge) surazal: mmh... i don't think so, because this would be a radical change of the ipchains code.
[20:35] (LaForge) surazal: and i'm quite sure that the packets go through INPUT, FORWARD and OUTPUT, as it is one of our FAQ's ;)
[20:35] (LaForge) are there any more questions? please feel free to ask
[20:36] (foo) laforge: is anyone working on libpcap support for netfilter?
[20:37] (LaForge) foo: not that i'm aware of.
[20:37] (LaForge) foo: it's probably worth asking on the mailinglist
[20:33] (surazal) LaForge, you said that in Linux 2.2 forwarded packets get thrown in the INPUT, OUTPUT, and FORWARD tables simultaneously, correct? Apparently, on mandrake Linux (according to one of my co-workers), this was not the case. Was there different network filter behaviors across different distributions?
[20:34] (surazal) Mandraek 7.2 FYI
[20:34] (Gandalf) surazal: first INPUT then FORWARD and then OUTPUT
[20:35] (surazal) ah ok I must correct my coworker then :^)
[20:36] (surazal) of course he'll insist he's right though :^P

[20:38] (foo) ok.
[20:38] (LaForge) surazal: for more information see http://netfilter.kernelnotes. org/unreliable-guides/packet-filtering-HOWTO-6.html
[20:39] (LaForge) (Blu3) I have a friend who needs to log the MAC addresses of packets, what is the best way to do that?
[20:39] (LaForge) you could either use the LOG target (which logs the packets to syslog, including the mac address
[20:38] (Blu3) I have a friend who needs to log the MAC addresses of packets, what is the best way to do that?
[20:38] (Gandalf) are there any plans for something like the IP Accounting in kernel 2.2 ?

[20:40] (LaForge) or the ULOG target (which in combination with ulogd would log whatever you want to a textfile/mysql database/ ...)
[20:40] (LaForge) (Gandalf) are there any plans for something like the IP Accounting in kernel 2.2 ?
[20:40] (LaForge) gandalf: what kind of accounting do you think of? we currently have packet and byte counters for each rule
[20:41] (LaForge) gandalf: if you want to do a per-uid-accounting you may want to have a look at 'ipacct' on freshmeat
[20:41] (Gandalf) byte counters, but dynamic not static as in a FORWARD rule for each ip
[20:42] (LaForge) gandalf: dynamic per ip address? run one of the accounting daemons like nacctd
[20:42] (LaForge) gandalf: but anyway, it's outside the scope of netfitler, as you are talking about 2.2
[20:42] (Gandalf) ok
[20:43] (LaForge) (MbM) LaForge: is there any difference between REDIRECT and DNAT --to-destination 127.0.0.1 ?
[20:43] (LaForge) mbm: let me think..
[20:40] (Blu3) thankyou
[20:41] (HoraPe) In 1998 i wrote a little text that was the first easy howto for iproute2. A thing i proposed was using ipchains' fwmark to route by port destination (for example, routing web traffic and ssh traffic via different interfaces)
[20:41] (HoraPe) The problem i was most often asked about was that it won't work with locally generated packets because they would hit only the output chain and too late, after having taken the routing decisions.
[20:41] (HoraPe) Does the adding of NF_IP_LOCAL_OUT hook solve this?
[20:41] (foo) horape: yes
[20:41] (foo) (scroll back)
[20:41] (HoraPe) foo, tnx
[20:41] (LaForge) horape: i've already answered that: yes :)
[20:42] (HoraPe) i didn't see the answer, maybe it was during the netsplit
[20:42] (HoraPe) tnx
[20:42] (MbM) LaForge: is there any difference between REDIRECT and DNAT --to-destination 127.0.0.1 ?

[20:44] (LaForge) mbm: i don't think so. it should be exactly the same. it's just for convenience
[20:44] (LaForge) mbm: ah... not to 127.0.0.1, but to the ip address of the incoming interface
[20:45] (LaForge) (marius) in that case, is there some sort of alias mechanism, so that you could have REDIRECT represent NAT --to-destination addr-of-incoming-if ?
[20:45] (LaForge) marius: that is exactly what REDIRECT is
[20:45] (marius) err DNAT
[20:45] (marius) yeah i know
[20:45] (marius) but i'm saying, is there an alias mechanism,so you could define your own
[20:46] (LaForge) marius: no. REDIRECT and DNAT are two seperate targets
[20:46] (LaForge) marius: you could probably do something like this using user-defined chains
[20:44] (marius) in that case, is there some sort of alias mechanism, so that you could have REDIRECT represent NAT --to-destination addr-of-incoming-if ?

[20:47] (LaForge) (marius) could you think of any concieveable uses for MIRROR? (other than testing)
[20:47] (LaForge) marius: mmh... if you know somebody is portscanning you, you can add a mirror rule for him :) so he's portscanning himself
[20:48] (marius) been there done that :)
[20:49] (LaForge) Cmarius) yah, be funny if the portscanning host had MIRROR too (marius) endless loop
[20:49] (LaForge) marius: the ttl is unchanged, so the ttl decreases and the packet is dropped somewhen
[20:49] (marius) well.. add some mangling to it too :)
[20:50] (LaForge) (MbM) oh, can limit be used in terms of kbps or is it simply in terms of number of matches?
[20:50] (LaForge) mbm: ou can set packets/sec /minute /hour /day
[20:50] (LaForge) so it is on a 'per packet' basis
[20:51] (LaForge) mbm: if you want to do something like 'limit bandwidth used for this kind of packet' you should have a view of the CBQ / tc / iproute2 stuff
[20:52] (LaForge) ok... any more questions for now?
[20:52] (LaForge) surazal Are there going to be any more lectures like this one in the future? :^)
[20:53] (LaForge) surazal: i REDIRECT this request to the umeet organizers :)
[20:53] (Ricardo) surazal: for sure :)
[20:53] (Ricardo) surazal: only give as a chance to invite so wonderful 'lectureres' as LaForge :)
[20:53] (Ricardo) s/as/us/
[20:53] (Ricardo) :)
[20:53] (LaForge) http://umeet.uninet.edu
[20:54] (LaForge) ricardo: thanks, you're welcome
[20:55] (LaForge) if you have any more netfilter related questions, please see the documentation and have a look at our mailinglist archives and FAQ. If you still have your question afterwards, just ask on the mailinglist
[20:55] (LaForge) Thanks again to the organizers and the audience!
[20:56] (Ricardo) Thank you very much, LaForge :)
[20:56] (surazal) yes, thank you
[20:56] * MJesus wants to specially thanks laforge for its support from the beginning of the organization of UMEET'2000
[20:56] ) plas plas plas plas plas plas plas plas plas plas
[20:56] ) plas plas plas plas plas plas plas plas plas plas
[20:56] ) clap clap clap clap clap clap clap clap clap clap
[20:56] ) clap clap clap clap clap clap clap clap clap clap
[20:56] ) plas plas plas plas plas plas plas plas plas plas
[20:56] (Blu3) thank you :)
[20:56] ) clap clap clap clap clap clap clap clap clap clap
[20:56] ) clap clap clap clap clap clap clap clap clap clap
[20:56] ) plas plas plas plas plas plas plas plas plas plas
[20:56] ) clap clap clap clap clap clap clap clap clap clap
[20:56] ) plas plas plas plas plas plas plas plas plas plas
[20:56] ) clap clap clap clap clap clap clap clap clap clap
[20:56] ) plas plas plas plas plas plas plas plas plas plas
[20:56] ) plas plas plas plas plas plas plas plas plas plas
[20:56] ) clap clap clap clap clap clap clap clap clap clap
[20:56] ) plas plas plas plas plas plas plas plas plas plas
[20:56] ) clap clap clap clap clap clap clap clap clap clap
[20:57] ) clap clap clap clap clap clap clap clap clap clap
[20:57] ) clap clap clap clap clap clap clap clap clap clap
[20:57] ) clap clap clap clap clap clap clap clap clap clap
[20:57] (LaForge) ok .... i'll be off for now... have to study some more brazilian portuguese grammar ;)
[20:57] (surazal) ok ok ok
[20:57] (surazal) MJesus: dude!
[20:57] (Dazman) heh
[20:57] ) muito obrigados Harald Welte !
[20:57] ) e boa noite!!!!
[20:57] (LaForge) mjesus ;)
[20:57] (antlarr) congrats for the talk !
[20:57] (surazal) heh... catch y'all later
[20:47] (marius) could you think of any concieveable uses for MIRROR?
[20:47] (marius) (other than testing)
[20:48] (MbM) marius: for MIRROR shouldn't you set limits? otherwise you could flood
[20:48] (MbM) bandwidth used by the incoming packets and the bandwidth used sending them out
[20:48] (MbM) could kill your connnection
[20:48] (marius) yah, be funny if the portscanning host had MIRROR too
[20:48] (marius) endless loop
[20:49] (MbM) yikes
[20:49] (MbM) oh, can limit be used in terms of kbps or is it simply in terms of number of matches?
[20:50] (MbM) ie can i use MIRROR but limit the mirroring to 2k/s ?
[20:51] (MbM) hmm that would mean packet loss though if it's in terms of packets
[20:52] (surazal) yes
[20:52] (surazal) Are there going to be any more lectures like this one in the future? :^)
[20:53] (surazal) Where can I find announcements?
[20:53] (surazal) in other words, where is umeet? :)
[20:53] (Ricardo) Uh
[20:54] (Ricardo) Umeet is on umeet.uninet.edu
[20:54] *** MbM (mbm@cb58615-f.baycty1.mi.home.com) Quit (Read error to MbM[cb58615-f.baycty1.mi.home.com]: EOF from client)
[20:54] (surazal) thanks! I'll keep my eyes open... this has been very useful
[20:55] (Ricardo) The next time we'll try to announce this congress a bit more
[20:55] (marius) Richardo: i'm sure we could arragne something wrt. Linux.com live!
[20:55] (marius) in terms of advertising
[20:55] (Ricardo) yep marius
[20:56] (Ricardo) We're impressed. :) We didn't expected so many lectures neither their high level
[20:56] (marius) Ricardo: email katharine@linux.com
[20:57] (marius) Ricardo: tell them marius reffered you
[20:57] (marius) err
[20:57] (marius) her
[20:57] (marius) and also that Blu3 (david) and MbM (mike)
[20:57] (marius) was here
[20:57] (marius) heh
[20:57] (Blu3) aye
[20:58] (marius) (and reccomended it :)
[20:58] (marius) recommended
[20:58] (marius) reven
[20:58] (marius) even
[20:58] (marius) evne
[20:58] (marius) heh
[20:58] * Dazman kicks marius.
[20:58] (marius) and Dazman too!
[20:58] (Dazman) thanks :)
[20:58] (Dazman) hah
[20:58] (Blu3) heh

Contact: