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?
Don’t give anyone else access to your device.
Simple.
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”:
: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:
:glob enc do={:retu [:conv transform=ro $1]}
[:parse [$enc ":chg uryyb"]]
which will print “hello”.
Same problem.
Decode/code function would still be visible.
No access = no problem.
Put it in a (remote) repository.
If decode is remote then decoding needs external access. That needs that the connection to be up.
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.
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.
You could easily encrypt the script in an unassailable way, but…
If the routerboard has to decipher it in some way to execute it, the decoding method is already ready…
Friendly repeat.
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?
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 …
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.
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?
Thank you very much for the answer, I will try to get the results that meet my expectations.
Repeat …
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.
Obviously you missed the point here …
Are there any resources I can learn about for remote locking?
Thank you, can you provide the reference link?