Security is none of my business!

… says the home IT expert. “I’m just not experienced enough to bother with these kind of nightmare”, says he, until malware kicks in …

I’ve gone through a little sweat and threat the past few hours as I wasn’t really able to securely (!) manage my NAS while absent from home and at the same time reading from the SynoLocker ransomware attack.

This isn’t particularly pleasant nor comforting in any way, but luckily it seems that I had at least done a few things right when configuring my gear (my data remained untouched so far). So, I thought to share some thoughts:

1 password – 1 service

The simplest and for sure one of the most silly reasons for being attacked is using some kind of default password (like “12345” or the username) or using one password for many services. This obviously wasn’t particularly the reason for SynoLocker to be able to attack, but still it gave comfort during the time today, when it was still unclear whether the attack is run via a password vulnerability.

I have to admit to gain some confidence in using an easy to remember algorithm which leads to a different password with whatever new service I consume.

No standard ports

For some reason I have this weird habit of changing ports when opening up a new service from the private LAN to the Internet. I never really go with what is suggested to be used, so when configuring my NAS for the first time, I chose to deviate from the given port 5000 and 5001 for the control panel. So far, I cannot be sure, but possibly this action saved me from SynoLocker’s attack.

So I better keep the habit and whenever I do have the possibility, I change any port exposed to that dangerous world outside.

Firewall rules are OK

Yes. They are. Especially the ones allowing you to manage your gear within the local private network. I got a rule to allow access from the private subnet

Ports: All - Protocol: All - Source IP: <my subnet IP, 16 bit + subnet mask> - Action: Allow

while at the same time everything not matching an existing rule is allowed. Now, when needing to close down everything I just need to enter the panel, chose to “deny all that doesn’t match a rule” and – BOOM – doors shut. Leaves me without management control form the outside. But – Hey! – that’s minor compared to encrypted data put at ransom. And rather sooner than later I’ll make my way into the private LAN anyway to fix things.

Let the service dictate

My NAS has quite a nice feature – which probably every NAS has anyway: When all is closed down for access from the outside, it tells you what to open for the particular service to work. Hence, I always close the firewall completely when installing or starting a new service. With that – through the respective warning popup – i instantly learn what shall be opened for this service to operate. There’s just a few things to keep in mind:

• No, you do NOT want to chose the “suppress firewall messages in future” option
• No, you do NOT want to click OK without investigating the list
• Yes, you DO want to spend time to figure out how to – here we are again! – change the default ports without disrupting the respective service

And so – to conclude: Here’s what put me under sweat and threat, eventually:

Update!

I didn’t. It turned out that I ran my gear with exactly the version vulnerable to SynoLocker without ever having even thought of checking for updates – without having checked the option to do critical updates automatically in the background.

“Why”, you ask? Honestly, because I tend to think that malfunctioning updates can break stuff as well. Question is only: What is worse? Malfunctioning update or malware injection?

Well – the option is checked now, the above saved me from a nightmare of data loss or at least financial implications and my gear remains closed to the public until further notice. From the vendor.