Linux·7 min read·

Fedora Server Initial Setup: SELinux-First Habits That Stick

A Fedora Server baseline from first boot with SELinux enforcing as the starting posture: users, sshd, firewalld, denials you can read, and upgrades you plan.

NB

Netbay Engineering

Netbay Engineering

On this page

Fedora Server is the RHEL family's proving ground, and it wears that status with purpose: it ships newer kernels, newer runtimes, and stricter defaults a full release ahead of the enterprise tree. The default posture is exactly what makes it interesting on a VPS, because several of those defaults are security decisions most distros leave to you. SELinux boots in enforcing mode, firewalld is live from first start, and a release is expected to be upgraded roughly every thirteen months. The habits that make a Fedora server manageable are the ones this post establishes: respect SELinux instead of disabling it, keep the firewall explicit, and treat the version upgrade as a scheduled event rather than an emergency.

Enforcing From the First Boot

Look at a fresh Fedora of version 42 or 43 and you will see what most distros leave for later: SELinux enforcing, firewalld active, and log rotation already in place. Enforcing is the important word. Most EL-family admins meet SELinux as an error; on Fedora it is the designed experience from the first boot, so the goal is to learn its small toolkit rather than fight it.

bash
getenforce
sestatus | head -6
semodule -l 2>/dev/null | wc -l

The First Twenty Minutes

Start the way you would any server: bring the base current, create an unprivileged admin user, and give it wheel membership so sudo works. Fedora ships the same OpenSSH defaults as RHEL, so root and password logins remain available until you say otherwise, and the config location is the same drop-in directory.

bash
sudo dnf upgrade --refresh
sudo dnf install -y tar vim
sudo useradd -G wheel deploy
sudo install -d -o deploy -g deploy -m 700 /home/deploy/.ssh
echo 'ssh-ed25519 <your-key>' | sudo tee /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

With key login proven in a second terminal, lock the daemon down:

bash
sudo tee /etc/ssh/sshd_config.d/50-hardening.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
EOF
sudo sshd -t && sudo systemctl restart sshd
Every access passes the SELinux gate CONFINED SERVICE nginx_t POLICY CHECK targeted policy ALLOWED the operation proceeds DENIED AVC record, ausearch reads it Enforcing is the default; denials land in the audit log, which is healthy

Firewall and Remote Access

firewalld is in charge from the first boot, with the public zone as the default and unmatched packets dropped. State the intended workload in service terms, make every change permanent, and reload.

bash
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Make new rules permanent by default. A runtime-only rule vanishes on the next reload, which is how admins discover the firewall quietly closed their own admin port at 3 a.m.

Read Denials Before You Disable

The reflex when a Fedora service fails with permission denied should be to check SELinux first, because most such failures are policy rather than filesystem. The four tools are consistent: ausearch reads the denial record, setsebool flips a sanctioned capability, semanage fcontext plus restorecon fix label mismatches, and audit2allow builds a minimal module for genuine custom cases. setenforce 0 is a diagnostic instrument, not a solution.

bash
sudo ausearch -m avc -ts recent
sudo setsebool -P httpd_can_network_connect on
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?"
sudo restorecon -Rv /srv/www

The Fedora Upgrade Is Part of the Job

Support runs about thirteen months per release, so the version hop is a routine, not an infrequent trauma. The mechanical path is a staged download followed by a reboot into the new system, and the planning around it is the real work: a snapshot, a test instance, and a maintenance window.

bash
sudo dnf upgrade --refresh
sudo dnf install -y dnf-plugin-system-upgrade
sudo dnf system-upgrade download --releasever=43
sudo dnf system-upgrade reboot

Snapshots make this nearly boring: if the new release misbehaves, the restore path is provider-side and quick. What should never happen is skipping releases, because Fedora upgrades are supported one hop at a time.

Takeaway

Fedora rewards the disciplined: keep it patched, upgrade it on the calendar, and let SELinux do its job by learning its four tools. Servers that follow those three habits get years of current software without ever tasting repair-by-reinstall.

Boot a Fedora Server VPS on Netbay in under 60 seconds and you begin inside an enforcing SELinux box on day one, which is the best possible place to form the habit — netbayhosts.in.

Keep reading

Follow along on a real VPS

Deploy Linux in under 60 seconds

These guides are written against Ubuntu, Debian, and RHEL-family images — the same ones on NetBay.

Deploy an instance