Hello, Le samedi 14 juillet 2012 à 14:00 +0100, Mr Dash Four a écrit : > > 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? For NFCT, you simply need to have nfnetlink_conntrack loaded. Things are more complicated for NFACCT and I've just wrote a page dedicated to this point: https://home.regit.org/2012/07/flow-accounting-with-netfilter-and-ulogd2/ > > 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. GPRINT is a one line per item textual log. NACCT is an tab separated output format dedicated to NFACCT data and that can be used to import data in other tools (Astaro does so). > Is there a description on the purpose of these and their configuration > parameters, if any? To now which keys are used and whch config var are available, you can use the -i option of ulogd: ulogd -i libexec/ulogd/ulogd_filter_MARK.so Name: MARK Config options: Var: mark (Integer, Default: 0) Var: mask (Integer, Default: -1) Input keys: Key: ct.mark (unsigned int 32, optional) Key: oob.mark (unsigned int 32, optional) Output keys: No statically defined keys > 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? This is read from end to start. All that matter is that for a plugin the needed keys are exported by another plugin on the left. > 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? Yes, there is default value. But for at least INPUT plugins, you need to specify a section. I really don't remember why but this is the case. > > >> 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. Yes, there's a discovery system that may require some tuning. But it can be made on a separate table use for the only purpose of describing the variables. > > 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. ;-) > BR, -- Eric Leblond Blog: http://home.regit.org/ - Portfolio: http://regit.500px.com/
Attachment:
signature.asc
Description: This is a digitally signed message part
