Addressing Configuration Issues of SafeLine WAF

SafeLine is a self-hosted WAF(Web Application Firewall) to protect your web apps from attacks and exploits.

No Interception Records After Configuration and Attack Testing

Check if the access request has truly gone through SafeLine.

Website Inaccessibility After Configuration

If the site is configured according to the doc but the website is inaccessible:

First, search for the error code corresponding to the request when accessing the website, and troubleshoot based on the error code prompts.

Outline several possible causes:

1. Incorrect site configuration, such as incorrect IP, port conflicts, etc.
2. Network issues between SafeLine and the configured site.
3. Network issues when accessing the configured site’s port on SafeLine (firewalls, security groups, etc.).
4. Other incorrect configurations may prevent new configurations from taking effect. Check for existing configuration errors.ort conflicts, etc.
5. Abnormal status of SafeLine itself; use docker ps to check the container status.
6. The default reverse proxy configuration of SafeLine does not match the requirements of the origin site, necessitating manual adjustment of the reverse proxy configuration.

Note: Logs from the safeline-mgt and safeline-tengine containers can assist in troubleshooting.

Website Inaccessibility

1. Identify Specific Symptoms of “Website Inaccessibility”:

• If you receive a 502 Bad Gateway tengine error: It is likely due to incorrect upstream server configuration in SafeLine or SafeLine’s inability to reach the upstream server. Continue with the following steps.

• If the request is returned but is very slow:

Confirm if the server load is normal by checking CPU, memory, and bandwidth usage.

On the client, execute the following command to check the network between SafeLine and the upstream server:

curl -H "Host: <SafeLine IP>" -vv -o /dev/null -s -w 'time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n' http://<upstream server address>

If time_namelookup is too long, check the DNS server configuration.

If time_connect is too long, check the network status between SafeLine and the upstream server.

If time_starttransfer is too long, check the upstream server status for potential resource overload.

• If none of the above apply, proceed to the next step.

2. On the client, execute:

curl -v -H "Host: <domain or IP>" http://<SafeLine IP>:<SafeLine listening port>

If you receive a response from the business website, and the site’s “Today’s Visits” increases by 1, the SafeLine configuration is correct, and the network is normal.

If the browser cannot access the site, but this step returns a normal response, the likely reasons are:

• The website domain has not yet pointed to SafeLine, and browser testing accesses http(s)://<SafeLine IP>, where the business service has Host verification and rejects the request. Modify the local host file to resolve the domain to SafeLine IP and access http(s)://<domain> for accurate testing.
• The website has implemented special handling, such as a 301 redirect to another address. Specifically examine the website’s business response content.
• If no response is received, proceed to the next step.

3. On SafeLine device, execute:

curl -v -H "Host: <domain or IP>" http://<SafeLine IP>:<SafeLinelistening port>

If you receive a response from the business website, and the site’s “Today’s Visits” increases by 1, the SafeLine configuration is correct.

• If step 2 fails but this step succeeds, the issue lies in the network between the client and SafeLine. Troubleshoot the network, ensuring the client can access SafeLine and check firewalls and open ports.
• If no response is received, proceed to the next step.

4. On SafeLine device, execute:

curl -H "Host: <domain or IP>" http://127.0.0.1:<SafeLine listening port>

• If you receive a response from the business website, and the site’s “Today’s Visits” increases by 1, the SafeLine configuration is correct.
• If step 3 fails but this step succeeds, and telnet returns Unable to connect to remote host: Connection refused, the firewall on the SafeLine device may be blocking the connection.
• Inspect the operating system’s firewall and possibly the cloud provider’s firewall. Check each item based on actual conditions, allowing access to SafeLine’s listening port.
• If no response is received, proceed to the next step.

5. On SafeLine device, execute:

netstat -anp | grep <SafeLine listening port>

Confirm port listening status. Normally, an nginx process should be listening on 0.0.0.0:<SafeLine listening port>. If not, submit feedback through the community or a Github issue, including the troubleshooting process. If so, proceed to the next step.

6. Execute on SafeLine device:

curl -H "Host: <domain or IP>" <upstream server address>

If you receive a response from the business website, there is no network issue between SafeLine and the site.

• If step 4 fails but this step succeeds, it may be a configuration error. Check the site configuration tutorial to confirm if the configuration is correct. If unresolved, submit feedback through the community or a Github issue, including the troubleshooting process.
• If this step fails, the issue lies in the network between SafeLine and the upstream server. Troubleshoot the network, ensuring SafeLine can access the upstream server.

After Configuration, Testing Returns 400 Request Header Or Cookie Too Large

• Check for loops: SafeLine forwards the request to the upstream server, which then forwards the request back to SafeLine.

• Reconfigure and Test Again

After Configuration, WAF Returns 404

• Compare requests with and without WAF to identify changes in SafeLine’s reverse proxy forwarding content.
• If the server strictly verifies requests, manually adjust SafeLine’s nginx configuration. Refer to the custom nginx modification guide below.

Note: SafeLine interface operations may override and reset certain custom settings.

Site Configuration Errors

• Error message:

nginx: [emerg] duplicate listen options for 0.0.0.0:80 in /etc/nginx/sites-enabled/IF_backend_4:10
nginx: configuration file /etc/nginx/nginx.conf test failed
exit status 1

Indicates a conflict between the current configuration and the original configuration, such as the original site using port 80 to listen to all domains. Reconfiguring another site to use port 80 for all domains will cause this error. Specify the domain for the second port 80 configuration.

• Error message:

listen tcp :80: bind: address already in use

Indicates the configured port is occupied by another non-SafeLine program. For example, port 80 is occupied. Identify the program occupying port 80, switch to another port, and reconfigure the site.

Commands for Disabling Firewalls on Different Versions

By default, SafeLine does not require the firewall to be disabled; configuring the corresponding open rules is sufficient. However, if configuration is cumbersome, the firewall can be directly disabled.

• Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS Debian 9 (Stretch), Debian 10 (Buster), Debian 11 (Bullseye)

Disable firewall command (UFW):sudo ufw disable

Note: Debian may not have UFW installed by default and relies on iptables.

• CentOS 7, CentOS 8, RHEL 7, RHEL 8, Fedora 32, Fedora 33, Fedora 34

Disable firewall command (Firewalld):sudo systemctl stop firewalld && sudo systemctl disable firewalld

• openSUSE Leap 15.2, openSUSE Leap 15.3

Disable firewall command (usually SuSEfirewall2 or firewalld):

1. For SuSEfirewall2:sudo SuSEfirewall2 stop
2. For firewalld:sudo systemctl stop firewalld && sudo systemctl disable firewalld