Page 1 of 1

Read-only Dude access - how?

Posted: Thu Mar 14, 2024 9:14 am
by Bomber67
I am managing the network for a customer of mine.
Technican of this company (and myself) uses Dude for monitoring the network.
Now one employee needs read only access to Dude, specifically for simple monitoring one part of the network (devices up/down, traffic flow on interfaces)

I have set up a user group with minimum privileges and added user, and he can view the network without the ability to change anything in The Dude
So far so good.

But Dude access requires Winbox access...permissions therefore includes Read and Winbox.. and once inside Dude he can Winbox any device via Rightclick -> Tools -> Winbox.
As you know user/pass is stored inside each device in Dude.

So how do I go about to provide him with a real read-only solution?
Is it somehow possible to disable right-click menu for specific users?
And if it is, he can then still Winbox the Dude server manually, as he has the password for it..

So what is the solution?
Will I have to setup a separate Dude server for him, without the Winbox tool?

Re: Read-only Dude access - how?

Posted: Fri Mar 22, 2024 8:08 pm
by ITsTEXnical
Upgrade your Dude server an option? Winbox has been removed from the tools menu available to Dude client users in the newest versions.

Re: Read-only Dude access - how?

Posted: Fri Mar 22, 2024 8:22 pm
by Amm0
Well removing the Tool is one approach, but doesn't really solve the undesired privilege escallation. It's still a variable in the system...

About only thing you can do is ALSO use a read-only account on the devices being monitored. So Dude itself does not have write access, thus when password is "passed-through" the Tools, it's not one with write access.

Personally, this is generally a good idea to avoid having a full admin passwords in more places (e.g. Dude's DB). See SolarWinds. Now using a read-only account on a Dude Device may limit what a full admin logged into the Dude can do (e.g. disable/enable/add/delete ip address, leases, etc.). – since AFAIK most actions go through the stored device's credentials, not the person logged into the Dude.

Another approach is directing the "read-only admin" to use webfig. In the router's main web UI with a Dude server running on it, you can see the map and devices. Not full info, but maybe just the map is enough for the readonly users vs. using the native windows app.

Re: Read-only Dude access - how?

Posted: Sat Mar 23, 2024 12:22 am
by ITsTEXnical
Some tools, like ping and trace, actually have 'write' access of necessity, even for a read-only user login. This is even documented in the Mikrotik RouterOS user manual in their new Spaces site. But no, the read-only user login does not have the ability to change the IP addresses or layouts in your monitoring maps, even though the map devices do, as you say, themselves have admin credentials to do the basic monitoring.

Some parts of managing the Dude Server application can only be done on the device hosting the application, I grant you that. But why give a read-only user access to the hosting device? They just need the Dude Client app and a read-only login for that I'm guessing.

I wondered what privileges you consider basic minimum to give a read-only user group. I do not include Winbox privilege to my read-only group. And as I said, the tool is no longer present in the Dude client for any user, admin or otherwise. You actually have to add Winbox login as a custom tool if you desire that for your admins (I sure do). Adding it is not a straightforward process, and I've not seen anyone document how to do it.

Hope I'm not missing some nuance in what you're saying and that this helps. I find it pretty easy to misinterpret the context of a given Wiki statement sometimes.

Re: Read-only Dude access - how?

Posted: Sat Mar 23, 2024 12:35 am
by ITsTEXnical
You are right about the stored devices cedentials - they are used by the devices to communicate with each other. Has nothing to do with the user login to the Dude Client - THAT can be read-only (user cannot make changes to the map devices or other elements).

Yes, Webfig is available via the Web tool in the map, but the user has the same read-only privileges in the target router, provided it even has an equivalent read-only user account configured.

Re: Read-only Dude access - how?

Posted: Sat Mar 23, 2024 1:19 am
by Amm0
Did not mean to be confusing.

While no user can view the password on from the Device dialog box. And you're likely right that the "writable" RouterOS stuff for a Device, use the logged in user. I think OP's point is Dude uses variables in various points, including Tools, but elsewhere too. And one of those variables is [Device.Password].

I'm not sure why you're saying "Tools" is removed. I see it on both V6 and V7 Dude's. Importantly, if you look at "Dude" under "Tools" it will invoke itself using the stored [Device.Password], not the logged in user. So that be one way for a read-only user to gain privilege escalation if the device's creds used anything with greater permissions than the logged on user. Removing the Dude from Tool menu avoid that one. And I don't know of other places.

Mikrotik does not document or claim support for "read only users" – they have policies which do what they say, even if not what you want. So one man's "privilege escalation" bug is another man's "policy delegation" feature, so wouldn't call this a security issue.

BUT... the security model does become simple if the Dude "read only" user's policy matched the device user's policy. e.g. BOTH using same "read" user group on RouterOS. There can be no privilege escalation if using the same policy.

And similar can happen "Web" tool for non-routers with saved username/password if those allowed some greater access to some Web admin.... Or, if SNMP profile used a writable community name.... Etc.

As noted earlier, read-only users are WAY easier if you limit them to webfig. There you also have skins and the "status page" feature if goal in Dude access is some dashboard for a customer. To me that's a better approach, since RouterOS policies are NOT very fine grained.

Re: Read-only Dude access - how?

Posted: Sat Mar 23, 2024 1:39 am
by ITsTEXnical
Hi Amm0. To clarify, I meant that the Winbox tool specifically has been removed from Tools in the newer Dude client versions, not that the whole tool list has been removed.

Re: Read-only Dude access - how?

Posted: Sat Mar 23, 2024 8:29 pm
by Amm0
Hi Amm0. To clarify, I meant that the Winbox tool specifically has been removed from Tools in the newer Dude client versions, not that the whole tool list has been removed.
That makes more sense.

To the original question is you'd have to make sure NOTHING uses "[Device.Password]". And a "seperate" Dude client isn't going to help — tools are defined on the server-side shared by all users AFAIK.

So removing winbox, if present be one. But even newest, the "Dude" under Tool also could be one way for a "read only" user to access a router with Dude installed:
dude.exe --contect [Device.FirstAddress] [Device.UserName] [Device.Password]

specifically itself. So that need to be removed as well for "read only" Dude user.

But overall, the security model isn't setup for delegated access is my main point. So the notion of a "read only" user is not defined & the underlying policy system isn't flexible nor particularly fine-grained.

Re: Read-only Dude access - how?

Posted: Mon Apr 15, 2024 10:03 pm
by getdunntrucking
I had this issue with our phone support techs in that they would sometimes change something in a router or switch in an attempt to help their customer (without permission of course). I put a Read Only Tech account in every MT on our network then I made a second Dude server with different credentials that logs into that Read Only account, and BAM, Read Only Mikrotiks in Dude. My Techs can still log in and look around but cannot change ANYTHING. You could also just deny any Winbox access at all to that user group under "System>Users>Groups".

We have about 400 MT devices so I made a small script to help with deployment of the additional account and then added it to my pre-deployment script.