Skip to Content
Version 7.1 by Alexandru Pentilescu on 2023/06/25 18:45
Show last authors
1 (% class="jumbotron" %)
2 (((
3 (% class="container" %)
4 (((
5 = Starting out =
6 When starting with a clean linux VPS, the first thing you must ensure is that you have access to the root account (either that or are part of the sudoers file in such a way that you can make administrative changes to your system). If you don't have these access rights on the target system, you must first contact the administrator of this system and ask them for such priviliges. Otherwise, this article will be of no use to you.
7
8 )))
9 )))
10
11 (% class="col-xs-12 col-sm-4" %)
12 (((
13 {{box title="**Contents**"}}{{toc /}}{{/box}}
14 )))
15
16 (% class="row" %)
17 (((
18 (% class="col-xs-12 col-sm-8" %)
19 (((
20 = Creating a new user =
21
22 If you don't have an active user just yet, please do the following:
23
24 {{code language="bash"}}
25 sudo adduser <newuser>
26 {{/code}}
27
28 Please replace <newuser> with your username.
29 Then, to make them part of the sudoers file, just do:
30
31 {{code language="bash"}}
32 sudo usermod -aG sudo <newuser>
33 {{/code}}
34
35 == Using root vs. using a sudoers user ==
36
37 There's an argument to be made between just logging in as root on the system directly or using a separate users which is part of the sudoers file.
38 Both are viable options for administrators to make configuration changes on the target system.
39 Some people argue that adding other users to a system is just adding complexity and, especially if you plan to be the sole administrator of the VPS, it makes little sense not to use the already built-in root user. After all, root starts out with all the priviliges and, most importantly, you'll never have to remember to keep invoking "sudo" whenever you need to run administrative commands in the terminal. Because of this, this is seen as the superior approach.
40
41 However, others make the argument that constantly running as root is a security risk for the system as a whole. When running as root, any terminal command issued will also run with absolute privileges, which runs the risk of amplifying any human error to disastruous proportions.
42 Granted, this risk also exists for sudoers users too, but only with the commands which are ran with "sudo". Having the extra step of manually prefixing each command with "sudo" is seen as a preventative measure of avoiding system damage.
43 Moreover, if the administrator is diligent, they may retroactively change the sudoers users' permissions manually to only allow privilege escalation for commands which they deem safe to run, effectively blocking any risk for overly dangerous commands such as "dd" or "rm -Rf".
44
45 Ultimately, the argument for or against using root access is mostly a philosophical one, rather than a technical one. There is no right or wrong answer to this question. Rather, each answer brings its own advantages and disadvantages to the table. What really matters is what you're more comfortable with using in the end.
46 Moreover, using a sudoers user rather than root is not inherently a guarantee for system safety either and should not be taken as a leeway for running suspicious executable files from the internet either, as privilege escalation bugs have existed in the Linux kernel since its own inception.
47
48 = Setting up an SMTP server =
49 This will be required for all the future things you will be doing on the server.
50
51 Moreover, this is not an easy task and will be a little time consuming. Please consult the documentation [[here>>https://wiki.transistor.one/bin/view/Guides/How%20to%20setup%20a%20postfix%20SMTP%20server/]]
52
53 = Setting up automatic updates =
54
55 System updates are a necessity for modern day operating systems and on linux, especially, there's a constant need to run such updates regurarly to avoid the risk of running vulnerable software that can be exploited by rogue malware.
56
57 Linux, in particular, is an attractive target for malware writers in recent years, due to the fact that corporate servers owned by renowned companies are seen as a more profitable compromise target for malicious actors who may wish to extort money from unpatched systems.
58
59 After all, large corporations running unpatched systems are more likely to pay significant amounts of money than lone private users if their systems were to be compromised.
60
61 As such, it's imperative to protect our systems from such damage by preventing the attacks in the first place. The first step in achieving this goal is by constantly patching the system. And a good way to do this without requiring manual intervention is setting up automatic updates.
62
63 Debian based systems have an official package known as unattended-upgrades which can do just this. To install this package, please run the following command:
64
65 {{code language="bash"}}
66 sudo apt-get install unattended-upgrades
67 {{/code}}
68
69 This will install the package from the official repositories. After this, the package should be configurable to the administrator by editing the /etc/apt/apt.conf.d/50unattended-upgrades file. This file should be generated automatically after installing the package.
70
71 There's a lot of stuff which can be configured in this file. Some of the options which I personally prefer to activate by uncommenting are the following:
72
73 {{code language="none"}}
74
75 // This option controls whether the development release of Ubuntu will be
76 // upgraded automatically. Valid values are "true", "false", and "auto".
77 Unattended-Upgrade::DevRelease "auto";
78
79 // Send email to this address for problems or packages upgrades
80 // If empty or unset then no email is sent, make sure that you
81 // have a working mail setup on your system. A package that provides
82 // 'mailx' must be installed. E.g. "user@example.com"
83 Unattended-Upgrade::Mail "Alexandru.Pentilescu@disroot.org";
84 {{/code}}
85
86 This lets the system know that I want for email notifications with respect to updates need to be delivered to that specific email address. This is important because, every time updates occur, this lets me know via email. Of course, you need to have an SMTP server running locally, as described in the previous step.
87
88 Then:
89
90 {{code language="none"}}
91 // Remove unused automatically installed kernel-related packages
92 // (kernel images, kernel headers and kernel version locked tools).
93 Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
94
95 // Do automatic removal of newly unused dependencies after the upgrade
96 Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
97 {{/code}}
98
99 These configuration options will instruct the package to remove obsolete files which become stale as updates come in.
100
101 {{code language="none"}}
102 // Automatically reboot *WITHOUT CONFIRMATION* if
103 // the file /var/run/reboot-required is found after the upgrade
104 Unattended-Upgrade::Automatic-Reboot "true";
105 {{/code}}
106
107 This will instruct the package to automatically reboot the system. This is necessary after specific kernel updates are installed that need to be installed in memory and replace the old ones.
108
109 Finally:
110
111 {{code language="none"}}
112 // If automatic reboot is enabled and needed, reboot at the specific
113 // time instead of immediately
114 // Default: "now"
115 Unattended-Upgrade::Automatic-Reboot-Time "02:00";
116 {{/code}}
117
118 This instructs the package to reboot the whole system, automatically, whenever an update requires it, the next time the system clock reaches this specific configured time. I set mine to reboot the system, whenever an update requires it, at 2AM. You may change the time to whichever fits your needs.
119
120 = Installing docker =
121
122 Docker is almost an irreplaceable piece of software that will be critical to your whole infrastructure. Docker needs to be installed on the system properly. In order to do so, please follow the guide [[here>>https://docs.docker.com/engine/install/ubuntu/]]
123
124 = Force postfix to bind to non-local IP addresses on start =
125
126 If we plan on using our SMPT server to relay emails coming from our docker containers, we will have to force postfix to bind to an IP address that's different from localhost. This needs to be done because, if we configure postfix to only bind to localhost, it will effectively be unreachable to our docker containers and they will not be able to use it as a relay.
127 In order to allow for postfix to bind to non-local addresses, we have to add the following configuration file /etc/sysctl.d/80-network.conf with the following contents:
128
129 {{code language="ini"}}
130 net.ipv4.ip_nonlocal_bind = 1
131 net.ipv6.ip_nonlocal_bind = 1
132 {{/code}}
133
134 Honestly, the "ipv6" line is unnecessary for our purposes, but I'm adding it anyway. After this file is added, after reboot, postfix will be able to bind itself to nonlocal addresses successfully.
135 )))