I am setting up a small file storage on my MK for external FTP from the WAN. I used to have an ASUS Router that allowed me to set up an FTP server and create users that have specific access to specific directories.
During this process of trying to set up the same facility on RouterOS 7, I noticed that I can create a user and additionally create a separate group for the FTP Users that have read/write access but this does not limit them to a specific directory. If anyone gets hold of their username and password, they can traverse the entire storage disk on the router without any restrictions.
This is not inherently the way an FTP server usually works so with all these bells and whistles that RouterOS 7 comes with, this feels like a major oversight!
Why not set up a decent piece of FTP server software on RouterOS allowing us to have better security? I get that a MK router is a router and is not MEANT to be used as an FTP server but it’s not that difficult to implement a decent FTP server at minimal cost to the hardware and OS that simply manages the security better.
Mmmm…FTP and security in one sentence. Can you elaborate a bit more why you want to use FTP? And why on a router? Would a container perhaps solve this problem? What is the purpose? Do you consider file sharing a routers task?
Next to that, would you consider FTP to be secure…at all?
Security on FTP is baked into whatever FTP software you are using in other words did you mean SFTP ??? ( and even SSH isnt the greatest protocol )
As noted plain FTP or hosting game servers these days is actually a dumb idea, begging to be hacked and will be hacked.
Security on FTP is baked into whatever FTP software you are using in other words did you mean SFTP ???
This statement isn’t entirely true. Some FTP servers does not work natively with SFTP. forcing the client to use a lower security protocol.
Anyways, I use cPanel for my host for my website and I have a daily script that runs to create a backup of our account and then transfer that backup files to my Offsite FTP server.
SFTP vs FTP vs SCP are not in question in this thread. I’m referring to the access that users have to the file system once they log in.
There is no granularity on which directories a user can access and cannot access and this to me seems very insecure when a particular FTP user logs in to travers the file system. If one ftp user uploads their files to a directory, now another FTP user that has write access can access that same directory if they wish because there is nothing preventing the users from accessing one another’s directories.
So when I refer to insecure, I’m referring to all users having access to all other users files and directories.
With that thinking, you might as well remove SMB, FTP and a PLETHORA of other services off the router.
The reality is that the router has these facilities available to use and if a basic ASUS router can achieve something so simple, RouterOS should easily be able to implement something like this considering the prestige of mikrotik and routeros.
I’m not asking for the router to take me to outer space. Its not a huge ask to simply expect an FTP server to have directory restrictions the same way that SMB does on this same router.
SMB restricts directory access on this router so why can’t they implement FTP directory access?
It’s an easy excuse say “MT does not deal in file services” but the reality is that they DO offer File services on the router through the USB port and therefore if one service like SMB can implement it and PureFTP or ProFTP can all implement something like this, it stands to reason that common sense should prevail and it should be implemented on the MT as well.
In the end it is all about supply and demand. Asus is targeting a different audience then MikroTik.
Either make a suggestion to MikroTik for implemention or accept it.
it stands to reason that common sense should prevail and it should NOT be implemented on the MT as well.
IMHO FTP has no place on a router, regardless if other brands do it “better” or not.
If you want FTP with all bells and whistles, use raspberry PI or full blown Linux machine, whatever. But not your router.
My view.
I totally agree here. Never understood why all these things were added.
I do make use of the container feature, I will admit that, but only for router/network related stuff: openspeedtest, netinstall, iperf and pihole.
Not for file services. I have a NAS for that.
Just because you don’t use it for File Services doesn’t mean it actually BELONGs on the router! Containers can be done on a separate device.
but the fact that you find it useful for your needs proves that maybe OTHER services are useful for OTHER people. like say the FTP service and SMB service. The MT team added a USB port to make these features available to us from the router so if it is there, then why not simply implement the feature properly.
If the team add FILE features to the device, and the we are told, “Hey! Don’t use those features because the router is not meant to be used for that!” then they should remove it entirely. But alas, the feature is there so why not simply do it right.
If people want the FTP server features removed because FILE services do not belong on a router, then they should REMOVE VPN features, SMB features, container features etc etc and if anyone commenting here uses any of these services for ANYTHING in their daily tasks then they don’t really have a leg to stand on when they defend their position to have File Services removed because then I want their services removed as well.
It’s a weak argument to say that I must not complain if the FTP server doesn’t have directory restrictions just because File services don’t belong on a router.
The reality is that the router HAS MANY features that don’t belong on it and yet MANY people use these unwarranted services regardless.
You have to understand that there is a massive number of MikroTik devices that have only 16MB of flash storage.
16 MEGAbytes. Not 16 GIGAbytes.
In such a tiny space there is always a limited amount of features you can provide.
For each function it can be argued that “this is only a few hundred KB” but all together they no longer fit in the flash.
Even the devices with more reasonable amount of storage usually have only 128MB or so. Storage of 1GB is the exception rather than the norm.
But that provides the space to run containers for functions not supported in the main image (and not available as packages).
Other manufacturers often have way more flash space on their devices, starting with 512MB and sometimes several GB, allowing them to run full-fledged Linux systems instead of the stripped down “busybox” stuff.
When you want that too, get a Raspberry Pi or similar SBC.
Thank you for your comment but I have to say that again, it’s not a strong argument to say that the reason they can’t implement directory restrictions is because some MT devices only have 16MB of flash storage. I mean come on…these boys and girls build amazing routers with an amazing router OS on it. Do you really think they can’t simply code it in and say well, this device has too little storage so these features are not available on this device?
They can easily roll out a OS version for the router and say that OS version xyz is the only OS supported for that specific device and the newer generations can use the NEWER versions of the OS that DOES include a SIMPLE feature like directory restrictions.
And if what you say is even remotely an adequate reason for not including simple directory restrictions, then to be honest, they should not have containers, SMB , VPN on those smaller devices either. and yet they do.
I’m sorry but I don’t buy that argument. These are clever boys and girls
I’d say that one of the very strong points of MikroTik is that there is no such differentiation of functionality between models.
The RouterOS capabilities are the same, no matter if you have a $30 tiny toy device or a $3000 enterprise CCR.
Not only that enables you to setup test environments using toy routers, it also means that devices that have not been produced for 10 years still receive updated RouterOS.
When every device had a different image, that would not be achievable, and you see that with other manufacturers.
(where devices go end-of-sale in 2 years and end-of-support in 3 years more)
Your point may have truth to it but that doesn’t mean that an FTP feature like directory restrictions can’t be implemented PURELY because File services don’t belong on a router.
We are not talking about hundreds of mb’s of code here.
AND, when using the file services anyway, it is assumed you are using the USB storage port that has some sort of storage device plugged in. so the size of the flash storage is a moot point.
RouterOS like to abstract Linux-things, so I’m not sure they want to bind “files” to some particular linux file system details like owner/group. And FTP follows the same policy system as rest of RouterOS.
Also, I think you’re presume a higher level of sophistication in policy / AAA elsewhere. Essentially, policy enforcement is comparing the policy “flags” from a user policy selections, to the particular operation’s required min policy flags. There no object/file-level ACLs in the current scheme. Like, for example, you cannot create a user that can change Wi-Fi passwords without them also being able to change system user passwords.
But you can file a feature request at help.mikrotik.com, but given the lack of support here, it be a tough climb I think. I’d imagine MT point out that new “file sharing” protocols, you can secure users by share - so the workaround be using another protocol that does let you have users associated with some “share”.
But some rich policy system, but just for FTP… may not be likely.
I’m disappointed to see that you think I am arguing simply because I disagree with your standpoint. but you’re right…the comments on here are not helping anyone. I will open a ticket or a service request.
