Selective security

Imagine a ZT network linking one or more ‘HQ’ sites and a number of satelites primarily for data gathering and system maintenance (ie full access). I am worried that a malicious user at a satelite site who is wrongly trusted with access to the satelite system could have complete communication with not only the other satelites but also HQ. I have seen a reference to a ‘whitelist’ but how would this work ? Could the satelite sites be, within the ZT configuration, classified as ‘untrusted’ and be unable to use any outward communication over the ZT network ?


You should be able to do that. Here’s is a link to a big document

The rules are low level and can be tricky to get right. Please test on a separate network :slight_smile:

There many different ways to get to the same results. Let us know what you’re trying and how you’re getting stuck.

Thanks. I had read that doc. - how does one assign a particular node as eg engineering or support ?

After you save the rules, there should be a “tags matrix” section just below the rules editor.

Thanks. I think I have the basis of a simple rules table which will allow unrestricted operations for the OPS etc people, but I am uncertain how to compose the rule to allow an unqualified site only what is necessary to facilitate the tunnel:

# Whitelist only IPv4 (/ARP) and IPv6 traffic and allow only ZeroTier-assigned IP addresses
not ethertype ipv4 	           # frame is not ipv4
and not ethertype arp 	  # AND is not ARP
and not ethertype ipv6 	  # AND is not ipv6
or not chr ipauth 	          # OR IP addresses are not authenticated

# Create a tag for which department someone is in
tag department
id 1000 			# arbitrary, but must be unique
default 100
enum 100 site
enum 200 ENG
enum 300 SUPPORT
enum 400 OPS

# Allow OPS or ENG or SUPPORT unrestricted, cripple all else
department OPS
or department ENG
or department SUPPORT

#  Now, how to drop all except that necessary to allow the tunnel …

# drop

To recap, OPS etc should be able to do everything just as before, but site (default) do nothing.
Many thanks

great. thanks. What can SITE devices do by default? Talk to each other? Or they only accept incoming connections from OPS/ENG/SUPPORT?

What protocols/apps need to be supported? UDP needs to be dealt with a little differently than TCP. Thanks.

Nothing, just accept incoming connections from OPS/ENG/SUPPORT eg:
SSH into SITE (with tunnel(s))
Connection to a TCP server app on the SITE device
Open simple configuration browser served on SITE device
and possibly send some UDP packets to a UDP port opened on the SITE device

  • definitely not talk to each other (or anyone else !!)

Here’s the simplest example I could come up with.

    break chr tcp_syn and not chr tcp_ack; # block creating new tcp connections

    tag udpserver id 1000
      default 0
      flag 0 yes

      ipprotocol udp
      and tor udpserver 1

    break ipprotocol udp;

    cap superuser id 1000 accept; ; # cap overrides break


The only gotcha is anyone can talk UDP with anything tagged “udpserver” (but not between each other). See:
Rules Engine | ZeroTier Documentation for more explanation.

Since zerotier creates an interface and address, you could additionally block things with iptables.

Fantastic, thank you. Works brilliantly (once I had discovered that tags must be lower-case !)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.