Warning: Unraid Servers exposed to the Internet are being hacked


Recommended Posts

Hello Unraid Community!

 

It has come to our attention that in recent days, we've seen a significant uptick in the amount of Unraid server's being compromised due to poor security practices.  The purpose of this post is to help our community verify their server's are secure and provide helpful best-practices recommendations to ensuring your system doesn't become another statistic.  Please review the below recommendations on your server(s) to ensure they are safe.

 

Set a strong root password

Similar to many routers, Unraid systems do not have a password set by default.  This is to ensure you can quickly and easily access the management console immediately after initial installation.  However, this doesn't mean you shouldn't set one.  Doing this is simple.  Just navigate to the Users tab and click on root.  Now set a password.  From then on, you will be required to authenticate anytime you attempt to login to the webGui.

 

In addition, there is a plugin available in Community Apps called Dynamix Password Validator.  This plugin will provide guidance on how strong of a password you're creating based on complexity rules (how many capital vs. lowercase letters, numbers, symbols, and overall password length are used to judge this).  Consider installing this for extra guidance on password strength.

 

Review port mappings on your router

Forwarding ports to your server is required for specific services that you want to be Internet-accessible such as Plex, FTP servers, game servers, VoIP servers, etc.  But forwarding the wrong ports can expose your server to significant security risk.  Here are just a few ports you should be extra careful with when forwarding:

 

  • Port 80:  Used to access the webGui without SSL (unless you've rebound access to another port on the Management Access settings page).  DO NOT forward port 80. Forwarding this port by default will allow you to access the webGui remotely, but without SSL securing the connection, devices in between your browser and the server could "sniff" the packets to see what you're doing.  If you want to make the webGui remotely accessible, install the Unraid.net plugin to enable My Servers on your system, which can provide a secure remote access solution that utilizes SSL to ensure your connection is fully encrypted.
  • Port 443:  Used to access the webGui with SSL.  This is only better than port 80 if you have a root password set.  If no root password is set and you forward this port, unauthorized users can connect to your webGui and have full access to your server.  In addition, if you forward this port without using the Unraid.net plugin and My Servers, attempts to connect to the webGui through a browser will present a security warning due to the lack of an SSL certificate.  Consider making life easier for yourself and utilize Unraid.net with My Servers to enable simple, safe, and secure remote access to your Unraid systems.

NOTE: When setting up Remote Access in My Servers, we highly recommend you choose a random port over 1000 rather than using the default of 443.

 

  • Port 445:  Used for SMB (shares).  If you forward this port to your server, any public shares can be connected to by any user over the internet.  Generally speaking, it is never advisable to expose SMB shares directly over the internet.  If you need the ability to access your shares remotely, we suggest utilizing a Wireguard VPN to create a secure tunnel between your device and the server.  In addition, if the flash device itself is exported using SMB and this port is forwarded, its contents can easily be deleted and your paid key could easily be stolen.  Just don't do this.
     
  • Port 111/2049:  Used for NFS (shares).  While NFS is disabled by default, if you are making use of this protocol, just make sure you aren't forwarding these ports through your router.  Similar to SMB, just utilize Wireguard to create a secure tunnel from any remote devices that need to connect to the server over NFS.
     
  • Port 22/23:  Used by Telnet and SSH for console access.  Especially dangerous for users that don't have a root password set.  Similar to SMB, we don't recommend forwarding these ports at all, but rather, suggest users leverage a Wireguard VPN connection for the purposes of connecting using either of these protocols.
     
  • Ports in the 57xx range:  These ports are generally used by VMs for VNC access.  While you can forward these ports to enable VNC access remotely for your VMs, the better and easier way to do this is through installing the Unraid.net plugin and enabling My Servers.  This ensures that those connections are secure via SSL and does not require individual ports to be forwarded for each VM.

 

Generally speaking, you really shouldn't need to forward many ports to your server.  If you see a forwarding rule you don't understand, consider removing it, see if anyone complains, and if so, you can always put it back.

 

Never ever ever put your server in the DMZ

No matter how locked down you think you have your server, it is never advisable to place it in the DMZ on your network.  By doing so, you are essentially forwarding every port on your public IP address to your server directly, allowing all locally accessible services to be remotely accessible as well.  Regardless of how "locked down" you think you actually have the server, placing it in the DMZ exposes it to unnecessary risks.  Never ever do this.

 

Consider setting shares to private with users and passwords

The convenience of password-less share access is pretty great.  We know that and its why we don't require you to set passwords for your shares.  However, there is a security risk posed to your data when you do this, even if you don't forward any ports to your server and have a strong root password.  If another device on your network such as a PC, Mac, phone, tablet, IoT device, etc. were to have its security breached, it could be used to make a local connection to your server's shares.  By default, shares are set to be publicly readable/writeable, which means those rogue devices can be used to steal, delete, or encrypt the data within them.  In addition, malicious users could also use this method to put data on your server that you don't want.  It is for these reasons that if you are going to create public shares, we highly recommend setting access to read-only.  Only authorized users with a strong password should be able to write data to your shares.

 

Don't expose the Flash share, and if you do, make it private

The flash device itself can be exposed over SMB.  This is convenient if you need to make advanced changes to your system such as modifying the go file in the config directory.  However, the flash device itself contains the files needed to boot Unraid as well as your configuration data (disk assignments, shares, etc).  Exposing this share publicly can be extremely dangerous, so we advise against doing so unless you absolutely have to, and when you do, it is advised to do so privately, requiring a username and password to see and modify the contents.

 

Keep your server up-to-date

Regardless of what other measures you take, keeping your server current with the latest release(s) is vital to ensuring security.  There are constant security notices (CVEs) published for the various components used in Unraid OS.  We here at Lime Technology do our best to ensure all vulnerabilities are addressed in a timely manner with software updates.  However, these updates are useless to you if you don't apply them in a timely manner as well.  Keeping your OS up-to-date is easy.  Just navigate to Tools > Update OS to check for and apply any updates.  You can configure notifications to prompt you when a new update is available from the Settings > Notifications page.

 

More Best Practices Recommendations

In addition to all of the above recommendations, we've asked SpaceInvaderOne to work up a video with even more detailed best-practices related to Unraid security.  We'll post a link as soon as the video is up to check out what other things you can do to improve your system security.

 

It is of vital importance that all users review these recommendations on their systems as soon as possible to ensure that you are doing all that is necessary to protect your data.  We at Lime Technology are committed to keeping Unraid a safe and secure platform for all of your personal digital content, but we can only go so far in this effort.  It is ultimately up to you the user to ensure your network and the devices on it are adhering to security best-practices.

  • Like 23
  • Thanks 9
Link to comment

Nice tips, I just wish it would be easier to setup KeysFile authentication and disable password authentication for the SSH.  

Just placing your pupkey in the UI and setting a checkbox to disable password auth would be nice. I currently have it setup like ken-ji describes here. Then i edited PasswordAuthentication to "no".  

 

Also think about a secure by default approach with future updates. Why not force the user to set a secure password on first load?  

Why even make shares public by default? Why allow "guest" to access SMB shares by default? Why create a share for the flash in the first place?  

I get that some of those things make it more convenient, but imo convenience should not compromise security.

Edited by Thx And Bye
  • Like 6
  • Thanks 3
Link to comment
1 hour ago, Thx And Bye said:

Why even make shares public by default? Why allow "guest" to access SMB shares by default? Why create a share for the flash in the first place?  

I get that some of those things make it more convenient, but imo convenience should not compromise security.

That is the very reason that there are so many threads about loss of access to Unraid servers via SMB occurs everything MS introduces a new WINDOWS security update (usually via the biannual 'Feature' updates-- plus, they never document what they did or how they did it)!!!  No everyone wants to stick their Unraid server out on the Internet.  Personally, I think it is bad idea to even consider it.  I want my two servers locked securely behind a router.  I am concerned about security (I have setup a separate VLAN setup for WIFI guests (Friends and Family) which is isolated from the portion of the LAN which those servers set on.)  The people I allow on my LAN I trust but I still have virtually all of my shares set to SECURE which grants read-only access to those shares and there is no user assigned to those shares so no one even has write access.  (This is to prevent the unlikely event of a Ransom attack  Malware getting into a Windows client.)  Yes, this does require that I use the Krusader Docker to do any array file maintenance that is required and that can be a bit of a pain but the extra peace of mind is well worth it.  (I would point out that what you propose would probably allow Malware to do its dirty work since one or more or your clients would have write direct write access to your shares.)

Link to comment
2 hours ago, sreknob said:

This would be a really nice addition!

 

Having a simple way to persist the public key would be nice for SSH.  If a similar method can also be used for root login, even better.

 

 

Link to comment

I really like these recommendations, which all have been previously implemented in my setup as a result of either watching SIO videos or various UnRAID forum posts.  But having this security info in one thread really makes better sense than users having to assemble it on their own.

 

Also, as another user posted in this thread, UnRAID should default to more secure settings out of the box.  I’m not an IT professional, but my reading of the forums suggests that many if not most computer problems come from user error.  I suspect security issues even more so.

Edited by DoItMyselfToo
Link to comment

I think this all great advice but I wondered what changed? Before few users made the mistake of exposing their servers to the WWW and paid for it.

However after the update to 6.9 and 6.9.1 it seems that it became more prevalent and more posts were to be found that stuffed disappeared or their servers were compromised. 

 

Just my opinion but it seems that added functionality exposed some of these folks where before 6.8.3 kept them unexposed.

 

Either way, I learned a long time ago what a misconfigure firewall can do when the internet is involved.

Link to comment
9 minutes ago, ijuarez said:

what changed?

Could be a malicious individual decided to start doing this just this week.

 

So far, nobody who has posted with this problem had ever posted to the forum before, and nobody that has been using Unraid for a while and are running these new versions has been hacked.

  • Like 3
Link to comment
1 hour ago, trurl said:

Could be a malicious individual decided to start doing this just this week.

 

So far, nobody who has posted with this problem had ever posted to the forum before, and nobody that has been using Unraid for a while and are running these new versions has been hacked.

 

 

Could be, I just hope more people read this post and take action

Link to comment

Couple of questions.

 

1. What's the difference between Secure and Private shares?

2. Under SMB User Access, if I change it to read only will that change anything for Plex, Sonarr, NZBget, etc or just if I need to access the shares?

3. Are there any shares that should be public or should they all be set to secure/private.

 

Sorry for the dumb obvious questions, I just wanna make sure any changes I make don't cause issues with the programs I have running.  I don't access my server through share's very often.

Edited by squirrellydw
Link to comment
2 hours ago, ijuarez said:

I think this all great advice but I wondered what changed? Before few users made the mistake of exposing their servers to the WWW and paid for it.

However after the update to 6.9 and 6.9.1 it seems that it became more prevalent and more posts were to be found that stuffed disappeared or their servers were compromised. 

 

Just my opinion but it seems that added functionality exposed some of these folks where before 6.8.3 kept them unexposed.

 

More folks opening up ports for the early preview feature of "unraid.net" to link back to their own server?

Link to comment
9 minutes ago, squirrellydw said:

Couple of questions.

 

1. What's the difference between Secure and Private shares?

2. Under SMB User Access, if I change it to read only will that change anything for Plex, Sonarr, NZBget, etc or just if I need to access the shares?

3. Are there any shares that should be public or should they all be set to secure/private.

 

Sorry for the dumb obvious questions, I just wanna make sure any changes I make don't cause issues with the programs I have running.  I don't access my server through share very often.

 

For the 1., it's all in the GUI help :

image.thumb.png.549a4ffc94f348a4480d1fc7277cc6a1.png

  • Thanks 2
Link to comment
12 minutes ago, squirrellydw said:

Under SMB User Access, if I change it to read only will that change anything for Plex, Sonarr, NZBget, etc or just if I need to access the shares?

You might want to test to be sure but I think it’s very unlikely that any changes to SMB settings could effect Plex, Sonarr, etc. They are not accessing the shares via SMB.

  • Thanks 1
Link to comment
3 hours ago, Tom3 said:

 

Having a simple way to persist the public key would be nice for SSH.  If a similar method can also be used for root login, even better.

 

 

 

This is implemented in Unraid OS 6.9.x which makes /root/.ssh a symlink to flash config/ssh/root directory.

  • Like 2
Link to comment

Since I brought up this area of discussion, let me give you my thoughts. 

47 minutes ago, squirrellydw said:

3. Are there any shares that should be public or should they all be set to secure/private.

 

First thing. Most of my servers usage is the storage of archival items like data backup of Windows client computers and permanent storage of Media files.  Most of the time these files are never changed (or deleted).  They are just read.  Even the backup of the data files usually require only read type access.  With read only, they can be copied back to a client if updating is necessary.    (If privacy is a concern for the files on your server then you will have to use the Private Security setting and set up users with read-write or read-only access.) 

 

I said that I have some shares set to Public.  I will give you an example.  We use an address book type program that several people have to have read-write type access to.  There is nothing is the database that is not information that is already in the public domain.  The people who are in it are basically friends and family.  While I could have setup with Private Security setting, it was much easier to just leave it as Public.  (There are several issues with SMB and users that must be addressed very carefully to have a fool-proof access to SMB shares on any SMB server!)   This Database is backed up to the Secure portion of the server on a regular basis!

 

Let me answer one question that will probably popup soon if I don't address it now. 

 

              How does one add data to a Secure (or even a Private) share if one does not have write access to it? 

 

The answer is a bit of trickery using 'disk access' to the cache drive.  It is explained how to do this here:

             https://forums.unraid.net/topic/58374-secure-writing-strategy-for-unraid-server-using-write-once-read-many-mode/#comment-572532

 

Edited by Frank1940
Link to comment
1 hour ago, BRiT said:

More folks opening up ports for the early preview feature of "unraid.net" to link back to their own server?

 

The issues have been around ports being forwarded or systems put in the DMZ while having no root password. There is nothing that connects the recent hacks with the new My Servers Remote Access functionality, just unfortunate timing.

 

Having said that, our Remote Access solution does use the root password to control access. So it is important to have a good strong password and a good idea to use a non-standard port. Note that we do require a non-null password in order to enable Remote Access, but once one has been set we can't review the password to say whether it is good or bad.

  • Like 2
Link to comment
5 minutes ago, ljm42 said:

 

The issues have been around ports being forwarded or systems put in the DMZ while having no root password. There is nothing that connects the recent hacks with the new My Servers Remote Access functionality, just unfortunate timing.

 

 

Just noting possible cause and effects -- why some may be opening up ports or putting servers into DMZ. It was asked "Why now and not before", well there's an answer.

 

Never said anything was wrong with the implementation of "My Servers".

  • Like 1
Link to comment

Thanks for the heads up.  I've updated to a stronger password and reviewed my share securities (these are already OK).

 

Also installed 'Dynamix Password Validator.' and while I see it in the plugins page I seem unable to sus out its location in the gui to actually use it.  Some help would be appreciated!

Link to comment
14 minutes ago, landS said:

 

Also installed 'Dynamix Password Validator.' and while I see it in the plugins page I seem unable to sus out its location in the gui to actually use it.  Some help would be appreciated!

It’s found under Users in each password section. Good question

  • Thanks 2
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.