Free course · Beginner
Cybersecurity Fundamentals
What you will learn
- Explain how a phishing email, a reused password and an unpatched server turn into a breach
- Set up multi-factor authentication and a password manager properly, and explain why length beats symbols
- Read a firewall rule and a port scan and say what is exposed and what is not
- Read authentication logs and tell a failed login burst from a real compromise
- Say clearly which systems you may test and which you may never touch, and why
- Write up a finding in the format a client or a manager expects
Course curriculum
5 modules · 15 lessons · a worked example and a practice task in every lesson
Module 1How attacks actually start1 of 53 lessons
Weeks 1–2 — the human and the credential. Almost every incident begins here, which is why it is week one instead of an appendix.
Phishing, the door that is always open
A phishing message asks for an action, not for information: open this, approve this, pay this. The tell is usually the consequence of doing nothing being urgent.
The lesson
Nearly every serious breach starts with one person clicking one link, and no firewall stops that. Phishing is a message that looks like it comes from somebody you trust — a bank, your college, your manager — and asks you to log in, open an attachment or pay an invoice. The tell is never the spelling; it is the pressure to act quickly and the fact that the request arrived at all.
Four checks catch most of them: read the actual address, not the display name; hover a link before clicking and read the domain to the right of the last dot; treat any unexpected attachment as hostile; and when a message asks for money, a password or a code, confirm through a channel you already trust rather than the one in the message.
The mistake is assuming you would never fall for one. Every phishing test in every company catches a third of the staff, including the security team, because the good ones arrive on a busy afternoon and look like work. Slow down on anything with an urgent request in it — that pause is the control.
Red flags: urgency ("act within 24 hours") a lookalike sender domain a link whose visible text and real target differ an unexpected attachment any request for a password, OTP or card details Verify out of band: call the person on a number YOU look up. Never enter credentials from a link in an email.Example A message claiming your salary account will be frozen in two hours works because urgency stops people checking the sender domain. Reading the domain and hovering over the link before clicking takes four seconds and defeats most of it.
Practice Collect five real phishing examples from public awareness pages and write the tell that would have caught each one.
Passwords, MFA and why length beats symbols
A long passphrase beats a short complex password, and reusing a password across sites is what turns one leaked database into ten compromised accounts.
The lesson
Length beats complexity. A four-word passphrase of twenty-odd characters is far harder to crack than eight characters with a symbol and a capital — and it is easier to remember. Attackers do not guess; they try billions of combinations per second against stolen databases, and every extra character multiplies the work.
Never reuse a password between important accounts: one breach anywhere reveals that password, and attackers try it everywhere. Use a password manager so you only remember one, and turn on multi-factor authentication — the code on your phone after the password — on your mail and GitHub first. Mail is the skeleton key: password resets for everything else arrive there.
The mistakes are a system everybody in a household knows, a password written in plain text on the desk, and MFA codes read out on a call to somebody who asked for them. A support agent will never ask for your one-time code; whoever does is attacking you.
Length beats symbols: "purple-tiger-battery-lamp-7" > "P@ssw0rd!" Use a password manager. Never reuse a password across sites. Turn on MFA - an app or a hardware key, not SMS if you can avoid it. Breached site? Change the password AND everywhere it was reused.Example Credential stuffing — trying leaked username and password pairs on other sites — works entirely because of reuse. Multi-factor authentication breaks it, which is why enabling it everywhere is the highest-value hour a beginner can spend.
Practice Turn on MFA on your own email and two other accounts, and install a password manager. Use a long passphrase for the master.
Attack surface: what you can see, you can defend
Every service listening on a port is something an attacker can talk to. Shrinking that list is the most effective defensive work there is, and it is less glamorous than it sounds.
The lesson
Attack surface is everything an attacker can reach: open ports, web forms, old test pages, an admin panel, a Git repository with a key in it, an unattended laptop on a public network. You cannot defend what you have not listed, so the first exercise in any audit is making the list.
Do it on your own project this week. Which endpoints are public? Which database is reachable from the internet? Which repository has ever contained a password or a key? Which accounts have admin rights and do all of them need them? Every answer that surprises you is a finding, and finding them yourself is the job.
The mistake is a development server left running with a default password, months after the project it belonged to. Remove, close or protect — and write down what you removed, because the list is what you show in an interview.
# Run only on your OWN machine. ip=$(curl -s ifconfig.me) nmap -F "$ip" # common ports ss -tulpn # local listening services systemctl list-units --type=service --state=running Close what you do not need. Remove default accounts. Enable a firewall. Fewer open doors, smaller attack surface.Example A development server left running on port 8080 with no password is a breach waiting for a scanner. Scanners are automated and constant; nothing has to be targeted at you personally for this to be found.
Practice List every service on your own machine that opens a port, and mark which ones you actually need.
Module 2Defending a small network2 of 53 lessons
Weeks 3–4 — ports, logs and the unglamorous controls. This is the actual day job of most security staff.
Networks, ports and what a firewall rule means
An IP address identifies a machine and a port identifies a service on it. A firewall rule allows or denies traffic between addresses and ports, and reading one is a core skill.
The lesson
A network moves packets between addresses. An address identifies a machine; a port identifies a service on it — 22 for SSH, 80 and 443 for the web, 3306 and 5432 for databases. A service listening on a port is a door, and whether the door is reachable from the internet is the whole question.
A firewall rule is one line of permission: allow, from an address range, to a port. Read them as sentences and they stop being scary. The rule you want is almost always "allow 443 from anywhere; allow 22 only from the office", and the one you do not want is "allow all to all", which is what a default cloud security group often gives you.
The mistake is opening a database port "temporarily" to test locally and forgetting it. Databases belong behind the application server, never exposed; that single rule is behind a large share of breached small systems.
# Allow SSH, HTTP, HTTPS - drop everything else. sudo ufw default deny incoming sudo ufw allow 22/tcp sudo ufw allow 80,443/tcp sudo ufw enable sudo ufw status verbose # 22 SSH . 80 HTTP . 443 HTTPS . 3306 MySQL (NEVER expose to the internet)Example "Allow 443 from anywhere, deny everything else" is a rule you can explain. "Allow all" with a note saying review later is how test environments become production incidents.
Practice Write the allow-and-deny list for a small office that needs web, mail and remote access — and nothing else.
Logs: reading the story of an incident
A log is a timeline. Five hundred failed logins from one address followed by one success is a story; the same five hundred spread across a week and never succeeding is noise.
The lesson
Logs are the timeline of what happened, and an incident is normally reconstructed from three sources: the web server's access log, which shows every request, the application log, which shows what the code did, and the authentication log, which shows who signed in from where and how often they failed. Reading them in time order is the whole technique.
Start from the thing you know — the time a customer reported the problem, an alert, a strange filename — and move outwards. Look for repetition (one address, hundreds of requests), for success after a run of failures (a password guessed), or for a request from a country nobody visits you from.
grep,sortanduniq -cturn ten thousand lines into a shortlist.The mistake is trusting a dashboard summary and never opening the raw lines. Summaries are written by whoever configured them and rarely answer the question in front of you. The second mistake is deleting a log after an incident because the disk was full — export it first, then rotate.
# Failing logins, and where they come from: sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head sudo last -f /var/log/wtmp | head # recent logins sudo journalctl -u ssh --since "1 hour ago" # Timeline: the first event, what changed, what was touched.Example Logs are shown in UTC, and reading a timestamp without converting it is the most common reason an investigation goes in the wrong direction for an hour.
Practice Take a sample authentication log, find the burst, convert the timestamp, and write three sentences on what happened.
Patching, backups and the boring controls that work
Unpatched software and untested backups cause more real damage than clever attacks. Both are boring, and both are what separates a defended system from a hopeful one.
The lesson
The unglamorous controls stop the attacks that actually happen: automatic updates on, backups that are tested by restoring one, least privilege so nobody has more access than the task needs, and disk or database encryption. None of them make an interesting demonstration, and all of them are in the list of top breaches every year.
A backup is not a backup until you have restored from it and checked the data is usable. Automate it, keep one copy somewhere the main system cannot reach — because ransomware encrypts attached drives too — and put a date in your calendar to restore one for real.
The mistake is a backup job that has been failing for months while the log line says it ran. Check the exit status and the file size, and restore once a quarter. Security is mostly maintenance, and maintenance is mostly noticing.
sudo apt update && sudo apt list --upgradable sudo apt upgrade -y # Backups: 3 copies, 2 media, 1 off-site (3-2-1) # Test a RESTORE, not just a backup - an untested backup is only a hope. # The controls that actually stop incidents: patch, backup, MFA, # least privilege. Boring, and they work.Example A backup that has never been restored is not a backup. Restoring one file from last week, on purpose, once, is the only way to know.
Practice Take a backup of something you care about, restore one file from it, and write down how long it took and what you would lose today.
Module 3Getting in legally3 of 53 lessons
Weeks 5–6 — legal practice, honest certificates and a write-up that gets you interviewed.
Labs and legal practice ranges
Practising on a system you do not own is a criminal offence in India under the IT Act and equivalent laws everywhere else — no exceptions for curiosity or for a course. Deliberately built practice ranges exist precisely so you never need to.
The lesson
Practise where you are allowed to. Legally safe environments to learn on: TryHackMe and Hack The Box (guided and legal), OWASP Juice Shop and DVWA running on your own machine, and your own virtual machines. Read the rules of a capture-the-flag event before you start; they say exactly what is in scope.
Never test a website you do not own or have written permission to test, even with a harmless automated scanner — that is a criminal offence in most countries regardless of intent, and in India it is a serious one. Universities and employers do give written permission for specific ranges and times; get it in writing, and stay inside it.
The mistake is running a vulnerability scanner against a college portal, a friend's site or a company that has not asked you to. Curiosity is not a defence, and a fresher with a police complaint has no career to protect.
Practice only where you are ALLOWED to: TryHackMe . Hack The Box . PortSwigger Web Security Academy OWASP Juice Shop (run it locally) . your own VMs Never test a site you do not own or have written permission to test. Keep a lab notebook - that notebook becomes your portfolio.Example Free and low-cost ranges give you vulnerable machines to attack with permission, with scoreboards and community support. Every skill in this course can be practised on them, and none of it requires touching somebody else's system.
Practice Create an account on one practice range, complete an introductory machine and save the walkthrough you wrote.
Two free certificates worth doing first
Entry-level security certificates are useful for one reason: they force you through a syllabus in order and give a recruiter something to verify. They are not a substitute for the practice range work.
The lesson
Start with Google's free cybersecurity course for vocabulary and how companies actually work, and Cisco's Introduction to Cybersecurity for the networking basics. Both are free, both can be finished in a few weekends, and both give a certificate you can put on your resume honestly as foundational training.
Then pick a direction rather than collecting badges: security operations (reading logs and alerts — the SOC analyst route, and the biggest fresher market), or application security (finding and fixing bugs in web applications). For either, add practice from a legal lab and one written-up finding of your own; that combination is what gets a fresher shortlisted.
The mistake is buying an expensive course before reading a single job ad. Read ten fresher security postings this week, note what they name — Splunk, Wireshark, Burp Suite, the SOC, Excel — and let the requirements choose your next month of study.
Both free to start: 1. Cisco "Introduction to Cybersecurity" (skillsforall) - fundamentals. 2. TryHackMe "Pre Security" path - hands-on basics. Then pick a direction: blue team (SOC), GRC, or offensive security. Add ONE small home-lab write-up - certificates alone do not get interviews.Example Pick one foundational certificate covering network and security basics, and check the current syllabus against what this course covers before paying for anything at all.
Practice Download the syllabus of one entry-level certificate and mark every objective you can already explain out loud.
Writing up a finding like a professional
A finding has five parts: what the issue is, how it can be exploited, what the impact would be, how to fix it, and how urgent it is. The fix and the urgency are what the reader acts on.
The lesson
A security report is written for two people at once: the engineer who must fix it, and the manager who must decide how urgent it is. Structure it as title, summary, impact in business words, reproduction steps, evidence, and the fix. Write the impact in terms of what data or access is lost, not in jargon.
Include the exact request and response, the version of the software, and the minimum steps to reproduce. Then calibrate the severity honestly — critical for remote code execution or data exposure, medium for something needing an authenticated user and unusual conditions — because a report that calls everything critical gets read as noise.
The mistake is a screenshot with no steps, which cannot be reproduced or fixed, and the second is a fix without a re-test. Say what you checked after the fix, and you become the junior whose reports are trusted, which is how the interesting work starts coming to you.
Title: Session cookie missing the Secure flag Risk: Medium - the cookie can cross plain HTTP on a hostile network Evidence: the response headers, and the request showing http:// Impact: session theft on public Wi-Fi Fix: set Secure; HttpOnly; SameSite=Lax Retest: confirmed set after the change Risk + evidence + impact + fix + retest. No names, no drama.Example A report that says "SQL injection found" gets ignored. A report that names the parameter, the impact on customer data and the two-line code fix gets scheduled this sprint.
Practice Write up one issue from a practice machine in that five-part format, with a screenshot, and publish it as a portfolio write-up.
Module 4Hands-on defence4 of 53 lessons
Harden a server, recognise the common web flaws, and handle secrets and keys like a professional.
Hardening a Linux server
Most breaches use a door somebody left open: a default password, an exposed database, an old package. Hardening is closing the obvious doors first, and it is measurable.
The lesson
Disable root login over SSH as well, and keep the SSH port and firewall on an allow list - the goal is fewer ways in, not a longer password.
Write the changes down as a checklist. A hardening step you cannot repeat on the next server is a one-off, not a control.
# key-only SSH sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' \ /etc/ssh/sshd_config sudo systemctl restart ssh # updates + firewall sudo apt update && sudo apt upgrade -y sudo ufw default deny incoming sudo ufw allow 22/tcp && sudo ufw allow 80,443/tcp sudo ufw enable # remove default accounts nobody uses sudo deluser --remove-home pi 2>/dev/null || trueExample Disabling password login for SSH and allowing only keys removes the single most attacked door on the internet.
Practice Harden one VM: key-only SSH, update packages, and enable the firewall - then list what you changed.
The OWASP Top 10, in plain words
The Top 10 is a list of the mistakes that keep happening: broken access control, injection, weak authentication, misconfiguration, and more. Knowing the five that hit web apps covers most real findings.
The lesson
Injection is still alive in any query built by string-joining user input; parameterised queries and escaping are the fix, and reviewers look for them first.
Misconfiguration - debug mode on, directory listing on, default credentials kept - is unglamorous and extremely common. Check the settings before hunting exotic bugs.
Checklist - the five that matter most: 1. Broken access control can you change an id in the URL and see others' data? 2. Injection is input concatenated into SQL or a shell command? 3. Authentication is there rate limiting on login? MFA? session timeouts? 4. Misconfiguration debug on? directory listing? default creds left? 5. Sensitive data secrets in the repo? stack traces shown to users? Fix order: 1 and 2 first - they are exploited the most.Example A page that shows /invoice/1042 and lets you open /invoice/1043 by changing the number is broken access control - the most common serious flaw.
Practice Take one web app and check three things: can you change an ID and see someone else data, is input reflected into the page, are errors leaking stack traces.
Secrets, keys and password managers
A secret in a Git repository is a secret that is already public. Keys, tokens and passwords belong in a manager or the environment, never in the code, and a committed key must be rotated, not deleted.
The lesson
A password manager is how a person keeps a different long password for every site; a secrets manager does the same for code. Reuse is the thing that turns one breach into ten.
Add a scanner to the pipeline so a secret never lands in the first place, and treat the removal of one as an incident with a rotation, not a quiet edit.
# look for secrets before they ship grep -rniE 'aws_secret|api[_-]?key|password *=' --include='*.py' --include='*.js' . # if a key WAS committed: # 1. revoke it in the provider (deleting the commit is not enough) # 2. issue a new one # 3. load it from the environment: export API_KEY=... # 4. add a scanner (gitleaks / trufflehog) to CIExample An AWS key pasted into a repo is found by scanners within minutes; deleting the commit does not help because the history keeps it - the key must be revoked and replaced.
Practice Search your own repositories for a key-like string and move anything found into an environment variable.
Module 5Responding, and getting hired5 of 53 lessons
What to do during an incident, and how to turn the fundamentals into a first security job.
Incident response basics
An incident is handled in a known order: prepare, detect, contain, eradicate, recover, learn. Skipping contain to go straight to the fix is how an attacker gets a second chance.
The lesson
A checklist written in calm times is what keeps a 2am response ordered; the goal in the first hour is to stop the spread and preserve evidence, not to fully understand the cause.
The lesson comes at the end and changes something real - a rule, a training, a monitor. An incident review that produces no change is a story, not a response.
IR order: Prepare -> Detect -> Contain -> Eradicate -> Recover -> Learn Suspected phished account - first hour: 1. Contain reset the password, revoke sessions, enable MFA 2. Preserve export the mailbox rules and the login log 3. Eradicate check for forwarding rules and new OAuth apps 4. Recover restore access, watch logins for a week 5. Learn add an alert for new mailbox rulesExample On a suspected compromise, isolate the machine from the network first - contain - then investigate, rather than pulling the power and losing the evidence in memory.
Practice Write a one-page incident checklist for a suspected phished account: who to call, what to isolate, what to preserve.
Writing a finding like a professional
A security finding a client will pay for has five parts: title, risk, evidence, impact and fix - in that order, in plain language, with the retest. No drama, no blame.
The lesson
Write for a busy non-security reader: the fix and the impact first, the technical detail in an appendix. A finding nobody acts on has protected nothing.
Always include a retest step - "verify by loading /admin in a private window" - so the client can confirm the fix themselves, which is what closes the ticket.
Title: Admin page reachable without authentication Risk: High Evidence: GET /admin returns 200 and user data with no session cookie Impact: Anyone can read every user record Fix: enforce the role check on the server for the route, not the menu Retest: load /admin in a private window -> expect 403 Detail (appendix): the request, the response headers, the timestamp.Example Title: "Admin page reachable without login". Risk: High. Evidence: the request and response. Impact: full data access. Fix: enforce the role check server-side.
Practice Turn one issue you found in a lab into a one-page finding in the five-part format.
The SOC analyst path and the interview
The common first security job is a SOC analyst: watch alerts, triage, escalate. Get there with fundamentals, two certificates, a home lab and a clear story about one investigation.
The lesson
Know the day of a tier-1 analyst: alerts, false positives, escalation criteria, and clear notes on every ticket. The tools are learnable; the discipline is what they screen for.
Be honest about what you have not done. Saying "I have done labs, not production incidents" is respected; pretending otherwise falls apart on the second question.
Tier-1 SOC day: - triage the alert queue against playbooks - close false positives with a reason - escalate real ones with evidence and a timeline Your interview story: "I saw 200 failed logins from one IP in the lab logs, confirmed it was brute force, blocked the IP, and wrote it up." Ask them: "what does a good escalation look like to you?"Example In an interview, "I saw repeated failed logins from one IP, isolated the source and blocked it" beats a list of tools you have read about.
Practice Prepare one investigation story in the five-part shape and one question to ask the SOC team.
About Cybersecurity Fundamentals
Understand how attacks actually begin, defend a small network with the controls that work, and practise only where practising is legal.
Any graduate curious about security, and IT or support staff who want the security side of their job. No coding required, though you will use a terminal on purpose-built practice ranges.
What you will be able to do at the end
- Explain how a phishing email, a reused password and an unpatched server turn into a breach
- Set up multi-factor authentication and a password manager properly, and explain why length beats symbols
- Read a firewall rule and a port scan and say what is exposed and what is not
- Read authentication logs and tell a failed login burst from a real compromise
- Say clearly which systems you may test and which you may never touch, and why
- Write up a finding in the format a client or a manager expects
How the course is structured
3 modules and 9 lessons, arranged so each one ends with something you have built. Every lesson carries a worked example and a practice task — the practice is the course, the reading is only the setup. Plan for 6 weeks · about 5 hours a week.
The full syllabus — every lesson, its example and its practice task — is in the Course curriculum below. Nothing is locked and nothing needs an account.
Your weekly routine
- Three sessions a week: one reading, one hands-on on a practice machine, one writing.
- Keep every command you learn in one notes file with the output it produced.
- Review your own account security once a week and close one gap each time.
What you will have built by the end
- A personal security review: MFA everywhere, a password manager, and a written list of what is still exposed
- A firewall and exposure report for a small office scenario
- Two published write-ups from legal practice machines, in the five-part format
Where this leads for a fresher
- Security operations centre (SOC) analyst, tier one
- IT support roles with a security responsibility
- Compliance and audit support roles
- Security track after an IT or networking start
Titles vary between companies; the evidence does not. A deployed project, a set of queries you can explain, or a case study with real testing behind it is what a fresher interview has to work with.
Frequently asked questions
Do I need coding to work in security?
Not for a first SOC or support role. Scripting helps you grow, and this course uses the terminal rather than a programming language. The paths that pay most later — application security, penetration testing — do want code, and that is a later decision.
Can I practise hacking on the college or office network?
No. Not on anything you do not own and have written permission to test. This is not a formality: unauthorised access is a criminal offence, and "I am learning" has never been a defence. Use a purpose-built practice range instead.
Are the practice ranges really free?
Several offer substantial free tiers or introductory machines, and the course shows you how to check what is genuinely free before signing up. Everything here can be learned on free material.
Is this course free?
Yes. Every lesson, example and practice task is free to read.
Not sure which of these you need first? The free Career Pulse check scores your skills, communication and goal clarity in about three minutes and tells you which gap to close first. Take the free check.