This category contains GNU/Linux tutorials and articles.

Preventing root access

Introduction

This is the second article in a series about hardening the security of GNU/Linux systems. This serie aims to provide useful, practical, hands on and easy to follow tutorial-like articles for any system administrator or user to implement.

In this series of articles we’ll use the CentOS 7 (Community Enterprise Operating System)[1] as our default operating system. CentOS is a free, enterprise-class, community-supported computing platform functionally compatible with its upstream source, Red Hat Enterprise Linux (RHEL)[2]. If you prefer an alternative operating system, please note that some configurations and packages might differ from what is described here.

If you like this article, have suggestions or comments; please feel free to leave a comment bellow.

About this article

This article provide instructions on how to configure your system to prevent any user, administrator or device to directly access the root account. By following the steps in this article your systems security will be tightened and many automated attacks, trying to access the root account, are avoided.

Preventing root access

Prevent remote access through SSH

The first step and the most simple configuration to make is to prevent the root account to remotely access your system through the SSH protocol. Permitting root to access a system through SSH exposes it to many automated attacks. By not permitting root access, any attacker would need to guess not only the password but a username as well, significantly increasing the complexity of the operation.

The configurations for permitting or restricting the root account to access a system trough SSH are done in the SSH daemon’s configuration file, the /etc/sshd_config file. Restricting access to the root account through SSH will only prevent the remote login. Any system administrator or user granted administrative authorities will still be able to remotely administrating the system using the sudo or su application, once a secure connection has been established.

The following two lines will restrict the root account to access the system through SSH:

sudo sed -i -e 's/#PermitRootLogin no/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart sshd.service

Changing the root shell

The second step would be to prevent users or administrators to directly access the root account. This is achieved by changing the root account’s shell in the /etc/passwd configuration file and set it to /sbin/nologin.

This configuration will now prevent any access to the root shell and will log any attempts to access it. This configuration does only apply to login, gdm (or any other desktop manager), su, scp, sftp or any other application that requires a shell. Applications like sudo, ftp and e-mail clients are not affected by this configuration.

The following command line will change the root shell:

sudo sed -i -e '1 s:/bin/bash:/sbin/nologin:' /etc/passwd

Prevent access through console devices

The third step would be to prevent root access to any console devices (TTY) or raw network interfaces. This is achieved by modifying the /etc/securetty configuration file. The /etc/securetty configuration file allows you to specify which TTY devices the root account is allowed to login on to. Any device not specified in this file will not permit access.

The configuration file can either be left completely blanked or each device in the configuration file could be commented out, making it easier to restore the file if needed. A missing configuration file will be interpreted as allowing access to any console device. Therefor the file should under no circumstances be removed. The following command line will put the # symbol before each line, commenting out all devices:

sudo sed -i -e 's/^/#/' /etc/securetty

Please note that this configuration does not affect applications such as ssh, scp or sftp since the console is not opened until after authentication. This, however, was already managed by not permitting root to login via the SSH protocol.

Additional configurations

By taking these three steps we successfully tightened our systems security and now prevent any user to directly login to the root account. To take things even further we could use PAM (Pluggable Authentication Modules)[3]. PAM uses a pluggable, modular architecture, which affords the system administrator a great deal of flexibility in setting authentication policies for the system.

PAM offers the following advantages:

  • a common authentication scheme that can be used with a wide variety of applications.
  • significant flexibility and control over authentication for both system administrators and application developers.
  • a single, fully-documented library which allows developers to write programs without having to create their own authentication schemes.

A tutorial on how to set up PAM to further tighten your system security will be written in the future. Subscribe to this blog to get notified whenever a new post is published. If you liked this tutorial or have suggestions on how to better configure your system, please leave a comment below.

Referenses

  1. https://www.centos.org
  2. https://wiki.centos.org/FAQ/General#head-4b2dd1ea6dcc1243d6e3886dc3e5d1ebb252c194
  3. https://en.wikipedia.org/wiki/Linux_PAM

Enabling automatic updates

Introduction

This is the first article in a series about hardening the security of GNU/Linux systems. This serie aims to provide useful, practical, hands on and easy to follow tutorial-like articles for any system administrator or user to implement.

In this series of articles we’ll use the CentOS 7 (Community Enterprise Operating System)[1] as our default operating system. CentOS is a free, enterprise-class, community-supported computing platform functionally compatible with its upstream source, Red Hat Enterprise Linux (RHEL)[2]. If you prefer an alternative operating system, please note that some configurations and packages might differ from what is described here.

If you like this article, have suggestions or comments; please feel free to leave a comment bellow.

About this article

This article provide instructions on how to set up your system to automatically download and install updates or patches using the yum-cron package. Having your system up to date is vital to maintain the integrity of your system and the data it contains. Every day thousands of thousands of system are subject to automated attacks that exploit known security flaws. Having an outdated or unpatched system makes you easy target for any such attack.

Enabling automatic updates

The yum-cron package

About

yum-cron is an alternate interface to yum that is optimised to be convenient to call from cron. It provides methods to keep repository metadata up to date, and to check for, download, and apply updates.

Rather than accepting many different command line arguments, the different functions of yum-cron can be accessed through config files. config-file is used to optionally specify the path to the configuration file to use. If it is not given, the default configuration file will be used. It is useful to be able to specify different configuration files for different use cases. For example, one configuration file might be set to update the repository metadata, and a line could be added to the crontab to run yum-cron frequently using this file. Then, another configuration file might be set to install updates, and yum-cron could be run from cron using this file just once each day [3].

Installing yum-cron

The yum-cron package is located in the default CentOS repository. It can easily be installed from the terminal:

sudo yum install -y yum-cron

Configuring yum-cron

The yum-cron configuration file(s) enables a wide variety of settings. The configuration file is relatively easy to understand and modify for any needs. The main configuration file for yum-cron is /etc/yum/yum-cron.conf and states the following:

[commands]
#  What kind of update to use:
# default                            = yum upgrade
# security                           = yum --security upgrade
# security-severity:Critical         = yum --sec-severity=Critical upgrade
# minimal                            = yum --bugfix update-minimal
# minimal-security                   = yum --security update-minimal
# minimal-security-severity:Critical =  --sec-severity=Critical update-minimal
update_cmd = default

# Whether a message should be emitted when updates are available,
# were downloaded, or applied.
update_messages = yes

# Whether updates should be downloaded when they are available.
download_updates = yes

# Whether updates should be applied when they are available.  Note
# that download_updates must also be yes for the update to be applied.
apply_updates = no

# Maximum amout of time to randomly sleep, in minutes.  The program
# will sleep for a random amount of time between 0 and random_sleep
# minutes before running.  This is useful for e.g. staggering the
# times that multiple systems will access update servers.  If
# random_sleep is 0 or negative, the program will run immediately.
# 6*60 = 360
random_sleep = 360


[emitters]
# Name to use for this system in messages that are emitted.  If
# system_name is None, the hostname will be used.
system_name = None

# How to send messages.  Valid options are stdio and email.  If
# emit_via includes stdio, messages will be sent to stdout; this is useful
# to have cron send the messages.  If emit_via includes email, this
# program will send email itself according to the configured options.
# If emit_via is None or left blank, no messages will be sent.
emit_via = stdio

# The width, in characters, that messages that are emitted should be
# formatted to.
output_width = 80


[email]
# The address to send email messages from.
# NOTE: 'localhost' will be replaced with the value of system_name.
email_from = root@localhost

# List of addresses to send messages to.
email_to = root

# Name of the host to connect to to send email messages.
email_host = localhost


[groups]
# NOTE: This only works when group_command != objects, which is now the default
# List of groups to update
group_list = None

# The types of group packages to install
group_package_types = mandatory, default

[base]
# This section overrides yum.conf

# Use this to filter Yum core messages
# -4: critical
# -3: critical+errors
# -2: critical+errors+warnings (default)
debuglevel = -2

# skip_broken = True
mdpolicy = group:main

# Uncomment to auto-import new gpg keys (dangerous)
# assumeyes = True

The first and most important configuration to make is to enable yum-cron to actually install the updates. The default value for apply_update is set to no, resulting in new updates or patches being downloaded but not installed.

sudo sed -i -e 's/apply_updates = no/apply_updates = yes/' /etc/yum/yum-cron.conf

For most systems, especially client workstations, this configuration would now be sufficient. The default value for update_command is set to default, resulting in the download and installation of any new updates or patches. However this might not suit all kinds of systems.

While having your system up to date is vital to maintain the integrity of your system, not all software updates contain critical security patches. Having a live production system set to install any available updates could potentially lead to server or service downtime. Any non-critical update should probably be tested in a sandbox environment before being deployed onto the live environment.

To resolve this issue yum-cron can be configured to restrict automatic updates of packages that isn’t marked as security update or patch. It can even be configured to restrict any packages that hasn’t been marked as a critical security updates. For any live production system, especially the once connected to the Internet, security updates is likely a good choice.

sudo sed -i -e 's/update_cmd = default/update_cmd = security/' /etc/yum/yum-cron.conf

Starting the service

The final two steps are to enable the yum-cron service on system startup and to start the service:

sudo systemctl enable yum-cron.service
sudo systemctl start yum-cron.service

References

  1. https://www.centos.org
  2. https://wiki.centos.org/FAQ/General#head-4b2dd1ea6dcc1243d6e3886dc3e5d1ebb252c194
  3. http://man7.org/linux/man-pages/man8/yum-cron.8.html