No work is planned on that but it is a good idea.
Yeah, I thought as much.
If not, I think I have enough PostgreSQL experience and could alter that script to include such implementation, though I might need help with the NFLOG/ULOGD2 part as I am fairly new to this.
I'm here to help ;)
OK, for now I have some general queries with regards to ulogd2. When I
gain more knowledge (and experience) my queries will become more
specific. For now though I have to sort out the following:
In the manual there is a very good example on how to use NFLOG (as a
iptables target), but I have no idea how to apply and select NFACCT and
NFCT. How do I use this?
OK, I defined 2 stacks which use both NFCT and NFACCT, but how do I tell
iptables how to use them? I presume this is in a similar way to NFLOG
(with a target), but in that manual there are no examples (or even
hints) given on how to use that.
Also, there are quite a few plugins which I have just a vague idea what
they do (they are not documented in the manual - I presume because they
were recently introduced) - GPRINT springs to mind, NACCT is the other.
Is there a description on the purpose of these and their configuration
parameters, if any?
Probably my last 2 queries for now: when I define a stack, I use a
series of plugins to define a chain - from the source of where the
packet originates, to a cascade of "filters" and then the output plugin.
Does the order of "filter" plugins matters (in other words, are they
traversed from left-to-right in the order they are specified in the
"stack" statement in ulogd.conf) or is this order irrelevant?
And the second query: usually every plugin, when defined in a stack
statement has its own section when the various plugin parameters are
defined. Say, "emu1" has its own "[emu1]" section in ulogd.conf and
there I could define various parameters related to the LOGEMU plug in.
There are some plugins though, which do not have such section, which
follows me to conclude that either defining that section is not
mandatory (in which case I presume the plugin "assumes" default values)
or, the plugin in question does not have any values to be specified, so
no such section is needed. Am I correct in this assumption?
The idea I have is that the ulogd2 daemon should only be allowed INSERT permissions (nothing else) to the log tables, so that even if someone is able to hijack the ulogd2 connection to PostgreSQL somehow, they won't be able to see what has been logged, let alone alter it or delete it.
That's a sane setup.
I will dig much more deeper into this once I know how ulogd works as my
knowledge of ulogd2 is not that great (yet!). My initial instinct is
that I may have to alter this script slightly, because from what I
gather ulogd2 is "sensing" the structure of the logging table by reading
the "description" of it in PostgreSQL. That particular operation usually
requires higher-than-needed privileges and in order to avoid that I
might need to find other ways to impose the "insert-only" restriction,
which, lets be clear, is what ulogd needs. Again, I might be wrong with
this, but that is what my initial observations with the script and ulogd
suggest.
INL company is dead but I'm sure that Pierre is still reading this ML
from another mail ;)
Ah, that explains it! Well, if he reads this thread, I would love to get
some feedback when I am confident enough to start digging into that
script. ;-)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
