DEV Community: Olatunde salami

Monitoring Users and Login Activity (with last, w, who)

Olatunde salami — Sat, 24 May 2025 11:19:10 +0000

Welcome to Day 17 of our Linux Security Basics series! After setting up a firewall with ufw or firewalld on Day 5, we added a strong layer of network security. Now, let’s turn our attention to what’s happening inside your system. Monitoring user activity is like having a security camera for your Linux server it helps you spot unauthorized access, track user behaviour, and respond to potential threats. Today, we’ll use three simple yet powerful commands: last, w, and who, to keep an eye on users and login activity. Let’s dive in with a story and some real-world scenarios!

Index

Why Monitor User Activity? A SysAdmin’s Wake-Up Call
Command 1: last - Review Login History
Command 2: w - Who’s Online Right Now?
Command 3: who - A Quick Snapshot of Logged-In Users
Best Practices: Keeping Your System Safe

Why Monitor User Activity? A SysAdmin’s Wake-Up Call

Picture this: You’re a sysadmin named Jamie, managing a Linux server for a small company. One Monday morning, you notice the server is running slower than usual. Digging deeper, you discover a user account you don’t recognise has been logging in at odd hours 2 a.m., 3 a.m. from an unfamiliar IP address. Someone compromised an old account with a weak password and has been running malicious scripts! If only you had been monitoring login activity, you could have caught this sooner.

Monitoring users and logins helps you:

Detect unauthorized access (e.g., brute force attacks or compromised accounts).
Track user behavior for auditing or troubleshooting.
Respond quickly to suspicious activity.

Let’s use last, w, and who to ensure Jamie’s nightmare doesn’t happen to you.

Command 1: `last` - Review Login History

The last command shows a history of user logins, including who logged in, when, from where, and for how long.

Real-Life Use Case: Investigating a Breach

Jamie wants to investigate the unauthorized logins on the company server.

Step 1: Run `last`

last

Output example:

jamie    pts/0        192.168.1.10    Mon May 19 09:00 - 10:00  (01:00)
unknown  pts/1        203.0.113.5     Sun May 18 02:00 - 03:00  (01:00)
root     tty1         localhost       Sat May 17 14:00 - 15:00  (01:00)

jamie: Logged in from a known IP.
unknown: Suspicious login from an unknown IP at 2 a.m.
root: Local login, likely during maintenance.

Step 2: Narrow Down with Options

To focus on a specific user:

last unknown

To see logins from a specific IP:

last -i 203.0.113.5

Jamie uses last to confirm the unknown user logged in multiple times over the weekend. The IP address (203.0.113.5) isn’t from the company network—a red flag! Jamie disables the account and starts investigating further.

Command 2: `w` - Who’s Online Right Now?

The w command shows who is currently logged into the system, what they’re doing, and how long they’ve been idle.

Real-Life Use Case: Spotting Suspicious Activity in Real Time

Jamie wants to see if the intruder is still on the system while investigating.

Step 1: Run `w`

Output example:

 10:41:00 up 5 days, 2:00,  2 users,  load average: 0.10, 0.15, 0.20
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
jamie    pts/0    192.168.1.10     09:00    0.00s  0.03s  0.01s bash
unknown  pts/1    203.0.113.5      10:30    5:00   1:20   0.50s python3 script.py

jamie: Actively working in a bash shell.
unknown: Running a Python script, logged in from the same suspicious IP.

Step 2: Take Action

Jamie sees the unknown user is still active, running a script. To stop them, Jamie terminates the session:

sudo pkill -u unknown

By using w, Jamie caught the intruder in the act and kicked them off the system before more damage was done.

Command 3: `who` - A Quick Snapshot of Logged-In Users

The who command provides a simpler view of currently logged-in users, showing their username, terminal, login time, and source.

Real-Life Use Case: Routine Checks for a Shared Server

Jamie manages a shared server for a university lab where multiple students log in. She wants a quick way to see who’s online during her daily checks.

Step 1: Run `who`

who

Output example:

jamie    pts/0    2025-05-24 09:00 (192.168.1.10)
student1 pts/1    2025-05-24 10:00 (172.16.2.15)
student2 pts/2    2025-05-24 10:15 (172.16.2.20)

All IPs are from the university network, and the users are recognised no immediate concerns.

Step 2: Add Details with Options

To see more details, use:

who -H

This adds headers for clarity.

Jamie uses who for quick checks, ensuring only authorized students are logged in. One day, she spots an unfamiliar IP, cross checks with last, and discovers a student shared their credentials prompting a security training session!

Best Practices: Keeping Your System Safe

Schedule Regular Checks: Run who or w daily to spot unusual activity.
Automate Monitoring: Create a script to log last output and email alerts for suspicious IPs:

  #!/bin/bash
  last > /var/log/login_history.log
  grep "203.0.113.5" /var/log/login_history.log | mail -s "Suspicious Login Alert" admin@example.com

Save as monitor_logins.sh, make it executable (chmod +x monitor_logins.sh), and schedule with cron. For example, add to crontab to run daily at 2 a.m.:

  0 2 * * * /path/to/monitor_logins.sh

Combine with Logs: Check /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (Red Hat) for more details on login attempts.
Act Quickly: If you spot suspicious activity, disable accounts (sudo passwd -l username) and investigate.

Troubleshooting: False Alarms and Missed Intruders

False Positives: Jamie once panicked over an unfamiliar IP, but it was a student using a VPN. Cross check IPs with known users before acting.
Missed Activity: If last shows no data, ensure /var/log/wtmp isn’t corrupted. Reset it with sudo truncate -s 0 /var/log/wtmp.

What’s Next?

You’re now equipped to monitor user activity and spot potential threats! Tomorrow, on Day 18, we’ll explore Introduction to SELinux or AppArmor for Advanced Hardening, taking your security to the next level. Stay tuned!

I would love to hear your thoughts, experiences, or tips about Linux! Feel free to share in the comments and join the conversation. Connect with me on LinkedIn!

30DaysLinuxChallenge #CloudWhistler #RedHat #CloudSecurity #DevOps #Linux #OpenSource #CloudComputing #RedHatEnterpriseLinux #SystemLogs #EnterpriseIT #Observability #Logging #SysAdmin #Automation #CloudEngineer #TechForBusiness #ITSupport #SRE #CloudOps

Simple Firewall with ufw or firewalld

Olatunde salami — Wed, 21 May 2025 22:33:03 +0000

Welcome to Day 16 of our Linux Security Basics series! After securing file permissions on topic 5, it’s time to add a layer of network security with a firewall. A firewall controls incoming and outgoing traffic, protecting your system from unauthorized access. Today, we’ll explore two user friendly tools: ufw (Uncomplicated Firewall) and firewalld. Let’s set up a simple firewall to fortify your Linux system!

Index

Why Use a Firewall?
Choosing Between ufw and firewalld
Setting Up a Firewall with ufwd
Setting Up a Firewall with firewalld
Best Practices

Why Use a Firewall?

A firewall acts as a gatekeeper, allowing only trusted traffic while blocking potential threats. Without one, your system is vulnerable to attacks like port scanning or unauthorized remote logins. Both ufw and firewalld simplify firewall management, making them ideal for beginners and experienced users alike.

Choosing Between ufw and firewalld

ufw: Lightweight and easy to use, pre installed on Ubuntu and Debian-based systems. Best for simple setups.
firewalld: More dynamic, with support for runtime changes and zones. Common on Red Hat-based systems (e.g., CentOS, Fedora).

Check which tool is available:

For ufw: sudo ufw version
For firewalld: sudo firewall-cmd --version

If both are installed, you can use either let’s cover both!

Setting Up a Firewall with ufw

1. Check Status

Ensure ufw is active:

sudo ufw status

If it says "inactive," proceed to enable it.

2. Enable ufw

Enable the firewall (this may disrupt existing connections, so plan ahead):

sudo ufw enable

3. Allow Essential Services

Allow traffic for services you need (e.g., SSH on port 22):

sudo ufw allow 22/tcp

Or use service names (if configured):

sudo ufw allow ssh

4. Deny Unwanted Traffic

Block specific ports (e.g., deny port 23, used for telnet):

sudo ufw deny 23

5. Set Default Policies

Restrict all incoming traffic by default, allowing only specified ports:

sudo ufw default deny incoming
sudo ufw default allow outgoing

6. Verify and Apply

Check the rules:

sudo ufw status

Apply changes (usually automatic with enable).

Setting Up a Firewall with firewalld

1. Check Status

See if firewalld is running:

sudo firewall-cmd --state

If it returns "not running," start it:

sudo systemctl start firewalld

2. Enable firewalld

Ensure it starts on boot:

sudo systemctl enable firewalld

3. Allow Services

Allow SSH (port 22):

sudo firewall-cmd --add-service=ssh --permanent

4. Add Custom Ports

Allow a custom port (e.g., 8080 for a web server):

sudo firewall-cmd --add-port=8080/tcp --permanent

5. Reload Rules

Apply changes:

sudo firewall-cmd --reload

6. Check Rules

View active rules:

sudo firewall-cmd --list-all

Best Practices

Allow Only Necessary Ports: Minimize open ports to reduce attack surfaces.
Test After Changes: Ensure services (e.g., SSH) still work after enabling rules.
Backup Rules: Save ufw rules with sudo ufw show raw or firewalld with sudo firewall-cmd --runtime-to-permanent.
Monitor Logs: Check /var/log/ufw.log (ufw) or firewalld logs for issues.

Troubleshooting

Locked Out?: If you block SSH, use the console or a rescue method to regain access.
Conflicting Rules?: Reset with sudo ufw reset or sudo firewall-cmd --reload.

What’s Next?

You’ve now added a firewall to protect your network traffic! On our next topic, we’ll explore Monitoring Users and Login Activity with commands like last, w, and who. Stay tuned!

I would love to hear your thoughts, experiences, or tips about Linux!
Feel free to share in the comments and join the conversation.
Connect with me on LinkedIn !

#30DaysLinuxChallenge #CloudWhistler #RedHat #Cloudsecurity #DevOps #Linux #OpenSource #CloudComputing #RedHatEnterpriseLinux #SystemLogs #EnterpriseIT #Observability #Logging #SysAdmin #Automation #CloudEngineer #TechForBusiness #ITSupport #SRE #CloudOps

Hardening File Permissions: Practical Steps to Lock Down Data

Olatunde salami — Mon, 19 May 2025 14:31:13 +0000

Welcome to Day 15 of 30days linux challenge. We will be treating the 4th topic in our Linux Security Basics series! By now, you've learned why Linux is secure by design, how to secure SSH, and how to protect against brute force attacks with fail2ban. Today, we’re diving into a critical aspect of Linux security: hardening file permissions. Properly managing file permissions ensures that only authorized users can access sensitive data, reducing the risk of unauthorized access or accidental leaks. Let’s explore practical steps to lock down your data.

Index

Why File Permissions Matter
Understanding Linux File Permissions
Practical Steps to Harden File Permissions
Harden Home Directories
Secure Directories with Sticky Bits
Secure Directories with Sticky Bits
Use chown to Correct Ownership
Find and Fix Risky Permissions
Automate with a Script
Best Practices

Why File Permissions Matter

In Linux, every file and directory has permissions that dictate who can read, write, or execute it. Misconfigured permissions can expose sensitive files (like configuration files or user data) to attackers or unprivileged users. For example, a world readable file containing passwords or a world writable directory could allow malicious changes. Hardening file permissions is about applying the principle of least privilege: users and processes should only have the access they need.

Understanding Linux File Permissions

Before we start, let’s recap how permissions work:

Permission Types:
- Read (r): View file contents or list directory contents.
- Write (w): Modify a file or create/delete files in a directory.
- Execute (x): Run a file (e.g., a script or binary) or access a directory.
Permission Groups:
- Owner (u): The user who owns the file.
- Group (g): Users in the file’s group.
- Others (o): Everyone else.
Viewing Permissions:

Use ls -l to see permissions. Example output:

  -rwxr-xr--  1 alice users  4096 May 19 2025 script.sh

Here, rwxr-xr-- means:

Owner (alice): Read, write, execute (rwx).
Group (users): Read, execute (r-x).
Others: Read only (r--).
- Numeric Notation: Permissions can be represented as numbers:
Read = 4, Write = 2, Execute = 1.
Example: 755 = rwx (7 = 4+2+1) for owner, r-x (5 = 4+1) for group and others.

Practical Steps to Harden File Permissions

Let’s walk through actionable steps to secure your files and directories. These commands assume you’re logged in as a user with sudo privileges.

1. Audit Existing Permissions

Start by checking permissions on critical files and directories.

Command:

  ls -l /etc /home /var/log

What to Look For:
- Sensitive files (e.g., /etc/shadow, /etc/passwd) should not be world-readable or writable.
- User home directories (/home/username) should not be accessible to others.
- Log files in /var/log should be restricted to root or specific services.
Example:

If /etc/shadow shows -rw-r--r-- (world-readable), it’s a security risk. Fix it later in Step 2.

2. Set Secure Permissions for Sensitive Files

Use the chmod command to adjust permissions.

Secure Configuration Files: The /etc/shadow file (containing hashed passwords) should only be readable/writable by root.

  sudo chmod 600 /etc/shadow

This sets rw------- (owner only).

Protect User Configuration Files: Files like ~/.ssh/id_rsa (SSH private keys) should be private.

  chmod 600 ~/.ssh/id_rsa

Remove World-Readable Permissions: For files that don’t need public access, remove permissions for "others."

  sudo chmod o-rwx /etc/myapp.conf

3. Harden Home Directories

Home directories should be accessible only by their owners.

Check Permissions:

  ls -ld /home/*

If a directory shows drwxr-xr-x, others can list its contents.

Restrict Access: Set permissions to 700 (owner only access).

  sudo chmod 700 /home/username

Set Default Permissions for New Files: Use umask to control default permissions. A umask of 022 ensures new files are not world-writable. Check your current umask:

  umask

To set it permanently, add umask 022 to ~/.bashrc or /etc/profile.

4. Secure Directories with Sticky Bits

In shared directories (e.g., /tmp), users might delete others’ files. The sticky bit prevents this.

Set the Sticky Bit:

  sudo chmod +t /tmp

Check with ls -ld /tmp. The permissions should show drwxrwxrwt.

5. Use `chown` to Correct Ownership

Ensure files are owned by the right user or group.

Check Ownership:

  ls -l /var/www

Web server files should typically be owned by the web server user (e.g., www-data).

Change Ownership:

  sudo chown -R www-data:www-data /var/www

6. Find and Fix Risky Permissions

Search for files with overly permissive settings.

Find World Writable Files:

  sudo find / -type f -perm -o+w

Review the output and remove unnecessary write permissions:

  sudo chmod o-w /path/to/file

Find World Readable Sensitive Files:

  sudo find /etc -type f -perm -o+r

Restrict access as needed.

7. Automate with a Script

To simplify, create a script to check and fix common issues.

#!/bin/bash
# Secure critical files
sudo chmod 600 /etc/shadow /etc/gshadow
sudo chmod 644 /etc/passwd
sudo chmod 700 /home/* -R
sudo chmod +t /tmp
echo "Permissions hardened!"

Save this as harden_permissions.sh, make it executable (chmod +x harden_permissions.sh), and run it with sudo ./harden_permissions.sh.

Best Practices

Regularly Audit Permissions: Use find or tools like lynix to monitor changes.
Backup Before Changes: Always back up critical files before modifying permissions.
Test Changes: Ensure services (e.g., web servers) still function after permission changes.
Document Exceptions: If a file needs unusual permissions, document why.

I would love to hear your thoughts, experiences, or tips about Linux!
Feel free to share in the comments and join the conversation.
Connect with me on LinkedIn !

Using Fail2Ban to Protect Against Brute Force Attacks

Olatunde salami — Sat, 17 May 2025 20:40:20 +0000

Table Of Content

Introduction
Why Fail2Ban?
Step 1: Installing Fail2Ban
Step 2: Configuring Fail2Ban
Step 3: Testing Your Setup
Step 4: Protecting Other Services
Step 5: Monitoring and Fine Tuning
Summary

Introduction

Brute force attacks are like a thief trying every key on a ring to unlock your server. They’re relentless, automated, and can overwhelm your system if left unchecked. Enter Fail2Ban, a lightweight, open-source tool that acts like a vigilant security guard, banning malicious IPs after too many failed login attempts.

In this article, we’ll walk through how to set up Fail2Ban to protect your server, with practical examples and tips to keep things engaging.

Let’s lock down your server! 🔒

Why Fail2Ban?

Imagine this: your SSH server logs show hundreds of login attempts from a single IP in minutes. Without protection, your server could be compromised, or at least slowed to a crawl.

Fail2Ban monitors logs, detects suspicious patterns, and temporarily bans IPs using firewall rules (like iptables or firewalld). It’s simple, effective, and works for services like SSH, Apache, Nginx, and more.

Fun Fact: Fail2Ban has been around since 2004 and is still a go-to tool for sysadmins. Its simplicity is its superpower!

Step 1: Installing Fail2Ban

Let’s get Fail2Ban up and running. Most Linux distros make this a breeze.

On Ubuntu/Debian:

sudo apt update
sudo apt install fail2ban

On CentOS/RHEL:

sudo yum install epel-release
sudo yum install fail2ban

After installation, start and enable Fail2Ban:

sudo systemctl start fail2ban
sudo systemctl enable fail2ban

Interactive Tip: Run fail2ban client status in your terminal. What do you see? Share your output in the comments it’s a great way to confirm your setup!

Step 2: Configuring Fail2Ban

Fail2Ban’s magic happens in its config files, located in /etc/fail2ban/.

Note: Don’t edit jail.conf directly it might get overwritten. Instead, create a jail.local file or use the jail.d/ directory for custom rules.

Example: jail.local for SSH

[DEFAULT]
bantime  = 600
findtime = 600
maxretry = 5

[sshd]
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 3600

What’s Happening Here?

bantime: How long (in seconds) an IP is banned (600 = 10 minutes).
findtime: The time window (in seconds) to look for failed attempts.
maxretry: Number of failed attempts before banning.
[sshd]: Protects the SSH service, using the sshd filter and monitoring /var/log/auth.log.

Engage with This: Try tweaking maxretry to 2 or bantime to 7200 (2 hours). What’s the trade off? Too strict, and you might lock out legit users; too lenient, and attackers slip through. Share your thoughts below!

Step 3: Testing Your Setup

Let’s simulate a brute force attack (safely, of course).

From another machine, try logging into your server via SSH with incorrect credentials multiple times:

ssh user@your-server-ip

After hitting the maxretry limit, check Fail2Ban status:

sudo fail2ban-client status sshd

You should see the offending IP in the Banned IP list.

To unban an IP (for testing):

sudo fail2ban-client unban <IP_ADDRESS>

Interactive Challenge: Set up Fail2Ban on a test server and try this. How many attempts did it take to get banned? Post your results!

Step 4: Protecting Other Services

Fail2Ban isn’t just for SSH. Want to secure your web server? Enable jails for Apache or Nginx.

Example: Protect WordPress Login
[wordpress]
enabled  = true
port     = http,https
filter   = wordpress
logpath  = /var/log/apache2/access.log
maxretry = 3
bantime  = 3600

You’ll need to create a custom filter file, e.g., /etc/fail2ban/filter.d/wordpress.conf:

[Definition]
failregex = ^.*wp-login\.php.* 401
ignoreregex =

Pro Tip: Check Fail2Ban’s GitHub for pre-made filters for popular services.

Got a service you want to protect? Drop it in the comments, and let’s brainstorm a filter together!

Step 5: Monitoring and Fine Tuning

Fail2Ban logs to /var/log/fail2ban.log. To monitor activity:

sudo tail -f /var/log/fail2ban.log

Adjust maxretry or findtime if you see too many false positives.

Want notifications? Integrate with email, Slack, etc., via the action directive in jail.local.

Engagement Prompt: How do you monitor your server security? Do you pair Fail2Ban with tools like Logwatch, Prometheus, or Grafana? Share your stack!

Common Pitfalls (and How to Avoid Them)

Wrong Log Path
Ensure logpath matches your system’s log location (e.g., /var/log/secure on CentOS).

Overly Aggressive Bans
Test your settings to avoid locking out legitimate users.

Firewall Conflicts

Ensure Fail2Ban’s firewall rules don’t conflict with other firewall tools.

Quick Poll: What’s the biggest security oops you’ve made?
No judgment mine was leaving port 22 open with a weak password.
Share yours below!

Wrapping Up: Stay One Step Ahead

Fail2Ban is a powerful ally against brute force attacks, but it’s not a silver bullet. Combine it with:

Strong passwords
SSH key authentication
Regular log monitoring

...for a robust defense. Your server deserves it!

Summary

Fail2Ban is an open source intrusion prevention tool that helps protect Linux servers from brute force attacks. It works by monitoring log files for suspicious activity (e.g., repeated failed login attempts) and automatically bans offending IP addresses using firewall rules like iptables or firewalld.

Key Steps to Use Fail2Ban:

1.Installation

Available via package managers (apt for Ubuntu/Debian, yum for CentOS/RHEL).
Enable and start the Fail2Ban service.

2.Configuration

Customize rules using jail.local or files in jail.d/.
Define parameters like bantime, findtime, and maxretry.

3.Testing

Simulate failed SSH logins and verify bans using fail2ban client status.
Unban test IPs if needed.

4.Protecting Other Services

Extend Fail2Ban to web servers (e.g., Apache, Nginx) and applications like WordPress by writing custom filters.

5.Monitoring & Fine Tuning

View logs in /var/log/fail2ban.log.
Adjust thresholds to avoid false positives.
Set up alerts for better visibility.

I would love to hear your thoughts, experiences, or tips about Linux!
Feel free to share in the comments and join the conversation.
Connect with me on LinkedIn !

Fortify Your SSH: Lock Out Root, Shift Ports, Key In Security.

Olatunde salami — Thu, 15 May 2025 21:41:26 +0000

Table Of Content

Introduction
Why SSH Needs Protection
Disable Root Login
Change the Default SSH Port
Set Up Key-Based Authentication
Summary What I Learned Today

Introduction

Yesterday, I talked about how Linux is secure by design but only if you take action. Today, I’m locking down one of the most important services on any Linux system:

SSH Your remote door into the system.

If SSH is exposed and misconfigured, it becomes a high-value target for brute-force attacks and exploits. So let’s secure it step-by-step.

Why SSH Needs Protection

By default, SSH can:

Allow root login
Use password authentication
Run on the default port (22)

This is convenient, but it also makes your system predictable and vulnerable.

1. Disable Root Login

Why?

Allowing root to log in remotely is risky if someone cracks the password, they get full control instantly.

How:

Open the SSH config file:

sudo nano /etc/ssh/sshd_config

Find or add this line:

PermitRootLogin no

Save and restart SSH:

   sudo systemctl restart ssh

Now, root cannot log in via SSH.

2. Change the Default SSH Port

Why?
Bots scan port 22 constantly. Moving SSH to a non-standard port reduces noise and avoids low effort attacks.

How:

Edit the SSH config again:

sudo nano /etc/ssh/sshd_config

Change the port:

   Port 2222

(Pick any unused port between 1024 and 65535)

Allow the new port in the firewall:

   sudo ufw allow 2222/tcp

Restart SSH:

   sudo systemctl restart ssh

✅ You’ll now connect like this:

ssh -p 2222 user@your-server

3. Set Up Key-Based Authentication

Why?
SSH keys are far more secure than passwords and resistant to brute-force attacks.

🧩 Step-by-Step:

** On Your Local Machine (Client):**

Generate a key pair:

   ssh-keygen -t rsa -b 4096

Copy the public key to the server:

   ssh-copy-id user@your-server -p 2222

This adds your public key to the server’s ~/.ssh/authorized_keys file.

On Your Server:

Edit the SSH config again:

   sudo nano /etc/ssh/sshd_config

Ensure these settings are enabled:

   PubkeyAuthentication yes
   PasswordAuthentication no

Restart SSH:

   sudo systemctl restart ssh

✅ Now, only systems with your private key can log in.

Bonus: Test Before Locking Yourself Out

Always open a second terminal and test your changes before closing your current SSH session. That way, if anything breaks, you're still connected and can fix it.

Summary What I Learned Today

Remote root login is dangerous, I disabled it.
Port 22 is predictable, I moved SSH to a safer port.
Passwords can be brute forced, I switched to SSH keys.
I always test SSH changes before restarting or disconnecting.

Result: My Linux SSH access is now much harder to exploit.

I would love to hear your thoughts, experiences, or tips about Linux!
Feel free to share in the comments and join the conversation.
Connect with me on LinkedIn !

Why Linux Is Secure by Design (But Still Needs You)

Olatunde salami — Wed, 14 May 2025 14:22:55 +0000

Table Of Content

Introduction
What Makes Linux Secure by Design?
Multi-User Architecture
Root vs Regular Users
Permission Based File Access
Minimal Default Services
Open Source Advantage
Summary

Introduction

Welcome to the start of my new series: Linux Security Basics. Over the next few days, I’ll explore how to protect a Linux system from the basics to the essentials every system admin, developer, or enthusiast should know.

We’re starting with a fundamental question:

Why is Linux considered secure by design?

Let’s unpack what makes Linux such a resilient operating system and why "secure by design" ≠ "secure by default."

What Makes Linux Secure by Design?

Linux didn’t become known for its security by accident. Several core principles make Linux a solid choice for both personal and enterprise environments.

1. Multi-User Architecture

From day one, Linux was built for multiple users. That means:

Every user has their own account.
Every file and process belongs to a user.
Regular users cannot access system files or affect other users’ processes.

This separation enforces boundaries that prevent accidental or malicious interference.

2.Root vs Regular Users

Linux uses a strict privilege model:

Root (administrator) has full access.
Normal users have limited access by default.

Commands that modify the system must be run with elevated privileges (e.g., sudo).

This makes it difficult for malware or bad commands to damage the entire system unless you’re running as root (which you shouldn't!).

3.Permission Based File Access

Every file and directory in Linux has:

Owner
Group
Permissions (read, write, execute)

With these controls, you can precisely limit who can access or change files.

Linux follows the principle of least privilege users get only the access they need.

4. Minimal Default Services

Unlike some operating systems that run numerous background services by default, many Linux distros:

Start with only essential services
Let you enable others manually
Offer tools to audit running processes (ps, ss, netstat, etc.)

Fewer services = fewer vulnerabilities = smaller attack surface.

5. Open Source Advantage

Linux is open source, meaning:

Code is publicly available for scrutiny.
Vulnerabilities are often found and fixed quickly.
The community and vendors (like Red Hat, Ubuntu, Debian) actively patch security holes.

Transparency leads to faster response and higher trust.

⚠️ So… Is Linux Automatically Secure?

Not quite.

Linux is secure by design, but not secure by default. For example:

SSH may allow root login unless you configure it.
Firewalls may be inactive unless you enable them.
Software updates are manual unless you schedule them.

Security still requires YOU the user/admin to take action.

That’s what this series is all about.

Summary

Linux’s architecture gives it a strong foundation for security.
Features like user separation, strict permissions, and fewer default services reduce risk.
But you still need to configure, update, and monitor your system actively.
Security is a process, not a checkbox.

I would love to hear your thoughts, experiences, or tips about Linux!
Feel free to share in the comments and join the conversation.
Connect with me on LinkedIn !

Access Unlocked: The Sudo Way

Olatunde salami — Wed, 14 May 2025 12:10:03 +0000

Table Of Content

Introduction
What is sudo?
Why Use sudo?
How to Configure sudo Access
Best Practices
Why Is sudo an Important Command?
Summary

Introduction

One of the core principles of Linux is the separation of standard users and administrative (root) privileges. Today, I explored how to configure sudo access, which allows users to execute commands with elevated privileges safely and securely.

What is sudo?

sudo (short for “superuser do”) is a command line utility that allows a permitted user to execute a command as the superuser or another user, as defined by the security policy.

Rather than logging in as root (which can be dangerous), users can gain temporary administrative access using sudo.

Why Use sudo?

Security: Limits access to sensitive commands.
Auditability: Logs all commands run with sudo for accountability.
Convenience: Avoids full root logins, reducing the risk of system wide mistakes.

How to Configure sudo Access

Add a User to the sudo Group Most Linux distros (like Ubuntu and Debian) use the sudo group to grant sudo privileges.

sudo usermod -aG sudo <username>

Replace with the actual user’s name.

For example, to grant sofia sudo access:

sudo usermod -aG sudo Sofia

To apply the group changes:

su - Sofia

Or have the user log out and back in.

Verify Access Switch to the user and test:

sudo whoami

Expected output:

root

Edit the sudoers File (Safely!) To customize permissions or define more specific rules, use:

sudo visudo

This command opens the /etc/sudoers file in a safe editor that prevents syntax errors.

Example Rule:

Allow a user to run only specific commands:

sofia ALL=(ALL) NOPASSWD: /usr/sbin/service apache2 restart

This allows sofia to restart Apache without a password.

Creating a Sudoers File in /etc/sudoers.d/ For better management, you can create custom sudoers files:

sudo visudo -f /etc/sudoers.d/sofia

Inside the file:

sofia ALL=(ALL) ALL

This method is preferred for organizing permissions per user or group.

Best Practices

Avoid using the root account directly.
Limit sudo access to trusted users only.
Log all sudo usage (by default, it’s stored in /var/log/auth.log).
Use visudo instead of editing /etc/sudoers directly.

Why Is sudo an Important Command?

sudo is one of the most essential tools in Linux system administration. Here’s why:

Security Through Least Privilege:
By default, users operate with limited permissions. sudo ensures that only trusted users can perform sensitive tasks like installing software, modifying system files, or managing services.
Reduces Risk of Damage:
Running as root all the time is dangerous. A single mistyped command can crash the system. sudo limits the time and scope of privileged actions.
Accountability and Logging:
Every sudo action is logged (usually in /var/log/auth.log), allowing administrators to track changes or investigate issues.
Granular Control:
With sudo, you can fine-tune what commands specific users can run ideal in multi user environments.
Promotes Best Practices:
Encourages the principle of “least privilege” by allowing users to elevate privileges only when necessary.

Summary

Today, I learned about the importance of the sudo command in Linux, which allows users to perform administrative tasks securely without logging in as root. I explored how to grant sudo access to users, safely edit the sudoers file, and follow best practices to maintain system security. sudo is a critical tool for privilege management, promoting safety, accountability, and control in multi user environments.

I would love to hear your thoughts, experiences, or tips about Linux!
Feel free to share in the comments and join the conversation.
Connect with me on LinkedIn !

🛡️Understanding and Using Special Permissions in Linux (with Real-Life Analogies)

Olatunde salami — Thu, 08 May 2025 09:01:27 +0000

Table Of Content

Introduction
SUID (Borrowing the Boss's Authority)
SGID (Group Consistency Keeper)
Sticky Bit (Don't Touch My Stuff!)
Numeric Representation of Special Permissions
Security Importance of Special Permissions
Best Practices
Conclusion

Introduction

Have you ever wondered how Linux ensures users can collaborate without stepping on each other's toes or how a regular user can run powerful programs without being given the keys to the whole system?
That's where special permissions come in. These are not your everyday read, write, and execute. These are the VIP badges: SUID, SGID, and the Sticky Bit.

Quick Recap: Standard vs Special Permissions
here’s the usual setup:

r (read): View contents
w (write): Modify contents
x (execute): Run files or access directories
But sometimes, that's not enough...

That's why we have these special permissions that are important in multiuser environments and shared directories.

SUID (Set User ID)
SGID (Set Group ID)
Sticky Bit

1. SUID (Borrowing the Boss's Authority)

SUID (Set User ID) allows users to run a program as if they were the file owner. Commonly, the owner is root.

Real-Life Analogy:
Imagine a guest in a hotel needs to access a restricted floor. Instead of giving them a master key (root access), the elevator (program) temporarily acts as if they are the manager (file owner) just to get them there and only there.

Example:
Check the file's permissions before:

$ ls -l script.sh
-rwxr-xr-x 1 root users 123 May  8 2025 script.sh

The owner is root, and the script is executable (x).

Run the command:

chmod u+s script.sh

Check permissions after:

$ ls -l script.sh
-rwsr-xr-x 1 root users 123 May  8 2025 script.sh

The s in rws indicates the setuid bit is set.

2. SGID (Group Consistency Keeper)

Set Group ID
Purpose

On files: Runs the file with the group ID of the file's group owner.
On directories: Ensures new files/folders inherit the directory's group ownership.

Real-Life Analogy:
You and your coworkers share a project folder. SGID makes sure everything dropped in stays under the same project group, so collaboration is smooth and consistent.

mkdir /shared  
chgrp developers /shared  
chmod g+s /shared

Now anything placed in /shared stays in the developers group.

Set It:

chmod g+s /some/dir

Tip: SGID is your friend when working in /var/www, /projects, or shared Git workspaces.

Listing:

drwxr-sr-x 2 www-data www-data 4096 May 8 10:30 html

3. Sticky Bit (Don't Touch My Stuff!)

Purpose:
Restricts file deletion in a directory so only the file’s owner (or root) can delete or rename files, even if others have write permission.

Real-Life Analogy:
Think of a public bulletin board. Everyone can post notes, but only the original author can take theirs down. That’s the sticky bit.

Set Sticky Bit:

ls -ld /tmp

Output:

drwxrwxrwt 10 root root 4096 May 8 10:30 /tmp

See the t at the end? That’s the sticky bit.

🔧 Set It:
chmod +t /shared-folder
💡 Use this anywhere multiple users need to share space, but still need file safety.

Set Sticky Bit:

chmod +t directory

Example:

drwxrwxrwt 10 root root 4096 May 8 10:30 /tmp

Numeric Representation of Special Permissions

Use octal numbers to combine special permissions with standard ones:

SUID = 4
SGID = 2
Sticky Bit = 1

Examples:

chmod 4755 myscript.sh   # Sets SUID
chmod 2755 shared_folder # Sets SGID
chmod 1777 /tmp          # Sets Sticky Bit

Security Importance of Special Permissions

Special permissions help enforce secure system behavior while allowing necessary flexibility:

SUID allows limited privilege escalation. It ensures that users can run specific programs with higher privileges without granting them full root access. However, misconfigured SUID programs are a common target for attackers to gain unauthorized root access.
SGID ensures group consistency, especially in shared development or collaboration directories. It helps prevent users from accidentally assigning wrong group ownership, which could leak sensitive data or cause privilege issues.
Sticky Bit protects shared directories by preventing users from deleting or renaming each other’s files, which is crucial in directories like /tmp.

Best Practices:

# Audit SUID and SGID files
find / -perm /6000 -type f 2>/dev/null

# Audit Sticky Bit directories
find / -perm /1000 -type d 2>/dev/null

Avoid setting SUID/SGID on scripts, as they are more easily exploited than compiled binaries.
Use special permissions only when necessary and monitor for unauthorized changes.

Conclusion

Special permissions in Linux SUID, SGID, and Sticky Bit are powerful tools for controlling access and behavior in a multi-user environment. They support secure delegation of privileges and controlled collaboration, but they must be used carefully. Misuse or misconfiguration can lead to serious security vulnerabilities. Always apply the principle of least privilege and audit permissions regularly to maintain a secure system.

I would love to hear your thoughts, experiences, or tips about Linux!
Feel free to share in the comments and join the conversation.
Connect with me on LinkedIn !

SSH and OpenSSH Overview: Secure Remote Access for Linux

Olatunde salami — Tue, 06 May 2025 18:43:17 +0000

Table Of Content

Introduction
What is SSH?
What is OpenSSH?
Key Components of OpenSSH
How SSH Works
The Security Importance of SSH
Best Practices for SSH Security
Why SSH Matters for Your Linux Challenge
Conclusion

Introduction

As part of my 30 days Linux challenge, understanding SSH (Secure Shell) and its most popular implementation, OpenSSH, is essential. SSH is a cryptographic network protocol that enables secure communication over an unsecured network, commonly used for remote access to Linux systems. OpenSSH is the open source toolset that brings this protocol to life. This article provides an overview of SSH, OpenSSH, their key features, the critical importance of SSH for security, and practical applications for Linux users.

What is SSH?

SSH is a protocol designed to provide secure, encrypted communication between two systems, typically a client (your local machine) and a server (a remote machine). It was developed in 1995 by Tatu Ylönen as a secure alternative to insecure protocols like Telnet, which transmitted data, including passwords, in plain text. SSH ensures:

Confidentiality: Data is encrypted, preventing eavesdropping.
Authentication: Verifies the identity of both client and server.
Integrity: Ensures data isn’t tampered with during transmission.

SSH is widely used for:

Remote command-line access to servers.
Secure file transfers (via SCP or SFTP).
Tunneling other protocols securely.

What is OpenSSH?

OpenSSH is the most widely used open source implementation of the SSH protocol, maintained by the OpenBSD project. It’s pre installed on most Linux distributions and macOS, making it the go to tool for secure remote administration. OpenSSH supports SSH version 2 (SSH-2), which is the current standard due to its enhanced security over the deprecated SSH-1.

Key Components of OpenSSH

OpenSSH provides several tools, including:

ssh: The client program for connecting to a remote server.
sshd: The SSH daemon running on the server, listening for incoming connections (default port: 22).
scp: A tool for secure file copying between hosts.
sftp: A secure alternative to FTP for file transfers.
ssh-keygen: Generates public private key pairs for authentication.
ssh-agent: Manages private keys for seamless authentication.
ssh-copy-id: Simplifies copying public keys to remote servers.

How SSH Works

SSH operates on a client server model using public key cryptography or password based authentication. Here’s a simplified workflow:

Connection Initiation: The client (your terminal) contacts the server’s SSH daemon (sshd) on port 22.
Key Exchange: The client and server negotiate a session key using algorithms like Diffie-Hellman to encrypt the session.
Authentication: The client authenticates using:
Password: A username and password (less secure, often disabled).
Public-Key: A private key on the client and a matching public key on the server (preferred for security).
Secure Session: Once authenticated, an encrypted session is established for commands, file transfers, or tunneling.

The Security Importance of SSH

SSH is a cornerstone of network security, particularly for Linux systems, due to its ability to protect sensitive data and prevent unauthorized access. Its security features address several critical risks:

Protection Against Eavesdropping:
Unlike older protocols like Telnet or FTP, SSH encrypts all data transmitted between client and server. This ensures that sensitive information, such as passwords, configuration files, or proprietary data, cannot be intercepted by attackers on the same network (e.g., public WiFi).
Mitigation of Man-in-the-Middle Attacks:
SSH uses host key verification to confirm the server’s identity, preventing attackers from impersonating a legitimate server. Public key authentication further strengthens this by ensuring only authorized clients can connect.
Secure Remote Administration:
System administrators often manage servers located in different geographic regions. SSH allows them to execute commands, update software, or troubleshoot issues remotely without exposing credentials or data to potential threats.
Defense Against Brute force Attacks:
By using key based authentication and disabling password logins, SSH significantly reduces the risk of automated brute force attacks, which target weak passwords.
Secure Data Transfers:
Tools like scp and sftp leverage SSH’s encryption to transfer files securely, protecting sensitive data from interception during transit.
Compliance with Security Standards: Many organizations must comply with regulations like GDPR, HIPAA, or PCI DSS, which mandate secure data transmission. SSH’s robust encryption and authentication mechanisms help meet these requirements.

Without SSH, remote access and file transfers would rely on insecure protocols, exposing systems to data breaches, unauthorized access, and other cyber threats. For Linux users, mastering SSH is not just about convenience it’s about safeguarding systems and data in an increasingly connected world.

Setting Up OpenSSH on Linux

For your Linux challenge, here’s how to get started with OpenSSH:
1. Install OpenSSH
Most Linux distributions include OpenSSH by default. To verify or install:

sudo apt update && sudo apt install openssh-client openssh-server  # Ubuntu/Debian
sudo dnf install openssh-clients openssh-server  # Fedora/RHEL

Start and enable the SSH daemon:

sudo systemctl enable sshd
sudo systemctl start sshd

2. Connect to a Remote Server
Use the ssh command to connect:

ssh username@remote_host

Example: ssh user@192.168.1.100

3. Generate SSH Keys
Passwordless authentication with keys is more secure. Generate a key pair:

ssh-keygen -t ed25519 -C "your_email@example.com"

This creates a private key (~/.ssh/id_ed25519) and a public key (~/.ssh/id_ed25519.pub). Copy the public key to the remote server:

ssh-copy-id username@remote_host

Now, you can log in without a password.
4. Secure File Transfer
Copy files securely with scp:

cp file.txt username@remote_host:/path/to/destination

Or use sftp for an interactive session:

sftp username@remote_host

Best Practices for SSH Security

To maximize SSH’s security benefits:

Disable Root Login: Edit /etc/ssh/sshd_config and set PermitRootLogin no.
Change Default Port: Modify Port 22 to a non standard port in sshd_config to reduce automated attacks.
Use Key-Based Authentication: Disable password authentication by setting PasswordAuthentication no in sshd_config.
Enable a Firewall: Use ufw or firewalld to allow only trusted IP addresses.
Keep OpenSSH Updated: Regularly update to patch vulnerabilities.
Monitor Logs: Check /var/log/auth.log or /var/log/secure for suspicious activity.

Why SSH Matters for Your Linux Challenge

Mastering SSH and OpenSSH is a cornerstone of Linux administration. Whether you’re managing a home server, deploying applications, or accessing a cloud instance, SSH provides a secure, reliable way to interact with remote systems. Its security features protect against real-world threats, making it indispensable for both personal and professional use.

Conclusion

SSH, through OpenSSH, is a powerful and essential tool for secure remote access in the Linux ecosystem. Its robust encryption, flexible authentication methods, and versatile utilities make it indispensable for both beginners and advanced users. By emphasizing security, SSH protects systems and data from eavesdropping, unauthorized access, and other threats. Incorporating SSH into your Linux learning will equip you with practical skills for managing systems securely and efficiently.

I would love to hear your thoughts, experiences, or tips about Linux!
Feel free to share in the comments and join the conversation.
Connect with me on LinkedIn !

The Key to Control: Navigating Users, Groups, and Permissions

Olatunde salami — Sun, 04 May 2025 09:59:11 +0000

Table Of Content

Introduction
What Are Users, Groups, and Permissions?
Getting to Know Users
Permissions: Who’s Allowed to Do What?
Groups: The Cool kid's Club
Changing Permissions with chmod
Changing Ownership with chown
Tips for Fellow Beginners
Conclusion

Introduction:

Welcome to Day 8 of my 30 day Linux challenge! Today, I’m treating a topic that's important to navigating linux effectively : users, groups, and permissions. If you’re new to Linux like me, these might feel like a mystery, but they’re the key to keeping your system organized and secure. Think of it as deciding who gets the keys to your Linux house and what rooms they can enter. In this article, I’ll break it down in simple terms, share my learning curve, my awkward mistake, and make it fun so you’ll want to keep reading!

What Are Users, Groups, and Permissions?

Linux is like a big shared apartment building. Users are the people living there (like you or your friend logging in). Groups are like clubs that users can join to share access to certain things. Permissions are the rules about who can open, edit, or delete files and folders. Together, they make sure everyone plays nice and nobody messes with someone else’s stuff.

For example, I’m the main user on my Linux system (let’s call me “Bigtee”), but I can add other users, like “crew,” and put them in groups to share files. Permissions let me decide if “crew” can just look at my files or edit them too.

Getting to Know Users

Every time you log into Linux, you’re using a user account. There’s also a super powerful user called root, who can do anything (like the landlord of the building). To see who you are, open the terminal (Ctrl + Alt + T) and type:

whoami
Bigtee

To see all users on your system, check the /etc/passwd file:

cat /etc/passwd

This lists everyone, including system users (like “nobody” or “daemon”) that Linux uses behind the scenes. Don’t worry about them for now I’m just focusing on my account and maybe a friend’s.

You can add a new user with:

sudo adduser crew

This asks for a password and some details. Now “crew” can log in! I tried this and felt like I was hiring a new teammate for my Linux adventure.

Groups: The Cool kid's Club

Groups make sharing easier. Imagine you have a folder of project files you want to share with “crew” but not everyone. You put you and “crew” in a group called “team.” To see what groups you’re in, type:

groups
Bigtee team

To create a group:

sudo groupadd team

To add someone to it:

sudo usermod -aG team crew

Now “crew” is in the “team” group! I messed up once by forgetting the -a flag and kicked myself out of my own group lesson learned!

Permissions: Who’s Allowed to Do What?

Permissions are where the fun happens. Every file and folder has rules about who can read (look at it), write (edit it), or execute (run it, like a script). To see permissions, use:

ls -l
-rw-r--r-- 1 Bigtee team 123 may 4 12:00 notes.txt
drwxr-xr-x 2 Bigtee team 4096 may 4 12:00 project

That string of letters (-rw-r--r-- or drwxr-xr-x) is the permission code. Here’s the breakdown:

First character: - means it’s a file, d means it’s a folder.
Next three: Permissions for the owner (e.g., rw- means Bigtee can read and write but not execute).
Middle three: Permissions for the group (e.g., r-- means team can only read).
Last three: Permissions for everyone else (e.g., r-- means others can read).

So, for notes.txt, I (Bigtee) can read and edit it, the “team” group can only read it, and so can everyone else. For the “project” folder, I can do everything, but “team” and others can only look inside and run stuff.

Changing Permissions with chmod

If I want to let “team” edit notes.txt, I change its permissions with chmod (change mode):

chmod g+w notes.txt

Now the group has write access. Check it with ls -l:

-rw-rw-r-- 1 Bigtee team 123 Oct 10 12:00 notes.txt

You can also use numbers, like chmod 664 notes.txt, where:

6 = read (4) + write (2) for owner and group.
4 = read for others.

I accidentally made a file executable once (chmod +x) and wondered why it wouldn’t run, turns out it wasn’t a script.

Changing Ownership with chown

If I want “crew” to own notes.txt instead of me, I use chown (change owner):

sudo chown crew notes.txt

To give it to the “team” group:

sudo chown :team notes.txt

I tried this and got confused when permissions didn’t work as expected, i figured I forgot to check the group settings. Always double check!
When I started this topic, I thought permissions would be boring, but it’s like playing gatekeeper for my files! I set up a “crew” user and a “team” group, shared a folder, and felt like a Linux boss. My big oops was changing permissions on a folder and locking myself out thankfully, sudo saved me. The terminal commands (chmod, chown) are starting to feel like second nature, and I’m getting better at spotting mistakes.

Tips for Fellow Beginners

Start Small:Create a test user and group to practice without risking your main files.
Check Before You Change:Use ls -l to see permissions before messing with chmod or chown.
Use sudo Wisely: It’s powerful but can cause chaos if you’re not careful.
Write It Down:I keep a notebook with commands like chmod g+w so I don’t forget.
Have Fun:Pretend you’re running a secret club it makes permissions way more exciting!

Conclusion

Users, groups, and permissions are like the rules of a Linux party who’s invited, who’s in the VIP group, and what they’re allowed to do. As a beginner, I’m fascinated to understand how to keep my system secure and share files like a pro. This Day 8 challenge has me pumped to explore more Linux tricks. If I can figure this out, so can you! Open that terminal, play with some permissions, and let’s keep rocking this Linux journey together.

I’d love to hear your thoughts, experiences, or tips about Linux!
Feel free to share in the comments and join the conversation.
Connect with me on LinkedIn !

Command Prompt, the Magical Wand of Linux !

Olatunde salami — Sat, 03 May 2025 06:52:15 +0000

Table Of Content

Introduction
What is This Magical Wand?
Essential Commands for Beginners
Tips That Saved Me
My Experience and Challenges
Conclusion

Introduction:

Welcome to my 30 days Linux challenge, where I’m waving the magical wand of Linux the command prompt, or as we cool kids call it, the terminal! If you’ve ever stared at that blinking cursor like it’s a cryptic riddle, don’t worry. This wand might not shoot sparkles like Harry Potters wand, but it casts powerful spells to bend Linux to your will. In this article, I’ll share my journey mastering the terminal, sprinkle some humor to keep you enchanted, and teach you the incantations (aka commands) to wield this magic like a Linux wizard.

What is This Magical Wand?

The command prompt is Linux’s spell book, a text based interface where you type commands to make things happen. Want to summon a file? Need to banish a folder? Abracadabra! Unlike point and click GUIs, the terminal gives you raw, unfiltered control over your system. It’s not like clicking icons it’s more like casting spells to make stuff happen fast.
To open the terminal, press Ctrl + Alt + T (works on most Linux versions like Ubuntu or Fedora) or search for “Terminal” in your apps. You’ll see something like::

user@hostname:~$

That $ means you’re a regular user. A # means you’re the all-powerful root wizard, Be careful with great power, you could accidentally break your system!

Essential Commands for Beginners

Here are my favourite commands that I’ve been practicing, with examples to help you try them too. I’ve made some mistakes, but that’s how I’m learning!

1. Navigating the File System

pwd (Print Working Directory): Shows where you are in your computer’s folders. It’s like a map when you’re lost.

pwd
/home/user

ls (List): Lists files and folders in your current spot. text

ls
documents  downloads  music  spellbook.txt  potions

Try ls -l for more details or ls -a to see hidden files.

cd (Change Directory): Teleports you to another realm

cd documents

To go back one folder, use cd ... It’s like hitting the back button.

2. Managing Files and Directories

mkdir (Make Directory): Creates a new directory.

mkdir my_project

means create a directory called my_project

touch: Creates an empty file.

touch notes.txt

cp (Copy): Copies files or directories.

cp notes.txt notes_backup.txt

means copy notes.txt

mv (Move): Moves or renames files.

mv notes.txt documents/notes.txt

rm (Remove): Deletes files or directories (use with caution!).

rm notes_backup.txt

3.Viewing and Editing Files

cat: Displays file contents.

cat notes.txt

less:Views large files one page at a time.

less long_file.txt

Press q to quit.

nano: A beginner-friendly text editor.

nano notes.txt

Save with Ctrl + O, exit with Ctrl + X

4. System Information

whoami : Shows your username.

whoami
user

df -h: Displays disk space usage in a human-readable format.

df -h

free -h: Shows memory usage.

free -h

5. Permissions and Ownership(Keeping My Files Safe)

chmod: Changes file permissions.(Controls who can use my files)

chmod u+x script.sh

This makes script.sh executable for the user.

chown: Gives a file to someone else (like sharing a toy)

sudo chown user2 file.txt

Tips That Saved Me

Press Tab: If I start typing a command or file name and hit Tab, the terminal finishes it for me. It’s like magic!
Use man: Typing man ls shows a guide for any command. It’s a bit boring but super helpful.
Try Pipes(|): I can mix commands, like ls | grep txt to find only text files.
Be Careful: I almost deleted something important with rm. Now I double-check everything.
Make Shortcuts : I added this to my ~/.bashrc file to make ls -l just ll:

alias ll='ls -l'

My Experience and Challenges

This 30day challenge has been wild. The first time I typed ls and felt like a hacker. I remember when i accidentally deleted a file with rm and just sat there looking for the file, until I figured that I had deleted it earlier .
But by Day 7, I am moving through folders and editing files with _nano _like it was no big deal. The terminal is picky if you misspell something, it won’t work but it’s teaching me to pay attention. Finding man pages was like discovering a secret library, and now I’m hooked.

Conclusion

Making command prompt my new best friend in Linux has helped me. It’s not as scary as it looks, and with a few commands, 1 can do so much! I’m still a beginner, but I’m excited to keep going in my 30day challenge. I’m excited and looking to explore advanced topics to automate stuff. If you’re new to Linux , embrace the terminal it’s your key to unlocking the power of Linux!

I’d love to hear your thoughts, experiences, or tips about Linux!
Feel free to share in the comments and join the conversation.
Connect with me on LinkedIn !

Taming the Daemons: Mastering Service Control with systemd

Olatunde salami — Thu, 01 May 2025 16:14:46 +0000

As a newcomer to Linux, one of the most empowering skills you can learn is managing system services. Whether you're starting a web server, scheduling a backup, or running a database, understanding how to control these services is key. In Linux, systemd is the tool that makes this possible.

Index

What is systemd?
Why You need to Manage Services?
What Preceded systemd?
Mastering systemctl
Troubleshooting Tips
Summary

What is systemd?

systemd is a system and service manager for Linux. It’s responsible for starting, stopping, and managing background processes (called services or daemons) that keep your system running. Think of it as the conductor of an orchestra, ensuring all parts of your Linux system like networking, logging, or web servers work together smoothly.
Unlike older systems, systemd is fast, efficient, and widely adopted by distributions like Ubuntu, Fedora, and Debian. As a beginner, learning systemd gives you control over your system’s behavior, from booting up to running critical applications.

Why You need to Manage Services?

Services are programs that run in the background to perform essential tasks. For example:

nginx or apache2 for hosting websites.
sshd for remote access via SSH.
cron for scheduling tasks.

By managing services, you can:

Start or stop them as needed.
Ensure they run automatically at boot.
Troubleshoot issues when something goes wrong.

All these are necessary in managing your linux service

What Preceded systemd?

Before systemd and its systemctl command became the standard for managing services, Linux used other tools to handle system startup and services. Here’s a quick look at the main ones:

SysVinit: The classic system, using shell scripts in /etc/init.d/ to start or stop services. It was simple but slow, as services started one at a time.
Upstart: Developed by Ubuntu, this event-driven system was faster and more flexible, using config files in /etc/init/ to manage services.
OpenRC: A lightweight tool, popular in Gentoo, that combined scripts with better dependency handling for faster startups.

These tools worked but lacked systemd’s speed, advanced features, and unified control, which is why most Linux systems switched to systemd starting around 2010.

Mastering systemctl:

Essential Commands for System Service Control
These systemctl command lets you control services. You’ll often need to run these commands with sudo because managing services requires administrative privileges. Below are the most common tasks you’ll perform as a beginner.

1. Checking a Service’s Status
To see if a service is running, use the status command. For example, to check the status of the SSH service (sshd):

sudo systemctl status sshd

This shows:

Whether the service is active (running), inactive, or failed.
Recent logs to help diagnose issues.
The service’s process ID (PID).

If you see “active (running),” the service is up and working!

2. Starting and Stopping a Service
To start a service, use:

sudo systemctl start sshd

To stop it:

sudo systemctl stop sshd

For example, if you’re testing a web server like Nginx, you might stop it to free up resources or start it to serve a website. These commands only affect the service’s current state—they don’t change what happens at boot.

3. Enabling and Disabling Services at Boot
Want a service to start automatically when your system boots? Use:

sudo systemctl enable sshd

This ensures the SSH service is always ready when your system starts. To disable autostart:

sudo systemctl disable sshd

Disabling a service doesn’t stop it immediately it just prevents it from starting at boot.

4. Restarting or Reloading a Service
Sometimes, you need to restart a service to apply changes. Use:

sudo systemctl restart sshd

This stops and then starts the service. If the service supports reloading (applying changes without stopping), you can use:

sudo systemctl reload sshd

Reloading is gentler, as it doesn’t interrupt active connections.

5. Listing All Services

To see all services on your system, run:

systemctl list-units --type=service

To see only services set to start at boot, use:

systemctl list-unit-files --type=service --state=enabled

These commands help you explore what’s running on your system and understand its components.

## Troubleshooting Tips
If a service isn’t working:

Check its status: sudo systemctl status .
Look at logs: journalctl u .
Ensure the service is enabled if it needs to start at boot: systemctl is enabled .

If you’re stuck, searching online for the error message (from logs or status) often points to solutions. Linux communities on forums like Stack Exchange are great resources.

Summary

Learning systemd is a gateway to mastering Linux. It gives you control over critical system components, from web servers to databases. As you grow, you’ll use systemd to create custom services, optimize boot times, and manage complex setups. For now, mastering systemctl commands like start, stop, enable, and status is a solid foundation.

I’d love to hear your thoughts, experiences, or tips about Linux!
Feel free to share in the comments and join the conversation.
Connect with me on LinkedIn !

DEV Community: Olatunde salami

Monitoring Users and Login Activity (with last, w, who)

Index

Why Monitor User Activity? A SysAdmin’s Wake-Up Call

Command 1: last - Review Login History

Real-Life Use Case: Investigating a Breach

Step 1: Run last

Step 2: Narrow Down with Options

Command 2: w - Who’s Online Right Now?

Real-Life Use Case: Spotting Suspicious Activity in Real Time

Step 1: Run w

Step 2: Take Action

Command 3: who - A Quick Snapshot of Logged-In Users

Real-Life Use Case: Routine Checks for a Shared Server

Step 1: Run who

Step 2: Add Details with Options

Best Practices: Keeping Your System Safe

Troubleshooting: False Alarms and Missed Intruders

What’s Next?

30DaysLinuxChallenge #CloudWhistler #RedHat #CloudSecurity #DevOps #Linux #OpenSource #CloudComputing #RedHatEnterpriseLinux #SystemLogs #EnterpriseIT #Observability #Logging #SysAdmin #Automation #CloudEngineer #TechForBusiness #ITSupport #SRE #CloudOps

Simple Firewall with ufw or firewalld

Index

Why Use a Firewall?

Choosing Between ufw and firewalld

Setting Up a Firewall with ufw

1. Check Status

2. Enable ufw

3. Allow Essential Services

4. Deny Unwanted Traffic

5. Set Default Policies

6. Verify and Apply

Setting Up a Firewall with firewalld

1. Check Status

2. Enable firewalld

3. Allow Services

4. Add Custom Ports

5. Reload Rules

6. Check Rules

Best Practices

Troubleshooting

What’s Next?

Hardening File Permissions: Practical Steps to Lock Down Data

Index

Why File Permissions Matter

Understanding Linux File Permissions

Practical Steps to Harden File Permissions

1. Audit Existing Permissions

2. Set Secure Permissions for Sensitive Files

3. Harden Home Directories

4. Secure Directories with Sticky Bits

5. Use chown to Correct Ownership

6. Find and Fix Risky Permissions

7. Automate with a Script

Best Practices

Using Fail2Ban to Protect Against Brute Force Attacks

Table Of Content

Introduction

Why Fail2Ban?

Step 1: Installing Fail2Ban

Step 2: Configuring Fail2Ban

What’s Happening Here?

Step 3: Testing Your Setup

Step 4: Protecting Other Services

Step 5: Monitoring and Fine Tuning

Wrapping Up: Stay One Step Ahead

Summary

Fortify Your SSH: Lock Out Root, Shift Ports, Key In Security.

Table Of Content

Introduction

Why SSH Needs Protection

1. Disable Root Login

2. Change the Default SSH Port

3. Set Up Key-Based Authentication

🧩 Step-by-Step:

Bonus: Test Before Locking Yourself Out

Summary What I Learned Today

Why Linux Is Secure by Design (But Still Needs You)

Table Of Content

Introduction

What Makes Linux Secure by Design?

Command 1: `last` - Review Login History

Step 1: Run `last`

Command 2: `w` - Who’s Online Right Now?

Step 1: Run `w`

Command 3: `who` - A Quick Snapshot of Logged-In Users

Step 1: Run `who`

5. Use `chown` to Correct Ownership