Closed hcooper closed 1 year ago
Despite ufw not allowing port 8080 from the internet, Docker adds its own iptables rules to permit any exposed container ports.
ufw
This is a problem because we've been hit by bots directly on port 8080, which bypass protections the reverse proxy provides.
So this PR is the real fix - no longer expose the port.
On the internal network the reverse proxy can still access the web server fine on port 80.
~: iptables -L -n -t nat Chain DOCKER (2 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 RETURN all -- 0.0.0.0/0 0.0.0.0/0 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.19.0.5:80 <--- the bad line. DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:172.19.0.6:443 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:172.19.0.6:80 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22001 to:172.19.0.4:22
After rebuilding and redeploying the webserver docker image, this line of iptables goes away, and direct connections from the internet fail.
Looks good to me, except the commit author is “Your name”
Despite
ufw
not allowing port 8080 from the internet, Docker adds its own iptables rules to permit any exposed container ports.This is a problem because we've been hit by bots directly on port 8080, which bypass protections the reverse proxy provides.
So this PR is the real fix - no longer expose the port.
On the internal network the reverse proxy can still access the web server fine on port 80.
After rebuilding and redeploying the webserver docker image, this line of iptables goes away, and direct connections from the internet fail.