Ricardo Javier Cardenes Medina: Creo que ya va siendo hora :-)

Ok, people, we're going to | Bien gente, vamos a empezar

start the talk. | la charla.

All those who want a Spanish | Los que quieran una traducción al

Translation of the talk, please | español de la charla, entren a

join #redes channel | #redes, por favor

Hi friends. Tonight, we are so fortunate tonight having with us Harald Welte. He is one of the core developers of the NetFilter project, the packet filtering and mangling engine for Linux 2.4, and is being sponsored by Conectiva, a Brazilian based Linux Company. Harald Welte :-) When you want :-)

Harald Welte: Hi everybody

Harald Welte:: thanks for the introduction

Ricardo Javier Cardenes Medina:: :)

Harald Welte: Ok. I'm going to give an introduction about netfilter / iptables

First of all, what is netfilter/iptables?
It is the new infrastructure in the linux 2.4 network stack, which is used for packet filtering / NAT and packet mangling
it is the successor of ipfwadm (2.0) and ipchains (2.2).
It was basically a complete redesign / rewrite, and there has almost no line of code survived from 2.2.x times

I'm saying it is a infrastructure, because it is more generic than only to be used by firewalling.

netfilter basically consists out of a set of hooks (call-back function entry points) in the standard linux kernel networking code
these hooks are placed at certain points of the layer-3 network protocols.
any kernel module can now register at any of these hooks, and each time a packet passes this hook, the network code will call this module
i will talk more about these details later.

First another question: why did we need netfilter? wasn't the 2.2.x code good enough?

ipchaisn didn't have an infrastructure to pass packets to userspace
transparent proxying was extremely difficult
all packet filter rules were dependent on interface adresses
masquerading (a special case of NAT) was hacked into the firewalling code
the code was way too complex and unstructured
and it was neither modular nor extensive
this should be enough reasons for a change ;)
to give a definition of terms...
"netfilter" is the set of hooks in the linux network stack.
"iptables" is the tables/chains of rules, which are implemented on top of netfilter.

I'd like everybody to have a look at the paper of this talk.

In section 1.4, there is a diagram
this diagram shows the netfilter hooks in the 2.4.x IPv4 stack.
[somebody just asked me about when to ask questions, I will make a short break from time to time for people to ask questions]
if we look at this diagram, packets coming in from a network interface enter the diagram from the left side

Ricardo Javier Cardenes Medina: Tell me so,

Harald Welte. I'll throw away the "moderate" from the channel

Harald Welte: packets leaving the machine through a network interface come out on the right side

packets targeted for the local machine (locally-originated or destined packets) go to the bottom or come from the bottom.
so if we look at a packet coming in on one interface and being forwarded to another network, we have the following path:
packet comes in
packet hits the PRE_ROUTING hook
the routing code makes the routing decision
packet hits the FORWARD hook
packet hits the POST_ROUTING hook
packet is sent to the outgoing network interface

I will make a short break for questions now. any questions up to now, on the diagram / hooks / ... ?

Ricardo Javier Cardenes Medina: If you have any questiong up to now, please tell it now :-)

dent: with this new code is it flexible enough to for instance let you make a remote packet appear local?

Harald Welte: dent: no. this does not make sense. it is not possible and could you please please wait with more generic questions until the end of the talk

dent: sorry ;) * dent will wait

Harald Welte: dent: no problem.

Ricardo Javier Cardenes Medina: Some other questions?

mmh... It seems you can continue :-)

Harald Welte: i was advised to slow down a bit, as the translation is taking it's time. so I will talk a bit more about not-so-important, not-to-be-translated stuff ;)

Ricardo Javier Cardenes Medina: Ok :-)

Maria Jesus Coma: yes...

Harald Welte: ok, well. something about the background. netfilter/iptables was developed during the last two years by Rusty Russel, Marc Boucher, James Morris and me.

Maria Jesus Coma: ATENCION : en #redes traduccion a español/there are Spanish translation at #redes

Harald Welte: Rusty Russel is the initial author, he deservers most of the credits :) he was already the linux-2.2 kernel firewall maintainer and co-author of ipchains he got paid for one year by Watchguard, inc., who do commercial linux-based firewall products marc, james and I joined him later and did most of the contributions in our spare time.

litoral: Ricardo Javier Cardenes Medina: "dime cuando, Harald Welte. Quitaré el "moderado" del canal

*Harald Welte nao entendi espanol. so portugues do brazil, ingles e alemao ;)

Ricardo Javier Cardenes Medina: litoral: Don't worry. That phrase was for #redes O:) We're about with the translation

Harald Welte: ok. I will continue at the hooks again

Ricardo Javier Cardenes Medina: It's when I told you to tell me when to throw away the moderated :-)

Harald Welte: section 1.4 discusses how other packets traverse the netfilter hooks, you can read it from there.

section 1.5:

every module registered to one of those hooks, has to return a value to the netfilter core what happens to the packet after this hook depends on the return value.
NF_ACCEPT means that the packet goes on, as if nothing happened
NF_DROP means the packet is dropped (i.e. it just disappears and nobody else will see it)
NF_STOLEN means that the kernel module (who attached to the hook) has taken over the packet, and the packet should not continue to gou through the network stack
NF_QUEUE is a special case, it means the packet will be sent to a special userspace process, more details about that later
NF_REPEAT means, that this hook should be called again
As pointed out earlier, the real ip tables are implemented on top of netfilter iptables registers to the netfilter hooks currently we have three different tables, for three different jobs:
filter - for traditional packet filtering
nat - for all kinds of network address translation
mangle - anything else which manipulates a packet but is not NAT ;)

i will now describe each of those tables individually, starting with filter
(section 1.6)
the filter table attaches to three of the netfilter hooks
LOCAL_IN, FORWARD and LOCAL_OUT
the filter table has one chain of rules attached to each of those hooks. The names of the chains are INPUT, FORWARD and OUTPUT.
if you look back to the diagram, you will conclude, that each packet will always only hit one of those three hooks (respectively their attached chains).
packets forwarded to other interfaces _ONLY_ traverse the FORWARD table
packets coming in from the network, having the firewall as their destination IP address, will _ONLY_ traverse the INPUT chain
packets being sent by local processes on the firewall will _ONLY_ traverse the OUTPUT chain.

It is important to see the difference from ipchains, where a forwarded packet used to traverse all three chains.

time for a short question-break again :) any questions up to now?

dent: so this makes i easier to have the right rule applied to the right case, although at times it might also mean triple the # of rules?

Harald Welte: dent: the first part of your sentence is true, the second not. dent: you can always have user-defined tables and then jump to this user-defined table from INPUT and FORWARD. sorry, user-defined chains of course

w8: never for OUTPUT?

Harald Welte: w8: for OUTPUT, too, of course.

dent: oh

Harald Welte: like in ipchains, you can jump from any chain to any other chain (within one table)

dent: so you could have a "badhosts" table and jump to it for all of them?

Harald Welte: dent: exectly

dent: nice

Harald Welte: other questions up to now?

dent: iptables is essentially an abstraction of netfilter?

Harald Welte: dent: no. it's two totally different things netfilter is just some callback functions in the network stack iptables is an abstract implementation of lists of filtering rules

dent: thanks. I see.

Harald Welte: dent: so you can use netfilter without iptables, as well as iptables without netfilter (theoretically)

Tv: netfilter is an API, iptables is an application for that API, right?

Harald Welte: Tv: exactly. iptables is one possible application using this API, later we will learn about another one) important to add, a kernel-only api, of course

_aSkAiNeT: Harald Welte you are talking about the default table, right? will you talk about nat, mangle...?

Harald Welte: skaintnet: as said, i will talk about all three of them. ok, time to continue with the presentation now we know that there are chains inside tables which attach to hooks. how do we use that thing? each chain consists out of a list of rules. this list of rules is traversed sequentially from top to bottom for every packet hitting this chain every rule consists out of two parts:

- one or more matches, specifying which packet matches to that rule

- one target, specifying the action to be taken when the matches match

the nice thing about iptables is: it's modularity any action or any target can be implemented as a seperate module so anybody can just write his own matches or targets, without interfering with the netfilter or iptables code. it's like writing plugins, just not for an application program, but the firewall part of your kernel for managing those tables, there is a commandline tool, called "iptables". this commandline tool is flexible, and handles all operations for all tables. so how do we use this commandline tool?? we have to build commands (section 2.2) every command exists out of

- which table we want to operate on
- which chain in this table to operate on kind of operation (insert, delete, modify, ...)
- which matches we want to use
- which target we want to use.

iptables -t table - -j ...

example:

iptables -t filter -A INPUT -j ACCEPT -p tcp --dport smtp

we Append a rule to the INPUT chain of the filter table. this rule matches TCP packets with a destination port of smtp (=25) and ACCEPTs them so, what kind of targets / matches do we have targets:

ACCEPT a packet

DROP a packet

QUEUE a packet

REJECT a packet

LOG a packet

(there are more targets than that, for more details look at the presentation paper or the netfilter/iptables documentation) as for matches, we have some basic matches:

-p protocol (tcp/udp/icmp)

-s source ip address / mask

-d destination ip address / mask

-i incoming interface name (eth0 / ppp12 / ..)

-o outgoing interface name

--dport (Destination port)

--sport (source port)

--mac-source MAC (ethernet) address

(again, there are more matches, please look in the documentation if you need more information about them)

ok, time again for some questions

dent: if I were to tell it to LOG would that imply an ACCEPT or a DROP?

Harald Welte: LOG is, what we call a 'non-terminating target'

Harald Welte: it's a bit weird, i know

Harald Welte: so what LOG does, it returns IPT_CONTINUE to the iptables code, and it continues with the next rule

dent: i c

dent: ty

giantux: Is it possible to make a connection-oriented port redirector?. ie. suppose i have httpd listening on port 80, but i want enable http services on port 3333 too

Ricardo Javier Cardenes Medina: Mmmh... It was one of my deeper questions }:)

Harald Welte: giantux: please wait until later, this is a NAT question and we didn't talk about NAT yet ;)

w8: Harald Welte: as you can say, this list of rules is traversed sequentially from top to bottom for every packet hitting this chain...

giantux: ok...

* giantux will wait like dent ;)

Harald Welte: w8: was this a question?

w8: so that means first wins?

Harald Welte: w8: ah, yes. the first matching rule is executed further behaviour depends on the target of the executed rule

w8: and the packet doesn't pass trough the rest of rules?

Harald Welte: no.

w8: ok

dent except for non terminating targets like LOG

Harald Welte: like, if the second rule has ACCEPT as target, and the rule matches, the packet is ACCEPTed at this chain

Harald Welte: dent: yes, they are the only exception

Tv: You need to make a clear difference between iptables ACCEPT and netfilter NF_ACCEPT.

Harald Welte: Tv: well, i don't think that this is too important right now

Tv: That was just one thing that confused me for a while.

Harald Welte: Tv: but the ACCEPT target returns IPT_ACCEPT to the iptables core, and the iptables core returns NF_ACCEPT to the netfilter core

ok. further questions up to now?

no.

so far about easy packet filtering next part of the presentation is about NAT

(Par III of the paper)
(Part III of the paper)
implemented on top of iptables and some other functions (connection tracking, will talk about that later), there is the nat module
f NAT (network address translation)
this generic infrastructure is controlled by the 'nat' table.
the 'nat' table attaches again to three of the netfilter hooks.
we have the PREROUTING chain (NF_IP_PREROUTING hook), POSTROUTING (NF_IP_POSTROUTING) and the OUTPUT chain (NF_IP_LOCAL_OUT).
what kind of NAT we want to do is specified by rules in those chains, utilizing the NAT targets.

we have basically two categories of nat:

source NAT and destination NAT.
Source nat changes the packet's source address
destination nat changes the packet's destination address
SNAT happens at the POST_ROUTING hook
DNAT happens at the PRE_ROUTING hook
why?

because if you change the destination address, you have to do that before the routing decision (which is based on the dest. address)

MASQUERADE is a special case of SNAT

REDIRECT is a special case of DNAT

some examples

iptables -t nat -A POSTROUTING -j SNAT --to-source 1.2.3.4 -s 10.0.0.0/8

we Append a rule to the POSTROUTING chain of the nat table.

the rule says: SNAT all packets with the original source address within 10.0.0.0/8 to the new address 1.2.3.4
this is a static rule, which would for example not work with ISP dialup lines which have a dynamic ip address.
for this case, we have the MASQUERADE target.

example:

iptalbes -t nat -A POSTROUTING -j MASQUERADE -o ppp0

we masquerade all packets going out to interface 'ppp0' the difference is, that we don't specify the new to-be-nat'ed address, but just use the current address of the outgoing interface destination nat:

example:

iptables -t nat -A PREROUTING -j DNAT --to-destination 1.2.3.4:8080 -p tcp --dport 80 -i eth1

DNAT all tcp packets with destination port 80 coming in on interface eth1 to 1.2.3.4:8080 basically an example for a transparent proxy setup

again time for questions

any questions related to NAT ?

dent: iptables -t nat -A POSTROUTING -j SNAT --to-source 192.168.10.2 -s 149.234.125.324 which could make external packets appear local?

Harald Welte: dent: this depends on your idea of 'local'

dent: IP addie wise

Harald Welte: dent: my definition of 'local' is 'packets from or to the local host"

dent: right , you've been firewall coding too long ;)

giantux. my question again... Is it possible to make a connection-oriented port redirector?. ie. suppose i have httpd listening on port 80, but i want enable http services on port 3333 too

Harald Welte: giantux: iptables -t nat -A PREROUTING -j DNAT --to-destination my.loc.al.ip:80 -p tcp --dport 3333 or iptables -t nat -A PREROUTING -j REDIRECT --to-port 80 -p tcp --dport 3333

giantux. the secondone would affect incoming packets to port 80? no, both rules do exactly the same

Harald Welte: that's why i didn't explain the REDIRECT target above

dent: laforge for these types of rules would you also have to make sure that the reply is properly redirected?

Harald Welte: dent: no.

* Harald Welte remembers he forgot to tell you something

Harald Welte: the nat table's chains are only traversed for each _first_ packet of every connection so all the SNAT/DNAT/... rules do, is to "set up a nat mapping", meaning to save some information in an internal nat database all further packets of the connection (in both directions) do not traverse the nat table at all, but are just 'automagically' changed

further NAT questions?

w8: uhm... ala "keep state" of ipf?

dent: is that the usateful conecpt?

Harald Welte: w8/dent: yes, the nat code uses state tracking, but that's irrelevant for now

... any further nat questions?

dent: I've seen nat devices where they have a pool of IPs to try and make incoming connections also possible

Harald Welte: dent: we can do that, too

dent: nice

Harald Welte: dent: you can do something like --to-source 1.2.3.10-1.2.3.200 for example and for 'incoming' connections, you just do DNAT rules.

dent: that simple?

Harald Welte: yes, it is 'that simple' to use ;)

Harald Welte: the NAT code has some algorithms to determine which address / port to use. it always tries to change as least as possible

dent: are the algorithms modular?

Harald Welte: you will _never_ end up with stuff like 2.2.x masquerading (i.e. all port numbers of masqued connections have portnumbers of 60000+, etc)

dent: yes, they are determined by your target we have for example also a SAME and a BALANCE target like if someone thinks they have a better scheduling system its easy for them to make it available (where schedule means how the IPs are rotated)

Harald Welte: dent: yes. for more info abou that, read the NAT and netfilter hacking howto's

ok, vamos continuar ;)

Part 4 - packet mangling

packet mangling is changing something inside a packet, which is not an address part. currently we don't have too much targets for mangle, but still it is interesting

TOS - manipulate the type of service bits in the ipv4 header

TTL - set/increase/decrease the TTL (time-to-live) of packets

MARK - set an internal mark field (nfmark/fwmark) to a certain value. Used mostly for policy routing with iproute2 and QoS using tc - both outside of scope of this presentation

simple example:

iptables -t mangle -A PREROUTING -j MARK --set-mark 10 -p tcp --dport 80

set the MARK field to 10 for all tcp packets with destination port 80

any more questions on anything from the beginning up to now?

i am going to continue with a completely different part now

dent: will you be doing an iproute2/QoS presentation? :)

Harald Welte: dent: no. Have a look at http://www.gnumonks.org/presentations/qos-saopaulo2001/ for the slides of a presentation about that. I have too much work to do to give any more presentations right now, sorry

Harald Welte: ok, let's go on with connection tracking

connection tracking is another part. conntrack is implemented on top of netfilter (and has no relation to iptables, for example) what does conntrack do?

it keeps track about all currently ongoing connections in which the local machine is involved this state information about connections is to be used by several other parts of linux:

- the NAT code

- for stateful firewalling

for each packet entering the system, conntrack will connect the information about which connection this packet belongs to at the PRE_ROUTING hook meaning that any other kernel code after this point can use this tracking information. connection tracking again is very modular we have a layer-four independent core and layer-four modules for tcp, icmp, udp.

in addition for some weird protocols like IRC and ftp, there are application-layer helper modules (layer 5+) anybody can just write modules for further layer 4 / layer 5 protocols and load them into conntrack so what can we do with this?

for example, we can use this information in any iptables rule there is an iptables match (the state match) which enables us to filter based on the packet's state we divide all packets in:

NEW - packet would establish new connection, if we accept it

ESTABLISHED - packet belongs to already-established connection

RELATED - packet is related to an already established connection

INVALID - packet cannot be classified (multicast, broadcast, errors, ...)

RELATED is, for example, ftp-data connections which are related to the control connection or icmp error messages in reply to a tcp/udp packet (frag needed, host/net/port unreachable, ...)

example:

iptables -t filter -A FORWARD -j ACCEPT -m state --state ESTABLISHED

accept all packets which belong to already established connections

ok. i think it's time to finish now. there is _lots_ of more things you can do with netfilter/iptables/conntrack/ ... for further reading, please refer to the netfilter homepage at http://netfilter.gnumonks.org/

Ricardo Javier Cardenes Medina: :-)

Harald Welte: i will be here on the channel for some more minutes for questions....

Ricardo Javier Cardenes Medina: Well...

Harald Welte: and there is, of course, a mailinglist (netfilter@lists.samba.org) for other questions...

Ricardo Javier Cardenes Medina: Before starting questions...

Ricardo Javier Cardenes Medina: Only a few words :-)

Ricardo Javier Cardenes Medina:

Ok. Thanks again for being here | Bien. Gracias de nuevo por estar

with us, Harald (one more time ;-)) | con nosotros, Harald (una vez más)

It was a great talk (like all of | Ha sido una gran charla (como todas

yours). I'm sure all people here | las tuyas). Estoy seguro de que la

have had a good (and productive) | gente ha pasado un buen (y productivo)

time. :) I want to remark too the | rato. Me gustaría resaltar también

good job of litoral and DaniT | el trabajo de litoral y DaniT

translating to Spanish. | traduciendo al español.

:-)

dent: how secure is the connection tracking? as in, how much can you trust that a packet is indeed from an established connection?

Ricardo Javier Cardenes Medina: Uh :-)

Harald Welte: I want to thank for the translation people as well. Spanish is the next language (after pt_BR) i'm going to learn :)

Ricardo Javier Cardenes Medina: Harald Welte: ;) thanks Harald Welte for spending the time to answer questions and giving the presentation, it has been most appreciated

Harald Welte: dent: depending on the protocol

netlag: tio, eres una makina XD

Ricardo Javier Cardenes Medina: netlag: Ehh...

dent: laforge TCP?

dent: traducionn lepera: Guy, you are a machine XDD

core: netlag xD

Harald Welte: dent: for example, for tcp we have an alternative tcp module, which even tracks the tcp window and knows if a packet is within the valid range of sequence numbers or not

Ricardo Javier Cardenes Medina netlag: "you're cool" would be more appropriate ;)

dent: and is there a log available of this chat for the parts I may have missed before I joined?

dent: yaya, ke kieres

Ricardo Javier Cardenes Medina uno hace lo ke puede

dent: laforge excellent. great work :)

Harald Welte: dent: the logs will be available on the uninet 6fevu pages, for sure.

Ricardo Javier Cardenes Medina: yup http://6fevu.uninet.edu

w8 Harald Welte/dent: of course, as usual...

Harald Welte: for everybody wanting to dig further in netfilter/iptables, i recommend getting the latest package from the homepage or looking into CVS :)

Ricardo Javier Cardenes Medina: We will put it in the next 24 hours

dent:where did the channel name come from? btw

Harald Welte: dent: from the name of the conference. ipv6, Firewalling, Encryption and Vpn in Uninet

w8: dent: ipv6/firewall/encryption/vpn/uninet

Ricardo Javier Cardenes Medina: Harald Welte: Where's the CVS/homepage located right now? kernelnotes have been down for weeks :?

dent: ah

Harald Welte: Ricardo, see above: http://netfilter.gnumonks.org/http://netfilter.samba.org/

Ricardo Javier Cardenes Medina: Harald Welte:: Uh. Ok :)

Harald Welte: http://netfilter.filewatcher.org/

w8: dent: ademas, nos recordaba a algo asi como 6fever, fiebre del sabado noche...

* Ricardo Javier Cardenes Medina: slaps himself for his ignorance

Harald Welte: we always had three homepages to have some kind of redundancy

w8: una rallada como otra de una noche XD

Ricardo Javier Cardenes Medina: I knew of samba.org :)

w8: rayada

Harald Welte: ok, any more questions? If not, i will continue learning PPC assembly and debug glibc-2.2.3 on ppc ;)

Ricardo Javier Cardenes Medina: }:)

w8: :)

Ricardo Javier Cardenes Medina: Ok. Thanks again, Harald Welte:. Have a nice hack }:)

dent Thanks laforge, I was probably the most spammy participent here ;)

Harald Welte: thanks everybody. dent: everybody else was just too shy to ask

dent: is there a mailing list for announcements of future talks?

w8: dent: 6fevu@uninet.edu at the moment

dent: ;)

Harald Welte: thanks everybody. dent: everybody else was just too shy to ask

Harald Welte: ok, well, have a good night everybody. see you...

Ricardo Javier Cardenes Medina: bueno gentes.

w8: esto sacabao

Ricardo Javier Cardenes Medina: Espero que les haya gustado

Ricardo Javier Cardenes Medina: :-)

Ricardo Javier Cardenes Medina: Y que les sea leve

w8: XD

Ricardo Javier Cardenes Medina: Que mañana hay que currar

Y es tardísimo (en esta parte del atlántico)

;-)