jeastman wrote: ↑Fri Apr 21, 2023 1:22 pm
If you identify something missing or would like to include additional documentation, please feel free to open a pull request on the package git repository. I'd like to make sure we address anything which might help folks out. There are a number of places where documentation is missing or could be improved and it is not always obvious where those things are. Projects like the build system are pretty much automated on our end or so routine for our internal team that omissions often go unnoticed unless they are pointed out.
Hi John,
I am not sure what the correct documentation should be. If I had typed make then the default would have worked and the getsrc would have happened. My issue is I typed in literally what was documented and it failed. I assumed it was like so much other documentation I have attempted on building Zimbra and moved on immediately to a custom solution with no investigation. I won't do that again. I doubled back only when Ian and you chimed in. In any event, I have investigated this 3 different ways to see how easy it would be to add. I use a sed script here to make a small change to the spec file and/or Makefile so I don't have to install the complete RPM for options 2 and 3.
- use parts of spec file and a download of the nginx.tar with wget to build a dynamic ModSecurity 3 Connector module (my 1st method and easiest)
- update the zimbra spec file to build modsecurity 3 connector inside the Zimbra nginx tree and associated RPM + updates to the Makefile to install it.
- update the zimbra spec file to build a statically compiled modsecurity 3 connector and associated Zimbra nginx RPM
The biggest problem is that this mod security connector for nginx requires a modsecurity library so in addition to the ngx_http_modsecurity_module.so
is libmodsecurity.so.3 => /usr/local/modsecurity/lib/libmodsecurity.so.3 (0x00007f44d8468000) ... That is probably too much to expect from Zimbra and many admins that might want to try it.
Not to mention, replacing ones nginx with this RPM probably isn't desirable given the risks of introducing any change to a production environment. I am leaning toward a single bash script I use to build the environment to build, install, initialize it, patch nginx includes/template files and pull/update rules. One script handles all aspects with documentation how to turn it off/on.
Ideally, Zimbra would include modsecurity 3 connector in their installs but not enabled or included in the nginx conf files (option 2 above without the Makefile update). Just the connector and the library. Without that basic support, I am not sure there would be enough interest for a trusted vetted space for rules. Another benefit to selling it for future enhancement is it would/could give Zimbra and admins an additional tool laying dormant that could be used in the future for possible quick security bug fixes.
jeastman wrote: ↑Fri Apr 21, 2023 1:22 pm
I really like the idea of sharing rules and would like to discuss how we might support that. I would rather see something which is community driven, optional and pulled rather than pushed. We have too many folks using the product in "unique" situations where routinely pulling in updated rules would break things more often than fix things. There are two possibilities which immediately come to mind (completely open to other options as well):
1. Establish a section on the wiki for documenting such rules (less actionable but more descriptive)
2. Create a git repository where rules could be submitted via pull request (allows for pull request review and ensuring the contents of the repository are vetted). Could also include cron-type scripts people could utilize to automatically pull the scripts if desired.
I would lean towards the second option, but would appreciate any thoughts or feedback.
I like the second option given the trusted/vetted nature of rules but I also have a wiki entry that explains the process, build, and how to write rules given there is a lot to wrap ones head around on it's capability and how to go about it. Given the prevalent use of fail2ban I have seen in these forums and Zimbra certified wiki's, I am planning about a dozen rules to handle an attack in real-time and feed fail2ban or ipset's. That should also be the less intrusive with no FP's and should be at least on par for performance as using if statements in nginx conf files which was done for the memcache security bug. Another use is to document what is being done to the proxy as significant enhanced logging can be enabled especially for POST given we can view both directions of request and responses. Lastly, modified OWASP core rule sets could be enabled which has substantial protections against various current exploits and bots. I view this as a trust exercise where you start with the 1st or 2nd capabilities before you might enable the core rules or variation of the rules.
It's getting a little off topic so I'll wrap it up and report that it's fairly easy to build modSecurity 3 into zimbra given the current state of repositories found in github.
Ref:
https://codebots.com/application-securi ... s-of-owasp
Jim
