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