Linux for Cybersecurity Beginners: Filesystem, Commands, Permissions and Logs
Plain-English notes on the Linux skills security analysts use every day: finding your way around the filesystem, essential commands, chmod with worked examples, users and groups, and reading authentication logs with grep. Ends with 15 hands-on practice tasks and solutions.
Independent study aid. Not affiliated with or endorsed by Google or Coursera. All explanations, examples and practice tasks are original. Confirm current course content on the official Coursera page.
1. Why security work depends on Linux
Most servers, cloud workloads, network appliances and security tools run Linux. As an analyst you will read logs, check who has access to what, search for suspicious activity and run tools from a terminal. Knowing a small set of commands well beats knowing many commands badly.
Where to practise
Use a virtual machine, not your main computer. See the home lab setup guide.
Core idea
Everything is a file, every file has an owner and permissions, and every action leaves a trail in the logs.
Study tip
Type every command yourself. Reading is not enough; muscle memory is the goal.
Safety: run the practice tasks in a lab VM. Commands that use sudo change the system. Always check a command before pressing Enter, especially anything containing rm.
2. Filesystem layout
Linux has one tree that starts at / (called “root”, not to be confused with the root user). Directories follow a common convention described in the Filesystem Hierarchy Standard, though distributions vary slightly.
| Path | What lives there | Why a security analyst cares |
|---|---|---|
/ | Top of the tree | Everything is below this point |
/home | Personal folders for each user | User files, shell history, hidden config files |
/root | Home folder of the root user | Should be tightly protected |
/etc | System configuration files | Accounts, services, SSH settings, scheduled jobs. Attackers like to change these. |
/var/log | Log files | Main place to investigate activity |
/tmp | Temporary files, writable by everyone | Common place for malware to drop files |
/bin, /usr/bin | Programs and commands | Altered binaries can signal compromise |
/sbin, /usr/sbin | Administration programs | Tools usually run with elevated rights |
/opt | Optional or third-party software | Where tools such as Splunk are often installed |
/dev | Device files | Disks, terminals and other hardware appear as files |
/proc | Live view of running processes and kernel data | Inspect processes without extra tools |
/boot | Files needed to start the system | Changes here deserve attention |
/mnt, /media | Mount points for extra drives | External drives and network shares |
Absolute vs relative paths: an absolute path starts at / (for example /etc/passwd). A relative path starts from where you are now (for example notes/day1.txt). The shortcuts ~ (your home), . (here) and .. (one level up) save typing.
3. Essential commands
Moving around and looking
| Command | Does | Example |
|---|---|---|
pwd | Shows your current directory | pwd |
ls | Lists files. -l long, -a hidden, -h readable sizes | ls -lah |
cd | Changes directory | cd /var/log |
cat | Prints a whole file | cat /etc/hostname |
less | Scrolls through a file (q to quit, /word to search) | less /var/log/syslog |
head / tail | First or last lines. tail -f follows new lines live | tail -n 20 file.log |
file | Identifies what type a file really is | file download.bin |
man | Opens the manual for a command | man grep |
Online manuals are also available at man7.org.
Creating, copying, moving and deleting
| Command | Does | Example |
|---|---|---|
mkdir | Makes a directory. -p makes parents too | mkdir -p lab/notes |
touch | Creates an empty file or updates its timestamp | touch a.txt |
cp | Copies. -r for directories | cp a.txt b.txt |
mv | Moves or renames | mv b.txt c.txt |
rm | Deletes. There is no recycle bin | rm c.txt |
rmdir | Deletes an empty directory | rmdir notes |
Be careful with rm -r. It deletes a directory and everything inside it with no confirmation. Double-check the path, and never combine it with sudo unless you are certain.
Searching and processing text
| Command | Does | Example |
|---|---|---|
grep | Finds lines matching a pattern | grep "error" app.log |
find | Searches for files by name, type, owner, age | find /home -name "*.txt" |
wc -l | Counts lines | wc -l app.log |
sort | Sorts lines | sort names.txt |
uniq -c | Counts repeated adjacent lines (sort first) | sort names.txt | uniq -c |
cut | Extracts columns | cut -d: -f1 /etc/passwd |
awk | Pulls out fields from lines | awk '{print $1}' file |
Pipes: the | symbol sends the output of one command into the next. Redirects: > writes output to a file (overwriting it) and >> appends. Chaining small commands is the secret of fast log analysis.
cut -d: -f1 /etc/passwd | sort | head -n 5
Processes, system information and privilege
| Command | Does |
|---|---|
whoami | Shows your current username |
id | Shows your user ID and group memberships |
ps aux | Lists running processes |
top | Live view of processes (q to quit) |
uname -a | Shows kernel and system details |
df -h / du -sh | Disk space overall / size of a folder |
ip a | Shows network interfaces and addresses |
sudo | Runs one command with administrator rights |
history | Shows previous commands |
Principle of least privilege: work as a normal user and use sudo only for the single command that needs it. Staying logged in as root makes mistakes and attacks far more damaging.
4. File permissions and chmod
How to read permissions
Run ls -l and you will see lines like this:
-rwxr-xr-- 1 maya analysts 482 Oct 2 09:10 backup.sh
| Part | Value | Meaning |
|---|---|---|
| First character | - | Type: - file, d directory, l link |
| Next three | rwx | Owner (user) permissions |
| Middle three | r-x | Group permissions |
| Last three | r-- | Everyone else (others) |
| Owner / group | maya analysts | The file’s owning user and group |
| Letter | On a file | On a directory | Number |
|---|---|---|---|
r read | View contents | List names inside | 4 |
w write | Change contents | Create, rename or delete items inside | 2 |
x execute | Run as a program | Enter the directory (cd) | 1 |
Numeric method: add the numbers for each group. rwx = 4+2+1 = 7, r-x = 4+0+1 = 5, r-- = 4, rw- = 6, --- = 0. Three digits give owner, group and others.
Seven worked examples
Example 1: Decode a mode
-rw-r--r-- → owner 6 (rw-), group 4 (r–), others 4 (r–) → 644. A typical setting for a normal document: owner edits, everyone else reads.
Example 2: Make a script runnable
chmod 755 backup.sh
ls -l backup.sh
Result: -rwxr-xr-x. Owner has full control; group and others can read and run it but not change it.
Example 3: Lock down a private file
chmod 600 secret.txt
Result: -rw-------. Only the owner can read or write. Use this pattern for private keys and notes with sensitive data.
Example 4: Symbolic mode, add one permission
chmod u+x run.sh
u = owner, g = group, o = others, a = all. + adds, - removes, = sets exactly. This adds execute for the owner and leaves everything else alone.
Example 5: Remove access for others
chmod go-rwx private.txt
Removes read, write and execute from group and others in one step.
Example 6: Directory permissions
chmod 700 ~/lab-private
Only the owner can list, enter or change the directory. If a directory lacks x for you, you cannot cd into it even if you can see its name.
Example 7: Why 777 is a red flag
chmod 777 gives everyone read, write and execute. Any user or compromised program could change or replace the file. In an audit, world-writable files and directories are worth investigating. Find them in your lab like this:
find ~ -type f -perm -002
The command lists regular files under your home that others can write to.
Changing ownership: sudo chown maya:analysts file.txt sets user and group. sudo chgrp analysts file.txt changes only the group. Add -R to apply to a directory tree, and use it with care.
5. Users and groups
Every account has a numeric user ID (UID), and every user belongs to at least one group (GID). Permissions are checked against these. UID 0 is root, the all-powerful account.
Where account data lives
| File | Holds | Who can read it |
|---|---|---|
/etc/passwd | Account list: name, UID, GID, home, shell | Everyone (it holds no password hashes) |
/etc/shadow | Password hashes and ageing settings | Root only (and privileged system groups) |
/etc/group | Groups and their members | Everyone |
/etc/sudoers | Who may use sudo | Root. Edit only with visudo |
A line in /etc/passwd looks like this, with fields split by colons:
analyst1:x:1002:1002::/home/analyst1:/bin/bash
Fields: username, password placeholder (x means the hash is in shadow), UID, GID, optional comment, home directory, login shell.
Managing users and groups (lab VM only)
sudo useradd -m -s /bin/bash analyst1 # create user with a home folder
sudo passwd analyst1 # set a password
sudo groupadd soc-team # create a group
sudo usermod -aG soc-team analyst1 # add user to the group
id analyst1 # confirm membership
groups analyst1 # list the user's groups
sudo usermod -L analyst1 # lock the account
sudo userdel -r analyst1 # delete user and home folder
- Important: in
usermod -aG, the-ameans append. Without it, the user is removed from every other supplementary group. - On Ubuntu and Kali, members of the
sudogroup can usesudo. Other distributions may use a group calledwheel. - Group changes apply at the next login.
- Security habits: one account per person, strong passwords, remove accounts when people leave, and review the members of the sudo group regularly.
6. Reading authentication logs with grep
Authentication logs record logins, failed attempts and use of sudo. On Debian-based systems such as Ubuntu and Kali they are usually in /var/log/auth.log. On Red Hat-style systems the file is /var/log/secure. Some systems store logs only in the journal, which you read with journalctl. Reading these logs normally needs sudo.
Sample log you can practise on
This is invented data using reserved example addresses. Each line holds a timestamp, host name, the program that wrote it, and a message.
Oct 2 09:14:01 labvm sshd[1201]: Failed password for invalid user admin from 203.0.113.45 port 52114 ssh2
Oct 2 09:14:05 labvm sshd[1203]: Failed password for invalid user admin from 203.0.113.45 port 52120 ssh2
Oct 2 09:14:09 labvm sshd[1205]: Failed password for root from 203.0.113.45 port 52131 ssh2
Oct 2 09:20:44 labvm sshd[1230]: Accepted password for maya from 198.51.100.7 port 40022 ssh2
Oct 2 09:31:12 labvm sudo: maya : TTY=pts/0 ; PWD=/home/maya ; USER=root ; COMMAND=/usr/bin/apt update
Oct 2 09:45:30 labvm sshd[1260]: Failed password for maya from 198.51.100.7 port 40100 ssh2
Oct 2 10:02:18 labvm sshd[1288]: Failed password for invalid user test from 192.0.2.99 port 33000 ssh2
Oct 2 10:02:22 labvm sshd[1290]: Failed password for invalid user test from 192.0.2.99 port 33004 ssh2
grep patterns that matter
| Goal | Command | Meaning |
|---|---|---|
| Find failed logins | grep "Failed password" sample.log | Lines containing that phrase |
| Count them | grep -c "Failed password" sample.log | Number of matching lines (6 here) |
| Ignore case | grep -i "failed" sample.log | Matches Failed, FAILED, failed |
| Exclude lines | grep -v "Failed" sample.log | Everything that does not match |
| Show line numbers | grep -n "Accepted" sample.log | Helps you locate the line again |
| Context | grep -A 2 -B 2 "Accepted" sample.log | Two lines after and before |
| Either word | grep -E "Accepted|sudo" sample.log | Extended pattern with OR |
| Only invalid users | grep "invalid user" sample.log | Attempts for accounts that do not exist |
Worked investigation: who is guessing passwords?
Step 1: Count failures.
grep -c "Failed password" sample.log
Answer: 6.
Step 2: Pull out the source addresses. The -o option prints only the matched part, and the pattern describes four groups of digits:
grep "Failed password" sample.log | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}'
Step 3: Count per address. Sort first so identical lines sit together, then count them, then sort by count:
grep "Failed password" sample.log | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort | uniq -c | sort -nr
Expected output:
3 203.0.113.45
2 192.0.2.99
1 198.51.100.7
Step 4: Interpret. Address 203.0.113.45 failed three times in eight seconds, including attempts for admin and root. That speed and the invalid user names point to automated guessing. Address 198.51.100.7 logged in successfully, then failed once, which looks like a normal typo. The signal is the pattern, not the single line.
Step 5: Report. Write what you saw, the time window, the counts and your recommended action (for example, block the address, disable password login for SSH, or enable rate limiting).
Spotting a successful login right after repeated failures from the same address is the pattern to look for. It may mean the guessing worked.
Useful extras for real systems
sudo grep "Failed password" /var/log/auth.log | tail -n 20
sudo tail -f /var/log/auth.log
sudo journalctl -u ssh --since "1 hour ago"
last -n 10
sudo lastb -n 10
tail -fshows new lines as they arrive. PressCtrl+Cto stop.- The SSH service unit is called
sshon Debian-based systems andsshdon many others. lastshows recent logins, andlastbshows failed ones if the system records them.- Rotated logs are renamed (for example
auth.log.1) and older ones may be compressed. Usezgrepto search compressed files.
7. 15 practice tasks with solutions
Do these in a lab VM. Try each task before opening the solution. First, set up the practice area and sample data by pasting this whole block into your terminal:
mkdir -p ~/linux-practice && cd ~/linux-practice
cat > sample.log << 'EOF'
Oct 2 09:14:01 labvm sshd[1201]: Failed password for invalid user admin from 203.0.113.45 port 52114 ssh2
Oct 2 09:14:05 labvm sshd[1203]: Failed password for invalid user admin from 203.0.113.45 port 52120 ssh2
Oct 2 09:14:09 labvm sshd[1205]: Failed password for root from 203.0.113.45 port 52131 ssh2
Oct 2 09:20:44 labvm sshd[1230]: Accepted password for maya from 198.51.100.7 port 40022 ssh2
Oct 2 09:31:12 labvm sudo: maya : TTY=pts/0 ; PWD=/home/maya ; USER=root ; COMMAND=/usr/bin/apt update
Oct 2 09:45:30 labvm sshd[1260]: Failed password for maya from 198.51.100.7 port 40100 ssh2
Oct 2 10:02:18 labvm sshd[1288]: Failed password for invalid user test from 192.0.2.99 port 33000 ssh2
Oct 2 10:02:22 labvm sshd[1290]: Failed password for invalid user test from 192.0.2.99 port 33004 ssh2
EOF
Task 1. Show your current directory and list everything in it, including hidden files, with sizes people can read.
pwd
ls -lah
You should see sample.log. Hidden items start with a dot.
Task 2. Create the directories reports/2026/october in one command.
mkdir -p reports/2026/october
-p creates every missing parent. Check with ls -R reports.
Task 3. Copy sample.log to reports/2026/october/ as auth-copy.log, then confirm it exists.
cp sample.log reports/2026/october/auth-copy.log
ls -l reports/2026/october
Always work on a copy of evidence, never the original.
Task 4. Show only the first 3 lines and the last 2 lines of sample.log.
head -n 3 sample.log
tail -n 2 sample.logTask 5. Find every .log file under your practice folder.
find ~/linux-practice -name "*.log"
Two results: sample.log and the copy from Task 3.
Task 6. Create report.sh containing one line (echo "hello"), then set it to 755 and run it.
echo 'echo "hello"' > report.sh
chmod 755 report.sh
./report.sh
It prints hello. The ./ tells the shell to run the file in the current directory.
Task 7. Create private.txt and make it readable and writable only by you, using symbolic mode, starting from any permissions.
touch private.txt
chmod u=rw,go= private.txt
ls -l private.txt
Result: -rw-------. The empty value after go= clears all group and others permissions.
Task 8. A file shows -rwxr-x---. Give the numeric mode and say who can do what.
750. Owner: read, write, execute. Group: read and execute. Others: nothing.
Task 9. Create a lab user analyst1 with a home directory and confirm the account exists.
sudo useradd -m -s /bin/bash analyst1
id analyst1
grep analyst1 /etc/passwd
Set a password with sudo passwd analyst1 if you want to log in as that user.
Task 10. Create a group soc-team, add analyst1 to it without removing other groups, and verify.
sudo groupadd soc-team
sudo usermod -aG soc-team analyst1
id analyst1
The output should list soc-team among the groups. Clean up when finished: sudo userdel -r analyst1 and sudo groupdel soc-team.
Task 11. Count how many failed password lines are in sample.log.
grep -c "Failed password" sample.log
Answer: 6.
Task 12. Show only the lines that are not failed logins, with line numbers.
grep -vn "Failed" sample.log
You should see line 4 (accepted login) and line 5 (sudo use).
Task 13. List the unique source IP addresses of failed logins, ranked by number of attempts.
grep "Failed password" sample.log | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort | uniq -c | sort -nr
Expected: 203.0.113.45 (3), 192.0.2.99 (2), 198.51.100.7 (1).
Task 14. How many failed attempts were for accounts that do not exist? Which user names were tried?
grep -c "invalid user" sample.log
grep "invalid user" sample.log | awk '{print $10}' | sort | uniq -c
Four attempts: admin twice and test twice. In these lines the user name is the tenth field, so $10 works. Field positions can differ between log formats, so always check a line first.
Task 15. Save a short findings file called findings.txt with the top attacker address and the count of failed logins, then check the permissions are 600.
{ echo "Top failed-login source:"; grep "Failed password" sample.log | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort | uniq -c | sort -nr | head -n 1; echo "Total failed logins:"; grep -c "Failed password" sample.log; } > findings.txt
chmod 600 findings.txt
cat findings.txt
ls -l findings.txt
The file should show 203.0.113.45 with 3 attempts and a total of 6, with mode -rw-------. Findings often include sensitive details, so restrict access.
8. Common mistakes
- Using
chmod 777to “fix” a problem. Find the real cause and grant only what is needed. - Forgetting
-ainusermod -aG. The user loses their other groups. - Running
uniqwithoutsort. It only collapses neighbouring duplicates. - Editing original logs. Copy evidence and work on the copy.
- Overwriting with
>by accident. Use>>when you mean to append. - Staying logged in as root. Use a normal account and
sudoonly when needed. - Assuming one log location. Check your distribution; use
/var/log/secureorjournalctlwhere appropriate. - Treating one failed login as an attack. Look at volume, speed, user names and what happens next.
- Mistyping paths in destructive commands. Run
lson the path first, thenrm.
9. YouTube search links
- Linux command line for beginners
- Linux filesystem hierarchy explained
- chmod and file permissions explained
- Linux users and groups
- Analysing auth logs with grep
10. One-screen revision summary
- Filesystem: one tree from
/; configuration in/etc, logs in/var/log, user files in/home, temporary files in/tmp. - Core commands:
pwd ls cd cat less head tail find grep mkdir cp mv rm. Use pipes to chain them. - Permissions: r=4, w=2, x=1; three digits for owner, group, others. 644 for documents, 755 for scripts, 600 for private files, avoid 777.
- Symbolic chmod: who (
u g o a), action (+ - =), permission (r w x). - Users:
/etc/passwdlists accounts,/etc/shadowholds hashes,usermod -aGadds groups safely. - Least privilege: normal account first,
sudofor single commands. - Auth logs:
grep "Failed password", then extract IPs,sort | uniq -c | sort -nr, then interpret the pattern. - Evidence habits: work on copies, record commands, report findings clearly.
11. What you should be able to do
Related pages
Educational summary for learners; not affiliated with Google or Coursera. Commands and file locations vary by Linux distribution, so verify details in your system’s manual pages. Last reviewed: October 2026.
