[squid-users] squidclient -h 127.0.0.1 -p 3128 mgr:info shows access denined

Amos Jeffries squid3 at treenet.co.nz
Fri Jul 12 11:57:12 UTC 2024


On 12/07/24 11:50, Jonathan Lee wrote:
>> I recommend changing your main port to this:
>>
>>   http_port 3128 ssl-bump ....
> 
> This is set to this when it processes
> 
> http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS tls-dh=prime256v1:/etc/dh-parameters.2048 options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE
> 

The key thing here was the removal of the IP address. So that Squid 
received both the 192.168.*.* and the 127.0.0.* traffic without needing 
separate http_port lines.



> 
>> and receiving the intercepted traffic on:
>>
>>  http_port 3129 intercept ssl-bump …
> 
> Do you mean https?
> 

Sorry. I missed that you had an https_port using 3129 already.



> https_port 127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=20MB cert=/usr/local/etc/squid/serverkey.pem cafile=/usr/local/share/certs/ca-root-nss.crt capath=/usr/local/share/certs/ cipher=EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!RC4:!aNULL:!eNULL:!LOW:!3DES:!SHA1:!MD5:!EXP:!PSK:!SRP:!DSS tls-dh=prime256v1:/etc/dh-parameters.2048 options=NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE
> 
> Https uses that port 3129
> 
> What should I adapt
> 
> http_port
> https_port?
> 

Both.

FYI, there are two issues:

1) listening on IP 127.0.0.1. Inside the OS there are different devices 
for localhost (lo) and WAN (eg. eth0). NAT is problematic already 
without introducing any tricky behaviours from bridging those "private" 
(lo) and "public" WAN devices.

The simplest solution is just not to put any IP address on the 
squid.conf *port line(s) with intercept options. The OS will select one 
appropriate for whatever device and tell Squid on a per-connection basis.

The more difficult way is to put one of the machines "global" (WAN or 
LAN) IP addresses. In your case 192.168.1.1. With most connections being 
from the LAN that minimizes the possible problems.


2) listening on a well-known proxy port 3128 for intercepted traffic.

There is malware in existence that scans for at least port 3128 (likely 
1080, 8080 etc common proxy ports) being used by proxies like yours and 
abuses them. As a result at least one popular antivirus network scanner 
(from Trend) does the same scan to detect insecure proxies.

The worst thing about this situation is that the NAT very effectively 
hides the malware. So it is extremely hard to see whether it is 
happening to you.


I am not sure what UI you are using to show those firewall rules in your 
other email. However the one that had ALLOW for the port range 3128-3129 
worries me. AFAIK that should only be for 3128 and a separate rule 
somewhere else to drop the intercepted port 3129 traffic pre-NAT.


HTH
Amos


More information about the squid-users mailing list