How to Configure SafeLine WAF to Correctly Obtain the Source IP

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

We often get feedback from users that the IP shown in the SafeLine attack logs is problematic.

Here, I will explain why there might be issues with the attack IP displayed in SafeLine in some situations.

Problem Description

By default, SafeLine reads the client IP through the Socket of the HTTP connection. When SafeLine is the outermost network device, there is no problem, and the IP obtained by SafeLine is the real IP of the attacker.

However, in some cases, we need to add other proxy devices (such as Nginx, CDN, application delivery, API gateway, etc.) in front of SafeLine. In this case, the actual connection to SafeLine is not the real website user but these proxy devices. In this case, we need to adjust the way SafeLine obtains the IP according to the actual network topology.

Understanding X-Forwarded-For

X-Forwarded-For is a relatively common HTTP request header.

When HTTP traffic passes through a proxy, the network connection is intercepted, and the server cannot know the real client IP. At this time, the proxy device will add an X-Forwarded-For header to the current traffic, and the content is the client IP that connects to this proxy.

In the following example, the HTTP proxy tells the server through the X-Forwarded-For header that the real client address is 1.2.3.4.

GET / HTTP/1.1
Host: demo.waf.chaitin.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.106 Safari/537.36
X-Forwarded-For: 1.2.3.4

X-Forwarded-For is actually a chain structure. If the traffic passes through multiple proxy devices, X-Forwarded-For will record all the IPs passed.

In the following example, the HTTP proxy tells the server through the X-Forwarded-For header that the traffic has passed through three layers of proxies, and the real client address is 1.2.3.4, the first layer of proxy is 11.12.13.14, the second layer of proxy address is 21.22.23.24, and the third layer of proxy address can be obtained directly through the Socket connection.

GET / HTTP/1.1
Host: demo.waf.chaitin.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.106 Safari/537.36
X-Forwarded-For: 1.2.3.4, 11.12.13.14, 21.22.23.24

Is the X-Forwarded-For Header Reliable?

The content transmitted by the X-Forwarded-For header is very reliable when the proxy device and proxy chain are trustworthy, and it can be used with confidence.

However, if the proxy device is untrustworthy, then attackers can forge the source IP by forging the X-Forwarded-For header.

SafeLine Configuration

SafeLine has an option in the global configuration that is specifically designed to solve this problem.

SafeLine provides several options in this configuration. Based on the knowledge mentioned above, everyone can choose the most suitable option according to the actual situation.

• Obtain from the network connection: Choose when SafeLine is the outermost proxy device and there are no other forward proxies.
• Obtain the address of the previous proxy from X-Forwarded-For: Choose when there is one layer of proxy device (such as Nginx, CDN, etc.) before the traffic reaches SafeLine.
• Obtain the address of the second-level proxy from X-Forwarded-For: Choose when there are two layers of proxy devices (such as Nginx, CDN, etc.) before the traffic reaches SafeLine.
• Obtain the address of the third-level proxy from X-Forwarded-For: Choose when there are three layers of proxy devices (such as Nginx, CDN, etc.) before the traffic reaches SafeLine.

• Obtain from other HTTP Headers: There are several situations

  • The traffic passes through some special reverse proxy devices that do not send X-Forwarded-For headers, but you can configure the IP to be sent through other headers.
  • The traffic reaches SafeLine through multiple paths, which may have one layer of proxy or two layers of proxy. You can configure the front proxy device to unify the HTTP header.