[syslog-ng] filter/parse based on certificate attributes?

[Balazs Scheidler]

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