Though we are constantly working on optimizing all Nemesida WAF components, there is a possibility of an emergency situation. Similar situations include:
- Emergency shutdown of the filtering node;
- Slowing down the access the web applications due to increased consumption of hardware resources of the filtering node server;
- Inability of clients to access the web application due to an increase in the count of legitimate request blocks.
Let’s look at each of these scenarios.
🔗 Emergency shutdown of the filtering node
During Nginx operation, errors may occur, leading to an emergency interruption of the execution of requests, as a result of which Nemesida WAF cannot process the request correctly. To track and correct errors in the code, the process memory image recording analysis (
core dump) is used.
If such a situation occurs, you must perform the following actions:
- Activate monitoring of Nginx process crashes when working with Nemesida WAF;
- Send the received information to the technical support for its analysis and troubleshooting.
In the case of a critical situation when failures in the operation of the filtering node interfere with the operation of the final web applications, it is allowed to exclude the processing of requests by the filtering node for the time of troubleshooting.
🔗 Slowing down the access the web applications due to increased consumption of hardware resources of the filtering node server
During its operation, the filtering node processes a large number of requests and analysis them with signature analysis and a machine learning module. These operations require a certain amount of server hardware resources. If there is a shortage of hardware resources, access to protected web applications may slow down due to overload in the work of the filtering node processing and proxying traffic. If such a situation occurs, you must perform the following actions:
- Study recommended hardware requirements for server with corresponding component and, if possible, add the required amount of resources in accordance with the requirements;
- Send the Nginx web server log to the technical support for analysis and troubleshooting (if the developers confirm the presence of a malfunction leading to increased consumption of server hardware resources) or receive recommendations to reduce the consumption of hardware resources.
In some cases, slower access to the final web application may occur if the filtering node processes requests that transmit large content in the request body (for example, when downloading files). Processing such requests requires a certain amount of hardware resources and time, which can slow down the work of both the filtering node and all web applications whose traffic is proxied through it. If the functionality of the web application supports file transfer, then as a possible solution to the problem, you need to apply parameters in Nemesida WAF Cabinet that exclude checking the contents of the request body.
In some cases, the filtering node may also consume an increased amount of hardware resources (in particular, server RAM) due to processing a large number of requests that are transmitted for additional analysis by the machine learning module. This is due to the fact that the signature analysis of the request additionally performs
Base64-decoding of the zones
HEADERS, after which detects signs of an attack (signatures), and the request is passed to the Nemesida AI MLA module. In most cases, to solve the problem, it will be enough to activate the option to disable decoding of the corresponding zone in Nemesida WAF Cabinet.
🔗 Inability of clients to access the web application due to an increase in the number of legitimate request blocks
When analyzing requests, the filtering node performs several stages of checks, which include analysis of queries by the signature method and analysis by machine learning. With an increase in the number of legitimate request blocks, it is necessary to find out the reason for this behavior on the part of the Nemesida WAF.
If such a situation occurs, it is recommended to perform the following actions:
- Switch Nemesida WAF to request processing in monitoring mode (the request is not blocked, but the corresponding events are recorded in the Nemesida WAF logs);
- Send the Nginx web server log to the technical support for analysis and troubleshooting (if the developers confirm the presence of a malfunction leading to false positives) or receive recommendations to reduce their number.
🔗 Disabling Nemesida WAF
In the event of a critical situation in which it is impossible to continue using the Nemesida WAF without compromising the performance of protected web applications (for example, when long waits for a response from a web application are unacceptable or the filtering node, proxying traffic, does not allow for constant availability of the web application for clients), it is allowed to disable the filtering node until the reasons for such behavior are clarified on the part of Nemesida WAF.
If it is necessary to disable the Nemesida WAF, it is recommended to perform the following actions:
- Generate the parameters
- Configure an additional server that will work in traffic mirroring to have up-to-date information about attacks on the protected web application, but not affect their performance;
- Submit to the service technical support Nginx web server log for analysis and troubleshooting (if the developers confirm its presence) or receiving recommendations for further actions.