Default block still allows ping and ssh

ACL (Access Control Lists)
#1

hello and thanks.

in the policy editor, i have commented out the default accept rule.
there are no accept rules at all yet ping/ssh still work?

here is the entire json file

{
  // Declare convenient hostname aliases to use in place of IP addresses.
  "Hosts": 
  {
    "en08":      "xxx.xxx.xxx.xxx",
    "pi4":       "xxx.xxx.xxx.xxx",
     "server02": "xxx.xxx.xxx.xxx"
  }
  // Access control lists.
//  "ACLs": 
//  [  // Match absolutely everything. Comment out this section if you want to define specific ACL restrictions.
//    { "Action": "accept", "Users": ["*"], "Ports": ["*:*"] }
//  ]
}

image

and as a new user i cannot post more than one image.
the image i wanted to post, shows the service for the pi4, and if click the circle, i get a pop-up
“who can access this service?
this service is not accessible to any users in your network.”

and i really am surprised that there is not a simple web gui to hide the complex and somewhat scary json
and to have a way to auto-create those test rules.

thanks much,

#2

Can you please email all these details with all images you wanted to share on support@tailscale.com ?

Usually, if you own that node you will be allowed to access those without any permission unless you tag those nodes and give explicit access permissions.

#3

i sent that email,

as an update, still having the problem even with this

image

also, another node, pi4, can ping server02

#4

sorry, i am confused, i thought tailscale uses a default deny.

"There is no way to explicitly reject connections. Instead, no connections are allowed unless granted by an "accept" rule

#5

Regular ACLs are applied to Users and whether that User is allowed to connect. Default deny means that a User is not allowed to connect to anything owned by other Users unless there is an ACL allowing it.

Tags ABAC, RBAC, access controls (ACLs), and restricted security policies · Tailscale are a way to dissociate a device from the User who created it. Now it is no longer associated with a User, access is controlled by the Tag. If there is no ACL allowing access to that Tag, then it will be denied.

#6

thanks,

normally, if there is some syntax problem, i get this with the line/col of the issue.
Error: line 1 col 2: invalid character 'd' looking for beginning of object key string

from that link you shared, i copy and pasted the example and i also pasted the text below.
in both cases i get Error: parser: json: cannot unmarshal string into Go value of type policy.Policy
please advise?

"TagOwners": {
	"tag:pi4": [
		"xxx@hotmail.com",
	],
}
#7

It is expecting each of those blocks to be inside the top level JSON structure.

{
  "TagOwners": {
	"tag:pi4": [
		"xxx@hotmail.com",
	],
  },
  "Groups": {
	"group:example": [
		"user1@example.com",
		"user2@example.com",
	],
  },
}
#8

It’s default deny with the exception of you not defining ACLs at all. If the “ACLs” key is not defined in the JSON, then everything is permitted.

If you write:

    {"ACLs": []}

… the nothing is permitted.

But if you write:

    {"ACLs": null}

or

    {}

… then everything is permitted.

#9

thanks much, spent many hours on this and got not no where…

  • tailscale is default-allow.
  • default-deny can enabled using with {"ACLs": []}

i always start with default-deny and add to that.

it seems that

  • my user has full access to all ports on all nodes. not liking that.
  • any node seems able to access any open port on any other node, not very secure.

i am trying to create rule(s), that allow two nodes/hosts to connect to each other without using a user.
much like any basic firewall rule.

thanks,
david

#10

Hmm, there’s some confusing stuff above. I think we should remove whatever feature causes default-allow when the ACLs section is missing. That’s not a common thing to do, but it’s still risky to have it fall back in this way. Filed https://github.com/tailscale/tailscale/issues/2799 for this.

Also, someone suggested above that connections between two of a user’s own devices are not affected by ACLs. That’s not true. ACLs affect all connections incoming over Tailscale.

If you try to reach the Tailscale IP of same device you’re on, without traversing the Tailscale network, you might not be restricted by ACLs.

Anyway, once you have an empty set of ACL rules, you could write rules referring to specific IP addresses (not recommended) or using ACL Tags (the recommended approach). So you could have tag:api-client and tag:api-server, and write rules that allow any device tagged as tag:api-client to initiate connections to tag:api-server, but not vice versa.

Sorry for the confusion.

1 Like
#11

hello and thanks,

i am glad default-allow issue will get fixed.
fwiw, i always test using the simplest config as possible and build up from that.

i could not find complete policy example, on tailscale website or on the internet.
to allow one node to ssh into another node.
please, can you share an example?

thanks,

#13

I might be missing something but your ACL is set to ACCEPT not DENY

#14

I believe in his example the default DENY rule should be applied implicitly, so only packets matching his one ACCEPT rule should pass.

#16

to all, this is an example for a node to node rules.

once again, the mistake i made is with basic json syntax, super unfriendly for end-users.
really surprised tailscale does not have a simple webpage to hide the json file.
and the different syntax for Hosts and ACL, only makes it more confusing.

anyhoo, here is the policy

{ 
    "Hosts": {
      "en08":     "100.101.234.28", 
      "pi4":      "100.102.244.119", 
      "server02": "100.88.213.100"},
    "ACLs": [
      { "Action": "accept", "Users": ["en08"],     "Ports": ["pi4:22"]},
      { "Action": "accept", "Users": ["en08"],     "Ports": ["server02:3389"]},
      { "Action": "accept", "Users": ["server02"], "Ports": ["pi4:22"]}]
}
#17

Glad you got it working, I think the confusion here is from a networking / firewall POV, you’d do your allow rules first then deny all last, I’ve not needed to use ACLs yet but good to know for the future!

#18

thanks, i got it working but way too painful to get there.

the TS rules are similar to a router firewall rule.
default deny and need to add allow rules.
no confusion about that.

the problem once again is dealing with terrible json syntax, the different json syntax for Hosts and ACLs and lack of webgui.

TS will accept this policy since it is valid json syntax but not valid for TS policy use.
en08 CANNOT ssh into pi4

    "ACLs": [
      { 
          "Action": "accept", "Users": ["en08"], "Ports": ["pi4:22"],
          "Action": "accept", "Users": ["en08"], "Ports": ["server02:*"]
      }
    ]

this policy en08 CAN ssh into pi4

  "ACLs": [
      {"Action": "accept", "Users": ["en08"], "Ports": ["pi4:22"]},
      {"Action": "accept", "Users": ["en08"], "Ports": ["server02:*"]}
   ]
#19

That first example where the node cannot ssh isn’t valid JSON. The object in the array is delineated by the curly brace on line two and completed on line 5, and in between you duplicate definitions for the Action, Users, and Ports properties of the object. My guess is that their huJSON parser must be using the second definitions to overwrite the first, thus no access.

The second example is correct because the individual ACL objects are defined independently.

#20

i have opend a issue about it.
https://github.com/tailscale/tailscale/issues/2807

see here that ts accepts the syntax…

image
image680Ă—583 13.8 KB

#21

Just following the documentation, I made my ACL rules, you could simplify your setup a lot.

The rules on this screenshot assume you want en08 to access pi4 at port 22and server02 at any port.

So you could just use this for the latest screenshot:

{ 
    "Hosts": {
      "en08":  "100.101.234.28", 
      "pi4":  "100.102.244.119", 
      "server02": "100.88.213.100"},
    "ACLs": [
    { "Action": "accept", 
      "Users": ["en08"], 
      "Ports": ["pi4:22", "server02:*"]
    
    },
]
}

And this for the rules you mentioned earlier:

{ 
    "Hosts": {
      "en08":  "100.101.234.28", 
      "pi4":  "100.102.244.119", 
      "server02": "100.88.213.100"},
    "ACLs": [
    { "Action": "accept", 
      "Users": ["en08", "server02"], 
      "Ports": ["pi4:22"]
    
    },
    { "Action": "accept", 
      "Users": ["en08"], 
      "Ports": ["server02:3389"]
    
    },
]
}

This is easier to understand and easier to modify and replicate without adding redudancy, the way you’ve writing it, if you need to access 10 hosts, you would add 10 lines, instead of just declaring those hosts on the same rule.

#22

thanks, but from a security audit perspective,
if i submitted your setup for approval, it would be rejected.

for each rule, one source, one dest, one set of ports on one line of text