On 09/25/08 09:54, Brent Clark wrote:
But what I have to do is that I keep having to remind myself is that iptables is for layer 3 /4 operation. But then what does layer 7 control?
Keep in mind that IPTables can filter on layers 2, 3, 4, and 7, depending on how it is used.
Well it seems to be the way to go, look at other tools like snort inline. And also whats interesting is that I see some of the BSD lot use / recommend this type of filtering (snort2pf).
I'm not saying that there is any thing wrong with moblock. I just find it a little odd that we are passing traffic from kernel space to user space to filter (as I (mis)understood it) by IP, a layer 3 address. So I guess my question is why not just filter with IPTables on layer 3? Why pass from kernel space to user space to do the filtering if we don't have to.
Now, if one of moblock's advantages is that it can take pre-generated files of IPs to filter and use them directly, then that is a plus. I would just be more interested in something that could feed those IPs in to something like an IP Set and do the filtering in kernel space.
It is my (mis)understanding that Snort (and the likes) do a lot more than simple layer 2 / 3 / 4 / 7 filtering. I.e. they take notice of a LOT more different things including timing between what is done. In some ways I look at things like Snort as doing stateful filtering across multiple layers as a whole rather than each layer individually. There is also the added advantage that things like Snort tend to be platform agnostic and thus easier to update where as IPTables / pf / etc are platform dependent and not portable.
Back to above, I'd be very interested in something that could translate the guarding.p2p and p2p.p2b files in to something like an IPSet. I think that would be a wonderful use. Download platform independent libraries and then translate them in to platform dependent and native in kernel filtering. Just my $0.02 worth.
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