Technical Review and Transition to Web Pentesting

You have reached the end of the course. In seven chapters you went from the layers of the TCP/IP model to the legal framework of penetration testing, building a working laboratory along the way. This final lesson is a checkpoint: it brings the pieces together, helps you assess where you stand, prepares your lab for the next course and shows you why every notion you learned will be needed to find and understand vulnerabilities in web applications.

There are no new techniques here. The most valuable thing a learner can do at this point is consolidate, because the later courses build directly on these foundations.

What you have learned

Networks (chapters 1 and 2)

• The TCP/IP layers, encapsulation, IPv4 addressing with masks and CIDR, private ranges and NAT.
• DNS and its record types, and why it matters for both attackers and defenders.
• HTTP, HTTPS and ports: what open, closed and filtered mean, and what the padlock really guarantees.
• Routing, switches, firewalls and the DMZ architecture.
• Capturing and reading packets with Wireshark, the weakness of ARP, VLAN segmentation and IPv6.

Your laboratory (chapter 3)

• Virtual machines, hypervisors, an isolated internal network, snapshots and the rules of a safe, ethical lab.

Operating systems (chapters 4 and 5)

• The Linux command line, file system, users, permissions, sudo, processes, services, logs and bash scripting.
• Windows architecture, the registry, Active Directory and GPO, PowerShell and event logs.

Cryptography (chapter 6)

• Hashing and salting, symmetric and asymmetric encryption, certificates and the TLS handshake, key and secret management.

Towards penetration testing (chapter 7)

• The legal framework, the PTES methodology and the principles of passive reconnaissance.

A recurring theme: the same questions everywhere

If you look back, you may notice that the same handful of questions came up on every platform:

1. Who or what is here? Addresses, accounts, processes, services.
2. What is exposed? Open ports, listening services, public records.
3. Who may do what? Permissions, ACLs, groups, least privilege.
4. What is trusted without being verified? ARP replies, DNS answers, certificates, scripts.
5. What is recorded? Logs, events, audit policies.
6. What is secret, and where is it kept? Passwords, keys, tokens.

Vulnerabilities are, in the end, answers to these questions that someone forgot to examine. In the web course, you will ask them about applications: who is this user, what does this page expose, which part of the request is trusted, what does the server log, where are the secrets?

Why these foundations matter for web pentesting

Here is the direct connection to course 3, "Web pentesting: understanding vulnerabilities":

What you learned here	How you will use it in the web course
HTTP methods, headers, cookies, status codes	Reading and modifying requests with an intercepting proxy; understanding sessions, access control and security headers
HTTPS and certificates	Configuring the proxy to inspect your own lab traffic; spotting weak TLS configuration
DNS and ports	Mapping an application's hosts and services
Linux, permissions and logs	Running vulnerable applications in your lab, and reading the logs to see what an attack looks like from the server side
Hashing, salting and secrets	Understanding authentication flaws, password storage and token handling
Lab and snapshots	Breaking and restoring intentionally vulnerable applications safely
Legal framework and PTES	Working only on legal training targets and structuring your findings in a notebook and a report

Preparing your lab for the next course

In course 3 you will use a Kali VM and a vulnerable web application hosted in a lab VM. Here is the checklist to complete before you move on:

1. Your Kali VM is updated, snapshotted, and attached only to the isolated lab network (NAT off except for updates).
2. Your Linux server VM is working with a static address in labnet, and you can reach it from Kali.
3. You have a snapshot named "clean baseline" for each machine.
4. You have a lab notebook with the network diagram, the address plan, the list of machines and the installed software.
5. You have read again the lab charter of chapter 3 and the legal lesson of this chapter.
6. You have at least 20 GB of free disk space and enough RAM to run two VMs at once.

The training targets that you will use are intentionally vulnerable web applications such as DVWA and OWASP Juice Shop (run in your own lab), and the exercises of the PortSwigger Web Security Academy, TryHackMe and HackTheBox, whose platforms are designed to be attacked within their rules. Do not search for other targets, and do not test anything that is not explicitly one of these or your own.

Self-assessment

Be honest with yourself. For each statement, you should be able to answer "yes" or explain the notion in your own words. If not, revisit the matching lesson before the next course.

• I can calculate the network address and the broadcast address of a /24 and explain what a default gateway is.
• I can explain what happens between typing a URL and seeing the page: DNS, TCP, TLS, HTTP.
• I can capture traffic in a lab and apply a display filter in Wireshark.
• I can explain why ARP is sensitive and name two protections.
• I can build an isolated lab network and use snapshots.
• I can read file permissions, change them with chmod and explain the role of sudo.
• I can find a failed SSH login in the logs of a Linux machine.
• I can explain what Active Directory, a domain controller and a GPO are.
• I can name three Windows event IDs and what they signify.
• I can explain the difference between hashing, symmetric and asymmetric encryption, and how a TLS handshake establishes trust.
• I can explain why a penetration test needs written authorisation and a defined scope, and cite the French articles on fraudulent access.

Your turn: write your lab report

Produce a short final document, "Lab report: foundations", of one to two pages that you could show to a future employer. It should contain: the network diagram of your lab with addresses; the list of machines, their operating systems and roles; three things you observed with Wireshark, with a screenshot or a description; the output of your Linux audit script and of your Windows inventory script (with any sensitive data removed); a short paragraph on the legal rules you follow; and a list of the three notions that you found hardest and what you will do to master them.

See a solution

A good report is concise and honest. Example of a structure: 1. Objective of the lab. 2. Diagram (one segment, labnet, 10.10.10.0/24, with Kali at .10, the Linux server at .20 and the optional Windows machine at .30). 3. Machine inventory. 4. Observations (a DNS lookup seen in a capture; an ARP exchange; a failed SSH login in the journal). 5. Hardening ideas for the Linux server (disable unused services, restrict SSH, review sudo rules, keep the system updated). 6. Legal and ethical commitments. 7. Learning gaps and a plan. The learning-gaps section is the most valuable: knowing what you do not yet master shows maturity, and it tells you what to review in the next weeks.