[HN Gopher] Command injection and backdoor account in D-Link NAS...
___________________________________________________________________
Command injection and backdoor account in D-Link NAS devices
Author : campuscodi
Score : 187 points
Date : 2024-04-07 11:39 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| tmoertel wrote:
| Ask HN: Are there any hardware manufacturers that can be relied
| upon _not_ to have big security problems?
| hwbunny wrote:
| D-Link always was an almost trash kinda company.
| wepple wrote:
| Amazon, Apple, Google tend to ship hardware that at least
| doesn't having gaping 1997 style vulnerabilities everywhere.
|
| Cisco have had some doozies but overall aren't terrible.
|
| Everything else is probably bad.
| jwells89 wrote:
| I wish Apple hadn't dropped out of the router business. The
| only good replacements all seem to be considerably more
| involved, e.g. a full Ubiquiti setup or one of the more
| mainstream routers with third party firmware. AirPorts were
| excellent for shoving into a corner and not having to think
| about aside from the odd firmware update every few years.
| rfoo wrote:
| What kind of hardware? For home networking? Ubiquiti is okay.
| As bugs in these enterprise/SMB networking gear worth a little
| $$$ so there's at least people looking for low hanging fruits.
|
| The best option however, is to find a recent MediaTek-based
| (because they are currently the most upstream-friendly WiFi AP
| SoC vendor) home router with vulnerable firmware (for easier
| flash lol) and replace the firmware with OpenWRT.
|
| For NAS just build your own, or buy used rack-mount servers off
| eBay and leave them in basement.
| candiddevmike wrote:
| Use generic hardware or build your own, and install an OS you
| can manage yourself
| mtlynch wrote:
| These problems all go away if you don't expose crappy
| management software directly to the Internet.
|
| Don't allow anonymous inbound traffic on your firewall to hit
| your NAS (or any other interface that you're not updating and
| monitoring rigorously).
|
| If you need remote access to your NAS, install a VPN (e.g.,
| Tailscale, ZeroTier) on the NAS or a different host on your
| internal network, and then access it remotely over an SSH
| tunnel.
|
| I understand that the casual home user doesn't know how to
| install a VPN or do SSH tunneling, so they end up exposing
| their NAS through the firewall, and that's why these issues are
| widespread. But for people who are a bit more technically
| savvy, you can massively reduce your attack surface by denying
| any inbound connections through your home firewall.
| kevincox wrote:
| While "don't let any possible attacker see the device" is
| good defence in depth it is a pretty shitty only level of
| security. Even if it is protected outside of your local
| network many people have crappy IoT devices or even just
| laptops with malware on their network.
|
| In top of that this won't even really prevent this
| vulnerability as it can be triggered by a GET request. This
| means that if you are connected to the VPN any site you visit
| can trigger it. (If they can guess the hostname or IP)
| Dalewyn wrote:
| >crappy IoT devices
|
| Those should all go on their own vlan, or for a more Joe
| Average(tm) approach the guest network.
|
| >laptops with malware on their network.
|
| At that point you've got bigger fish to fry than shitty
| firmware, all bets are off.
| kevincox wrote:
| Why are all bets off if you have malware on my network.
| My devices are hardened with the expectation of being on
| hostile networks. My computers, phone and home server all
| assume that they are exposed to malicious actors. Of
| course defence in depth is also important, but there is
| no reason that all bets should be off if an attacker can
| access your device over the network.
| Dalewyn wrote:
| Do you consider yourself a malicious actor to yourself?
| Because that's what you're saying.
|
| I am assuming the hypothetical compromised laptop is your
| own, and thus assuming it contains credentials.
|
| What credentials? Everything. All your credentials are
| belong to us.
|
| At that point, the only way to defend against that is to
| have never trusted yourself. That's a ridiculous stance
| for any normal person; their home network is a trusted
| space.
|
| That's why I'm saying all bets are off, you have bigger
| fish to fry than caring about some shitass firmware
| written by some third rate bank clerk in Bangladesh in a
| plastic box made by the finest sweatshops in China.
| kevincox wrote:
| Why would you assume the compromised laptop is my own?
| What if I have roommates? Or a friend comes over for a
| LAN party? I want them on my real network for Steam game
| transfers and game traffic. Maybe I want them to pull
| mods off of my NAS.
| Dalewyn wrote:
| In that case, yes that network isn't a home network and
| should be untrusted as such.
|
| Personally were I in your situation, I would have
| individual computers for each network as needed for total
| and proper segregation of trust; a NAS for the home and a
| NAS for the public (eg: LAN party) network. I would not
| trust a single computer with all sorts of data to safely
| handle two wildly different levels of trust
| simultaneously like that.
|
| I consider the home network a trusted enclave. Thus, all
| bets are off if a compromised laptop is in the home
| network. I assumed the laptop was your own as a worst
| case scenario (Credentials! In plain arm's reach!). If an
| untrusted third party laptop breached or was invited into
| your home network, that's not immediately as bad but the
| bets are still off.
|
| Basically: I see worrying about shitass firmware when you
| haven't secured the network as pointless. The
| hypothetical situation presented was a compromised laptop
| in the network; forget the firmware, you need to deal
| with that laptop and then commence cleanup of the network
| first.
| dvdkon wrote:
| We seem to have very different approaches to security.
| I'd instead say "forget about the network, you need to
| secure your servers".
|
| I fundamentally dislike "secure enclaves", since they
| amount to giving up at some point. You can instead
| _meaningfully_ exercise "defence in depth" by trying to
| keep file servers secure against unauthenticated
| attackers, or even authenticated ones; by not running
| unneeded network services on your desktops; etc.
|
| Securing one layer perfectly might be tempting, but it's
| much more work than securing multiple layers "well
| enough". In other words, "shared WPA2 WiFi + an up-to-
| date TrueNAS system + multiple accounts for different
| users" will be much less work and more practical than any
| network-only solution you can suggest.
|
| A layered approach also means that you don't need to
| worry so much about someone else's screwups. A friend had
| malware on their laptop, but didn't have credentials for
| the NAS? Not much need to worry, maybe just change the
| WiFi password and you're _probably_ fine. They had access
| to a limited account? Probably only the data on that
| account is compromised. Most times you won 't even get to
| check logs to confirm or start some top-to-bottom
| "cleanup", since you'll never know this even happened.
| fulafel wrote:
| This is the only sane way. You are then able to reason
| about impact and reasonably investigate when you
| inevitably end up dealing with a incident. Relying on a
| "trusted internal network" went out of fashion a long
| time ago.
| mtlynch wrote:
| > _While "don't let any possible attacker see the device"
| is good defence in depth it is a pretty shitty only level
| of security._
|
| If we're talking about a company, I agree. For a home, I
| think VPN + firewall is sufficient security against
| insecure management software on network devices.
|
| > _Even if it is protected outside of your local network
| many people have crappy IoT devices or even just laptops
| with malware on their network._
|
| If there's a malicious laptop within your network, what
| difference does it make if your NAS has a security
| vulnerability? If your laptop is compromised, it's game
| over anyway because the attacker can steal your cookies or
| install a keylogger. If it's a housemate's laptop that
| doesn't have access to the NAS, they can do ARP
| poisoning[0] and MitM your NAS to steal your credentials
| (unless you're also vigorous about managing your own TLS
| CA).
|
| > _In top of that this won 't even really prevent this
| vulnerability as it can be triggered by a GET request. This
| means that if you are connected to the VPN any site you
| visit can trigger it. (If they can guess the hostname or
| IP)_
|
| Other websites can trigger the behavior, but they can't
| read any responses because of same origin policy, so they
| can't exploit anything.[1]
|
| Correction: I overlooked in the writeup that the GET
| request allows RCE. So, you're right is that malicious
| websites can exploit this despite SOP. Still, firewall +
| VPN reduces your risk by many orders of magnitude. Instead
| of the attacker trivially scanning for your device or
| looking it up on Shodan, they have to trick you into
| visiting a malicious site.
|
| [0] https://en.wikipedia.org/wiki/ARP_spoofing
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/Security/Same-o...
| kevincox wrote:
| > they can do ARP poisoning[0] and MitM your NAS to steal
| your credentials (unless you're also vigorous about
| managing your own TLS CA)
|
| All traffic to my NAS is secured, even over the local
| network. I don't trust the network and I don't think it
| should be game-over for my NAS because my housemate
| installs some malware. I use SSH with pinned keys and TLS
| (thanks Let's Encrypt).
|
| I think if any NAS appliance doesn't provide some basic
| security like this it is a failing of that vendor. Even a
| self-signed TLS cert to provide TOFU validation would go
| a long way. (And actually in many ways be more secure
| than a public CA issued certificate.)
| mtlynch wrote:
| I guess I'm not really sure what you're advocating.
|
| These measures sound good for you, but what percentage of
| HN readers can do that? How many threats does it
| eliminate in practice beyond what you'd get from basic
| VPN + firewall?
|
| There's always additional security measures you can take,
| but the costs go up and the marginal benefits go down.
|
| It's a bit like saying it's not sufficient for other HN
| users to deadbolt their doors because it's weaker than
| the armed guards that patrol your property 24/7.
| kevincox wrote:
| Well what are you advocating? It seems like you are
| suggesting that device security isn't important because
| it is hard to do and a firewall will solve most problems.
|
| But at the same time we are looking at a vulnerability
| that works through a firewall.
|
| I am just suggesting that even in a presence of a
| firewall we should expect appliances to be secure on a
| hostile network. That is the standard we should hold
| vendors to. Much like Android, iOS, Windows and macOS
| hold themselves to this standard.
|
| I'm also not saying that you should test this standard,
| defence in depth is very valuable. But I don't think
| saying "it is hard and a firewall solves many issues" is
| a good reason to forgive these vendors for shit security.
| mtlynch wrote:
| > _Well what are you advocating? It seems like you are
| suggesting that device security isn 't important because
| it is hard to do and a firewall will solve most
| problems._
|
| I'm advocating firewall with no inbound traffic + VPN for
| remote access. It mitigates most of the risk of devices
| on your network having security vulnerabilities.
|
| My original comment in this thread was that it's more
| important to firewall + VPN your network than it is to
| pick a network appliance with a good security record.
|
| I agree that there certainly are additional precautions
| you can take, but I think firewall + VPN defends against
| most practical attacks the average HN user would
| encounter.
|
| Firewall + VPN is something a large proportion of HN
| (40%?) is capable of doing with about an hour of effort.
| I think it's a pretty small segment of HN that's even
| capable of the precautions you're talking about (separate
| VLANs, custom certificates, hardening every host), and it
| would take person-days of effort to replicate.
|
| > _But I don 't think saying "it is hard and a firewall
| solves many issues" is a good reason to forgive these
| vendors for shit security._
|
| I don't forgive vendors for shit security. I agree with
| you that we should hold vendors accountable. RCE on an
| unauthenticated GET request is absurdly incompetent and
| irresponsible, and D-Link deserves punishment. That said,
| I'm not in a position to influence D-Link, but I am in a
| position to help users protect themselves if appliances
| on their network have mistakes like this.
| asveikau wrote:
| > For a home, I think VPN + firewall is sufficient
| security against insecure management software on network
| devices.
|
| If you have some iot devices which phone home on the same
| network, then this theoretically could be a vector. It
| can be hard to know if that's the case.
|
| On the more paranoid side, be sure your guest wifi can't
| access these devices.
| amluto wrote:
| There are two _major_ problems with this approach:
|
| 1. With gadgets like this, the gadget is likely to be your
| firewall.
|
| 2. You are almost certainly running a sandboxed agent inside
| your firewall that runs untrusted code: your web browser.
| CSRF attacks taking over crappy devices like the devices in
| question are a thing.
| wepple wrote:
| This advice massively reduces the largest risk, but "problems
| all go away" is wildly wrong
|
| There are a ton of remote access and update functionality in
| these things that make them fully exploitable even with no
| internet exposure.
|
| Theyll do crazy things like VPN back to home servers, where
| every single device is on a flat /8 with no additional
| security. So anyone who dumps the VPN keys from one is
| basically on your eth.
|
| Or update unsigned firmware from domains that end up
| abandoned and left hanging
|
| Etc etc
| mtlynch wrote:
| > _This advice massively reduces the largest risk, but
| "problems all go away" is wildly wrong_
|
| By the problems all go away, I meant the problems
| associated with a network appliance handling malicious
| input that leads to a security issue. If the device isn't
| exposed to the Internet, it can't bungle malicious input.
|
| > _Theyll do crazy things like VPN back to home servers,
| where every single device is on a flat /8 with no
| additional security. So anyone who dumps the VPN keys from
| one is basically on your eth._ > > _Or update unsigned
| firmware from domains that end up abandoned and left
| hanging_
|
| Are there cases of that happening with products that have
| wide usage? Like 1M+ devices in the field?
|
| The only time I can recall hearing of anything like that,
| was for a very small time vendor.[0]
|
| Every security vulnerability I've heard about around NAS
| devices required the device to be exposed to the public
| Internet or for the attacker to be on the same local
| network as the vulnerable device.
|
| [0] https://news.ycombinator.com/item?id=34325695
| wepple wrote:
| Yeah, there have been a bunch. The last one I remember
| was a fairly well used security camera. VPN was how they
| streamed video back to storage. A really "simple"
| solution to turning a LAN-based video camera into an
| internet-connected one.
|
| I'll see if I can drag up some references, a quick google
| doesn't show what I'm looking for.
| panja wrote:
| Use your own hardware and something like Unraid
| tomaskafka wrote:
| Mikrotik seems to be pretty regularly updated, even old devices
| - assuming they're not NSA frontend :)
| arp242 wrote:
| To the best of my knowledge there has never been a remote
| exploit for a Commodore 64.
| basementcat wrote:
| Morning standup at a state sponsored hacking organization.
|
| Bob: I hope everyone had a good weekend. I'd like to start
| out by giving some kudos to Fred and Jane for the D-Link NAS
| back door!
|
| A round of polite clapping.
|
| Bob: Let's start with Igor, how's it going?
|
| Igor: Bah, my target is running web server on Commodore 64 so
| I spend all weekend to write 6502 remote exploit for Contiki
| OS. Unfortunately, I found out target keeps secrets on ZX81
| but I don't know Z80 assembly.
|
| Bob: Fortunately we're a state sponsored hacking organization
| so we have considerable resources. Federico, do you think you
| could give Igor a hand?
|
| Federico: Certamente!
| jqpabc123 wrote:
| Short answer --- no.
|
| The key term here is *hardware manufacturers*.
|
| They have no financial incentive to worry too much about
| software. The solution to every problem is to buy new hardware.
| Software bugs are just added incentive.
| GEBBL wrote:
| How did this pass code review?
| mmsc wrote:
| What code review?
| hwbunny wrote:
| Exactly.
| riedel wrote:
| Walter Shao [0] says lgtm... (There is simply little awareness
| and not even minimum standards in the industry)
|
| [0]
| https://forum.qnap.com/viewtopic.php?f=45&t=160849&start=450...
| steve1977 wrote:
| ouch...
| cqqxo4zV46cp wrote:
| This is completely usual for IoT/networking devices. It's the
| longstanding reality. They just come at this stuff differently.
| codedokode wrote:
| As I understand, the problem is that authentication used users
| from /etc/passwd and allowed to log in as any user, even as
| system user like "messagebus" which has no password. It is
| annoying that linux software uses system database for
| authorization, for example, Postgres and Samba do this and there
| is always a risk that you have some system user you don't know
| about which can be used to access your system.
| cqqxo4zV46cp wrote:
| Yeah. It's a pretty old-hat way of thinking. The 'unified
| authentication database' ship sailed long ago, for better or
| worse.
| candiddevmike wrote:
| Unraveling this and dumping NSS would probably have a
| measurable increase in security and isolation. A backdoor xz
| thing in libnss would be catastrophic.
| duskwuff wrote:
| You're probably thinking of PAM (passwords and
| authentication), not NSS (hostname lookup). Both are direly
| in need of modernization, though.
| segfaultbuserr wrote:
| "No password = locked account" is today's default policy on
| most systems, for a reason.
| jesprenj wrote:
| Not really. To be really sure, set ! as a password in
| /etc/shadow. That's what most distributions do. PAM has
| another security measure, if user's shell is not in
| /etc/shells, it's also considered a locked account and will
| not allow login.
| segfaultbuserr wrote:
| Of course, follow the best practices if you want to be
| really sure, e.g. set the password field to "!" so it's
| invalid, set the shell to /sbin/nologin, set the home
| directory to /dev/null (doesn't really do anything but it's
| a convention), etc, etc, etc. The "must have password"
| policy is for preventing accidental mistakes by people who
| don't know anything about what we just said, and my
| experience is that it's an effective one.
| 0x0 wrote:
| Setting the home directory to a special device node file
| "/dev/null" sounds like a good way to shoot yourself in
| the foot, and I've never heard of this practice before.
| On Debian, at least, it seems like setting the home
| directory to "/nonexistent" is more common.
|
| For example, running "deluser" later could end up
| performing a "remove home" cleanup operation, and you
| certainly don't want to remove the /dev/null file.
| TacticalCoder wrote:
| Yup and for outgoing traffic firewalling rules can also be
| put in place to only allow users authorized to emit
| traffic. Drop or reject anything by default, then only
| allow some users to send packets (like "john" and "_apt"
| [to update packages], etc.).
|
| It's not incompatible with the other measures you
| described.
|
| FWIW I also log, for every "user" on the system, anything
| from a user that's not supposed to access the net.
| okl wrote:
| Samba has its own user DB with the default auth backend and
| allows per share restrictions. Same with Postgres. "PostgreSQL
| database user names are logically separate from user names of
| the operating system in which the server runs."
| [https://www.postgresql.org/docs/current/client-
| authenticatio...]
| jra_samba wrote:
| Samba doesn't use the passwords or users in /etc/passwd
| directly. You have to map any SMB users into /etc/passwd users
| in Sambas database. Without that mapping they don't exist for
| Samba.
| jcpham2 wrote:
| When my bosses want to know why a quote for a device like a NAS
| is thousands and thousands of dollars instead of hundreds of
| dollars I use examples like this.
|
| Running consumer gear, especially public facing internet consumer
| gear is just asking for trouble.
|
| TrueNAS/FreeNAS whatever it's called these days - a real OS with
| real vendor and community support keeping the project alive and
| up to date is just necessary.
|
| Buying these consumer devices that are set and forget with
| limited or zero firmware updates is BAD. Not to mention the code
| quality and unknown closed source backdoors
| lyu07282 wrote:
| > TrueNAS/FreeNAS whatever it's called these days - a real OS
| with real vendor and community support keeping the project
| alive and up to date is just necessary.
|
| and for routers there is OpenWRT. For example Turris is built
| on that and provides automatic firmware updates, that's a huge
| security benefit for those devices:
|
| https://www.turris.com/en/
| jcpham2 wrote:
| Huge OpenWRT fan I'd almost even be tempted to deploy an
| OpenWRT device somehow as a NAS over any prebuilt consumer
| device.
|
| It's build it yourself (and get what you pay for) or buy junk
| and similarly roll the dice.
|
| It's not a terrible difficult value proposition to explain
| but there's always the person in the room that knows just
| enough to not know this is something you do not introduce on
| your corporate network; you leave it home tucked away behind
| a firewall
| yjftsjthsd-h wrote:
| > I'd almost even be tempted to deploy an OpenWRT device
| somehow as a NAS over any prebuilt consumer device.
|
| No ZFS, but it appears to support mdadm and btrfs so that
| could work if you can get good hardware for it.
| cqqxo4zV46cp wrote:
| Have I woken up in some universe where the word "backdoor"
| doesn't mean what it used to? I am used to backdoor implying
| malicious intent on the part of the vendor / author, or something
| left by an attacker. I'm just not seeing that here. This just
| looks like utterly unsurprising incompetence on the part of a
| consumer networking / IoT gear manufacturer. Yes, I know what a
| literal 'back door' is, and yes, I know that "make it look like
| incompetence" could be a strategy. I'd partially blame people
| being all hot and bothered about xz, but I can see that these
| files were committed two weeks ago.
| rfoo wrote:
| > This just looks like utterly unsurprising incompetence on the
| part of a consumer networking / IoT gear manufacturer.
|
| Then how about Xiongmai NVRs [1]? Can I say it's just an
| incompetently implemented debug feature left enabled in
| production?
|
| [1] https://habr.com/en/articles/486856/
| II2II wrote:
| I also get the impression that the definition has shifted,
| though I don't recall malicious intent from the vendor/author
| being a part of it. Classical backdoors include things like
| service accounts that were intended for the vendor, which were
| genuinely intended for service. Granted, those passwords were
| intended to be changed. (Also, that's not really appropriate
| for consumer grade gear though, since consumers have not
| received that level of support in decades and were not
| connected to networks when that level of service actually
| existed.)
|
| Either way though, I do seem to recall intention being part of
| the definition. Ah well. It's just a new meaning to get used
| to!
| BobbyTables2 wrote:
| They knowingly created a password less account because of
| their authentication system!
|
| If it isn't a true backdoor, then it is utter stupidity and
| negligence!
|
| When it comes to security, why is EOL allowed by society?
|
| We don't give 5 or 10 yr old cars a free pass to blow up or
| stop working without a manufacturer recall.
|
| Software is even easier to fix!
| II2II wrote:
| The tricky part is determining how long software should be
| supported for, at least with respect to security updates.
| I'm sure that most people would agree that 5 years is
| insufficient. Twenty five years, many would say is too
| long.
|
| As for the car analogy, it is a weak comparison. First of
| all, the owner is expected to do some upkeep. A car is more
| likely to be deemed unroadworth from a lack of upkeep as it
| is from a design flaw or manufacturer defect. The other
| consideration is that the notion of secure software is a
| shifting target. In the case of cars, physics is a passive
| adversary. In the case of computer security, the adversary
| is active. Is software security to be judged by the
| security standards of when it is developed, or of when it
| is used? The former will catch cases like this, but will
| prove ineffective in the long term. The latter will
| bankrupt the industry.
| halJordan wrote:
| I think you went to sleep in some other universe and are waking
| up in the real world where backdoor has always meant "bypasses
| the front door."
| cjbprime wrote:
| I'm surprised it wasn't "authentication bypass" too.
| NKosmatos wrote:
| The thing of interest is that although the DNS-320L, and the
| other D-Link NASes, is EOL (End Of Life), there are more than
| 90,000 devices still operating out there!
|
| The bad thing here is that many manufacturers, even big ones,
| tend to forget "old" products and drop support for them. Usually
| it's a market/business decision, but this is what happens with
| closed systems :-(
|
| Quoting from
| https://www.dlink.com/uk/en/products/dns-320l-sharecenter-2-... :
|
| >> This product was phased out on: 13/11/2017
|
| >> This product's last date of support is on: 13/11/2019
|
| Being an owner of 320L, I don't expect D-Link to offer us an
| updated firmware any time soon.
| captn3m0 wrote:
| Is there a better way to track D-Link EOLs? Would be nice to
| have this up at the endoflife.date.
| pierrec wrote:
| >I don't expect D-Link to offer us an updated firmware any time
| soon
|
| Don't worry, some botnet will infect all of these and fix the
| vulnerability in order to prevent competing malware from
| gaining access. This fix will deploy within an impressively
| tight timeline.
| bchanudet wrote:
| Sometime ago I found an alternative "OS" for my DNS-320L called
| Alt-f [0]. Granted its UI is very old-school but it has worked
| flawlessly. There has been no release since 2022 but at least
| it's more recent than the last official firmware (and I assume
| is not impacted by the vulnerability).
|
| IIRC I didn't even had to format or move the data I had on it
| before installing.
|
| [0] https://sourceforge.net/projects/alt-f/
| speedylight wrote:
| I see IoT devices are still the weakest link in any network.
| TacticalCoder wrote:
| > I see IoT devices are still the weakest link in any network.
|
| That's why IoT stood for, since the very beginning, for _"
| Internet of shitty insecure Things"_ : )
| fx1994 wrote:
| I bought used DNS-320L and first thing is to load it with ALT-F
| alternative firmware. Worked great but device was too slow for my
| needs.
| starky wrote:
| I'd assume that every consumer NAS device is insecure these days.
| I had a Terramaster NAS and was hit with a ransomware attack
| because of the poor security of their OS through a feature I had
| turned off. It caused me to look into it more and realized that
| all of the consumer NAS devices have had similar security issues.
|
| You are far better off getting cheap hardware and running TrueNAS
| or Unraid on it as they actually get regular software updates and
| don't have a history of major security issues.
| 0x073 wrote:
| Terramaster is a cheap young Chinese nas brand.
|
| Never had issues with Synology.
| starky wrote:
| As I said, while that was the brand I had, brands like QNAP
| and Asustor have also had the exact same issues. These
| devices are all just examples of poorly supported hardware,
| where a solution where you control the hardware and software
| installed on it is far more likely to be supported going
| forward.
| syntaxing wrote:
| QNAP is known to have garbage security though. I personally
| have a Synology NAS with no internet access (blocked using
| my firewall)
| ajross wrote:
| > You are far better off getting cheap hardware and running
| TrueNAS or Unraid on it as they actually get regular software
| updates and don't have a history of major security issues.
|
| Unpopular opinion: really you'd be "far better off" using
| Dropbox or Drive or whatever. By demanding to store your junk
| yourself you've already walked away from the clearly most
| robust solution.
|
| Obviously this will engender the standard HN freakout about
| privacy and Big Tech and whatever, and I won't engage. But at
| the narrow level of robustness and security, the cloud experts
| are going to do this objectively better than anything under
| your personal control, probably by more than an order of
| magnitude.
| derekp7 wrote:
| You are leaving out the other primary reasons for a local NAS
| -- upload bandwidth, data caps, and special usage scenarios.
| Not to say that cloud-hosted solutions purely for backup
| purposes don't have their place, but it is just one component
| of a 3-2-1 backup policy.
| beeboobaa3 wrote:
| Have you seen how much those services charge for even just
| 10tb of storage? It's insane.
| ajross wrote:
| Looks like $15 a month at Dropbox (it's true that the other
| providers don't count that high[1] in their standard rates,
| so you end up having to do it as more expensive overage).
| Seems like a bargain for not getting backdoored to me. But
| then I did say it was an unpopular opinion.
|
| [1] I do chuckle at the use of "just 10tb". Obviously the
| real issue here is that these NAS boxes are deployed in
| service of movie and porn collections that people don't
| want to leave with a third party. But my point was about
| reliability and security, not legality or propriety.
| beeboobaa3 wrote:
| From what I can tell dropbox will charge you
| E14.50*3=43.5/month (Business plan with a minimum of 3
| users) or E522/year for 9TB, but maybe I'm missing
| something in their pricing?
|
| > I do chuckle at the use of "just 10tb"
|
| It's 2024. 2TB SSDs can be bought cheaply, and so can
| 16TB HDDs.
| IshKebab wrote:
| Yeah but the fact that you can buy a 10TB disk doesn't
| mean it's normal to need to store 10TB of data.
|
| I think bandwidth is a bigger issue with cloud storage.
| Most people have terrible upload bandwidth.
| aborsy wrote:
| Dropbox speed is low. Even in Dropbox plus, ordinary
| features are behind paywall. Not interesting.
|
| Also, it's not a good idea to store TBs of personal
| information on someone else's computer or potentially the
| internet.
| arp242 wrote:
| It shows "EUR12/user/month" for Business (9TB), but
| that's with a 3 user minimum, so EUR36/month. The
| "Essentials" package for individuals is EUR16.58/month,
| but has only 3TB of storage. I don't know what it would
| cost to add extra storage for that (doesn't show a
| price), but I would be surprised if it was less than
| EUR25/month, and wouldn't be surprised if it was quite a
| bit more than that.
| starky wrote:
| Those aren't an equivalent solution at all. A NAS is for
| storage of lots of data, even the biggest options from the
| companies you mentioned wouldn't provide as much data as I
| have on my NAS. If I were to host the data in a real solution
| for larger amounts of data such as with Backblaze I'd have to
| pay nearly $1000/year.
|
| There are multiple different tiers of data that I keep: on
| device, encrypted snapshots, cloud, and NAS. There is
| differing amounts of money and effort I'm willing to spend
| depending on the type of data, but no one solutions is
| sufficient for everything.
| dvngnt_ wrote:
| seems pretty cheap tbh
| lupusreal wrote:
| If you're using a NAS as regular storage as I do, having it
| on your LAN gives you _far_ superior performance. NFS exposed
| only over wireguard is secure enough for me and I 've never
| had any worries about "robustness".
|
| Inb4 the old "dropbox/ftp HN suggestion" meme. I'm not
| recommending my setup for common users, or even for you. It
| suits my needs and that's all that I really care about.
| Ao7bei3s wrote:
| Unraid is not confidence inspiring either. It's just more
| commercial closed source software, developed behind closed
| doors and with a slow update cadence (~3 months). They have
| made questionable security choices anywhere you can see, and I
| have strong doubts that their code quality is any better.
|
| The PHP scripts certainly are a horrible mess, in all ways. For
| example, shell injection prevention is based on using
| escapeshellarg at each call site... that pattern is _exactly_
| the structural root cause for vulnerabilities like the one
| D-Link had.
|
| In no particular order, and obviously not exhaustive:
| Everything runs directly as root - nginx, php-fpm, smb, ... No
| AppArmor/SELinux. There is no Secure Boot support (especially
| unfortunate since boot is from USB stick). No HTTPS access to
| web frontend by default. SMB protocol defaults are insecure.
| SMB shares default to public. SSH allows password-based root
| login. Pools are unencrypted at rest by default. They have a
| checkbox to enable telnet for management! Very permissive
| iptables rules. Almost any features that real competitors like
| Synology would officially provide come from third parties via a
| moderately shady app store.
|
| Note it's not about any of these individual points. I see above
| as signal that they are not security experts and see security
| as an afterthought, rather than as something that deserves a
| team of experts that specifically cares about it.
|
| (There's certainly other fields they also aren't experts in,
| like UX - their predominant UI pattern is "list of dropdown
| fields". Even in storage, one could have a longer discussion
| how their Array feature - the true core of their product -,
| compares to modern solutions. There's a reason they've evolved
| cache pools to just pools as a separate thing, and some users
| do pool-only Unraid...)
|
| That's all quite understandable since it's a small team with
| only 2-3 coders (https://unraid.net/about). But nevertheless.
| ffsm8 wrote:
| > _Everything runs directly as root - nginx, php-fpm, smb,_
|
| For the record: you _need_ root on Linux to open ports below
| 1000. By necessity, these programs _need_ at least one thread
| that runs as root just from that.
|
| Can't comment on the rest. As I never used it. Fedora server
| + cockpit UI was enough for me when I switched from my
| Synology NAS the other day
| matthews2 wrote:
| You can drop root after binding, or you can use
| capabilities to allow a particular program to bind on
| privileged ports. php-fpm could listen on a UNIX socket
| instead of a TCP socket.
| Ao7bei3s wrote:
| Exactly. A more modern secure approach is to let the init
| system open the socket and pass it as an FD. This has
| some side benefits too (not even temporary root for
| daemon, less custom code, standard&declarative config,
| socket activation).
|
| (Of course Unraid, being based on Slackware, has a legacy
| init system that doesn't support this scheme. But there
| are enough other options.)
| arp242 wrote:
| You can use cap_net_bind_service to bind ports <1024. You
| can listen on >1024 and redirect in iptables, or even with
| a trivial TCP proxy.
|
| There are options on pretty much any system, but certainly
| on Linux with capabilities. None of these require direct
| support from the application (dropping root after binding
| does).
|
| You almost never need to run anything as root, especially
| not with these "run 6 different types of services in a box"
| type of appliances.
|
| None of this is new; this was already widely considered
| best practice when I was starting out 25 years ago.
| duskwuff wrote:
| > There are options on pretty much any system, but
| certainly on Linux with capabilities.
|
| If you're using systemd, you can grant the appropriate
| capability to the process by setting:
| [Service]
| AmbientCapabilities=CAP_NET_BIND_SERVICE
|
| in its service file. Note that this will necessarily
| allow the process to listen to _any_ port; there is,
| unfortunately, currently no way to lock it down to a
| single port.
| m463 wrote:
| I think people should learn how to configure their network in
| the first place.
|
| - Don't get a cloud router (ever!)
|
| - learn about vlans and use them.
|
| - never hook a critical device like a NAS to the wider internet
| eigenvalue wrote:
| I'm surprised that there aren't projects that aggregate a bunch
| of these known exploits together with these security search
| engines to find vulnerable devices and use them to create a TOR-
| like network of proxy server nodes. Presumably most of these
| vulnerable devices are running in homes of consumers with
| residential internet, making the traffic hard to identify as
| being from a VPN service. Not that I'm suggesting anyone actually
| do this since it would be highly illegal...
| tadfisher wrote:
| Why do that for free? Folks are perfectly happy to pay to be
| part of NordVPN's proxy network.
| smashed wrote:
| I've seen compromised iot devices used to run proxy servers.
| They are mostly resold on black market as residential IPs for
| web scrapping and such. Since there is a black market for it
| they mostly get resold, instead of put to use on the free TOR
| network I guess.
|
| Residential ISPs usually monitor the blacklisting of their IP
| addresses and will contact/suspend the customer once the IPs
| get listed on public black lists.
| galangalalgol wrote:
| How unlikely is it that some major iot device manufacturers
| outsource the firmware to someone who puts botnets in to
| start with? Who writes fridge firmware? Does ge or Samsung do
| that in house? Ovens? Definitely some liability there, but
| I'm not sure which way that drives it, out or in.
| srgseg wrote:
| This is why I always use an encrypted file system, where the
| encryption keys are only known to the client (and not the NAS or
| other storage provider).
| prmoustache wrote:
| I just use an old computer full of drives on which I ssh mount.
| I don't even care setting up samba these days.
|
| Even NAS distros/OSes are usually overkill for home and less
| than 5 different users. In a typical family context you usually
| only need one filesystem for each user + 1 shared fs with same
| RW for everyone.
| srgseg wrote:
| Exactly - just a Linux box, mounted with SSHFS. To be fair, I
| have spent some time over the years writing my own scripts
| for SMART alerts, but the end result is better monitoring and
| alerting than a NAS would provide.
| aborsy wrote:
| Synology DSM and apps are closed source. It's a Taiwanese
| company, and I wonder to what extent it can be trusted?
|
| Anyone has information on the security of DSM? Like, is it
| compliant for use in sensitive departments?
| bonzini wrote:
| I honestly don't know, but the fact that they give updates for
| 10 years is impressive compared to everyone else.
|
| I bought one in fall 2012 and it got the DSM 7.0 update on 2022
| or 2023; even though the UI is really really slow, it gives me
| a lot of confidence that they know what they're doing.
| wolverine876 wrote:
| Remember the recent stories about how FOSS is inherently less
| secure than proprietary systems - and because of the xz exploit,
| which was infinitely more complex? I'm trying to remember a FOSS
| system with a hardcoded, passwordless backdoor - it's a big
| world; there must be some. I almost expect a backdoor (though
| with a password!) in a consumer NAS.
|
| I don't knee-jerk reject proprietary solutions. And they might
| have an advantage if there was liability for this sort of thing.
| D-Link should be paying hefty fines for selling this obviously
| substandard, unprofessional crap to the public.
___________________________________________________________________
(page generated 2024-04-07 23:01 UTC)