ILLES, Marton wrote:

Hi,

I was wondering what kind of information do you need? I can imagine a tag that reflects whether the message was received through an encrypted transport. The certificate attributes/details could be stored as name/value pairs which you can refer from templates or use in filters. Using tags for certificate attributes seems bit more tricky as tags has only on/off states. What kind of information would you need from certificates?

I was planning to use a single tls listener with multiple parties (using a cert generated by my own CA!) sending messages and then relay or modify the messages based on an attribute in the certificate (i.e. "subject unique identifier" or an arbitrary X509v3 extension). I could also do filtering based on IP and/or hostname within the message but I think it would be more secure (as sender may modify their IP and hostname, but not the certificate) and faster to use tags. What do you mean with tags only having on/off? In the examples they do not look like booleans, i.e. the ".source." tag being dynamically built from the receive channel name!? Thanks, Christian

On Tue, 2011-02-08 at 15:49 +0000, Florian Pieper wrote:

Christian Tramnitz <chris.ace <at> gmx.net> writes:

...

ILLES, Marton wrote:

...

Hi,

I was wondering what kind of information do you need? I can imagine a tag that reflects whether the message was received through an encrypted transport. The certificate attributes/details could be stored as name/value pairs which you can refer from templates or use in filters. Using tags for certificate attributes seems bit more tricky as tags has only on/off states. What kind of information would you need from certificates?

I was planning to use a single tls listener with multiple parties (using a cert generated by my own CA!) sending messages and then relay or modify the messages based on an attribute in the certificate (i.e. "subject unique identifier" or an arbitrary X509v3 extension).

I could also do filtering based on IP and/or hostname within the message but I think it would be more secure (as sender may modify their IP and hostname, but not the certificate) and faster to use tags.

What do you mean with tags only having on/off? In the examples they do not look like booleans, i.e. the ".source." tag being dynamically built from the receive channel name!?

Hi folks,

I found the post and I'm planning to do the same kind of setup / filtering. Is there any process being made since then to filter on a certifiate's values? I'd really like to compare some values in the certificate and based on this re-route the message. I also read the newer article about syslog-ng string tagging (posted in August) but not sure whether this will be helpful for my needs?

Thanks for any hint,

Well, this is certainly doable, but copying the X.509 certificate properties into each and every message has a non-trivial cost, so I wouldn't want to do that for all users. However I'm pondering with the idea of introducing source/destination driver plugins, e.g. entities that can attach to an existing source/destination driver, which could be a place to add this functionality. However the framework doesn't not yet exist, and although I've tried to convince some of the staff inside BalaBit to implement it, I don't know how generic that will be. The idea is something like this: source s_tcp { tcp(ip('0.0.0.0') mytcpplugin(foo(bar))); }; Where mytcpplugin() would get a chance to modify each incoming message before passing it to the rest of syslog-ng. However it is still tricky how this will get the information in the first place, since being generic means that the plugin will be injectable in any of the source drivers, and currently there's no way to discover what the actual source driver in question is. With a custom patch it is certainly doable, you'd have to insert this code somewhere in afsocket_sc_queue(), which still has a reference to the connection where the message is being received and the message as it was fetched from the transport. -- Bazsi