On 01/16/08 03:37, DI Roman Fiedler wrote:
The idea was that the intercept host(s) can see the original source and destination IP for traffic analysis (check if one source host scans all destinations or just permanently hits one), but I guess this is not a "must have". No matter which of these method is used, both of them split the traffic in PREROUTING and before the filter tables, which I want to avoid somehow (see below for explanation).
I'm not sure what your Layer 2 and Layer 3 setup looks like so I can't say for sure, but I think I would be tempted to look at doing some sort of Layer 2 filtering / bridging to accomplish what you are after. More specifically, if I was not happy with the traffic, I would alter its Layer 2 destination MAC address to that of the honey pot. This way, the traffic would still have the appropriate Layer 3 source and destination IP addresses.
That's the problem: Our setup contains 7 networkcards, with vlan tagging more than 10 networks plus some vpns. We also need to do policy routing since some IPs occur more than once in the complete network setup. Some hundred rules are contained in a shorewall config. The problem: shorewall adds the filter rules to the filter table, after routing and natting, so massive change of setup would be needed to make pre-route decisions work.
It sounds like things are fairly complex with lots of interfaces and further more is likely to change with time as business needs change too. As such, with out knowing more about your filtering rules, I can't say for sure if a Layer 2 approach would work for you or not. I'm betting that you would need a mixture of EBTables and IPTables to do all the filtering that you want on the bridged traffic. That is to say you could do the simple filtering via EBTables and only use IPTables (seeing the bridged traffic) for the things that EBTables can not do (i.e. connection state and other advanced match extensions).
My goal was to do it with minimal effort, e.g. make an iptables-save output patch that will transform the current iptables data to a setup that can do the intercepting. I do not think that it would be possible to do the thing with shorewall directly and I want to avoid recoding all filter rules in the prerouting table (some would be impossible since they use output interface for decision, which is not defined at this point).
It may be possible to allow Shorewall manage the IPTables rules and you personally (possibly via scripts) manage EBTables rules before IPTables sees the packets. If you did not need to use IPTables to filter the bridged traffic (that is to say you are comfortable with stateless filtering on source / destination protocol and / or port) you could bridge the traffic with out IPTables being any the wiser. If you can use EBTables to do your filtering, I'd hope that you could put EBTables and bridging in as a shim between the NICs and where IPTables picks up. You could possibly even bypass IPTables for some traffic entirely.
Of course with bridging you will have to manage your IP ranges appropriately.
I thought that perhaps somebody has done experiments with a "strange" setups, e.g. use a tricky combination of MIRROR targets or a loop via some geek netlink program that can feedback the packet from the ULOG target to the interface receive methods so that it can pass PREROUTING twice.
Such is probably possible, though I'm not sure of any thing like that. You may want to look in to how various IDS / IPS systems work.
Grant. . . . - To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
