GUI editor to tame mod_security rules

⌈⌋ branch:  modseccfg


Update of "modseccfg"

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview

Artifact ID: eb76dbccb95cf28d82e69c96423765107dac077ebaacc4b8b26461200c1ba8e2
Page Name:modseccfg
Date: 2020-11-14 10:23:20
Original User: mario
Mimetype:text/x-markdown
Parent: f94af9edc6f01578294cdd3ee5a25bec183564ef28722f92de56e055ad6c4a52 (diff)
Next 51ab8eadc14cb925f49ec2fffba48d3dad9129f7dc293e82964383d8e0d7d052
Content

WARNING: THIS IS ALPHA STAGE QUALITY AND WILL MOST CERTAINLY DELETE YOUR APACHE CONFIGURATION - It doesn't, but: no waranty and such. - Also, hasn't many features yet.

modseccfg

  • Simple GUI editor for SecRuleDisableById settings
  • Tries to suggest false positives from error and audit logs
  • (And a few options to configure mod_security and CRS variables.)
  • Runs locally, via ssh -X forwarding, or per modseccfg vps5: automount.

Installation

  • You can install this package locally or on a server:

    pip3 install modseccfg

  • And your distro must provide a full Python 3.x installaton:

    sudo apt install python3-tk ttf-unifont libapache2-mod-security2

Start options

  • To run the GUI locally / on test setups:

    modseccfg python3 -m modseccfg

  • To start it on a server per X11 forwarding (terribly slow over SSH):

    ssh -X vps5 modseccfg

  • Alternatively use xpra:

    xpra --start ssh:vps5 --start=modseccfg

  • Best: use an automatic filesystem mount (with ssh shortcut/pubkey auth already configured). That's a bit slow on startup, but pays off when browsing for details.

    modseccfg vps5:/

WARNING: This will bind the remote / server root. Take care to configure the mount point (File → Settings → Utils → Remote binding), and no backup or cleanup job is running whilst modseccfg is active.
This doesn't strictly require the root user for ssh, but permissions for logs and individual *.conf files when changed (chown the ones that shall be editable). The sshfs/fuse mount will be terminated with the GUI, though.

Usage

You obviously should have Apache(2.x) + mod_security(2.9) + CRS(3.x) set up and running already (in DetectionOnly mode initially), to allow for log inspection and adapting rules.

  1. Start modseccfg (python3 -m modseccfg)
  2. Select a configuration/vhost file to inspect + work on.
  3. Pick the according error.log
  4. Inspect the rules with a high error count.
  5. [Disable] offending rules
    • Don't just go by the error count however!
    • Make sure you don't disable essential or heuristic rules.
    • Compare error with access log details.
    • Else craft an exception rule ([Modify] or →Recipes).
  6. Thenceforth restart Apache after testing changes (apache2ctl -t).

Notes

  • Preferrably do not edit default /etc/apache* files
  • Work on separated /srv/web/conf.d/* configuration, if available
  • And keep vhost settings in e.g. vhost.*.dir files, rather than multiple <VirtualHost> in one *.conf (else only the first section will be augmented).

Missing features

  • Doesn't process any audit.log yet.
  • Can't classify wrapped (<Location> or other directives) rules yet.
  • No rule information dialog.
  • No SecOption editor yet.
  • No CRS settings (setvar:crs…) editor yet.
  • Recipes are not worth using yet.
  • No sudo usage.
  • No support for nginx or mod_sec v3.
  • No support for Windows setups. (Would work, but no interest in user support.)