Squid Caching Proxy on AWS User Guide

Overview

This guide covers deploying and operating Squid on AWS using the cloudimg AWS Marketplace image. Squid is one of the most widely deployed open source caching proxies in the world, used to cache web content, accelerate repeat requests and control outbound HTTP and HTTPS traffic. It runs as a headless daemon configured through /etc/squid/squid.conf, with no web console.

The image installs Squid 6.14 from the Ubuntu 24.04 archive (GPL 2.0) and configures a responsible, secure by default caching forward proxy for your own authorized clients: content caching, egress control and bandwidth savings inside your network. It is not an anonymizer, and it is not a way to bypass geo restrictions or run an open public proxy.

Never an open proxy. An unauthenticated forward proxy reachable from the public internet is abused for spam relaying, credential stuffing and content laundering. This image ships default deny with per instance proxy authentication: the only rule that permits proxying is http_access allow authenticated, the final rule is http_access deny all, and there is deliberately no http_access allow all. Every request must present a valid proxy username and password or it is refused with 407 Proxy Authentication Required.

Security by design, no default credential. No default or shared credential ships in the image. On the first boot of every instance the squid-firstboot.service runs once. It generates a per instance proxy password, writes it hashed into the Squid password database at /etc/squid/passwd, and writes the plaintext login to /root/squid-credentials.txt (mode 0600, root only). The captured image ships no password database at all, and squid.service is gated on that file, so no instance can proxy until first boot provisions your instance. A stale or guessed password is refused with a 407, and every instance ends up with a different password.

What is included:

• Squid 6.14 from the Ubuntu 24.04 archive, run under systemd (squid.service) as the unprivileged proxy user, listening on port 3128

• A hardened, reviewed /etc/squid/squid.conf: default deny access control, per instance Basic proxy authentication, blocking of CONNECT tunnels to non TLS ports and requests to non web ports, a localhost only cache manager, disabled inter cache peering (ICP), and minimised information leakage (version string, Via and X-Forwarded-For suppressed)

• A per instance proxy password generated on first boot and documented in /root/squid-credentials.txt (0600), so no image ever ships a usable or default credential

• An on disk object cache so repeated requests for the same object are served from cache, reducing latency and egress bandwidth

• A squid-roundtrip.sh self check that proves, at any time, that an authenticated request succeeds and is cached while an unauthenticated request is refused

Connecting to your instance

Connect over SSH on port 22 as the default login user for your OS variant, using your EC2 key pair:

ssh -i your-key.pem ubuntu@<instance-ip>

Prerequisites

• An AWS account subscribed to the Squid listing on AWS Marketplace

• An EC2 key pair for SSH access

• A Security Group allowing TCP 22 (admin) and TCP 3128 (proxy). Restrict TCP 3128 to your trusted client subnets rather than opening it to the world, even though the proxy also requires authentication

Recommended instance type: m5.large (2 vCPU, 8 GB RAM) is a comfortable starting point. Scale up for more concurrent clients or a larger working cache.

Step 1: Launch from AWS Marketplace

Subscribe to the Squid listing, choose Launch through EC2, and pick your instance type, key pair, subnet and Security Group. Configure the Security Group to allow TCP 22 for administration and TCP 3128 for proxy clients, scoped to your trusted client subnets. Assign a public IP (or Elastic IP) if your clients connect from outside the VPC.

You can also launch from the AWS CLI (replace the AMI id with the one shown on your subscription's launch page, and the ids with your own):

aws ec2 run-instances \
  --image-id ami-xxxxxxxxxxxxxxxxx \
  --instance-type m5.large \
  --key-name your-key \
  --security-group-ids sg-xxxxxxxx \
  --subnet-id subnet-xxxxxxxx \
  --associate-public-ip-address

Step 2: First boot

On the first boot of every instance the squid-firstboot.service runs once. It asserts the shipped configuration is default deny and authentication required, generates the per instance proxy password into /etc/squid/passwd, initialises the cache, starts Squid, and writes the plaintext login to /root/squid-credentials.txt. Allow about 20 seconds after the instance is first reachable.

Step 3: Confirm the service is running

Squid runs under systemd and listens on port 3128. Confirm the version and that the service is active:

squid -v | head -1
systemctl is-active squid.service

Confirm the configuration is valid and that Squid owns the proxy port:

sudo squid -k parse >/dev/null && echo "squid.conf OK"
sudo ss -tlnp | grep ':3128 '

Step 4: Retrieve your per instance credentials

The per instance proxy username and password are written to a root only file on first boot. Confirm the file exists with the correct owner and permissions (do not print its contents into shared logs):

sudo ls -l /root/squid-credentials.txt

Read your credentials interactively when you need them:

sudo cat /root/squid-credentials.txt

The file records squid.proxy.user (the proxy username, proxyuser) and squid.proxy.pass (this instance's unique password), along with the proxy endpoint. Keep the password private.

Step 5: Prove the proxy works

The image ships a self contained self check that proves, without exposing your password, that an authenticated request succeeds and is served from cache on repeat, while an unauthenticated request is refused with 407 and a request to a denied port is refused with 403:

sudo /usr/local/sbin/squid-roundtrip.sh

You can also test from any client that has the credentials. Point the client at the instance on port 3128 with the username and password from /root/squid-credentials.txt:

curl -x http://<instance-ip>:3128 \
  --proxy-user 'proxyuser:<your-password>' \
  https://example.com/ -o /dev/null -sS -w '%{http_code}\n'

A repeated request for the same cacheable object is served from Squid's cache. The same request without credentials is refused with 407, proving this is not an open proxy.

Step 6: Review the security configuration

The whole access policy lives in one reviewed /etc/squid/squid.conf. The rule ordering is the security guarantee: port safety checks first, the cache manager restricted to localhost, then the only proxying allow rule (http_access allow authenticated), then http_access deny all as the final rule. There is no http_access allow all:

grep -E 'auth_param basic (program|realm)|^acl authenticated|^http_access|^http_port|^icp_port' /etc/squid/squid.conf

Step 7: Restrict the proxy port to trusted clients

Even though the proxy requires authentication, scope network access to it. In the EC2 Security Group, restrict inbound TCP 3128 to your trusted client subnets or Elastic IPs rather than 0.0.0.0/0. Keep TCP 22 restricted to your administration network. Treat the per instance password as a secret and rotate it if it is ever exposed.

Step 8: Add proxy users or rotate the password

The password database is a standard Apache style htpasswd file at /etc/squid/passwd. Add another proxy user, or change a password, with the htpasswd tool (install apache2-utils first), then reload Squid without dropping connections:

sudo apt-get install -y apache2-utils
sudo htpasswd /etc/squid/passwd newuser
sudo squid -k reconfigure

To rotate the built in proxyuser password, run sudo htpasswd /etc/squid/passwd proxyuser, then sudo squid -k reconfigure, and update any clients.

Step 9: Tune caching and add upstream peers

Edit /etc/squid/squid.conf to tune the cache. Common changes are the on disk cache size (cache_dir ufs /var/spool/squid 1024 16 256, where 1024 is megabytes), in memory cache (cache_mem 256 MB), the maximum cacheable object size (maximum_object_size 256 MB), and the refresh_pattern rules that control object freshness. To chain to an upstream proxy, add a cache_peer line. After any change, validate and reload:

sudo squid -k parse
sudo squid -k reconfigure

Step 10: Enable TLS interception (optional)

For content filtering or caching of HTTPS traffic you can enable TLS interception (SSL bump). This requires generating a certificate authority whose certificate you install on your client machines, and configuring http_port ... ssl-bump with ssl_bump rules. Because it decrypts client traffic, deploy it only for clients you own and administer, and generate the CA key per deployment. cloudimg engineers can help you design and deploy an SSL bump configuration after purchase.

Honest use

This image is a caching forward proxy for your own authorized clients - content caching, egress control and bandwidth savings inside your network. Do not operate it as an open public proxy, an anonymizer, or a way to bypass geo restrictions. The default deny, authentication required configuration is designed to keep it a responsible, private proxy.

Support

cloudimg provides 24/7 technical support for this image. Our engineers can help with scoping client access lists, restricting the proxy port to trusted subnets, adding upstream cache peers, tuning caching and refresh rules, enabling TLS interception, and version upgrades. Contact support@cloudimg.co.uk; critical issues receive a one hour average response time.

cloudimg is not affiliated with or endorsed by the Squid project or the Squid Software Foundation. All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.