Guide: Recommended Work Sequence
Wizards, baseline protection, and the powerful inheritance mechanisms in vWAF can save you a lot of time in setting up and maintaining your security configuration. However, this requires careful planning of the individual work steps.
Basic principles
- First use Wizards, then fine-tune manually In general, it’s advisable at the start to carry out a basic configuration first using the Wizards. You then already have a basic configuration of handlers, and the most important attributes in the handlers are already preconfigured. In the next step, you can then refine the default settings manually.
- Make every change on the highest possible level To use the integrated inheritance mechanisms optimally, you should always make changes to the configuration on the level of the application. Bear in mind that when you overwrite an attribute on the path level, the inheritance mechanism for that attribute remains permanently broken. The more points are affected by individual variations, the more points you will need to maintain individually later on.
Based on the basic principles given above, this results in the following work steps.
Work steps
| Activity | For description, see |
|---|---|---|
1. | Create an application and set up application mapping for this application. This step can only be carried out by an administrator from the zeusafm Administrator user group or by an administrator who has the appropriate read/write permissions. ATTENTION For security reasons, we recommend disabling the option allow traffic for unknown hosts in Global Configuration after you’ve assigned all of your hosts in Application Mapping. | |
2. | Run wizards to create a basic configuration. Use the Baseline Protection Wizard to achieve initial protection with minimum effort. | |
3. | Optional: Add paths. Optional: Add preconditions. | |
4. | Optional: Add and edit handlers. | |
5. | Commit and activate the ruleset. Enable traffic if required. | |
6. | After you’ve added and edited a new application, usually detection mode is enabled for this application by default. (See Detection Mode, Protection Mode). You can now test the ruleset before using it in protection mode. This eliminates the risk that the access to your running web application is affected by a faulty, or by a too restrictive ruleset (false positives). By analyzing the Log Files, you can see which handler causes certain requests to be denied. Only when your ruleset fully works as intended, should you enable protection mode (see Editing Applications) and make the ruleset the protection ruleset (see Version Control). | |
7. | The arguments of input form fields are a frequently used attack vector. To add particularly strong protection for your most critical pages, such as login pages, manually add whitelisting for these pages with the help of the Whitelist Handler. | |
8. | In addition to the security configuration created in the steps above, you can optionally configure alerts, which inform you in case of particular events but don’t trigger any automatic action (see Configuring Alerts). | |
For further information regarding the underlying principles and how vWAF is structured and controlled, see Basic Principals of Use.
Step-by-step refinement
Even experts are barely able to predict all conceivable attack scenarios to a web application. If you were to attempt to exclude these risks step by step, it’s almost certain that significant weak spots would remain.
It’s therefore strongly advisable to take the opposite approach: Don’t prohibit specific actions, but instead permit specific actions. The basic principle for working with vWAF should always be: Everything that’s not explicitly permitted, is forbidden. This results in the following procedure, which ensures a high degree of security:
- Create a list of everything that’s explicitly permitted.
- Configure vWAF using the wizards and handlers provided so that only the things specified on your list in step 1 are possible. Carry out this work using paths so that specific actions are only permitted where absolutely necessary.
- Test your web application and expand the scope of the permitted actions as required so that all functions of your web application work as intended. Always keep all the rules as tight as possible.
- Check the log files in vWAF at regular intervals to ensure that no requests were denied where this wasn’t necessary (see Log Files). Expand your list from step 1 as required.
vWAF provides a powerful function that tells you why a certain handler became active and how you can modify your configuration to avoid this in the future. See Log Files for details.
Repeat steps 2 to 4 until your web application functions correctly works for all legitimate users in all possible scenarios. Then switch from detection mode to protection mode (see Version Control and Editing Applications).