BETWEEN READ AND TEST POLICY

Azma · February 4, 2019, 6:59am

HI All,

am i only have this issue?

under /user group → policy=ssh,read | we can only read configs but can’t do test such as ping, treaceroute, etc
it’s very clear that we need add “test” policy as well to be able run ping, traceroute, etc

but if policy=ssh,test | we can’t read any configs but also can’t do testing ping, traceroute, etc.

so how if you want to provide a test router to limited users only without capablity to read any configs? (dont ask me to set skin )

should this be addressed as feature request?

thanks..

normis · February 4, 2019, 12:42pm

Not possible. User can’t do anything if there is no read.

vecernik87 · February 4, 2019, 11:50pm

@Azma:
You can’t do ping without having read-access to interfaces and routing tables. Similar applies to other tests which rely on some particular parts of config.
I have seen similar request a while ago and my suggestion is to give user test+read+web permissions and assign him special webfig layout which will allow him to do only a ping (and traceroute or other tests):

/user group
add name=testgroup policy="read,test,web,!local,!telnet,!ssh,!ftp,!reboot,!write,\
    !policy,!winbox,!password,!sniff,!sensitive,!api,!romon,!dude,!tikapp" \
    skin=testskin
/user
add group=testgroup name=test

file testskin.json (source code for the skin, should be placed in /flash/skins directory)

{
    'Quick Set': 0,
    WebFig: 0,
    Terminal: 0,
    Manual: 0,
    Logout: 0,
    CAPsMAN: 0,
    Wireless: 0,
    Interfaces: 0,
    Bridge: 0,
    Switch: 0,
    PPP: 0,
    Mesh: 0,
    IP: 0,
    Routing: 0,
    System: 0,
    Queues: 0,
    Files: 0,
    Log: 0,
    RADIUS: 0,
    Tools: {
        'BTest Server': 0,
        'Bandwidth Test': 0,
        Email: 0,
        'Flood Ping': 0,
        Graphing: 0,
        'IP Scan': 0,
        'MAC Server': 0,
        Netwatch: 0,
        'Packet Sniffer': 0,
        'Ping Speed': 0,
        Profile: 0,
        RoMON: 0,
        SMS: 0,
        Telnet: 0,
        Torch: 0,
        'Traffic Generator': 0,
        'Traffic Monitor': 0
    },
    Partition: 0,
    'Make Supout.rif': 0,
    Undo: 0,
    Redo: 0,
    'Hide Passwords': 0,
    'Safe Mode': 0,
    WinBox: 0,
    Graphs: 0,
    License: 0
}

If you are not sure how to upload the skin, you can create it manually:

and the result will look like this:

Not a best solution but maybe good enough?

Azma · February 5, 2019, 12:38am

Hi Normis,
thanks for your response. But i’m sure there are no disadvantage to implement this. For example.

I want give limited access and able to read only over ssh and cant do test, i can do it by set up “policy=read,ssh” ← doing test should be impossible
I want to give read access and test, so “policy=read,ssh,test” ← able to doing test and read all config
I want to give test only not to read configs, so “policy=ssh,test” ← able to test only

What i got now are only option 1 and 2. It should be better due to it gives more options to users rather than current policy, but the old GOAL is still the remain. So far i know this like cisco does (able ping, traceroute without config terminal).

So please make “test” as stand-alone function!, ← my request

Hi Vecernik87,
Thanks for your input. Yes webfig skin perfectly could do this, but its need more effort. Need setup cert, config skin.

vecernik87 · February 5, 2019, 1:25am

I agree it requires more effort but you are not the first one who hit this issue. I would be very surprised if you somehow come with argument which would change Mikrotik’s mind.

In regard to your attempt:

I want to give test only not to read configs, so “policy=ssh,test” ← able to test only

Normis already said that and I gave you bit more explanation on WHY is there such limitation. I guess it was not that clear so let me give you an example:

Part of the “ping” and “traceroute” function is ability to select interface (for example arp ping require interface). When the interface is selected, user is technically exposing part of the config (practically same as /interface print) which you would like to protect.

In other words:
Without ability to select interface you can’t use arp-ping.
Should the ping/traceroute function be available when several parameters will be either compromised or unavailable?

Cisco solves this by limiting available parameters (when not logged in, you can enter only hostname. When logged in, you can specify interfaces etc..). I am not sure whether RouterOS supports approach, where single command accepts/rejects different parameters based on user’s permissions. Although, if it could, it would be a great addition!

Azma · February 5, 2019, 2:03am

I know, i hope MikroTik would accept what is my point of view as well as many users before me, at least they say “yes we need add more options”

I believe,

so let me give you an example:

Part of the “ping” and “traceroute” function is ability to select interface (for example arp ping require interface). When the interface is selected, user is technically exposing part of the config (practically same as /interface print) which you would like to protect.

But from this i found a strange goal of what is this code was made for, from my point of view as a user, a access right is to control user and function, not function to function.

Am i right?

Azma · February 5, 2019, 2:19am

Even “ping” and “traceroute” somehow can read interface, we are still able to limit user from doing test by not add “test” policy (policy=ssh,read,!test,…).

vecernik87 · February 5, 2019, 3:23am

Not sure if we are on the same page. Here is couple of commands, which expose interfaces defined in the router. I assume, user without “read” policy shouldn’t be able to know what interfaces are available.
First command confirms that interface exists and something is answering to ARP requests:

[admin@mikrotik] > ping 10.245.24.220 arp-ping=yes interface=bridge-abc     
  SEQ HOST                                     SIZE TTL TIME  STATUS                         
    0 00:11:32:60:D2:C7                                 0ms  
    1 00:11:32:60:D2:C7                                 0ms  
    sent=2 received=2 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms

Second command confirms that interface exists but target IP is either behind router or not available at all:

[admin@mikrotik] > ping 10.245.24.220 arp-ping=yes interface=bridge-def
  SEQ HOST                                     SIZE TTL TIME  STATUS                         
    0 10.245.24.220                                           timeout                        
    1 10.245.24.220                                           timeout                        
    sent=2 received=0 packet-loss=100%

Third command proves that selected interface does not exist at all.

[admin@mikrotik] > ping 10.245.24.220 arp-ping=yes interface=bridge1    
input does not match any value of interface

And if you don’t want to do trial&error approach, fourth command actually give full list of available interfaces…

[admin@mikrotik] > ping 10.245.24.220 arp-ping=yes interface= {[TAB KEY PRESSED]}
"vlan1-management test"  ether4               wlan-def-staff       ovpn-out
bridge-abc               ether5               wlan-xyz-legacy      pptp-out
bridge-def               vlan-def-guest       wlan-xyz-management  sstp-out
bridge-xyz               vlan-def-impos       wlan-xyz-security    vlan-xyz
ether1-uplink            vlan-xyz-staff_2-12  wlan-xyz-staff       wlan1   
ether2-pc                wlan-def-guest       eoip-def-trunk       wlan2   
ether3-ntb               wlan-def-impos       eoip-xyz-trunk

In all cases, user is getting some information about interfaces, which he is not expected to have access to. I know it is “just” an interface name but it can contain info about subscribers/customers. It may expose particular IP available for specific interface etc… It is part of config and without “read” policy it should not be accessible - I hope we all agree on this statement.

Azma · February 5, 2019, 4:05am

Yes we all agree that double tab functions helps us to identify interface and its comment which the function it self has a capability to read an interface.

but, back to my simulation above, if you set policy=ssh,read,test, any sensitive information such as customer interface will be exposed as well. Or even though “test” is able to read interface without “read”.

So if we dont want any sensitive information being exposed, simply dont give “test” and “read” policy.

Conclusion: With “test” policy able to read interface without “read” policy, administrator able to combine so we could have 4 options (1 options additional)

User can read configs, but cant test
User can read configs and can test
User cant read configs but can test, or
User cant read configs and cant test, due to have some sensitive information.

Please find if any fail algorithm of simulation above.