Build

SUDO – Superuser do

Adding users to the sudo/doas/wheel group is a straightforward way to grant root-like access, especially in a multi-user environment where multiple users need administrative privileges. Is it wise – no, is it needed – sometimes. See also the Fail2ban section.

Nalle

Nalle

— 4 min read
Share
SUDO – Superuser do
Photo by Jon Tyson / Unsplash

The sudo (superuser do) or the doas or wheel command allows a user to execute a command as the superuser or another user. It provides a way to perform administrative tasks without logging in as the root user.

    • Enhancing security by limiting the exposure of the root account.
    • Weakening the security by elevate users to root access.

Best Practices for the sudo / doas / wheel groups

Limit Access

  • Only grant sudo, doas or wheel access to users who truly need it.
  • Avoid giving full sudo access to all users.
  • Define specific commands they can run as sudo, doas or wheel

Regular Auditing

Periodically review the sudoers file to ensure that only authorized users have the appropriate sudo permissions.

Use Logging

Enable sudo logging to track who is using sudo and what commands they are running.
In most Linux distributions, sudo logging is already enabled, and logs can be found in /var/log/auth.log (Ubuntu).

From Debian 8 (Jessie), systemd is installed by default. By default, there is no more
/var/log/auth.log. You can view the log of SSHD with the following command :

journalctl -u ssh.service

No rsyslog !

Some minimal images of a distro might miss the rsyslog.
If your fail2ban looks for authentication events in /var/log/auth.log you have a big security issue. Typically, it's replaced by the systemd "journal" facility. That's why the file auth.log is missing and fail2ban won't start.

To get the good old log files back, install rsyslog, and fail2ban will work properly.

sudo apt-get install rsyslog

Adding fail2ban protection to your node/VM

If you allow root level access in any form additional protection is needed.

Debian and others don't usually use rsyslog because they have systemd logging.

Using systemd with fail2ban

You can secure your SSH login using fail2ban, disable direct root login, or use public key authentication. The fail2ban will temporarily block IP addresses after a defined number of failed login attempts.

Install fail2ban using the following command or see the GitHub for other ways:

apt install fail2ban

Configuring fail2ban with systemd

In the /etc/fail2ban/ directory, you'll find the global configuration file jail.conf.
Do not edit this file, as it gets overwritten during package updates.

Copy the file

Copy it to jail.local for your own configuration:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

nano /etc/fail2ban/jail.local

Edit settings

Edit the settings in jail.local to match your requirements.
Example: increase ban time to 30 minutes and reduce the maximum retry attempts to 3:

[...]
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1
bantime  = 30m
findtime  = 10m
maxretry = 3
[...]

[...]
[sshd]
enabled = true
mode   = normal
port    = ssh
logpath = %(sshd_log)s
backend = systemd
enabled = true
[...]

Check that you changed the backend to systemd.

Restarting fail2ban

After making the necessary changes, restart fail2ban to apply the new settings:

systemctl restart fail2ban.service

After some time you can check if IPs can be ban failed attempts to log in for ## min.
If you have IPs banned, see example. That means success – fail2ban is working correctly.

fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- Journal matches:	_SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
|- Currently banned:	2
|- Total banned:	2
`- Banned IP list:	192.0.2.100 10.10.10.100

Example: fail2ban is working

References

Fail2ban [1]

  1. Fail2ban Wikipedia, getting started GitHub ↩︎

Read more