This Week in Numbers

• 🧩 7 CTI frameworks and tools covered — Pyramid of Pain, Cyber Kill Chain, Unified Kill Chain, Diamond Model, MITRE ATT&CK, MISP/OpenCTI, YARA

• 🕵️ 4 practical rooms worked end-to-end (Trooper, Summit, Eviction, Friday Overtime)

• ⏱️ 10 minutes stuck on a single MITRE label before "why vs. how" finally clicked

• 🔁 5 struggles documented — all the same root cause wearing a different costume

• 💡 1 realization: getting a framework "roughly right" isn't the same as getting it right

Every Struggle Was the Same Mistake Wearing a Different Costume

Going in, I expected this week to be the easy one. Two weeks of hands-on tooling behind me — Nmap, Wireshark, Metasploit, Burp — and now just frameworks to read and apply. Reading always feels safer than running an exploit.

By the end of the week I knew better:

Almost everything this week — MITRE ATT&CK, the Pyramid of Pain, MISP, the Diamond Model, YARA — was really the same question asked in a different vocabulary: am I actually being precise here, or just close enough?

A Tactic and a Technique both describe "what the attacker did," but one is the goal and one is the method. An IOC and an IOA both describe "evidence," but one is a disposable artifact and one is the behavior underneath it. A saved MISP event and a published one both look identical in the UI, but only one is actually shared. Five different frameworks, one repeated failure mode: collapsing two related-but-different ideas into a single guess.

• What was the attacker trying to accomplish, versus how did they do it? → Tactic vs. Technique
• Did the artifact change, or did the behavior change? → IOC vs. IOA
• Did I finish the action, or just set it up? → Saving vs. Publishing in MISP
• Am I exploring one thread, or the whole web around it? → Pivoting the Diamond Model
• Is my rule's logic specific, or just present? → YARA strings vs. condition

Once that pattern was visible, Week-10 stopped feeling like five unrelated rooms and started feeling like one long lesson in the same discipline, asked five different ways.

02 — I Mapped an Alert's "How" and Called It the "Why" in MITRE ATT&CK

Working through the MITRE room, I was given a scenario: a phishing email drops a malicious macro to gain a foothold. I confidently labeled "Phishing" as the Tactic. It felt right — phishing is the attack. ATT&CK marked it wrong, and it took a good ten minutes to figure out why.

I'd been reading Tactics and Techniques as the same thing wearing different labels. A Tactic is the attacker's goal — the "why" (here, Initial Access). A Technique is the specific method used to reach that goal — the "how" (Phishing sits underneath the Initial Access Tactic). I'd been naming the tool and calling it the objective.

1. "What was the attacker trying to accomplish?"        → that's the Tactic
2. "What specific method did they use to accomplish it?" → that's the Technique

Scenario: phishing email → malicious macro → foothold
Tactic:     Initial Access
Technique:  Phishing (T1566)

🔐 The habit that fixed it: Getting a framework "roughly right" isn't the same as getting it right. Mislabeling a Technique as a Tactic doesn't just cost a wrong answer — in a real SOC it means writing the incident report at the wrong level of detail entirely. {% /callout %}

03 — I Treated a Rotated IOC as "New Intel" Instead of the Same IOA

In the Pyramid of Pain room, I hit a scenario where an attacker's C2 IP changed between two incidents. My first instinct was to log it as a separate, unrelated finding — new IP, new entry.

I'd been thinking entirely in IOC terms — each new hash or IP as its own isolated fact — instead of asking whether the underlying behavior connecting them was the same. The IP had changed; the technique used to stand it up hadn't. I was tracking artifacts, not the attacker.

1. Has this IOC (hash/IP/domain) changed?     → expected, low pain to rotate
2. Has the underlying TTP changed?             → if no, it's still the same actor/campaign
3. Log it as a continuation, not a new event

That one distinction is the entire reason the Pyramid of Pain exists — low-pain indicators are supposed to change. Treating every rotated IOC as a brand-new finding means missing that it's the same campaign wearing a different IP.

04 — I Built a MISP Event and Assumed It Was Shared the Moment I Saved It

In the Threat Intelligence Tools room, I created a MISP event, added a few IOCs as attributes, and moved on assuming it was now visible to the connected community. Nothing had actually been shared.

Saving an event in MISP and publishing it are two different actions. I'd created and populated the event but never hit publish, and I hadn't set a Traffic Light Protocol (TLP) tag either — so even if I had published it, MISP had no instruction on who was actually cleared to see it.

1. Create Event
2. Add Attributes (IOCs)
3. Tag with TLP (who's allowed to see this)
4. Publish

🔐 Real-world echo: An unpublished MISP event is functionally the same as an analyst's private notes — accurate, but useless to anyone else. The entire value of a TIP is step 4, not step 2. {% /callout %}

05 — I Stayed on One Vertex of the Diamond Model Instead of Pivoting

In the Trooper room, I identified a malicious IP (Infrastructure) early and spent most of my time learning more about that one IP — more WHOIS lookups, more passive DNS — instead of moving anywhere else.

I'd found one vertex of the Diamond Model and kept digging straight down into it instead of using it to reach the other three. The room's actual expectation was to pivot from that Infrastructure data point out to Capability (what tooling connected to it) and eventually Adversary — not to exhaustively mine a single vertex first.

Adversary ←→ Infrastructure ←→ Capability ←→ Victim
   (found one? ask what it connects to on each of the other three)

The Diamond Model's value is in the pivoting, not in any one vertex alone. Going deep on Infrastructure without ever crossing to Capability or Adversary is the CTI equivalent of reading one page of a report and calling it the investigation.

06 — My YARA Rule "Matched" Everything Because I Never Wrote a Real Condition

Writing my first YARA rule, I defined a few strings that looked specific to the sample malware, ran it, and it flagged almost every file in the test set — including clearly unrelated ones.

I'd copied the rule structure but left the condition block as a lazy catch-all instead of combining the strings with real logic. A condition like "any of them" matches if even one loosely common string shows up anywhere — which is exactly what happened, since one of my patterns was generic enough to appear in unrelated files too.

condition:
    $a and $b and not $c    // require the specific combination,
                             // explicitly exclude a known false-positive pattern

🔐 The habit that fixed it: The strings block is just a list of candidates — the condition block is what actually turns YARA into a detection instead of a keyword search. A rule with strong strings and a weak condition is still a weak rule. {% /callout %}

The Bigger Realization

Week-09 taught me not to distrust the tool before checking my own configuration. Week-10 taught me a sharper version of the same lesson: the frameworks are precise, and "close enough" on a term is exactly how a Technique gets logged as a Tactic, a rotated IP gets logged as new intel, and a saved event never actually reaches anyone.

Every mistake this week traced back to the same root cause, just wearing a different framework's clothes. A confident MITRE label collapsed the moment I actually separated "why" from "how." A rotated IOC looked like new intel until I checked the behavior underneath it. A MISP event looked shared until I noticed I'd skipped the one button that mattered. A single Diamond Model vertex felt thorough until the practical room asked me to actually pivot. A YARA rule looked correct until its condition logic proved otherwise.

None of these were tool failures. Nmap, MISP, and YARA all did exactly what I told them to — the gap was always in how carefully I'd actually defined the term or the logic before trusting my first read of it.

How I Studied This Week

Instead of taking each room's summary at face value, I forced myself to separate concepts that felt interchangeable before trusting any answer:

I also went past the room summaries themselves — reading MITRE's own ATT&CK site directly for real technique IDs, checking Bianco's original Pyramid of Pain post instead of only the room's version of it, and reading MISP's own docs for how TLP tagging and correlation actually work under the hood.

5 Mental Models I Had to Replace

Misconception 01 — A Tactic is just a more formal name for the attack. It's the attacker's goal, not their method. Phishing is a Technique; Initial Access is the Tactic it serves.

Misconception 02 — Every changed indicator is a new finding. A rotated IP is expected, low-pain behavior — check whether the TTP changed before logging anything as "new."

Misconception 03 — Creating an event in MISP means it's shared. Creating populates it. TLP tagging and publishing are what actually make it visible to anyone else.

Misconception 04 — Finding one Diamond Model vertex is the investigation. It's the starting point. The model's entire value is in pivoting across all four.

Misconception 05 — A YARA rule with the right strings is a working rule. Strings are just candidates. The condition is the logic that turns them into an actual detection.

Resources That Helped Me

Week 10 Complete.

Week-09 was about running tools against a target. This week was about understanding the target before the tools ever get used — the Pyramid of Pain, the Kill Chain models, and the Diamond Model are all the same question asked three different ways: how far did the attacker get, and what would actually cost them to change?

Seven frameworks and tools, four full practical scenarios, and five mistakes that all trace back to one habit I'm still building: trusting my first read of a term less, and checking the actual definition more.

Next step: carry this same precision into detection and response — connecting how an attacker's TTPs actually get mapped, alerted on, and investigated once they show up in a real SIEM.

Let's Connect

If you're on a similar journey or have feedback, I'd love to connect!

🔗 LinkedIn: Durga Madhav Chandra 💻 GitHub: DurgaMadhavChandra

#Cybersecurity #LearningInPublic #BuildInPublic #ThreatIntelligence #MITREATTACK #MISP #YARA #InfoSec #SOCAnalyst #CTI

This Week in Numbers

Two Paths, One Week

I went into this week expecting Cyber Security 101 to teach me new concepts. Pre Security had already given me the map — OSI, TCP/IP, Linux and Windows fundamentals, how the web works. I assumed Cyber Security 101 would just be "the same map, zoomed in."

It wasn't. It was the same map, handed to me with the instruction: now walk it yourself.

Every room in Cyber Security 101 ends the same way — not a quiz, but a live VM and a flag you actually have to capture. That single design choice changed the entire shape of the week. I wasn't reading about Nmap. I was staring at my own scan output, trying to figure out why half the ports said something I didn't fully understand yet.

01 — Pre Security: The Terrain I Already Knew, Now With Hands on It

Pre Security's 13 rooms weren't new information — I'd built the mental model for most of this already. What changed was doing it instead of reading it.

Offensive/Defensive Security Intro → Careers → Network Fundamentals → LAN → OSI Model → Packets, Frames & Ports → Extending Your Network → How the Web Works → Website Fundamentals → Web Architecture → Linux Fundamentals → Windows Fundamentals

The room that actually surprised me here was Website Fundamentals. I already knew, in theory, that developers sometimes leave sensitive data sitting in front-end source code. Actually opening a page's source and finding something I wasn't supposed to see turned "check the source code" from a rule I'd read into a reflex I now have.

02 — Cyber Security 101: Where Theory Became Muscle Memory

This is where the week actually got hard. 14 modules, 55 sub-rooms, covering everything from Linux/Windows/AD fundamentals to cryptography, exploitation, web hacking, offensive tooling, defensive security, and the 2025 OWASP Top 10.

The Room That Changed My Whole Perspective — "Blue"

Inside the Exploitation Basics module sits a room called "Blue" — a deliberately unpatched Windows machine, vulnerable to a years-old, fully documented SMB exploit. I fired up Metasploit, searched for the module, set my target, and ran it.

It worked. First try, technically.

Then my Meterpreter session died instantly, before I could type a single command.

🔐 What I learned the hard way: a successful exploit and a stable session are two different milestones. My payload architecture didn't match the target, and my LHOST was pointing at the wrong interface. The exploit "worked" — the connection just never had a chance to survive. I go into the full breakdown in this week's 03-errors-and-struggles.md.

Once I fixed both values and got a stable session, running getuid, sysinfo, and browsing the filesystem on a machine I'd just exploited was the single most concrete "I actually did that" moment of the entire certificate so far.

03 — Networking Got Real: Nmap, Wireshark, Tcpdump

Pre Security taught me what a port scan is. This week I ran one.

nmap -sV -sC -p- 10.10.10.10

Watching real open/closed/filtered results come back — instead of reading a definition of what those words mean — is what separated "I know what Nmap is" from "I can use Nmap."

The Filtered Port That Almost Got Skipped

I nearly walked straight past a filtered port, reading it the same as closed — "nothing there, move on." It isn't the same thing at all.

open → something is actively listening and responded closed → the host responded, but nothing is listening filtered → no response at all — a firewall is in the way, the real state is unknown, not "safe to ignore"

That one word, misread, would have meant skipping exactly the kind of port a firewall is deliberately protecting — the one most worth a second look.

04 — Cryptography Stopped Being a Definition

I already knew, on paper, that hashing is one-way and encryption is reversible with a key. This week I cracked an actual hash:

john --wordlist=rockyou.txt hash.txt

Watching John chew through a wordlist and actually recover a plaintext password is what made "weak, reused passwords are a real vulnerability" stop being a warning I'd read a dozen times and start being something I'd proven myself.

05 — Web Hacking Taught Me the Browser Lies

Opening Burp Suite's Proxy tab for the first time, I expected to immediately see traffic. I saw nothing. My first assumption: the tool was broken.

It wasn't. My browser simply wasn't pointed at Burp's listener yet.

Burp Proxy listener → 127.0.0.1:8080 (default) Browser proxy setting → manually set to the same host:port Burp's CA certificate → installed in the browser for HTTPS interception

Once traffic actually started flowing through, intercepting and editing a request before it reached the server made "never trust client-side validation" a lesson I proved to myself instead of one I just accepted from a slide.

06 — Starting SAL-1 and the 20 Minutes That Taught Me Everything

With both learning paths done, I started prepping for TryHackMe's SOC Analyst Level 1 (SAL-1) certification. I expected the jump to be conceptual. It wasn't — it was learning to actually investigate.

During one of the first investigation labs, I searched for events tied to an alert and found nothing. I rewrote my query. Checked filters. Started wondering if the SIEM wasn't collecting logs at all.

🔐 The realization: almost twenty minutes in, I noticed my search window was set to the wrong time range. The logs had been there the entire time — I was simply looking in the wrong place. A SIEM can only show you what you ask it to show, and even a perfectly written query is useless against the wrong timeframe.

Since then, every investigation starts the same way, before a single query gets typed:

1. Verify the alert timestamp

2. Confirm the search/time range covers that timestamp

3. Confirm the correct log source is selected

4. Only then start searching for evidence

The Cybersecurity Connection

Every struggle this week — the SIEM, the filtered port, the dead Meterpreter session, the empty Burp history — traced back to the exact same root cause, and it wasn't a knowledge gap:

I trusted my first assumption about what a tool was telling me, instead of verifying the state it was actually in.

The realization that changed everything this week:

"The tools are rarely wrong. The assumptions about what they're currently configured to show you absolutely can be."

That's not a Nmap lesson or a Burp Suite lesson — it's the exact instinct a SOC analyst has to fight on every single shift.

How I Studied This Week

Instead of rushing to the flag, I forced myself to slow down on four questions every time something didn't behave the way I expected:

4 Mental Models I Had to Replace

Misconception 01 — "No results" means the data isn't there Usually it means the query is wrong — the time range, the filter, the log source — not that the underlying data doesn't exist.

Misconception 02 — A scan result is either "there" or "not there" Nmap's filtered state is neither — it's an honest "I don't know," and treating uncertainty as "safe to ignore" is exactly how real findings get skipped.

Misconception 03 — A successful exploit means the job is done Getting a session to open and getting a session to survive are two separate problems, gated by completely different configuration details.

Misconception 04 — If a tool shows nothing, the tool is broken Almost every "broken tool" moment this week was actually a configuration gap on my end — the browser's proxy setting, the search window, the payload architecture. The tool was doing exactly what it was told.

Resources That Helped Me

Week 09 Complete. 🛠️🔐

Pre Security answered "how does this all work?" Cyber Security 101 answered "what do I actually run to test or defend it?"

But the thing that's actually going to matter once I'm in a SOC seat isn't knowing what Nmap or a SIEM does. It's the habit this week forced on me: verify what you're looking at before you trust what it's telling you.

Next step: keep pushing through SAL-1 prep, and start treating every lab like a real shift instead of a room to finish.

Let's Connect

If you're on a similar journey or have feedback, I'd love to connect!

🔗 LinkedIn: Durga Madhav Chandra 💻 GitHub: DurgaMadhavChandra

#CyberSecurity101 #PreSecurity #TryHackMe #SOCAnalyst #LearningInPublic #BuildInPublic #Networking #Metasploit #BurpSuite #SIEM #CyberSecurity

This Week in Numbers

• 🎓 2 Coursera courses completed (Put It to Work: Prepare for Cybersecurity Jobs, Accelerate Your Job Search with AI)

• 🧩 9 courses of the Google Cybersecurity Certificate now complete — the certificate is done

• 🗣️ 1st week the "struggle" wasn't a script or a query — it was explaining my own work out loud

• 🤖 4 AI tools added to my job-search workflow (Career Dreamer, Sheets, Gemini, Gemini Live)

• 💡 0 technical errors to report — and that's the actual story of this week

Everything Comes Back to Deployment, Not Just Skill

Going into this week, I expected it to feel like a light wrap-up after seven weeks of technical weight. By the end of it, I understood it differently:

Course 8 and Course 9 weren't a break from the technical work — they were the step that makes the technical work count for something. A skill nobody can see you use isn't a skill an employer can hire.

Data classification, incident escalation, stakeholder communication, resumes, interviews, elevator pitches, AI-assisted job search — on paper these look like seven unrelated topics. In practice they're all the same question asked from different angles:

• Can I take what I know, and get it in front of the right person, in a form they can actually use?

02 — Knowing What to Protect, and Who to Tell

Course 8 opened with the security mindset — the habit of constantly evaluating risk instead of waiting for an alert to force the question. That habit only works if you also know what you're protecting, which is where data classification came in: public, private, sensitive, and confidential data don't deserve the same amount of effort, and treating them all the same is its own kind of mistake.

From there the course moved into incident escalation — not solving the incident myself, but recognizing something is wrong and getting it to the right person, following whatever escalation policy is actually in front of me rather than guessing. Then it went one step further: even once something is escalated correctly, five very different stakeholders — a risk manager, a CEO, a CFO, a CISO, an operations manager — all need that same information delivered differently.

🔍 The habit that stuck: Escalation isn't about knowing everything. It's about recognizing something is wrong, getting it to someone who does, and then explaining it in whatever format that specific person can act on fastest.

03 — Turning Seven Weeks of Notes Into a Resume and an Interview

This was the part of the week that actually felt uncomfortable, in a good way. Writing seven weeks of notes is one thing. Compressing that into resume bullets, a two-minute elevator pitch, and answers I could actually say out loud under mock-interview pressure is a completely different skill — and it exposed which topics I understood well enough to explain, versus which ones I only understood well enough to recognize on a quiz.

The STAR method (Situation, Task, Action, Result) was the tool that made this possible. It turns a vague claim like "I'm good at incident response" into a specific, verifiable story with a beginning, middle, and end. The mock interview question about walking through an incident response was the first time Course 6's entire lifecycle came out of my mouth instead of off a page — that's when it stopped feeling memorized and started feeling learned.

🔍 The habit that stuck: The gap between "I understand this" and "I can explain this to someone else" is bigger than it looks — right up until an interview forces you to close it.

04 — Bringing AI Into the Job Search Itself

Course 9 shifted the lens again — from preparing materials manually to using AI as an actual collaborator in the search. Career Dreamer turned my background into a Career Identity Statement and a web of career paths I wouldn't have thought to search for directly. A simple Google Sheets tracker kept every application, contact, and follow-up date somewhere other than my memory. Gemini helped tighten résumé language and tailor it per job description, and Gemini Live let me practice answering out loud, in real time, instead of just typing responses into a text box.

None of these tools did the thinking for me — Career Dreamer doesn't apply to jobs, Gemini doesn't know what's actually true about my background, and Gemini Live doesn't decide what a good answer sounds like. What they removed was the friction of starting from a blank page at every single step.

🔍 The habit that stuck: As more people use AI tools to prepare, the advantage stops being access to the tools and starts being how deliberately they're actually used.

The Bigger Realization

The first seven weeks of this certificate taught me how systems work, how to watch them, and how to automate that watching. This week taught me that none of it matters if it stays in my head or in a GitHub repo nobody reads out loud. Course 8 and Course 9 aren't a detour from the technical work — they're the delivery mechanism for it.

Every earlier week had a moment where the tool told me I was wrong — an error, a failed lab check, a rule that saved wrong. This week didn't have that moment, and I think that's exactly why it was harder in a different way. Nothing was going to flag a weak elevator pitch or a resume bullet that undersold what I actually did. The only feedback loop was whether I could say it clearly enough that someone else understood it the first time.

How I Studied This Week

I also kept a job-search tracker running in Sheets from day one instead of trusting memory, and used Gemini Live to practice answering out loud more than once — the same way regex101 gave me a fast feedback loop back in Week 7.

4 Mindset Shifts From This Week

Shift 01 — Data protection isn't uniform. Public, private, sensitive, and confidential data all carry different risk, and treating them the same wastes effort where it matters least and under-protects where it matters most.

Shift 02 — Escalation is a judgment skill, not a technical one. The size of an issue today says nothing about the size it could become if it isn't escalated — and every organization's process is different, so the transferable skill is finding and following whatever policy exists.

Shift 03 — A resume proves you can do the job; a cover letter (and an elevator pitch) explains why you want to. Tailoring both to the specific role and company is what separates an application from a form letter.

Shift 04 — AI tools narrow the preparation gap, not the effort gap. Career Dreamer, Gemini, and Gemini Live make starting easier, but the judgment about what's true and worth saying is still entirely mine.

Resources That Helped Me

Week 08 Complete.

Nine courses of the Google Cybersecurity Certificate, done. The first weeks taught me how systems work. The middle weeks taught me how to watch them and automate that watching. This week taught me how to walk into a room — or a Zoom call — and explain why any of it matters to someone deciding whether to hire me.

The certificate didn't end with a lab or a script. It ended with a résumé, a pitch, and a mock interview answer that finally sounded like something I understood, not something I memorized.

Next step: start applying the "who needs to know this, and how" instinct from this week to real applications — and keep building this repo as the portfolio piece it already turned out to be.

Let's Connect

If you're on a similar journey or have feedback, I'd love to connect!

🔗 LinkedIn: Durga Madhav Chandra 💻 GitHub: DurgaMadhavChandra

#Cybersecurity #LearningInPublic #BuildInPublic #GoogleCybersecurityCertificate #InfoSec #SOCAnalyst #CareerChange #JobSearch #AIforCareers #CertificateComplete

This Week in Numbers

• 🚨 2 Coursera courses completed (Sound the Alarm: Detection and Response, Automate Cybersecurity Tasks with Python)

• 🐍 1st Week I wrote and debugged real Python scripts instead of just reading about syntax

• 🕵️ 0 error messages thrown across all four mistakes this week — every one of them ran clean and was still wrong

• 🔍 1 rule direction I read backwards, and didn't catch until the lab flagged it

• 💡 1 Realization: the most dangerous mistakes are the ones the tool never complains about

Everything Comes Back to Asking the Right Question First

Going into this week, I expected Course 6 and Course 7 to feel like two separate skills — one about watching a network, one about writing code. By the end of the week I understood them differently:

Almost everything this week — SIEM queries, IDS rules, regex, containment decisions — was really the same failure wearing different clothes: acting before I'd actually confirmed what I was looking at.

A SIEM query without a hypothesis is just noise. An IDS rule read left-to-right instead of source-to-destination watches the wrong traffic. A regex with an unescaped character matches the wrong text and never tells you. A containment decision made before analysis is a guess with extra steps. Once that clicked, Course 6 and Course 7 stopped feeling like "detection" and "automation" bolted together, and started reporting back to the same underlying question:

• Did I actually confirm what I think happened, before I acted on it?

02 — I Was Searching for Data Instead of Investigating an Event

I could read through logs and understand what individual entries meant. I could follow along with packet analysis just fine. But the moment a lab put me inside a SIEM tool and asked me to investigate an event, I froze. I kept writing queries trying to "find something" — throwing filters at the tool hoping something useful would surface. I had no direction.

IDS signatures changed how I saw everything. A signature isn't just a rule — it's a written description of known attack behavior. When I traced one back to what an actual attacker does, the SIEM query stopped being a search problem. It became a question: did this specific behavior happen, and when?

Before: pull fields and filter, hoping something useful surfaces
        (undirected exploration — no hypothesis, just noise)

After:  1. What does this attack behavior actually look like?
        2. What source IP, port, or time window would prove it happened?
        3. Only then → build the query around that specific answer

🔍 The habit that fixed it: A SIEM query without a security question behind it is just noise. The tool only becomes powerful once you know what attack behavior you're looking for — and that only comes from understanding how the attack actually works, not from memorizing the query language. {% /callout %}

03 — I Wrote an IDS Rule Backwards Without Noticing

The activity asked for a rule alerting on traffic coming into a protected host on port 22. I wrote the protected host first because it felt like the important part — the same way I'd read an English sentence, subject first. The lab flagged it as wrong and I couldn't immediately see why.

alert protocol source_ip source_port -> dest_ip dest_port (options)

What I wrote:  192.168.1.10:22 -> any:any   (traffic FROM the host, port 22)
What I needed: any:any -> 192.168.1.10:22   (traffic TO the host, port 22)

A Suricata-style rule reads as source -> destination, not "important thing first." I had the direction of the traffic completely backwards — my rule was watching for traffic leaving port 22, not arriving at it.

🔍 Real-world echo: A rule that "looks right" because the important detail is early in the line isn't the same as a rule that's structurally correct. The arrow means direction, and skimming past it is exactly how a detection rule ends up watching the wrong traffic entirely. {% /callout %}

04 — My Regex Matched Nothing Because I Forgot to Escape a Period

I wrote a pattern to pull IP addresses out of a log file:

import re
match = re.search(r'\d+.\d+.\d+.\d+', log_line)

It ran without any errors, which made me assume it was correct — until I tested it against a log line with a version number sitting next to an IP address, and it matched the wrong thing entirely.

I'd forgotten that . in regex means "any character," not a literal period. My pattern wasn't looking for an IP address shape at all — it was matching almost any group of digit-something-digit-something-digit-something-digit.

import re
match = re.search(r'\d+\.\d+\.\d+\.\d+', log_line)

"No error" is not the same as "correct." A script can run cleanly and still be quietly wrong — especially in regex, where an unescaped character doesn't throw an exception, it just silently changes what you're actually matching against.

05 — I Contained an Incident Before Confirming What I Was Containing

Given an alert about unusual outbound traffic, I immediately jumped to containment — isolating the host — before confirming what the traffic actually was or where it was going.

1. Detection & Analysis  → what is this traffic, where is it going, is it actually malicious?
2. THEN Containment       → isolate based on what step 1 actually confirmed
3. Eradication            → remove the confirmed cause
4. Recovery                → restore and verify

The lab's follow-up question asked me to justify the containment decision with evidence, and I realized I didn't have any yet. Detection and Analysis comes before Containment in the lifecycle for a reason — acting before confirming risks containing the wrong thing entirely.

🔍 One habit, four contexts: Containment feels like the responsible, decisive move to make first — but skipping analysis isn't fast response, it's guessing with extra steps. The lifecycle puts confirmation before action for a reason. {% /callout %}

The Bigger Realization

Course 6 gave me an alert queue and a lifecycle to work through. Course 7 gave me a script editor and a language to automate that lifecycle with. I'd been treating them as unrelated — a detection course and a coding course — until the SIEM struggle showed me they're the same muscle: don't act until you've confirmed what you're actually looking at.

Every mistake this week traced back to that same root cause, and none of them announced themselves. A SIEM query with no hypothesis still returns rows. A backwards rule still saves without complaint. A regex with one missing backslash still runs top to bottom. A containment action still "works," technically, even without evidence behind it. Last week a terminal error stopped me in my tracks immediately. This week, nothing stopped me — I had to go back and check my own reasoning, because the tool never would.

How I Studied This Week

Instead of trusting that "it ran" meant "it's right," I forced myself to ask a confirming question before treating anything as done:

I also kept a regex tester open the entire week instead of guessing blind, and pulled up real sample PCAP files in Wireshark outside the guided lab so packet analysis wasn't something I only practiced once inside a walkthrough.

4 Mental Models I Had to Replace

Misconception 01 — A SIEM is a search engine you throw filters at. It's an investigation tool — the query should follow a specific hypothesis about attacker behavior, not lead one.

Misconception 02 — An IDS rule reads like a sentence, important part first. It reads as source -> destination. Direction is the meaning, not decoration.

Misconception 03 — If a regex runs without errors, it's correct. Regex fails silently. An unescaped character doesn't crash — it just quietly matches the wrong thing.

Misconception 04 — Containment is the responsible first move after an alert. Containment is a decision that should follow analysis, not replace it. Acting before confirming is guessing, not responding.

Resources That Helped Me

Week 07 Complete.

Last week was about operating inside a system — commands and queries. This week was about watching that system for trouble, and writing the code to watch it for me. The uncomfortable part wasn't the syntax — it was realizing how many of my mistakes never made a sound.

Four courses down, five total complete. The alert queue doesn't feel like noise anymore, and a broken script doesn't feel like a dead end — it feels like a traceback waiting to be read properly.

Next step: carry this week's "confirm before you act" instinct into the last stretch of the certificate, and start connecting detection, automation, and analyst judgment into something that looks like an actual SOC workflow instead of separate courses.

Let's Connect

If you're on a similar journey or have feedback, I'd love to connect!

🔗 LinkedIn: Durga Madhav Chandra 💻 GitHub: DurgaMadhavChandra

#Cybersecurity #LearningInPublic #BuildInPublic #Python #SIEM #GoogleCybersecurityCertificate #InfoSec #SOCAnalyst #IncidentResponse #DetectionAndResponse

This Week in Numbers

• 🐧 2 Coursera courses completed (Tools of the Trade: Linux and SQL, Assets, Threats, and Vulnerabilities)

• ⌨️ 1st Week I actually broke something in a terminal instead of just reading about breaking things

• 🔗 3 Days spent fighting a single SQL JOIN

• 🗂️ 4 Asset classification tiers I finally learned to apply correctly, not just recite

• 💡 1 Realization: hands-on feedback finds the gaps in your understanding faster than reading ever will

Everything Comes Back to Relationships

Going in, I treated Linux and SQL as two separate, mostly mechanical skills — commands to memorize, syntax to get right. By the end of the week I understood them differently:

Almost everything this week — file permissions, SQL joins, asset-to-vulnerability mapping — was really the same question asked in different languages: how does this thing relate to that thing?

A permission relates a user to a file. A JOIN relates one table to another through a shared key. An asset relates to its vulnerabilities through an asset_id. Once that clicked, Course 4 and Course 5 stopped feeling like "computing skills" and "security concepts" bolted together, and started feeling like one continuous skill:

• Who is this user actually allowed to touch? → Permissions

• What's the shared key linking these two tables? → SQL Joins

• Which vulnerabilities actually belong to this asset? → Asset Mapping

Once that clicked, Course 4 and Course 5 stopped being "a computing skills course" and "a concepts course" bolted together, and started reporting back to the same underlying question.

02 — I Tried to Numeric-Notation My Way Through chmod Without Understanding It

Working through Course 4's permissions lab, I hit a task asking me to give a script owner read/write/execute, group read/execute, and others nothing. I typed chmod 750 script.sh because I'd memorized "750 is a common permission setting" from a cheat sheet — not because I understood why those three digits meant what they meant.

The lab changed the requirement slightly — group should only get read, not execute — and I froze. I had no idea which digit to change or why, because I'd never actually connected 7, 5, and 0 back to rwx, r-x, and ---.

r = 4 | w = 2 | x = 1
Owner: rwx = 4+2+1 = 7
Group: r-- = 4+0+0 = 4   (what I actually needed, not 5)
Others: --- = 0+0+0 = 0

chmod 740 script.sh

🔐 The habit that fixed it: A memorized number is only useful for the exact question it was memorized for. Rebuilding the permission from r/w/x values up every time was slower at first — but it's the only version of this skill that actually transfers to a scenario the cheat sheet didn't cover. {% /callout %}

03 — I Spent Three Days Fighting a SQL Join, Thinking About the Problem Backwards

I could write a basic SELECT statement fine. Filter with WHERE, no problem. But the second a lab asked me to pull data from two tables — an assets table and a vulnerabilities table — using a JOIN, I completely stalled. I kept trying to filter my way to the answer instead of relating the tables to each other.

A JOIN isn't a syntax trick — it's a relationship. An asset_id in one table and the same asset_id in another table are literally how a database connects "what device is this" to "what's wrong with it." That's the exact question a security analyst asks every day: which assets have critical vulnerabilities, and how do I find that fast in a database instead of scrolling a spreadsheet.

I stopped trying to memorize JOIN syntax and started drawing the tables out by hand — asset_id, hostname, owner on one side, asset_id, CVE, severity on the other. Once I could see the shared column, the query wrote itself:

SELECT hostname, severity
FROM assets
INNER JOIN vulnerabilities ON assets.asset_id = vulnerabilities.asset_id
WHERE severity = 'Critical';

That one line taught me more about vulnerability management than the reading did — because I had to think like an analyst to even write it.

04 — I Drew the Classification Line in the Wrong Place

In Course 5's asset classification activity, I was given a fictional company's internal onboarding guide — useful to new employees, but never meant to leave the building — and I classified it as Public. My reasoning was "it's not sensitive data, nobody's harmed if it leaks." That felt airtight right up until I checked it against the answer key.

I'd been classifying assets purely on sensitivity of content, when the actual scheme also depends on intended audience. Public doesn't mean "not embarrassing if leaked" — it means "there's genuinely no restriction on who can see it." An onboarding guide was still written for employees only, which makes it Internal-Only by definition, regardless of how harmless the content feels.

Who was this actually written for?        → defines the audience boundary
What happens if that audience expands?     → defines the classification tier

🔐 Real-world echo: I'd been running one test (harm) when the classification scheme actually runs two (harm and intended audience). Skipping the second question is exactly how a low-harm document gets mislabeled Public when it was never meant to leave the org in the first place. {% /callout %}

05 — I Mapped a Spoofing Scenario to the Wrong STRIDE Category

Course 5's threat modeling walkthrough gave me a scenario: an attacker using a stolen employee badge to enter a restricted server room. I confidently labeled it Tampering, since my brain jumped straight to "something physical was altered — access was changed."

Nothing in the scenario involved data or a system being changed. Tampering is about integrity — modifying something that should stay intact. What actually happened was an attacker successfully pretending to be someone they weren't, using stolen credentials to pass as an authorized identity. That's Spoofing, which attacks authentication, not integrity.

Pretending to be someone else            → Spoofing (Authentication)
Changing data/systems without permission → Tampering (Integrity)
Denying an action you actually took       → Repudiation (Accountability)
Seeing data you shouldn't                  → Information Disclosure (Confidentiality)
Overwhelming a system                       → Denial of Service (Availability)
Gaining access beyond your permission level  → Elevation of Privilege (Authorization)

One letter of difference decided this one, too — "something happened to access" isn't specific enough to pick a STRIDE category. A stolen badge and a tampered system both feel like access problems, but they violate completely different principles.

The Bigger Realization

Course 4 gave me the environment security tools actually run in. Course 5 gave me the discipline to ask "what are we protecting, from whom, and how would they get to it." I'd been treating them as unrelated — a technical skills course and a concepts course — until the SQL join struggle showed me they're the same muscle.

Every mix-up this week traced back to the same root cause as last week, just with sharper feedback. A memorized chmod value collapsed the moment the requirement changed slightly. A JOIN refused to click until I stopped filtering and started relating two tables the way an actual analyst would. A classification call felt obviously right until I realized I'd only tested for harm and skipped the audience question. A STRIDE category felt correct purely because it sounded dramatic, not because it matched what was actually violated.

A terminal doesn't care how confident you feel — it errors out or it doesn't. That's a faster, blunter teacher than a quiz question, and I think that's exactly why this week's mistakes stuck better than last week's did.

How I Studied This Week

Instead of just watching the course labs passively, I rebuilt almost everything from first principles instead of memorizing the shortcut version:

I also went outside the guided Coursera labs — practicing extra Linux navigation and SQL joins on Linux Journey and SQLBolt, and reading MITRE's own ATT&CK matrix directly instead of relying on the course's summary of adversary tactics.

4 Mental Models I Had to Replace

Misconception 01 — Numeric permissions are a lookup table. chmod 750 is just r/w/x values added up. Memorize the math, not the number, or the first changed requirement breaks you.

Misconception 02 — A SQL JOIN is a syntax problem. It's a relationship problem. Draw the shared key between two tables before writing a single line of SQL.

Misconception 03 — Asset classification is purely about how sensitive the content is. It's sensitivity and intended audience. A harmless document can still be Internal-Only if it was never meant to leave the org.

Misconception 04 — A STRIDE category can be picked by how dramatic a scenario feels. It has to be picked by which specific principle — authentication, integrity, confidentiality, availability, accountability, authorization — was actually violated.

Resources That Helped Me

Week 06 Complete.

Last week was about understanding the structure the wire operates inside of. This week was about finally operating inside that structure myself — typing the commands, writing the queries, and building the threat model instead of just reading about all three.

Two courses down this week, five total complete. The terminal doesn't feel intimidating anymore, and neither does a blank SQL query window — that alone tells me the hands-on approach is working.

Next step: carry the relationship-thinking from this week — permissions, joins, asset-to-vulnerability mapping — into detection and response, and start connecting how systems are attacked to how alerts actually get investigated.

Let's Connect

If you're on a similar journey or have feedback, I'd love to connect!

🔗 LinkedIn: Durga Madhav Chandra 💻 GitHub: DurgaMadhavChandra

#Cybersecurity #LearningInPublic #BuildInPublic #Linux #SQL #GoogleCybersecurityCertificate #InfoSec #SOCAnalyst #ThreatModeling #VulnerabilityManagement

This Week in Numbers

Everything Comes Back to One Triangle

Going in, I treated the CIA Triad as a slide you memorize on day one and move past. By the end of the week I understood it differently:

Confidentiality, Integrity, and Availability aren't three separate rules — they're the only three questions that matter when something goes wrong.

Every framework, every control, every incident report this week eventually collapsed back into one of these three questions:

• Did the wrong person see this? → Confidentiality

• Was this changed without permission? → Integrity

• Can the right people still get to it? → Availability

Once that clicked, the eight CISSP domains stopped feeling like a list to memorize and started feeling like eight different departments all reporting back to the same three-word mission statement.

02 — The Day I Learned Risk Isn't a Synonym for "The Bad Thing"

My first real mix-up came in Course 2. A practice scenario described an unpatched server exposed to the internet, and without thinking, I labeled the server itself as "the risk."

It felt right. It was the thing that was wrong, after all.

Going back to the definitions slowly instead of trusting my gut, the picture separated out:

Vulnerability → the unpatched server itself (the weakness)
Threat        → an attacker scanning for exposed services (the actor/event)
Risk          → the potential damage if the two actually meet (the outcome)

{% callout type="info" %} 🔐 The habit that fixed it: I stopped leaving these three definitions stacked as separate bullet points and started rewriting them side by side, in the same scenario, every time. Seeing them stacked separately is exactly what let me blur them together in the first place. {% /callout %}

03 — Reciting a Framework Isn't the Same as Understanding Its Order

I could say "Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor" from memory without hesitating. Then a quiz asked what comes right after Select, and I confidently answered "Authorize." Wrong.

I'd memorized the NIST Risk Management Framework as seven words in a row, not as a dependency chain. Select picks the controls. Implement deploys them. Assess checks whether they actually work. Only then does Authorize make sense — you can't formally accept risk for a control nobody has verified yet.

A list feels shuffleable. A pipeline doesn't — and treating RMF like the first is exactly how I got the second wrong.

04 — Not Every Attack Is a Confidentiality Problem

A Course 2 scenario described a DDoS attack knocking a company's website offline. My brain instantly filed it as "attack → confidentiality," no reading required.

It's not. Nothing in a DDoS scenario touches data being viewed or stolen — the entire point is overwhelming a system so legitimate users can't reach it. That's a textbook availability problem.

Data seen by the wrong person   → Confidentiality
Data changed without permission → Integrity
Service or data made unreachable → Availability

{% callout type="info" %} 🔐 Real-world echo: Most cybersecurity headlines are about breaches and leaked data, which quietly trained my instinct to jump to "confidentiality" for anything labeled an attack. Assuming every attack targets the same pillar is exactly how you misclassify an incident's severity and send the wrong team down the wrong path first. {% /callout %}

05 — One Letter, One Very Different Job: IDS vs. IPS

Skimming Course 3's device list, I mentally filed IDS and IPS as basically the same thing — "the tool that stops bad traffic." That assumption walked straight into a wrong answer on a practice question.

Reading each acronym slowly instead of as a pair:

IDS = Intrusion Detection System  → watches and alerts. Nothing more.
IPS = Intrusion Prevention System → watches AND actively blocks.

One letter of difference. The entire meaning of "someone needs to respond right now" versus "the system already responded — go confirm it did the right thing" lives inside that one letter.

06 — The Week I Realized I'd Memorized the Map, Not Walked the Terrain

This was the real struggle of the week, and it didn't show up until I tried to actually use everything I'd learned in one go.

Three courses, one week — CIA Triad, eight domains, NIST CSF and RMF, playbooks, network architecture, hardening. On paper, all of it made sense. Then I sat down to map a simple incident to an actual response process, and I froze. I could recite the triad. I could list the domains. I could explain what a playbook is for. The moment a scenario asked "what's your first step," I hesitated.

That's not a knowledge problem. That's an application problem.

So I started asking one question after every concept: "If I were the analyst on shift, what would I actually do right now?" I walked a basic scenario — an unauthorized login attempt on a network device — end to end:

Which domain does this fall under?      → Security & Risk Management / IAM
Which control should have caught this?   → Access control / MFA enforcement
What does the playbook say to do first?   → Detection and Analysis phase
Where does this sit in the architecture?   → Access layer, network device

That single exercise taught me more than the rest of the week combined. The triad stopped being abstract the moment I had to decide, under a fake deadline, that this was an availability concern first (an active login attempt potentially locking out the real device owner) — not a confidentiality one out of habit.

The Bigger Realization

Foundations gave me vocabulary. Risk management gave me structure. Networking gave me terrain. I'd been studying all three as separate subjects — until one scenario forced me to use them as one continuous way of thinking.

Every mix-up this week traced back to the same root cause: the gap between defining something and deciding with it. Risk, threat, and vulnerability are easy to define separately and easy to blur under pressure. The RMF steps are easy to recite and easy to reorder by accident. The CIA Triad is easy to quote and easy to misapply on autopilot. IDS and IPS are one letter apart on the page and an entire incident-response decision apart in practice.

An incident doesn't arrive with a label telling you which term, which step, or which pillar applies. You either know how to reach for the right one under pressure, or you don't — and the only way to find out which one you are is to stop reciting and start deciding.

How I Studied This Week

Instead of just watching the course videos passively, for every named framework or standard, I went and read the primary source directly — not the course's summary of it:

I also completed every portfolio activity properly instead of skimming it: a security audit against a fictional company's controls, a six-phase incident-response walkthrough, a full incident report written around the NIST CSF, and a guided OS-hardening exercise.

5 Mental Models I Had to Replace

Misconception 01 — Risk means "the thing that's wrong." Risk is the potential outcome of a vulnerability and a threat meeting — not either one on its own.

Misconception 02 — A seven-step framework is just a list to memorize. NIST RMF is a dependency chain. Each step needs the output of the one before it; none of them are interchangeable.

Misconception 03 — Every attack is a confidentiality issue. Attacks target availability and integrity just as often — DDoS is the clearest example, and assuming otherwise misclassifies severity.

Misconception 04 — IDS and IPS are basically the same tool. One detects and alerts; the other detects and blocks. That distinction changes what an analyst has to do next.

Misconception 05 — Knowing the frameworks means you can use them. Fluent recall and real understanding are different skills. Only one of them helps when a scenario asks for a decision instead of a definition.

Resources That Helped Me

Week 05 Complete. 🛡️🔐

Last week was about touching the wire — watching real packets move in Wireshark. This week was about understanding the structure the wire operates inside of: what it's protecting, what could go wrong, and who's allowed to touch it.

A security analyst who only knows the frameworks can't read a packet capture. One who only knows Wireshark can't explain why the organization cares. This week, NIST and OWASP stopped being acronyms to memorize and started being living documents written by people solving the same problems I'm learning to solve.

Next step: carry the terrain from this week — networks, devices, protocols — into Linux and SQL, and start connecting how systems are attacked to how they're actually investigated.

Let's Connect

If you're on a similar journey or have feedback, I'd love to connect!

🔗 LinkedIn: Durga Madhav Chandra 💻 GitHub: DurgaMadhavChandra

#Cybersecurity #LearningInPublic #BuildInPublic #NIST #RiskManagement #NetworkSecurity #InfoSec #SOCAnalyst #GoogleCybersecurityCertificate

This Week in Numbers

Networking Is Really a System of Addresses

Before this week, networking felt like trivia.

Port 22 is SSH.

Port 443 is HTTPS.

/24 means 254 hosts.

Facts that lived in tables and went nowhere.

Then something clicked.

Every networking concept I studied seemed to answer the same question:

"Where is this traffic going, and should it be allowed to get there?"

Which layer is this protocol operating on?

Which device makes this routing decision?

Which rule permits or denies this packet?

Which service is listening on this port, and does it need to be?

Networking stopped feeling like a certification topic and started feeling like the map every attacker and every defender is reading at the same time.

01 — The Moment the OSI Model Stopped Being a Table

I had memorised the OSI model before.

Seven layers.

Application, Presentation, Session, Transport, Network, Data Link, Physical.

A table to recite on demand and forget immediately after.

Then I opened Wireshark and captured a real DNS query.

I watched it move through the layers in front of me.

Application layer — the query itself.

Transport layer — UDP, port 53.

Network layer — the IP address it was heading to.

Data Link layer — the MAC address of my gateway.

Physical layer — the bytes on the wire.

Every layer I had been memorising in theory was sitting right there in a real packet.

The moment that changed everything was realising the OSI model isn't a memorisation exercise.

It's a map.

Every attack lives somewhere on that map.

DDoS targets Layer 3 and Layer 4.

SQL injection and XSS live at Layer 7.

ARP poisoning happens at Layer 2.

Once I could place an attack on the map, I could immediately ask: what defence belongs at that layer?

That question made the entire week make sense.

02 — Subnetting Was Painful Until the Pattern Clicked

I won't pretend subnetting was intuitive.

The binary math felt mechanical.

Converting octets, counting host bits, working out broadcast addresses.

I ran through it slowly at first:

192.168.1.0/26
Subnet mask: 255.255.255.192
Host bits: 6
Usable hosts: 2^6 - 2 = 62

Mechanical. Slow. Uncomfortable.

Then I started doing it faster. And faster. And it clicked.

What actually changed my thinking wasn't the math.

It was the moment I connected subnetting to firewall rules.

Every ACL I'll ever write is in CIDR notation.

Every penetration test scope is defined in CIDR notation.

Every network segmentation strategy — the core defence-in-depth control that limits how far an attacker can move — is built on subnet boundaries.

Misread a boundary and you misconfigure a firewall.

That's not a theory failure. That's a real-world breach waiting to happen.

The math stopped feeling like a chore and started feeling like a language I needed to be fluent in.

03 — I Captured the TCP Handshake and Finally Understood It

I had read the three-way handshake dozens of times.

SYN → SYN-ACK → ACK

Simple enough to draw from memory.

But I didn't really understand it until I watched it happen in Wireshark.

I generated traffic with curl, applied a filter, and watched three packets appear in sequence.

Each one was a conversation.

The client saying: I want to connect.

The server saying: I hear you, I'm ready.

The client saying: Understood. Let's go.

What hit me wasn't the handshake itself.

It was what the handshake makes possible.

A SYN flood — one of the oldest denial-of-service attacks — works by sending thousands of SYN packets and never completing the handshake.

The server holds connection state for every half-open session.

Eventually it runs out of room and legitimate connections can't get through.

Seeing the handshake in real traffic made that attack technique instantly, viscerally obvious in a way that reading about it never had.

04 — Port Scanning Taught Me to Read the Network Like a List of Open Doors

Before this week, Nmap felt like a tool I was supposed to use without fully understanding why.

I ran it against my lab:

nmap -sV 192.168.1.0/24

What came back wasn't just a list of numbers.

It was a list of decisions someone had made about what to expose.

Port 22 open — SSH is running here.

Port 3389 open — RDP is accessible here.

Port 445 open — SMB is listening here.

Every open port is a service.

Every service has a version.

Every version has known vulnerabilities.

The scan wasn't showing me ports.

It was showing me the attack surface.

That shift in framing — from "port numbers to memorise" to "an inventory of exposure" — changed how I think about reconnaissance entirely.

05 — VLANs Created the Illusion of Separation. Misconfigured Trunking Broke It.

VLANs made perfect sense on paper.

One physical switch. Multiple isolated networks.

Sales can't talk to Engineering. Engineering can't talk to the Management VLAN.

Clean. Logical. Secure.

Then I learned about VLAN hopping.

A misconfigured trunk port — one that doesn't properly restrict which VLANs are allowed — can let an attacker craft frames that jump between segments.

The physical switch is still one device.

The isolation only holds if the configuration is correct.

That was the moment network segmentation stopped feeling like a guaranteed control and started feeling like a configured control.

Configurations can be wrong.

Wrong configurations are how attackers move through networks that were supposed to stop them.

06 — DNS, DHCP, and NTP Felt Boring Until I Saw What Happens When They're Attacked

I almost skimmed these sections.

DHCP assigns IP addresses automatically.

DNS resolves names to addresses.

NTP synchronises clocks.

All three felt like infrastructure plumbing. Background noise. Invisible until they fail.

Then I read about rogue DHCP servers.

An attacker on the same network segment can respond to DHCP discovery broadcasts faster than the legitimate server.

The client accepts the first offer it receives.

The attacker's offer points to their own default gateway and their own DNS server.

Every request that client makes now flows through the attacker's machine first.

That's a full man-in-the-middle position — gained without touching the target at all.

Just by answering a broadcast first.

DHCP, DNS, and NTP stopped feeling like boring infrastructure.

They started feeling like the three highest-leverage targets on a local network.

07 — IPv6 Was the Blind Spot I Wasn't Expecting

Every network topic this week felt like building on something I had vaguely heard of before.

IPv6 was different.

Not because it was harder — but because of what I didn't know I didn't know.

Many networks run dual-stack: both IPv4 and IPv6 simultaneously.

Security teams configure firewall rules for IPv4.

They forget about IPv6.

An attacker who routes their traffic over IPv6 on a network that "only runs IPv4" may bypass every control that was written assuming the old addressing model.

IPv6 also replaced ARP with NDP — the Neighbour Discovery Protocol.

NDP has no built-in authentication.

The same spoofing attacks that work against ARP work against NDP.

The lesson wasn't about IPv6 specifically.

It was about unmonitored protocols.

An unmonitored protocol is an open door.

The lock on the front door doesn't matter if you leave the back window open.

The Cybersecurity Connection

Every networking topic this week mapped directly to an attack technique.

OSI layers → attacks have a precise location on the model.

TCP handshake → SYN floods exploit the connection state it creates.

Port scanning → open ports are attack surface, not just configuration.

VLANs → VLAN hopping breaks segmentation through misconfiguration.

DHCP/DNS → rogue servers redirect traffic without touching the target.

IPv6 → unmonitored protocols bypass IPv4-only controls.

BGP → route hijacking can silently redirect traffic at internet scale.

One realisation stood out above everything else:

Attackers don't need to break the network. They need the network to be misconfigured.

Every switch, router, firewall, and access point operates exactly as designed.

Security comes down to whether those designs were implemented correctly — and whether someone is watching the traffic to notice when they weren't.

How I Studied This Week

Instead of memorising protocol tables, I tried to ask four questions about everything:

I also ran every command I was reading about:

ping, traceroute, netstat, nmap, dig, arp -a.

And I captured the results in Wireshark to see what each one actually looked like on the wire.

Reading about protocols and watching them happen are two completely different experiences.

5 Mental Models I Had to Replace

Misconception 01 — Networking is just memorising port numbers

Ports are a symptom. The real skill is understanding what service is running, why it's exposed, and what an attacker can do with it.

Misconception 02 — VLANs mean the networks are completely separated

VLANs are a configuration. Misconfigured trunking collapses that separation entirely.

Misconception 03 — If my network runs IPv4, I don't need to worry about IPv6

Dual-stack is the default on modern systems. An unmonitored IPv6 path bypasses IPv4-only security controls.

Misconception 04 — DHCP, DNS, and NTP are background plumbing

They are the highest-leverage attack targets on a local network. Compromise any of them and you redirect everything.

Misconception 05 — Subnetting is a certification topic

Every firewall rule, every segmentation strategy, and every penetration test scope is written in CIDR notation. Get it wrong and the controls fail silently.

Resources That Helped Me

Week 04 Complete. 🌐🔐

This week looked like networking on the surface.

But underneath, it was really about traffic.

Who generates it.

Where it goes.

What happens when it's intercepted, redirected, or forged.

Every protocol.

Every port.

Every subnet boundary.

Every VLAN tag.

All of them taught the same lesson:

The network doesn't know the difference between legitimate traffic and an attack. That's your job.

Next step: Dive deeper into how attacks actually move across these networks — and how defenders detect and stop them.

Let's Connect

If you're on a similar journey or have feedback, I'd love to connect!

🔗 LinkedIn: LinkedIn

💻 GitHub: GitHub

#Networking #Cybersecurity #LearningInPublic #BuildInPublic #NetworkingFundamentals #Wireshark #Nmap #OSIModel #EthicalHacking #InfoSec

This Week in Numbers

Linux Is Really a System of Boundaries

Before this week, Linux commands felt random.

ls

cd

grep

chmod

find

cron

A collection of tools I needed to memorize.

Then something clicked.

Every Linux concept I learned seemed to answer the same question:

"Who is allowed to do what?"

Who can read this file?

Who can write to this directory?

Who can execute this program?

Which process owns this resource?

Which user is allowed to run this command?

Linux stopped feeling like a collection of commands and started feeling like a carefully designed security model.

01 — The Day File Permissions Finally Became Real

I had seen permission numbers before:

chmod 755
chmod 644
chmod 600

They felt like magic numbers everyone memorized.

Then I generated an SSH key and tried connecting.

Instead of logging in, SSH refused:

Permissions 0644 for 'key.pem' are too open.

At first I thought:

"The key is correct. Why won't it work?"

Then I realized something important.

A private key isn't private if everyone on the system can read it.

Changing:

chmod 644 key.pem

to

chmod 600 key.pem

instantly solved the problem.

That was the moment permissions stopped being theory and became security.

02 — The Most Dangerous Command I Typed This Week

At some point I ran:

chmod 777

without fully understanding what I was doing.

It fixed the immediate error.

It also destroyed the security model.

I learned that giving everyone full access isn't solving a permission problem.

It's removing the protection entirely.

The deeper lesson wasn't about chmod.

It was about trust.

Linux forces you to think about trust explicitly.

Every file has an owner.

Every process has permissions.

Every action has consequences.

Cybersecurity begins with understanding those relationships.

03 — grep Changed How I Look at Data

One of the biggest surprises this week wasn't a security tool.

It was grep.

I used to read logs manually.

Line by line.

Looking for patterns with my eyes.

Then I started combining commands:

grep
cut
sort
uniq

Suddenly the terminal felt less like a command line and more like a query language.

A few commands could answer questions that would take minutes by hand.

Which IP appears most often?

Which requests target login pages?

Which entries contain specific keywords?

The moment I started piping commands together, Linux felt incredibly powerful.

04 — My Cron Job Taught Me a Lesson About Assumptions

One of the strangest bugs this week was a cron job that worked perfectly when I ran it manually.

But completely failed when scheduled.

No output.

No errors.

Nothing.

After digging deeper, I discovered cron runs in a very different environment.

The script expected commands to exist in $PATH.

Cron didn't know where they were.

The fix was simple:

/usr/bin/nmap

instead of

nmap

But the lesson was much bigger.

Many bugs happen because we assume the environment will look exactly like our own.

Linux taught me to stop assuming and start verifying.

05 — Processes Felt Different After I Learned Signals

Before this week, killing a process meant:

kill -9 PID

Problem solved.

Now I understand that processes are conversations.

Signals are messages.

SIGTERM asks a process to shut down cleanly.

SIGKILL forces it to stop immediately.

The operating system isn't simply destroying programs.

It's coordinating them.

That small shift changed how I think about process management.

06 — Restricted Shells Changed My View of Security Controls

While working through Bandit challenges, I encountered a restricted shell.

At first I thought something was broken.

Commands were missing.

Navigation was limited.

Everything felt constrained.

Then I realized the restriction was intentional.

Someone had built a boundary.

The challenge wasn't using Linux.

The challenge was understanding the boundary well enough to recognize where it was weak.

That felt incredibly close to real-world cybersecurity.

Most security isn't about breaking systems.

It's about understanding where restrictions exist and how they can be bypassed.

07 — SUID Was My Biggest "Aha!" Moment

The concept seemed confusing initially.

Then I learned a simple explanation:

A SUID program runs with the permissions of its owner, not the user executing it.

That one sentence suddenly made privilege escalation examples make sense.

The interesting part wasn't the command itself.

The interesting part was the trust relationship behind it.

Who owns the program?

What privileges does it inherit?

Can those privileges be abused?

Understanding SUID felt like seeing the first building block of Linux privilege escalation.

The Cybersecurity Connection

Every Linux topic this week connected directly to security.

• File permissions determine access control.

• SSH keys protect authentication.

• Processes reveal system activity.

• Cron jobs automate tasks and can become attack vectors.

• SUID binaries can enable privilege escalation.

• Logs provide evidence during investigations.

• Restricted shells enforce security boundaries.

One realization stood out above everything else:

Attackers rarely need to break Linux. They simply look for boundaries that were configured incorrectly.

The operating system already provides the rules.

Security often comes down to whether those rules were implemented properly.

How I Studied This Week

Instead of memorizing commands, I tried to answer four questions:

I also spent time breaking things intentionally, reading error messages, debugging permission issues, experimenting with cron jobs, and documenting every mistake.

The mistakes taught me more than the successful commands.

5 Mental Models I Had to Replace

Misconception 01 — Linux is just commands

Linux is really a system of permissions, ownership, and boundaries.

Misconception 02 — If something doesn't work, use chmod 777

Most permission problems come from misunderstanding ownership, not insufficient permissions.

Misconception 03 — Base64 is encryption

Base64 only changes representation. Anyone can decode it instantly.

Misconception 04 — Cron behaves exactly like my terminal

Scheduled tasks run in a different environment and often require explicit paths.

Misconception 05 — Security starts with hacking tools

Security starts with understanding how the operating system already controls access.

Resources That Helped Me

Week 03 Complete. 🐧🔐

This week looked like Linux on the surface.

But underneath, it was really about trust, ownership, permissions, and boundaries.

The commands were useful.

The mindset was more valuable.

Every permission bit.

Every process.

Every SUID binary.

Every restricted shell.

All of them taught the same lesson:

Security begins long before exploitation. It begins with understanding the system you're trying to protect.

Next step: Continue building deeper Linux knowledge and start exploring how attackers and defenders interact with these same foundations every day.

Let's Connect

If you're on a similar journey or have feedback, I'd love to connect!

🔗 LinkedIn: LinkedIn

💻 GitHub: GitHub

#Linux #Cybersecurity #LearningInPublic #BuildInPublic #LinuxFundamentals #Bash #OpenSource #EthicalHacking #Programming #InfoSec

This Week in Numbers

The Operating System Is the Manager of Everything

I used to imagine the OS as software that sits between me and the hardware. A much better way to think about it:

The Operating System is the manager responsible for sharing the computer's limited resources between thousands of competing tasks simultaneously.

It decides:

• Which process gets CPU time

• Which program gets memory

• Which application can access a file

• Which device receives input and output

• Which requests are allowed to interact with hardware

The deeper I went, the more I realized every topic in OS is just another answer to one question:

"How do we efficiently share limited resources?"

02 — The Day My Mental Model of Programs Broke

One of my biggest misconceptions: programs simply run until they finish.

Open Chrome → CPU runs Chrome → Chrome finishes → next.

That was my entire model. Then I learned about process states, CPU scheduling, and context switching.

NEW → READY → RUNNING → WAITING → READY → TERMINATED

At first it looked like another diagram to memorize. Then I imagined opening Chrome, VS Code, and Spotify at the same time.

• Who gets the CPU first?

• What happens when Spotify waits for network data?

• Why doesn't the whole system freeze?

The OS isn't just running programs — it's constantly moving them between states and deciding who gets CPU time next. It stopped feeling magical and started feeling like an incredibly efficient traffic controller.

03 — CPU Scheduling Changed How I Think About Performance

At first, all the algorithms blended together. What finally helped was changing the question I was asking.

Instead of: "How does this algorithm work?"

I started asking: "What problem was this algorithm invented to solve?"

The Convoy Effect — my favorite OS concept this week

A single long process forces many short processes to wait behind it.

Imagine a supermarket billing counter — one customer with 200 items, ten customers behind with one item each. FCFS is technically fair. Practically, everyone suffers.

{% callout type="info" %} 🔐 Cybersecurity Connection: A process monopolizing CPU resources and starving others looks remarkably similar to a Denial of Service attack playing out in slow motion. {% /callout %}

04 — Concurrency Was Much Harder Than I Expected

When I first heard "concurrency", I thought it simply meant multiple things happen at the same time. That sounded easy. Then I reached the Critical Section Problem.

The Race Condition that changed everything

I saw an example where two threads both increment the same variable and the final answer is wrong. I asked myself: "How can adding one and adding one not become two?"

// Thread A and Thread B both increment a shared counter
// Expected: counter = 2. Actual: counter = 1. Here's why:

Thread A reads counter (value: 0)
Thread B reads counter (value: 0)   ← OS switches here
Thread A writes counter = 1
Thread B writes counter = 1         ← overwrites A's work!

// Result: counter = 1, not 2. This is a race condition.

Once that clicked, mutexes, semaphores, and condition variables stopped looking like complicated theory. They became mechanisms for telling the OS:

"Only one thread should be allowed to touch this shared resource at a time."

Classical Synchronization Problems — not just textbook questions

I implemented solutions for all of these and solved LeetCode Concurrency challenges:

• Print in Order

• Print FooBar Alternately

• Print Zero Even Odd

• Building H₂O

• Fizz Buzz Multithreaded

• Dining Philosophers

Writing actual synchronization code taught me far more than reading ever could.

05 — Deadlocks Finally Made Sense

I could memorize the four necessary conditions:

1. Mutual Exclusion

2. Hold and Wait

3. No Preemption

4. Circular Wait

But I didn't understand why they mattered until this analogy:

A group of friends sharing a limited number of bike locks. Each person grabs one lock and waits for a lock someone else already holds. Nobody releases what they have. Nobody moves forward. Everyone waits forever — that's deadlock.

The goal of deadlock prevention isn't a clever algorithm — it's deliberately breaking at least one of the four conditions required for deadlock to exist.

06 — Virtual Memory Was My Biggest "Aha!" Moment

I kept wondering: if my laptop only has limited RAM, how can a program larger than that still run?

The answer came from a simple analogy:

My study desk is small, so I don't keep every book on it — only what I need right now. The rest sit on a nearby shelf. That's Virtual Memory — RAM is the desk, secondary storage is the shelf.

Pages move between RAM and disk depending on what the program currently needs.

Page Replacement Algorithms

Then I discovered Thrashing — where excessive page swapping causes the system to spend more time moving memory around than actually executing useful work. Another reminder that OS design is always about balancing trade-offs.

07 — Why System Calls Matter More Than I Thought

At first I didn't understand why applications need system calls at all. If my program wants to create a file, why can't it simply write to the disk directly?

Imagine the consequences of unrestricted hardware access:

• Multiple applications could overwrite the same resource simultaneously

• Normal programs could accidentally modify kernel memory

• Malware could directly manipulate hardware without any restriction

{% callout type="info" %} 🔐 Cybersecurity Connection: System calls are one of the first security boundaries between user applications and the OS kernel. Many EDR and endpoint security tools monitor system calls for exactly this reason. Security begins with good boundaries. {% /callout %}

The Cybersecurity Connection

One of the reasons I wanted to study OS early is that almost every security topic depends on it. This week connected many ideas together:

• Process isolation helps contain malicious software

• Memory management is the foundation for understanding buffer overflow attacks

• Race conditions can become real-world exploitable vulnerabilities

• Deadlocks and synchronization issues affect system reliability at scale

• Malware often manipulates processes, threads, and permissions — not breaking the OS, but using it

The realization that changed everything:

"Attackers don't always break the operating system. They often use the operating system exactly as it was designed — just not how it was intended to be used."

How I Studied This Week

Instead of memorizing definitions, for every topic I forced myself to answer four questions:

I also drew process state diagrams, simulated scheduling algorithms by hand, wrote small C programs, and implemented multithreading problems in C++. Building small examples taught me far more than passively watching videos ever could.

5 Mental Models I Had to Replace

Misconception 01 — Programs run one after another The OS constantly switches between hundreds of processes in milliseconds. Nothing "simply runs until it finishes" without interruption.

Misconception 02 — Concurrency means everything happens together Concurrency means multiple things are in progress — not necessarily simultaneously. The interleaving creates subtle bugs like race conditions that are hard to reproduce.

Misconception 03 — A program must fully load into RAM before running Virtual memory and demand paging mean only the needed pages load into RAM. Programs can be larger than physical memory and still execute fine.

Misconception 04 — Scheduling algorithms are just interview formulas Each algorithm was invented to solve a specific real problem. Understanding that makes them memorable and meaningful — not arbitrary patterns to memorize.

Misconception 05 — Attackers "break" the operating system Most attacks use the OS exactly as designed — manipulating process permissions, exploiting race conditions, or abusing memory layout. Understanding the design is what reveals the vulnerabilities.

Resources That Helped Me

Week 02 Complete. ⚙️🔐

Cybersecurity doesn't begin with hacking tools or exploit development.

It begins with understanding the OS that every application, process, and attack ultimately depends on.

Next step: Build on these foundations and continue exploring the layers that make modern computer systems work.

Let's Connect

If you're on a similar journey or have feedback, I'd love to connect!

🔗 LinkedIn: [Durga Madhav Chandra](https://www.linkedin.com/in/durga-madhav-chandra-vemulapalli-a96143398/) 💻 GitHub: [DurgaMadhavChandra](https://github.com/DurgaMadhavChandra/cybersecurity-journey)

#OperatingSystems #Cybersecurity #LearningInPublic #BuildInPublic #Concurrency #MemoryManagement #Linux #Programming #SoftwareEngineering

The Beginning

Most people starting in cybersecurity want to jump straight to Kali Linux, run Nmap, and feel like Mr. Robot within the first week. I almost did the same. Then I found CS50 and something stopped me in my tracks.

David Malan didn't open a code editor for the first hour of Week 0. He talked about thinking. About decomposing problems. About patterns and abstraction. I was frustrated — when do we actually code?

"Programming is not about memorizing syntax. It is about learning how to think and solve problems."

That frustration turned into the most important mindset shift of my journey. This week wasn't just about learning C or algorithms — it was about rewiring how I approach every problem.

This week in numbers:

• 4 topics covered

• 5 real bugs faced and fixed

• 182 lines of C written

• 1 mindset completely shifted

01 — Computational Thinking

The OS your brain runs before writing any code

Computational thinking is a structured problem-solving approach built on four pillars. Every program ever written — from a login form to a threat detection system — starts here.

Every computer program follows: Input → Process → Output

The moment this clicked for me was when I applied decomposition to a cyberattack. A penetration test isn't chaos — it's a structured sequence of steps. That structure IS computational thinking.

🔐 Cybersecurity Connection

Analyzing attacks step by step (Recon → Scan → Exploit) is decomposition in practice. Detecting patterns in suspicious logins is pattern recognition. Building port scanners applies algorithm design. This isn't just theory — it's the mental framework of every security engineer.

My observation: Most beginners treat cybersecurity as a toolkit problem. They ask "which tools should I know?" instead of "how should I think?" Tools change. Thinking doesn't.

02 — Algorithms

Why "fast enough" is never fast enough at scale

An algorithm is a deterministic, step-by-step set of instructions to solve a problem. But not all solutions are equal — the difference between O(n) and O(log n) isn't academic. It's the difference between a SIEM that works and one that crashes under real traffic.

Big O — Slowest to Fastest:

O(n²)      → Bubble Sort, Selection Sort
O(n log n) → Merge Sort
O(n)       → Linear Search
O(log n)   → Binary Search
O(1)       → Hash Table lookup

The number that changed my perspective: Searching 1,000 elements — Linear Search takes 1,000 checks. Binary Search takes ~10. At a million log entries, that's the difference between real-time detection and a system that can't keep up with threats.

🔐 Cybersecurity Connection

Cybersecurity tools search through millions of log entries every second. A SIEM using Linear Search on 1 million logs would be painfully slow. Hash Tables and Binary Search are what make threat detection operate at machine speed. Algorithm choice IS security architecture.

03 — Data Structures

The containers that determine how fast your code thinks

If algorithms are strategies, data structures are the storage systems those strategies operate on. Choosing the wrong one doesn't just slow your program — in a real-world security context, it can mean missing an attack entirely.

Complexity at a glance:

Hash Tables felt like magic until I understood collisions. A poorly designed hash function with predictable collisions is a security vulnerability, not just a performance problem.

My observation: I kept asking "why not just use arrays for everything?" The answer became clear when I hit the resizing problem. Security systems deal with unpredictable data volumes — a DDoS can spike log entries 1000x in seconds. Rigid structures break. Dynamic ones adapt.

04 — C Language

Where most vulnerabilities in history were born

C was intimidating. No auto-complete, no safety net, no garbage collector. My first program had four compilation errors before it printed "hello, world." But there's a reason I chose to start here.

Most real-world vulnerabilities — buffer overflows, format string attacks, use-after-free bugs — are C problems. Learning C isn't just learning to program. It's learning where attacks are born.

Binary Search — my Week 01 final version:

// This took 3 attempts and a paper trace to get right
// The off-by-one errors are where buffer overflows come from

int binary_search(int arr[], int size, int target) {
    int left = 0;
    int right = size - 1;  // Bug 1 was: right = size

    while (left <= right) {
        int mid = (left + right) / 2;
        if (arr[mid] == target) return mid;
        else if (arr[mid] < target) left = mid + 1;  // Bug 2: was mid
        else right = mid - 1;                        // Bug 3: was mid
    }
    return -1;
}

Stack with overflow protection:

// My original push() failed silently on overflow.
// Silent failures = undetected breaches in production.

#define MAX 5
int stack[MAX];
int top = -1;

void push(int value) {
    if (top == MAX - 1) {
        printf("Stack Overflow — cannot push %d\n", value);
        return;
    }
    stack[++top] = value;
}

⚠️ The frustration of learning C is exactly what attackers exploit when developers rush. Off-by-one errors aren't just bugs — they are the most common source of buffer overflow vulnerabilities in history.

5 Times I Got Completely Stuck

I'm documenting every mistake because struggling is how understanding actually forms.

Bug 1 — I Thought Programming Was Just About Writing Code

I opened VS Code immediately on Day 1. CS50 Week 0 stopped me cold. David Malan spent an hour on thinking, not coding. I was frustrated.

Then came the phone book example — ripping it in half to prove Binary Search. I paused the video. Applied decomposition to a penetration test on paper. Suddenly the theory had a body.

Fix: Spent an entire session on computational thinking with zero code. Just pen and paper.

Insight: Skipping computational thinking means writing programs that solve the wrong problems. Security professionals think like attackers before they open a terminal.

Bug 2 — Binary Search: 3 Bugs Before It Worked

My broken code:

int right = size;        // Bug — should be size - 1
left = mid;              // Bug — causes infinite loop
right = mid;             // Bug — causes infinite loop

Traced through manually on paper with [2, 4, 6, 8, 10], target = 6. Spotted every issue.

Fix: right = size - 1 · left = mid + 1 · right = mid - 1

Insight: Off-by-one errors are how buffer overflows happen. Writing one byte past an array boundary is literally how attackers take control of systems.

Bug 3 — Stack Overflow: Silent Failure Was the Real Bug

My push() silently did nothing when the stack was full. No error, no warning. Added debug printf and saw the same top value repeating endlessly.

Fix: Check overflow condition first, print an error, then return. Never fail silently.

Insight: Silent failures are how security breaches go undetected for months. Error handling isn't defensive programming — it's incident response infrastructure.

Bug 4 — Queue vs Stack: FIFO and LIFO Kept Switching in My Head

Stopped trying to memorize the terms. Mapped them to real things:

• Queue = SOC alert triage. First alert in, first investigated.

• Stack = Browser back button. Last visited, first to return.

Insight: In a real SOC, if alerts were processed as a stack, older critical incidents would be permanently buried. Data structure choice has operational consequences.

Bug 5 — C Felt Like Driving Without Power Steering

Four errors before "hello, world." Missing #include <cs50.h>. Forgot semicolons. Used string without knowing it's a CS50 typedef for char *.

Three rules I now follow in C:

1. Always write includes first

2. End every statement with a semicolon

3. Check the CS50 manual before using any function

Insight: Every developer who rushes in C is writing tomorrow's CVE. Slow, careful C code is the foundation of secure systems.

Weekly Reflection

Looking back, my biggest struggle wasn't any specific error. It was slowing down enough to think before coding. Every bug had the same root cause — I assumed I understood something before I actually did.

The fix was always the same: go back to basics, trace through manually, visualize it. That pattern — assume, fail, trace, fix — is exactly how penetration testers work.

I didn't just learn computing fundamentals this week. I learned how to debug my own thinking. That's the skill that scales.

Week 01 is committed to my GitHub. Every note, every bug, every line of C — building in public.

Up next → Week 02: Operating Systems and Linux Fundamentals

Resources I Used

Let's Connect

If you're on a similar journey or have feedback, I'd love to connect!

• 🔗 LinkedIn: Durga Madhav Chandra

• 💻 GitHub: DurgaMadhavChandra

#Cybersecurity #CS50 #Programming #CLang #Algorithms #DataStructures #ComputerScience #LearnToCode #CyberSecurityAwareness #EthicalHacking #100DaysOfCode #OpenSource #TechLearning #Beginners #ComputationalThinking #SoftwareDevelopment #SecurityEngineer #BuildingInPublic #CodingJourney #Linux