[squid-users] Squid and iptables

Fri Feb 14 08:21:32 UTC 2020

On 11/02/20 4:48 am, L.P.H. van Belle wrote:
> Hai, 
>  
> I'm having a squid 4.10 on Debian 10 running ( with strongswan VPN ) and ufw firewall (iptables) 
> Most is running fine but i still see some error and i somehow miss here what im doing wrong. 
> 

You may not be doing anything.

INVALID from Conntrack means the packet is either corrupted at the
binary level, or not supposed to exist, maybe both if the corruption
makes something that looks like a valid but wrong packet.

> So if someone has suggestions that would be great. I see for example these lines in the UFW log. 
> 
> Feb 10 15:42:21 rtd-proxy1 kernel: [14315.762249] [UFW AUDIT INVALID] IN=eth0 OUT= MAC=56:30:b7:fd:da:24:84:2b:2b:90:a5:f1:08:00 SRC=192.168.0.101 DST=192.168.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=22171 DF PROTO=TCP SPT=52273 DPT=8080 WINDOW=0 RES=0x00 ACK RST URGP=0
> Feb 10 15:42:21 rtd-proxy1 kernel: [14315.762308] [UFW BLOCK] IN=eth0 OUT= MAC=56:30:b7:fd:da:24:84:2b:2b:90:a5:f1:08:00 SRC=192.168.0.101 DST=192.168.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=22171 DF PROTO=TCP SPT=52273 DPT=8080 WINDOW=0 RES=0x00 ACK RST URGP=0
> 
> Now, strange thing here is im allowing my traffic on my lan interface fully, so i dont see/get why i get these INVALID/BLOCK.
> Im out of ideas, i looked to much at it, i done see it anymore..  :-( 
> 
> The needed parts of my squid and iptables (ufw) setup. 
> ETH0 = LAN  192.168.0.1.0/24 	(ip: 192.168.0.1.1/24  )

Too many dots for an IP address. I hope that is manual obfuscation...

> ETH1 = WAN  1.2.4.4/32	
>   
> The squid part 
> # From squid cache.log the needed lines from a start of squid with the lines from squid.conf 
> 
> # http_port localhost:3128 connection-auth=off
> 2020/02/10 11:44:13 kid1| Accepting HTTP Socket connections at local=[::1]:3128 remote=[::] FD 17 flags=1 
> # all requests for and on loclhost are trusted, so fully allowed withouth authenticationn. 

NP: "connection-auth=" has nothing to do with whether the connection is
trusted or not. It is about whether the HTTP auth schemes are going to
be used. Disabling it breaks NTLM and Negotiate - the "connection based"
auth schemes.

> 
> # http_port 192.168.249.221:3128 intercept  ( no-authentication possbible on intercept ) 
> 2020/02/10 11:44:13 kid1| Accepting NAT intercepted HTTP Socket connections at local=192.168.0.1.1:3128 remote=[::] FD 21 flags=33
> 

 ... looks to be botched obfuscate. The config line does not match IPs
with the mentioned log line.

BTW, standardized IP ranges like 192.168.* do not really need
obfuscating. They are not (or should not be) globally accessible.

> # https_port 192.168.249.221:3129 intercept ssl-bump \ .. (plus the cert - key parts, not relevant this works ). 
> 2020/02/10 11:44:13 kid1| Accepting NAT intercepted SSL bumped HTTPS Socket connections at local=192.168.0.1.1:3129 remote=[::] FD 25 flags=33
> 
> # Non-proxy aware  (with authentication)
> # http_port 192.168.249.221:8080
> 2020/02/10 11:44:13 kid1| Accepting HTTP Socket connections at local=192.168.0.1.1:8080 remote=[::] FD 29 flags=1
> 
> # http_port 192.168.249.221:8081 ssl-bump \ .. (plus the cert - key parts, not relevant this works ). 
> 2020/02/10 11:44:13 kid1| Accepting SSL bumped HTTP Socket connections at local=192.168.0.1.1:8081 remote=[::] FD 37 flags=1
> 

[ I have unwound the nested tree of sub-chains to follow what is going
on more simply. ]

> 
> # Generated by xtables-save v1.8.2 on Mon Feb 10 15:16:26 2020
> *filter
> :INPUT DROP [213:54000]
> :FORWARD ACCEPT [704:28436]
> :OUTPUT ACCEPT [57:19155]

> -A INPUT -m conntrack --ctstate NEW -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW AUDIT] "> -A INPUT -i lo -j ACCEPT

This should probably be done *after* the checks and handling of INVALID
traffic.

> -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -m conntrack --ctstate INVALID -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW AUDIT INVALID] "
> -A INPUT -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
> -A INPUT -m conntrack --ctstate INVALID -j DROP> -A INPUT -i eth0 -p udp -m multiport --dports 80,443 -j DROP

Use REJECT here. HTTP/3 uses these ports and DROP will cause Browsers
etc to have long timeouts on initial connection setup.

> -A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "

> -A FORWARD -m conntrack --ctstate NEW -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW AUDIT] "
> -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
> -A FORWARD -p tcp -m conntrack --ctstate NEW -j ACCEPT
> -A FORWARD -p udp -m conntrack --ctstate NEW -j ACCEPT

> -A OUTPUT -m conntrack --ctstate NEW -m limit --limit 3/min
--limit-burst 10 -j LOG --log-prefix "[UFW AUDIT] "
> -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
> -A OUTPUT -o lo -j ACCEPT
> -A OUTPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
> -A OUTPUT -p tcp -m conntrack --ctstate NEW -j ACCEPT
> -A OUTPUT -p udp -m conntrack --ctstate NEW -j ACCEPT

> 
> *nat
> :PREROUTING ACCEPT [0:0]
> :INPUT ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]

> -A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -m comment --comment "Squid-Intercept 443->3129" -j REDIRECT --to-ports 3129
> -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -m comment --comment "Squid-Intercept 80->3128" -j REDIRECT --to-ports 3128

 1) Your Log lines above say that Squid is accepting *forward proxy*
traffic on port localhost:3128. The above rules will intercept that traffic.
  One of several reasons why one should avoid using a standard port for
purposes other than its officially registered use.

 2) there are no lines preventing NAT catching the traffic leaving Squid
to those ports and looping it back into Squid.

> -A POSTROUTING -s 192.168.0.1.0/24 -o eth1 -m comment --comment "IP-Masq Lan via eth1" -j MASQUERADE

> 
> *mangle
> :PREROUTING ACCEPT [0:0]
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]

Missing rule(s) to prevent other machines and software sending traffic
directly to the NAT intercept ports Squid is using. You need those ports
to be locked down so only the NAT system can cause packets to arrive there.

> 
> Thanks for looking at it.. 
> I hope someone see what im doing wrong here..
> 

There are a few other things (ICMP handling etc.), But I am restricting
my comments to the rules that are processed for HTTP(S) traffic.

Amos