|
|
| (2 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| − | = Common uses for a server=
| + | #REDIRECT [[Setting up a Server]] |
| − | * Install FTP software and run a FTP.
| |
| − | * Install a cloud service like Seafile to run your own Dropbox service, no privacy issues, full control, unlimited space (well, limited by how many drives you can cram in)
| |
| − | * Always on seedbox. Start torrents with your phone through the web interface while out, they're done by the time you're back home.
| |
| − | * Host a personal website
| |
| − | * Run your own mailserver just like Hillary!
| |
| − | ** Warning: Running a mailserver is a shitton of work. You will get hacked all the fucking time and it's very high-maintenance.
| |
| − | * Run a dedicated game server
| |
| − | * Run various webapps, develop your own webapps
| |
| − | * SSH-tunnel to the server from work/school/etc to use it as a proxy, so that the admin of the network you're on can't see what sites you're going on
| |
| − | | |
| − | = Home Server vs. VPS =
| |
| − | If you want a server, you have two options: Either make your own, or rent one.
| |
| − | | |
| − | Running your own has the following benefits:
| |
| − | * Cheap servers are almost always VPSs, and their specs are set very low. Even bottom of the barrel hardware from 5 years ago or average hardware from 10 years ago will get you much better performance.
| |
| − | * Upgrading is as easy as buying a new component and sticking it in. You can install whatever software you want.
| |
| − | * No giving permanent access to your credit card to some company on the other side of the planet.
| |
| − | * You don't have to trust anyone with your data.
| |
| − | * When at home, you can connect to the server over LAN for blazing fast speeds.
| |
| − | * Can connect server to TV with HDMI for watching movies.
| |
| − | * Very cheap or free if you have old hardware lying around.
| |
| − | | |
| − | But renting a server also has benefits:
| |
| − | * Can rent the server in a country with strong privacy laws.
| |
| − | * Protects your identity if you use it as a proxy (assuming the company fucks you over).
| |
| − | * Less downtime, less maintenance problems, no electric cost.
| |
| − | * Probably more secure than what you'll get if you roll your own.
| |
| − | * No fucking around with ISP.
| |
| − | * At $10/mo will cost you $120 in one year. If you are buying all hardware new, a headless server (no permanent monitor or keyboard) will cost more.
| |
| − | | |
| − | == Home server ==
| |
| − | A server is any machine that is on all the time, and accepts connections from the internet. Anyone who knows the IP of the server or a domain that points to that IP can try connecting. Servers can serve multiple different services, usually each service has its own port. Once it's set up you disconnect everything (monitor, keyboard, mouse) except the power cord and ethernet jack, and install something called an SSH server. You can then connect to the server from anywhere over the internet (or from inside your house over the LAN) and control it remotely.
| |
| − | | |
| − | Servers are typically administered from the command line, because GUI lags a shitton for remote access.
| |
| − | | |
| − | === Hardware===
| |
| − | The first option to consider just getting a self-contained system, like a small PC designed for this purpose or a Banana board.
| |
| − | | |
| − | If you want to build your own, it can be as easy as buying some of the cheapest stuff from the Logical Increments list.
| |
| − | | |
| − | * Case: You want the smallest case that your mainboard will fit in. Unlike a desktop, you don't really need to worry about cooling or space. You can usually find some good cases like Corsair or Fractal for only $5-10 more than the cheapest one available, so that might be a good idea.
| |
| − | * Motherboard: Get the cheapest one you can find. Go for microATX or miniATX. The main criteria you want are:
| |
| − | ** Compatible with a suitable CPU
| |
| − | ** Has on-board graphics
| |
| − | ** HDMI output is nice so you can connect to a TV
| |
| − | ** USB 3.0 or eSATA support if you'll be using those for backing up to external drives.
| |
| − | * CPU: You want a cheap CPU with very low power consumption. Server CPU usage hovers around 1% and rarely goes above 5%. If your load is ever 100% it's time to monetize whatever it is you've been doing and get rich. Every extra watt is more power consumption, more heat and more noise (and with a server the noise can be a much bigger problem, depending on where it is). AMD's budget CPUs are great for these requirements.
| |
| − | * RAM: Any sane server OS will easily be okay with 512 MB. 1-2 GB doesn't hurt, but above 2 GB is overkill. (even 1 GB is overkill unless you're actually doing some heavy stuff)
| |
| − | * HDD: Anything big and cheap works fine. Even really shitty old drives can be repurposed and put in a suitable RAID, to compensate for failure, low speed or small capacity. This is probably the most critical spec of your server, besides power consumption - just stick every spare HDD you have in there.
| |
| − | * PSU: Your peak power consumption will probably be less than 100W, and you will never be at peak (maybe when installing OS). Unfortunately, it's hard to find decent PSUs (given that this machine is always powered, PSU is probably not a place to skimp) below 500W, so you will probably end up with those.
| |
| − | | |
| − | === Distro===
| |
| − | Windows may rule on the desktop, but with servers, Linux is king.
| |
| − | | |
| − | For beginners, Ubuntu Server is Ubuntu with all the desktop stuff (like GUI or user-oriented programs) stripped. You can even use a Desktop version like Xubuntu, although you should disable the desktop environment to avoid wasting CPU cycles and power.
| |
| − | | |
| − | Top server distros are Debian and CentOS.
| |
| − | | |
| − | == VPS ==
| |
| − | A VPS is a virtual private server. When you rent a server from a company, they don't literally go and build a new machine just for you. They have huge server boxes running a VM software, and they just create a new virtual machine for you. That is your VPS.
| |
| − | | |
| − | === Companies===
| |
| − | | |
| − | =Security=
| |
| − | Unlike a desktop, a server is always working, accepts connections from the internet (your desktop is normally firewalled and doesn't have any ports open) and is easy to discover (especially if you send mail from it). It's under a bit more risk, and its worth thinking about what intrusions you will try to prevent and how.
| |
| − | | |
| − | == Threat model==
| |
| − | There are 4 main classes of attackers, grouped by what sorts of security measures are appropriate for them.
| |
| − | | |
| − | ===Busybodies===
| |
| − | These are extremely unmotivated people like asshole flatmates or nosy neighbors (who end up on your WAN). They will rarely even try anything, and if they do, they will make the tiniest of efforts and give up at the first sign of difficulty.
| |
| − | | |
| − | Just put good passwords on your shit and don't tell them to anyone, and it will be enough for this group.
| |
| − | | |
| − | ===Casual snoopers===
| |
| − | These are attackers who actually have a strong motive to get your data, but aren't competent and don't have the resources to make a serious attack. Say a burglar steals your computer. Of course he will try turning it on and seeing if there's anything interesting inside. He will not hesitate at all, unlike the previous group. Hopefully, he will see a password prompt, and after a few tries, give up on trying to guess it. However, again unlike the previous group, he will not stop there. If at all computer literate, he will try to plug the hard drive into another computer, or boot from a LiveCD. At that point it's possible that you will be the victim of identity theft.
| |
| − | | |
| − | Technically, this group has physical access, so by the common maxim of computer security, you have already lost. But in practice, they could only defeat your security theoretically. In practice, they don't know how to actually leverage that physical access, and probably won't bother trying.
| |
| − | | |
| − | Full disk encryption will deter this group, since they don't have the resources to defeat, and will simply give up and just sell the hardware at that point. Encryption takes a lot of work to defeat, and most of the shit people encrypt honestly isn't valuable or worth bothering with.
| |
| − | | |
| − | ===Skids===
| |
| − | Within even the first day of your server's uptime, you will realize that there's tons people constantly trying to hack your machine. There is a sliding scale: There are tons of shitty script kiddies just randomly scanning ports over a range of IPs, and when they see your server responding, they start trying to bruteforce the SSH. This is extremely common and very easy to protect against. On the other hand, there are some extremely determined, very skilled hackers who buy 0days on the black market and use them, but these will probably be rarer, and they will prefer go after juicier targets like banks before coming after your home server full of animu porn.
| |
| − | | |
| − | The way to defend against this group is to configure your server for strong security, always keep your software up to date as new exploits appear, and keep a close eye on signs of intrusion. Defending against this group is probably the bulk of your security related maintenance workload.
| |
| − | | |
| − | At the same time, you have to recognize that you the only way to have perfect security is to turn off your server and disconnect it from the internet. Consider something like the Heartbleed bug: There is nothing you could have done to protect against it, even if you acted the moment the news broke (you could have been attacked before the news were out). That said, if a bad guy got hold of Heartbleed, he probably wouldn't attack you (there are much better targets), and just because you can't have perfect security, doesn't mean you shouldn't have any security. Lockpicks exist, but we still lock our doors.
| |
| − | | |
| − | ===Hardcore===
| |
| − | The last class is attackers with very high competence, extensive resources, who are highly motivated to come after ''you''. This is basically a government agency (CIA/NSA/FBI/Chinese spies) or a serious hacker (eg. hired by a company) targeting specifically you. Note that, as opposed to the 0day hacker from the previous class, these attackers are targeting specifically you. So the argument that they have "bigger fish to fry" does not apply anymore: Either the government is after you because you did something they don't like, or a someone paid a hacker to get you, either way the attacker will not stop until they've tried every trick in the book (and it's a very big book).
| |
| − | | |
| − | There isn't much you can do about this group. You could try to take some measures, but they will be very inconvenient, and some may even be dangerous or borderline illegal. For one, the government could easily gain physical access to your system by producing a warrant, and unlike a burglar, they actually could and would take advantage of that physical access. Given this, your best option is to not attract any attacks in the first place: Don't do anything illegal, don't be an important person targeted by cyber warfare, and don't piss off any hackers, or anyone who would pay a hacker. Anything beyond that is out of this document's scope.
| |
| − | | |
| − | == Recommended security policy==
| |
| − | Going by the above model, these recommendations aim to deter entirely the first two groups, deter as much of the third group as possible, without taking any additional measures for the fourth group.
| |
| − | | |
| − | === GNU/Linux===
| |
| − | * If you are behind a router, only forward ports you need.
| |
| − | * When installing the OS, encrypt your entire drive (except for /boot which is needed to actually boot before the disk is unlocked). Because you need to enter a password at boot to decrypt, you will not be able to reboot remotely, but the alternative of not encrypting is unacceptable. Try not to kill your server when you're not around to boot it.
| |
| − | ** Encrypting only your home directory is not adequate. There is sensitive data outside the home directory as well.
| |
| − | | |
| − | ==== Disable password login for SSH ====
| |
| − | First you need to generate keys for authenticating yourself.
| |
| − | | |
| − | <code>openssh-server</code> will look for keys under <code>~/.ssh</code>. On your server, run:
| |
| − | | |
| − | mkdir ~/.ssh
| |
| − | chmod 700 ~/.ssh
| |
| − | | |
| − | Generate a pair of 2048-bit RSA keys:
| |
| − | | |
| − | <code>ssh-keygen -t rsa</code>
| |
| − | | |
| − | This will ask you for a file to save the key in and walk you through the process:
| |
| − | | |
| − | Generating public/private rsa key pair.
| |
| − | Enter file in which to save the key (/home/b/.ssh/id_rsa):
| |
| − | Enter passphrase (empty for no passphrase):
| |
| − | Enter same passphrase again:
| |
| − | Your identification has been saved in /home/b/.ssh/id_rsa.
| |
| − | Your public key has been saved in /home/b/.ssh/id_rsa.pub.
| |
| − | | |
| − | Use a good passphrase that you can remember easily and don't mind typing a lot. You will use this passphrase everytime you SSH into your server.
| |
| − | | |
| − | Now you need to record the public key in the authorized key store. Make a backup, then copy the public key:
| |
| − | | |
| − | cp authorized_keys authorized_keys_Backup
| |
| − | cat id_rsa.pub >> authorized_keys
| |
| − | | |
| − | There should be one RSA key per line in the <code>authorized_keys</code>.
| |
| − | | |
| − | Now take the private key (<code>id_rsa</code> without <code>.pub</code>) and put it on every machine that should be able to connect by SSH. After that's done, you need to disable password authentication. First open <code>sshd_config</code>:
| |
| − | | |
| − | sudo nano /etc/sshd_config</code>
| |
| − | | |
| − | Make the following changes:
| |
| − | | |
| − | * Change <code>PasswordAuthentication yes</code> and to <code>PasswordAuthentication no</code>.
| |
| − | * Change <code>RSAAuthentication no</code> to <code>RSAAuthentication no</code>.
| |
| − | | |
| − | Save with Ctrl+X, Y, Enter.
| |
| − | | |
| − | You will no longer be able to use your Linux user account password to login with SSH. You'll need to point your SSH client (ie. PuTTY, openssh-client, etc) to the private key, and you will still need to enter a password. This password is to unlock your private key.
| |
| − | | |
| − | If your client machine is ever stolen, the attacker will obtain your key. They will not be able to login, because they don't know the passphrase of the key. However, they can now try to brute force your password, so you should make a new pair of keys (by repeating this process except for the <code>sshd_config</code> part), delete the old public key from <code>authorized_keys</code> and switch to the new one.
| |
| − | | |
| − | Random hackers on the internet will fail because the server will refuse connection attempts unless they are trying to use a key.
| |
