A new version of OSSEC was released today. There is support for more logs and several bugs were fixed. Perhaps one of the most interesting changes is support for WordPress logging. WordPress, despite being one of the most popular blogging applications in the world, does not have logging by default! Can you believe that? Someone can be pounding away at your admin credentials all day and you might be none the wiser.
Daniel Cid saw this as a problem and took an old, unmaintained logging extension, fixed bugs (including some security bugs), and extended the logging functionality. Then he added support into OSSEC, of course. If you have a WordPress blog, it’s a worthwhile upgrade.
I also contributed some stuff. RoundCube support has been added, although amazingly, again, the logging sucks. By default it will log successful authentication but not failed. Huh? There’s a patch to make it do both. OSSEC can monitor those, which I’ ll post about a bit later. I also contributed Dovecot support, but that may not have made it into this one. If you need to analyze Dovecot logs, just get it from the OSSEC users mailing list.
All in all, this seems like a good release.
I was recently troubleshooting a problem with WordPress and wanted to post the solution here for others to search on. If you’re experiencing the following symptoms:
- Clicking “Status: Draft Edit” does nothing
- Clicking “Visibility: Public Edit” moves the page down
- Clicking “Publish immediately Edit” does nothing
- You can’t add tags from the “Add New Post” screen
…the reason may be the Apache LimitRequestFieldSize directive. There are a few other similar symptoms, but they mostly boil down to, “I clicked something and nothing happened.”
Most posts I encountered said something along the lines of, “clear your cache, disable all your plugins and try again.” For some people this works, but it didn’t work for me.
I discovered that the problem was directly related to the value of the LimitRequestFieldSize directive. The default value of 8190 is probably OK for almost all situations, although there is a slight risk leaving the value that high. The CIS Apache Benchmark recommends a value of 100, which in my experience is not usable for most applications. I tried a value of 500, which didn’t make much of a difference. Inching the value up bit-by-bit eventually hit that magic number that made everything start working.
Depending on your environment and the size of the headers your browser is sending, you may need to adjust this value up or down, but try to stay on the conservative side to protect yourself from buffer overflows.
One final note, this is a server-wide directive and cannot be placed in a virtual host container.