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.

    PathWhat lives thereWhy a security analyst cares
    /Top of the treeEverything is below this point
    /homePersonal folders for each userUser files, shell history, hidden config files
    /rootHome folder of the root userShould be tightly protected
    /etcSystem configuration filesAccounts, services, SSH settings, scheduled jobs. Attackers like to change these.
    /var/logLog filesMain place to investigate activity
    /tmpTemporary files, writable by everyoneCommon place for malware to drop files
    /bin, /usr/binPrograms and commandsAltered binaries can signal compromise
    /sbin, /usr/sbinAdministration programsTools usually run with elevated rights
    /optOptional or third-party softwareWhere tools such as Splunk are often installed
    /devDevice filesDisks, terminals and other hardware appear as files
    /procLive view of running processes and kernel dataInspect processes without extra tools
    /bootFiles needed to start the systemChanges here deserve attention
    /mnt, /mediaMount points for extra drivesExternal 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
    CommandDoesExample
    pwdShows your current directorypwd
    lsLists files. -l long, -a hidden, -h readable sizesls -lah
    cdChanges directorycd /var/log
    catPrints a whole filecat /etc/hostname
    lessScrolls through a file (q to quit, /word to search)less /var/log/syslog
    head / tailFirst or last lines. tail -f follows new lines livetail -n 20 file.log
    fileIdentifies what type a file really isfile download.bin
    manOpens the manual for a commandman grep

    Online manuals are also available at man7.org.

    Creating, copying, moving and deleting
    CommandDoesExample
    mkdirMakes a directory. -p makes parents toomkdir -p lab/notes
    touchCreates an empty file or updates its timestamptouch a.txt
    cpCopies. -r for directoriescp a.txt b.txt
    mvMoves or renamesmv b.txt c.txt
    rmDeletes. There is no recycle binrm c.txt
    rmdirDeletes an empty directoryrmdir 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
    CommandDoesExample
    grepFinds lines matching a patterngrep "error" app.log
    findSearches for files by name, type, owner, agefind /home -name "*.txt"
    wc -lCounts lineswc -l app.log
    sortSorts linessort names.txt
    uniq -cCounts repeated adjacent lines (sort first)sort names.txt | uniq -c
    cutExtracts columnscut -d: -f1 /etc/passwd
    awkPulls out fields from linesawk '{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
    CommandDoes
    whoamiShows your current username
    idShows your user ID and group memberships
    ps auxLists running processes
    topLive view of processes (q to quit)
    uname -aShows kernel and system details
    df -h / du -shDisk space overall / size of a folder
    ip aShows network interfaces and addresses
    sudoRuns one command with administrator rights
    historyShows 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
    PartValueMeaning
    First character-Type: - file, d directory, l link
    Next threerwxOwner (user) permissions
    Middle threer-xGroup permissions
    Last threer--Everyone else (others)
    Owner / groupmaya analystsThe file’s owning user and group
    LetterOn a fileOn a directoryNumber
    r readView contentsList names inside4
    w writeChange contentsCreate, rename or delete items inside2
    x executeRun as a programEnter 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
    FileHoldsWho can read it
    /etc/passwdAccount list: name, UID, GID, home, shellEveryone (it holds no password hashes)
    /etc/shadowPassword hashes and ageing settingsRoot only (and privileged system groups)
    /etc/groupGroups and their membersEveryone
    /etc/sudoersWho may use sudoRoot. 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 -a means append. Without it, the user is removed from every other supplementary group.
    • On Ubuntu and Kali, members of the sudo group can use sudo. Other distributions may use a group called wheel.
    • 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
    GoalCommandMeaning
    Find failed loginsgrep "Failed password" sample.logLines containing that phrase
    Count themgrep -c "Failed password" sample.logNumber of matching lines (6 here)
    Ignore casegrep -i "failed" sample.logMatches Failed, FAILED, failed
    Exclude linesgrep -v "Failed" sample.logEverything that does not match
    Show line numbersgrep -n "Accepted" sample.logHelps you locate the line again
    Contextgrep -A 2 -B 2 "Accepted" sample.logTwo lines after and before
    Either wordgrep -E "Accepted|sudo" sample.logExtended pattern with OR
    Only invalid usersgrep "invalid user" sample.logAttempts 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 -f shows new lines as they arrive. Press Ctrl+C to stop.
    • The SSH service unit is called ssh on Debian-based systems and sshd on many others.
    • last shows recent logins, and lastb shows failed ones if the system records them.
    • Rotated logs are renamed (for example auth.log.1) and older ones may be compressed. Use zgrep to 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.log
    Task 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 777 to “fix” a problem. Find the real cause and grant only what is needed.
    • Forgetting -a in usermod -aG. The user loses their other groups.
    • Running uniq without sort. 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 sudo only when needed.
    • Assuming one log location. Check your distribution; use /var/log/secure or journalctl where appropriate.
    • Treating one failed login as an attack. Look at volume, speed, user names and what happens next.
    • Mistyping paths in destructive commands. Run ls on the path first, then rm.

    9. YouTube search links

    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/passwd lists accounts, /etc/shadow holds hashes, usermod -aG adds groups safely.
    • Least privilege: normal account first, sudo for 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

    ← Back to hub

    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.