How to setup my own home server and make it available to anyone?
How to setup my own home server and make it available to anyone?
I'd like to have my own server at home sorta like a home AWS.
How to set up one and make it available to anyone over the Internet? What tech specs should I buy (RAM, CPU, # of cores, operating system, etc.)?
How much does it cost to keep one running all the time?
You're viewing a single thread.
Your basic requirements are:
- Some kind of domain / subdomain payed or free;
- Home ISP that has provides public IP addresses - No CGNAT BS;
- Ideally a static IP at home, but you can do just fine with a dynamic DNS service such as https://freedns.afraid.org/ (will update your domain with your dynamic IP when it changes);
- Ideally a home ISP that allows for "bridged" mode or has a ONT device + router where you can add a switch in between and have the server directly connected to the Internet, with its own public IP, outside of your home network (more bellow);
Hardware coices:
Don’t get server hardware, use regular desktop/laptop machines as they’ll be more than enough for you. Server hardware is way more expensive and won’t be of any advantage. If you’re looking to buy you can even get very good 9-10th gen Intel CPUs and motherboards that are perfect to run servers (very high performance) but that people don’t want because they aren’t good to play the latest games.
This hardware is also way more power efficient and sometimes even more powerful than any server hardware that you might get for the same price. Get this hardware for cheap and enjoy.
If you don't require a TON of computer power some people might suggest ARM board, such as the Raspberry Pi, but be careful with those. ARM is great for power savings but compared to consumer hardware is it shit when it comes to performance and reliability. Also I personally like to avoid the Raspberry Pi and their stuff as much as possible. They've done good things for the community however they've some predatory tactics and shenanigans that aren't cool. Here a few examples of what people usually fail to see:
- Requires a special tool to flash. In the past it was all about getting a image and using etcher, dd or wtv to flash it into a card, now they're pushing people to use Raspberry Pi Imager. Without it you won't be able to easily disable telemetry and/or login via network out of the box;
- Includes telemetry;
- No alternative open Debian based OS such as Armbian (only the Ubuntu variant);
- Raspberry Pi 5 finally has PCI. But instead of doing what was right they decided to include some proprietary bullshit connector that requires yet another board made by them. For those who are unware other SBC manufacturers simply include a standard PCI slot OR a standard NVME M2 slot. Both great option as hardware for them is common and cheap;
- It is overpriced and behind times.
For what's worth the NanoPi M4 released in 2018 with a RK3399 already had a PCI interface, 4GB of RAM and whatnot and was cheaper than the Raspberry Pi 3 Model B+ from the same year that had Ethernet shared with the USB bus. If you still want ARM and you're about just serving a few websites, cloud service wtv pick a Chinese brand such as friendlyelec or rockpi. More computing for less money and a lot less proprietary BS.
Mini computers from big brands though, for 100€ you can get an HP Mini with an i5 8th gen + 16GB of ram + 256GB NVME that obviously has a case, a LOT of I/O, PCI (m2) comes with a power adapter and more importantly it outperforms a RPi5 in all possible ways. Note that the RPi5 8GB of ram will cost you 80€ + case + power adapter + bullshit pci adapter + sd card + whatever else money grab.
Side not on alternative brands, HP mini units are reliable the BIOS is good and things work. Now the trendy MINISFORUM is cool however their BIOS come out of the factory with wired bugs and the hardware isn't as reliable - missing ESD protection on USB in some models and whatnot.
Quick check list for outward facing servers:
- Isolate them from your main network. If possible have then on a different public IP either using a VLAN or better yet with an entire physical network just for that - avoids VLAN hopping attacks and DDoS attacks to the server that will also take your internet down;
- If you're using VLANs then configure your switch properly. Decent switches allows you to restrict the WebUI to a certain VLAN / physical port - this will make sure if your server is hacked they won't be able to access the Switch's UI and reconfigure their own port to access the entire network. Note that cheap TP-Link switches usually don't have a way to specify this;
- Only expose required services (nginx, game server, program x) to the Internet. Everything else such as SSH, configuration interfaces and whatnot can be moved to another private network and/or a WireGuard VPN you can connect to when you want to manage the server;
- Use custom ports with 5 digits for everything - something like 23901 (up to 65535) to make your service(s) harder to find;
- Disable IPv6? Might be easier than dealing with a dual stack firewall and/or other complexities;
- Use nftables / iptables / another firewall and set it to drop everything but those ports you need for services and management VPN access to work - 10 minute guide;
- Use your firewall to restrict what countries are allowed to access your server. If you're just doing it for a few friends only allow incoming connection from your country (https://wiki.nftables.org/wiki-nftables/index.php/GeoIP_matching)
Realistically speaking if you're doing this just for a few friends why not require them to access the server through WireGuard VPN? This will reduce the risk a LOT and won't probably impact the performance. This is a decent setup guide https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-debian-11 and you might use this GUI to add/remove clients easily https://github.com/ngoduykhanh/wireguard-ui
Point of order on the raspberry pi:
Here's your Debian https://raspi.debian.net/tested-images/
There multiple issues with those Debian images and while I would love to run them, they don't cut it. Generic images might underperform in your board, the GPIO and other low level components will, most likely, not work and you might burn your storage as logging and other I/O intensive operations aren’t tweaked for SD cards.
There's also Armbian (https://www.armbian.com/rpi4b/) but only Ubuntu based right now. Armbian could be a great solution however there has been not much interest in the RPi board most likely due to what I pointed before.
Also WRT telemetry: https://forums.raspberrypi.com/viewtopic.php?t=341514
The only telemetry is pertaining to what the imager is burning to the card. So if you don't use the imager there's no telemetry, if you use the imager but disable telemetry, there's no telemetry, if you don't disable it, it just sends back what you're installing.
Here the problem: they're forcing people into the Raspberry Pi Imager with shady tactics. Without it you won’t be able login via network out of the box and by default it enables telemetry. This isn't okay.
I've already spoken about the "telemetry" but here's your ssh login. Literally all the installer is doing is adding a blank file.
Then if you don't want to do that every time, just create an image for it. That's your new image to flash onto the SD cards.
There's nothing stopping you from not using the imager. dd works just fine. There's no telemetry on the OS itself, so here's how you personally get what you're looking for.
- dd the base image to a card
- verify the card and image are working properly by booting on a pi
- turn off pi
- insert card into computer and create file in boot directory
- create a new bootable backup image from the card, and save that on the computer it's plugged into, cloud or local backup storage you're running, whatever
- dd that image as the base image for all new cards.
but here’s your ssh login. Literally all the installer is doing is adding a blank file.
Yes and why are they forcing us to go through hoops / non standard BS instead of doing it like any other SBC and just enabled by default. Armbian does it and once you login you're required to change the password for security.
I remember before the imager the RPi also had SSH enabled by default. Don't sugar coat it around security, this is bullshit to force people into their imager.
None of this forces you to use their imager though... It's barely a hoop, most people running multiple pi's as servers will have done this for a reason other than ssh anyway.
And yes one solution to this security problem is to require changing the username and password, the more effective solution is to not have the process running at all, unless specifically enabled. I'm sure that sentence sounds familiar from your company's security team.
Raspberry pi's serve a lot of purposes, many of those purposes don't need ssh. But if you enable it by default that opens the pi up to being a target, which we saw be a huge problem before this change.
Also, this is not the only distribution that has ssh disabled by default. It's just the only popular distribution I'm aware of that doesn't have a server image option 🤷♂️ it's actually standard security procedure.
For example, if you install Ubuntu desktop, it'll have ssh disabled, because it is standard. Pretty much any distro should do this as well as long as it's not their "server" ISO.
In any case it's a good practice to backup your images regardless of what hardware you're running on, especially if you're running a cluster, it allows for easy reproduction across the cluster.
The most common use case for a RPi is people who just want to hook it into some electronics and play a bit with it, very much like a modern day Arduino. The second most common is some kind of server be it simple SMB share, DLNA wtv. The 3rd case is custom images like retropi, home assistant etc... In the first tow having SSH by default greatly simplifies things.
People who deploy professionally / on scale / create customs images for other things are tech savvy enough and know how to disable SSH - no need to have it disabled by default.
People who deploy professionally / on scale / create customs images for other things are tech savvy enough and know how to disable SSH - no need to have it disabled by default.
I think you've solved your own problem. The people that are savvy enough to do it know how to enable it and it's not a real impact to them. But by disabling it, the people that don't are protected. Which is why this is a standard practice across Linux distros.
It could be standard practice across Linux distros but not standard across SBCs...
I just found your comment, that was very helpful thank you!
You're welcome.