Warning : redis and Fairware ransonware

This is more a security announcement than a question.
Our owncloud 10.02 server has been hacked yesterday (July 7) by the ransonware named Fairware.
I had recently installed a new instance (10.02) of OwnCloud on a freshly installed Ubuntu 16.04 server. I have installed Redis for cache, following the guide indicated on the manual. I did bind the redis server to the localhost, as a security measure. Obviously it is not efficient.
The ransonware Fairware is not a true ransonware, as it "simply" delet your data. Once logged in your system (it add its own key in authorized_keys) it performs:
rm -rf /var/www/
rm -rf /usr/share/nginx
rm -rf /var/lib/mysql/
rm -rf /data/
And it gives in a Readme file the address to contact for the ranson. But as everything is deleted (not crypted) it is useless to pay anything!
Fortunately, in our configuration, owncloud and mysql as well as owncould data are NOT on the common directory /var/www, and so on. Therefore the ransonware did not affect any of our data (which are backup anyway). So the consequences are minimal.
I am going to create a new server and to migrate the data disk on this new server. I would like to better secure my new redis installation, following this site. Anyone could give advices on securing the redis server ?
Thanks,

Did you use a firewall? Are you sure Redis was the problem?

I use Fail2ban, but there is no specific jail against intrusion via redis.
Yes, I am quite sure the problem came through redis. I have found exactly what is described in thispage. What I don't understand is that following the script found on this page, this is the version 3.0 of redis that is installed, while the 3.2 is available, and correct the problem. But I don't know how to manually install version 3.2

If it's on the same machine, just use sockets like recommended in the docs you linked. Use a new setup to make sure that your new setup is more secure.

That's what I have done: I did create a new VM, transfer the data disk to the new VM, and kill the old VM, which had been attacked. And on the new machine, I did install redis 3.2 where the security breach has been resolved. I also did apply the recommendations in the post (renaming most command, set up a strong password, etc.).
My post was more to discuss the problem, as it happened to me after installing redis server using the script proposed on the link given in the OwnCloud documentation...

The documents talk about a Redis server directly exposed to the Internet. This means that hosts on the Internet can connect directly to Redis, which means that you're not using a firewall. This would be recommended to prevent problems like this happening in future.

Just bind such services to a socket, for the database you should do the same if it should only be accessed from within the server. You should first configure services in a secure way (either socket, or if not with permission settings) before putting up a firewall.

I might be wrong, but I thought that the directive "bind 127.0.0.0" was doing the job. What else should I do ?

I guess that either didn't do the job as you have expected or that ransomware didn't get in via redis.

I am quite sure it cames through REDIS, as everything I observed on my server was similar to what is described in the link about Fairware I gave in my first post. And to make the server works again, I needed to reinstall REDIS.
Anyway I tried to set up more rigid rules via iptables as indicated in the link, but I reached my limits and nothing was working anymore... so I came back to my first settings...

Before you activate the firewall, use an external portscanner to check for open ports (e.g. nmap myhost.example.com). You can check other security guidelines how to secure webservers. Just a firewall doesn't help you if you have security problems in web applications.

When I scan my port I obtain:
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp filtered smtp
80/tcp filtered http
443/tcp open https

I don't think that the redis default port is in the top1000 of nmap.