Selective security

Community Support
1

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 ?
Thanks

2

Hello!

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.

3

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

4

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

5

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
drop
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
accept
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

6

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.

7

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 !!)
8

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
    ;

    accept
      ipprotocol udp
      and tor udpserver 1
    ;

    break ipprotocol udp;

    cap superuser id 1000 accept; ; # cap overrides break

    accept;

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.

9

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

10

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