Hello, Le dimanche 15 juillet 2012 à 23:36 +0100, Mr Dash Four a écrit : > >> Currently, NFCT reports absolutely everything, which is not what I > >> really want as I have to sift through thousands of logs, not to mention > >> that by reporting everything the system load is much higher. > >> > >> So, is there a way for me to do that, somehow? > >> > > > > Not now but I'm working on it: Pablo has made a filter system in > > libnetfilter_conntrack. I will used it to filter. > > > This would be some awesome feature. I think this new filter which > implements "custom" restrictions should not be for a particular input > filter, but rather be universal. Yes and no ;) (maybe maybe) > In other words, to be able to > customise, say, certain IP addresses/subnets, certain ethernet > interfaces etc, and then used anywhere in stack statements - NFCT, NFLOG > and so on. If this universal filter is an excellent idea, it will suffer from some performance issue. The NFCT filter I'm currently implementing does the filtering inside the kernel which is really efficient. For NFLOG, kernel filtering can be done via iptables. Implementing a userpsace filter is indeed a good idea but I don't think it is possible to do a kernel filtering ulogd module. The ulogd architecture will hardly deal with that because you will not be able to access to the constructor (in the input plugin) from the filter module. > > If this is implemented, it will certainly make ulogd2 very powerful and > flexible at the same time - a bit like what syslog-ng is to the old > syslog ;-) lol, the stack system is already a really big improvment. > > The specific reason I raised this issue is because on the main firewall > we have here, if I deploy ulogd2 and use NFCT at its present form, I > will get the logs from all 7 interfaces, and it would make it an > absolutely huge task to sift through all these logs and "match" the > various entries (OK, doing it through the database will help up a bit, > but not a lot). > > If I am able to place a "custom" filter with different "filter" values > in each separate stack, redirecting input to different places, then I > would be able to track down what I want quite easily. You should be able to do a per-network filtering with my current work. I should have a patch ready today. > > >> I had in mind exactly what you've suggested above - use a separate, > >> manually-registered table containing the table columns and their mapping > >> to ulogd2 parameters - much less risk and everything is configurable, > >> though the downside is that the two tables need to be synchronised if > >> the structure of the main ulogd table changes (columns renamed or added). > >> > > > > It seems the safest way. > > > It looks that way, doesn't it? In the coming days I'll look at the PGSQL > implementation code to see whether SSL connection to the database server > is a possibility with this plug in - it will be another good security > feature if that is possible to be implemented. Fine! BR, -- Eric Leblond Blog: http://home.regit.org/ - Portfolio: http://regit.500px.com/
Attachment:
signature.asc
Description: This is a digitally signed message part
