Skip to content

Investigate a mechanism for centralized/shared persistent storage #378

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rcbarnett-zz opened this issue Oct 17, 2013 · 7 comments
Closed

Comments

@rcbarnett-zz
Copy link
Contributor

MODSEC-224: For distributed environments, we need to extend the persistent storage mechanism to allow for centralized logging. This would allow individual ModSec installs to access a central storage location for initcol, setsid, setuid actions. One option may be to look at memcached.

Possible directives would be:

SecPersistentStorage Local|Centralized

  • Local would be the way it is currently with local SDBM files
  • Centralized would use something like a memcached server(s)

SecCentralizedStorageHost hostname|ip

  • would define where the memcached server is, etc...
@ghost ghost assigned zimmerle Oct 17, 2013
@rcbarnett-zz
Copy link
Contributor Author

Original reporter: rbarnett

@rcbarnett-zz
Copy link
Contributor Author

[email protected]: I have seen that in the beta release of http 2.3 there is now also a memcache implementation for the SSL Sessioncache (modules/cache/mod_socache_memcache.c). Maybe some part of the Code can be reused?

@rcbarnett-zz
Copy link
Contributor Author

[email protected]: I tested kyoto tycoon which can be used as an alternative for memcached and has also a replication feature built in, memcached protocol is supported.
http://dailyadminlife.blogspot.com/2011/07/kyoto-tycoon-memcached-alternative-with.html

@rcbarnett-zz
Copy link
Contributor Author

rbarnett: there is an Apache module that implements this -
https://code.google.com/p/modmemcachecache/

We could re-use some data.

@zimmerle
Copy link
Contributor

This functionality is under test under the branch:

https://github.com/SpiderLabs/ModSecurity/tree/memcache_collections

This test implementation is using memcache to store the collections values. The memcache server can be informed by the utilization of the following configuration option:

SecPersistentStorage memcache "--SERVER=your.server.ip.addrs."

If SecPersistentStorage was not informed or if is set to "local" the collection will be stored on the sdbm files.

@matthewlenz
Copy link

Anyone know the current status of this feature? This type of feature would be awesome for people who want to use multiple embedded solutions. Apache 2.4 (as people have mentioned) supports this type of functionality for SSL cache and 2.4 is now in Debian stable (8.0).

@zimmerle zimmerle added this to the v3.0.0 milestone Mar 24, 2016
@zimmerlezen zimmerlezen modified the milestones: v3.0.0 owasp compatible, v3.0.0 feature complete Mar 28, 2016
@zimmerle
Copy link
Contributor

zimmerle commented May 5, 2016

This feature is being implemented as part of version 3 (aka libmodsecurity). In version 3, the collections were implemented over a interface that allow us to extend ModSecurity with different collections backends.

The interface is available here:
https://github.com/SpiderLabs/ModSecurity/blob/libmodsecurity/headers/modsecurity/collection/collection.h

Tickets were opened to track the implementation of the initial backends, they are: #1139, #1140, #1141

@zimmerle zimmerle closed this as completed May 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants