• 0 Posts
  • 12 Comments
Joined 3 years ago
cake
Cake day: June 18th, 2023

help-circle
  • Your first concern should be your boundary firewall. You should have all ports closed except the ones that you are definitely using for external services. You should know which ports you have open and why, and what traffic, how much and how often you expect to see on those ports (8080 will have regular Internet use traffic, but your reverse proxy port should only have traffic when you’re away from home and actively using it), and you should monitor that traffic at the firewall every so often, and especially when you make changes to your network. Closed ports should be configured to drop packets rather than respond that the port is closed (stealth mode). On a home network, preventing unwanted incoming connections will protect you from the majority of malicious activity. It’s the most effective single thing you can focus on.

    The next thing would be to separate untrusted devices onto dedicated VLANs. This would be for IoT devices, gaming consoles, “smart” appliances, anything that connects to the Internet whose software you don’t have control over. They get isolated on a VLAN that only connects to the Internet and doesn’t allow local connections to devices on other VLANs, so the rest of your network doesn’t exist as far as they’re concerned. This should cut down on things like “smart” appliances taking inventory of your home network and reporting it back to the manufacturer’s servers.

    If you do these two things, and you’ve got your reverse proxy configured properly so that other people can’t break into it, you should minimize unwanted connections to your network and your server/containers should be fine with default internal firewall policies. The only reason you would need to do more is if you expect a direct/intentional attack by a motivated hacker, but in that case there’s not much you can do unless you’re an expert.

    If you want to go further, try implementing the community version of runZero:

    https://www.runzero.com/platform/community-edition/

    https://help.runzero.com/docs/self-hosting/

    https://www.cisa.gov/resources-tools/services/runzero-community-edition

    This is a network visibility tool that will discover and identify devices. To get a really complete look, you would run it from inside your network and deal with anything that you don’t think should be accessible, then run it again from outside your network to see what a potential attacker would see.


  • More specifics are needed for a support request. Provide the baseline specifications please.

    What OS are you using? What is the make and model of the drive? Is it internal or external? USB? SATA? SAS? NVMe? A PCIe adapter? Is this a desktop, laptop, NAS, server, NUC, Raspberry Pi with an expansion board?

    For all we know you’re using a refurbished and relabeled SAS drive plugged into an adapter on an eSATA port on a 10 year old motherboard sitting in a cardboard box.

    Are you familiar with SMART? Have you done any diagnostics?



  • I wonder what you are securing against?

    OK, you’re familiar with vulnerability scanners and port scanners right?

    The threat model here isn’t really attackers specifically targeting your home network for any particular reason (unless you’re a LastPass engineer working remotely while running an exposed Plex server). They’re not looking for you, they’re looking for anything useful.

    The threat model is attackers using scanning tools to discover vulnerable systems connected to the Internet. All they need from you is an active connection and a system that can store data, from which they can host malware files for distribution to other targets or conduct attacks or just run a cryptominer (if you’re lucky and they’re not very ambitious). They can find this by scanning for open ports and then running a vulernability scanner to figure out if there’s some exposed hardware that can be exploited.

    An unsecured system is a hazard that could land you in jail when someone else starts using your device and network connection to commit crimes.

    Now, as long as you’re behind a standard residential network service, and your ISP is in control of your gateway device, you’re relatively safe from this. Most ISPs will block any traffic like that very strictly. If your ISP is in control of your gateway device then they’re responsible for its behavior (demarcation matters).

    But, most self-hosters run into limitations with their ISP blocking a lot of ports by default, because they want to access their personal server from outside their home, and so they take control by running their own gateway device or paying for a business connection which gives them complete control over which ports are open. This is where the risk comes in. You are assuming the responsibility for properly securing your connection to the public Internet, taking it off your ISP’s hands.

    If you’re going to do this, you should know exactly which ports you have open to the outside and why, and a general idea of what traffic you expect to see on them when and how much. Monitor that traffic at your firewall. Every other port should be closed and your firewall (on your router, gateway device, or better yet a dedicated OPNSense firewall) should be configured to drop packets received by closed ports (“stealth” mode). You don’t want it to respond that those ports are blocked, you want it to appear to not be there at all.

    Every other security implementation is a secondary concern for a home network. Yes you should patch your software regularly and you should practice deny-by-default and least-privilege as a matter of course, but you’re going to mitigate 90% of your risk by just not accepting incoming connections for anything you don’t need. Most vulnerable systems are discovered by automated scanning, so the less your system responds to external connections the better. If you’re going to worry about configuring, securing and patching one device, make it that front line firewall. And be very selective about which internally hosted services you expose externally.


  • You are running into the ultimate, and ultimately unavoidable, limitation of self-hosting, which is the self.

    You should run a VM on the VPS for Vaultwarden, with no other services in the VM except whatever you need to connect to it remotely. Keep it simple. Run an exact copy of the VM on your local server. Have the VPS instance push its database to the local instance regularly, to keep up with any changes that your users make. Make regular backups of the local instance.

    When you need to update the software, freeze an image of the local VM and then update the local VM, then when you’re sure it’s stable, copy the updated local VM to the VPS. If either the local or VPS instance crashes out, you should be able to recover (or reproduce) one from the other.

    In the end though, it is functionally impossible to ensure reliability by yourself. Hosting Vaultwarden on a VPS shifts the responsibility for running the underlying server and network connection to the provider, and probably removing the dependence on your residential network connection will be better for your family/users.

    You are still the weak point in your system. You need someone else who can log in to your local server, and into the VPS, and perform recovery if needed. There is no technical solution for this. You cannot be the sole admin, and also ensure reliability for other users.





  • No, we’re talking about companies scraping hundreds of millions if not billions of labor hours of output to train their models for the sake of developing software products which they then sell for profit.

    Every model that was trained on legally acquired free public data and open source code should be freely publicly available and open source.

    Every model that was trained on not legally acquired public data (e.g. Meta’s models) should be taken out of production until all of the lawsuits are concluded, and hopefully the parties responsible are put out of business.

    I’m not talking about future, potential labor that AI might replace. I’m talking about the labor which was stolen to produce these models in the first place.

    But, please use AI.


  • Please identify the issues with the LLM generated code.

    Why would the issues be obvious and easy to point out? Most issues with code aren’t. If they were, we wouldn’t have Patch Tuesday, a direct code review would prevent issues from shipping in the first place.

    Throwing this out as if it means LLM code is acceptable and ends the argument is ridiculous. Do you have any grasp of how software vulnerabilities are discovered at all?



  • The core problem with this approach is that antivirus scanning is generally based on signature recognition of malicious binaries. Behavior-based antivirus scanning mostly doesn’t work and tends to generate a lot of false positives. No freely available antivirus is going to have a signature library that is kept up to date enough to be worth the effort of running it on Linux - most vulnerabilities are going to be patched long before a free service gets around to creating a signature for malware that exploits those vulnerabilities, at which point the signature would be moot. If you want antivirus that is kept up to date on a weekly or better basis, you’re going to have to pay for a professional service.

    That said, there are other, simpler (and probably more effective) options for hardening your systems:

    • Firewall - if your servers are dedicated to specific services and you don’t plan on adding many more applications, you should be able to tighten up their firewalls to have only the ports they need open and nothing else. If network security is a priority, you should start with this.
    • Application Whitelisting - prevent unrecognized applications from running. There are more options for this on Windows (including the builtin Applocker), but there are some AWL options for Linux. It’s a lot easier to recognize the things that you do want to run than all of the things that you don’t want to run.
    • Secure OS - I assume you’re using Debian because it’s familiar, but it is a general-purpose OS with a broad scope. Consider switching to a more stripped-down variant like Alpine Linux (it can be installed on a Pi).