NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

9066 strange internal disk issue - drive full?

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.

0 Kudos
Message 11 of 30
(1,110 Views)

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/

0 Kudos
Message 12 of 30
(1,110 Views)

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.

0 Kudos
Message 13 of 30
(1,110 Views)

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

0 Kudos
Message 14 of 30
(1,110 Views)

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

0 Kudos
Message 15 of 30
(1,110 Views)

Dave, thanks for your feedback!

Dimitri

0 Kudos
Message 16 of 30
(1,110 Views)

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.

0 Kudos
Message 17 of 30
(1,110 Views)

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.

Message 18 of 30
(1,110 Views)

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.

0 Kudos
Message 19 of 30
(1,110 Views)

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.

0 Kudos
Message 20 of 30
(1,110 Views)