基于net.SplitHostPort(r.RemoteAddr)的IP过滤是否可被绕过？

我用IP过滤做服务器安全防护，想确认基于net.SplitHostPort(r.RemoteAddr)的远程IP过滤机制是否存在被绕过的可能，为此写了一个测试用HTTP服务器：

package main

import (
    "fmt"
    "net"
    "net/http"
)

func getHello(w http.ResponseWriter, r *http.Request) {
    fmt.Printf("got /hello request\n")
    host, _, _ := net.SplitHostPort(r.RemoteAddr)
    fmt.Printf("Ip is %s\n", host)
}

func main() {
    http.HandleFunc("/hello", getHello)

    http.ListenAndServe(":3333", nil)
}

随后用curl做了测试：

curl http://localhost:3333/hello 
# 服务器日志输出 -> Ip is 127.0.0.1

curl http://localhost:3333/hello -H "X-Forwarded-For: 3.3.3.3" -H "Host: 3.3.3.3"
# 服务器日志输出 -> Ip is 127.0.0.1

测试显示无法让服务器误判请求IP为3.3.3.3，但我还有疑问：r.RemoteAddr是否确实从TCP数据包中读取IP？是否存在通过请求头或伪造数据包绕过的可能？

解答 #

1. r.RemoteAddr的来源
   r.RemoteAddr的值确实来自TCP连接建立阶段的底层数据包，是传输层确认的远端IP和端口，和HTTP请求头属于完全不同的层级。所以修改任何HTTP请求头（比如X-Forwarded-For、Host）都无法篡改这个值，这也是你测试中结果始终不变的原因。

2. 是否存在绕过可能

• 无中间代理的直连场景：这种情况下攻击者几乎无法绕过。虽然存在IP欺骗技术，但TCP是面向连接的协议，伪造源IP后攻击者无法收到服务器的响应，无法完成完整的HTTP请求流程；同时IP欺骗还需要攻击者控制目标网络的路由或处于同一网段，实际操作难度极大。
• 有反向代理/负载均衡的场景：此时r.RemoteAddr获取到的是代理服务器的IP，而非真实客户端IP。如果仍只用这个值做过滤，会导致过滤逻辑失效（所有请求都被判定为来自代理IP）。另外如果代理配置不当，攻击者可能通过伪造X-Forwarded-For等请求头来误导服务器获取的真实IP，但这并非绕过r.RemoteAddr的过滤，而是你选错了获取客户端真实IP的方式。

内容的提问来源于stack exchange，提问作者RudeusGreyrat