Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[建议] 支持接收PROXY Protocol,方便的获取真实IP #359

Open
cddqssc opened this issue Oct 7, 2023 · 13 comments
Open

[建议] 支持接收PROXY Protocol,方便的获取真实IP #359

cddqssc opened this issue Oct 7, 2023 · 13 comments
Labels
enhancement New feature or request

Comments

@cddqssc
Copy link

cddqssc commented Oct 7, 2023

背景与遇到的问题

当waf的上游是端口转发(例如frp)或者负载均衡器的时候,waf无法获取真实IP,NGINX的PROXY Protocol就是解决这个问题的:https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/

建议的解决方案

实际上很简单:根据nginx文档只需要添加proxy_protocol字段到监听的端口后面,就能获取真实IP了
server {
listen 80 proxy_protocol;
listen 443 ssl proxy_protocol
#...
}
目前手动修改配置文件服务重启会被覆盖,也无法在custom的config添加这个字段
建议:能不能UI加一个选项,然后就能在配置文件中加上这个proxy_protocol

@cddqssc cddqssc changed the title [建议] 支持接收PROXY Protocol [建议] 支持接收PROXY Protocol,方便的获取真实IP Oct 7, 2023
@cddqssc
Copy link
Author

cddqssc commented Oct 7, 2023

目前waf可以从http header中获取真实IP(X-Real-IP),但是这样不太优雅,因为如果上游没有传递X-Real-IP(例如端口转发),就获取不到真实IP。而如果使用proxy_protocol,waf就能直接从网络连接中获取真实IP

@zclaiqcc zclaiqcc added the enhancement New feature or request label Oct 8, 2023
@Lorna0
Copy link
Collaborator

Lorna0 commented Oct 11, 2023

通过 Header 传递真实 IP 是 HTTP 下的标准解决方案,七层负载一般都支持,咋会不优雅。

proxy protocol 只在纯四层负载的情况下有意义,而且也不是很常用的方案(大多直接从网络层转发,不需要处理 IP。网络环境不支持的话也直接上七层负载),处理 SMTP、POP3、IMAP 这些协议的时候可能会用到,对代理 HTTP 的 WAF 来说使用场景似乎比较有限呀。

@cddqssc
Copy link
Author

cddqssc commented Oct 11, 2023

通过 Header 传递真实 IP 是 HTTP 下的标准解决方案,七层负载一般都支持,咋会不优雅。

proxy protocol 只在纯四层负载的情况下有意义,而且也不是很常用的方案(大多直接从网络层转发,不需要处理 IP。网络环境不支持的话也直接上七层负载),处理 SMTP、POP3、IMAP 这些协议的时候可能会用到,对代理 HTTP 的 WAF 来说使用场景似乎比较有限呀。

举个例子:
用户通过HTTPS访问服务器,服务器把HTTPS流量通过端口转发(或者负载均衡器)给WAF,如下图
image

这个时候,Header里面没有真实IP,WAF获取不到真实IP。想要在header里面添加XFF,就要在转发那一层解密后添加XFF后再传递给WAF,这样全程就不是HTTPS了,就造成了不安全因素,而且麻烦。 我希望到waf之前的流量全程都是HTTPS,然后WAF来解密处理,而且waf仅仅是添加一个proxy protocol就能获取真实IP,既安全又方便。

这种场景可能并不常见,但是也不能说很稀有吧,端口转发/负载均衡应该也是比较常见的吧?waf文档里面是支持这样的接入方式的,并且添加这个功能比较容易。

@0x7k
Copy link

0x7k commented Oct 16, 2023

+1

@ac-sc
Copy link

ac-sc commented Oct 29, 2023

通过 Header 传递真实 IP 是 HTTP 下的标准解决方案,七层负载一般都支持,咋会不优雅。
proxy protocol 只在纯四层负载的情况下有意义,而且也不是很常用的方案(大多直接从网络层转发,不需要处理 IP。网络环境不支持的话也直接上七层负载),处理 SMTP、POP3、IMAP 这些协议的时候可能会用到,对代理 HTTP 的 WAF 来说使用场景似乎比较有限呀。

举个例子: 用户通过HTTPS访问服务器,服务器把HTTPS流量通过端口转发(或者负载均衡器)给WAF,如下图 image

这个时候,Header里面没有真实IP,WAF获取不到真实IP。想要在header里面添加XFF,就要在转发那一层解密后添加XFF后再传递给WAF,这样全程就不是HTTPS了,就造成了不安全因素,而且麻烦。 我希望到waf之前的流量全程都是HTTPS,然后WAF来解密处理,而且waf仅仅是添加一个proxy protocol就能获取真实IP,既安全又方便。

这种场景可能并不常见,但是也不能说很稀有吧,端口转发/负载均衡应该也是比较常见的吧?waf文档里面是支持这样的接入方式的,并且添加这个功能比较容易。

如果是图上的这种方式,就算waf支持pp协议,从转口转发过来的数据如果做了源地址转换,waf是不是也无法获取到客户端的真实ip地址?

@Trenck
Copy link

Trenck commented Oct 31, 2023

在header里面添加XFF,再以https转给waf,这中间还是可以是加密的

@cddqssc
Copy link
Author

cddqssc commented Oct 31, 2023

在header里面添加XFF,再以https转给waf,这中间还是可以是加密的

你是认真的吗?

@Lorna0
Copy link
Collaborator

Lorna0 commented Nov 6, 2023

在header里面添加XFF,再以https转给waf,这中间还是可以是加密的

你是认真的吗?

一般正式网站确实是这样部的,最外层的设备放证书,源 IP 信息用 XFF 或 X-Real-IP 来传递。中间需要全程加密的话,就都走 HTTPS。例如证书放 CDN 上,CDN 给源站生成一个自己信任的自签证书,然后用 https 连源站,这样全程都是 HTTPS。

对于负载均衡来说,web 流量的目的端口都是 80,站点信息是放在 host 里,解了密才知道是哪个站。有时候还需要根据URL、UA 等进行负载,这些都需要解密。如果没有这些需求,想只通过目的端口进行转发,那也可以直接四层路由来转发和负载,比七层代理的方案性能还高些,所以一般正式网站的负载均衡都会解密。Proxy protocol 主要是用来代理 SMTP、POP3、IMAP 这些 TCP 协议,代理网站的情况比较少见。

我盲猜你的情况是个人自建了很多 TCP 服务,包括一个 http 服务,然后想要统一通过负载代理出去?这种情况企业级 waf 确实几乎没有,可能是社区版特有需求吧,看看大家反馈。

@cddqssc
Copy link
Author

cddqssc commented Nov 6, 2023

在header里面添加XFF,再以https转给waf,这中间还是可以是加密的

你是认真的吗?

一般正式网站确实是这样部的,最外层的设备放证书,源 IP 信息用 XFF 或 X-Real-IP 来传递。中间需要全程加密的话,就都走 HTTPS。例如证书放 CDN 上,CDN 给源站生成一个自己信任的自签证书,然后用 https 连源站,这样全程都是 HTTPS。

对于负载均衡来说,web 流量的目的端口都是 80,站点信息是放在 host 里,解了密才知道是哪个站。有时候还需要根据URL、UA 等进行负载,这些都需要解密。如果没有这些需求,想只通过目的端口进行转发,那也可以直接四层路由来转发和负载,比七层代理的方案性能还高些,所以一般正式网站的负载均衡都会解密。Proxy protocol 主要是用来代理 SMTP、POP3、IMAP 这些 TCP 协议,代理网站的情况比较少见。

我盲猜你的情况是个人自建了很多 TCP 服务,包括一个 http 服务,然后想要统一通过负载代理出去?这种情况企业级 waf 确实几乎没有,可能是社区版特有需求吧,看看大家反馈。

感谢答复,这个问题对我个人来说已经解决,之前不太清楚如何手动编辑conf文件,修改后老是自动被覆盖。
现在已经手动修改了,并且可以正常运行了,需要此功能的可以参考如何修改conf文件:https://waf-ce.chaitin.cn/docs/faq/other

@guorenxi
Copy link

guorenxi commented Dec 4, 2023

在header里面添加XFF,再以https转给waf,这中间还是可以是加密的

你是认真的吗?

一般正式网站确实是这样部的,最外层的设备放证书,源 IP 信息用 XFF 或 X-Real-IP 来传递。中间需要全程加密的话,就都走 HTTPS。例如证书放 CDN 上,CDN 给源站生成一个自己信任的自签证书,然后用 https 连源站,这样全程都是 HTTPS。
对于负载均衡来说,web 流量的目的端口都是 80,站点信息是放在 host 里,解了密才知道是哪个站。有时候还需要根据URL、UA 等进行负载,这些都需要解密。如果没有这些需求,想只通过目的端口进行转发,那也可以直接四层路由来转发和负载,比七层代理的方案性能还高些,所以一般正式网站的负载均衡都会解密。Proxy protocol 主要是用来代理 SMTP、POP3、IMAP 这些 TCP 协议,代理网站的情况比较少见。
我盲猜你的情况是个人自建了很多 TCP 服务,包括一个 http 服务,然后想要统一通过负载代理出去?这种情况企业级 waf 确实几乎没有,可能是社区版特有需求吧,看看大家反馈。

感谢答复,这个问题对我个人来说已经解决,之前不太清楚如何手动编辑conf文件,修改后老是自动被覆盖。 现在已经手动修改了,并且可以正常运行了,需要此功能的可以参考如何修改conf文件:https://waf-ce.chaitin.cn/docs/faq/other

谢谢,我也正在找这个解决方法。

@gospider007
Copy link

在header里面添加XFF,再以https转给waf,这中间还是可以是加密的

你是认真的吗

@wuyue92tree
Copy link

在header里面添加XFF,再以https转给waf,这中间还是可以是加密的

你是认真的吗?

一般正式网站确实是这样部的,最外层的设备放证书,源 IP 信息用 XFF 或 X-Real-IP 来传递。中间需要全程加密的话,就都走 HTTPS。例如证书放 CDN 上,CDN 给源站生成一个自己信任的自签证书,然后用 https 连源站,这样全程都是 HTTPS。
对于负载均衡来说,web 流量的目的端口都是 80,站点信息是放在 host 里,解了密才知道是哪个站。有时候还需要根据URL、UA 等进行负载,这些都需要解密。如果没有这些需求,想只通过目的端口进行转发,那也可以直接四层路由来转发和负载,比七层代理的方案性能还高些,所以一般正式网站的负载均衡都会解密。Proxy protocol 主要是用来代理 SMTP、POP3、IMAP 这些 TCP 协议,代理网站的情况比较少见。
我盲猜你的情况是个人自建了很多 TCP 服务,包括一个 http 服务,然后想要统一通过负载代理出去?这种情况企业级 waf 确实几乎没有,可能是社区版特有需求吧,看看大家反馈。

感谢答复,这个问题对我个人来说已经解决,之前不太清楚如何手动编辑conf文件,修改后老是自动被覆盖。 现在已经手动修改了,并且可以正常运行了,需要此功能的可以参考如何修改conf文件:https://waf-ce.chaitin.cn/docs/faq/other

proxy protocol 好像只能在server中修改listen设置,location下怎么处理呢,能给个配置参考一下吗,谢谢~

@1447262390
Copy link

目前我也碰到这个问题,希望能找到支持接收PROXY Protocol获取真实ip。希望后续能得到支持

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

10 participants