Think like a defender: network attack surface, threat modeling, the OWASP Top 10, core controls, identity, cryptography, frameworks and the rules of ethical testing.

Cybersecurity Fundamentals

## Why it matters

In Networking Fundamentals you learned how data moves: IP addresses get packets to the right machine, ports get them to the right program, and TCP or UDP decides how they travel. This course asks a different question about the same ideas: **what can an attacker reach, and what would they do with it?**

Defenders call the answer the **attack surface**: every place where someone outside your control can send input to your systems. On a network, the biggest part of the attack surface is simple to describe. It is every IP address you expose, every port that is listening on it, and every protocol spoken on that port.

## The core idea: a listening port is an open door

A program that accepts network connections **listens** on a port. A web server listens on 443, an SSH server on 22, a database on 5432. Each listening port is a door, and behind each door is software that might have bugs, weak passwords or bad settings.

Three questions turn a port list into a security review:

1. **Should this service be running at all?** Unused services are pure risk.
2. **Who needs to reach it?** The whole internet, the office network, or only the machine itself (`127.0.0.1`)?
3. **Is the protocol safe on this network?** Some old protocols send passwords in cleartext.

### Common ports and what defenders worry about

| Port | Protocol | Defender's concern |
|---|---|---|
| 21 | FTP | Logins and files sent in cleartext; use SFTP instead |
| 22 | SSH | Password-guessing bots run constantly; use keys, not passwords |
| 23 | Telnet | Everything in cleartext; should not be exposed anywhere |
| 25 | SMTP | Open relays get abused to send spam and phishing |
| 53 | DNS | Open resolvers are abused for amplification attacks |
| 80 / 443 | HTTP / HTTPS | Web apps are the most attacked layer (module 2) |
| 445 | SMB | File sharing; many worms spread through it; never expose to the internet |
| 3389 | RDP | Remote desktop; a favourite way in for ransomware groups |
| 3306 / 5432 | MySQL / PostgreSQL | Databases should almost never face the internet |

You do not need to memorise every number, but the ones above appear constantly in logs, firewall rules and certification exams.

## TCP and UDP from the defender's side

**TCP** opens a connection with a three-way handshake: the client sends SYN, the server answers SYN-ACK, the client finishes with ACK. Two security facts follow from this:

- A **port scan** works by sending SYNs and watching the replies. SYN-ACK means "open", RST means "closed", silence usually means a firewall dropped it.
- A **SYN flood** sends huge numbers of SYNs and never finishes the handshake, so the server fills up with half-open connections. Operating systems defend with SYN cookies, and providers filter floods upstream.

**UDP** has no handshake, so the sender's address is easy to forge. Attackers send small requests to open DNS, NTP or memcached servers with a forged source address (the victim's). The servers send much larger replies to the victim. This is an **amplification attack**, and it is why you should not run open resolvers on the internet.

## Worked example: reviewing a server

You manage a small Linux server that should only host a website. On that server you run:

```bash
sudo ss -tulnp
```

`-t` TCP, `-u` UDP, `-l` listening, `-n` numeric ports, `-p` show the owning process. Part of the output:

```text
Netid State  Local Address:Port  Process
tcp   LISTEN 0.0.0.0:22          sshd
tcp   LISTEN 0.0.0.0:443         nginx
tcp   LISTEN 0.0.0.0:80          nginx
tcp   LISTEN 0.0.0.0:5432        postgres
tcp   LISTEN 127.0.0.1:6379      redis-server
udp   UNCONN 0.0.0.0:161         snmpd
```

Read it line by line, asking the three questions:

- **22 (sshd) on 0.0.0.0** means every interface. SSH is needed for administration, but it should accept keys only and, ideally, only from your admin network or a VPN.
- **80 and 443 (nginx)** are the job of this server. Keep them, and make port 80 only redirect to 443.
- **5432 (postgres) on 0.0.0.0** is a problem. The database only serves the local website, so it should listen on `127.0.0.1` or be blocked by the firewall.
- **6379 (redis) on 127.0.0.1** is fine: only programs on the same machine can reach it.
- **161/udp (snmpd)** was installed by default and nobody uses it. Remove it.

Then make the firewall match the plan, with a **default deny** rule for incoming traffic and explicit allows for 22 (from the admin range), 80 and 443. The result: three doors instead of six, and each one is there on purpose.

## Packets tell stories

Every packet carries a source and destination address, ports, and flags. Defenders rarely read single packets for fun; they look for **patterns**:

- One source touching hundreds of ports in a few seconds: a port scan.
- Thousands of failed SSH logins from many addresses: a password-guessing botnet.
- An internal machine suddenly sending large amounts of data to an unfamiliar address at 3 a.m.: possible data theft, or "exfiltration".

Watching **outbound** traffic matters as much as inbound. Malware has to call home, so egress filtering (only letting servers talk to destinations they need) limits the damage of a compromise.

## Common mistakes

- **Trusting "it's only internal".** Attackers who get one foothold move sideways through internal networks. Internal services need authentication too.
- **Binding to 0.0.0.0 by default.** Many tools listen on every interface unless told otherwise. Check after every install.
- **Allow-all firewalls with a few blocks.** Default deny with a short allow list is easier to reason about.
- **Scanning networks you don't own.** Scanning someone else's systems without written permission can break laws such as the US Computer Fraud and Abuse Act, and it breaks most providers' terms of service. Practise only on your own machines or lab (lesson 4.2 covers the rules).

## Quick recap

- The attack surface is everything outsiders can send input to; on a network, that means exposed addresses, listening ports and protocols.
- For every listening port ask: should it run, who needs it, and is the protocol safe?
- TCP handshakes explain port scans and SYN floods; UDP's forgeable sources explain amplification.
- Default deny inbound, filter outbound, and keep internal-only services on localhost or private networks.


Look at packets, ports and protocols the way a defender does: every listening service is part of your attack surface.

Packets, ports, and protocols

Common Ports - CompTIA Network+ N10-009 - 1.4

## Why it matters

DNS and HTTP are the two protocols almost every user touches every minute, which makes them the two protocols attackers abuse most. You already know how they work from Networking Fundamentals. This lesson is the defender's six-minute version: the abuse patterns that matter and how they show up in logs.

## DNS: when the phone book lies

DNS turns names such as `bank.example` into IP addresses. If an attacker can change the answer, victims go to the attacker's server while their browser shows the right name. There are several ways to change or misuse the answer.

| Abuse | What happens | Defences |
|---|---|---|
| **Cache poisoning** | A resolver is tricked into storing a forged answer, so everyone using it gets the wrong address | Random source ports and query IDs, DNSSEC validation |
| **Domain hijacking** | The attacker takes over the registrar account and changes the real records | MFA on the registrar account, registrar lock, alerts on record changes |
| **Typosquatting and look-alikes** | `examp1e.com` or `example-login.com` registered for phishing | Monitor new registrations, register common typos, train users |
| **DNS tunnelling** | Data hidden inside DNS queries to sneak out past firewalls | Watch for very long or random subdomains and high query volume to one domain |
| **Amplification** | Small spoofed queries to open resolvers produce big replies aimed at a victim | Do not run open resolvers; rate-limit responses |

**DNSSEC** adds digital signatures to DNS records so a validating resolver can tell whether an answer is genuine. It protects the integrity of the answer, not its privacy. **DNS over HTTPS (DoH)** and **DNS over TLS (DoT)** encrypt the query between you and the resolver, which protects privacy on the local network, but they also mean the network team can no longer see those queries, which is why some companies restrict them.

### Spotting tunnelling in a DNS log

Normal lookups look like this:

```text
10:02:11 host-14 A   www.wikipedia.org
10:02:12 host-14 A   fonts.gstatic.com
```

Tunnelling often looks like this:

```text
10:15:01 host-22 TXT 4a6f686e2053...6d697468.x7q.example-c2.net
10:15:01 host-22 TXT 31323334203...9393939.x7q.example-c2.net
10:15:02 host-22 TXT 4d61696e2053...7472656574.x7q.example-c2.net
```

The giveaways: long random-looking labels (hex-encoded data), many queries per second from one host, the same unusual parent domain every time, and lots of TXT queries. None of these proves an attack on its own, but together they are worth investigating.

## HTTP: reading the web's paper trail

Every HTTP request carries a method, a path, headers and sometimes a body, and the server answers with a status code. Web server access logs record most of this, and the patterns tell you a lot:

```text
203.0.113.9 "POST /login HTTP/1.1" 401
203.0.113.9 "POST /login HTTP/1.1" 401
203.0.113.9 "POST /login HTTP/1.1" 401   (x 400 in 5 minutes)
198.51.100.7 "GET /.env HTTP/1.1" 404
198.51.100.7 "GET /wp-admin/ HTTP/1.1" 404
198.51.100.7 "GET /phpmyadmin/ HTTP/1.1" 404
192.0.2.44 "GET /download?file=../../../etc/passwd HTTP/1.1" 400
192.0.2.80 "GET /search?q=%27%20OR%201%3D1-- HTTP/1.1" 500
```

Reading it:

- **Hundreds of 401s on `/login` from one address**: password guessing (brute force) or credential stuffing with leaked passwords. Defences: rate limits, lockouts, MFA.
- **Many 404s for well-known admin paths and secret files**: an automated scanner looking for forgotten software or leaked config files. Make sure files like `.env` are never served.
- **`../` in a parameter**: a path traversal attempt to read files outside the web folder.
- **`' OR 1=1--` (URL-encoded as `%27%20OR%201%3D1--`)**: a SQL injection probe. The **500** status is the worrying part, because it suggests the input reached the database and broke a query.

### Headers defenders care about

Servers can send response headers that make browsers enforce extra rules:

- `Strict-Transport-Security` (HSTS): always use HTTPS for this site.
- `Content-Security-Policy` (CSP): only run scripts from approved sources, which limits cross-site scripting.
- `X-Content-Type-Options: nosniff` and `X-Frame-Options` / CSP `frame-ancestors`: block content-type tricks and clickjacking.
- Cookie flags `Secure`, `HttpOnly` and `SameSite`: keep session cookies off plain HTTP, away from page scripts, and out of most cross-site requests.

You will see these again in module 2.

## Common mistakes

- **Treating 404s as harmless noise.** Most are, but a scan followed by a 200 on `/.env` is a breach.
- **Only watching inbound requests.** DNS logs from your own machines are one of the best places to spot malware calling home.
- **Forgetting the registrar.** A strong server is useless if someone can log in to the domain account with a reused password and repoint the records.
- **Logging secrets.** Do not log full request bodies or authorization headers; logs get copied and shared.

## Quick recap

- DNS abuse changes or misuses the answer: poisoning, hijacking, look-alike domains, tunnelling and amplification.
- DNSSEC protects answer integrity; DoH and DoT protect query privacy.
- HTTP logs reveal brute force (many 401s), scanning (many 404s), traversal (`../`) and injection probes (odd quotes and SQL keywords, especially with 500s).
- Security headers and cookie flags tell the browser to enforce extra protections.


Recognise how attackers abuse DNS and HTTP, and spot the patterns those attacks leave in logs.

DNS and HTTP in 6 minutes

DNS Attacks - CompTIA Security+ SY0-701 - 2.4

DNS Cache Poisoning - Computerphile

## Why it matters

The padlock in the address bar is one of the most misunderstood symbols on the internet. People read it as "this site is safe". It actually means something narrower and very important: **the connection between you and this server is private and has not been tampered with, and the server proved it owns this name.** Knowing exactly what TLS (Transport Layer Security) does and does not promise is basic knowledge for anyone defending systems.

## What TLS protects

TLS sits between TCP and the application protocol (HTTP, SMTP, IMAP and many others). It provides three things for data **in transit**:

1. **Confidentiality.** After the handshake, traffic is encrypted with a symmetric key that only the two ends know. Someone on the same café Wi-Fi sees scrambled bytes.
2. **Integrity.** Every record carries an authentication tag. If anyone changes a single bit on the way, the receiver detects it and drops the connection.
3. **Server authentication.** The server presents a **certificate**: its public key plus its domain name, signed by a **certificate authority (CA)** that your browser or operating system already trusts. The server proves it holds the matching private key during the handshake.

## How certificate trust works

A certificate is checked as a chain:

```text
Root CA (preinstalled in your OS or browser trust store)
  └── Intermediate CA (signed by the root)
        └── www.example.com certificate (signed by the intermediate)
```

The client checks that each signature is valid, that the chain ends at a trusted root, that the certificate has not expired, and that the name in the certificate matches the name you typed. If any check fails, the browser shows a full-page warning. That warning is TLS doing its job.

You can look at a certificate yourself:

```bash
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null \
  | openssl x509 -noout -subject -issuer -dates
```

The output shows who the certificate is for (`subject`), who signed it (`issuer`) and when it is valid (`notBefore`, `notAfter`). In a browser, clicking the padlock shows the same details.

## The attack TLS stops: on-path interception

In an **on-path attack** (often called man-in-the-middle), the attacker sits between the victim and the server, for example with a fake Wi-Fi hotspot or by poisoning ARP or DNS on a local network. Without TLS they can read and change everything: passwords, session cookies, the downloaded file.

With TLS, the attacker can still intercept the traffic, but:

- They cannot read it, because they do not have the session keys.
- They cannot change it without detection, because of the integrity tags.
- They cannot pretend to be the server, because no trusted CA will sign a certificate for `bank.example` to them. Their only option is to present a fake certificate, and the browser warns loudly.

This is why **clicking through certificate warnings** is dangerous, and why disabling certificate checks in code is one of the most common serious mistakes:

```python
# Never do this in real code: it turns off server authentication.
requests.get("https://api.example.com", verify=False)
```

With `verify=False` the encryption is still there, but you no longer know who you are encrypting to, so an on-path attacker can simply present their own certificate.

A related trick is **SSL stripping**: the attacker keeps the victim on plain HTTP and talks HTTPS to the server themselves. The defence is **HSTS** (`Strict-Transport-Security` header), which tells the browser to use HTTPS for that site every time, and the HSTS preload list built into browsers.

## What TLS does not protect

| Not protected | Why |
|---|---|
| **Phishing sites** | `examp1e-login.com` can get a perfectly valid certificate. The padlock proves the name, not the honesty of the owner. |
| **The endpoints** | Malware on your laptop or a breached server sees the data before encryption or after decryption. |
| **Data at rest** | Once the server receives your data and stores it, TLS is finished. Storage needs its own encryption and access control. |
| **Metadata** | Observers still see IP addresses, timing and size of traffic, and usually the site name (in DNS and the TLS handshake's server name field). |
| **Application bugs** | SQL injection or cross-site scripting arrive over TLS just as easily as normal traffic. |

## Versions and settings

Use **TLS 1.2 or 1.3** only. SSL 2.0/3.0 and TLS 1.0/1.1 are deprecated because of known weaknesses. TLS 1.3 removed old, weak options and made the handshake faster. Free certificate authorities such as Let's Encrypt, with automatic renewal, have removed most excuses for running sites without TLS. Expired certificates still cause many outages, so monitor expiry dates.

Organisations sometimes run **TLS inspection** proxies that decrypt and re-encrypt traffic to scan it, using a company root certificate installed on managed devices. It is a legitimate security tool on company equipment with clear policy, but it also concentrates risk in the proxy.

## Common mistakes

- **Reading the padlock as "trustworthy site".** It means "private connection to the owner of this name".
- **`verify=False` or "accept any certificate" in code**, often added to silence an error during testing and never removed.
- **Mixed content**: an HTTPS page loading scripts over HTTP, which lets an attacker change those scripts.
- **Forgetting internal services.** Traffic between your own servers crosses networks too; encrypt it.

## Quick recap

- TLS gives confidentiality, integrity and server authentication for data in transit.
- Trust comes from certificate chains ending at a CA in your trust store, plus a name match and a valid date.
- TLS defeats on-path attackers only if certificate checks stay on; HSTS stops downgrade to HTTP.
- It does not stop phishing, compromised endpoints, application bugs, or exposure of data at rest and metadata.


Explain what TLS protects (confidentiality, integrity, server identity in transit) and what it does not protect.

Why TLS matters

Transport Layer Security (TLS) - Computerphile

On-path Attacks - CompTIA Security+ SY0-701 - 2.4

Packets, ports, DNS, HTTP and TLS seen as attack surface: what is exposed, how it is abused, and what the abuse looks like in logs.