Squid Proxy on Ubuntu: The Access-Control Checklist

Production validation: keep Squid from becoming an open proxy

This runbook applies to an Ubuntu or Debian Squid host using the packaged service name squid, the main configuration file at /etc/squid/squid.conf, and a network firewall such as UFW or a cloud security group. Squid access rules and firewall rules should agree with each other: Squid decides who is allowed to proxy requests, while the firewall decides who can reach the listening port at all. The Squid http_access documentation is clear that rule order matters, so place narrow allow rules before the final deny rule and test from both an allowed and a denied source. Squid http_access docs

Target system: Ubuntu/Debian Squid host

# /etc/squid/squid.conf
# Replace these examples before production use.
http_port 192.0.2.10:3128

acl hosting_admins src 203.0.113.0/24
http_access allow hosting_admins
http_access deny all

If the proxy should listen on one private address only, bind http_port to that address instead of every interface. Squid documents http_port as the directive that controls the socket Squid listens on, so this is the right place to make the listening address explicit. Squid http_port docs If the proxy must listen publicly, compensate with both a strict firewall rule and a specific Squid ACL. Avoid a broad rule such as http_access allow all; that is the classic open-proxy mistake.

Target system: Ubuntu/Debian after editing Squid configuration

sudo squid -k parse
sudo squid -k reconfigure
systemctl status squid --no-pager

squid -k parse should succeed before you reconfigure the running daemon. If parsing fails, do not reload or restart; fix the syntax while the old process is still serving traffic. If reconfigure succeeds but clients still fail, check whether the service is listening on the expected address and whether another firewall layer is blocking the port. The Ubuntu Squid man page identifies Squid as the local web proxy/caching daemon and documents the service command context for packaged Ubuntu systems. Ubuntu squid man page

Target system: Ubuntu/Debian proxy host using UFW

sudo ufw allow from 203.0.113.0/24 to any port 3128 proto tcp
sudo ufw status numbered

On a cloud VPS, repeat the same scoping in the provider security group. UFW can be correct while the provider firewall still allows the world, or the reverse. Also check IPv6: a proxy locked down for IPv4 but reachable on a public IPv6 address can still be abused. Ubuntu’s server firewall documentation explains UFW as Ubuntu’s default firewall management interface, so this command path is Ubuntu/Debian-specific rather than a generic Linux instruction. Ubuntu firewall documentation

Verification from allowed and denied clients

Target system: allowed admin workstation or VPN client

curl --proxy http://PROXY_IP:3128 --head https://example.com/

Target system: denied workstation outside the approved source range

curl --proxy http://PROXY_IP:3128 --connect-timeout 5 --head https://example.com/

Target system: Ubuntu/Debian Squid host while running both tests

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

A good result is boring: the allowed client receives a normal HTTP response, the denied client fails or receives a Squid denial, and the access log shows the difference. Squid’s access_log documentation describes request logging, which makes the log check part of the control rather than an afterthought. Squid access_log docs For HTTPS, successful proxying often appears as a CONNECT request, while rejected clients commonly show TCP_DENIED/403. If both clients are allowed, review ACL order and firewall scope. If both are denied, review the source CIDR, NAT/VPN egress address, http_port binding, and cloud firewall. If nothing appears in access.log, the request may not be reaching Squid at all.

Platform notes before copying this Ubuntu Squid pattern elsewhere

The commands above are for Ubuntu/Debian because they use the Ubuntu package name, service behavior, UFW example, and /etc/squid/squid.conf path. On a RHEL-family server such as RHEL, AlmaLinux, Rocky Linux, or many non-cPanel CloudLinux systems, the same Squid directives are still relevant, but the package and firewall commands usually change to dnf, systemctl, and firewall-cmd. Do not paste the UFW rule into a RHEL-family host and assume the firewall is handled. The safe translation is to keep the Squid ACL logic identical, then implement the port restriction in the firewall tool that host actually uses.

Target system: RHEL-family host using firewalld, concept example only

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.0/24" port protocol="tcp" port="3128" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

That example is intentionally labeled as RHEL-family, not Ubuntu. The Squid documentation remains the authority for acl, http_access, http_port, and access_log; the operating system documentation controls the firewall syntax. On cPanel/WHM hosting, be even more careful: shared hosting accounts generally should not run a public Squid proxy at all, and root-managed services should be coordinated through the host’s firewall and abuse policy. A hosting proxy becomes an abuse target quickly if it accepts unauthenticated traffic from the internet.

Review checklist before exposing port 3128

• Does Squid listen only on the intended interface?
• Does the host firewall restrict the same source range as the Squid ACL?
• Does the cloud firewall or provider security group repeat that restriction?
• Have you tested both an allowed and a denied client?
• Can you identify the client IP, requested host, and result in access.log during an abuse review?