ProLUG SEC Unit 5 🔒

Original URL: https://trevorsmale.github.io/techblog/post/psc5/

Intro 👋

Repositories and Patching is the general theme of this unit. We dive into creating internally audited repositories for safe enterprise operation. This configuration allows for greater security scrutiny and compatibility testing before schedule patching takes place. For example, a company would like to skip every other version of a package in order to reduce update cadence, giving more time for assessment, correction and troubleshooting of internal software. Much like any enterprise decision regarding cost and effort and analysis must take place. ¹

Worksheet

`Discussion Post 1`

Review the rocky documentation on Software management in Linux.²

Question

What do you already understand about the process?

Answer

I had gained a decent understanding of the package management systems of both RHEL and DEBIAN based distros through both studying for the LPIC 1 and completing the ELAC course through this group. From this I had learned about versioning and dependency management including modules. The differences between RPM, YUM, and DNF and how these evolutions of package management came into being.

Question

What new things did you learn or pick up?

Answer

- I did not understand the depth to which RPM packages tracked package data.
I did not know that headers could be edited in the package in order to add custom labeling.
I had basic awareness and high level understanding of internal package management. Prior to our lecture, I had not seen an internal package server/relay be setup/configured.
I did not know much about EPEL beyond having to call it in the CLI for additional packages outside of DNF.

Question

What are the DNF plugins? What is the use of the versionlock plugin?

Answer

DNF plugins are external modules that extend the functionality of DNF. I have some experience activating the COPR repo using DNF plugins. Furthermore, versionlock is a specific plugin that allows for an admin/engineer/dev to lock a particular package to a specified version so that it is not mistakenly changed/overwritten. This is typically done in software development in my experience, with software development many dependencies might be needed. Breaking updates were common place, so most modern software projects contain a lock file that indicates what specific dependency version must be used in order to build or interpret the project.

Question

What is an EPEL? Why do you need to consider this when using one?

Answer

EPEL stands for Extra Packages for Enterprise Linux. These packages exist outside of the core enterprise offering and are therefore potentially issue causing. Unlike core packages, these extra packages could introduce possible incompatibility issues, resulting in rejection by endorsed support specialists.

`Discussion Post 2`

Do a google search for “patching enterprise Linux”³

Question

What blogs (or AI) do you find that enumerates a list of steps or checklists to consider?

Answer

I used to sources that I had found to be concise
- RedHat Documentation⁴
- Chat*ippity

Question

After looking at that, how does patching a fleet of systems in the enterprise differ from pushing “update now” on your local desktop?

Answer

Patching a fleet of systems involves the systematic updating of installed software to fix security vulnerabilities, improve stability, and introduce minor enhancements. The process is governed by organizational policies to ensure uptime and compliance.

Because changes affect many systems simultaneously, patching acts as an amplifier of problems if not handled carefully. Therefore, enterprise patching must be strategic, managed, and auditable.

In contrast, running updates on a personal system is typically an automated, low-risk operation, with little concern for version conflicts or trust in the source. Additionally, modern filesystems like ZFS and Btrfs provide the ability to quickly roll back changes if something fails.

Question

What seems to be the major considerations? What seems to be the major roadblocks?

Answer

Major Considerations
- Uptime and Service Continuity
- Security and Compliance
- Testing and Validation
- Dependency Management
- Rollback and Recovery Planning
- Orchestration and Scalability
Major Roadblocks
- Legacy Systems
- Change Resistance
- Incomplete Asset Inventory
- Tight Maintenance Windows
- Patch Quality and vendor Bugs
- Complex Dependencies and Integration Points
- Resource Constraints

Definitions

Patching The process of applying updates to fix bugs, improve security, or enhance performance.
Repos (Repositories) Remote or local collections of software packages used by package managers.
Software Applications or tools installed on a system to perform specific functions.
EPEL (Extra Packages for Enterprise Linux) A Fedora project providing additional packages for RHEL-based systems.
BaseOS The core operating system components in RHEL/Rocky, including the kernel and essential services.
AppStream A modular repository in RHEL/Rocky that provides applications and tools in versioned streams.
httpd The Apache HTTP Server package available via repos for web serving.
patching A type of update package that modifies existing software without replacing the whole binary.
GPG Key Used to verify the integrity and authenticity of packages in a repo.
DNF/YUM Package managers in RHEL-based systems used to install, update, and manage software packages.

Lab 🧪

Apache STIGs Review

Look at the 4 STIGs for “tls”

What file is fixed for all of them to be remediated?

# Install httpd on your Rocky server
systemctl stop wwclient
dnf install -y httpd
systemctl start httpd

Check STIG V-214234

Question

What is the problem?

Answer

Event logging can fail.

Question

What is the fix?

Answer

This can be fixed by implementing failure alerts.

Question

What type of control is being implemented?

Answer

This type of control would be a Detective Control

Question

Is it set properly on your system?

Answer

No, this is not setup by default, it must be implemented after installation.

Check STIG V-214248

Question

What is the problem?

Answer

By default, sensitive information including security controls may be available to all users because privelaged user access controls have not been implemented.

Question

What is the fix?

Answer

Develop roles for privelaged users and define access policies.

Question

What type of control is being implemented?

Answer

This is a preventative type control.

Question

Is it set properly on your system?

Answer

No, not by default. Of course super user has special priveledges. However, beyond that there are no other tiers of access.

Question

How do you think SELINUX will help implement this control in an enforcing state? Or will it not affect it?

Answer

SELINUX allows for strong group creation and control. So it would help batch users and apply granular control mechanisms.

Building repos

# Start out by removing all your active repos
cd /etc/yum.repos.d
mkdir old_archive
mv *.repo old_archive
dnf repolist

# Mount the local repository and make a local repo
mount -o loop /lab_work/repos_and_patching/Rocky-9.5-x86_64-dvd.iso /mnt
df -h #should see the mount point
ls -l /mnt
touch /etc/yum.repos.d/rocky9.repo
vi /etc/yum.repos.d/rocky9.repo

[BaseOS]
name=BaseOS Packages Rocky Linux 9
metadata_expire=-1
gpgcheck=1
enabled=1
baseurl=file:///mnt/BaseOS/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
[AppStream]
name=AppStream Packages Rocky Linux 9
metadata_expire=-1
gpgcheck=1
enabled=1
baseurl=file:///mnt/AppStream/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
#Save with esc :wq or “shift + ZZ”

Question

Do the paths you’re using here make sense to you based off what you saw with the ls -l? Why or why not?

Answer

TODO

chmod 644 /etc/yum.repos.d/rocky9.repo
dnf clean all
# Test the local repository
dnf repolist
dnf --disablerepo="*" --enablerepo="AppStream" list available
Approximately how many are available?
dnf --disablerepo="*" --enablerepo="AppStream" list available | nl
dnf --disablerepo="*" --enablerepo="AppStream" list available | nl | head
dnf --disablerepo="*" --enablerepo="BaseOS" list available
Approximately how many are available?
dnf --disablerepo="*" --enablerepo="BaseOS" list available | nl
dnf --disablerepo="*" --enablerepo="BaseOS" list available | nl | head
# Try to install something
dnf --disablerepo="*" --enablerepo="BaseOS AppStream" install gimp
hit “n”

Question

How many packages does it want to install?

Answer

TODO

Question

How can you tell they’re from different repos?

Answer

TODO

# Share out the local repository for your internal systems (tested on just this one system)
rpm -qa | grep -i httpd
systemctl status httpd
ss -ntulp | grep 80
lsof -i :80
cd /etc/httpd/conf.d
vi repos.conf


Options Indexes FollowSymLinks
AllowOverride None
Require all granted

Alias /repo /mnt

Options Indexes FollowSymLinks
AllowOverride None
Require all granted

systemctl restart httpd
vi /etc/yum.repos.d/rocky9.repo

###USE YOUR HAMMER MACHINE IN BASEURL###
[BaseOS]
name=BaseOS Packages Rocky Linux 9
metadata_expire=-1
gpgcheck=1
enabled=1
#baseurl=file:///mnt/BaseOS/
baseurl=http://hammer25/repo/BaseOS/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
[AppStream]
name=AppStream Packages Rocky Linux 9
metadata_expire=-1
gpgcheck=1
enabled=1
#baseurl=file:///mnt/AppStream/
baseurl=http://hammer25/repo/AppStream/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

Question

Do the paths you’ve modified at baseurl make sense to you? If not, what do you need to better understand?

dnf clean all
dnf repolist
# Try to install something
dnf --disablerepo="*" --enablerepo="BaseOS AppStream" install gimp

Digging Deeper

Question

You’ve set up a local repository and you’ve shared that repo out to other systems that might want to connect. Why might you need this if you’re going to fully air-gap systems? Is it still necessary even if your enterprise patching solution is well designed? Why or why not?

Answer

We need a unified checkpoint that ensures secure conformity of a package before patching air-gapped systems. Air-gapped systems are not eternally disconnected, they can be connected to other systems in a highly controlled manner.

Question

Can you add the Mellanox ISO that is included in the /lab_work/repos_and_patching section to be a repository that your systems can access? If you have trouble, troubleshoot and ask the group for help.

Answer

Yes you can, it must be given a special header and be registered aka. Packaged into the local repo in order for other package management systems to see it.

ProLUG Links ⛓️

Discord: https://discord.com/invite/m6VPPD9usw Youtube: https://www.youtube.com/@het_tanis8213 Twitch: https://www.twitch.tv/het_tanis ProLUG PSC Repo: https://github.com/ProfessionalLinuxUsersGroup/psc ProLUG PSC Book: https://professionallinuxusersgroup.github.io/psc/ ProLUG Book of Labs: https://leanpub.com/theprolugbigbookoflabs KillerCoda: https://killercoda.com/het-tanis

Professional Linux User Group Security Engineering Unit 5 Web Book ProLUG, 2025. ↩︎
Rocky Documentation: Software Management Web Book Rocky Docs, 2025. ↩︎
Google Search Engine Web Search Engine, 2025. ↩︎
Epel Documentation Web Docs IBM, 2025. ↩︎