imthenachoman / How-To-Secure-A-Linux-Server
- вторник, 12 февраля 2019 г. в 00:17:55
An evolving how-to guide for securing a Linux server.
An evolving how-to guide for securing a Linux server that, hopefully, also teaches you a little about security and why it matters.
sudo
umask
This guide's purpose is to teach you how to secure a Linux server.
There are a lot of things you can do to secure a Linux server to prevent bad-actors from gaining access to your server and this guide will attempt to cover as many of them as possible. More topics/material will be added as I learn, or as folks contribute.
This guide...
I assume you're using this guide becuase you, hopefully, already understand why good security is important. That is a heavy topic onto itself and breaking it down is out-of-scope for this document. If you don't know the answer to that question, I advise you research it first.
At a high level, the second a device, like a server, is in the public domain -- i.e visible to the outside world -- it becomes a target for bad-actors. An unsecured device is a playground for bad-actors who want access to confidential data, or to add nodes to their coordinated large-scale DDOS attacks.
What's worse is, without good security, you may never know if your server has been compromised. A bad-actor may have gained unauthorized access to your server and copied your data without changing anything so you'd never know. Or your server may have been part of a DDOS attack and you wouldn't know. Look at many of the large scale data breaches in the news -- the companies often did not discover the data leak or intrusion until long after the bad-actors were gone.
Contrary to popular, bad-actors don't always want to change something or lock you out of your data for money. Sometimes they just want your for their data warehouses (there is big money in big data) or to covertly use your server for their nefarious purposes.
This guide may appear duplicative/unnecessary because there are countless articles online that tell you how to how to secure Linux but the information is spread across different articles, that cover different things, and in different ways. Who has time to scour through hundreds of articles?
As I was going through research for my Debian build, I kept notes. At the end I realized that, along with what I already knew, and what I was learning, I had the makings of a how-to guide. I figured I'd put it online to hopefully help others learn, and save time.
I've never found one guide that covers everything -- this guide is my attempt to remedy that.
Many of the things covered in this guide may be rather basic/trivial, but most of us do not install Linux every day and it is easy to forget those basic things.
IT automation tools like Ansible, Chef, Jenkins, Puppet, etc. help with the tedious task of installing/configuring a server but IMHO they are better suited for multiple or large scale deployments. IMHO, the overhead required to use those kinds of automation tools is wholly unnecessary for a one-time single server install for home use.
I wanted to put this document on GitHub to make it easy to collaborate. The more folks that contribute, the better and more complete this guide will become.
To contribute you can fork and submit a pull request or submit a new issue.
I am very lazy and do not like to edit files by hand if I don't need to. I also assume everyone else is just like me. :)
So, when and where possible, I have provided code
snippets to quickly do what is needed, like add or change a line in a configuration file.
The code
snippets use basic commands like echo
, cat
, sed
, awk
, and grep
. How the code
snippets work, like what each command/part does, is out of scope for this guide -- the man
pages are your friend.
Note: The code
snippets do not validate/verify the change went through -- i.e. the line was actually added or changed. I'll leave the verifying part in your capable hands. The steps in this guide do include taking backups of all files that will be changed.
Not all changes can be automated with code
snippets. Those changes need good, old fashioned, manual editing. For example, you can't just append a line to an INI type file. Use your favorite Linux text editor.
sysctl
HardeningBefore you start you will want to identify what your principals are. What is your threat model? Some things to think about:
These are just a few things to think about. Before you start securing your server you will want to understand what you're trying to protect against and why so you know what you need to do.
Installing Linux is out-of-scope for this document. If you need help, start with your distribution's documentation. Regardless of the distribution, the high-level process usually goes like so:
Where applicable, use the expert install option so you have tighter control of what is running on your server. Only install what you absolutely need. I, personally, do not install anything other than SSH.
Debian is my distribution of choice and what this guide was written/tested on. Everything below should, in most cases, work on other distributions but file paths and settings may differ slightly. Check your distribution's documentation.
sudo apt update && sudo apt upgrade
on Debian based systems)/etc/fstab
(like mounting /tmp
in RAM using tmpfs
)Using SSH public/private keys is more secure than using a password. It also makes it easier and faster, to connect to our server because you don't have to enter a password.
Check the references below for more details but, at a high level, public/private keys work by using two keys to verify identity.
For SSH, a public and private key is created on the client. The public key is then securely transferred to the server you want to connect to. After this is done, SSH uses the public and private keys to verify identity and then establishing a secure connection. Identity is verified by encrypting and decrypting data that both the client and server know. If the data can't be decrypted, the identity can't be verified and a connection will not be established.
They are considered more secure because you need the public key to establish an SSH connection. If you set PasswordAuthentication yes
in /etc/ssh/sshd_config
, then SSH won't let you connect without the public key.
You can also set a passphrase for the keys which would require you to enter the key passphrase when connecting using public/private keys. Keep in mind doing this means you can't use the key for automation because you'll have no way to send the passphrase in your scripts.
We will be using Ed25519 keys which, according to https://linux-audit.com/:
It is using an elliptic curve signature scheme, which offers better security than ECDSA and DSA. At the same time, it also has good performance.
man ssh-keygen
man ssh-copy-id
From the computer you're going to use to connect to your server, the client, not the server itself, create an Ed25519 key:
ssh-keygen -t ed25519
Now you need to append the contents of the public key ~/.ssh/id_ed25519.pub
to the ~/.ssh/authorized_keys
file on the target server. You'll want to do this in a secure way since the public key gives access to your server. One approach is to copy it to a USB stick and physically transfer it to the server. If you're sure there is nobody listening between the client you're on and your server, you can use ssh-copy-id
to transfer and append the public key:
ssh-copy-id user@server
Now would be a good time to perform any tasks specific to your setup.
sudo
sudo
lets accounts run commands as other accounts, including root. We want to make sure that only the accounts we want can use sudo
.
sudo
privileges limited to those who are in a group we specifysudo
groupwheel
groupCreate a group:
sudo groupadd sudo
Add account(s) to the group:
sudo usermod -a -G sudo user1
sudo usermod -a -G sudo user2
sudo usermod -a -G sudo ...
You'll need to do this for every account on your server that needs sudo
privileges.
Edit /etc/sudoers
:
sudo cp --preserve /etc/sudoers /etc/sudoers.$(date +"%Y%m%d%H%M%S")
sudo visudo
Add this line if it is not already there:
%sudo ALL=(ALL:ALL) ALL
sysctl
Hardening (WIP)umask
umask
controls the default permissions of files/folders when they are created. Insecure file/folder permissions give other accounts potentially unauthorized access to your data. This may include the ability to make configuration changes.
When and if other accounts need access to a file/folder, you want to explicitly grant it using a combination of file/folder permissions and primary group.
Changing the default umask
can create unexpected problems. For example, if you set umask
to 0077
for root, then non-root accounts will not have access to application configuration files/folders in /etc/
which could break applications.
umask
for non-root accounts to 0027umask
for the root account to 0077umask
is a Bash built-in which means a user can change their own umask
setting.man umask
Set default umask
for non-root accounts to 0027 by adding this line to /etc/profile
and /etc/bash.bashrc
:
umask 0027
sudo cp --preserve /etc/profile /etc/profile.$(date +"%Y%m%d%H%M%S")
sudo cp --preserve /etc/bash.bashrc /etc/bash.bashrc.$(date +"%Y%m%d%H%M%S")
echo -e "\numask 0027 # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")" | sudo tee -a /etc/profile /etc/bash.bashrc
We also need to add this line to /etc/login.defs
:
UMASK 0027
sudo cp --preserve /etc/login.defs /etc/login.defs.$(date +"%Y%m%d%H%M%S")
echo -e "\nUMASK 0027 # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")" | sudo tee -a /etc/login.defs
!! USE WITH CAUTION !! -- Set default umask
for the root account to 0077 by adding this line to /root/.bashrc
:
umask 0077
sudo cp --preserve /root/.bashrc /root/.bashrc.$(date +"%Y%m%d%H%M%S")
echo -e "\numask 0077 # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")" | sudo tee -a /root/.bashrc
If a bad actor has physical access to your server, they could use GRUB to gain unauthorized access to your system.
If you forget the password, you'll have to go through some work to recover the password.
man grub
man grub-mkpasswd-pbkdf2
Create a Password-Based Key Derivation Function 2 (PBKDF2) hash of your password:
grub-mkpasswd-pbkdf2 -c 100000
The below output is from using password
as the password:
Enter password:
Reenter password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.100000.2812C233DFC899EFC3D5991D8CA74068C99D6D786A54F603E9A1EFE7BAEDDB6AA89672F92589FAF98DB9364143E7A1156C9936328971A02A483A84C3D028C4FF.C255442F9C98E1F3C500C373FE195DCF16C56EEBDC55ABDD332DD36A92865FA8FC4C90433757D743776AB186BD3AE5580F63EF445472CC1D151FA03906D08A6D
Copy everything after PBKDF2 hash of your password is
, starting from and including grub.pbkdf2.sha512...
to the end. You'll need this in the next step.
Create the file /etc/grub.d/01_password
and add the below code after replacing [hash]
with the hash you copied from the first step:
#!/bin/sh
set -e
cat << EOF
set superusers="grub"
password_pbkdf2 grub [hash]
EOF
For example:
#!/bin/sh
set -e
cat << EOF
set superusers="grub"
password_pbkdf2 grub grub.pbkdf2.sha512.100000.2812C233DFC899EFC3D5991D8CA74068C99D6D786A54F603E9A1EFE7BAEDDB6AA89672F92589FAF98DB9364143E7A1156C9936328971A02A483A84C3D028C4FF.C255442F9C98E1F3C500C373FE195DCF16C56EEBDC55ABDD332DD36A92865FA8FC4C90433757D743776AB186BD3AE5580F63EF445472CC1D151FA03906D08A6D
EOF
Set the file's execute bit so update-grub
includes it when it updates GRUB's configuration:
sudo chmod a+x /etc/grub.d/01_password
Make a backup of /etc/grub.d/10_linux
and unset execute bit so update-grub
doesn't try to run it:
sudo cp --preserve /etc/grub.d/10_linux /etc/grub.d/10_linux.$(date +"%Y%m%d%H%M%S")
sudo chmod a-x /etc/grub.d/10_linux.*
To make the default Debian install unrestricted (without the password) while keeping everything else restricted (with the password) modify /etc/grub.d/10_linux
and add --unrestricted
to the CLASS
variable.
sudo sed -i -r -e "/^CLASS=/ a CLASS=\"\${CLASS} --unrestricted\" # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")" /etc/grub.d/10_linux
Update GRUB with update-grub
:
sudo update-grub
If you have sudo
configured properly, then the root account will mostly never need to log in directly -- either at the terminal or remotely.
Be warned, this can cause issues with some configurations!
If your installation uses sulogin
(like Debian) to drop to a root console during boot failures, then locking the root account will prevent sulogin
from opening the root shell and you will get this error:
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Press Enter to continue.
To work around this, you can use the --force
option for sulogin
. Some distributions already include this, or some other, workaround.
An alternative to locking the root acount is set a long/complicated root password and store it in a secured, non digital format. That way you have it when/if you need it.
man systemd
!! USE WITH CAUTION !! -- Lock the root account:
sudo passwd -l root
AllowGroups
To make it easy to control who can SSH to the server.
/etc/ssh/sshd_config
to limit who can SSH to the serverAllowGroup
setting set in Secure /etc/ssh/sshd_config
.man groupadd
man usermod
Create a group:
sudo groupadd sshusers
Add account(s) to the group:
sudo usermod -a -G sshusers user1
sudo usermod -a -G sshusers user2
sudo usermod -a -G sshusers ...
You'll need to do this for every account on your server that needs SSH access.
/etc/ssh/sshd_config
SSH is a door into your server. This is especially true if you are opening ports on your router so you can SSH to your server from outside your home network. If it is not secured properly, a bad-actor could use it to gain unauthorized access to your system.
AllowGroups
first.man sshd_config
Make a backup of /etc/ssh/sshd_config
:
sudo cp --preserve /etc/ssh/sshd_config /etc/ssh/sshd_config.$(date +"%Y%m%d%H%M%S")
Edit /etc/ssh/sshd_config
then find and edit or add these settings that should apply regardless of your configuration/setup:
########################################################################################################
# start settings from https://infosec.mozilla.org/guidelines/openssh#modern-openssh-67 as of 2019-01-01
########################################################################################################
# Supported HostKey algorithms by order of preference.
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
# LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in.
LogLevel VERBOSE
# Log sftp level file access (read/write/etc.) that would not be easily logged otherwise.
Subsystem sftp /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO
# Use kernel sandbox mechanisms where possible in unprivileged processes
# Systrace on OpenBSD, Seccomp on Linux, seatbelt on MacOSX/Darwin, rlimit elsewhere.
UsePrivilegeSeparation sandbox
########################################################################################################
# end settings from https://infosec.mozilla.org/guidelines/openssh#modern-openssh-67 as of 2019-01-01
########################################################################################################
# only use the newer, more secure protocl
Protocol 2
# disable X11 forwarding as X11 is very insecure
# you really shouldn't be running X on a server anyway
X11Forwarding no
# disable port forwarding
AllowTcpForwarding no
AllowStreamLocalForwarding no
GatewayPorts no
PermitTunnel no
# don't allow login if the account has an empty password
PermitEmptyPasswords no
# ignore .rhosts and .shosts
IgnoreRhosts yes
# verify hostname matches IP
UseDNS no
Compression no
TCPKeepAlive no
AllowAgentForwarding no
PermitRootLogin no
Then find and edit or add these settings, and set values as per your requirements:
Setting | Valid Values | Example | Description | Notes |
---|---|---|---|---|
AllowGroups | local UNIX group name | AllowGroups sshusers |
group to allow SSH access to | |
ClientAliveCountMax | number | ClientAliveCountMax 0 |
maximum number of client alive messages sent without response | |
ClientAliveInterval | number of seconds | ClientAliveInterval 300 |
timeout in seconds before a response request | |
ListenAddress | space separated list of local addresses |
|
local addresses sshd should listen on |
See Issue #1 for important details. |
LoginGraceTime | number of seconds | LoginGraceTime 30 |
time in seconds before login times-out | |
MaxAuthTries | number | MaxAuthTries 2 |
maximum allowed attempts to login | |
MaxSessions | number | MaxSessions 2 |
maximum number of open sessions | |
MaxStartups | number | MaxStartups 2 |
maximum number of login sessions | |
PasswordAuthentication | yes or no |
PasswordAuthentication no |
if login with a password is allowed | |
Port | any open/available port number | Port 22 |
port that sshd should listen on |
Check man sshd_config
for more details what these settings mean.
Restart ssh:
sudo service sshd restart
Per Mozilla's OpenSSH guidelines for OpenSSH 6.7+, "all Diffie-Hellman moduli in use should be at least 3072-bit-long".
man moduli
Make a backup of /etc/ssh/moduli
:
sudo cp --preserve /etc/ssh/moduli /etc/ssh/moduli.$(date +"%Y%m%d%H%M%S")
Remove short moduli:
sudo awk '$5 >= 3071' /etc/ssh/moduli | sudo tee /etc/ssh/moduli.tmp
sudo mv /etc/ssh/moduli.tmp /etc/ssh/moduli
By default, accounts can use any password they want, including bad ones. pwquality/pam_pwquality addresses this security gap by providing "a way to configure the default password quality requirements for the system passwords" and checking "its strength against a system dictionary and a set of rules for identifying poor choices."
Install libpam-pwquality
.
For Debian based systems:
sudo apt install libpam-pwquality
Edit /etc/pam.d/common-password
and change the line that starts like this:
password requisite pam_pwquality.so
to this:
password requisite pam_pwquality.so retry=3 minlen=10 difok=3 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1 maxrepeat=3 gecoschec
The above options are:
retry=3
= prompt user 3 times before returning with error.minlen=10
= the minimum length of the password, factoring in any credits (or debits) from these:
dcredit=-1
= must have at least one digitucredit=-1
= must have at least one upper case letterlcredit=-1
= must have at least one lower case letterocredit=-1
= must have at least one non-alphanumeric characterdifok=3
= at least 3 characters from the new password cannot have been in the old passwordmaxrepeat=3
= allow a maximum of 3 repeated charactersgecoschec
= do not allow passwords with the account's namesudo cp --preserve /etc/pam.d/common-password /etc/pam.d/common-password.$(date +"%Y%m%d%H%M%S")
sudo sed -i -r -e "s/^(password\s+requisite\s+pam_pwquality.so)(.*)$/# \1\2 # commented by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")\n\1 retry=3 minlen=10 difok=3 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1 maxrepeat=3 gecoschec # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")/" /etc/pam.d/common-password
Call me paranoid but I want to deny all traffic in and out of my server except what I explicitly allow. Why would my server be sending traffic out that I don't know about? And why would external traffic be trying to access my server if I don't know who or what it is? When it comes to good security, reject/deny by default, and allow by exception.
Ensuring that only traffic we explicitly allow is the job of a firewall. On Linux, the most common firewall is iptables. iptables, however, is rather complicated and confusing (IMHO). This is where UFW comes in. UFW simplifies the process of creating and managing iptables rules.
UFW works by letting you configure rules that:
You can create rules by explicitly specifying the ports or with application configurations that specify the ports.
Install ufw
.
For Debian based systems:
sudo apt install ufw
Deny all outgoing traffic:
sudo ufw default deny outgoing comment 'deny all outgoing traffic'
If you are not as paranoid as me, and don't want to deny all outgoing traffic, you can allow it instead:
sudo ufw default allow outgoing comment 'allow all outgoing traffic'
Deny all incoming traffic:
sudo ufw default deny incoming comment 'deny all incoming traffic'
Obviously we want SSH connections in:
sudo ufw limit in ssh comment 'allow SSH connections in'
Allow additional traffic as per your needs. Some common use-cases:
# allow traffic out on port 53 -- DNS
sudo ufw allow out 53 comment 'allow DNS calls out'
# allow traffic out on port 123 -- NTP
sudo ufw allow out 123 comment 'allow NTP out'
# allow traffic out for HTTP, HTTPS, or FTP
# apt might needs these depending on which sources you're using
sudo ufw allow out http comment 'allow HTTP traffic out'
sudo ufw allow out https comment 'allow HTTPS traffic out'
sudo ufw allow out ftp comment 'allow FTP traffic out'
# allow mail to go out
sudo ufw allow out 'Mail submission' comment 'allow mail out'
# allow whois
sudo ufw allow out whois comment 'allow whois'
# allow traffic out on port 68 -- the DHCP client
sudo ufw allow out 68 comment 'allow the DHCP client to update'
Start ufw
:
sudo ufw enable
If you want to see a status:
sudo ufw status
or
sudo ufw status verbose
ufw
ships with some default applications. You can see them with:
sudo ufw app list
To get details about the app, like which ports it includes, type:
sudo ufw app info [app name]
For example:
$ sudo ufw app info DNS
Profile: DNS
Title: Internet Domain Name Server
Description: Internet Domain Name Server
Port:
53
If you don't want to create rules by explicitly providing the port number(s), you can create your own application configurations. To do this, create a file in /etc/ufw/applications.d
.
For example, here is what you would use for Plex:
$ cat /etc/ufw/applications.d/plexmediaserver
[PlexMediaServer]
title=Plex Media Server
description=This opens up PlexMediaServer for http (32400), upnp, and autodiscovery.
ports=32469/tcp|32413/udp|1900/udp|32400/tcp|32412/udp|32410/udp|32414/udp|32400/udp
Then you can enable it like any other app:
sudo ufw allow plexmediaserver
A firewall will board up all the doors and windows you don't want anyone using so nobody can see they are even there. But what about the doors and windows you want visible so approved folks can use them? Even if the door is locked, how do you ensure that someone doesn't try to force their way in?
That is where Fail2ban comes in. It will monitor network traffic/logs and prevent intrusions by blocking suspicious activity (e.g. multiple successive failed connections in a short time-span).
Install fail2ban
.
For Debian based systems:
sudo apt install fail2ban
We don't want to edit /etc/fail2ban/fail2ban.conf
or /etc/fail2ban/jail.conf
because a future update may overwrite those so we'll update a local copy instead. Add this to /etc/fail2ban/jail.local
after replacing [LAN SEGMENT]
and [your email]
with the appropriate values:
[DEFAULT]
# the IP address range we want to ignore
ignoreip = 127.0.0.1/8 [LAN SEGMENT]
# who to send e-mail to
destemail = [your e-mail]
# who is the email from
sender = [your e-mail]
# since we're using exim4 to send emails
mta = mail
# get email alerts
action = %(action_mwl)s
Note: Your server will need to be able to send e-mails so Fail2ban an let you know of suspicious activity and when it banned an IP.
Create a jail for ssh
by adding this to /etc/fail2ban/jail.d/ssh.local
:
[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
maxretry = 5
Enable fail2ban
and the jail for SSH:
sudo fail2ban-client start
sudo fail2ban-client reload
sudo fail2ban-client add sshd
To check the status:
sudo fail2ban-client status
sudo fail2ban-client status sshd
WIP
Even though SSH is a pretty good security guard for your doors and windows, it is still a visible door that bad-actors can see and try to brute-force in. Fail2ban will monitor for these brute-force attempts but there is no such thing as being too secure.
Using Two Factor Authentication (2FA) / Multi Factor Authentication (MFA) requires anyone entering to have two keys to enter which makes it harder for bad actors. The two keys are:
Without both keys, they won't be able to get in.
Many folks might find the experience cumbersome or annoying. And, acesss to your system is dependent on the accompanying authenticator app that generates the code.
Install it libpam-google-authenticator
.
For Debian based systems:
sudo apt install libpam-google-authenticator
Make sure you're logged in as the ID you want to enable 2FA/MFA for and execute google-authenticator
:
google-authenticator
Notice this is not run as root.
Select default option (y in most cases) for all the questions it asks and remember to save the emergency scratch codes.
Now we need to enable it as an authentication method for SSH by adding this line to /etc/pam.d/sshd
:
auth required pam_google_authenticator.so nullok
Check here for what nullok
means.
sudo cp --preserve /etc/pam.d/sshd /etc/pam.d/sshd.$(date +"%Y%m%d%H%M%S")
echo -e "\nauth required pam_google_authenticator.so nullok # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")" | sudo tee -a /etc/pam.d/sshd
Enable it in the SSH settings by adding this line in /etc/ssh/sshd_config
:
ChallengeResponseAuthentication yes
sudo cp --preserve /etc/ssh/sshd_config /etc/ssh/sshd_config.$(date +"%Y%m%d%H%M%S")
echo -e "\nChallengeResponseAuthentication yes # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")" | sudo tee -a /etc/ssh/sshd_config
Restart ssh
:
sudo service sshd restart
It is important to keep your server up-to-date with all security patches. Otherwise you're at risk of known security vulnerabilities that bad-actors could use to gain unauthorized access to your server.
You have two options:
Which option you pick is up to you but I prefer being notified by e-mail when updates are available. This is because an update may break something else. If the server updates it-self then I may not know and, if I do find out, I'll have to scramble to fix it. If it e-mails me when updates are available, then I can do the updates at my schedule.
Install apticron
.
For Debian based systems:
sudo apt install apticron
Set the value of EMAIL
in /etc/apticron/apticron.conf
to your e-mail address.
As you use your system, and you install and uninstall software, you'll eventually end up with orphaned, or unused software/packages/libraries. You don't need to remove them, but if you don't need them, why keep them? When security is a priority, anything not explicitly needed is a potential security threat. You want to keep your server as trimmed and lean as possible.
For Debian based distributions, you can use deborphan to find orphaned packages.
Install deborphan
:
sudo apt install deborphan
Run deborphan
as root to see a list of orphaned packages:
sudo deborphan
Pass it's output to apt
to remove them:
sudo apt --autoremove purge $(deborphan)
You will want to repeatedly run this command until deborphan
no longer returns any orphaned packages.
while [[ $(deborphan | wc -l) != 0 ]] ; do
sudo apt --autoremove purge $(deborphan)
done
Unless you're planning on setting up your own mail server, you'll need a way to send e-mails from your server. This will be important for system alerts/messages.
mail
configured to send e-mails from your server using GmailInstall exim4
.
For Debian based systems:
sudo apt install exim4
Configure exim4
:
For Debian based systems:
sudo dpkg-reconfigure exim4-config
You'll be prompted with some questions:
Prompt | Answer |
---|---|
General type of mail configuration | mail sent by smarthost; no local mail |
System mail name | (default) |
IP-addresses to listen on for incoming SMTP connections | 127.0.0.1 |
Other destinations for which mail is accepted | (default) |
Visible domain name for local users | (default) |
IP address or host name of the outgoing smarthost | smtp.gmail.com::587 |
Keep number of DNS-queries minimal (Dial-on-Demand)? | No |
Split configuration into small files? | No |
Add a line like this to /etc/exim4/passwd.client
*.google.com:yourAccount@gmail.com:yourPassword
Replace yourAccount@gmail.com
and yourPassword
with your details. If you have 2FA/MFA enabled on your Gmail then you'll need to create and use an app password.
This file has your Gmail password so we need to lock it down:
sudo chown root:Debian-exim /etc/exim4/passwd.client
sudo chmod 640 /etc/exim4/passwd.client
Restart exim4
:
sudo service exim4 restart
Add some mail aliases so we can send e-mails to local accounts by adding lines like this to /etc/aliases
:
user1: user1@gmail.com
user2: user2@gmail.com
...
You'll need to add all the local accounts that exist on your server.
From https://cisofy.com/lynis/:
Lynis is a battle-tested security tool for systems running Linux, macOS, or Unix-based operating system. It performs an extensive health scan of your systems to support system hardening and compliance testing.
We want it to be installed system wide so go to /usr/local
and clone it from https://github.com/CISOfy/lynis:
cd /usr/local
sudo git clone https://github.com/CISOfy/lynis
Update it:
sudo /usr/local/lynis/lynis update info
Run a security audit:
sudo /usr/local/lynis/lynis audit system
This will scan your server, report its audit findings, and at the end it will give you suggestions. Spend some time going through the output and address gaps as necessary.
/tmp
In RAM Using tmpfs
RAM is faster than disk, even SSD. By mounting /tmp
in RAM using tmpfs
, you may notice a performance increase.
Using tmpfs
will consume RAM. If RAM fills up your system may become unstable. tmpfs
may resort to using swap.
man mount
man tmpfs
Add this line to /etc/fstab
:
tmpfs /tmp tmpfs defaults,noatime,rw,nodev,nosuid,nodiratime,mode=1777,size=2GB 0 0
Change the value of size
to suit your needs. If you remove the size
option then it will default to using half of your RAM.
sudo cp --preserve /etc/fstab /etc/fstab.$(date +"%Y%m%d%H%M%S")
echo -e "\ntmpfs /tmp tmpfs defaults,noatime,rw,nodev,nosuid,nodiratime,mode=1777,size=2G 0 0 # added by $(whoami) on $(date +"%Y-%m-%d @ %H:%M:%S")" | sudo tee -a /etc/fstab
For any questions, comments, concerns, feedback, or issues, submit a new issue.
This guide comes with ABSOLUTELY NO WARRANTY. Use with caution.