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

[Jonathan Lee]

Does this also auto solve for IPv6 connections changing it to just 

http_port 3128
https_port 3129??

> On Jul 12, 2024, at 04:57, Amos Jeffries <squid3 at treenet.co.nz> wrote:
> 
> 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
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org <mailto:squid-users at lists.squid-cache.org>
> https://lists.squid-cache.org/listinfo/squid-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20240727/798e17d7/attachment-0001.htm>