Hello,

I don't see how this is an issue, because Tor guards / middles only ever relay traffic, and exits already have sufficient REJECT rules:

reject 0.0.0.0/8:*
reject 169.254.0.0/16:*
reject 127.0.0.0/8:*
reject 192.168.0.0/16:*
reject 10.0.0.0/8:*
reject 172.16.0.0/12:*

I am just going to assume that CUPS opens these ports on your public interface?!

But your point of containerization is a always a good one, my Tor exit runs in a QEMU/KVM VM on our colocated server, which has nothing else running on it except for openvpn and systemd-resolved (using DNS-over-TLS and DNSSEC).

You should also have IPTables configured accordingly, and it's rules loaded on every boot automatically.

I attached an example bash script on how to configure IPtables, but please go through the entire script and see what it actually does, don't just apply it and lock yourself out of the system.

Note that this is for my system, so you will have to change ports and so on for your system, and remove useless lines.

Thank you,
George

There are some very significant recent CVEs out for CUPS, the unix
printing system.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=cups

It's an ideal moment to remind relay operators that a Tor node, relay or
bridge, should be a single-purpose internet server.

Running alternate internet services is a bad idea. The node should have
the minimum packages installed for the purpose of running a node. More
packages means more possible vulnerabilities.

Needless to say, a CUPS server listening on 631/tcp or 631/udp while
providing Tor access is a bad idea.

g

--
43C2 85B0 41B6 4AC1 0E02 2767 7092 AEB3 40B0 C804

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays