01-13-2016 07:28 AM
Legacy FTP is insecure (as noted when it is selected for install). We strongly recommend not installing it. That's probably how the virus landed on the target.
01-13-2016 07:39 AM
Thanks, we’re transitioning to SSH but are just looking for a temporary solution to secure our existing FTP implementation. If there’s any workarounds for this (a third party FTP solution that you know can be compiled on the Linux RT operating system for example) please let me know.
Thanks,
David
David Grant, B.A.Sc. P.Eng.
davidg@aercoustics.com<mailto:davidg@aercoustics.com>
Tel: +1-416-249-3361;291
www.aercoustics.com<http://www.aercoustics.com/
01-13-2016 08:27 AM
The FTP server on there is a third party server already, vsftpd -- ironically, "very secure" FTP daemon: https://help.ubuntu.com/community/vsftpd -- I say ironically because for compatibility with legacy applications designed for older NI products, we have to install it in a very insecure configuration. That was intended to make it easy for cases like yours when you're trying to migrate an existing FTP application (since the older FTP server didn't have the security features of vsftpd) but results in this situation of a security hole on the new controllers, which is why we don't recommend it. If you want to try it, instructions for other distros (like that Ubuntu link, or review https://security.appspot.com/vsftpd/vsftpd_conf.html and edit /etc/vsftpd.conf on your target) may work for our vsftpd too. Disabling anonymous login might close the hole the virus used (no promises). But I'd be a lot happier if you could move to ssh! Let us know how it goes.
01-20-2016 09:21 AM
Hi !
I am facing exactly the same situation, using a completely different configuration (cFP-2120 running the default VxWorks OS), operating in the same way (non-stop acquisition, writing raw data to a CFlash and just some few logs in C:).
Two of my systems, connected to the internet "behind" a 3G router, were found with a full disk (C:) with these info.zip and img00x.exe craps.
And, yes, I am using the standard FTP service installed with the LV RT.
So, it's not just a RT Linux issue.... and, of course, I am interested in implementing a solution, while these devices are operating on field.
Best regards,
Dimitri
01-20-2016 09:31 AM
Dimitri,
We found these files on almost all of our 15 cRIOs, but only our development 9066 which has a smaller internal disk size than our production 9064s was filled and consequently "taken out".
For all our systems we've set passwords for FTP access and blacklisted all network traffic except traffic from our office IP and the breach appears to have stopped.
Dave
01-20-2016 05:32 PM
Dave, thanks for your feedback!
Dimitri
01-22-2016 10:53 AM
Just a thought but really depends on your needs: Have you considered killing FTP in favor of using SCP? It's built on SSH and "feels" a lot like FTP.
01-22-2016 10:57 AM
Yes, this is our plan.
I'm told our backend system was developed before SSH was a feature on cRIOs, so we're migrating but obviously needed a more secure interim solution.
01-22-2016 12:51 PM
davidgravy2,
While still not ideal, you could modify the FTP package that is installed through MAX to have a more secured configuration (the configuration that you mentioned that you'd used in a previous comment). This means that any targets that you install the FTP server to will have the more-stringent configuration by default. The downside to this approach, other than the work involved, is that anytime that you update LVRT you will lose the changes that you've made to the package that is installed through MAX.
Let me know if you'd like some pointers or assistance on how to do this.
01-22-2016 02:51 PM
Since we have some applications in this thread where people have moved from using FTP on non-Linux LVRT targets to Linux targets, I'd be interested in opinions about the FTP server default configuration. For example anonymous FTP is allowed full access to the filesystem by default because that's how it was before. Some legacy applications ported to the newer platform presumably require it to stay that way, but times have changed security-wise in the ~20 years since LVRT's first FTP server, and times have also changed feature-wise with scp being a possibility now. Can readers in this situation comment on the value you got from having FTP default to the old configuration and the effort it would take to make your application use FTP in a more secure configuration (I realize this could vary depending which options we change to improve security *), vs. switching to scp?
* Options like: disable anonymous FTP, limit filesystem access, enable FTPS, etc...
Edit: in case a later reader reads this without the context from earlier in the thread, the default configuration of the system is more secure because FTP is not installed at all, in favor of scp. This question is just about the default behavior of FTP if you choose to install it.