From 03d1e7cc6edfd7ab4e01ff66c84261ab0b2f85df Mon Sep 17 00:00:00 2001
From: Peter Boy <pb@resdigita.de>
Date: Apr 10 2021 10:03:43 +0000
Subject: Added content postinstall and cockpit, some minor updates


---

diff --git a/docs/modules/ROOT/nav.adoc b/docs/modules/ROOT/nav.adoc
index 1350e13..40f249b 100644
--- a/docs/modules/ROOT/nav.adoc
+++ b/docs/modules/ROOT/nav.adoc
@@ -1,6 +1,8 @@
 * xref:index.adoc[Welcome]
 * xref:server-installation.adoc[Server Installation]
 * xref:server-administration.adoc[Server Administration]
+** xref:sysadmin-postinstall.adoc[Post Installation Tasks]
+** xref:sysadmin-cockpit.adoc[Cockpit]
 * xref:server-virtualization.adoc[Virtualization]
 ** xref:virtualization-install.adoc[Add Virtualization Support]
 ** xref:virtualization-vminstall.adoc[VM Installation Using Cockpit]
diff --git a/docs/modules/ROOT/pages/server-administration.adoc b/docs/modules/ROOT/pages/server-administration.adoc
index 90ccb7a..66a966c 100644
--- a/docs/modules/ROOT/pages/server-administration.adoc
+++ b/docs/modules/ROOT/pages/server-administration.adoc
@@ -1,41 +1,52 @@
-= Fedora Server Administration Guides
+= Fedora Server Edition Basic Administration Guide
 Peter Boy; Jan Kuparinen
 :page-authors: {author}, {author_2}
 
-[sidebar]
-****
-Author: Peter Boy (pboy) | Creation Date: 2021-03-10 | Last update: 2021-03-26 | Related Fedora Version(s): 34
-****
 [NOTE]
 ====
-First Draft! Please comment on server mailing list
+Beta 1 – Please comment on server mailing list!
 ==== 
+[sidebar]
+****
+Author: Peter Boy (pboy) | Creation Date: 2021-03-10 | Last update: 2021-03-26 | Related Fedora Version(s): 33,34
+****
 	
 == What You Find Here
 
-Basic system administration is covered by Fedora's overall System Administration Guide (link). But there are several of Fedora Server specific topics which are not included. There are such basic items as storage organization to more advanced security considerations up to virtualization.
+Generic basic system administration is covered by Fedora's overall  https://docs.fedoraproject.org/[System Administration Guide]. But there are several of Fedora Server specific topics which are not included. There are such basic items as storage organization to more advanced security considerations up to virtualization.
 
 == Post Installation security enhancements
-- Installing fail2ban (short step-by-step installation guide the Fedora way)
-- Disabling ssh password based login for all users except some fallbacks (short guide how to do)
-- Protecting Cockpit password login
-- Don't deactivate SELinux but resolve issues (link to cockpit SELinux page and description how to resolve on CLI (or link))
-- Reduce the number of system users (If certain system users are required, move each (or all) to a lightweight  system container, e.g. systemd-nspawn, or even a (semi-lightweight) Cloud Image VM)
-- Would be nice to offer some configurable Ansible scripts for those repetitive tasks (downloadable from server-wg home page)
-- links to existing script at GitHub system roles and a guide how to use that script for this purpose
 
-== Specific System Administration Tasks
+As part of the installation, the system is already fitted with many security-relevant configurations. But some items need manual intervention. 
+
+First of all, the root account needs a key file to enable secure access via ssh. Right after installation, login as root is not possible due to the (public) key file requirement as configured during installation.
+
+For a number of other procedures, the system manager must weigh the pros and cons and make a decision. This involves, for example
+
+- Installing fail2ban to block IPs with too many unsuccessful logins
+- Disabling ssh password based login for all users except one (or very few) fallbacks
+- Protecting Cockpit password terminal login capability
+
+== Cockpit
+
+Fedora Server Edition is designed as a headless device, i.e. without a graphical user interface. Corresponding packages are not even installed. Accordingly, at most a simple text-based terminal is available on the box.
+
+Typically, however, administration is done remotely via a secure SSH connection.
+
+In addition, a lightweight web-based graphical user interface, Cockpit, is available by default and is intended to simplify many typical and repetitive maintenance tasks. For example, the creation, formatting and mounting of a logical file area can be done with a short input form consisting of 3-4 topics and one click. This saves even the experienced system administrator a lot of time and the (error-free) typing of several command lines. 
+
+
+
 
-=== Cockpit
-- recommended documentation for specific types of installation / use case
-- how to secure access / login page (integration into fail2ban, access via ssh tunnel, access via VPN)
+== Comming Up Next
 
-=== SELinux issues
-- How to fix
+- Manage storage
 
-=== How to manage storage
+- SELinux, don't deactivate but resolve issues (link to cockpit SELinux page and description how to resolve on CLI (or link))
 
+- Ansible, would be nice to offer some configurable Ansible scripts for those repetitive tasks (downloadable from server-wg home page)
+* links to existing script at GitHub system roles and a guide how to use that script for this purpose
 
 
 
-Further topics of this kind to be added
+More topics of this kind to be added
diff --git a/docs/modules/ROOT/pages/server-installation.adoc b/docs/modules/ROOT/pages/server-installation.adoc
index c65c47e..7d04c62 100644
--- a/docs/modules/ROOT/pages/server-installation.adoc
+++ b/docs/modules/ROOT/pages/server-installation.adoc
@@ -69,7 +69,7 @@ Note: Post F32 NetworkManager stores the configuration in __/etc/NetworkManager/
 
 == Creating users
 
-As a minimum, you must set a password for the ROOT account. Select "Root Password" below 'USER SETTINGS' and enter an appropriate password. For security reasons, ssh login as root is only allowed with key-file, but the account is not locked. It is not advisable to modify these security settings!
+As a minimum, you must set a password for the ROOT account. Select 'Root Password' below 'USER SETTINGS' and enter an appropriate password. For security reasons, ssh login as root is only allowed with key-file, but the account is not locked. It is not advisable to modify these security settings! This way, secure root access via ssh key file is still an option and, in an emergency, also with a password via an attached console or Cockpit login. 
 
 If there is no direkt terminal access available create a fall back user (e.g. hostmin) with password authentication active and administration privilege (group wheel & sudo su). In such a case, this is the only way to get access to the server after the reboot! And even later, it is the only way to get administrative access if for some reason the private key file is not available.
 
diff --git a/docs/modules/ROOT/pages/sysadmin-cockpit.adoc b/docs/modules/ROOT/pages/sysadmin-cockpit.adoc
new file mode 100644
index 0000000..cdab035
--- /dev/null
+++ b/docs/modules/ROOT/pages/sysadmin-cockpit.adoc
@@ -0,0 +1,14 @@
+= System Administration – Cockpit
+Peter Boy; Jan Kuparinen
+:page-authors: {author}, {author_2}
+
+[NOTE]
+====
+First Draft! Please comment on server mailing list
+==== 
+[sidebar]
+****
+Author: Peter Boy (pboy) | Creation Date: 2021-03-10 | Last update: 2021-03-26 | Related Fedora Version(s): 33,34
+****
+
+*comming soon*
\ No newline at end of file
diff --git a/docs/modules/ROOT/pages/sysadmin-postinstall.adoc b/docs/modules/ROOT/pages/sysadmin-postinstall.adoc
new file mode 100644
index 0000000..1f2df4c
--- /dev/null
+++ b/docs/modules/ROOT/pages/sysadmin-postinstall.adoc
@@ -0,0 +1,378 @@
+= System Administration – Post Installation Tasks
+Peter Boy; Jan Kuparinen
+:page-authors: {author}, {author_2}
+
+[NOTE]
+====
+Beta Version (1)! Please comment on server mailing list
+==== 
+[sidebar]
+****
+Author: Peter Boy (pboy) | Creation Date: 2021-04-20 | Last update: 2021-04-26 | Related Fedora Version(s): 33,34
+****
+
+These post-install tasks are all optional. The system administrator has to decide whether each individual task makes sense in the specific use case or not.
+
+== 1. Set up root login via key file
+
+According to the default installation, SSH login is only possible using an RSA key file. However, the setup cannot be done as part of the installation. If this step is omitted, logging in as root via SSH is not possible.
+
+=== Prepare a pair of private / public RSA keys
+
+This step is to be performed only if a pair of RSA keys does not already exist. It is best to create the key in the _.ssh_ directory of the desktop user. It should not be secured by password to enable automatic processing. The naming with leading 'id_' und trailing '_rsa' is just a common convention, yet helpful.
+
+a. Execute on the local desktop 
++
+[source]
+----
+[…]# mkdir ~/.ssh 
+[…]# cd ~/.ssh 
+[…]# ssh-keygen -t rsa -b 4096  -C "root@example.com" -f id_<outputkeyfile>_rsa
+----
+
+=== Transfer and Install the Public Key onto the Server
+
+a. Log in to your server via sftp using the unprivileged administration account and transfer the public key file
++
+[source,]
+----
+[…]# sftp hostmin@example.com
+sftp> put ~/.ssh/id_<outputkeyfile>_rsa.pub
+sftp> quit
+----
+
+b. Log in to your server via ssh using the unprivileged administration account again 
++
+[source,]
+----
+[…]$ ssh  hostmin@example.com
+----
+
+c. On the server acquire root permissions, move the key file and adjust permissions
++
+[source,]
+----
+[…]$ sudo su -
+[…]# mkdir /root/.ssh 
+[…]# cd  /root/.ssh
+[…]# mv /home/hostmin/id_<outputkeyfile>_rsa.pub /root/.ssh/authorized_keys
+[…]# chown  -R  root.root  /root/.ssh
+[…]# chmod 700 /root/.ssh
+[…]# chmod 600 ~/.ssh/*
+[…]# /sbin/restorecon  -R  -vF  /root/.ssh
+----
+
+=== Test and Simplify Access
+
+a. On your local workstation test key file based access:
++
+[source,]
+----
+[…]# ssh -i ~/.ssh/id_<outputkeyfile>_rsa  root@example.com
+----
++
+adjust file and domain name as appropriate.
+
+a. To simplify access create a configuration file on your desktop and define a short name for the connection:
++
+[source,]
+----
+[…]# vi ~/.ssh/config
+#  ###########################################################
+#  my rented remote server, root account
+#  ###########################################################
+Host myhost
+        Hostname myhost.example.com
+        User root
+        ProxyCommand none
+        ForwardAgent no
+        ForwardX11 no
+        Port 22
+        KeepAlive yes
+        IdentityFile ~/.ssh/id_<outputkeyfile>_rsa
+----
++
+again, replace names accordingly.
+
+a. Check if everything works:
++
+[source,]
+----
+[…]# ssh myhost
+----
+
+== 2. Update System and Install Additional Software
+
+Now that secure administrative access is in place, it's time to update the system and install some useful software. Of course, 'useful software' concretizes itself differently depending on the user and application context. Anyway, a good choice might be vim. With vimdiff e.g. a comparison of updates of configuration files (*.rpmnew) is very comfortable and straightforward.
+[source,]
+----
+[…]# dnf update
+[…]# dnf install vim
+----
+Add to the software list as needed.
+
+== 3. Double Check Hostname and Time Synchronisation
+
+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.
+
+a. Check for correct hostname
++
+[source,]
+----
+[…]# hostnamectl
+----
+* Set hostname if required:
++
+[source,]
+----
+[…]# hostnamectl  set-hostname  <YourFQDN>
+----
+
+b. Control of time zone, time synchronisation, time 
++
+[source,]
+----
+[…]# timedatectl
+----
+* Correct time zone if necessary:
++
+[source,]
+----
+[…]# timedatectl set-timezone  <ZONE>
+----
+* If necessary, activate time synchronisation:
++
+[source,]
+----
+timedatectl set-ntp true
+----
+* Correct time if necessary:
++
+[source,]
+----
+[…]# timedatectl set-time  <TIME>
+----
+
+
+== 4. Consolidation of Network Configuration
+
+Depending on installation efforts, network configuration consolidation may be required.
+
+a. Check IP addresses, interface and which protocol stack is used 
++
+[source,]
+----
+[…]# ip a
+1:  lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc n
+         ...
+2:  enp3s0: <BROADCAST,MULTICAST,UP,LOWER
+         ...
+         
+[…]# nmcli con
+NAME    UUID                                  TYPE      DEVICE 
+enp3s0  dabaa33b-25b0-3bfd-8a74-b6b40847a7a4  ethernet  enp3s0 
+
+[…]# who am i 
+root     pts/5        2021-04-09 21:07 (2003:ca:7f05:xx00:yyyy:zzzz:479a:b36e)
+
+[…]# nmcli -p -f ipv4.method,ipv6.method con show 'enp3s0'
+=====================================================================
+                    Connection details (enp3s0)
+=====================================================================
+ipv4.method:              manual
+---------------------------------------------------------------------
+ipv6.method:              manual
+---------------------------------------------------------------------
+----
++
+ Adjust interface names to your custom config
+
+b. Just in case IPv6 is configured as local only (fe80::....) or not static, you may set up a fixed IPv6
++
+[source,]
+----
+[…]# nmnmcli con mod 'enp3s0' ipv6.method manual \
+  ipv6.addresses <YOUR_IPv6_PREFIX>::2/64 \
+  ipv6.gateway fe80::1 \
+  ipv6.dns "2a01:4f8:xx:yy::zzz:8888 2a01:4f8:xx:yy::zzz:9999"
+[…]# nmnmcli con up 'enp3s0'
+[…]# nmnmcli con reload
+----
++
+Again, don't forget to adjust names, prefix, and DNS IP addresses. Pay special attention to the gateway. Using a local address of 1 (fe80::1) is a widely used convention.Another is the IPV6 prefix with the address 1. But each provider may have an even different approach.
++
+Check connectivity from your local workstation. If that fails, the gateway configuration is the first suspected culprit.
++
+[source,]
+----
+[…]# ping6 <YOUR_IPv6_PREFIX>::2 
+[…]# # e.g. ping6  2a01:xxx:yyy:zzz::2
+----
+
+c. Optionally reconfigure IPv4 as static. But make sure the IPv6 address works and don't change both protocol stacks at the same time (and in the worst case drop connectivity at all):
++
+[source,]
+----
+[…]# nmnmcli con mod 'enp3s0' ipv4.method manual \
+  ipv4.addresses <YOUR_IPv4>/27 \
+  ipv4.gateway <GATEWAY> \
+  ipv6.dns "<DNS1_IPv4> <DNS2_IPv4>"
+[…]# nmnmcli con up'enp3s0'
+[…]# nmnmcli con reload
+----
++
+Again, don't forget to adjust names, prefix, and DNS IP addresses and check connectivity from your local workstation:
++
+[source,]
+----
+[…]# ping <YOUR_IPv4> 
+----
+
+d. Optionally you may have a look at the NetworkManager configuration file
++
+[source,]
+----
+[…]# less /etc/NetworkManager/system-connections/enp3s0.nmconnection
+----
+
+Finally reboot now to check everything from ground up
+
+== 4. Disable System Users Password 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. 
+
+a. Create a sshd configuration file and edit as follows:
++
+[source,]
+----
+[…]# vi /etc/ssh/sshd_config.d/60-local.conf
+# Local custimization: disable password login except for
+# one (optionally add some more) user as a fallback option. 
+PasswordAuthentication no
+
+Match User hostmin
+ PasswordAuthentication yes
+#Match User hostmin2
+#       PasswordAuthentication yes
+----
+
+b. Reload the sshd daemon
++
+[source,]
+----
+[…]# systemctl  reload sshd
+----
+
+c. Test that everything works as expected
+* Is an authorised user able to log in?
+* Is anyone else is rejected with the message "Permission denied (publickey,gssapi-keyex,gssapi-with-mic)"?
+* If this does not work: Check whether the latest update has been installed. The file /etc/ssh/sshd_config.d/50-redhat.conf there should not include a line „PasswordAuthentication yes“ (as this is already the default and should not be repeated in order not to hinder other configurations).
+
+
+== 5. Install fail2ban
+
+The software monitors the log files for authentication errors.  In case of multiple retries from the same IP address, the source IP gets blocked by the firewall. This is to prevent brute force methods for cracking passwords and bots checking for weak passwords. However, if an error occurs in the authentication process, a system administrator may also lock himself out.
+
+a. Installation of the software and the required Postfix
++
+[source,]
+----
+[…]# dnf install fail2ban postfix
+----
+a. Create and fill configuration file
++
+[source,]
+----
+[…]# vi /etc/fail2ban/jail.local
+# Jail configuration additions for local installation
+
+# Adjust the default configuration's default values
+[DEFAULT]
+# Optional enter an trusted IP never to ban
+#ignoreip = www.xxx.yyy.zzz/32
+bantime  = 6600
+backend = auto
+
+# The main configuration file defines all services but
+# deactivates them by default. We have to activate those neeeded
+[sshd]
+enabled = true
+----
+a. Activate software
++
+[source,]
+----
+[…]# systemctl  enable  postfix  --now  
+[…]# systemctl  enable  fail2ban  --now
+----
+a. Control in the log
++
+[source,]
+----
+[…]# tail -f /var/log/fail2ban.log
+----
+
+== 6. Install and Configure Logwatch
+
+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.
+
+a. Install software
++
+[source,]
+----
+[…]# dnf install  logwatch
+----
+
+b. The only configuration required is to enter a real email address for root, the recipient of the report. It is added at the end of the file.
++
+[source,]
+----
+[…]# vi /etc/aliases 
+...
+# Person who should get root's mail
+#root:          marc
+root:		   real@address.for.root
+
+[…]# newaliases
+----
+
+== 7. Securing Cockpit Access
+
+Cockpit enables a password-supported root login in its web interface as well as a corresponding terminal access, 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 is allowed only via an ssh tunnel or accessibility in the firewall is activated on demand only. 
+
+a. Reconfigure firewall permanently
++
+[source,]
+----
+[…]# firewall-cmd --permanent --remove-service=cockpit 
+[…]# firewall-cmd --reload
+----
+
+b. To access Cockpit via ssh tunnel
+* Login to the server via ssh and setup a tunnel
++
+[source,]
+----
+ssh host.example.com -L 9090:host.example.com:9090
+----
+* On the desktop keep logged in and open your browser using the address _localhost:9090_
+
+c. To add Cockpit service temporarily on demand 
+* Login to the server and reconfigure firewall
++
+[source,]
+----
+firewall-cmd –add-service=cockpit
+----
+* When finished remove cockpit again
++
+[source,]
+----
+firewall-cmd –remove-service=cockpit
+----

