At one time we faced a perhaps similar dilemma: hardware with
proprietary software/firmware that would not support then current
security/encryption methods/protocols. The hardware could not be
replaced for two reasons: it was integrated into specific systems that
were in use; the vendor did not support the old hardware and we had
insufficient external funding to replace all of the systems that would
need to be replaced for compatibility with the vendor then current
products. The solution we used was to put a physical dedicated buffer
computer (not virtual, no hypervisor) between all network accesses to
the affected hardware system and the buffer machine was only on an
internal network, as would be the affected hardware, all behind the
"hardening" of our Internet connected networks (that included a
honey-pot sacrificial "trap"). The buffer machine did a bi-directional
translation from current methods to what was required by the affected
hardware. In addition, there was a terminal console machine that could
be attached directly to the affected hardware platform and environment
allowing us to fully manually configure -- in so far as the proprietary
environment allowed -- as an "emergency" measure (that we rarely had to
use). There was some increase in latency, but as the affected hardware
was not a real time system but merely a "low" latency and "high"
throughput system, the increased latency and lowered throughput did not
impact the usages of the affected hardware, and was fully transparent to
the end users of the entire system.
On 11/5/21 08:14, Konstantin Olchanski wrote:
Once I had a clue I was able to install the vsftpd rpm
Running an unmaintained, out-of-date, password based service like FTP ...
I would presume the OP has a clue ...
Why would you presume this? ...
bah, hambug! He uses Linux, he has a clue.
Most likely FTP is needed to support some piece of old hardware that cannot be
trivially
replaced or upgraded.
With our MIDAS data acquisition software we have an important user with a
standing requirement
to support writing data to an FTP server (comlpete with clear-text password,
etc),
because that is the interface to their main sata store system. (*you* go and
tell them
"just write all your data to a usb drive!").
If ftp is needed, then it is needed, period.
I just recently had to junk a very nice multiport 1gige switch, just because
the management interface is an https web page, *but* supports only SSLv3
(predates TLS)
and only obsolete cyphers (RC4 & co). Modern web browser absolutely refuses to
connect,
even though it is on a very secure private network (direct wire connection!).
Very old web browser (SL6 firefox?) did manage to connect (after spewing
nonsense
about expired https certificates) but then my javascript was too old and the
login
page did not work.
So sometimes you have to "turn back the clock" and use "obsolete" and "insecure"
and even "it's so dangerous now!" software and connectivity.
