I am wanting to know if it is possible to encrypt .rsc files and have mikrotik decrypt and run the script? Trying to preserve data integrity on some of the work I have been doing as there are multiple eyes managing the RBs I work with.
+1 for this
We have many scripts that we’ve spent many hundreds of hours developing and need to protect .
+1
+1
This would also be extremely useful for us. I would also like a way to store the email password the same way the user passwords are stored so others cannot see them.
+1
This is a much needed feature
Encrypted Scripts? yes i need it.
This feature i need and expected to have it on routeros.
A user group without access to telnet prevented someone from exporting the whole config.
Blocking the ability to see / edit / export scripts would be welcome.
Simply use the API to make a program which configures your router. You can encrypt them in your own software, and use API commands to configure the router as you please.
We have no plan to make encrypted scripts.
Could you explain that a little more?
Like I pointed out… I think the big one…
Some of us spend a lot of time energy and effort becoming Mikrotik proficient. Even getting certified…
To know that
/
export compact file=allsomeoneeleseshardwork
can be a little disheartening.
Copy&paste example using my PHP client (simply adjust desired export filename, encryption password, and router credentials at the top):
<?php
use PEAR2\Net\RouterOS;
require_once 'PEAR2_Net_RouterOS-1.0.0b4.phar';
$filename = 'allsomeoneeleseshardwork';
$encryptionPassword = 'encryption password';
$util = new RouterOS\Util($client = new RouterOS\Client('192.168.0.1', 'admin', 'password'));
//Export the configuration
$exportRequest = new RouterOS\Request('/export');
$exportRequest->setArgument('file', $filename);
$client($exportRequest);
//Wait for the file to become readable
sleep(2);
//Get the file's contents
$fileContents = $util->getFileContents($filename . '.rsc');
//Remove the original unencrypted file
$util->changeMenu('/file');
$util->remove($filename . '.rsc');
//Encrypt the previously fetched content using OpenSSL
$encryptedFileContents = openssl_encrypt($fileContents, 'AES256', $encryptionPassword);
//Save the file on the web server, in the PHP file's folder
file_put_contents($filename . '.rsc.encrypted', $encryptedFileContents);
And to get a decrypted file out of the encrypted one:
<?php
$filename = 'allsomeoneeleseshardwork';
$encryptionPassword = 'encryption password';
file_put_contents($filename . '.rsc', openssl_decrypt(file_get_contents($filename . '.rsc.encrypted'), 'AES256', $encryptionPassword));
If PHP is nor your cup of tea, there are always other API clients, but the main takeaway is to have a separate device that will fetch the file, do the encryption, and perhaps keep the encrypted copy, while removing the unencrypted one (OR store the encrypted file on the router… though that’s kind’a pointless when you have no way to import it back in).
Personally, I believe that if you’re in any need of encryption, you should use something like TrueCrypt to create and use an entire encrypted storage (be it in “image file” or an actual encrypted HDD partition/drive), and just place your encrypted files in there. It’s more convenient, less error prone than encrypting/decrypting individual files (which is what the above code does), and in a sense, it’s more secure too.
BTW, in the above approach, there’s a small window (just a little over 2 seconds) in which someone with “read,ftp” access to the router may theoretically create a copy of the file, and THAT copy will be unencrypted. It’s unlikely in practice, but if you absolutely don’t trust anyone with such permissions on the router, you may want to also adjust the API script to forbid logins from all such usernames (by disabling the users in the “/user” menu) until you’ve removed the file, and re-enable them afterwards.
I catch your point.
-1000 for encrypt the scripts,
for two reason:
- MikroTik spend lot of time on new features like .sensitive. encrypted backup or ip cloud, and not spend 30 minutes to fix ALREADY EXISTING FUNCTIONS, like user-manager profile limitation (see all my bug reports), kernel panic if MPPE are used after the rewriting of “ppp” on 6.8 (and is why on my 4 pppoe-server RB1100AHx2 I’m forced to still use 6.7 because ever try with new RouterOS go on kernel panic), webfig can not create script that exec some commands because the right are missing… WinBox from 6.8 on some case are not usable on remote side (and for replicate this make me discover another way to get kernel panic)…
And I write only about the bug I have find and I have signaled to mikrotik on detailed way to reproduce…
- Encrypting is the dead of sharing information… I see this on various application…
+1 with script block , many people steal our works
+1
Really needed
To decrypt the script means RouterOS needs decryption key. And if this key is inside router, anyone can get it.
Yes, this may be accurate, but… if I need to enter password when deploying encrypted script and RouterOS encrypt if with some special key (serial-number, licence key or sometnig), script won’t be usable on other router. Maybe to thing about this?
Why not just prevent the user accessing RouterOS at all?
Because I have clients which are using my system and I don’t want to give them all of my “magic”. They need access but I don’t want to allow them to see all. Main problem with MT is that user management is very poor. You can’t grant specific thing to specific user - that’s the main problem.
Force the users to Web access only and apply a skin for them. It’s not so much secure but at least it could help you a bit.
I really need to encrypt rsc file. I think ROS already has decryption method which has today on load router encrypted backup. Or at least make webfig as security feature that customer can`t see hidden configuration pages even try to access to link manually.
If we set a password to a user, this is not exportable from the router.
Is there anyway to put on a script a hashed password, other than plaintext?
We are used to configure a user account with a password, like a backdoor, but… with this as plaintext, is not really good.
thanks