No Attacks Are Recorded During Testing, and Access Records Show 0
Ensure that the requests are not bypassing SafeLine and going directly to the origin server.
How to Record All Requests to SafeLine (Enabling Access Logs)
By default, SafeLine does not save request logs. To enable request logging, modify the nginx.conf
file located in the resources/nginx
directory of the SafeLine installation.
As shown in the image, uncomment line 98 and delete the content on line 99.
After saving the file, check the configuration by running:
docker exec safeline-tengine nginx -t
You should see:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Finally, apply the configuration by running:
docker exec safeline-tengine nginx -s reload
Note: This operation may increase disk usage, so regularly clean up the access logs.
MGT Certificate Error Preventing Startup
To resolve a certificate error, run the following command on the WAF machine:
docker exec safeline-mgt app/mgt-cli reset-cert
Clear Database Statistics and Detection Logs
To clear the logs, run:
docker exec safeline-mgt cleanlogs
Note: This operation will delete all log information and cannot be undone.
{.is-warning}
Export SafeLine Logs to XXX
To forward intercept logs to a target address via syslog, we’ll use fluentd
. Here’s how:
Create a
fluent.conf
file to configure data reading frommgt_detect_log_basic
and forwarding via syslog. Use the syslog section in the documentation as a reference.Create a Dockerfile for Fluentd:
FROM fluent/fluentd:v1.16-1
USER root
RUN apk add --no-cache --update --virtual .build-deps \
sudo build-base ruby-dev \
&& apk add libpq-dev \
&& sudo gem install pg --no-document \
&& sudo gem install fluent-plugin-remote_syslog \
&& sudo gem sources --clear-all \
&& apk del .build-deps libpq-dev \
&& rm -rf /tmp/* /var/tmp/* /usr/lib/ruby/gems/*/cache/*.gem
COPY fluent.conf /fluentd/etc/fluent.conf
USER fluent
- After building the Docker image, run the container:
echo "" > ./sql-state
docker run -d --restart=always --name safeline-fluentd --net safeline-ce -v ./sql-state:/var/run/fluentd/sql_state safeline-flunetd:latest
Refer to the documentation for more details.
Customizing Nginx Configuration for Sites
SafeLine regenerates the Nginx configuration files in resources/nginx/sites-enabled/
every time a site is modified or the service is restarted. To persistently add custom Nginx configurations, modify the proxy_params
file in resources/nginx/proxy_params
.
Example:
server {
location ^~ / {
proxy_pass http://backend_1;
include proxy_params;
include /etc/nginx/custom_params/backend_1;
# ...
}
}
To support X-Forwarded-Proto, add the following line to resources/nginx/proxy_params
:
proxy_set_header X-Forwarded-Proto $scheme;
Check the configuration:
docker exec safeline-tengine nginx -t
You should see:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Finally, reload the Nginx configuration:
docker exec safeline-tengine nginx -s reload
The Domain in the Attack Logs Is Not My Website
The domain field in attack logs is taken from the Host in the HTTP Header. If absent, the destination IP is used as the domain by default. If the client modifies the Host in the HTTP Header, the modified Host will be displayed.
Here’s a screenshot for reference:
Internal Network Requests from the Public Network in the Attack Logs
This can occur if:
- The attacker forged the Host field in the HTTP Header.
- The attacker used HTTP 1.0, which lacks the Host field. The WAF will then use the machine's internal IP to complete the request.
Check Container Logs and Troubleshoot Based on Error Logs
- Check container status:
docker ps
- View Tengine logs:
docker logs -f safeline-tengine
- View MGT logs:
docker logs -f safeline-mgt
How to Uninstall SafeLine
-
Navigate to the SafeLine installation directory (default:
/data/safeline
):
cd /data/safeline
-
Stop the Docker containers and network (do not directly delete the containers):
docker compose down
-
Remove SafeLine-related files:
rm -rf /data/safeline
Emergency Tengine Recovery
If editing site configurations results in errors and the Tengine backend keeps restarting after a restart or upgrade, you might need to reset the Tengine container configuration. Common causes include:
- The website port being occupied by another process.
- DNS configuration issues leading to unresolved IPs.
Solution:
- Check the Tengine container logs to diagnose the problem.
- Use the
reset_tengine.sh
script in the installation directory to reset the Tengine container configuration.
Does SafeLine Support WebSocket?
Yes, WebSocket is supported by default.
Problem Not Solved?
If your issue is still unresolved, you can:
Top comments (0)