lkml.org 
[lkml]   [1999]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectNETLINK and discerning input vs output packets
Date
Greets!

Perhaps an easy question: consider ipchains configured with
CONFIG_IP_FIREWALL_NETLINK and the following rules:

Chain input (policy ACCEPT):
target prot opt source destination ports
- tcp -----o 10.1.1.1 10.2.2.2 1000 -> 2000
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):
target prot opt source destination ports
- tcp -----o any any any -> any
Now, as you know the -o option pushes the data down to /dev/fwdata. Well, the
question is how do I tell what rule caused the packet to be dropped to
userspace? I don't need to know the ipchain name or such, but whether it is
coming INTO or going OUT OF the system. The box may be a router, so checking
the source/destination vs the machine's IP isn't going to work.

Is there anything I can look at inside the iphdr or tcphdr of a packet that
will tell me which direction it's moving?

[ more details ]
In reality what I am doing is writing a stateful/heuristic packet filter with
ipchains. I thought it would be neat that instead of putting a timeout value
on holes opened up, I could examine the incoming packets (that match my
dynamically added ACCEPT rules) and use _that_ flow to keep-alive the accept
rule. (SPF 1.1, which inspired me, watches only outgoing data to determine if
a port needs to be kept open. A unidirectional data flow with UDP, for
example, would get shutdown with that method after its timeout as the inside
box isn't sending back data to keep spf aware that the port needs to remain
open).

Peace!
-- n i c h o l a s j l e o n
elegance through simplicity http://www.mrnick.binary9.net
good fortune through truth icq#2170994
nicholas@binary9.net




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [from the cache]
©2003-2011 Jasper Spaans