Hello, Le dimanche 15 juillet 2012 à 13:24 +0100, Mr Dash Four a écrit : > > For NFCT, you simply need to have nfnetlink_conntrack loaded. > > > I did, but I also made the mistake of including a few filters in that > stack, which were incompatible and that was the reason I did not get any > NFCT logs. Once that was corrected I started seeing connection tracking > logged. > > I have another question with regards to this: Is it possible to limit > (by a separate filter or otherwise) the reporting and restrict it, to > say, a specific set of interfaces or specific source/destination IP > addresses/subnets? > > 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. > > > 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/ > > > Very helpful, thanks! I don't see it as complicated at all, certainly no > more complicated than the existing accounting techniques. Yes, not that complicated, documentation was just lacking. > > >> 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 > > > Or look at the source code, which is what I did at the end. :) > > >> 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. > > > Yep, the pgsql plugin makes extensive use of pg_namespace, pg_class and > pg_attribute which are system tables. These contain definitions of every > single object registered on that database server and is a major security > risk (as I pointed out, if that ulogd connection to the database server > is hijacked, then the attacker could find out what is on that database > without any problems, which is not good). You're right. > 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. BR, -- Eric Leblond Blog: http://home.regit.org/ - Portfolio: http://regit.500px.com/
Attachment:
signature.asc
Description: This is a digitally signed message part
