[squid-users] Client IP spoofing via squid proxy

[Ambadas Hibare]

HI,

Client IP: 172.16.5.110
Client Mac: 00:23:7D:E8:AC:C4

Squid Box:

eth0 IP: 172.16.5.102
eth0 Mac: 18:A9:05:3C:12:E4

eth1 IP: 10.0.0.102
eth1 Mac: 18:A9:05:3C:12:E6

> "Your "ip route" rules use eth1, but your rp_filter settings only change eth0. Also your iptables rules do not distinguish by ethN."

Yes. Should that setting be applied on both eths' or only the one facing the client?
Also want to know if it's possible to do tproxy setup with just one eth at squid box?

> "Your trace shows the MAC address *:c4 contacting Squid (MAC address *:e4) and delivering an HTTP request. Squid (*:e4) then contacts the remote server be sending > a TCP SYN packet ... which the MAC address *:c4 rejects."

In trace it shows squid (*:e4) (packet# 83) is contacting the web server (google.com) via client IP (172.16.5.110). So it's getting spoofed!? But not able to understand why client is sending RST to google (packet# 84) just after that & response

PS. The default gateway for client is squid box IP (eth1). 

Regards,
Ambadas


-----Original Message-----
From: Amos Jeffries [mailto:squid3 at treenet.co.nz] 
Sent: 07 May 2015 11:05
To: Ambadas Hibare; squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Client IP spoofing via squid proxy

On 7/05/2015 4:59 p.m., Ambadas Hibare wrote:
> Hi,
> 
> Thanks for replying.
> 
> I did a full transparent tproxy setup for squid proxy on linux(RHEL 6) machine as below:
> 
> Version: squid-3.5.1
> configure options:  '--enable-follow-x-forwarded-for' 
> '--enable-linux-netfilter' --enable-ltdl-convenience
> 
> squid.conf:
> http_port 3128
> http_port 3129 tproxy
> 
> Linux Kernel Configuration:
> NF_CONNTRACK=m
> NETFILTER_TPROXY=m
> NETFILTER_XT_MATCH_SOCKET=m
> NETFILTER_XT_TARGET_TPROXY=m
> 
> Routing configuration:
> ip -f inet rule add fwmark 1 lookup 100 ip -f inet route add local 
> default dev eth1 table 100 ip -f inet6 rule add fwmark 1 lookup 100 ip 
> -f inet6 route add local default dev eth1 table 100
> 
> echo 1 > /proc/sys/net/ipv4/ip_forward echo 0 > 
> /proc/sys/net/ipv4/conf/default/rp_filter
> echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
> echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
> 
> iptables Configuration:
> iptables -t mangle -N DIVERT
> iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle 
> -A DIVERT -j ACCEPT iptables  -t mangle -A PREROUTING -p tcp -m socket 
> -j DIVERT iptables  -t mangle -A PREROUTING -p tcp --dport 80 -j 
> TPROXY --tproxy-mark 0x1/0x1 --on-port 3129
> 
> The below machines are on local LAN setup Client IP: 172.16.5.110 
> Client's gateway: 10.0.0.102 DNS Server IP: 172.16.1.7 (same for both 
> client & squid machine) Web server IP: 216.58.196.110 (google.com)
> 
> Squid Machine has 2 eth interfaces,
> eth1 (facing client): 10.0.0.102
> eth0 (connecting to web): 172.16.5.102
> 

And MAC addresses please? TPROXY mixes up all the IPs.


> While browsing, the client is getting connection timeout. After analyzing the squid side traces, i found that client is doing DNS (for google.com) & connecting to that DNS IP on 80 port. Squid is able to intercept the request on 3129 port, doing DNS and trying to connect to google.com (using spoofed client IP) but is getting RST packet.
> Can you you please tell me what is missing here?

Your "ip route" rules use eth1, but your rp_filter settings only change
eth0. Also your iptables rules do not distinguish by ethN.

So its possible that rp_filter is still affecting traffic on eth1 trying
to be TPROXY'd.

Also its possible the eth0 traffic being TPROXY'd is not finding a
usable route table entry.

Your trace shows the MAC address *:c4 contacting Squid (MAC address
*:e4) and delivering an HTTP request. Squid (*:e4) then contacts the
remote server be sending a TCP SYN packet ... which the MAC address *:c4
rejects.


Some possibilities about what is actually going on:

1) Squid SYN packet gets to server. The server SYN ACK gets routed to
client, which rejects with RST. The RST gets routed to Squid.

2) Squid SYN packet hits rp_filter protection which RST. (If *:c4 is a
NIC on the Squid box).

3) Squid SYN packet sent out wrong ethN interface (towards client) and
the router that way rejects the SYN with RST, since it knows routing bak
to Squid is invalid.

Amos