matching the first packet of a connection

matching the first packet of a connection

[Eric Leblond]

Hi,

I'm trying to match the first packet of a connection : for a TCP
connection I want to match the first SYN packet received by the firewall
and ignore the possible reemission, in fact I want to accept them.

Is this possible ?

I've try to use the conntrack module but I was not successful.

BR,
-- 
Eric Leblond <eric@inl.fr>

Re: matching the first packet of a connection

[George Alexandru Dragoi]

If you have nothing against ip_conntrack, use -m state --state NEW and
accepts those connections


On 5/4/05, Eric Leblond <eric@inl.fr> wrote:
> Hi,
> 
> I'm trying to match the first packet of a connection : for a TCP
> connection I want to match the first SYN packet received by the firewall
> and ignore the possible reemission, in fact I want to accept them.
> 
> Is this possible ?
> 
> I've try to use the conntrack module but I was not successful.
> 
> BR,
> --
> Eric Leblond <eric@inl.fr>
> 
> 


-- 
Bla bla

Re: matching the first packet of a connection

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

On Wed, 2005-05-04 at 20:43 +0300, George Alexandru Dragoi wrote:
> If you have nothing against ip_conntrack, use -m state --state NEW and
> accepts those connections

question was not so easy ;-) 
I mean that I want to match the "FIRST" SYN packet and not the second
and following.

BR,
-- 
Eric Leblond <eric@inl.fr>
INL

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: matching the first packet of a connection

[Thomas Jones]

Eric Leblond wrote:

>Hi,
>
>I'm trying to match the first packet of a connection : for a TCP
>connection I want to match the first SYN packet received by the firewall
>and ignore the possible reemission, in fact I want to accept them.
>
>Is this possible ?
>
>I've try to use the conntrack module but I was not successful.
>
>BR,
>  
>
The "tcp filter" Table Match Operations provide:

-p tcp --syn

Thomas

Re: matching the first packet of a connection

[Daniel Lopes]

Thomas Jones schrieb:
> Eric Leblond wrote:
> 
> 
>>Hi,
>>
>>I'm trying to match the first packet of a connection : for a TCP
>>connection I want to match the first SYN packet received by the firewall
>>and ignore the possible reemission, in fact I want to accept them.
>>
>>Is this possible ?
>>
>>I've try to use the conntrack module but I was not successful.
>>
>>BR,
>> 
>>
> 
> The "tcp filter" Table Match Operations provide:
> 
> -p tcp --syn
> 
> Thomas
> 
> 
or something like this:
-p tcp --tcp-flags ALL SYN -m state --state NEW

Re: matching the first packet of a connection

[Jason Opperisano]

On Wed, May 04, 2005 at 08:11:11PM +0200, Daniel Lopes wrote:
> >The "tcp filter" Table Match Operations provide:
> >
> >-p tcp --syn
> >
> >Thomas
> >
> or something like this:
> -p tcp --tcp-flags ALL SYN -m state --state NEW

it probably doesn't matter, but a "safer" match would probably be:

  -p tcp SYN,ACK,FIN,RST SYN

i only say that because CWR and ECN are acceptable flags that may be set
on a TCP SYN.  i don't believe --tcp-flags can match on these today,
and i don't know if '--tcp-flags ALL' will get confused by these bits
being set (i don't think it would), but i'd venture to guess at some
point "ALL" will include them and it's something to be aware of.

from RFC 2481 section 6.1.1

"When a node sends a TCP SYN packet, it may set the ECN-Echo and CWR
 flags in the TCP header.  For a SYN packet, the setting of both the
 ECN-Echo and CWR flags are defined as an indication that the sending
 TCP is ECN-Capable, rather than as an indication of congestion or of
 response to congestion."

-j

--
"Stewie: Why does that man drop his club before he runs? I would
 bring it with me."
        --Family Guy

Re: matching the first packet of a connection

[Taylor, Grant]

> I'm trying to match the first packet of a connection : for a TCP
> connection I want to match the first SYN packet received by the firewall
> and ignore the possible reemission, in fact I want to accept them.
> 
> Is this possible ?
> 
> I've try to use the conntrack module but I was not successful.

Question:  Are you wanting to just silently DROP the first connection attempt and force people to try to reconnect via retransmission of the SYN packet?  If that is the case you will want to do something out side of the connection tracking match extensions that exist because (as far as I know and understand) they all deal within a given connection.  You are really wanting to break / prevent one connection attempt and then allow the subsequent ones.  Or at least that's how I understand what you have written.  I have a feeling that you will be playing with the recent or set match extensions where you add a connection attempt to a recent list or set list while dropping the first connection attempt packet.  Subsequent connection attempt packets can then be matched against the recent list or set list to see if there has been a connection attempt dropped and if so accept the present connection
  attempt.

If you give me more to work with I might be able to come up with a rule set to help you out.



Grant. . . .

Re: matching the first packet of a connection

[Eric Leblond]

Hi,

Problem seems difficult to explain, here's the detail :

In the scope of the NuFW project we need to queue SYN packets for
connection we want to authenticate (see http://www.nufw.org/ for details
on principles). For a single connection we want to QUEUE only the first
packet coming to the firewall (SYN packet in the case of TCP). All
subsequent packets of the connection even if they are also SYN packet
(if for example server is unreachable or does not exist) have to me
authorized or drop depending of the decision taken on the first packet.
In fact this is an extension of the ESTABLISHED or RELATED match.

I hope my problem is clearly explained this time.

BR and thanks for the help


On Wed, 2005-05-04 at 14:37 -0500, Taylor, Grant wrote:
> > I'm trying to match the first packet of a connection : for a TCP
> > connection I want to match the first SYN packet received by the firewall
> > and ignore the possible reemission, in fact I want to accept them.
> > 
> > Is this possible ?
> > 
> > I've try to use the conntrack module but I was not successful.
> 
> Question:  Are you wanting to just silently DROP the first connection attempt and force people to try to reconnect via retransmission of the SYN packet?  If that is the case you will want to do something out side of the connection tracking match extensions that exist because (as far as I know and understand) they all deal within a given connection.  You are really wanting to break / prevent one connection attempt and then allow the subsequent ones.  Or at least that's how I understand what you have written.  I have a feeling that you will be playing with the recent or set match extensions where you add a connection attempt to a recent list or set list while dropping the first connection attempt packet.  Subsequent connection attempt packets can then be matched against the recent list or set list to see if there has been a connection attempt dropped and if so accept the present connecti
 on attempt.
> 
> If you give me more to work with I might be able to come up with a rule set to help you out.
> 
> 
> 
> Grant. . . .
> 
-- 
Eric Leblond <eric@regit.org>
NuFW, Now User Filtering Works : http://www.nufw.org

Re: matching the first packet of a connection

[Taylor, Grant]

> In the scope of the NuFW project we need to queue SYN packets for
> connection we want to authenticate (see http://www.nufw.org/ for details
> on principles). For a single connection we want to QUEUE only the first
> packet coming to the firewall (SYN packet in the case of TCP). All
> subsequent packets of the connection even if they are also SYN packet
> (if for example server is unreachable or does not exist) have to me
> authorized or drop depending of the decision taken on the first packet.
> In fact this is an extension of the ESTABLISHED or RELATED match.

I'm not quite sure how to "queue" packets as take them in to some sort of FIFO with a pause but possibly you do and you just need help matching which packets to queue.  I know with the recent match extension you could probably ""remember a connection attempt (how to remember for just that connection is a question in and of it's self though (working on this)) and queue the first one and then take some sort of action on subsequent based on how the packets are dequeued.  I think you are going to need to rely on some sort of external input, possibly via the condition match extension.  I've seen and briefly read about NuFU but I need to do so again to get up to speed to help with this.  Let me go do some reading and I'll get back to you.



Grant. . . .

Re: matching the first packet of a connection

[Taylor, Grant]

> In the scope of the NuFW project we need to queue SYN packets for
> connection we want to authenticate (see http://www.nufw.org/ for details
> on principles). For a single connection we want to QUEUE only the first
> packet coming to the firewall (SYN packet in the case of TCP). All
> subsequent packets of the connection even if they are also SYN packet
> (if for example server is unreachable or does not exist) have to me
> authorized or drop depending of the decision taken on the first packet.
> In fact this is an extension of the ESTABLISHED or RELATED match.

After doing much deliberating and research I have come up with one thing that you might be able to try:

iptables -t filter -A FORWARD -i $LAN -o $INet -m state --state NEW -m connbytes ! --connbytes 1: --connbytes-dir original --connbytes-mode packets -j QUEUE

In theory this rule will look for and match against any packet that is passing from the $LAN to the $INet with a state of NEW and has NOT seen more than one packet coming from the original sending system.  After reading about NuFW they are queuing packets via the QUEUE target.

Give this a shot and let me know what you think.



Grant. . . .

Re: matching the first packet of a connection

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]

Hi,

Problem seems difficult to explain (and I'm not speaking well tonight),
here's the detail :

In the scope of the NuFW project we need to queue SYN packets for
connection we want to authenticate (see http://www.nufw.org/ for details
on principles). For a single connection we want to QUEUE only the first
packet coming to the firewall (SYN packet in the case of TCP). All
subsequent packets of the connection even if they are also SYN packet
(if for example server is unreachable or does not exist) have to me
authorized or drop depending of the decision taken on the first packet.
In fact this is an extension of the ESTABLISHED or RELATED match.

I hope my problem is clearly explained this time.

BR and thanks for the help


On Wed, 2005-05-04 at 14:37 -0500, Taylor, Grant wrote:
> > I'm trying to match the first packet of a connection : for a TCP
> > connection I want to match the first SYN packet received by the firewall
> > and ignore the possible reemission, in fact I want to accept them.
> > 
> > Is this possible ?
> > 
> > I've try to use the conntrack module but I was not successful.
> 
> Question:  Are you wanting to just silently DROP the first connection attempt and force people to try to reconnect via retransmission of the SYN packet?  If that is the case you will want to do something out side of the connection tracking match extensions that exist because (as far as I know and understand) they all deal within a given connection.  You are really wanting to break / prevent one connection attempt and then allow the subsequent ones.  Or at least that's how I understand what you have written.  I have a feeling that you will be playing with the recent or set match extensions where you add a connection attempt to a recent list or set list while dropping the first connection attempt packet.  Subsequent connection attempt packets can then be matched against the recent list or set list to see if there has been a connection attempt dropped and if so accept the present connection attempt.
> 
> If you give me more to work with I might be able to come up with a rule set to help you out.
> 
> 
> 
> Grant. . . .
> 
-- 
Eric Leblond <eric@regit.org>
NuFW, Now User Filtering Works : http://www.nufw.org
-- 
Eric Leblond <eric@inl.fr>
INL

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]