Tinyproxy

Search for Tinyproxy in Azure Marketplace, select the SecureAnyCloud publisher, and click Create. Configure the Network Security Group to allow TCP 8888 (proxy) from your client subnets and TCP 22 for administration. Restrict port 8888 to trusted client networks and never expose it to the public internet.

RG="proxy-prod"; LOCATION="eastus"; VM_NAME="tinyproxy1" IMAGE_URN="sac1647283583153:tinyproxy-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:tinyproxy-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --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 8888 to your client subnet):
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 8888 --priority 1001
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1002

On first boot the image resolves the VM address, generates a unique per VM proxy password, and injects it into the Tinyproxy configuration. It then asserts the secure defaults, starts the service, and proves that an anonymous request is refused while an authenticated request succeeds. This completes within a minute. SSH in as azureuser and read the credentials:

sudo cat /root/tinyproxy-credentials.txt

Expected output (the password is unique to your VM):

proxy.user=sac proxy.pass=<per-VM-password> proxy.host=10.0.0.18 proxy.endpoint=10.0.0.18:8888

Check that tinyproxy.service is active and owns port 8888. The ss output confirms that the tinyproxy process is the listener on :8888.

systemctl is-active tinyproxy.service
sudo ss -tulnp | grep -E ':8888 '

Expected output:

active tcp LISTEN 0 1024 0.0.0.0:8888 0.0.0.0:* users:(("tinyproxy",pid=26937,fd=3))

Send a request through the proxy with curl -x. A request without credentials is refused with HTTP 407 (Proxy Authentication Required). A request with the per VM credentials succeeds with HTTP 200. Read the username and password from the credentials file, then run the self test tool.

PROXY_USER="$(sudo grep -E '^proxy\.user=' /root/tinyproxy-credentials.txt | cut -d= -f2-)" PROXY_PASS="$(sudo grep -E '^proxy\.pass=' /root/tinyproxy-credentials.txt | cut -d= -f2-)" curl -x "http://127.0.0.1:8888" -s -o /dev/null -w 'anonymous request: HTTP %{http_code}\n' http://example.com/ curl -x "http://$PROXY_USER:$PROXY_PASS@127.0.0.1:8888" -s -o /dev/null -w 'authenticated request: HTTP %{http_code}\n' http://example.com/
sudo /usr/local/sbin/tinyproxy-roundtrip.sh

Expected output:

anonymous request: HTTP 407 authenticated request: HTTP 200 round-trip OK: anonymous request refused (HTTP 407), authenticated request with the per-VM password succeeded (HTTP 200); the shipped proxy is not open (localhost + RFC1918 only) and enforces per-VM BasicAuth

Review the configuration. The SecureAnyCloud configuration is the whole of /etc/tinyproxy/tinyproxy.conf, and the stock file is backed up to tinyproxy.conf.orig. The version is 1.11.1 from the Ubuntu archive. The BasicAuth line carries this VM's unique password, which is masked below.

tinyproxy -v | head -1 grep -vE '^[[:space:]]*#|^[[:space:]]*$' /etc/tinyproxy/tinyproxy.conf

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

tinyproxy 1.11.1 User tinyproxy Group tinyproxy Port 8888 Timeout 600 DefaultErrorFile "/usr/share/tinyproxy/default.html" StatFile "/usr/share/tinyproxy/stats.html" LogFile "/var/log/tinyproxy/tinyproxy.log" LogLevel Info PidFile "/run/tinyproxy/tinyproxy.pid" MaxClients 100 Allow 127.0.0.1 Allow ::1 Allow 10.0.0.0/8 Allow 172.16.0.0/12 Allow 192.168.0.0/16 Allow fc00::/7 ViaProxyName "sac" DisableViaHeader Yes ConnectPort 443 ConnectPort 563 BasicAuth sac <per-VM-password>

Confirm the key security property. The Allow rules permit only localhost and the private RFC1918 ranges, there is no Allow 0.0.0.0/0, and the BasicAuth line forces every request to authenticate. A request without valid credentials is refused with HTTP 407.

grep -E '^[[:space:]]*(Allow|BasicAuth|ConnectPort|DisableViaHeader)' /etc/tinyproxy/tinyproxy.conf curl -x http://127.0.0.1:8888 -s -o /dev/null -w 'anonymous request: HTTP %{http_code}\n' http://example.com/
sudo grep -E '^proxy\.(user|host|endpoint)=' /root/tinyproxy-credentials.txt

Expected output (password masked):

Allow 127.0.0.1 Allow ::1 Allow 10.0.0.0/8 Allow 172.16.0.0/12 Allow 192.168.0.0/16 Allow fc00::/7 DisableViaHeader Yes ConnectPort 443 ConnectPort 563 BasicAuth sac <per-VM-password> anonymous request: HTTP 407 proxy.user=sac proxy.host=10.0.0.18 proxy.endpoint=10.0.0.18:8888

Configure the clients on your local network to use the VM as their HTTP and HTTPS proxy, with the credentials in the URL. 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, and use the username and password from the credentials file:

export http_proxy="http://sac:<per-VM-password>@<proxy-ip>:8888"
export https_proxy="http://sac:<per-VM-password>@<proxy-ip>:8888"

The source address ACLs serve only clients on a private (RFC1918) subnet, or the VM itself. Keep the proxy and its clients on the same VNet or a peered network. For an application, set its proxy setting to http://sac:<per-VM-password>@<proxy-ip>:8888.

If your clients are outside the default RFC1918 ranges, add an Allow line for their network. Edit /etc/tinyproxy/tinyproxy.conf and add your own network alongside the existing Allow lines:

# allow an extra trusted client subnet Allow 100.72.0.0/16

Apply the change with sudo systemctl restart tinyproxy. Allow only networks you control, and never add Allow 0.0.0.0/0. Basic authentication is enforced regardless of source address, so clients on the new subnet still need the proxy password.

The per VM password lives on the BasicAuth line in /etc/tinyproxy/tinyproxy.conf. To rotate it, edit that line. To add a second username and password pair, add another BasicAuth <user> <password> line. Then restart the service:

BasicAuth sac <a-new-strong-password> BasicAuth teammate <another-strong-password>

Apply the change with sudo systemctl restart tinyproxy. Update the credentials file to match any change you make. Never remove the BasicAuth line, because that turns off authentication.

Tinyproxy can filter which destinations clients may reach. Enable the filter in /etc/tinyproxy/tinyproxy.conf and point it at a file of allowed or denied domains:

Filter "/etc/tinyproxy/filter" FilterDefaultDeny Yes

Create /etc/tinyproxy/filter with one domain regex per line (for example \.ubuntu\.com$), then apply the change with sudo systemctl restart tinyproxy. With FilterDefaultDeny Yes, only destinations that match the file are allowed.

• Restrict the NSG. Allow TCP 8888 only from the client networks that need the proxy, and TCP 22 for administration only. Never expose port 8888 to the public internet.
• Keep authentication on. The shipped configuration requires a per VM password on every request. Never remove the BasicAuth line.
• Keep the proxy closed. The Allow rules restrict access to localhost and private ranges. Never add Allow 0.0.0.0/0.
• Use destination filtering for egress control. Step 11 shows how to limit which sites clients may reach through the proxy.
• Keep the OS and Tinyproxy patched. Unattended security upgrades remain enabled on the running VM.
• Watch the logs. /var/log/tinyproxy/tinyproxy.log records connections and errors.

Tinyproxy is free software maintained by the Tinyproxy project and contributors, distributed under the GNU General Public License, version 2 (GPL-2.0). This image bundles the unmodified Ubuntu archive package. SecureAnyCloud provides the packaging, the forward proxy hardening, the closed by default configuration, the per VM authentication, the self test tool, and 24/7 support with a guaranteed 24 hour response SLA.

SecureAnyCloud is not affiliated with or endorsed by the Tinyproxy project. Tinyproxy is used here only to identify the software.

Deploy on Azure

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

Need Help?

Email sales@secureanycloud.com for deployment help, configuration questions, or licensing questions.

Deploy on Azure

Launch Tinyproxy on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Tinyproxy. Select the SecureAnyCloud listing, choose Select, then choose Continue on the subscription summary.

Choose an instance type of m5.large or larger. Tinyproxy is very light, but m5.large is the tested recommendation. Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and a subnet with outbound internet access. Create or select a security group that allows inbound port 22 from your management network.

Select Launch instance. First boot initialization takes a few seconds after the instance state becomes Running and the status checks pass.

Run the following command to launch an instance from the SecureAnyCloud Tinyproxy Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens port 22 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --metadata-options "HttpTokens=required,HttpEndpoint=enabled" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=tinyproxy}]'

On first boot the image resolves this instance's addresses using the EC2 Instance Metadata Service (IMDSv2), so it works with HttpTokens=required enabled.

This step matters most, and it is deliberately left to you. The listing's recommended security group opens SSH only, so the proxy port is not reachable until you open it. Add one inbound rule for TCP 8888 and scope it to your own VPC or subnet CIDR, never to 0.0.0.0/0.

In the console, go to EC2 > Security Groups > your group > Inbound rules > Edit inbound rules > Add rule. Set Type to Custom TCP, Port range to 8888, and Source to Custom with your own VPC CIDR.

From the AWS CLI, replace <security-group-id> with your group and <your-vpc-cidr> with your own range:

aws ec2 authorize-security-group-ingress \
  --group-id <security-group-id> \
  --protocol tcp --port 8888 \
  --cidr <your-vpc-cidr>

Even if this rule is widened by mistake, the proxy still refuses a client from outside the private ranges. Step 7 proves it.

Connect as the ubuntu user. See the Connecting to your instance table above for other variants.

ssh ubuntu@<public-ip>

The message of the day prints the proxy endpoint and the key operational commands when you log in.

Check the service. First boot starts Tinyproxy after it generates this instance's proxy password and re-asserts the secure configuration.

systemctl is-active tinyproxy

Real output from a running instance:

active

Confirm that the proxy owns port 8888:

sudo ss -ltnp | grep -E ':8888'

Real output:

LISTEN 0 1024 0.0.0.0:8888 0.0.0.0:* users:(("tinyproxy",pid=6096,fd=3)) LISTEN 0 1024 [::]:8888 [::]:* users:(("tinyproxy",pid=6096,fd=3))

Read the whole security posture in one place. This command prints the access control and tunneling directives from the live configuration. It deliberately does not print the BasicAuth line that holds this instance's password:

sudo grep -E '^(Port|Allow|ConnectPort|DisableViaHeader|ViaProxyName) ' /etc/tinyproxy/tinyproxy.conf

Real output from a running instance:

Port 8888 Allow 127.0.0.1 Allow ::1 Allow 10.0.0.0/8 Allow 172.16.0.0/12 Allow 192.168.0.0/16 Allow fc00::/7 ViaProxyName "sac" DisableViaHeader Yes ConnectPort 443 ConnectPort 563

Because at least one Allow rule is present, every source that does not match one of those lines is denied. Confirm that there is no allow all rule anywhere:

if
sudo grep -qE '^[[:space:]]*Allow[[:space:]]+0\.0\.0\.0/0' /etc/tinyproxy/tinyproxy.conf; then echo "FAILED: an allow all rule is present" exit 1 fi echo "Confirmed: no allow all rule; every source outside the allow list is denied"

Real output:

Confirmed: no allow all rule; every source outside the allow list is denied

Run the single command that the image ships to exercise every lock against the running service. It starts a temporary local origin, makes four requests with a normal client, and checks what the proxy did with each one.

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

Real output from a running instance:

OK tinyproxy egress-control posture proven: allowed+authenticated 200, no-credential 407, wrong-credential 401, disallowed-source 127.0.0.2 403; deny-by-default ACL (loopback + RFC1918 only, no allow-all), per-instance BasicAuth, CONNECT limited to TLS ports

Each part of that line means the following:

Request Result What it proves

Allowed source, correct credentials HTTP 200 The proxy actually works

Allowed source, no credentials HTTP 407 Proxy authentication is enforced

Allowed source, wrong credentials HTTP 401 The credential is really checked

Source outside the allow list, correct credentials HTTP 403 The access control list denies before authentication is even considered

The same proof runs on every first boot, so an instance that cannot demonstrate it never reports itself ready.

Tinyproxy answers 401 Unauthorized when a client sends a wrong proxy credential. It answers 407 Proxy Authentication Required only when the client sends no credential at all. Both are refusals. The distinction is upstream behavior, not a configuration choice.

First boot generates a proxy password unique to this instance and writes it, with the proxy endpoint, to a root only file. Nothing secret ships inside the image, so this file is the only place the credential exists.

Print the non secret fields and confirm that the password line is present, without showing the password on your screen:

sudo grep -E '^PROXY_(USER|PRIVATE_HOST|PORT|ENDPOINT)=' /root/tinyproxy-credentials.txt echo "PROXY_PASSWORD lines present: $(sudo grep -c '^PROXY_PASSWORD=' /root/tinyproxy-credentials.txt)"
sudo stat -c '%n %a %U:%G' /root/tinyproxy-credentials.txt

Real output from a running instance:

PROXY_USER=sac PROXY_PRIVATE_HOST=172.31.90.248 PROXY_PORT=8888 PROXY_ENDPOINT=172.31.90.248:8888 PROXY_PASSWORD lines present: 1 /root/tinyproxy-credentials.txt 600 root:root

To see the password itself, read the whole file. It looks like this, with the password replaced by an example value:

# Tinyproxy egress-control forward proxy - credentials for THIS instance, generated on
# its first boot. They are unique to this instance; nothing is baked into the image.
# Keep this file secret (0600 root:root).
# PROXY_USER=sac PROXY_PASSWORD=<PROXY_PASSWORD> PROXY_HOST=203.0.113.10 PROXY_PRIVATE_HOST=172.31.90.248 PROXY_PORT=8888 PROXY_ENDPOINT=172.31.90.248:8888

PROXY_ENDPOINT uses the instance's private address on purpose. Clients elsewhere in your VPC should reach the proxy at that address.

Make a real outbound request through the proxy. The command reads the credential from the root only file at run time, so it never appears on screen:

PU=$(sudo grep '^PROXY_USER=' /root/tinyproxy-credentials.txt | cut -d= -f2-)
PP=$(sudo grep '^PROXY_PASSWORD=' /root/tinyproxy-credentials.txt | cut -d= -f2-)
curl -sS -o /dev/null -w 'authenticated request over HTTPS: HTTP %{http_code}\n' \
  --max-time 20 -x "http://$PU:$PP@127.0.0.1:8888" https://example.com/
curl -sS -o /dev/null -w 'authenticated request over HTTP: HTTP %{http_code}\n' \
  --max-time 20 -x "http://$PU:$PP@127.0.0.1:8888" http://example.com/

Real output from a running instance:

authenticated request over HTTPS: HTTP 200 authenticated request over HTTP: HTTP 200

The HTTPS request goes through a CONNECT tunnel on port 443, which is one of the two tunnel ports this image permits.

Now confirm that the same request without a credential is refused:

CODE=$(curl -sS -o /dev/null -w '%{http_code}' --max-time 20 -x http://127.0.0.1:8888 http://example.com/ 2>/dev/null) if [ "$CODE" = "407" ]; then echo "Confirmed: a request with no credentials was refused with HTTP 407" else echo "FAILED: expected HTTP 407 but observed HTTP $CODE" exit 1 fi

Real output:

Confirmed: a request with no credentials was refused with HTTP 407

On any host inside your VPC that the allow list covers, set the standard proxy environment variables. Replace USER and PASSWORD with the values from Step 8, and replace <proxy-private-ip> with the PROXY_PRIVATE_HOST value:

export http_proxy=http://USER:PASSWORD@<proxy-private-ip>:8888
export https_proxy=$http_proxy
export no_proxy=169.254.169.254,localhost,127.0.0.1 curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/

Keep 169.254.169.254 in no_proxy. The EC2 Instance Metadata Service must never be reached through a proxy.

For a system wide setting, most tooling also reads the same variables from /etc/environment. Package managers have their own settings. APT reads /etc/apt/apt.conf.d/, and dnf and yum read a proxy= line in their configuration file.

Run the exposure check that ships with the image. It enumerates every listening socket and fails closed if anything unexpected is bound to a non loopback address. It runs during the build and again immediately before the image is captured, and you can run it yourself at any time:

sudo /usr/local/sbin/tinyproxy-exposure-check.sh "22 8888"

Real output from a running instance:

--- non-loopback TCP listeners --- tcp 0.0.0.0:22 tcp 0.0.0.0:8888 tcp [::]:22 tcp [::]:8888 --- non-loopback UDP listeners --- udp 172.31.90.248%ens5:68 EXPOSURE_CHECK_OK (allowed tcp: 22 8888; allowed udp: 68 546)

Only SSH and the proxy port are reachable from the network. The UDP entry is the DHCP client.

Read the proxy log. Every request through the proxy is logged in one place, which is the point of routing egress through a single hop.

sudo tail -4 /var/log/tinyproxy/tinyproxy.log

Real output from a running instance:

CONNECT Jul 26 05:55:39.121 [6096]: Established connection to host "example.com" using file descriptor 7. INFO Jul 26 05:55:39.130 [6096]: Closed connection between local client (fd:6) and remote client (fd:7) CONNECT Jul 26 05:55:39.138 [6096]: Connect (file descriptor 6): 127.0.0.1 CONNECT Jul 26 05:55:39.142 [6096]: Request (file descriptor 6): GET http://example.com/ HTTP/1.1

Set LogLevel Connect in the configuration to log every request line, or LogLevel Warning to reduce the output.