How do I protect the script from being pirated? I want the script that I entered into PPP > Profile > Scripts > On Up / On Down not to be hijacked by Admins/Technicians who have access to my microbill. in PHP I use Obfuscation, but what about in Mikrotik?

Long live Caesar!

Oh for fun. In recent V7, the simplest be to use ":convert transform=rot13" somehow.

One way, make function, to both encode and decode something & ofuscate that code using ROT13 "encryption":
Then use that function to encode some code by calling the $enc function:
:put $enc ":put hello"
which get you ":chg uryyb"

Then in your script source you can wrap that obfuscated source you generated:
which will print "hello".

Put it in a (remote) repository.

If decode is remote then decoding needs external access. That needs that the connection to be up.

FWIW, I was not actually suggesting using my ROT13 code above. My attempt at humor here. e.g. Isn't RSC already obfuscated enough?

If someone has access to the router, they can get the config via export, and nothing you do be too hidden. e.g. since first step to post on this forum is including the config – someone on forum would explain what it does if they didn't know.

The underlying issue is there no user policy that blocks read scripts if logged in. Like the rest of various policy scheme, it's hit-or-miss whether you can construct an RouterOS user with restricted rights.

I think best you could do is use a skin to hide the PPP menu. Work for webfig/winbox. Not going to help with CLI nor :export... but at least someone have to know the CLI to "steal" your precious script.

If one reads the tea leaves here: I'm thinking OP's company sells fully-configured mikrotik for say 3X cost of hardware. They hire more junior folk to install it, who realize it's just a config file & get the idea to sell it for 2X hardware themselves... Now if your business's only added value is some specific RouterOS script, you have bigger problem....

But if we ignore the foolhardy use case here. To @holvoetn's point.... Underlying issue of delegated admin is something Mikrotik does not do. Folk do have employees and customer, who may need access to the router but someone may want to restrict what they can do/see on some granular level.

Cisco etc have TACACS+ where you'd be able to "delegate" access on a command-by-command basis. On RouterOS, all you got the dozen user policy choices that rarely align with the desired policy for some "operator" type account (e.g. read, only some writes, etc.).

No one remember MetaROUTER?

Ahead of the times. VRF and Docker, before either were invented. Left with /container that can't run RouterOS inside it (like MetaROUTER could), but some RouterOS-on-RouterOS certainly be one way to ofuscate things on V6.

Don't give anyone else access to your device.
Simple.

If I am the owner and need admin staff to manage my mikrotik, do you think the admin is prohibited from being given access to the mikrotik?

Long live Caesar!

Oh for fun. In recent V7, the simplest be to use ":convert transform=rot13" somehow.

One way, make function, to both encode and decode something & ofuscate that code using ROT13 "encryption":

Code: Select all

:glob enc do={:retu [:conv transform=ro $1]}

Then use that function to encode some code by calling the $enc function:
:put $enc ":put hello"
which get you ":chg uryyb"

Then in your script source you can wrap that obfuscated source you generated:

Code: Select all

:glob enc do={:retu [:conv transform=ro $1]}
[:parse [$enc ":chg uryyb"]]

which will print "hello".

Thank you very much for the answer, I will try to get the results that meet my expectations.

Put it in a (remote) repository.

Are there any resources I can learn about for remote locking?

If decode is remote then decoding needs external access. That needs that the connection to be up.

Thank you, can you provide the reference link?

What could ever be so precious to protect?

If you do not have administrator rights on the RouterBOARD, it means that it is not yours.
If you have that right, remove all other users.

Buy one for yourself and don't let anyone access it.
You can already see how to configure it from the one you already use.

Here I am the owner of Mikrotik, and I need admin staff to manage, to make it easier to manage the server because I don't only manage this business myself, but there are several businesses that I have to manage and all of them require me to leave the office environment.

Repeat ...

I am aware of the current restrictions and I do agree with you.
There _should_ be a more granular level of providing access. But that's unfortunately not the case now so ...

If you need admin staff to manage your router, then you need to trust them with all the info in that router.
If you don't trust them, manage the router yourself.

Same thing with giving house keys to cleaning personnel. If you don't trust them, do the cleaning yourself.

One or the other.
Not both.

That's how it is with current way of permissions in RouterOS. Nothing we can do about that.

Sorry, it's not that I don't trust employees, but this is a script that I think is important and confidential. If the admin sells the script that I made to another Mikrotik owner, what should I do?

Or create external service (in PHP or whatever) which will perform same script logic and trigger with fetch external service endpoint in PPP profile up and down scripts with some parameters you need, you can control/fetch data from ROS over its API from that service. Restrict access to server where service is performed.

@optio, perhaps... but don't forget there are restrictions what PPPoE scripts can do in recent V7... And, well, you may not have internet since it's bring up PPPoE...

But making any of the PPPoE or dhcp-client etc scripts any MORE complex that strictly needed would NOT be my recommendation. One bug in these scripts, there is no internet. And Mikrotik scripting is funky so complex tricks may break in future versions. So if you're doing a lot in a PPPoE (enough to worry about be pirated) – you're doing something not worth copying.

Since were not talking about obfuscating a queue tree – which are tricky/time-consuming to setup... I'd be worried that my untrustworthy helpers might figure out how to use queues to improve user experience.

It was suggestion if this is really some "secret" algorithm in script, I'm not using PPPoE, so PPP profile scripts for PPPoE cannot execute fetch to some external service on LAN with some static IP (such service doesn't need to be on some server accessed over WAN and actually it is better to be on LAN for ROS API usage to avoid using VPN) or there are some ROS bugs here?

It was suggestion if this is really some "secret" algorithm in script, I'm not using PPPoE, so PPP profile scripts for PPPoE cannot execute fetch to some external service on LAN with some static IP (such service doesn't need to be on some server accessed over WAN) or there are some ROS bugs here?

You may be right /tool/fetch is allowed & I'm recalling some bug. But there are restrictions with various on-XXX= scripts can do — ironically here, to avoid privilege execution e.g. a lower level user ("write", not "full") used be able to update the PPP/DHCP script, which in previous V7 ran as "full" user permissions (and thus the untrustworth lower-level user could add script that added a new full user to do more).

So AFAIK all the on-XXX= script follow netwatch's docs (https://help.mikrotik.com/docs/display/ROS/Netwatch) – but I do NOT do anything beyond basic stuff like get/set/find/if in these script SO have not verify (just my memory and belief docs might not be updated for PPP)

Netwatch executes scripts as *sys user, so any defined global variable in the Netwatch script will not be readable by for an example a scheduler or other users

Netwatch is limited to read,write,test,reboot script policies. If the owner of the script does not have enough permissions to execute a certain command in the script, then the script will not be executed. If the script has greater policies than read,write,test,reboot - then the script will not be executed as well, make sure your scripts do not exceed the mentioned policies.

It is possible to disable permission checking for RouterOS scripts under /system/scripts menu. This is useful when Netwatch does not have enough permissions to execute a script, though this decreases overall security. It is recommended to assign proper permissions to a script instead.

Since fetch requires ftp user policy from ROS 7.13+ version it might be a problem as you stated, if ppp up/down events are limited as netwatch, but this is not documented afaik, it needs to be tested to be sure.

V7.12 release notes say:

*) console - restrict permissions to "read,write,reboot,ftp,romon,test" for scripts executed by DHCP, Hotspot, PPP and Traffic-Monitor services;

But they don't doc the restriction at help.mikrotik.com for those. Only netwatch doc has note about — which doesn't mention ftp or romon — but netwatch change is not in any release note...

As you say, you'd want to test it.