At some point, building a server wasn’t enough. It also needed to be secure. That’s where hardening came in. I had a document for this as well. Based loosely on CIS guidance, adapted for what we actually needed at the time. From the document:

“hardening… according to CISecurity”

It wasn’t theoretical. It was practical. The first step was obvious: Stop doing dangerous things. No root login over SSH. No password authentication. Only key-based access. From the guide:

• PermitRootLogin no
• PasswordAuthentication no

Then came access control. TCP wrappers. Firewall rules. Explicitly defining what was allowed and what wasn’t. Example:

ALL: ALL in hosts.deny

Start with nothing. Allow only what you need. Then system services. A long list of things to disable. Not because they were broken. Because they weren’t needed. There was even a script to identify what could be turned off:

generate a list of enabled services and review them manually

That was the pattern.

• Reduce.
• Limit.
• Control.

Then came kernel tuning.

• disable redirects
• enable SYN cookies
• restrict routing behaviour

And filesystem controls:

• nodev
• nosuid

Even things like:

• disabling USB devices
• restricting cron usage
• enforcing password complexity

Some of it felt heavy-handed. Some of it probably was. But it taught something important.

Security isn’t one setting. It’s layers.

Each change on its own doesn’t do much. Together, they reduce risk. Not eliminate it. Just reduce it. Looking back, not everything in that document would still be relevant today. Some of it is tied to the time, the tools, the version of Linux. But the approach still holds.

• Take a system.
• Understand what it does.
• Remove what it doesn’t need.
• Restrict what remains.

And write it down so you can do it again. That’s how I learned it. Not from a course but from building, breaking, and repeating what worked.

Tags:

linuxrhelsecurityhardeningiptablessshcisinfrastructuresysadmin