Service Discovery and Vulnerability Research

Lesson plan

Level

Beginner

Time

About 60 minutes; the steps below add up to 59

Learners work out what they must know about a server before judging a known weakness, and how one address serves several services, before ports and services are defined. Predictions then precede which activity touches the target, what an invented scan gives you, how a version result could be wrong, the order of the workflow, the most precise source, what a CVE match still leaves open and whether an easy target is a fair one; checks follow port numbers, authorisation, validation and exploit code. The habit to build: a version is a lead, a match is a hypothesis, and every step that touches a system needs permission.

Objectives

• Explain ports and services, and why a port number is a hint and not proof
• Tell discovery, research and exploitation apart, and say which need authorisation
• Read the columns of an Nmap version scan and treat its results as evidence to check
• Follow a research workflow from an observed version to an applicability decision
• Explain why a matching CVE is a hypothesis, not confirmation

Before the lesson

• Open this page on your own screen and use “Open the lesson window” to open the lesson in a second window. Share only that second window.
• Learners need the Ports and Sockets, Vulnerabilities and Exposure, Ethics and Authorisation and Virtual Machines lessons first.
• All scan output in the lesson is invented. Do not show real scans of any system in the session.
• The lesson takes about 59 minutes.
• In presentation mode every step is shown in turns: Next reveals one moment, part or answer at a time, and the instructor view names what is on screen and what comes next.

Steps

1. Introduction Opening

   On screen: the lesson’s title, module and number; Next adds its objectives and key terms, as the lesson page lists them; Next again begins the first step.

   Objectives on screen

   • Explain ports and services, and why a port number is a hint and not proof
   • Tell discovery, research and exploitation apart, and say which need authorisation
   • Read the columns of an Nmap version scan and treat its results as evidence to check
   • Follow a research workflow from an observed version to an applicability decision
   • Explain why a matching CVE is a hypothesis, not confirmation

   Purpose: Learners work out what they must know about a server before judging a known weakness, and how one address serves several services, before ports and services are defined. Predictions then precede which activity touches the target, what an invented scan gives you, how a version result could be wrong, the order of the workflow, the most precise source, what a CVE match still leaves open and whether an easy target is a fair one; checks follow port numbers, authorisation, validation and exploit code. The habit to build: a version is a lead, a match is a hypothesis, and every step that touches a system needs permission.

2. 1. What is it running? Think 5 min

   Purpose: Raise the need to know what is running, and the role of ports.

   Ask

   • What must you find out first?
   • How does traffic reach the right service?

   Responses to expect

   • “The version” comes quickly; services and ports need a prompt.
   • On screen in turns: the opening question, its answer; then the question on one address with three services, and its answer.

   Discussion pause: Collect suggestions before revealing.

   In the lesson window

   • Think it through: You are asked whether a server is affected by a known weakness in some web software. What do you need to find out about the server before you can even start to answer?
   • Think it through: One server offers a website, file transfer and remote sign-in, all at the same IP address. How does incoming traffic reach the right one?

3. 2. Ports and services Explain 5 min

   Purpose: Define port and network service, and the limits of a port number.

   Ask

   • Does an open port 80 prove a web server?

   Responses to expect

   • Many say yes.
   • On screen in turns: the opening; then the port; the network service; the check question on port 80, and its answer; every service is exposure.

   Misconceptions to challenge

   • A learner may believe: “A port number tells you exactly what is running.” Respond: It is a strong hint; any service can listen on any port.

   In the lesson window

   • Check your understanding: A scan finds port 80 open. Does that prove a web server is running?

4. 3. Discovery, research and exploitation Predict 6 min

   Purpose: Separate the three activities and their need for authorisation.

   Ask

   • Which sends traffic, and which tries to change the target?
   • Which needs no permission?

   Responses to expect

   • Learners often think scanning is harmless.
   • On screen in turns: the opening; then the question on which activities touch the target, and its answer; three activities compared; research stays away from the target; the check question on what needs no permission, and its answer.

   Misconceptions to challenge

   • A learner may believe: “Scanning is harmless, so it does not need permission.” Respond: It sends traffic to someone else’s system and needs authorisation.

   In the lesson window

   • Think it through: Finding which services a server runs, reading about known weaknesses in them, and trying to use a weakness: which of these sends traffic to the target, and which tries to change what it does?
   • Check your understanding: Which of the three activities can be done without the target owner’s authorisation?

5. 4. Service and version detection with Nmap Predict 9 min

   Purpose: Read the version-scan command and columns, and the limits of version detection.

   Ask

   • Which rows can be researched?
   • How could the version be wrong?

   Responses to expect

   • Port 8080 is often guessed at.
   • On screen in turns: the opening; then reading the results: the four columns; an invented result; the question on the three rows, and its answer; one row at a time, starting with port 22; port 80; port 8080; what the three rows give you; the question on how the version could be wrong, and its answer; how version detection works.

   Misconceptions to challenge

   • A learner may believe: “Nmap told me the version, so that is what is installed.” Respond: It is inference from responses; banners can be changed.

   In the lesson window

   • Think it through: Look at the invented result. Which rows give you something to research, and what should you write down for port 8080?
   • Think it through: Nmap reports “Examplesrv 2.3”. How could that be wrong?

6. 5. From version to vulnerability: a research workflow Predict 6 min

   Purpose: Order the research workflow and show why each step depends on the last.

   Ask

   • What is the right order?
   • What goes wrong without validation?

   Responses to expect

   • Testing is sometimes placed before research.
   • Diagram: step through the workflow after the class has ordered the steps; compare their order with each step as it appears.
   • On screen in turns: the opening; then the question on putting the steps in order, and its answer; the research workflow, one step at a time; the diagram’s stages one at a time; the check question on skipping validation, and its answer; each step depends on the one before.

   In the lesson window

   • Think it through: Put these in order: research the version, find the open ports, test (if authorised), identify the service, check the vulnerability really applies.
   • Check your understanding: In the workflow, what goes wrong if you skip applicability validation?

7. 6. Where to research Predict 4 min

   Purpose: Compare CVE records, the NVD, vendor advisories and exploit databases.

   Ask

   • Where is the most precise answer?

   Responses to expect

   • The vendor’s advisory.
   • On screen in turns: the opening question, its answer; then four places to research, starting with CVE records; the NVD; vendor advisories; exploit databases.

   In the lesson window

   • Think it through: You want to know precisely which versions of a product a flaw affects, and which update fixes it. Where would you expect the most precise answer?

8. 7. Why a match is not confirmation Predict 8 min

   Purpose: Set out what a match leaves open, and record a lead with the fictional example.

   Ask

   • What would you still need to check?
   • Does exploit code prove anything about your server?

   Responses to expect

   • Backports are new to most learners.
   • On screen in turns: the opening; then the question on what still needs checking, and its answer; six checks, starting with similar product names; version ranges; configuration; backported patches; vendor advisories; exploit availability; the check question on public exploit code, and its answer; recording a lead responsibly, starting with the observation; the research; the comparison; the decision; stopping there.

   Misconceptions to challenge

   • A learner may believe: “There is a CVE for this version, so the system is vulnerable.” Respond: It must be checked against what was observed.

   Discussion pause: Reveal the six checks one at a time, after the class has listed its own; tick off the ones they found.

   To go further

   • How could you find out whether a vendor has backported a fix, without testing the system?

   In the lesson window

   • Think it through: A CVE record mentions the product your scan found. List what you would still need to check before saying the system is affected.
   • Check your understanding: Exploit code for a flaw in Examplesrv 2.3 appears in a public database. Does that show your lab server is vulnerable?

9. 8. Authorisation still applies Predict 3 min

   Purpose: Restate that every step touching a target needs permission within scope.

   Ask

   • Is an easy, out-of-date router a fair target?

   Responses to expect

   • No: being reachable gives no permission.
   • On screen in turns: the opening question, its answer; then every scan needs permission; reporting with confidence.

   In the lesson window

   • Think it through: A neighbour’s home router is easy to reach and probably out of date. Is it a suitable target to practise scanning on?

10. 9. Apply it in a new situation Apply 4 min

    Purpose: Set up independent application, ideally on a later day.

    Ask

    • Who will try these now, and who later in the week?

    Responses to expect

    • The report wording tests confidence; port 9100 tests honesty about gaps; the target tests authorisation.
    • On screen in turns: the opening; then the question on report wording, and its answer; the question on an unknown service, and its answer; the question on a practice target, and its answer.

    If the explanation does not land: Have pairs write a one-line finding for the Examplesrv row, then compare wordings.

    In the lesson window

    • Apply it: An authorised scan of a client’s server suggests a version in a CVE’s affected range, but the required module may or may not be enabled. Which report wording is best?
    • Apply it: A scan shows port 9100 open with SERVICE “unknown”. A colleague writes “printer service” in the report. What is the problem?
    • Apply it: A learner practising version scans needs a target. Which is suitable?

11. 10. Check your understanding Check 6 min

    Purpose: Check the lesson against the approved revision-bank questions.

    Ask

    • Answer individually, then compare before revealing.

    Responses to expect

    • The backport question links to the match step.
    • On screen in turns: the opening; then the revision questions one at a time, each followed by its answer; where to practise next.

12. 11. What to remember Consolidate 3 min

    Purpose: Summarise the five points, the key terms and the misunderstandings.

    Ask

    • Without looking: the rule about versions and CVE matches.

    Responses to expect

    • A detected version is a lead; a matching CVE is a hypothesis.
    • On screen in turns: the opening; then the summary; the key terms; the common misunderstandings.

13. Lesson recap Closing

    On screen: the lesson’s objectives again; Next adds the closing question, which asks the class to explain each one in their own words without looking back. It says nothing about what anyone has learnt: use the answers to decide what to revisit.

    Points to listen for

    • Ports are hints, not proof.
    • Research reads; discovery and exploitation touch the target.
    • A version scan is evidence to check.
    • A match is a hypothesis; validate it.
    • Permission and scope come first, always.

Consolidation

• Ports are hints, not proof.
• Research reads; discovery and exploitation touch the target.
• A version scan is evidence to check.
• A match is a hypothesis; validate it.
• Permission and scope come first, always.