Hi,
How does a usable ipset (hash:ip,port) look like, so that it is a whitelist for in/out tcp connections? *Everything* else from/to the outside world is assumed to be dropped. (DNS too).
* dir auths from src/or/auth_dirs.inc * fallback dirs from scripts/maint/fallback.whitelist * current guard relays (parsed from a consensus file)
anything else?
Bonus question: how would you write this whitelist in iptables rules, assuming you have the complete ipset?
thanks
martin
On Tue, May 08, 2018 at 04:45:58PM +0200, Martin Kepplinger wrote:
How does a usable ipset (hash:ip,port) look like, so that it is a whitelist for in/out tcp connections? *Everything* else from/to the outside world is assumed to be dropped. (DNS too).
- dir auths from src/or/auth_dirs.inc
- fallback dirs from scripts/maint/fallback.whitelist
- current guard relays (parsed from a consensus file)
anything else?
There isn't really a standard port for the ORPort or the DirPort. All kinds of ports are used for this. For example, you could only allow port 443 and you would be good to go, just not for all relays.
In theory, you could create a giant iptables ruleset for every relay out there, which you would have to update all the time, because it changes every day. I think that it is a more sensible approach if you configure a couple of bridges on your clients and only allow these IP:Port combinations. This would be a wiser approach if you aim for a minimum of allowed connection types.
On 2018-05-08 16:59, Jonathan Marquardt wrote:
On Tue, May 08, 2018 at 04:45:58PM +0200, Martin Kepplinger wrote:
How does a usable ipset (hash:ip,port) look like, so that it is a whitelist for in/out tcp connections? *Everything* else from/to the outside world is assumed to be dropped. (DNS too).
- dir auths from src/or/auth_dirs.inc
- fallback dirs from scripts/maint/fallback.whitelist
- current guard relays (parsed from a consensus file)
anything else?
There isn't really a standard port for the ORPort or the DirPort. All kinds of ports are used for this. For example, you could only allow port 443 and you would be good to go, just not for all relays.
In theory, you could create a giant iptables ruleset for every relay out there, which you would have to update all the time, because it changes every day.
That's not really a problem with ipset. My list above results in about 2800 entries (ip,port combinations). I could easily update it hourly. Starting tor-browser doesn't yet work though, and while I might simply still get iptables rules wrong, I thought I'd ask if I miss addresses.
Allowing local connections is necessary for the control port, and not an issue. It's about remote tcp connections.
I think that it is a more sensible approach if you configure a couple of bridges on your clients and only allow these IP:Port combinations. This would be a wiser approach if you aim for a minimum of allowed connection types.
Possibly. I clearly want to try this approach though: not running Tor myself, just looking at the network. Again, size doesn't matter. Do I miss something?
thanks martin
On Wed, May 09, 2018 at 10:18:10AM +0200, Martin Kepplinger wrote:
On 2018-05-08 16:59, Jonathan Marquardt wrote:
On Tue, May 08, 2018 at 04:45:58PM +0200, Martin Kepplinger wrote:
How does a usable ipset (hash:ip,port) look like, so that it is a whitelist for in/out tcp connections? *Everything* else from/to the outside world is assumed to be dropped. (DNS too).
- dir auths from src/or/auth_dirs.inc
- fallback dirs from scripts/maint/fallback.whitelist
- current guard relays (parsed from a consensus file)
anything else?
There isn't really a standard port for the ORPort or the DirPort. All kinds of ports are used for this. For example, you could only allow port 443 and you would be good to go, just not for all relays.
In theory, you could create a giant iptables ruleset for every relay out there, which you would have to update all the time, because it changes every day.
That's not really a problem with ipset. My list above results in about 2800 entries (ip,port combinations). I could easily update it hourly. Starting tor-browser doesn't yet work though, and while I might simply still get iptables rules wrong, I thought I'd ask if I miss addresses.
Allowing local connections is necessary for the control port, and not an issue. It's about remote tcp connections.
Well, you really only need to allow TCP connections to all the guard nodes on their ORPorts and the connections to the fallback dir. That's it.
Maybe check your firewall's logs?
tor-relays@lists.torproject.org
-
Jonathan Marquardt -
Martin Kepplinger