From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Matthew Donofrio" Subject: How exactly does RELATED work in Connection Tracking? Date: Mon, 21 Oct 2002 22:48:31 -0700 Sender: netfilter-admin@lists.netfilter.org Message-ID: <000801c2798e$a7dcfd70$09c809c0@PENT4> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C27953.FAFDD1E0" Return-path: Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: To: netfilter@lists.netfilter.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C27953.FAFDD1E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone. Before I ask my question, I just want to alert everyone = that I am newbie to Linux and the netfilter architecture. OK, that = being said, here's my question. I'm trying to determine how exactly an = incoming packet is determined to be RELATED to an existing connection in = Connection Tracking. For instance, how exactly does a TCP connection = know that the packet is starting a new connection and this should be = deemed RELATED? What fields (for lack of a better word) are compared to = come to this conclusion? Thanks in advance. -Matt ------=_NextPart_000_0005_01C27953.FAFDD1E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi everyone. Before I ask my = question, I just=20 want to alert everyone that I am newbie to Linux and the = netfilter=20 architecture. OK, that being said, here's my question. I'm = trying to=20 determine how exactly an incoming packet is determined to be RELATED to = an=20 existing connection in Connection Tracking. For instance, how = exactly=20 does a TCP connection know that the packet is starting a=20 new connection and this should be deemed RELATED? What fields = (for=20 lack of a better word) are compared to come to this conclusion? = Thanks in=20 advance.

-Matt

------=_NextPart_000_0005_01C27953.FAFDD1E0-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cedric Blancher Subject: Re: How exactly does RELATED work in Connection Tracking? Date: 23 Oct 2002 00:21:17 +0200 Sender: netfilter-admin@lists.netfilter.org Message-ID: <1035325277.10494.18.camel@elendil> References: <000801c2798e$a7dcfd70$09c809c0@PENT4> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <000801c2798e$a7dcfd70$09c809c0@PENT4> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="iso-8859-1" To: Matthew Donofrio Cc: netfilter@lists.netfilter.org Le mar 22/10/2002 =E0 07:48, Matthew Donofrio a =E9crit : > I'm trying to determine how exactly an incoming packet is determined > to be RELATED to an existing connection in Connection Tracking. For > instance, how exactly does a TCP connection know that the packet is > starting a new connection and this should be deemed RELATED? What > fields (for lack of a better word) are compared to come to this > conclusion? I am no Netfilter developper, but this is what I understood from all I've read on the subject. Connection tracking relies on data structures. In those, to be quick, you have tuples that are used to recognise packets going both ways. A tuple is a set of datas that caracterize a packet for Netfilter. Theses tuples are used firstly to build conntrack table entries, and then to try to match theses entries against further packets. That means when you see a packet, you can calculate its own tuple, and then compare it to the ones that are in data structures that represent current conntracked flows. When you load an ip_conntrack module, such as ip_conntrack_ftp, it starts to look at specific network flows. For FTP conntrack, it looks at every TCP connection destined to port 21. Then, it tries to spot data connection negociation into them (PORT and OK that follows PASSIVE). When spot, theses commands are parsed, and a tuple is extracted to match the first packet of the rekated connection. As an example, when you see parameters associated to PORT command, you are able to exactly know what packet will initiate data connection. This extracted tuple is called an expectation. When a packet reaches the box, then Netfilter looks at it, extract from the header its own tuple and then compares it to known tuples that are part of current conntracked connections. If it matches one of theses tuples, then it is ESTABLISHED. It is also compared to all expectations. If it matches one expectation, then we know this packet is RELATED (and if it does not match anything, it is NEW). Then, we can create a new structure for him with tuples and so on and treat the flow as others. Hope this 2 cents of euro will help you ;) --=20 C=E9dric Blancher IT systems and networks security expert - Cartel S=E9curit=E9 Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99 PGP KeyID:157E98EE FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cedric Blancher Subject: Re: How exactly does RELATED work in Connection Tracking? Date: 23 Oct 2002 15:26:22 +0200 Sender: netfilter-admin@lists.netfilter.org Message-ID: <1035379582.8853.69.camel@elendil> References: <000801c2798e$a7dcfd70$09c809c0@PENT4> <1035325277.10494.18.camel@elendil> <000b01c27aac$d6b2a270$09c809c0@PENT4> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <000b01c27aac$d6b2a270$09c809c0@PENT4> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="iso-8859-1" To: Matthew Donofrio Cc: netfilter@lists.netfilter.org Le mer 23/10/2002 =E0 17:57, Matthew Donofrio a =E9crit : > The tuple is just the source address and destination address for a > particular packet, correct? No, because your box can have multiple different flows with the same destination. A tuple as src address, dst address, layer 4 protocol and layer 4 datas, such as src and dst ports for TCP or UDP. > So is it safe to say that the only fields that are compared for > connection tracking are the source and destination addresses? No it's not sufficient. you have to look at layer 4 datas. =20 > So, if a packet comes in and the source and destination addresses > match an entry in the conntrack state table, then we can say that > it is part of some ESTABLISHED connection. It is established if its tuple (as defined below) matches an entry in the conntrack table, i.e. if it is the same than the tuples associated to entries. Good reading for you are : http://www.gnumonks.org/presentations/netfilter-knf2002/netfilter-knf2002= .pdf http://www.gnumonks.org/presentations/netfilter-internals-lt2002/netfilte= r-internals-lt2002.pdf --=20 C=E9dric Blancher Consultant en s=E9curit=E9 des syst=E8mes et r=E9seaux - Cartel S=E9curi= t=E9 T=E9l: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99 PGP KeyID:157E98EE FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Matthew Donofrio" Subject: Re: How exactly does RELATED work in Connection Tracking? Date: Wed, 23 Oct 2002 08:57:06 -0700 Sender: netfilter-admin@lists.netfilter.org Message-ID: <000b01c27aac$d6b2a270$09c809c0@PENT4> References: <000801c2798e$a7dcfd70$09c809c0@PENT4> <1035325277.10494.18.camel@elendil> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: Cedric Blancher Cc: netfilter@lists.netfilter.org >Connection tracking relies on data structures. In those, to be quick, >you have tuples that are used to recognise packets going both ways. A >tuple is a set of datas that caracterize a packet for Netfilter. Theses >tuples are used firstly to build conntrack table entries, and then to >try to match theses entries against further packets. That means when you >see a packet, you can calculate its own tuple, and then compare it to >the ones that are in data structures that represent current conntracked >flows. >When a packet reaches the box, then Netfilter looks at it, extract from >the header its own tuple and then compares it to known tuples that are >part of current conntracked connections. If it matches one of theses >tuples, then it is ESTABLISHED. It is also compared to all expectations. >If it matches one expectation, then we know this packet is RELATED (and >if it does not match anything, it is NEW). Then, we can create a new >structure for him with tuples and so on and treat the flow as others. The tuple is just the source address and destination address for a particular packet, correct? So is it safe to say that the only fields that are compared for connection tracking are the source and destination addresses? So, if a packet comes in and the source and destination addresses match an entry in the conntrack state table, then we can say that it is part of some ESTABLISHED connection. Thanks again. -Matt From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antony Stone Subject: Re: How exactly does RELATED work in Connection Tracking? Date: Thu, 24 Oct 2002 11:06:37 +0100 Sender: netfilter-admin@lists.netfilter.org Message-ID: <200210241006.g9OA6gL04057@vulcan.rissington.net> References: <000801c2798e$a7dcfd70$09c809c0@PENT4> <1035325277.10494.18.camel@elendil> <000b01c27aac$d6b2a270$09c809c0@PENT4> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <000b01c27aac$d6b2a270$09c809c0@PENT4> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: netfilter@lists.netfilter.org On Wednesday 23 October 2002 4:57 pm, Matthew Donofrio wrote: > >Connection tracking relies on data structures. In those, to be quick, > >you have tuples that are used to recognise packets going both ways. A > >tuple is a set of datas that caracterize a packet for Netfilter. Theses > >tuples are used firstly to build conntrack table entries, and then to > >try to match theses entries against further packets. That means when you > >see a packet, you can calculate its own tuple, and then compare it to > >the ones that are in data structures that represent current conntracked > >flows. > > > >When a packet reaches the box, then Netfilter looks at it, extract from > >the header its own tuple and then compares it to known tuples that are > >part of current conntracked connections. If it matches one of theses > >tuples, then it is ESTABLISHED. It is also compared to all expectations. > >If it matches one expectation, then we know this packet is RELATED (and > >if it does not match anything, it is NEW). Then, we can create a new > >structure for him with tuples and so on and treat the flow as others. > > The tuple is just the source address and destination address for a > particular packet, correct? No. For TCP and UDP packets the tuple also contains the source and destination port numbers. > So is it safe to say that the only fields > that are compared for connection tracking are the source and destination > addresses? No, otherwise if a client connected to a server using http, and then set up a new connection to the same server by ssh (same IP addresses, different port numbers), they would appear to be the same connection ! > So, if a packet comes in and the source and destination > addresses match an entry in the conntrack state table, then we can say that > it is part of some ESTABLISHED connection. Thanks again. If a packet comes in and the source and destination addresses and port numbers match an entry in the conntrack state table (with source and destination either way round, to allow for reply packets) then we can say that it is part of some ESTABLISHED connection. You're welcome. Antony. -- How I want a drink, alcoholic of course, after the heavy chapters involving quantum mechanics. - 3.14159265358979