BennTech

Members
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

11 Good

About BennTech

  • Rank
    Newbie

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yeah, you're right. This did get blown out of proportion. This is what LimeTech representatives SHOULD do when an Unraid customer reports a security flaw: Acknowledge the customer's concern. Acknowledge the security flaw. Describe the steps being taken to correct the issue. Thank the customer for reporting the flaw so LimeTech can continue to improve and secure their product. The only part has happened is #3. However, even in their "fix" LimeTech doesn't acknowledge that they are going to stop writing a plaintext password to a file. Quite the opposit
  2. Thanks, limetech, for your thorough answer. I have to reiterate that I still don't want my password written in plaintext to disk. This reduces security by unnecessarily introducing an additional attack vector. Now my secret password is not just vulnerable to keyloggers, shoulder surfing, etc., but also to all the vulnerabilities of a keyfile. Yes, the password is also available in memory, network buffers, etc. But to retrieve it from those locations requires precise timing and more skills than most computer-literate users possess. Again, no system is 100% secure, so this is about making it
  3. Thank you, Xaero. Finally someone who gets it. I will say this in defense in LimeTech. LUKS is relatively new for them, and they plan on adding features in future versions, like allowing multiple keys (something that is already built-in to LUKS, but currently has to be done manually with cryptosetup). That said, I think LimeTech should keep a single password for the whole array. I shouldn't need to enter a different password for every drive in my array--that can get unwieldy. And salting the password with the license key or drive serial doesn't add much security since t
  4. bonienl, you helped me out with jumbo frames affecting Unassigned Devices, and I appreciate that. But you are absolutely wrong here. Storing a secret password in a plaintext file is a HUGE SECURITY FLAW. Not accessible by any regular users? So Unraid and its underlying Slackware OS is 100% free of all exploits and privilege escalation? All Unraid plugins and apps and dockers are likewise 100% free of all exploits and privilege escalation? Let's be clear: NO SYSTEM IS 100% SECURE. Even LUKS can be bruteforced. The point is to make it as difficult and time-consuming as po
  5. My question still stands: WHY IS UNRAID STORING MY SECRET PASSWORD IN PLAIN TEXT? If I am not using a keyfile, then why do I have to delete a keyfile every time I start the array? So now I not only have to enter the password, I have to remember to delete the keyfile as well even though I don't use one? And I should add that it needs to be securely deleted by overwriting with random/cryptographic data to prevent data leakage. And how many other Unraid users have their key exposed and don't know about it because they never poked around? LUKS is very secure, but Unraid effectively mak
  6. That's entirely different. I do NOT "autostart" my array with a keyfile. As I said, I use ONLY A PASSWORD, not a keyfile. I specifically enter my LUKS password after each boot. That password should be secret. Unfortunately, Unraid then stores that secret password in plaintext on the system.
  7. I understand /root is in RAM, but it is still setup as a file system and is accessible via simple built-in commands. Even someone who has never used Linux before can obtain the LUKS password in 2 seconds with a simple "cat /root/keyfile" and BAM! LUKS password displayed and entire array encryption compromised.
  8. I just came across the file /root/keyfile that stores my LUKS drive encryption password in plaintext. Why??!? I am not using a keyfile; I am using a password only. I thought that password was secure only to find it written out in plaintext on my server. This is a huge security hole. I tried deleting the file, but it is recreated on each startup. Why would Unraid store the LUKS password in a plaintext file? Why store it all? Why not just keep it exclusively in memory? Most importantly, HOW DO I PREVENT /root/keyfile FROM BEING CREATED AT EACH STARTUP?
  9. Do you have exporting to custom location working? if so, would you post the scripts you made? I can't have filenames exported to the unencrypted USB drive because the actual filenames might include sensitive information.
  10. This is getting a bit off-topic for Unassigned Devices, but here's what I've discovered. My motherboard has 2 built-in Realtek 8111C LAN controllers. I have these setup as a bond (802.3ad link aggregate), and I have bridging enabled. I had set my "Desired MTU" in Unraid as 9000. However, the Realteks only support 6128 max (as evidenced by bonienl's find in the logs). In 6.5.3, Unraid drops the invalid 9000 and sets the Realteks, bond, and bridge to the standard 1500. In 6.6.x, Unraid sets the Realteks and bond to 1500, but sets the bridge to 9000. If I set the Des
  11. Finally something useful! THANK YOU, boneinl! Disabling jumbo frames and reverting to 1500 MTU fixed it! I might go back and bump up to 6000 (everything else on my network supports at least that). I might even revert back to 6.5.3 to see what the MTU is there. Perhaps an updated driver lowered the max. But for now it works. Thank you! Thank you! Thank you! I didn't know should have been keeping records to prove other people had issues back when I spent days researching this back in October, but a quick search pulls up: "WonkoTheSane" posted in this thread starting o
  12. I should add that I've been a computer programmer since the 1980s. I currently run my own IT company. I haven't done much Linux programming, but I am familiar with the OS. I am well-versed in client/server and networking protocols. My network switch is a smart switch. I can run Wireshark if we need. I'm ready to go. You want to troubleshoot? Limited time offer, though. I can't afford to skip backups forever. (You can message me privately if you want to avoid clogging this thread with troubleshooting this one issue.)
  13. My servers are NOT going offline. That is EXACTLY the finger pointing that I described back in December in this thread where you responded saying you haven't seen any finger pointing. Let me make this clear: MY SERVERS ARE NOT OFFLINE. I HAVE NO NETWORK ISSUES. My backups with the Duplicati docker have been rock solid since I started them a year ago. Back in October I upgraded to 6.6.x (tested 6.6.0 through 6.6.3) with no changes to my NAS devices or network. Unraid 6.6.x FAILS EVERY TIME with a timeout. Every backup failed for an entire month while I researched and troub
  14. I finally have some downtime where I'm not in need of regular backups can work with you to troubleshoot this. Previously, I have been running 6.5.3 using a Duplicati docker to backup my Unraid files to old Netgear ReadyNAS NV and NV+ mounted with Unassigned Devices using SMB. When I upgraded to 6.6.x, my NAS devices would drop from Unassigned Devices when my Duplicati backups ran. Logs show the mounts timed out and Unassigned Devices would show them mounted with a 0/0 byte count. I switched the shares to NFS. Same issue. I tried multiple versions of Unraid (6.6.0, 6.6.1, 6.6.2, 6.6
  15. This is a problem with Unraid 6.6.x. I spent a lot of time researching this, and Lime Tech tells you it's a third-party plugin and to contact Unassigned Devices. Unassigned Devices tells you that your remote server is offline or you have network issues. That's not the problem. Unfortunately, I don't know what the actual problem because everyone points fingers somewhere else. The fact is that numerous people have issues with drives dropping from Unassigned Devices when using Unraid 6.6.x. Affects both SMB and NFS. Mapped drives suddenly drop during moderate or high usage. The only s