Post Installation Tasks

In a default installation, the root account is locked and administrative work is delegated to a user account that is entitled to root privileges (sudo). It is convenient to make the login process as comfortabe as possible.

A key file for SSH saves the annoying and error-prone typing of the hopefully secure and sufficiently long password. Additionally, you may prepare your local desktop to use a short name instead of having to type in a complete FQN hostname.

Open Cockpit in your desktops browser https://host.example.com:9090. Accept the security warning of your browser. Cockpit uses a self signed certificate.

If you disabled root access during installation (recommended), login as root is not possible.

Login with your administrative user account. At the top you will see a warning that the Web Console is running with limited permissions. Enable administrator access so that all administrative privileges are automatically available after login.

System users are a systematic weak point in defending a server against compromise attacks. This is certainly unintentional on the part of the users. It is due to lack of understanding, insecure passwords, falling for phishing attacks, and alike. On the other hand, it is precisely the users that a server is operated for.

Therefore, it is best practice to minimize the number of system users and instead use virtual accounts or offload applications that require system users to virtual machines or containers. In case of an intrusion, this is a kind of second line of defense, trying to keep the server itself from being infected even then.

In addition, it is a small effort to generally prevent password-based login and to enforce key files. An exception can be defined for individual, selected users. If a server is located in a data center and can only be remotely accessed without much additional effort, it may make sense to set up a "fallback user" if key-based authentication is no longer available for some reason.

As a side effect it saves a lot of warning messages in the log file and makes it easier to check them.

Cockpit relies on a password based login to its web interface, even for root (unless the root account is completely locked, locking the account as part of ssh does not help here). And thus it is a potential target for brute-force attacks. In most cases, it is rarely used in daily operations and it may be a good practice to remove the general accessibility in the firewall. Instead, access Cockpit in one of the three secure alternatives described below.

There are several ways to improve the security of Cockpit access. All of them are based on permanently withdrawing access to Cockpit in the firewall. So, reconfigure the firewall permanently.

Use one of the following alternatives to access Cockpit.

Even if you activated root access during installation, you have hopefully kept the default option to restrict root to key file authentification. So you have to set up a key file prior to any ssh login. But be aware! You can still log in to Cockpit’s web interface. Therefore, in this case, be sure to implement the additional security measures described in the previous chapter!

Both are important for trouble-free server operation. Just in case you missed its configuration during installation or it is incorrect, now is the opportunity to fix it.

Depending on installation efforts, network configuration consolidation may be required.

It sounds trivial, but before any change of the network configuration make sure that the entries in the DNS are correct. If you change from DHCP to fixed addresses, you may need to adjust the DNS and vice versa!

Finally reboot now to check everything from ground up

With Fedora 39 the default LVM configuration has changed. The various LVM management commands now only process registered, 'legitimate' block devices connected to the system. It is essential to check the correctness of the devices file list.

Depending on how you decided on data storage during installation, different supplementary configuration may be required.

If a general disabling of the password login is not an option, the installation of fail2ban is worth considering.

The software monitors the log files for authentication errors. In case of multiple retries from the same IP address, it reconfigures the firewall on the fly to block the source IP This is to prevent brute force methods for cracking passwords and bots checking for weak passwords. However, a system administrator may also lock himself out, if if they happen to make a mistake. Therefore, you can exclude destinct IP addresses, e.g. the administrators desktop, from blocking.

The software checks log files for anomalies and compiles a daily report that can optionally be sent to system administrators via email. It is something like a minimal defensive effort. More powerful, but much more involved would be the installation of a monitor software.

It is common sense among system administrators,that regular installation of bug fixes and closing of security vulnerabilities is essential, i.e. applying updates in a systremtatic way. An important step is to automate the process as much as it is reasonable.

Fedora includes a tool, dnf-automatic, which supports several modes of update automation: do not apply, notify admin, apply and notify admin, apply without notification. In particular, alternatives 2 and 3 are definitely worth considering. A general principle might be: Alternative 2 is the minimum choice for almost any system, alternative 3 is not at all suitable for critical systems that must not fail under any circumstances.

We recommend to install at least alternative 2:

If you want to automatically install, activate the corresponding timer instead.

Now that secure administrative access is in place, it’s time to update the system and install some useful software. Of course, 'useful software' varies depending on the use case or applications that will be run on Fedora Server. Anyway, a good choice might be vim. With vimdiff e.g. a comparison of updates of configuration files (*.rpmnew) is very comfortable and straightforward.

Add to the software list as needed.

Finally reboot the server.