* RE: logging of successful tcp connections
@ 2005-04-21 22:28 christopher.f.ulherr
2005-04-21 23:55 ` Taylor Grant
0 siblings, 1 reply; 6+ messages in thread
From: christopher.f.ulherr @ 2005-04-21 22:28 UTC (permalink / raw)
To: gtaylor; +Cc: netfilter
> No, I don't think there is a ""trivial way to do this. What
> initially comes to mind is to use the recent match extension
> for the history mechanism that is needed in this scenario. I
> think you will need to so something along these lines to come
> even close to what you are after:
>
> 1) Put all traffic in a NEW state in to a recent list
> (recent_NEW) and continue to handle it like you normally would.
> 2) Put all traffic in an ESTABLISHED state in to a
> (different) recent list (recent_ESTABLISHED) and continue to
> handle it like you normally would.
> 3) If traffic is ESTABLISHED that is on the recent_NEW list
> but not on the recent_ESTABLISHED list you know that this
> connection recently (as in this connection) transitioned from
> the NEW state to the ESTABLISHED state and thus would be
> added to the recent_ESTABLISHED list. I would be tempted to
> jump to a new sub chain where you could log and do any other
> actions on the packet that you wanted to.
> 4) If traffic is ESTABLISHED that is on the
> recent_ESTABLISHED list and has the FIN flag set in the
> header you know that this connection recently (as in this
> connection) transitioned from the ESTABLISHED state to a
> closing (FIN) state and thus would be added to the recent_FIN
> list. I would be tempted to jump to a new sub chain where
> you could log and do any other actions on the packet that you
> wanted to.
>
> You would also want to watch for any traffic that came in
> with the RST flag set as well as traffic that never goes
> through a FIN state.
>
> Keep in mind that this is all theoretical and had not even
> been cooded out (IPTables script written) and thus should be
> taken as what I would try first to set something like this
> up. If you would like to give me some network config that
> you are working with I would be happy to see if I could not
> come up with working examples for you to use.
Hrmm... I've looked over the recent patch, but I'm not certain how to
implement this 'and' logic "if it's in list A, but not in list B".. etc.
There must be some place in the connection tracking code where a simple
log can be placed. I'm not that familiar with the internals, but it
would seem that just before updating the state, you could just printk a
log. Am I way off here?
Chris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: logging of successful tcp connections
2005-04-21 22:28 logging of successful tcp connections christopher.f.ulherr
@ 2005-04-21 23:55 ` Taylor Grant
0 siblings, 0 replies; 6+ messages in thread
From: Taylor Grant @ 2005-04-21 23:55 UTC (permalink / raw)
To: christopher.f.ulherr; +Cc: netfilter
> Hrmm... I've looked over the recent patch, but I'm not certain how to
> implement this 'and' logic "if it's in list A, but not in list B".. etc.
If you wanted to see if a packet was transitioning from NEW to ESTABLISHED I think it would be as simple as something like the following:
iptables -t filter -A FORWARD -i $INet -o $LAN -d $INet_IP -m recent --rcheck --name recent_NEW -m recent ! --rcheck --name recent_ESTABLISHED -j Transition_to_ESTABLISHED
I'm not sure about the placement of the "!" on the line, you might have to play with it a bit to make sure that the syntax is correct. Anyone have any input here?
> There must be some place in the connection tracking code where a simple
> log can be placed. I'm not that familiar with the internals, but it
> would seem that just before updating the state, you could just printk a
> log. Am I way off here?
I'm sure there is a place in the kernel code that this could be put, though I don't know as if many people would want such a thing. It might be able to be there and something that is off by default and then turned on via /proc.
Grant. . . .
^ permalink raw reply [flat|nested] 6+ messages in thread
* logging of successful tcp connections
@ 2005-04-21 17:28 christopher.f.ulherr
2005-04-21 19:58 ` Taylor, Grant
0 siblings, 1 reply; 6+ messages in thread
From: christopher.f.ulherr @ 2005-04-21 17:28 UTC (permalink / raw)
To: netfilter
I would like to know if there is a way I can log only successful tcp
connections. I'm only interested in successful (established) connections,
and not just syn "connection attempts". I guess what I need is a way to log
a single packet if it caused a state transition from NEW to ESTABLISHED. It
would also be helpful to log the packet that terminated the connection
(state change from established). In this manner, we could easily tell what
connections were made, and their duration (and not rely on the userland
application to log this info).
I've looked into using the state matching, but couldn't achieve this
specific functionality with that.
Is there some trivial way to accomplish this I am overlooking?
Thanks,
Chris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: logging of successful tcp connections
2005-04-21 17:28 christopher.f.ulherr
@ 2005-04-21 19:58 ` Taylor, Grant
0 siblings, 0 replies; 6+ messages in thread
From: Taylor, Grant @ 2005-04-21 19:58 UTC (permalink / raw)
To: christopher.f.ulherr; +Cc: netfilter
> I would like to know if there is a way I can log only successful tcp
> connections. I'm only interested in successful (established) connections,
> and not just syn "connection attempts". I guess what I need is a way to log
> a single packet if it caused a state transition from NEW to ESTABLISHED. It
> would also be helpful to log the packet that terminated the connection
> (state change from established). In this manner, we could easily tell what
> connections were made, and their duration (and not rely on the userland
> application to log this info).
You don't ask for any thing easy do you. ;)
> I've looked into using the state matching, but couldn't achieve this
> specific functionality with that.
I think this is something that is beyond basic state matching as state matching is just matching on the current state of the packet / connection. This does not have any thing to do with the prior state of the packet / connection.
> Is there some trivial way to accomplish this I am overlooking?
No, I don't think there is a ""trivial way to do this. What initially comes to mind is to use the recent match extension for the history mechanism that is needed in this scenario. I think you will need to so something along these lines to come even close to what you are after:
1) Put all traffic in a NEW state in to a recent list (recent_NEW) and continue to handle it like you normally would.
2) Put all traffic in an ESTABLISHED state in to a (different) recent list (recent_ESTABLISHED) and continue to handle it like you normally would.
3) If traffic is ESTABLISHED that is on the recent_NEW list but not on the recent_ESTABLISHED list you know that this connection recently (as in this connection) transitioned from the NEW state to the ESTABLISHED state and thus would be added to the recent_ESTABLISHED list. I would be tempted to jump to a new sub chain where you could log and do any other actions on the packet that you wanted to.
4) If traffic is ESTABLISHED that is on the recent_ESTABLISHED list and has the FIN flag set in the header you know that this connection recently (as in this connection) transitioned from the ESTABLISHED state to a closing (FIN) state and thus would be added to the recent_FIN list. I would be tempted to jump to a new sub chain where you could log and do any other actions on the packet that you wanted to.
You would also want to watch for any traffic that came in with the RST flag set as well as traffic that never goes through a FIN state.
Keep in mind that this is all theoretical and had not even been cooded out (IPTables script written) and thus should be taken as what I would try first to set something like this up. If you would like to give me some network config that you are working with I would be happy to see if I could not come up with working examples for you to use.
Grant. . . .
^ permalink raw reply [flat|nested] 6+ messages in thread
* logging of successful tcp connections
@ 2005-04-21 16:38 christopher.f.ulherr
2005-04-22 15:14 ` Eric Leblond
0 siblings, 1 reply; 6+ messages in thread
From: christopher.f.ulherr @ 2005-04-21 16:38 UTC (permalink / raw)
To: netfilter
I would like to know if there is a way I can log only successful tcp
connections. I'm only interested in successful (established)
connections, and not just syn "connection attempts". I guess what I need
is a way to log a single packet if it caused a state transition from NEW
to ESTABLISHED. It would also be helpful to log the packet that
terminated the connection (state change from established). In this
manner, we could easily tell what connections were made, and their
duration (and not rely on the userland application to log this info).
I've looked into using the state matching, but couldn't achieve this
specific functionality with that.
Is there some trivial way to accomplish this I am overlooking?
Thanks,
Chris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: logging of successful tcp connections
2005-04-21 16:38 christopher.f.ulherr
@ 2005-04-22 15:14 ` Eric Leblond
0 siblings, 0 replies; 6+ messages in thread
From: Eric Leblond @ 2005-04-22 15:14 UTC (permalink / raw)
To: christopher.f.ulherr; +Cc: netfilter
Le jeudi 21 avril 2005 à 09:38 -0700,
christopher.f.ulherr@exgate.tek.com a écrit :
> I would like to know if there is a way I can log only successful tcp
> connections. I'm only interested in successful (established)
> connections, and not just syn "connection attempts". I guess what I need
> is a way to log a single packet if it caused a state transition from NEW
> to ESTABLISHED. It would also be helpful to log the packet that
> terminated the connection (state change from established).
Have a look at :
http://regit.free.fr/nufw/content.php?article.11
We used this in the NuFW project(http://www.nufw.org) to track the state
of connections.
> In this
> manner, we could easily tell what connections were made, and their
> duration (and not rely on the userland application to log this info).
>
> I've looked into using the state matching, but couldn't achieve this
> specific functionality with that.
>
>
> Is there some trivial way to accomplish this I am overlooking?
>
>
> Thanks,
> Chris
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-04-22 15:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-21 22:28 logging of successful tcp connections christopher.f.ulherr
2005-04-21 23:55 ` Taylor Grant
-- strict thread matches above, loose matches on Subject: below --
2005-04-21 17:28 christopher.f.ulherr
2005-04-21 19:58 ` Taylor, Grant
2005-04-21 16:38 christopher.f.ulherr
2005-04-22 15:14 ` Eric Leblond
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox