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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
