* matching the first packet of a connection
@ 2005-05-04 15:21 Eric Leblond
2005-05-04 17:43 ` George Alexandru Dragoi
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Eric Leblond @ 2005-05-04 15:21 UTC (permalink / raw)
To: netfilter
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>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: matching the first packet of a connection
2005-05-04 15:21 matching the first packet of a connection Eric Leblond
@ 2005-05-04 17:43 ` George Alexandru Dragoi
2005-05-04 18:50 ` Eric Leblond
2005-05-04 17:57 ` Thomas Jones
2005-05-04 19:37 ` Taylor, Grant
2 siblings, 1 reply; 11+ messages in thread
From: George Alexandru Dragoi @ 2005-05-04 17:43 UTC (permalink / raw)
To: Eric Leblond; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: matching the first packet of a connection
2005-05-04 15:21 matching the first packet of a connection Eric Leblond
2005-05-04 17:43 ` George Alexandru Dragoi
@ 2005-05-04 17:57 ` Thomas Jones
2005-05-04 18:11 ` Daniel Lopes
2005-05-04 19:37 ` Taylor, Grant
2 siblings, 1 reply; 11+ messages in thread
From: Thomas Jones @ 2005-05-04 17:57 UTC (permalink / raw)
To: Eric Leblond; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: matching the first packet of a connection
2005-05-04 17:57 ` Thomas Jones
@ 2005-05-04 18:11 ` Daniel Lopes
2005-05-04 18:34 ` Jason Opperisano
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Lopes @ 2005-05-04 18:11 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: matching the first packet of a connection
2005-05-04 18:11 ` Daniel Lopes
@ 2005-05-04 18:34 ` Jason Opperisano
0 siblings, 0 replies; 11+ messages in thread
From: Jason Opperisano @ 2005-05-04 18:34 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: matching the first packet of a connection
2005-05-04 17:43 ` George Alexandru Dragoi
@ 2005-05-04 18:50 ` Eric Leblond
0 siblings, 0 replies; 11+ messages in thread
From: Eric Leblond @ 2005-05-04 18:50 UTC (permalink / raw)
To: George Alexandru Dragoi; +Cc: netfilter
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: matching the first packet of a connection
2005-05-04 15:21 matching the first packet of a connection Eric Leblond
2005-05-04 17:43 ` George Alexandru Dragoi
2005-05-04 17:57 ` Thomas Jones
@ 2005-05-04 19:37 ` Taylor, Grant
2005-05-04 21:21 ` Eric Leblond
2005-05-04 21:30 ` Eric Leblond
2 siblings, 2 replies; 11+ messages in thread
From: Taylor, Grant @ 2005-05-04 19:37 UTC (permalink / raw)
To: netfilter
> 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. . . .
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: matching the first packet of a connection
2005-05-04 19:37 ` Taylor, Grant
@ 2005-05-04 21:21 ` Eric Leblond
2005-05-04 21:36 ` Taylor, Grant
2005-05-05 7:53 ` Taylor, Grant
2005-05-04 21:30 ` Eric Leblond
1 sibling, 2 replies; 11+ messages in thread
From: Eric Leblond @ 2005-05-04 21:21 UTC (permalink / raw)
To: Taylor, Grant; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: matching the first packet of a connection
2005-05-04 19:37 ` Taylor, Grant
2005-05-04 21:21 ` Eric Leblond
@ 2005-05-04 21:30 ` Eric Leblond
1 sibling, 0 replies; 11+ messages in thread
From: Eric Leblond @ 2005-05-04 21:30 UTC (permalink / raw)
To: netfilter
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: matching the first packet of a connection
2005-05-04 21:21 ` Eric Leblond
@ 2005-05-04 21:36 ` Taylor, Grant
2005-05-05 7:53 ` Taylor, Grant
1 sibling, 0 replies; 11+ messages in thread
From: Taylor, Grant @ 2005-05-04 21:36 UTC (permalink / raw)
To: netfilter
> 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. . . .
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: matching the first packet of a connection
2005-05-04 21:21 ` Eric Leblond
2005-05-04 21:36 ` Taylor, Grant
@ 2005-05-05 7:53 ` Taylor, Grant
1 sibling, 0 replies; 11+ messages in thread
From: Taylor, Grant @ 2005-05-05 7:53 UTC (permalink / raw)
To: netfilter
> 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. . . .
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-05-05 7:53 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-04 15:21 matching the first packet of a connection Eric Leblond
2005-05-04 17:43 ` George Alexandru Dragoi
2005-05-04 18:50 ` Eric Leblond
2005-05-04 17:57 ` Thomas Jones
2005-05-04 18:11 ` Daniel Lopes
2005-05-04 18:34 ` Jason Opperisano
2005-05-04 19:37 ` Taylor, Grant
2005-05-04 21:21 ` Eric Leblond
2005-05-04 21:36 ` Taylor, Grant
2005-05-05 7:53 ` Taylor, Grant
2005-05-04 21:30 ` Eric Leblond
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.