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