Re: pgsql-ulogd2

[Mr Dash Four <mr.dash.four@googlemail.com>]

>> 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. 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 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 ;-)

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.

>> 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.