20. Vulnerability Scanning and Assessment
Chala mitrano, Chapter 19 madhe aapan target chi yaadi banavli – konte ports ughde, konti service, konta version. Aata pudhcha prashna: ya versions madhe kontya kamjorya (vulnerabilities / असुरक्षितता) aahet? Doctor aadhi report baghto, mag upchar tharavto. Aapan pan aadhi vulnerability shodhu, tyanna gambhirtenusar kramvar lavu, aani mag report karu. Lakshat theva – vulnerability scanner "hack" karat nahi, to fakt sangto kuthe dhoka aahe. Aani punha ekda: sagle labs fakt tumchya host-only lab var (Metasploitable 2 192.168.56.20). Samjla ka? Chala suru karuya!
What you will learn in this chapter
- What a vulnerability is, and the words CVE, CWE and CVSS
- Finding known vulnerabilities manually with searchsploit and the NVD website
- Nmap vulnerability scripts as a quick first check
- OpenVAS / Greenbone: installing and running a full network vulnerability scan
- Nikto for web server scanning
- Reading results, removing false positives and prioritising fixes
- Writing a clear vulnerability report – the real product of an assessment
Lab scope for this whole chapter
Vulnerability scanners send thousands of requests and can crash old services. Run every scan in this chapter only against Metasploitable 2 (192.168.56.20), DVWA or Juice Shop on your host-only network – never against any website or server you do not own.
Concepts in this chapter
- 20.1Vulnerability, CVE, CWE and CVSS
- 20.2Manual Lookup: searchsploit and Exploit-DB
- 20.3Nmap Vulnerability Scripts
- 20.4OpenVAS / Greenbone: Full Vulnerability Scanning
- 20.5Nikto: Web Server Scanning
- 20.6Reading Results: False Positives and Prioritising
- 20.7Writing a Vulnerability Report
- 20.8Red vs Blue, Project and Real Incidents
The chapter recap is at the end of the last concept page.
Chapter 20: Vulnerability scanning — practice tasks
Open chapter lessons · Full guided lab: patch outdated package verify cve fixed (not repeated here)
20.1 Rank findings by CVSS (paper)
EasyBankingWhy: You can't fix everything at once.
What: Sort the data file by risk.
Data file: findings.csv
| ID | CVSS | Internet-facing |
|---|---|---|
| CVE-A | 9.8 | Yes |
| CVE-B | 5.3 | No |
| CVE-C | 7.5 | Yes |
About this file: Made-up scan findings. Each row is one finding. Columns: ID = finding name; CVSS = severity 0–10; Internet-facing = reachable from the internet.
How:
- Sort by CVSS high to low.
- Bump internet-facing items up.
Expected output: CVE-A first, then CVE-C, then CVE-B.
Hint
Exposure matters as much as score.
Answer / how to check
- Top item: highest CVSS and internet-facing.
20.2 Scan a Docker image with Trivy
MediumITWhy: Old images carry known CVEs.
What: Scan nginx:1.19 vs nginx:latest.
How:
docker run --rm aquasec/trivy image --severity HIGH,CRITICAL nginx:1.19- Repeat for nginx:latest.
Expected output: 1.19 shows many more HIGH/CRITICAL.
Hint
Count with the summary line.
Answer / how to check
- latest has fewer findings.
20.3 Run Nikto on your lab nginx
EasyRetailWhy: Quick web misconfig check.
What: Scan your own VM's HTTP.
How:
nikto -h http://192.168.56.101- Note missing headers.
Expected output: Missing X-Frame-Options etc.
Hint
Fix with the linked headers lab.
Answer / how to check
- Re-scan after fixes shows fewer items.
What this chapter adds
Chapter 19 told you which ports and versions are open. This chapter asks: which of those versions have known weaknesses, how serious are they, and how do you write that down so someone can fix them?
Real-world picture
Indian CERT-In advisories and the US CISA Known Exploited Vulnerabilities (KEV) catalogue both exist to help defenders prioritise. A CVE on KEV is not a theory. It is being used in the wild. Your report should highlight those first.
After this lesson you will be able to
- Explain CVE, CWE and CVSS in one sentence each.
- Use searchsploit and Nmap scripts on lab VMs only.
- Run a Greenbone/OpenVAS scan in the lab and read the report.
- Write one finding in professional report format.
Recap
- Scanners find. Humans prioritise and fix.
- Permission and host-only networking still apply.
Defender's worksheet (do this today)
- Write the lesson title and date in your notebook.
- List three systems you own (VMs, personal projects, or lab apps) where this lesson applies.
- Run one safe command or checklist item from the lesson on a lab system only.
- Paste the command and its output under an Evidence heading.
- Write one fix you would give a teammate in two sentences.
- Write one mistake students make with this topic and how to avoid it.
More real-world pictures
Indian workplace (sample data)
Suppose we are a junior analyst at Tech Mahindra supporting a client SOC. After reading this lesson you add one detection or one hardening item to the team weekly checklist, with the owner name and a due date. That is how learning becomes operations.
Global practice
Public bodies such as CERT-In (India), CISA (US) and NCSC (UK) publish advisories that map to the same ideas: patch, least privilege, logging and user awareness. Bookmark one advisory feed and read it every Monday.
Home and family
Explain this lesson to a family member in four sentences without jargon. If they can repeat the main warning back to you, you understand it well enough to teach.
Connect to earlier chapters
Parts 1 to 9 built Linux, web servers, databases and cloud pieces. This lesson only makes sense when you can point to a concrete config file, package name or architecture box from those parts. If you cannot, revisit the matching earlier chapter before you practise any tool command.
Common mistakes
- Skipping written permission just for a quick scan.
- Practising on hostel or office Wi-Fi targets without authorisation.
- Collecting tool output without writing the fix.
- Copying exploit commands onto production to verify. Verification for defenders means checking versions and patches, not firing modules.
Recap
- Evidence, fix, owner, date.
- Own lab only.
- Teach one other person the warning from this lesson.