Networking Azure

Squid on Ubuntu 24.04 on Azure User Guide

Last updated: 2026-07-18 | Product: Squid 6.14 on Ubuntu 24.04 LTS on Azure

Overview

This guide covers the deployment and configuration of Squid on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Squid is a mature, widely deployed caching forward proxy for HTTP and HTTPS. It sits between clients and the wider web, caching frequently requested content to cut bandwidth and latency, and applying access control over which clients may reach which destinations.

The image installs Squid 6.14 from the Ubuntu 24.04 archive and configures it as a responsible, secure by default caching proxy for use inside your own network. Unattended security upgrades remain enabled on the running VM so the package keeps receiving patches.

Security by design, not an open proxy. An open forward proxy that will relay requests for anyone on the internet is abused for spam relaying, anonymisation and attack laundering. This image ships with source address ACLs so the proxy answers only the machine itself (localhost) and hosts on private, RFC1918 ranges. Every other source, including the public internet, falls through to a final http_access deny all rule and is refused. There is deliberately no http_access allow all. Requests to non web ports and CONNECT tunnels to non TLS ports are also blocked, the cache manager is reachable only from localhost, ICP is disabled, and information leakage is minimised.

Security by design, no bootstrap credential. The image ships without proxy authentication. Access is controlled by source address, not a shared password, so there is nothing to leak. If you want password based access you can opt in to Basic authentication and generate your own credential on the VM (see Step 11); no secret is ever baked into the image.

What is included:

Squid 6.14 from the Ubuntu 24.04 archive, run under systemd as the unprivileged proxy user (squid.service), listening on TCP 3128
A secure caching proxy configuration: source address ACLs (localhost plus RFC1918 only), a final http_access deny all, blocked unsafe ports, a localhost only cache manager, ICP disabled, and version string, Via and forwarded for hardening
A response cache (256 MB memory cache plus a 1 GB on disk cache) so repeated requests are served locally as cache hits
A shipped self test tool, squid-roundtrip.sh, that proves the proxy forwards, serves a repeat from cache and refuses a denied request
Ubuntu 24.04 LTS base with latest security patches applied at build time, and unattended security upgrades kept enabled
Azure Linux Agent for seamless cloud integration and SSH key injection
24/7 cloudimg support with a guaranteed 24 hour response SLA

Prerequisites

Active Azure subscription, SSH public key, VNet and subnet in the target region
Subscription to the Squid listing on Azure Marketplace
Network Security Group rules allowing TCP 22 (admin) and TCP 3128 (proxy) from the client networks that will use the proxy

Recommended virtual machine size: Standard_B2s (2 vCPU, 4 GB RAM) is ample for a caching proxy serving a local network. Sites with very high request volumes can use Standard_D2s_v5 or larger, and can raise cache_mem and the cache_dir size in the configuration.

Step 1: Deploy from the Azure Portal

Search Squid in Marketplace, select the cloudimg publisher, and click Create. Configure the Network Security Group to allow TCP 3128 (proxy) from your client subnets, and TCP 22 for administration. Keep 3128 restricted to trusted client networks only; never expose it to the public internet.

Step 2: Deploy from the Azure CLI

RG="proxy-prod"; LOCATION="eastus"; VM_NAME="squid1"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/squid-ubuntu-24-04/versions/<version>"
SSH_KEY="$(cat ~/.ssh/id_rsa.pub)"
az group create --name "$RG" --location "$LOCATION"
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$GALLERY_IMAGE_ID" \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard
# Open the proxy and admin ports on the VM's NSG (restrict 3128 to your client subnet):
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 3128 --priority 1001
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1002

Step 3: First boot

On first boot the image resolves the VM address, asserts the secure defaults (not an open proxy), config tests Squid, initialises the cache, starts the service, proves a proxied round trip works and a repeat is served from cache, then writes /root/squid-credentials.txt. This completes within a minute. SSH in as azureuser and read the endpoint details:

sudo cat /root/squid-credentials.txt

Step 4: Confirm the service is running

squid.service is active and owns port 3128. ss confirms the squid process is the listener on :3128.

systemctl is-active squid.service
sudo ss -tulnp | grep -E ':3128 '

Expected output:

active
tcp   LISTEN 0      256                 *:3128             *:*    users:(("squid",pid=2247,fd=18))

squid.service reports active, and ss shows the squid process listening on TCP port 3128, confirming the caching proxy is up and ready to accept client connections

Step 5: Make a request through the proxy and prove caching

Point a request at the proxy with curl -x. The proxy forwards it to the origin and returns the response. Then run the shipped self test tool: it fetches a local object through the proxy twice, so the repeat is served from cache (a cache HIT), and confirms a denied request is refused.

curl -x http://127.0.0.1:3128 -s -o /dev/null -w 'via proxy: HTTP %{http_code}\n' http://example.com/
sudo /usr/local/sbin/squid-roundtrip.sh

Expected output:

via proxy: HTTP 200
round-trip OK: proxied fetch succeeded, repeat served from cache (TCP_MEM_HIT), request to a denied port refused (HTTP 403); the shipped config is not an open proxy (http_access deny all is the final rule; only localhost + RFC1918 allowed)

A request through the proxy to example.com returns HTTP 200, and the squid-roundtrip self test reports the repeat request was served from cache as a TCP_MEM_HIT and that a request to a denied port was refused with HTTP 403, proving both caching and the secure defaults

Step 6: Review the configuration

The cloudimg configuration is the whole of /etc/squid/squid.conf (the stock file is backed up to squid.conf.orig). squid -k parse validates it. The version is 6.14 from the Ubuntu archive.

squid -v | head -1
sudo squid -k parse >/dev/null 2>&1 && echo "squid -k parse: OK (configuration is valid)"
grep -vE '^[[:space:]]*#|^[[:space:]]*$' /etc/squid/squid.conf

Expected output (comments and blank lines stripped for brevity):

Squid Cache: Version 6.14
squid -k parse: OK (configuration is valid)
visible_hostname squid.cloudimg.internal
acl localnet src 10.0.0.0/8
acl localnet src 172.16.0.0/12
acl localnet src 192.168.0.0/16
acl localnet src fc00::/7
acl localnet src fe80::/10
acl SSL_ports port 443
acl Safe_ports port 80
...
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access allow localnet
http_access deny all
http_port 3128
icp_port 0
cache_mem 256 MB
maximum_object_size 256 MB
cache_dir ufs /var/spool/squid 1024 16 256
httpd_suppress_version_string on
via off
forwarded_for delete

squid version 6.14 reported, squid -k parse confirms the configuration is valid, and the squid.conf listing shows the localnet ACLs restricted to private ranges, the ordered http_access rules ending in deny all, the 3128 listener, ICP disabled and the information leakage hardening

Step 7: Verify the responsible defaults

This is the key security property. The http_access rules allow only localhost and the private localnet ranges and end with http_access deny all, so the proxy is not open to the public internet. A request that falls to a denied rule (here, a non web port) is actively refused with HTTP 403.

grep -E '^[[:space:]]*http_access' /etc/squid/squid.conf
curl -x http://127.0.0.1:3128 -s -o /dev/null -w 'request to denied port: HTTP %{http_code}\n' http://127.0.0.1:9/
sudo grep -E '^squid\.' /root/squid-credentials.txt

Expected output:

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access allow localnet
http_access deny all
request to denied port: HTTP 403
squid.host=10.0.0.11
squid.proxy=10.0.0.11:3128

The http_access rules show allow localhost and allow localnet followed by a final deny all, a request to a denied port is refused with HTTP 403, and the per-VM endpoint notes list only the proxy host and port with no password, confirming the proxy is not open and ships no baked credential

Step 8: Point clients at the proxy

Configure the clients on your local network to use the VM as their HTTP and HTTPS proxy. On a Linux client, set the standard proxy environment variables (replace <proxy-ip> with the VM public IP, or its private IP inside the VNet):

export http_proxy="http://<proxy-ip>:3128"
export https_proxy="http://<proxy-ip>:3128"

Because of the source address ACLs, only clients on a private (RFC1918) subnet, or the box itself, are served, so keep the proxy and its clients on the same VNet or a peered network. For an application, set its proxy setting to http://<proxy-ip>:3128.

Step 9: Allow additional client networks (optional)

If your clients are on a network range that is not one of the default RFC1918 ranges, add an ACL for it. Drop a file such as /etc/squid/conf.d/20-clients.conf (or edit /etc/squid/squid.conf) with your own network, keeping the deny all as the final rule:

# allow an extra trusted client subnet
acl mynet src 100.72.0.0/16
http_access allow mynet

Validate with sudo squid -k parse, then apply live with sudo squid -k reconfigure. Only ever allow networks you control, and never add http_access allow all.

Step 10: Control outbound destinations (optional)

A common use of a forward proxy is to restrict which destinations clients may reach. To allow only a named set of sites, add a destination ACL and place it before the allow rules:

# only allow the listed destination domains
acl allowed_sites dstdomain .ubuntu.com .github.com .microsoft.com
http_access deny localnet !allowed_sites

Validate with sudo squid -k parse and apply with sudo squid -k reconfigure. Client requests to any domain not on the list are then refused.

Step 11: Enable Basic proxy authentication (optional)

To require a username and password instead of, or in addition to, source address control, enable Basic authentication with a per VM credential that you generate on the VM (never baked into the image). Install the helper, create a user, then add the auth stanza to /etc/squid/conf.d/10-auth.conf:

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic realm cloudimg squid proxy
acl authenticated proxy_auth REQUIRED
http_access allow localnet authenticated

Create the password file with sudo apt-get install -y apache2-utils then sudo htpasswd -c /etc/squid/passwords <username> (you will be prompted for a password), set it readable by the proxy user, validate with sudo squid -k parse, and apply with sudo squid -k reconfigure.

Step 12: Security recommendations

Restrict the NSG. Allow TCP 3128 only from the client networks that need the proxy, and TCP 22 for administration only. Never expose 3128 to the public internet.
Keep it closed by default. The shipped configuration ends in http_access deny all; keep that rule last so any new client range is allowed only where you add an explicit rule.
Prefer destination allow lists for egress control. Step 10 shows how to limit which sites clients may reach through the proxy.
Keep the OS and Squid patched. Unattended security upgrades remain enabled on the running VM.
Watch the logs. /var/log/squid/access.log records every request with a cache result code (for example TCP_MEM_HIT or TCP_MISS), and /var/log/squid/cache.log records service messages.

Step 13: Support and Licensing

Squid is free software maintained by the Squid Software Foundation and contributors, distributed under the GNU General Public License, version 2 (GPL-2.0). This cloudimg image bundles the unmodified Ubuntu archive package. cloudimg provides the packaging, the secure caching proxy hardening, the not an open proxy defaults, the shipped self test tool, and 24/7 support with a guaranteed 24 hour response SLA.

cloudimg is not affiliated with or endorsed by the Squid project or the Squid Software Foundation. Squid is used here only to identify the software.

Deploy on Azure

Find Squid on Ubuntu 24.04 LTS on the Azure Marketplace, published by cloudimg. Deploy from the Portal or the Azure CLI as shown above.

Need Help?

Email support@cloudimg.co.uk for deployment help, configuration questions, or licensing enquiries.