Privoxy is reachable on the VPN IP address from the internet

[henriquevcosta]

I've just noticed that I can reach privoxy if I go to http://<VPN IP>:8118.
The reason I noticed it is because after a while it started getting abused by external IPs. Is this something that could be filtered out by an iptables rule or is there a legitimate case to allow that incoming traffic? I'm guessing that my VPN provider has all ports open while the normal use case is to have a specific port forwarded, but I may be wrong...

I've removed the /config/privoxy directory and restarted the container to ensure that I hadn't mangled some config there, and the env variables to the container are (fetched from docker inspect):

"PGID=876",
"PUID=876",
"VPN_ENABLED=yes",
"VPN_USER=<redacted>",
"VPN_PASS=<redacted>",
"VPN_PROV=custom",
"VPN_CLIENT=<redacted>",
"STRICT_PORT_FORWARD=no",
"ENABLE_PRIVOXY=yes",
"ENABLE_AUTODL_IRSSI=no",
"DEBUG=false",
"LAN_NETWORK=192.168.0.0/16,172.16.0.0/20,172.17.0.0/20",
"TZ=Australia/Sydney",
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"HOME=/home/nobody",
"TERM=xterm",
"LANG=en_GB.UTF-8"

[henriquevcosta]

I added 2 rules at the top and so far it seems like both Privoxy and the qbittorrent UI are still working, and neither is accessible on the VPN IP (note: the qbittorrent UI wasn't accessible but I suspect that's not merit of the firewall).

iptables -I INPUT 1 -i tun0 -p tcp --dport 8080 -j DROP
iptables -I INPUT 1 -i tun0 -p tcp --dport 8118 -j DROP

I don't know a lot about iptables, I am under the impression that the typical approach is to have a default DROP and then ACCEPT rules before that. However... I thought that incoming traffic from the TUN interface should only be allowed to hit either the torrent listening port OR be for any established connection, but not wanting to introduce connection state tracking I felt I'd just block those 2 explicitly.

With this the VPN traffic can get to any open port, but there don't seem to be too many listening ports apart from those so it seems like an acceptable risk...

Do you think this makes sense as an approach going forward? I see as much traffic on the en0 interface from the VPN host as on the tun0 interface so I'm not 100% sure what I'm doing makes sense... or is that because the incoming VPN data first is coming from the VPN provider on en0 and then makes it into the tun0 interface with its proper source IP?

help?comments? thanks in advance!

Chain INPUT (policy DROP 12 packets, 5491 bytes)
 pkts bytes target     prot opt in     out     source               destination
    1    40 DROP       tcp  --  tun0   any     anywhere             anywhere             tcp dpt:http-alt
    7   448 DROP       tcp  --  tun0   any     anywhere             anywhere             tcp dpt:privoxy
 935K  701M ACCEPT     all  --  eth0   any     my-vpn-provider.host   anywhere
 5874 1358K ACCEPT     all  --  any    any     172.16.3.0/24        172.16.3.0/24
    0     0 ACCEPT     all  --  eth0   any     my-vpn-provider.host   anywhere
    0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:http-alt
    0     0 ACCEPT     udp  --  eth0   any     anywhere             anywhere             udp dpt:http-alt
    0     0 ACCEPT     tcp  --  eth0   any     192.168.0.0/16       172.16.3.0/24        tcp dpt:privoxy
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp echo-reply
 1004  169K ACCEPT     all  --  lo     any     anywhere             anywhere
 850K  650M ACCEPT     all  --  tun0   any     anywhere             anywhere

[dansonamission]

My tables look the same but can't access those ports using the vpn address. Tried a couple of port checkers online too.

[henriquevcosta]

Thanks for checking, could it be my VPN provider opening all ports vs yours being a bit more reasonable? My provider doesn't have a port forwarding functionality, it's just all open.

[dansonamission]

I just checked and the VPN provider I'm using doesn't offer any port forwarding. I'm not going to see the issue as the ports are closed at the provider, making my testing pointless :)

[binhex]

could it be my VPN provider opening all ports vs yours being a bit more reasonable?

This is pretty much the case, most VPN providers do NOT open all ports for security reasons, in fact a vast majority have all incoming ports closed, and a small fraction of those offer the ability to define permitted incoming ports (port forwarding), yes i could tie down which incoming ports are open but this adds a lot of complexity to the image, as i would then have to have a toggle to permit each service to be accessible or not via ENV VARS as some people will no doubt want to be able to connect to privoxy/qbittorrent// over the VPN.

My advise would be either to switch VPN provider or lock down privoxy:- https://www.privoxy.org/user-manual/config.html#ACLS

[henriquevcosta]

Thank you @binhex, do you think it's "safe" to map a privoxy config file into /config/privoxy/config or does the container modify the file during startup and I should inject the acl config in some other way?

[binhex]

simply edit the file /config/privoxy/config it's persistent and will not revert with image/container changes.

[henriquevcosta]

Excellent, thanks, I'll do that. I'll just close this issue, thank you again for the support.