Introduction to Securing Manjaro Servers
Manjaro Linux, a popular Arch-based distribution, has gained traction not only as a desktop operating system but also as a server platform. Its rolling release model, access to the Arch User Repository (AUR), and cutting-edge packages make it an attractive choice for developers and system administrators. However, with great flexibility comes the responsibility of proper security configuration. Unlike enterprise-focused distributions such as RHEL or Ubuntu Server, Manjaro does not ship with hardened server defaults out of the box.
This tutorial provides a practical, hands-on checklist for securing a Manjaro server. Whether you are deploying a web server, a database host, or a container runtime, following these steps will significantly reduce your attack surface and improve your overall security posture.
Why Server Hardening Matters
Server hardening is the process of reducing a system's vulnerability exposure by configuring it securely, removing unnecessary services, and applying defense-in-depth principles. A fresh Manjaro installation is designed to be user-friendly, which often means more services are enabled, more ports are open, and more default configurations are left in place than a production server should allow.
Attackers routinely scan the internet for exposed services with default credentials, outdated software, and misconfigured permissions. Without hardening, your server could be compromised within minutes of being exposed to the public internet. Hardening also helps you meet compliance requirements such as GDPR, HIPAA, or PCI-DSS, which mandate specific security controls.
Prerequisites
Before you begin, ensure you have:
- A Manjaro server installation with root or sudo access
- A stable internet connection
- Basic familiarity with the command line and pacman package manager
- A backup of any critical data before making system changes
Step 1: Keep the System Updated
The first and most fundamental security practice is keeping your system fully updated. Manjaro's rolling release model means updates are frequent, and security patches are delivered as soon as upstream projects release them. Stale systems are prime targets for exploitation.
# Update all packages
sudo pacman -Syu
# Clean the package cache to save space and reduce risk of downgrade attacks
sudo paccache -r
# Optionally, remove all cached packages except the most recent three versions
sudo paccache -rk3
Consider setting up automatic updates using a tool like unattended-upgrades equivalents or a cron job. However, because Manjaro is a rolling release, automatic updates can occasionally break the system. A safer approach is to subscribe to security advisories and apply updates manually after testing.
Step 2: Create a Non-Root User with Sudo Privileges
Running services or performing daily tasks as the root user is dangerous. A single mistake or compromised process can destroy the entire system. Instead, create a dedicated user account with limited sudo access.
# Create a new user
sudo useradd -m -G wheel -s /bin/bash deployuser
# Set a strong password
sudo passwd deployuser
# Verify the wheel group has sudo privileges
sudo visudo
In the sudoers file, ensure the following line is uncommented:
%wheel ALL=(ALL) ALL
This grants sudo access to all members of the wheel group. For even tighter security, you can restrict sudo to specific commands by creating custom sudoers entries.
Step 3: Secure SSH Access
SSH is the primary remote administration protocol for Linux servers, and it is also one of the most commonly attacked services. Securing SSH is critical.
Disable Root Login and Password Authentication
Edit the SSH daemon configuration file at /etc/ssh/sshd_config:
# Disable root login over SSH
PermitRootLogin no
# Disable password authentication
PasswordAuthentication no
# Limit SSH to specific users
AllowUsers deployuser
# Change the default SSH port (optional but reduces noise)
Port 2222
# Disable empty passwords
PermitEmptyPasswords no
# Set a login grace timeout
LoginGraceTime 30
# Limit authentication attempts
MaxAuthTries 3
Before restarting SSH, ensure you have set up SSH key-based authentication:
# On your local machine, generate an SSH key pair
ssh-keygen -t ed25519 -C "deploy@server"
# Copy the public key to the server
ssh-copy-id -p 2222 deployuser@your-server-ip
# Restart the SSH service on the server
sudo systemctl restart sshd
Always test your new SSH connection in a separate terminal before closing your existing session to avoid locking yourself out.
Install and Configure Fail2Ban
Fail2Ban monitors log files for repeated failed login attempts and temporarily bans offending IP addresses using firewall rules.
# Install Fail2Ban
sudo pacman -S fail2ban
# Create a local configuration file
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
# Edit the local configuration
sudo nano /etc/fail2ban/jail.local
Configure the SSH jail in jail.local:
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600
# Enable and start Fail2Ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
Step 4: Configure a Firewall
A firewall controls incoming and outgoing network traffic based on predetermined security rules. Manjaro does not enable a firewall by default, so you must configure one manually. UFW (Uncomplicated Firewall) is an excellent choice for simplicity.
# Install UFW
sudo pacman -S ufw
# Default policies: deny incoming, allow outgoing
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Allow your custom SSH port
sudo ufw allow 2222/tcp
# Allow HTTP and HTTPS if running a web server
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# Enable the firewall
sudo ufw enable
# Check the status
sudo ufw status verbose
Always verify that your SSH port is allowed before enabling the firewall, or you will lock yourself out of the server.
Step 5: Disable Unnecessary Services
Every running service is a potential attack vector. Audit your system for unnecessary services and disable them.
# List all enabled services
sudo systemctl list-unit-files --state=enabled
# Disable a specific service
sudo systemctl disable servicename
# Stop a running service
sudo systemctl stop servicename
# Mask a service to prevent it from being started manually or by dependencies
sudo systemctl mask servicename
Common services to review and potentially disable include Bluetooth, Avahi (mDNS), and printing services, none of which are typically needed on a server.
Step 6: Secure Shared Memory and Kernel Parameters
The Linux kernel exposes many tunable parameters through /proc/sys. You can harden your system by adjusting these values in /etc/sysctl.d/99-security.conf.
# Create a sysctl configuration file
sudo nano /etc/sysctl.d/99-security.conf
Add the following hardening parameters:
# Prevent IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Ignore ICMP broadcast requests (smurf attacks)
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Disable source packet routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
# Ignore ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
# Log suspicious packets (martians)
net.ipv4.conf.all.log_martians = 1
# Enable TCP SYN cookies
net.ipv4.tcp_syncookies = 1
# Restrict core dumps
fs.suid_dumpable = 0
# Protect shared memory
kernel.shmmax = 268435456
Apply the changes immediately:
sudo sysctl --system
Secure /tmp and /dev/shm
The /tmp and /dev/shm directories are world-writable and can be abused by attackers to execute malicious scripts. Mount them with noexec, nosuid, and nodev options.
# Edit fstab
sudo nano /etc/fstab
# Add these lines
tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev 0 0
tmpfs /dev/shm tmpfs defaults,noexec,nosuid,nodev 0 0
# Remount the filesystems
sudo mount -o remount /tmp
sudo mount -o remount /dev/shm
Step 7: Install and Configure AIDE for File Integrity Monitoring
AIDE (Advanced Intrusion Detection Environment) creates a database of file and directory attributes and alerts you when unauthorized changes occur. This is essential for detecting compromises.
# Install AIDE
sudo pacman -S aide
# Initialize the AIDE database
sudo aide --init
# Move the database to the proper location
sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
# Run a manual check
sudo aide --check
Schedule regular checks via a cron job or systemd timer:
# Create a systemd timer for daily AIDE checks
sudo nano /etc/systemd/system/aide-check.service
[Unit]
Description=AIDE File Integrity Check
After=local-fs.target
[Service]
Type=oneshot
ExecStart=/usr/bin/aide --check
StandardOutput=journal
sudo nano /etc/systemd/system/aide-check.timer
[Unit]
Description=Daily AIDE File Integrity Check
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
sudo systemctl enable --now aide-check.timer
Step 8: Enable Automatic Security Updates for Critical Packages
While full automatic updates on a rolling release can be risky, you can selectively update security-critical packages. Use a script that targets specific packages:
#!/bin/bash
# /usr/local/bin/security-update.sh
# List of security-critical packages to update automatically
PACKAGES="openssl openssh linux linux61 gnutls nss curl wget"
for pkg in $PACKAGES; do
sudo pacman -S --noconfirm --needed "$pkg"
done
echo "Security update completed at $(date)" >> /var/log/security-updates.log
# Make the script executable
sudo chmod +x /usr/local/bin/security-update.sh
# Add a weekly cron job
sudo crontab -e
Add the following line to run the script every Sunday at 3 AM:
0 3 * * 0 /usr/local/bin/security-update.sh
Step 9: Configure Audit Logging
The Linux Audit system provides detailed logging of security-relevant events, including file access, system calls, and user actions. This is invaluable for forensic analysis after a breach.
# Install audit
sudo pacman -S audit
# Enable and start the audit daemon
sudo systemctl enable auditd
sudo systemctl start auditd
# Add a rule to monitor changes to /etc/passwd
sudo auditctl -w /etc/passwd -p wa -k identity_changes
# Add a rule to monitor sudo usage
sudo auditctl -w /usr/bin/sudo -p x -k sudo_usage
# Make rules persistent
sudo nano /etc/audit/rules.d/audit.rules
# /etc/audit/rules.d/audit.rules
-w /etc/passwd -p wa -k identity_changes
-w /etc/group -p wa -k identity_changes
-w /etc/sudoers -p wa -k sudo_changes
-w /usr/bin/sudo -p x -k sudo_usage
-w /var/log/auth.log -p wa -k auth_log_changes
# Reload audit rules
sudo augenrules --load
Step 10: Limit Process and Resource Usage
Resource limits prevent a single compromised process from consuming all system resources, which is a common denial-of-service technique.
# Edit limits configuration
sudo nano /etc/security/limits.conf
Add the following limits:
# Limit core dumps
* hard core 0
* soft core 0
# Limit max processes per user
* hard nproc 512
* soft nproc 256
# Limit open files
* hard nofile 4096
* soft nofile 1024
Step 11: Secure the Bootloader
An unsecured bootloader allows anyone with physical access to bypass your security by booting into single-user mode or editing kernel parameters. Secure GRUB with a password.
# Generate a GRUB password hash
grub-mkpasswd-pbkdf2
# Edit the GRUB configuration
sudo nano /etc/grub.d/40_custom
Add the following, replacing the hash with your generated one:
set superusers="admin"
password_pbkdf2 admin grub.pbkdf2.sha512.10000.YOUR_HASH_HERE
# Regenerate the GRUB configuration
sudo update-grub
Step 12: Regular Backups and Disaster Recovery
No security strategy is complete without backups. Even the most hardened server can be compromised or suffer hardware failure. Implement a robust backup strategy using tools like rsync, BorgBackup, or restic.
# Install BorgBackup
sudo pacman -S borg
# Initialize a backup repository on a remote server
borg init --encryption=repokey ssh://backup@remote-server:22/path/to/repo
# Create a backup
borg create --stats --progress \
ssh://backup@remote-server:22/path/to/repo::'{hostname}-{now}' \
/etc /home /var/www /var/lib/mysql
# Prune old backups, keeping 7 daily, 4 weekly, and 6 monthly archives
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 \
ssh://backup@remote-server:22/path/to/repo
Best Practices Summary
- Principle of least privilege: Grant users and services only the permissions they absolutely need.
- Defense in depth: Layer multiple security controls so that if one fails, others remain effective.
- Regular audits: Periodically review your firewall rules, user accounts, and running services.
- Monitor logs: Set up centralized logging and alerting for suspicious activity using tools like rsyslog, Loki, or the ELK stack.
- Test your backups: A backup you have never restored is not a backup; it is a hope.
- Use SELinux or AppArmor: If available, enable mandatory access control for additional process isolation.
- Keep documentation: Maintain a record of all security configurations and changes for audit and recovery purposes.
- Subscribe to security advisories: Follow the Arch and Manjaro security mailing lists to stay informed about vulnerabilities.
Conclusion
Securing a Manjaro server is an ongoing process rather than a one-time task. By following this practical checklist, you have established a strong security foundation that covers system updates, access control, network filtering, intrusion detection, file integrity monitoring, and disaster recovery. Remember that security is a continuum: new vulnerabilities emerge daily, configurations drift over time, and attackers constantly evolve their techniques. Schedule regular reviews of your server's security posture, stay informed about emerging threats, and always test changes in a staging environment before applying them to production. With diligence and the layered approach outlined in this tutorial, your Manjaro server will be well-equipped to withstand the vast majority of common attacks while maintaining the flexibility and performance that made you choose Manjaro in the first place.