Squid 7.8

Option A: AWS Marketplace console

• Open the SecureAnyCloud Hardened WireGuard VPN & VPN, Proxy and Remote Access AMIs listing on AWS Marketplace. Choose View purchase options, then Subscribe. One subscription covers every version in the listing.
• When the subscription is active, choose Launch your software.
• Choose One-click launch from AWS Marketplace, or Launch from EC2 Console for the full launch wizard. In Version, choose Squid 7.8 on Ubuntu 24.04, then choose your Region.
• Pick an instance type and your key pair. m5.large is recommended, and the software charge is $0.04 per vCPU per hour.
• Set the security group. The listing's default group allows SSH (22) only, so restrict it to your own IP address. You open the proxy port to your clients in Step 5.
• Choose your VPC and subnet and leave the metadata defaults, because the image already requires IMDSv2. Then choose Launch.

Option B: AWS CLI

Run these commands on your own workstation. They create a security group that allows SSH from your management address and the proxy port from your VPC only, then launch the instance. Replace the AMI ID with the one shown for your Region on the Marketplace launch page. Replace the VPC, subnet, key pair and CIDR ranges with your own.

SG=$(aws ec2 create-security-group --group-name squid \
  --description "Squid caching proxy" --vpc-id vpc-0123456789abcdef0 \
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 22 --cidr <your-mgmt-cidr>
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 3128 --cidr <vpc-cidr>
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids "$SG" \
  --subnet-id subnet-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=squid}]'

You do not need --metadata-options, because the AMI already requires IMDSv2.

Connect over SSH as ubuntu with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>

First boot finishes within a minute of launch. It generates this instance's proxy password and stores only a SHA-512 hash of it in /etc/squid/passwd. It then starts Squid and checks that Squid refuses requests without the password, accepts them with it and refuses the metadata service.

The details are in /root/squid-credentials.txt, which only root can read. This command prints everything except the password line:

sudo grep -v '^PROXY_PASSWORD=' /root/squid-credentials.txt

# Squid 7.8 - generated on first boot by squid-firstboot.service.
# The password below is unique to this instance; nothing was baked into the image. Keep this file private.
#
# VPC clients: HTTP proxy 172.31.81.132:3128 with the user and password below (open TCP 3128 in the security group to
# your VPC or client security group only - never 0.0.0.0/0). Only private (RFC 1918 / fc00::/7) sources are served. PROXY_HOST=172.31.81.132 PROXY_PORT=3128 PROXY_USER=sac
# Self-test:
sudo squid-selftest New password:
sudo squid-access rotate-password Status:
sudo squid-access status
# Guide: https://secureanycloud.com/stacks/squid-7-8/

PROXY_HOST is your instance's private IP address. To see the password, run sudo cat /root/squid-credentials.txt.

Check that Squid and its first-boot service are active and see which ports are listening:

systemctl is-active squid squid-firstboot
sudo ss -Hltn | awk '{print $4}' | sort

active active *:3128 0.0.0.0:22 127.0.0.53%lo:53 127.0.0.54:53 [::]:22

Squid listens on port 3128 on IPv4 and IPv6. The two :53 sockets are Ubuntu's local DNS resolver on loopback, which Squid uses for name lookups.

Run the self-test that ships with the image. It exercises the whole path without printing the password:

sudo squid-selftest

SELFTEST_OK squid=active user=proxy port=3128 no-credential=407 wrong-password=407 password=200 imds=403 imds6=403 loopback=403

Clients in your VPC connect to the instance's private IP address on port 3128. In the EC2 console, edit the instance's security group and add an inbound rule with these values:

• Type: Custom TCP, Port range: 3128
• Source: your VPC CIDR (for example 10.0.0.0/16) or the security group your client instances use

Never use 0.0.0.0/0. Squid refuses public source addresses and still requires the password, but the port should not be exposed to the internet at all.

From a client instance in your VPC, pass the user and password from Step 2. With curl, run:

curl -sS -o /dev/null -w '%{http_code}\n' --proxy http://<PROXY_HOST>:3128 --proxy-user '<PROXY_USER>:<PROXY_PASSWORD>' https://example.com/

200

For tools that read the standard environment variables (apt, pip, curl, wget, most SDKs), set http_proxy and https_proxy to http://<PROXY_USER>:<PROXY_PASSWORD>@<PROXY_HOST>:3128.

The proxy password travels with HTTP Basic authentication on the proxy connection, which is not encrypted. Keep port 3128 inside your VPC. To use the proxy across the internet, open an SSH tunnel with ssh -L 3128:127.0.0.1:3128 ..., then point your client at the proxy 127.0.0.1:3128 with the same user and password.

Without a password, Squid answers 407 and asks for Basic credentials. On the instance, run:

curl -s -D - -o /dev/null -x http://127.0.0.1:3128 http://example.com/ | tr -d '\r' | grep -E '^(HTTP|Proxy-Authenticate|Server)'

HTTP/1.1 407 Proxy Authentication Required Server: squid Proxy-Authenticate: Basic realm="sac Squid proxy"

A wrong password gets the same answer. Requests from addresses outside the private ranges are refused with 403 before any password is asked for. The rules are in /etc/squid/squid.conf. List them with:

grep -E '^http_access' /etc/squid/squid.conf

http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access deny to_localhost http_access deny to_linklocal http_access deny to_metadata http_access deny to_self http_access allow localhost manager http_access deny manager http_access deny FTP http_access deny !localnet !localhost http_access allow localnet authenticated http_access allow localhost authenticated http_access deny all

The order matters, because the first match wins. The rules cover, in turn: unsafe ports and non-443 CONNECT, the forbidden destinations, the cache manager for loopback only, FTP, and sources outside your networks. Only then do the password-protected allow rules apply, with deny all last.

A proxy that fetches any URL could be abused to read the instance metadata service or to reach services that listen only on the instance itself. The next command tests this with the password. It writes the password to a curl config file on your session's private tmpfs, so it never appears on a command line or on disk.

sudo sh -c 'printf "proxy-user = \"sac:%s\"\n" "$(sed -n "s/^PROXY_PASSWORD=//p" /root/squid-credentials.txt)"' > /run/user/$(id -u)/squid-curl for u in http://169.254.169.254/latest/meta-data/ 'http://[fd00:ec2::254]/latest/meta-data/' http://127.0.0.1:22/ http://localhost:8080/; do printf '%s %s\n' "$(curl -s -o /dev/null -w '%{http_code}' -K /run/user/$(id -u)/squid-curl -x http://127.0.0.1:3128 "$u")" "$u" done rm -f /run/user/$(id -u)/squid-curl

403 http://169.254.169.254/latest/meta-data/ 403 http://[fd00:ec2::254]/latest/meta-data/ 403 http://127.0.0.1:22/ 403 http://localhost:8080/

The 403 answers show Squid refusing the destination before it makes any connection. Independently of those rules, the Squid service and its authentication helper are blocked from the metadata service at the system level. Confirm this with:

systemctl show -p IPAddressDeny squid

IPAddressDeny=fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32

Squid's cache manager reports statistics. It answers on the instance's loopback address only, and no password-protected action (shutdown, reconfigure) is enabled. Query it from the instance:

curl -s http://127.0.0.1:3128/squid-internal-mgr/info | head -4

Squid Object Cache: Version 7.8 Build Info: Service Name: squid Start Time: Sat, 31 Oct 2026 18:56:55 GMT

If your clients use addresses outside the private ranges, for example a 100.64.0.0/10 secondary VPC range, add an acl localnet src line after the existing ones in /etc/squid/squid.conf. Use any editor, or the command below, then check and apply the change:

sudo sed -i '/^acl localnet src fc00::\/7/a acl localnet src <vpc-cidr>' /etc/squid/squid.conf
sudo squid-guard && sudo systemctl reload squid

squid-guard runs before every start and reload. It refuses a configuration in which an http_access allow rule does not require the password, the destination denies are missing or come after an allow, deny all is not last, or the cache manager has a password. It also re-renders the list of this instance's own addresses.

The security group still decides who can reach port 3128 at all.

Run this command to replace the proxy password:

sudo squid-access rotate-password

The command generates a new password, replaces the hash in /etc/squid/passwd and writes the new password to /root/squid-credentials.txt. It also restarts Squid, which empties the authentication cache, so the old password stops working at once.

sudo squid-access status shows the proxy address and the allowed source ranges without printing the password. To add more users, append user:hash lines to /etc/squid/passwd, using hashes from openssl passwd -6.

CONNECT tunnels are allowed to port 443 only. To allow another port, add acl SSL_ports port 8443 below the existing acl SSL_ports port 443 line in /etc/squid/squid.conf. Then run sudo squid-guard && sudo systemctl reload squid.

The disk cache is 1 GB in /var/spool/squid, and the memory cache is 256 MB. Both are set by cache_dir and cache_mem in squid.conf, so size them to your volume and instance. Logs are in /var/log/squid. View the latest access log lines with:

sudo tail -n 3 /var/log/squid/access.log

Each line holds the time, response time, client address, cache result and status, size, method, URL (without its query string), user and the upstream address. cache.log holds start-up messages and errors. Both logs rotate daily and are kept for seven days.