The interface gives a 32bit counter total length, 32bit fwmark count,
the name of the interface it's coming from, the ip header, and the
data in the packet itself.
If you mark 'interesting rules' with a firewall mark, you can estimate
which rules were passed. But that's only a workaround, not a solution.
Regards
Frank
Dipl.-Inform. Frank Bernard phone : +49 700 34739255 (0700 34739255)
Ellerstr. 11 vanity : +49 700 FIREWALL (0700 FIREWALL)
60389 Frankfurt fax : +49 69 47885616
Germany email : frankb@ipf.de
www : http://www.linuxwall.de
On Sat, 12 Jun 1999, Nicholas J. Leon wrote:
> Date: Sat, 12 Jun 1999 23:21:08 -0400
> From: Nicholas J. Leon <nicholas@binary9.net>
> To: Linux Kernel List <linux-kernel@vger.rutgers.edu>
> Subject: NETLINK and discerning input vs output packets
>
> 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/
>
-
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/