Welcome to the deep dive. Today, we're tackling Linux security and hardening. It's not just about servers anymore, is it. I mean Linux is everywhere now, cloud stuff, IoT devices, even your smart fridge maybe.
Right, So understanding how to lock these systems down is becoming way more critical.
So our goal in this deep dive is really to pull out the most practical, actionable stuff from our sources help you build a more secure Linux setup exactly.
We've gone through a lot of material covers pretty much everything from like the initial setup to more advanced things intrusion prevention, data protection, all that. Okay, we'll hit on updates, firewalls. Think of those as your digital border control, h encryption obviously access control, who gets to do what, and you know, tools to spot threats. We want to give you real world knowledge, but without drowning you in jargon.
Good and to make it practical. A lot of the source materials suggests using virtual box for practice environments.
Yeah, that's a great tip. Virtual box is fantastic. It's free, runs on almost anything, Windows, Linux, Mac.
Even Solaris apparently.
Ah yeah, if you're feeling nostalgic, and the examples will draw on used various Linux versions Bontouo server, Sento seven, Analynux eight eight and nine, Fedora two. So good mix, okay, And for anyone listening who's on Windows, connecting to those Linux vms is key, right right. So the sources mentioned tools like siguin or you know, the built in SSH client in Windows ten and eleven, they get you into your Linux lab.
Perfect. Okay, So where do we start.
Let's dive right in with the absolute foundation.
Keeping systems updated updates always fun, though I guess it's maybe less painful on Linux than say Windows sometimes.
Generally, yeah, it's often more streamlined, but it's completely non negotiable for security, you've got to patch those vulnerabilities. Think of it like regular checkups for your system's health.
Makes sense. So how does it work on say a Buntu or Debi based systems.
Pretty simple? Actually, two main steps. First, apped update that just refreshes the list of what packages are available, like checking the catalog. Then apped upgrade that's the part that actually downloads and installs the new versions. Puts the potentially more secure stuff in place.
And you can automate this, right, I think I saw something about that.
You absolutely can on a Buntu, you can tweak a file at captaped dot com dot D twenty auto auto upgrades. Right inside there, there's a setting apt dot periodic dot unattended upgrade. You can set it to one one for fully automatic.
Installs, or you can just get notified.
Exactly set it to zero one to disable the installed part. But you can still configure it to download or just notify you. Gives you that balance, you know, convenience versus control.
Nice? And what about the red hat world CentOS on my Linux?
Similar idea, different commands. You'll use YUM on older stuff like Cento AS seven or DNF on the newer ones like Almal Linux eight and nine. Same principle, they'll get those security patches installed.
And if you really want to stay on top of vulnerabilities.
The CVE database is your friend, Common Vulnerabilities and Exposures. It's at CVET minor dot org. Basically the public library of known security flaws, central reading.
Really okay, updates covered next up firewalls building those digital walls.
Yes, the bouncers for your network traffic, deciding who gets in who stays out.
And for Ubuntu, the go to seems to be uf uncomplicated firewall.
That's the one. Don't let the name fool you though. It's pretty capable for common tasks enabling it, disabling.
It, allowing specific things like SSH so you don't lock yourself out crucial point.
Yeah yeah, oof to allows sefsh is probably one of the first rules you'll set. It manages the underlying rules for you.
So UFOs is like a front end for eptables or NF tables exactly.
It simplifies managing them. On older systems, it was mainly iptables. Newer Ubuntu uses NF tables by default. Now okay, but oof is smart enough to translate your simple commands into the right rules for whichever back end is running. So even with NF tables handles the complexity.
But understanding the basics of how iptables or NF tables work, chains rules matching packets is still useful.
Oh definitely. It helps understand why the rules work. And modern firewalls like these are stateful stateful meaning meaning they track active connections. So if you initiate a connection out, the firewall knows to allow the return traffic for that specific conversation. It's much smarter than just basic packet filtering. Big security advantage.
Gotcha. Now shifting to red hat systems, firewalled is the tool there, yep.
Firewalled similar goal to rent managing rules, but it works a bit differently. You check its status, make sure it's.
Running, and it uses zones, right. What's that about?
Zones are a key concept like public home, internal DMZ. Each zone has a default trust level and a set of allowed services.
Or ports, So you assign network interfaces to zones precisely.
Your public facing web servers interface might be in the public zone, which is typically quite restrictive, and internal database server might be in a more trusted internal zone.
And you add services like sshhttp HTTPS to specific zone.
Exactly firewall CMD zone, public AD service permanent. That kind of thing permanent makes the change stick after a reboot.
You can also add specific ports right like for DNS.
Yeah fort fifty three. For DNS, TCP and UDP, you can specify the protocol firewall cmd ad port fifty three TCP.
Interesting point about blocking ICMP like pings is that generally a good idea well, it.
Can reduce your system's visibility slightly, but blocking pings specifically ICMP type eight echo requests and type zero echo replies can sometimes make troubleshooting harder. Our sources suggests maybe blocking redirect messages type five is more useful, but yeah, you might allow pings temporarily if you're diagnosing network issues.
Okay. And firewalled has a panic mode. Sounds dramatic.
It is. It's like the big red button if you think you're under active attack. Firewall cmd panic on. It drops all network traffic in and out instantly isolates the system. Wow.
Okay, hopefully not need it often. And logging, can you see it's being blocked?
Yes, boken log drop packets with check varlog, curn dot log usually okay. With firewalled on RHL type systems, it's typically varlog messages really useful for seeing if your rules are working as expected or something legitimate is being blocked.
The sources mentioned rich rules in Fireworld. What are those?
Ah? Rich rules give you much more fine grain control. You can create rules based on source, IP destination, port protocol specific actions.
Very powerful, more complex than just adding a service.
Way more flexible. Yeah, let's you build really specific policies.
And you can directly mess with iptables or NF tables even when using Fireworld. But maybe shouldn't.
Generally Yeah, especially with the direct rules feature in firewalled. Yeah, it's usually best to stick to the standard zone and service commands or rich rules. Direct rules are powerful, but easier to mess up and break your firewall. Last resort really got it?
Okay, firewall's done. Let's talk encryption. Keeping secret secret absolutely.
Essential scrambling data to only the right people or systems with a key can read.
It, and Linux has quite a few tools for this.
It does for individual files, GPGG and U. Privacy Guard is a classic.
Very romantic, symmetric and asymmetric YEP.
Symmetric uses one secret key for both locking and unlocking. Asymmetric uses a key pair public key to encrypt, private key to decrypt. The sources touch on creating keys, which involves understanding randomness or entropy for strong.
Keys okay, and for whole discs or partitions.
LUKS is the standard Linux unified key setup. Great for adding a new encrypted drive or encrypting a USB stick. You set a passphrase to unlock it right. Usually happens a boot time or when you plug the device.
In, and E crypts that was for encrypting directories exactly.
It encrypts just a specific folder within your file system creates an encrypted layer.
How does that work in practice?
You use a moult command basically mountain x t crypt's path do encrypted past to mount point. It asks for a passphrase encryption settings. Then your files are purity ECRYPTI in the mount point, but are stored encrypted underneath.
Clever. Okay, move into network encryption TLSSSL certificates. We have to talk about Let's encrypt.
Oh yeah, Let's encrypt has been a massive game changer. Free automated TLS certificates made HTTPS way more accessible compared to.
The traditional certificate authorities.
Right. Traditional cas often cost money, involve more manual validation, but might offer different warranty levels or support options. Depends on your needs.
And sometimes you need to create your own self signed SERTs.
Yeah, for internal testing maybe development. You use the open as a cell toolkit for that.
The sources mentioned RSA and elliptic curve keys and NIST recommendations.
Yep OpenSL can create both. NIST is recommending stronger keys now think three seventy two bit RSA or three hundred four bit ecdsa minimum.
Why the push for stronger keys partly?
Faster computers but also looking ahead to quantum computing longer RSA keys can have a slight performance hit, though elliptic curve is often faster for the same secure level.
Interesting dog tag came up too.
What's that dog tag? Is more of an enterprise thing. A full certificate system like running your own internal caa much bigger scale than just making one offserts with open SSL more complex.
Too, and red hat has system wide crypto policies.
Now yeah, RHL eight and later, let's use set a policy like default or legacy or future future.
Being the strongest right.
Enforces stronger algorithms and protocols across the whole system. SSHTLS everything helps keep things consistent. They also have fits mode for government.
Compliance and even mentions of quantum resistant encryption.
Looking way ahead, it's on the horizon, something to keep an eye on for long term data protection.
Okay, fascinating stuff. Let's pivot to who gets access to what on this system. Discretionary access control or.
DS the absolute basics of Linux permissions, file ownership and read write execute permissions.
So chound to change the owner or.
Group yep, chound user dot group file name. Pretty straightforward and shod.
For the permissions themselves using letters or numbers.
Both work. Symbol mode uses r WX for read, write, execute, and plus or to add or remove permissions for user, U, group, G or others. Oh like chamaud U plus xscript, dot sh.
And the numbers octal mode.
Right each permission. R w X has a number four two one you atom up for each category, user, group, other, So r WX is four plus two plus one and plus seven. R w is four plus two plus two U plus.
Six R is four ah so six forty four. For a file means owner gets read right, six, group gets read four, others get read four.
Exactly and seven to fifty five. For a directory is common. Owner gets read right, execute seven, group and others get red execute five Xcute on a directory means you can enter it.
What about permissions like six hundred or seven hundred. That's a litt quiz you mentioned.
Yeah. Six hundred means only the owner can read and write. Very common for private files like SSH keys. Seven hundred means only the owner can read, write, and executor. Good for private directories.
Okay, special permissions too. SUI D and sg D they sound risky.
They can be sid set user ID on an executable means it runs with the permissions of the file's owner, not the person running it.
So if root owns a SUID file.
Anyone running it runs it as route. Big security risk if that program has flaws. Privileged escalation waiting to happen.
And SGID is similar, but for the.
Group YEP runs with the file's group privileges necessary for some things like the passode command needs SUID to modify the shadow password file, but you need to be careful.
How do you find these files?
The fine command is great for that. Find it g tite F SUID nactusq and R NASHU four thousand, NASHUR two thousand ECGLS that searches for files with either the SUISH four thousand or SGID Nashua two thousand bit set.
Good to know. Beyond standard permissions, there are extended attributes.
Yeah check command. Let's use set extra flags like chat plus I file name.
What does plus I do?
Makes the file immutable? Can't be changed, deleted, renamed anything, even by route until you remove the flag with chat R great for protecting credit config files.
And access control lists ACLS for more specific permissions.
Right standard permissions are just owner, group others. ACLS let you give permissions to specific additional users or groups.
How do you manage those?
Set faclmu dot username dot rw filename to give a specific user ReadWrite get facul file name to see the ACLS.
There's a mask too.
Yeah, the mask can limit the effective permissions for named users and groups added via ACLS. It's an extra layer of control. You can remove ACLS with set facul maxx.
Okay lots control. Air Let's shift to managing user accounts themselves. Account security using pseudo instead of root login seems key.
Absolutely fundamental. Logging in is route all the time is just too risky. Pseudo let's specific users run specific commands as route or another user using their own passwords. And if it's better auditing for one pseudologs who ran what? Plus, you don't need to share the actual root password less.
Exposure and you can figure it with the pseudo editing at serdalos of suters.
Correct the pseudo locks the file and check syntax before saving, which is fafor. You can define rules there grant permissions to users or better yet.
Groups like the wheel group. On some systems, exactly.
Add users to the wheel group, then give that group pseudo rights and asceted to suitors. You can also set things like requiring a password every time defaults, time stamp timeout zero.
You can get really specific with command aliases too, right, but be careful.
You can create aliases for groups of users or commands, but broad command aliases like allowing all commands and users men can accidentally grant way more power than you intended. Be specific.
Can you allow users to run commands as other users, not just route?
Yes, other user command The tuterit does file lets you specify which users a user can run commands as, and.
No pass WD entries avoid those generally.
Yes, very risky. It lets users run pseudo commands without any password. Prompt only use it if absolutely necessary and for very specific limited commands.
Good warning and a reminder about default accounts passwords on IoT devices, change them immediately critical.
That's often the first thing attackers try publicly known defaults are a huge vulnerability.
The source is also compared to aducer and user ad What's the difference?
Aducer is usually more interactive, friendlier prompts you for info, creates the home directory, copy skeleton files.
Can even encrypt the home directory.
Yeah, if you have ecris utils installed aducer can set that up automatically. User ad is lower level, less interactive, more script friendly maybe, but you have to do more set up manually.
Okay, let's talk passwords. Enforcing strong ones with PAM.
PAM pluggable Authentication modules is the framework Linux uses for authentication. The punked hamduck You'll quality dot so module checks password strength.
How do you configure it?
In files? Under it set a channel d usually in system auth or password oth or similar common files. You can set minimum length, require different character types upper case, lowercase, digits, symbols prevent dictionary words, yep it checks again dictionaries and common patterns helps prevent really weak passwords.
There's a debate about password expiration versus long pass phrases.
There is Forcing frequent changes often leads people to pick simpler, guessable passwords or reuse patterns. The current thinking often leans towards using longer, complex but memorable passphrases and not forcing expiration unless there's a suspected compromise.
Makes sense, and the peel and Quality package helps On Debiandubuntu.
Yes provides tools in the library for this.
What about checking if passwords have been leaked in breaches a good proactive step.
You can use APIs like the have a Been Pound Passwords API. There are command line tools like using curl to check a hash of your password against the database.
You check the hash, not the password itself.
Crucially, yes, you don't send your actual password. You send a hash of it, and the service tells you if that hash exists in the breach data. Much safer, okay.
And ensuring accounts don't stay active forever expiration policies.
The change command is for that changeyyyy mmddd. Username sets an account expiration date.
Can you force a password change on next log in?
Yep change DoD zero username sets the last change date to epoc zero forcing a change immediately.
What about locking accounts after too many failed logins? Route force prevention.
Also done with PAM modules okay, pantally two. On older systems, PAM faylock is more common now.
Can figure those in et cetera bat D as well.
Yes, typically in files like log ner slide. You said how many failures trigger a lockout and for how long? Critical defense?
Can you manually lock accounts too?
Sure? User modeage to L username locks it, user motag to U unlocks or password to l and passwood you. The output might differ slightly between distros, but they do the job.
And finally, BIOCEUEFI security and using a checklist important basics.
Definitely secure boat firmwore passwords. Don't forget the physical or firmware level, and a checklist helps ensure you cover all the bases during setup.
Right, let's secure remote access SSH is king.
Here absolutely and securing SSH properly is paramount. First rule, Use SAH keys, not just passwords.
Why are keys so much better?
They're way harder to root force. A strong key is cryptographically secure, unlike potentially weak password. You generate a pair. Private key stays with you. Public key goes on the server.
Generate with skegen recommendations on type and.
Size Yes, cheek and following this guidance, aim for at least three seventy two bit RSA keys or maybe even better three hundred and eighty four bit ECDSA keys, stronger crypto okay.
Then get the public key onto the server's dotch authorized keys file.
Right this chash copy aid user at host is the easiest way, or just paste it in manually if you have to.
Then crucially disabled password log in in et cetera. Strident fig yes.
Set password authentication no, and also permit root log in no.
Permit root log in no is vital. Don't log in directly as rootover SSH.
Best practice absolutely log in as a regular user, then use pseudo. Some distros might default permit rootleg in differently, so always check and set it to know.
What about two factor authentication for SSH, AD's another layer.
You can use things like Google Authenticator with PAM. Install the PAM module them PAM Google Authenticator, configure it.
And then you need your key and a code from your phone exactly.
Time based code makes it much harder for someone even if they somehow get your private key.
Understanding the SSH encryption algorithms themselves seems important to disabling weak ones definitely.
SSH uses symmetric ciphers for the main data key exchange algorithms kex and max for integrity. You should disable older weaker ones.
And should configure how do you know what you're weak?
Check currentness recommendations, security advisories. Tools like nmap with the sish to enam algos script can show you what your server offers. Then you can figure cipher's m max kex algorithms, directives and should config to only allow strong ones.
And on Alma Linix nine. Those crypto policies help here too.
Yes, update crypto policies can manage the allowed SSH algorithms based on the policy level, Default, future, et cetera.
Simplifies things, okay, beyond authentication controlling who can connect.
Several ways in should config allow users and allow groups, let you white list specific users or groups. Host based authentication that checks the client's host key requires careful setup less common now TCP wrappers at costs, dot allow at coast, dot deny are another layer based on client IP and firewalls. Of course, In firewalls, as we discussed, limit access to Port twenty two from trusted sources.
Automatic logout for idle SSH sessions good idea.
Yeah, prevents abandoned sessions being potentially hijacked. Set the tmout environment variable. You can put it in a script and etcetera profile dot D like export tmout six hundred for ten minutes, make the script executable.
Disable x eleven forwarding.
Two if you don't need it, Yes, x eleven forwarding no in should config. The x eleven protocol has some known weaknesses.
Managing authorized keys files centrally. How does that work?
Instead of each user having their own YATCH authorized keys, you can tell sig via authorized keysfile, and you you canfig to look somewhere else like ETCeteras authorized keys percent, where percent is.
The username and permissions are key.
There Absolutely that central directory and the key files should typically be owned by root read only for root, keeps users for modifying others. Keys for large scale commercial tools exist too.
Okay. Last sshpoint SFTP only access, no shell.
Very common requirement. Create a dedicated group, say sitchpitzers, add users to it, set their shell to something non interactive that handles s FTP like this, her lives FTP server.
And configures didn't contact ye.
Use subsystem SFTP internal as FTP. Then add a match group, press pussers block inside that block. Set crute directory path the their data to lock them into a specific directory. Set force command internal SFTP and allow TZP forwarding no s eleven forwarding no, so.
They can only transfer files within their cruit jail exactly.
No shell access just SFTP and putty is a common Windows client for SSHSFTP.
Great, okay, let's shift to intrusion detection and prevention spotting the bad guys.
Right, we've talked prevention with firewalls, iptables and of tables. Detect involves monitoring.
Snort came up as a network IDs and IDs.
Yes, snortwatches network traffic. Compares it to rules looking for attack patterns. Running it in Docker or Podman can simplify setup. Keeping its rules updated is critical.
Security Onion is more comprehensive, much more.
It's a whole platform, bundles idsps like Snortseracata, forensic tools, log management, ELK stack. It's now often installed on Cento seven text mode. Powerful, but more complex.
What about tools running on the Linux host itself for auditing?
Linus Linus is great scans your system, checks configuration against security best practices, looks for hardening opportunities, gives detailed reports.
Free version available yep.
Open source version is very capable. Commercial versions add more features. You can often find it in the EPO repo for red hat systems. It checks kernel hardening too.
Kylie Linux is mentioned too.
Collie is more for penetration testing the athensive side, but it contains tons of auditing tools you could use defensively too.
The sources were cautious about root kit scanners like rootkit Hunter or screwtkit.
Yeah. The problem is advanced rootkits are designed to hide from these tools. They might catch older or simpler ones, but don't rely on them exclusively. Even appromore celenicx won't stop the installation of rootkit, though they might limit what it can do afterwards. Defense in depth is key.
Any quick malware analysis tips.
If you have a suspicious file, the strings command can be useful. It just prints readable text found inside the file. Might reveal URLs commands clues. Might need the by Noodle's package for it.
And checking file hashes online.
Yeah, calculate the SAHA two five six hash of the file, then search for that hash on virus total or similar sites. See if it's known malware safer than running the file. Don't upload sensitive files though, just check the hash.
Good advice. Final section general system hardening techniques, extra fortifications.
Right the finishing touches, secure boot, disabling unneeded services. Those are basics. Then kernel hordening via systeale.
Tuning parameters in proxis yeah, and making them stick in at stale dot com.
Exactly or files in at center STLDT lots of parameters you can tweak.
For security examples like disabling ting responses.
Net dot IPv four dot icmpico an oreo one does that. NED dot IPv four dot com dost sender cendris directs zero disables sending ICMP.
Redirects TCP s y and cookies.
NED dot IPv four dot pcpc and cookies one helps mitigate s y n flood dose attacks. Link protection f s DOT protected hard links one and f s DOT protected simblinks one protects against certain attacks using links in worldwritable directories.
S u ID dumpable f s DOT sue.
Dumpable zero prevents core dumps from s yz g i D programs, which could leak memory contents.
Address space layout randomization kernel.
DOT randomides of VAS based two makes buffer overflow exploits harder by randomizing memory locations.
Essential restricting kernel info colonel.
Dot dm s korrestrict one limits who can read kernel logs via d sdi E dot colonel dot ap director at one or two hides kernel pointer addresses in proc, reduces info leaks.
Control groups and name spaces were mentioned too.
Yeah Kernel features for isolation c groups limit resource usage CPU memory per process group helps prevent resource exhaustion. A name spaces give processes isolated views of things like network PIDs, mounts, foundation for containers.
Final Capabilities ss CAP more granular privileges capabilities that you give specific root like powers to a process without making it fully root.
Set cap lets you restrict which system calls a process can even make drastically limits a tack surface.
Hand Boxing technology seem important for isolating apps. Fire Jail.
Fire Jail uses suid to sandbox applications, restricts filesystem access, network, et cetera. Mostly for desktop apps. The suid bit makes some admins nervous on servers, though.
Snaps and flat pass.
Yeah the package formats but also provide sand boxing. Snaps ubintu have automatic updates. Ubuntu Core uses snaps for the whole OS Good Fryot, flat Pack, Fedora others also sandboxes. Updates, usually managed via the flatub repository or similar manual updates often.
What about anti malware clamavo good to have even on Linux install clamavvy enable clam av fresh clam service for auto updates.
Lm D Linux maor detect is another option. Run scans periodically.
CYLINICX might interfere.
Sometimes you might need to set SELINICX booleians like antivirus scan scan System one to allow the scanner to read all files.
System auditing with audit.
Very powerful logs detailed info about system events based on rules you define file access commands, run system calls.
Configure rules with audittail or in it cotta trules dat.
YEP, then use a search to search logs or report for summarys. Essential for forensics and compliance and notified. Weight is simpler for just real time file change notifications, but less.
Comprehensive opensacky for compliance scanning.
Yes, scans against security basedlines like PCIDSS digs tells you where you're non compliant. Red AD systems can even apply profiles during install. Doesn't fix everything automatically like dispartitioning, but great for checks.
Blog management arci's log log Watch.
Crucial know your key logs, varlogoth dot log messages, secure, et cetera, configure RSISLOGBX or sizelog dot com for local storage, maybe a remote log into a central server. Log Watch analyzes logs, daily email summaries needs a mail server like postfix setup.
And finally securing the bootloader GRUB.
Important physical security step set a Grub password to prevent unauthorized kernel parameter changes or booting into recovery mode.
How different on RedHat versus UBUNTUU.
Yeah, Redhead uses Grub two, set password a Boontuo involves editing files and etcagrub dot D and running update. Grub protects against unauthorized boot time access.
USB guard was mentioned too.
Controls which USB devices can be used. Doesn't stop booting from USB though, need BIOCEUFI password for that. Modern FPUs also have security features built in.
Wow, Okay, that was a lot. A real deep dive into Linux security.
It covers a huge amount of ground, doesn't It updates, firewalls, encryption, access control, monitoring, hardening.
It really shows securing Linux isn't just one thing. It's many layers working together, an ongoing process.
Absolutely, and for you listening, the key is don't feel overwhelmed. You don't need to do everything.
Today right Pick a few things.
Yeah, identify what's most critical for your setup. Start with the basic updates, firewall, strong passwords, SSH keys, pseudo. Then build from there.
Explore the tools that sounded interesting, use the man pages, the websites, exactly.
Use this as a starting point, dig deeper into OOH or audit or kernel tuning, whatever fits your needs or sparks your interest.
So a final thought, then, with threats always changing, new vulnerabilities popping up, how do you build that mindset of continuous improvement keeping security front of mind in your daily workflow. It's not just set and forget, is it.
Not at all? It requires ongoing learning, staying informed, and regularly reviewing your configurations. We really hope you continue exploring these topics. If you try things out, run into issues, have more questions, let us know your feedback helps everyone.
Definitely thanks for joining us on this deep dive into Linux security