System hardening on installation

Ask Fedora
, ,
1

Hi folks, I hope you’re having a restful weekend.

I was toying with OpenSUSE Leap and FreeBSD to get hands on with installation experience of other OSes. Both gives options to configure system hardening options on installer. FreeBSD gives two options with the standard installer (looking retro and hip);

  • Select hardening options from 12 most recommended settings. See image below.
  • (additionally) before moving to installation, you have a choice to enter shell to customize more

When installing Fedora workstation and Spins with Anaconda installer, what advanced options are there to configure settings in shell? If you can suggest commands or scripts to harden systems during installation and post-installation, I would appreciate it.

I must confess I don’t even know how to get into shell prompt when installing with Anaconda.

Figure. Selecting Hardening Security Options in FreeBSD

bsdinstall-hardening
bsdinstall-hardening864×480 40.1 KB

1 Like
2

Many of those options are already in place by default with fedora, and some are obscure as to purpose. There are differences between environments so I will address some of the items from the Workstation edition.

On fedora /tmp is a virtual file system so it is always emptied with a boot/restart (#6) (this seems to be true on all editions)
swap is in a virtual swap space using zram to there is never a physical copy of swap unless one uses hibernate which requires user configuration.
The root user is locked by default so the admin user uses sudo to perform admin tasks. Even logging in at the virtual console (ctrl-alt-F2) requires a username/password (#9)
Sendmail is never enabled by default (#8)
‘ddtrace’ is not installed nor available and I see no option with dtrace to make it destructive (#10) (I do not use dtrace so am not familiar with all its potential)

As far as the others I cannot speak to how that would be done. Remember that FreeBSD and linux are different.

For the average user fedora is more than adequately secure. The shell prompt is not needed to perform an install, and many never use the terminal access.

Remember one thing that applies almost universally across all linux, BSD, OpenSUSE, (and others) systems. If the machine is physically accessible to an attacker they can own the system no matter how well the OS may be hardened. Drive encryption makes this much harder.

Also most home systems have at least 2 levels of protection that must be broken before the system can be compromised from the outside – The ISP (including the local router with its firewall) and the firewall on the machine itself (which is enabled and very secure by default)

It seems most successful attacks are the result of social engineering or incompetence on the part of the user where the user actually opens up the access (web browser links, downloading malicious software, and the like).

3

I know Fedora Linux is well known for ‘secure by default’. However, some people with curious mind and informed users may want to understand what’s behind the façade (graphical installer) and know what advanced mode there is in OS and application level. Network stack and physical security are a different matter.

FreeBSD and OpenSUSE give options to customize during and after installation explicitly in graphical installer, so anyone who wants to touch ‘advanced mode’ has options to configure, or you can ignore them by clicking ‘no’.

4

Generally speaking Fedora Worstation is reasonably hardened by default with one glaring exception. Workstation beigns life with almost/all ports open on its firewall. Once you fine tune this to your needs with Firewalld this no longer is a problem. It helps maintaining an open profile on Firewalld for service discovery but outside of that lock it down.

5

Not true. A clean install of fedora has (almost) no ports open.

This from a clean install of F38 shows ssh is open because I explicitly opened it and started sshd on the system. Otherwise fedora is totally closed in the first 1024 ports (system services). No system services open a port above 1024 though user apps may do so. Systemd does open llmnr but otherwise nothing.

$ nmap -p1-65535 192.168.124.40
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-15 12:35 CDT
Nmap scan report for 192.168.124.40
Host is up (0.000095s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT     STATE SERVICE
22/tcp   open  ssh
5355/tcp open  llmnr

Nmap done: 1 IP address (1 host up) scanned in 15.12 seconds

Try that yourself to confirm rather than stating something that is not valid.

2 Likes
6

Yet ports 1025+ are open. On the server edition everything is closed. There are plenty of commonly used services outside of the system services range.

Don’t appreciate the tone of that comment, especially when you yourself are presenting something that is not valid or at least incomplete.

7

Having a better router makes your home secure enough that will fulfill your threat level mostly routers are not very secure by design they run ancient kernel and not upto date packages so i recommend you can increase with openwrt router or maybe pfsence or opnsence firewall routers.

1 Like
8

Those are the mentioned apps, but not standard system services for workstation, and you explicitly said workstation.
True that firewalld does not block ports above 1024 by default, but normal services do not have ports open there either so it has the same effect.

In terms of security, if one is using an app with a port above 1024 then it is up to the app to be designed in a secure manner. Firewalld would not assist if the port were allowed by firewalld but the app allowed an attacker to penetrate.

Firewalld has no benefit where the port is not commonly opened so there is no connection to be exploited. One can attack a blank wall forever and never penetrate. Firewalld closing those many unused ports in that range simply applies more processing load on firewalld when an attempt is made.

9

If the port is not filtered by the firewall, but no application is listening on that port, then the port is closed. I would be worried if Fedora had 1025+ open ports by default.

As far as I remember Fedora’s firewall by default is very restrictive, had to punch a hole for KDE Connect and SMB.

I double checked, the Fedora Server profile is the restrictive one. The workstation one doesn’t filter ports 1025+. I still had to explicitly allow SMB server ports, but KDE Connect wasn’t necessary probably.

10

Remember that FreeBSD and linux are different.

Correct. For example, SELinux isn’t on FreeBSD. It is safe to deduce secure by default comes from SELinux that hardens the OS layer in its default enforcing mode. Configuring SELinux is not an average user to be concerned about, so I just need to get acquainted with Quick Docs guide and Red Hat resources on SELinux and policy.

The shell prompt is not needed to perform an install, and many never use the terminal access.

In exceptional cases (like troubleshooting with sys admin during installation), tmux could be a solution to access an interactive shell during the installation.

To switch from the graphical installation environment to tmux, press Ctrl+Alt+F1. To go back to the main installation interface which runs in virtual console 6, press Ctrl+Alt+F6.

Thanks for sharing valuable input to my question, which is about system hardening option in installer (Anaconda). I feel we enthusiastically :tada: :tada:digressed toward security in a broader sense.

11

It might be a good idea to disable llmnr unless you use it in a network work a majority of WIndows systems. For hot spots it might even be a security risk as llmnr could anounce your computer to the rest of the local network.

2 Likes
12

I am not going to argue why assuming that since it was shipped without anything requiring ports above 1024 that a default of just closing those ports and not the rest is completely reasonable, but this fits almost no ones definition of hardened.

Generally speaking sure…until you run into a zero day because some developer broke something, or someone found something buried in legacy code. It ain’t accepting anything if the port is closed.

Yeah, we are just going to have to disagree. I work in a lot of very locked down environments and this comment would probably make my boss send me to get my head examined. The deafult configuration on Fedora Workstation is only really acceptable in a trusted environment. Once again not really what people are talking about when they ask about hardened systems.

I am not saying the Workstation is insecure, it has simpy the best SELinux implementation around and that goes a long way to providing a hardened system. My point was that the user has to take a very close look at their local firewall rules because relying on your network is a no go. I use Fedora Workstation everyday on multiple systems and anything portable gets a very serious look at what networks it is connecting to and what ports are being opened on those networks. I would do the same with any system, but closed ports by default are simply more secure.

1 Like
13

What a fallacy. If I run some service that opens a port (regardless of where that may be) then the port must also be open on the firewall – ergo it is up to the app to provide security for that already open port. Firewalld has no chance of benefiting the user in that situation.

I agree 100%, and I neglected to mention that in my first response here.

14

This is only the case if you are adding the service to firewalld. If the app is configured to use a specific port and the firewall has closed it, it is closed or more technically filtered, the firewall is blocking the incoming traffic. Nothing the app can do about it. I think we are talking about two different things. If you are not managing your ports via services options in firewalld this is not going to be the case. You very well can block a port, and an app trying to use it wont connect, because it cant. If you add the service to the firewall then the port is open and the app is listening…unless you configure the app to listen on a non-standard port. If it is listening on a port not defined by the service and that port is closed in the firewall it is simply not going to receive a damn thing Services in relation to firewalld are a convenient way of making it easier to manage the firewall, but they are by definition opening the port. Just because I enable a service in systemd that service does not get added to the firewall unless I explicitly add it and if I dont it can run merrily away without ever receviing a single packet.

15

To sum up my findings on the subject line,

  1. System hardening ‘on installation’ using Anaconda installer
  • Fedora Workstation: Anaconda graphical installer in Workstation edition does not give options to configure system hardening ‘on installation’
  • Red Hat Enterprise Linux: Security Policy is enabled by default since Red Hat Enterprise Linux 7.2.

When enabled, the packages necessary to provide this functionality will automatically be installed. However, by default, no policies are enforced, meaning that no checks are performed during or after installation unless specifically configured.

  1. How to get into text mode installation while using Anaconda: Press Ctrl + Alt + F1

I managed to enter tty from Anaconda. tty + tmux could be useful for those who aspire to be SysAdmin and are curious about advanced mode to interact with real sysadmins for getting technical help.

  1. Security is not achieved by ticking boxes in installer. We need to consider various security practices and review of SELinux, Firewalld policy in detail and, in addition, network security layers. Thanks to your valuable input, I’m better informed now on this respect.

  2. Different OSes have different UX design and on-screen text for graphical installer. By poking around different OSes (OpenSUSE Leap, FreeBSD, Arch), I’m more inclined to advocate Anaconda installer in Fedora family distributions. I’m looking forward to the next version of Anaconda.

16

In which case the app is useless since connections are blocked. Thus one shoots themselves in the foot.

17

I have not much time at the moment so I just “throw” some often-underestimated points at you sine I have some relations to these topics; forgive me if I repeat something that was already mentioned, I didn’t read the whole topic :wink: (and forgive me that some of the below is copy-pasted from another text of mine :smiley: )

You can make Fedora a fortress by using confined user accounts of SELinux [1]. This can add security to your environment that can compete with containerization, and it can also protect applications from each other within user realms. I found out it even limits copy-paste to user-triggered events (e.g., copy-pasting with middle mouse) while applications get hindered to access the origin of the content or the content while transferred. This can be highly relevant for password managers, where it is often forgotten that in GUIs, a lot applications can have related access (e.g., when copy-pasting without caching such as middle mouse + confined users make it more or less impossible that a third application/tool can access the password).

However, currently, confined user accounts break some things. I work with it on KDE since January. But it has some issues (a timeout makes the login idle for 30 seconds, video conferencing is currently blocked). GNOME seems to be more stable but I saw that file roller has issues with it. Yet, an account can be easily confined and unconfined. Optimizing the SELinux classifications of files and users shall not be super relevant here, since the confinement itself makes the most major difference and should remain compatible with and without confinement.

I have started to collaborate with the SIG/WG and the selinux related team, but there had been no time yet to get that fixed in order to get fully supported. I hope in the short-/mid term, we get Fedora as “confinable” as CentOS or RHEL.

Additionally, be aware that the packages that are shipped with Workstation WG and KDE SIG are “cross-checked” since these WG/SIG carefully select what they ship (and they keep doing so). This means if you keep preferring using such packages over others, you can rely on these packages getting critical updates immediately. Unfortunately, as in most operating systems, packaging can end up in “single points of failures” (the maintainer). This is already security relevant. Personally, I carefully select packages I install and check who keeps checking and working with them, and if they remain updated on time (you can do that in bodhi and koji).

(To avoid confusions: flatpak will not solve the above mentioned issues but maybe even increases them since most flatpaks disable all containerization possibilities anyway while they add much heterogeneous software/builds from various unknown environments).

Generally, if you want to keep secure: do not add patches or so yourself, and rely on what is build+tested in the Fedora community. Keep your kernel tainted = 0 :slight_smile: A major security and stability advantage of Fedora is that it keeps the vanilla kernel, which means that it keeps all security and stability guarantees of the official Linux kernel. Any change in the kernel breaks that. Unfortunately, this also includes third party drivers.

Concerning disk encryption, yeah it makes a difference as Jeff already noted. Use Anaconda If you have an AES-NI on your machine → check with lscpi | grep aes (no output means you have none; if the “Flags” are output you have it; today mostly phones, tablets, raspberry and such have none but “normal” computers have already for long). If you have none, you might pre-create adiantum disks instead of using the Anaconda encryption default to achieve an acceptable performance and battery life time. A compromise before adiantum gets introduced in Anaconda (this change relies on storaged) is on its way (AES128 instead of AES256 makes a difference on non-AES-NI machines), but might need some releases before introduction as well :wink:

Also, keep using a secure browser (which also means “secure on Fedora” not just “at all”), a major issue on average machines: Firefox remains the best supported, cross-checked and immediately updated on Fedora (also with regards to my above comments about keeping in our own homogeneous repos and focus on cross-checked packages).

I leave out the firewalling (which seems to have been discussed already anyway), since firewalld shall be configured in a well compromise of security and usability in Workstation and KDE Spin.

Lastly, as indicated in the last paragraph, it might be noted that GNOME- and KDE-based systems are best supported (practically, you can consider KDE as WG, except that it does not contain release blockers), while others tend to lack cross-checks and maintenance (including of packages) because they are often just projects of a few people. So if you focus on security, I suggest to stick with GNOME or KDE Fedoras.

Although it might feel like giving you more power, I suggest to avoid the netinstaller because it does not incorporate the careful/thoughtful considerations and pre-configurations of the WG/SIG but is widely “blank”.

[1] Some illustrative pages about SELinux confined user accounts:
Chapter 3. Managing confined and unconfined users Red Hat Enterprise Linux 8 | Red Hat Customer Portal
Confining the User with SELinux: danwalsh — LiveJournal
Difference between a Confined User (staff_u) and a Confined Administrator.: danwalsh — LiveJournal
#358 KDE Spin/components not properly aligned with SELinux (this can be verified with SELinux confined user accounts)

( If someone is playing with confined user accounts and has questions, feel free to open a topic here and trigger me with @py0xc3 ) → I am already seeking potential collaborators for testing when this gets to the next stage :wink: )

After all, don’t forget to consider physical access (Jeff already indicated that), add BIOS passwords, and also don’t forget that video capturing of keyboards and screens is possible as well (underestimated at public places). I guess I forgot a lot, but maybe this adds some incentives to the considerations :wink: If there are questions about my points or so, feel free to trigger me with @py0xc3 as I will maybe not get your post otherwise :smiley:

Btw, Anaconda will hopefully give you more possibilities to adjust/customize things within the graphical installer (also with regards to security things) in future once the WebUI is introduced (although this will still take some time)

18

I’m so grateful to you sharing professional advice. I learned a ton - confined user accounts.

I gather many of these security hardening can be done after installation. Great if I can understand better how I can do it during installation using Kickstart/Ansible to automate most of steps.

Anaconda will hopefully give you more possibilities to adjust/customize things within the graphical installer (also with regards to security things) in future once the WebUI is introduced (although this will still take some time)

Could you point me to the Git repo that manages all the development/milestone for the new Anaconda installer? Thanks.

19

Be aware that there is not “the one repo” where everything with regards to Anaconda is consolidated. Anaconda is just the front-end. E.g., everything with regards to disk encryption “in the back” is related to blivet (repo here). Martin (he is the owner) just made me aware that even the default settings of the disk encryption are discussed and determined upstream, in collaboration with downstream (following the Fedora philosophy obviously).

As far as I know, many decisions (such as what to use where and for what; e.g., blivet for storage stuff) are not yet fixed when it comes to the new Anaconda Web-UI (but I am not sure if my information in this respect is up to date).

I think most interesting for you are the previews of the future Web UI. Be aware that much is not yet implemented. This means, at the moment, you cannot do much but only see and follow how it develops. The previews can be found here: Index of /groups/anaconda/webui_preview_image/x86_64 (the live image is something new ; ) Be aware that any Fedora installed with these installers should not be used in production environments - these installations should be considered broken (its just a preview of the installers ; )

That said, the official repo of Anaconda is: GitHub - rhinstaller/anaconda: System installer for Fedora, RHEL and other distributions :smiley:

You can also check out cockpit: you can install cockpit, and additional packages such as for virtual machines (cockpit-machines.noarch) and such, with dnf and check out in your browser (this technology is finally the foundation of the new Web UI). Cockpit is already in production and might better indicate how flexible / easy-to-adjust this technology and its modularity is, because more usable software and documentation is available for it (but I have to make clear that I do not consider myself an expert in web technologies). It might also give a better understanding of the front-end interaction with various backend possibilities (I found it super impressive how quickly some of the front-end modules such as cockpit-machines have been developed and released, sometimes shortly after the demand became known).

Related:
Anaconda - Fedora Project Wiki (you can find them also in Matrix, they are neighbours of Docs :wink: )

For more, please open a new topic :wink: (I think I have already overstretched this one ^^).

20

This is the whole point. The configuration of the firewall should be the deciding factor, not how a particular app is configured. Not to mention using the services feature actually makes configuration management a lot harder, particulalry when you are using non standard ports. There are tons of reasons you might want the app locked down, or have all unused ports closed. This all depends on your threat model. Sure in a low threat environment it could easily be seen as shooting yourself in the foot unless you have other controls and workflows that take precedence over doing things the way you propose doing them.

1 Like