I have a QNAP server that recently got hit with the Deadbolt malware. Wiped out my entire movie library. I’m looking for explicit directions as to how to secure the server so I don’t get hit again (from a PLEX perspective). I really only use the server for Plex and I have a few family members from outside my network. Thoughts?
To keep the machine from being hit by those malwares,
-
Maintain full control of the machine (Don’t let anyone other than yourself use it.)
-
Put only media on it. (No EXE or BAT or other scripts)
-
Make certain the admin password is a complex one (14 mixed letters, digits, and punctuation which makes sense only to you)
-
Do not grant “administrator” privilege to any “normal” user accounts.
-
Don’t install any apps/services except those by QNAP or trusted providers
-
Make 100% certain the QNAP malware app runs with full privilege to quarantine anything it doesn’t like (even potentially false positives)
-
If you need to allow access, Keep it In-House only or over a controlled VPN.
The intent/goal is to keep a complete separation of Administrator and Non-privileged users.
Having the machine be accessible remotely is an invitation to infiltration but if you must, it’s 100% reasonable to make a modem/firewall rule which only allows certain IP addresss (DynDNS FQDNs are better – for each person).
On a personal note: I share my server with a few people. I have a firewall rule (in my pfsense router/firewall) which only allows those people to connect. Everyone else sees a “whole in the internet” aka no-reply as if I don’t exist.
I listen to a podcast called Security Now!. It’s a good podcast for security. The host, Steve Gibson, often talks about QNAP in a very bad light about its security problems. So I would say to secure the QNAP you buy a new NAS, only use it inside your local LAN or perhaps install a different OS (if that’s possible).
For example, see Security Now! Transcript of Episode #813.
QNAP has prioprietary hardware which requires their drivers.
While you can boot another OS via thumbdrive, you will only get a fraction of the performance. (This has been tried with Ubuntu 20 on a TVS-1282-i7)
This is why I put the security “at the front door” (the pfsense)
Can you tell me how you are doing this? Likewise, I want to share the Plex server with my adult son and daughter. Do I have to know their IP addresses for all of their devices to create the rule?
Thank you.
- Pfsense or other firewall which supports FQDNs & IP addresses in rules.
- Create a group (Alias in pfSense term) which contains the list of those allowed access. My alias name is “PlexAllowedRemotes”
- Create a NAT Forwarding rule which allows “GroupName” to connect to the external Plex port
For those who are remote -
- Get a free DDNS name (easiest) which automatically updates (via their computer)
- Live in such an area / have an ISP where it’s very reasonably safe to either enter their IP because it’s static (my IP is effectively static even though it’s officially DHCP)
- Add the IP, small IP range, or DDNS FQDN into the GroupName.
Sorry. Just getting back to this as I recover my QNap server. Are you using a Pfsense hardware device or using it via AWS?
I use Pfsense.
It’s my edge device router/firewall solution.
Hardware: ISP → S33 cable modem → pfSense box → main switch
The default behavior on pfsense is to drop all packets which don’t match a rule
I added two things to my pfsense for Plex:
-
An “Alias” which contains the static IP addresses or FQDN (ddns works well) of those who I will allow to see my Plex port
-
A firewall rule (NAT) which
– references the Alias list of who to allow to see the port is open
– Forward those requests through like normal NAT Port Forwarding traffic to PMS. -
PMS is on a Manual port forward settings so the rule always works as expected
In practice:
- Family member attempts to contact my server via Plex.tv
- I see the IP address inbound to my server
- Pfsense looks at the Alias (allowed list) and resolves FQDN → IP address
- When IP addresses match , the rule fires and access is granted.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.