3proxy Proxy Server 0.9.9.1

Option A: AWS Marketplace console

• Open the SecureAnyCloud Hardened WireGuard VPN & VPN, Proxy and Remote Access AMIs listing on AWS Marketplace and choose View purchase options, then Subscribe. One subscription covers every version in the listing.
• Once 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 3proxy Proxy Server 0.9.9.1 on Ubuntu 24.04, then choose your Region.
• Pick an instance type (m5.large recommended; the software charge is $0.04 per vCPU per hour) and your key pair.
• Security group: the listing's default group allows SSH (22) only. Restrict it to your own IP address. You will open the proxy ports to your clients in Step 5.
• Choose your VPC and subnet, leave the metadata defaults (the image already requires IMDSv2), then choose Launch.

Option B: AWS CLI

Run this on your own workstation. It creates a security group that allows SSH from your management address and the two proxy ports from your VPC only, then launches 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 3proxy \
  --description "3proxy HTTP and SOCKS 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 10.0.0.0/16
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 1080 --cidr 10.0.0.0/16
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=3proxy}]'

You do not need --metadata-options: the AMI already makes IMDSv2 required.

Connect 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 user and password, stores the password hash for 3proxy, records the instance's private IP, starts the proxy and runs the self-test. The details are in /root/3proxy-credentials.txt, which only root can read. Print everything except the password line with this command:

sudo grep -v '^proxy\.pass=' /root/3proxy-credentials.txt

# 3proxy 0.9.9.1 on Ubuntu 24.04 (sac AWS Marketplace image) - THIS instance.
# The user and password below were generated on this instance's first boot and exist nowhere else # (3proxy itself keeps only a salted hash of the password, in /etc/3proxy/passwd). proxy.user=sac22bff3 proxy.host=172.31.83.46 proxy.http_port=3128 proxy.socks_port=1080 proxy.http_endpoint=172.31.83.46:3128 proxy.socks_endpoint=172.31.83.46:1080 # # NOT AN OPEN PROXY: both ports require the user and password above (HTTP 407 / SOCKS5 refusal # without them), only localhost and private (RFC1918) clients are served, and the proxy refuses to # connect to loopback, private, link-local (instance metadata) and multicast destinations. # # NETWORK ACCESS: the listing security group opens SSH only. To serve clients in your VPC, add # inbound rules for TCP 3128 and/or 1080 ONLY from your VPC CIDR or client security group - never # 0.0.0.0/0 - and point clients at the PRIVATE IP above. Or use an SSH tunnel: # ssh -i <key.pem> -N -L 3128:127.0.0.1:3128 -L 1080:127.0.0.1:1080 ubuntu@<public-ip> # # Test from a client: # curl -x http://sac22bff3:<password>@172.31.83.46:3128 https://example.com/ -sS -o /dev/null -w '%{http_code}\n' # curl -x socks5h://sac22bff3:<password>@172.31.83.46:1080 https://example.com/ -sS -o /dev/null -w '%{http_code}\n' # Self-test:
sudo /usr/local/sbin/3proxy-roundtrip.sh
# User guide: https://secureanycloud.com/stacks/3proxy-proxy-server-0-9-9-1/

Your user name (SecureAnyCloud followed by six hex digits) and private IP will differ. Print the password itself only when you need it, with sudo sed -n 's/^proxy\.pass=//p' /root/3proxy-credentials.txt; it is 40 or more characters long.

Run these commands to confirm that 3proxy.service is active, first boot has completed, the binary is release 0.9.9.1, and 3proxy is the process listening on ports 1080 and 3128. The security group and the access list decide who can actually use those ports.

systemctl is-active 3proxy.service 3proxy-firstboot.service
sudo grep -ao '3proxy-0\.9\.9\.1' /usr/local/bin/3proxy | head -1 sudo ss -Htlnp '( sport = :3128 or sport = :1080 )'

active active 3proxy-0.9.9.1 LISTEN 0 26 0.0.0.0:1080 0.0.0.0:* users:(("3proxy",pid=8306,fd=3)) LISTEN 0 26 0.0.0.0:3128 0.0.0.0:* users:(("3proxy",pid=8306,fd=7))

Do not run 3proxy without a configuration file to check its version. With no argument it waits for a configuration on standard input.

Run the shipped self-test to check the whole security posture in a few seconds. It needs no internet access. It starts a small test web server on a documentation address (192.0.2.80, TEST-NET-1) on the loopback interface, and on 127.0.0.1 and the private IP. It then proves each of these points:

• The only non-loopback listening ports are 22, 1080 and 3128.
• Over HTTP, an anonymous request and a wrong password both get 407, and the instance's password gets 200 with the test page.
• Over SOCKS5, no authentication and a wrong password are refused, and the instance's password reaches the test page.
• Loopback, the private IP, a host name that resolves to 127.0.0.1 and the instance metadata service are all refused by the access list, while the same metadata service answers the instance shell directly.

sudo /usr/local/sbin/3proxy-roundtrip.sh

round-trip OK: listening tcp 22 1080 3128 ; HTTP anonymous 407, wrong password 407, per-instance password 200 (body proxied); SOCKS5 no-auth/wrong refused, authenticated reaches the origin; loopback, private, hostname-to-loopback and instance-metadata destinations refused by the ACL on both (HTTP 403), HTTP CONNECT to a non-TLS port 403; host-shell metadata control 200

Add inbound rules for TCP 3128 (HTTP) and/or TCP 1080 (SOCKS) to the instance's security group, only from the networks that need the proxy (your VPC CIDR, a subnet, or a client security group). Never open them to 0.0.0.0/0. Even if you did, the access list would refuse every public source, but the rule keeps the ports private at the network edge as well:

aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 3128 --cidr <vpc-cidr>
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 1080 --cidr <vpc-cidr>

Then point clients at the proxy's private IP (proxy.host in the credentials file). On a Linux client, set the standard proxy variables with the user and password from Step 2:

export http_proxy="http://<PROXY_USER>:<PROXY_PASS>@<PROXY_HOST>:3128"
export https_proxy="$http_proxy"
export no_proxy="localhost,127.0.0.1,169.254.169.254" curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/

Keep 169.254.169.254 in no_proxy on the clients, so each client reads its own instance metadata directly (the proxy would refuse it). For SOCKS-aware tools, use socks5h://<PROXY_USER>:<PROXY_PASS>@<PROXY_HOST>:1080; the h makes the proxy resolve host names, so its destination rules see the real address.

Using the proxy from your workstation through SSH

To use the proxy from a machine outside the VPC without opening 3128 or 1080 at all, forward them over SSH and point your browser or tools at 127.0.0.1:3128 or 127.0.0.1:1080 (requests then reach 3proxy from 127.0.0.1, which the access list serves; the password is still required):

ssh -i ~/.ssh/my-key-pair.pem -N -L 3128:127.0.0.1:3128 -L 1080:127.0.0.1:1080 ubuntu@<public-ip>

On the instance, send these requests to see authentication at work on both ports. Without credentials or with a wrong password, you get 407 over HTTP and curl exit 97 (a SOCKS refusal) over SOCKS. With the instance's credentials, requests succeed over plain HTTP, over HTTPS through CONNECT, and over HTTPS through SOCKS5.

The credentials reach curl on standard input (-K -), so they never appear in a process listing or your shell history.

PU="$(sudo sed -n 's/^proxy\.user=//p' /root/3proxy-credentials.txt)" PP="$(sudo sed -n 's/^proxy\.pass=//p' /root/3proxy-credentials.txt)" curl -s -o /dev/null -w 'no credentials: HTTP %{http_code}\n' -x http://127.0.0.1:3128 http://example.com/ printf 'proxy-user = "%s:wrong-password"\n' "$PU" | curl -K - -s -o /dev/null -w 'wrong password: HTTP %{http_code}\n' -x http://127.0.0.1:3128 http://example.com/ printf 'proxy-user = "%s:%s"\n' "$PU" "$PP" | curl -K - -s -o /dev/null -w 'HTTP proxy, http: HTTP %{http_code}\n' -x http://127.0.0.1:3128 http://example.com/ printf 'proxy-user = "%s:%s"\n' "$PU" "$PP" | curl -K - -s -o /dev/null -w 'HTTP proxy, https: HTTP %{http_code}\n' -x http://127.0.0.1:3128 https://example.com/ printf 'proxy-user = "%s:%s"\n' "$PU" "$PP" | curl -K - -s -o /dev/null -w 'SOCKS5 proxy, https: HTTP %{http_code}\n' -x socks5h://127.0.0.1:1080 https://example.com/ curl -s -o /dev/null -w 'SOCKS5, no credentials: curl exit %{exitcode}\n' -x socks5h://127.0.0.1:1080 https://example.com/ || true

no credentials: HTTP 407 wrong password: HTTP 407 HTTP proxy, http: HTTP 200 HTTP proxy, https: HTTP 200 SOCKS5 proxy, https: HTTP 200 SOCKS5, no credentials: curl exit 97

Inspect the rules with the commands below. 3proxy checks them top to bottom and the first match wins: authentication, then the destinations that are never served, then the abuse limits, then the one allow for this instance's user from private sources, then deny *. Only root and the proxy3 group can read the files that hold the user and the password hash.

sudo grep -E '^(users|auth|deny|allow|proxy|socks) ' /etc/3proxy/3proxy.cfg
sudo stat -c '%a %U:%G %n' /etc/3proxy/3proxy.cfg /etc/3proxy/passwd /etc/3proxy/allowed-users /root/3proxy-credentials.txt
sudo sed -E 's/(CR:\$3\$)[^$]+\$.*/\1<salt>$<hash>"/' /etc/3proxy/passwd

users $/etc/3proxy/passwd auth strong deny * * 0.0.0.0/8,10.0.0.0/8,100.64.0.0/10,127.0.0.0/8,169.254.0.0/16,172.16.0.0/12,192.168.0.0/16,224.0.0.0/3,168.63.129.16/32 deny * * ::/128,::1/128,::ffff:0:0/96,fc00::/7,fd00::/8,fe80::/10,ff00::/8 deny * * * 25 deny * * * 1-442,444-562,564-65535 HTTPS deny * * * * BIND,UDPASSOC allow $/etc/3proxy/allowed-users 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 deny * proxy -a -4 -i0.0.0.0 -p3128 socks -4 -i0.0.0.0 -p1080 640 root:proxy3 /etc/3proxy/3proxy.cfg 640 root:proxy3 /etc/3proxy/passwd 640 root:proxy3 /etc/3proxy/allowed-users 600 root:root /root/3proxy-credentials.txt "sac22bff3:CR:$3$<salt>$<hash>"

proxy -a also removes the Via and X-Forwarded-For headers, so the sites your clients visit do not learn their private addresses.

Request the instance metadata service, loopback, the instance's own private IP and a host name that resolves to loopback (localhost), using the correct password. The access list refuses all of them with HTTP 403, while the metadata service still answers the instance shell directly. The systemd metadata block sits behind the access list on both units:

PU="$(sudo sed -n 's/^proxy\.user=//p' /root/3proxy-credentials.txt)" PP="$(sudo sed -n 's/^proxy\.pass=//p' /root/3proxy-credentials.txt)" PH="$(sudo sed -n 's/^proxy\.host=//p' /root/3proxy-credentials.txt)" for url in http://169.254.169.254/latest/meta-data/ http://127.0.0.1:22/ "http://${PH}:22/" http://localhost:22/; do printf 'proxy-user = "%s:%s"\n' "$PU" "$PP" | curl -K - -s -m 10 -o /dev/null -w "%{http_code} ${url}\n" -x http://127.0.0.1:3128 "$url" || true done curl -s -m 5 -o /dev/null -w 'metadata from the shell: HTTP %{http_code} (IMDSv2 token request)\n' -X PUT -H 'X-aws-ec2-metadata-token-ttl-seconds: 60' http://169.254.169.254/latest/api/token systemctl show -p IPAddressDeny 3proxy.service 3proxy-firstboot.service

403 http://169.254.169.254/latest/meta-data/ 403 http://127.0.0.1:22/ 403 http://172.31.83.46:22/ 403 http://localhost:22/ metadata from the shell: HTTP 200 (IMDSv2 token request) IPAddressDeny=fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32 IPAddressDeny=fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32

See the refusal of a public source for yourself. This block briefly adds a documentation-range address (192.0.2.88, TEST-NET-1) to the loopback interface, sends a request from it with the correct password, and removes the address again. 3proxy answers 403 because the source is not private. The same request from 127.0.0.1 succeeds:

PU="$(sudo sed -n 's/^proxy\.user=//p' /root/3proxy-credentials.txt)" PP="$(sudo sed -n 's/^proxy\.pass=//p' /root/3proxy-credentials.txt)"
sudo ip addr add 192.0.2.88/32 dev lo printf 'proxy-user = "%s:%s"\n' "$PU" "$PP" | curl -K - -s -o /dev/null -w 'from 192.0.2.88 (public): HTTP %{http_code}\n' --interface 192.0.2.88 -x http://192.0.2.88:3128 http://example.com/ printf 'proxy-user = "%s:%s"\n' "$PU" "$PP" | curl -K - -s -o /dev/null -w 'from 127.0.0.1 (local): HTTP %{http_code}\n' --interface 127.0.0.1 -x http://127.0.0.1:3128 http://example.com/
sudo ip addr del 192.0.2.88/32 dev lo

from 192.0.2.88 (public): HTTP 403 from 127.0.0.1 (local): HTTP 200

3proxy.service only starts once first boot has written /var/lib/sac/data/3proxy-ready, and its start-up check (ExecStartPre, run as root) re-reads the configuration every time. Both units carry the metadata block drop-in. The request log records one line per request (time, service, result code, user, client, destination and bytes), never a password or a URL:

systemctl cat 3proxy.service | grep -E '^(ConditionPathExists|ExecStartPre|ExecStart|User|IPAddressDeny)=' ls /etc/systemd/system/3proxy.service.d/ /etc/systemd/system/3proxy-firstboot.service.d/
sudo bash -c 'tail -n 3 /var/log/3proxy/3proxy.log*' | cut -c1-100

ConditionPathExists=/var/lib/sac/data/3proxy-ready User=proxy3 ExecStartPre=+/usr/local/sbin/3proxy-preflight.sh ExecStart=/usr/local/bin/3proxy /etc/3proxy/3proxy.cfg IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128 /etc/systemd/system/3proxy-firstboot.service.d/: 50-sac-imds-deny.conf /etc/systemd/system/3proxy.service.d/: 50-sac-imds-deny.conf 1792453852.288 PROXY.3128 00001 sac22bff3 127.0.0.1:48984 0.0.0.0:0 0 0 1792453861.226 PROXY.3128 00001 sac22bff3 192.0.2.88:58532 0.0.0.0:0 0 0 1792453861.276 PROXY.3128 00000 sac22bff3 127.0.0.1:54500 172.66.147.243:80 98 933

Result code 00000 is a completed request and 00001 a request the access list refused. The log rotates daily (3proxy.log.YYYY.MM.DD) and keeps 30 days. The start-up check, /usr/local/sbin/3proxy-preflight.sh, refuses to start 3proxy if auth strong is missing or weakened, if the loopback, private or link-local destination denies or the final deny * are gone, if an allow line serves any user or the whole internet, if the password file does not hold exactly one $3$ hash for the configured user, or if another service (the admin web interface, a port mapper, a DNS proxy) is added. If you deliberately want a different policy, edit that script rather than removing the check.

Edit /etc/3proxy/3proxy.cfg, restart 3proxy and run the self-test again (sudo systemctl restart 3proxy && sudo /usr/local/sbin/3proxy-roundtrip.sh). Common changes:

• Serve another of your own client ranges that is not RFC 1918 (for example a carrier-grade NAT range on a VPN): add it to the source list of the allow line, never 0.0.0.0/0:

allow $/etc/3proxy/allowed-users 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10

• Let clients reach one internal service through the proxy (for example an internal package mirror): add a specific allow line for that address and port above the destination deny lines. Keep it as narrow as possible and never allow 169.254.0.0/16:

allow $/etc/3proxy/allowed-users 10.0.0.0/8 10.0.5.20 443

• Allow only a list of destination domains: replace the allow line with one that names the hosts (wildcards at the start or end are allowed), for example allow $/etc/3proxy/allowed-users 10.0.0.0/8 *.amazonaws.com,example.com.

To issue a new user and password, run first boot again. It generates new credentials, rewrites the hash and the credentials file, restarts 3proxy and runs the self-test. The old credentials stop working immediately:

sudo rm /var/lib/sac/data/3proxy-firstboot.done
sudo systemctl start 3proxy-firstboot.service
sudo grep -v '^proxy\.pass=' /root/3proxy-credentials.txt

Update your clients with the new values. The new password is generated and hashed inside the first-boot unit, so it never appears on a command line or in /var/log/auth.log.

• Keep TCP 3128 and 1080 open only to the networks that need the proxy, and TCP 22 only to your management addresses. If your clients only need one protocol, open only that port.
• Keep auth strong and the destination denies. The start-up check enforces them; they are what make a mis-set security group harmless.
• Restrict destinations (Step 11) if the proxy is the only egress for a private subnet.
• Ship /var/log/3proxy/ to your log platform.
• Leave unattended security upgrades on, and reboot after kernel updates.