>Thelismor |
|
| (69 intermediate revisions by 17 users not shown) |
| Line 1: |
Line 1: |
| {{Move||[[wikipedia:Wikipedia:Naming_conventions (capitalization)]]. Title makes it unclear which server we're talking about. Merge with [[Home server]] suggested. Remember [[Special:WhatLinksHere/Setting_up_a_Server]]}}
| |
| [[File:Setting_up_a_Fileserver.jpeg|thumb|This picture details the ramblings of an incompetent years ago, please do not follow it.]]
| |
|
| |
| '''Need a fileserver that won't face the external internet? Check [[Home server]].'''
| |
|
| |
| Need to email? Set up a web server? Well, here's some advice. We're gonna try to write this page like you've never done this shit before. It does, however, assume you have at least some basic [[GNU/Linux]] knowledge. If you don't, you probably aren't ready for this. You weren't going to set up a server using Windows, were you? Jesus Christ, how horrifying. | | Need to email? Set up a web server? Well, here's some advice. We're gonna try to write this page like you've never done this shit before. It does, however, assume you have at least some basic [[GNU/Linux]] knowledge. If you don't, you probably aren't ready for this. You weren't going to set up a server using Windows, were you? Jesus Christ, how horrifying. |
|
| |
|
| A lot of this applies to both a physical machine as well as a [[VPS]] setup.
| | Common uses for a server: |
| | | * Install a media player system and stream content to your local network |
| = Common uses for a server=
| | * Install a cloud service like Nextcloud to run your own Dropbox service, no privacy issues, full control, unlimited space (well, limited by how many drives you can cram in). |
| * 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. | | * 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 | | * Host a personal website. |
| * Run your own mailserver just like Hillary! | | * 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. | | ** Warning: Running a mailserver is a shitton of work, especially if you want emails to google/outlook to be seen. |
| * Run a dedicated game server | | * Run a dedicated game server. |
| * Run various webapps, develop your own webapps | | * 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 | | * 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. |
| | | * Run a VPN for location spoofing or security when you're out and about. |
| = 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.
| |
| | |
| === Operating system===
| |
| You should run [[Debian]], RHEL or CentOS if you want [[GNU/Linux]], or any [[FreeBSD|*BSD]] that you like.<br>
| |
| | |
| [[Ubuntu]] usually does retarded things with their packages and versions (lib*-ubuntu1.l2), and pulls unstable software from Debian Sid.
| |
| | |
| Rolling release distros ([[Arch]], Fedora) are not really good for a server, because it's supposed to stay working, and it shouldn't break/change it's behavior on updates.
| |
| | |
| [[Gentoo]] is usually too much trouble to be worth it, but it's ok.
| |
| | |
| You should also consider a NAS-centric operating system for a home server - FreeBSD-based FreeNAS or NAS4Free are common choices. Both are [[free]] software and have simple GUIs to set up your services.
| |
| | |
| If you have a raspberry pi that you want to be put to use, ArkOS is a stable, Arch based distro for running a home server on a raspberry pi with a Web based GUI. [https://arkos.io ArkOS main website]
| |
| | |
| == 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===
| |
| | |
| =Setting up your services=
| |
| | |
| == Centralized storage==
| |
| One option is to set it up with NFS (Linux-centric, can be used on windows but it's shit) or samba, so you can watch your chinese cartoons on any device and keep your documents/whatever synchronized.
| |
| | |
| You may want to consider a [[RAID]] array for long-term file storage. RAID is not backup, but will protect your files in case of drive failure. NAS4Free allows you to easily set up RAID arrays using UFS or ZFS.
| |
| | |
| == Setting Up Email and web server, the EASY way ==
| |
| | |
| ''See also: [[Email]]''
| |
| | |
| Want to use your own email server to avoid the [[NSA]]? Good call! But setting up email servers can be pretty complicated. Assuming you mostly don't know what the hell you are doing, and assuming you're already secured your system per above, have a peek at [http://www.iredmail.org/ iRedMail]. iRedMail is an automated email and web server setup package. It works best if installed on a FRESH system - if you're already fumbled around with Apache and/or dovecot and/or postfix and failed, wipe your shit and start over with iRedMail. It will install and configure Postfix, Dovecot, Apache, and MySQL. It also installs and configures fail2ban and iptables. It includes spam filtering and greylisting. It just works. Its pretty awesome.
| |
| | |
| You will, however, still need to manually set up your DNS records (MX, SPF, and DKIM). Refer to the [[Email]] article for more on this.
| |
| | |
| If you want to get fancy and replace MySQL with MariaDB, or replace Apache with, say, Nginx, you can do that after you set up iRedMail, but any breakage is up to you to fix.
| |
| | |
| =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 attackers===
| |
| 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.
| |
| | |
| ==== Protecting Your Private Network ====
| |
| Use a [https://en.wikipedia.org/wiki/DMZ_%28computing%29 DMZ], nigger.
| |
| | |
| ==== Securing your shell ====
| |
| | |
| If anyone breaks into your shell, you are FUCKED. They will own your whole server within minutes. There are bots that do nothing but scan for vulnerabilities on random IP addresses all day long, and they will hammer your SSH port like it's Natalie Portman's butthole. You need to secure that shit as your first priority, and here's how:
| |
| | |
| Add a non-root user. Then, while logged in as root, do this:
| |
| | |
| visudo
| |
| | |
| Go down to the bit where it says ''# User privilege specification'', and copy the setup for the root line. So, if your non-root user is "faggot," make it look like so:
| |
| | |
| # User privilege specification
| |
| root ALL=(ALL) ALL
| |
| faggot ALL=(ALL) ALL
| |
|
| |
| We are going to use [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY] in this tutorial because its consistently available on almost all platforms, including GNU/Linux (check your repos) OSX, and Windows. You can also use ssh-keygen for GNU/Linux or something else entirely, but if you already knew that, you probably wouldn't need this page, amirite?
| |
| | |
| The PuTTY suite includes a program called PuTTYGen. Run PuTTYGen to generate a public/private key pair. Go with SSH-2 DSA, 4096 bits - nobody's gonna crack that shit easily, and the [[NSA]] infiltrated the RSA, so fuck that. When done, it will display your public key. Except for the very beginning and very end, it will look like a shitton of gibberish - this is normal. Copy and paste that text into a text file, but omit the last bit that says "dsa-key-########". Put in a passphrase, this is not meant to authenticate you against the SSH server, but to keep the private key secure in case it's stolen from your client machine. Save the private key.
| |
| | |
| Open PuTTY and log in as your non-root user. Then do this:
| |
| | |
| mkdir /home/faggot/.ssh
| |
| nano /home/faggot/.ssh/authorized_keys
| |
| | |
| Paste in your public key that you saved as a text file. MAKE SURE IT IS ALL ONE LINE, like so:
| |
| | |
| ssh-dsa [insanely long string of crap]
| |
| | |
| And save it.
| |
| | |
| Now take ownership of it:
| |
| | |
| chmod 600 ~/.ssh/authorized_keys
| |
| | |
| DO NOT LOG OUT OF PuTTY YET, but open a second PuTTY session and connect to your server, only this time point PuTTY to your private key file to test it out. If it all goes well, your login will look something like this:
| |
| | |
| Using username "faggot".
| |
| Authenticating with public key "dsa-key-########"
| |
| | |
| Assuming that works, close your previous PuTTY session and do this:
| |
| | |
| sudo nano /etc/ssh/sshd_config
| |
| | |
| You can change the SSH port here to a random number - that's optional though, because hacker bots are gonna find it anyhow. But if you do change it don't forget to change it in PuTTY as well.
| |
| | |
| But DO make the following changes:
| |
| | |
| PermitRootLogin no
| |
| PasswordAuthentication no
| |
| X11Forwarding no
| |
| UsePAM no
| |
| | |
| Add the following to the bottom if missing:
| |
| | |
| UseDNS no
| |
| AllowUsers faggot
| |
| | |
| If you have additional users, put a space after "faggot" and add the next user, and so on if you have more.
| |
| | |
| Save these changes and restart your SSH server. On [[Debian]], or any other system using sysvinit or OpenRC setup it would be:
| |
| | |
| sudo /etc/init.d/ssh reload
| |
| | |
| If you are using systemd, it would be:
| |
| | |
| sudo systemctl restart sshd
| |
| | |
| BOOM. Assuming all went well, you have now set up your shell so that 1) "root" cannot log in, 2) ONLY "faggot" can log in, and 3) "faggot" can ONLY log in using their private key file instead of a password. You'll still want to set up and install fail2ban or similar to secure things further.
| |
| | |
| Oh, and don't lose that private key file. You cannot recreate it, so losing it means you are doomed. Back it up in multiple places. You may wish to place a copy on a floppy drive (if you're a time-traveller from 1995) or USB stick as well, for safekeeping.
| |
| | |
| ===== Securing your shell even more (and everything else) =====
| |
| | |
| Even with your shell secured, its still gonna get hammered, and that's going to get irritating quick. Given enough time, even your super-secret keyfile can eventually be guessed. Well, guess what? You can ban the SHIT out of those bots with fail2ban.
| |
|
| |
|
| fail2ban monitors your log files (any of them, not just SSH). If it sees too many login failures, it bans the offending IP for as long as you configure it to. It won't prevent a distributed brute-force attack, but it will help a LOT.
| | =Getting Started= |
| | * [[Encryption|Encrypted or unencrypted drive (LUKS)]] |
| | * [[Home server/Choosing an Operating System]] |
| | * [[Home_Server/Setting up your Storage]] |
| | * [[Home server/Remote access]] |
|
| |
|
| *[https://www.digitalocean.com/community/articles/how-to-protect-ssh-with-fail2ban-on-debian-7 How To Protect SSH with fail2ban on Debian 7] | | =Recommended software= |
| *[https://www.digitalocean.com/community/articles/how-to-protect-ssh-with-fail2ban-on-centos-6 How To Protect SSH with fail2ban on CentOS 6] | | * [[Home server#Server software]] |
| *[https://www.digitalocean.com/community/articles/how-to-protect-ssh-with-fail2ban-on-ubuntu-12-04 How To Protect SSH with fail2ban on Ubuntu 12.04]
| | * [[Home server#System administration software]] |
|
| |
|
| Please note that if you are going to install iRedMail (below), it will install and configure fail2ban for you. You may still wish to tweak its settings though.
| | ==Common home server services== |
| | Most packages have clear tutorials on their repo/project site. Here are some handpicked guides for the most common types of software used |
| | * Cloud Storage - Nextcloud |
| | * Web Server - [https://homebrewserver.club/fundamentals-webserver-website.html Apache] or NGINX |
| | * VPN - Wireguard or OpenVPN |
| | * Media Streaming - Jellyfin or PLEX |
| | * XMPP - [https://homebrewserver.club/configuring-a-modern-xmpp-server.html Prosody] |
|
| |
|
| ==== fail2ban ==== | | =Centralized storage= |
| | A server is perfect for this job. It is (supposedly) an always available resource on the local network. If using this in your house, you can expect reasonable speeds, even over WiFi that will let you do many daily tasks. One option is to set it up with NFS (Linux-centric, can be used on windows but it's shit) or Samaba if you have Windows clients on your network, so you can watch your chinese cartoons on any device and keep your documents/whatever synchronised. This synchronisation is a key benefit of the network storage. |
|
| |
|
| fail2ban is a utility that scans your system log files and bans anyone who tried to make logins and fails. With the default settings, 3 failed SSH logins trigger a 10 minute ban for that IP. This makes brute-forcing very difficult. Usually hackers see the ban and move on, they don't bother even waiting for the 10 minutes to run out.
| | You may want to consider a [[Wikipedia:RAID|RAID]] array for long-term file storage. RAID is not backup, but will protect your files in case of drive failure. See [[Home server#File Systems and RAID]] for more information. |
|
| |
|
| sudo apt-get install fail2ban
| | == Web server == |
| | [[File:Tidle town.png|thumb|right|alt=A reminder why you should always self-host and if you don't, avoid inbred retards|A reminder why you should always self-host and if you don't, avoid inbred retards]] |
|
| |
|
| fail2ban comes with a bunch of rules already set up. To see these, type <code>sudo fail2ban-client -d</code> (fail2ban runs as root so you won't get anything without sudo). For best results, the jails should be reviewed and fine tuned. There is a manual here: http://www.fail2ban.org/wiki/index.php/MANUAL_0_8
| | A web server serves up a page. The nice things about serving it from a server, than, say, Wordpress or your Dropbox share, is that now you can run web apps and server side code for a dynamic page. |
|
| |
|
| fail2ban keeps a log where it records IPs it banned. You can see it with <code>nano /var/log/fail2ban.log</code>. After a few days, a bunch of Chinese IPs should pop up.
| |
|
| |
|
| | ===HTTPS=== |
| | The extra CPU burden of TLS is minuscule. Your server should serve up everything on HTTPS only. Keep port 80 (plain HTTP) open but redirect everything to HTTPS. If port 80 is closed, typing the address of your server into the address bar of a browser will probably fail (because the browser assumes you meant HTTP, but you have to go to HTTPS). |
|
| |
|
| | Issue a self-signed certificate. CAs are for jerks. Set the duration short (eg. a year) and don't forget to make a new one. If you've got a domain, get a Lets Encrypt-signed cert and set up a cron job to renew it. They're pretty sweet. |
|
| |
|
| ==== Protecting from DDoS and shit ====
| | [https://certbot.eff.org/ Certbot] makes https easy to implement with Let's Encrypt certificates |
| Use [http://www.fail2ban.org/wiki/index.php/Main_Page Fail2Ban] (and/or [http://denyhosts.sourceforge.net/ DenyHosts]) and perhaps a redundant computer in the DMZ. Also never use passwords, only keyfiles.
| |
|
| |
|
| | =External links= |
| | * [https://library.linode.com/ Linode Library] - Good beginner tutorials |
| | * [https://landchad.net/ landchad.net] - "Chad's Guide to Starting Your Own Website" |
| | * [https://github.com/x08d/lockdown.sh Script to secure Debian and Debian based Linux installs] |
| | * [https://gist.github.com/deergod1/818ec78ab70947a2f89df2bb5bb28896 Setup pfSense] |
| | * [https://github.com/pikvm/pikvm Raspberry Pi KVM for managing servers remotely] |
| | * [https://devconnected.com/syslog-the-complete-system-administrator-guide/ The Complete System Administrator Guide] |
| | * [https://github.com/erebe/personal-server/blob/master/README.md Example of a personal server] |
| | * [https://www.cyberciti.biz/cloud-computing/increase-your-linux-server-internet-speed-with-tcp-bbr-congestion-control/ Increase Linux Internet speed with TCP BBR congestion control] |
|
| |
|
| = External links = | | =See also= |
| [https://library.linode.com/ Linode Library] - Good beginner tutorials. | | * [[Home server]] |
| | * [[Setting up a Server/Home or Remote?]] |
| | * [[Setting up a Server/Mail]] |
| | * [[Setting up a Server/DNS]] |
|
| |
|
| [[Category:Tutorials]] | | [[Category:Tutorials]] |
| [[Category:HowTo]] | | [[Category:HowTo]] |
