Post cover image

August 20, 2026

From Open Ports to Vulnerabilities: My Hands-On Practice with Nmap and GVM

When learning cybersecurity, it is easy to run a command, see some output, and move on.

By Cybersage

7 min read

For example, you might run an Nmap scan and see a list of open ports:

21
22
53
80
139
445

But the real learning begins when you start asking questions.

What is running on these ports?

Which services are exposed?

Are the versions outdated?

Do these services have known vulnerabilities?

Are the scanner findings real risks or possible false positives?

That is what I explored during my recent hands-on practice with Nmap and GVM/OpenVAS.

In this lab, I performed reconnaissance and vulnerability scanning against an authorized practice target.

The target was:

10.6.6.23
gravemind.vm

This post explains my complete process and, more importantly, what I learned from it.

All activities described here were performed in an authorized practice environment for educational purposes.

Step 1: Start with the attack surface

Before checking for vulnerabilities, I needed to understand what the target was exposing to the network.

I started with:

nmap -sV 10.6.6.23
None

The -sV option tells Nmap to detect services and attempt to identify their versions.

The scan showed several open ports.

21/tcp   FTP
22/tcp   SSH
53/tcp   DNS
80/tcp   HTTP
139/tcp  NetBIOS
445/tcp  SMB

Immediately, I had a much clearer picture of the target.

It was not just "a machine on the network."

It was a machine exposing multiple network services.

Conceptually, the attack surface looked like this:

Target: 10.6.6.23
FTP       SSH       DNS      HTTP       SMB
21/tcp    22/tcp    53/tcp   80/tcp   139/445

This is why port scanning is such an important first step.

You cannot properly assess a system if you do not know what is accessible.

Looking at the services

The scan detected vsftpd on port 21.

FTP immediately caught my attention because traditional FTP is not designed to protect credentials and data in the same way as encrypted alternatives.

Then there was SSH on port 22.

SSH is commonly used for remote administration, so its configuration and version are important from a security perspective.

Port 53 was running a DNS service.

Port 80 was running an nginx web server.

Finally, ports 139 and 445 indicated Samba/SMB-related services.

Each open service represents something that should be understood and assessed.

An open port is not automatically a vulnerability.

But every exposed service is part of the overall attack surface.

Step 2: What operating system is running?

After identifying the services, I attempted operating system detection.

I used:

nmap -O 10.6.6.23
None

The results suggested that the target was running Linux.

The output also indicated:

Device Type: General Purpose
Running: Linux
Network Distance: 1 hop

This information can be useful when assessing a target because operating systems have different:

  • Services
  • Configurations
  • Patch levels
  • Security controls
  • Vulnerability histories

However, one thing I learned is that OS detection is not always exact.

Nmap is making an educated estimate based on how the target responds to network probes.

So the result should be treated as useful intelligence, not necessarily absolute proof.

Step 3: Checking for known vulnerabilities with Nmap

Once I knew the services and versions, I wanted to see whether the detected software was associated with known vulnerabilities.

I used:

nmap -sV --script vulners --script-args mincvss=4 10.6.6.23
None

This command combined service/version detection with the Vulners NSE script.

The mincvss=4 argument helped filter the results so that lower-severity vulnerability references were not the main focus.

The scan returned vulnerability references associated with some detected software versions.

I saw CVE information and severity scores related to services such as FTP and SSH.

This was an important moment in the lab because I learned something that every beginner should understand:

A CVE in scanner output does not automatically mean the system is vulnerable.

The scanner may see a particular software version and associate it with publicly known vulnerabilities.

But in a real assessment, I would still need to verify:

  • Is that exact version actually installed?
  • Has the vulnerability been patched by the distribution?
  • Is the vulnerable feature enabled?
  • Is the service configuration relevant?
  • Is the vulnerability remotely exploitable?
  • Is the finding a false positive?

So vulnerability scanning should not be confused with vulnerability exploitation.

Scanning identifies potential risks.

Validation determines the actual risk.

Step 4: Moving from Nmap to GVM/OpenVAS

After using Nmap, I wanted to perform a broader vulnerability assessment.

For this, I used Greenbone Vulnerability Management, commonly known through GVM/OpenVAS.

Before starting, I checked the installation:

sudo gvm-check-setup
None None None None

The output verified important components such as:

  • OpenVAS Scanner
  • Notus Scanner
  • Redis
  • GVM services
  • Network Vulnerability Tests
  • Feed and configuration components

The setup check confirmed that the main services were active and ready.

Once everything was prepared, I opened the Greenbone Security Assistant web interface.

Step 5: Creating the vulnerability scan

Inside GVM, I created an immediate scan against:

10.6.6.23

GVM handled the workflow of:

Target Creation
↓
Task Creation
↓
Scan Execution
↓
Vulnerability Checks
↓
Report Generation

At this point, I could see the difference between Nmap and GVM more clearly.

Nmap gave me a strong understanding of what was exposed.

GVM went further by systematically checking the target for known security issues and organizing the results into a report.

Step 6: Analyzing the GVM results

The completed scan reported multiple findings with different severity levels.

One of the highest-severity findings was:

Operating System (OS) End of Life (EOL) Detection
Severity: 10.0

The scan also reported medium-severity FTP-related issues.

These included:

Anonymous FTP Login Reporting
Severity: 6.4

and:

FTP Unencrypted Cleartext Login
Severity: 4.8

There were also lower-severity information disclosure findings related to:

TCP Timestamps
ICMP Timestamp Reply

The findings gave me a much broader picture of the target's security posture.

Scanning Report ::

None

What does an End-of-Life operating system finding mean?

This was one of the most important findings from the scan.

An operating system that has reached End of Life may no longer receive security updates.

That creates a serious security concern.

Imagine a new vulnerability is discovered in an unsupported system.

If the vendor no longer provides patches, the organization may be left with a permanently exposed system.

This is why asset management and patch management are so important.

A vulnerability assessment is not only about finding technical flaws.

Sometimes the problem is that an organization is simply running software that is no longer supported.

Anonymous FTP: Why is it important?

The scan also reported anonymous FTP access.

Depending on the configuration, anonymous access could expose files that should not be publicly available.

Potential problems could include:

  • Sensitive files being readable
  • Internal information being exposed
  • Upload functionality being enabled
  • Misconfigured directory permissions

In a real environment, the next step would be to validate exactly what level of access is available.

This is another example of why scanning and validation are both important.

FTP cleartext authentication

The scan also reported that FTP authentication may occur without encryption.

Traditional FTP can transmit usernames and passwords in a form that is not protected by modern transport encryption.

If an attacker can observe the relevant network traffic, this could expose credentials.

A more secure approach would be to use:

SFTP or FTPS

This was a good reminder that a service can be functioning correctly from an operational perspective while still being a poor security choice.

Low severity does not mean "ignore it"

The scan also found information disclosure issues involving TCP and ICMP timestamps.

These findings had lower severity scores.

However, I learned that vulnerability severity should not be interpreted as:

High = important
Low = useless

Low-severity findings can still provide useful information during reconnaissance.

Attackers often combine multiple small pieces of information.

A hostname here.

A timestamp there.

A software version somewhere else.

Individually, these may not be critical.

Together, they can help build a detailed profile of a target.

Nmap and GVM: My biggest takeaway

After completing both parts of the practice, I understood their roles like this:

Nmap asks:

What is running on this target?

GVM asks:

What known security problems may affect this target?

My workflow became:

Target
|
v
Nmap Scan
|
----------------------
|         |          |
Ports    Services    Versions
|
v
Vulnerability Checks
|
v
GVM/OpenVAS
|
----------------------
|         |          |
CVEs    Severity    Findings
|
v
Validation
|
v
Remediation

I think this is one of the most useful lessons for beginners.

Do not rely on only one tool.

Use different tools to understand different parts of the security assessment process.

What I learned from this practice

This lab taught me much more than just a few commands.

First, reconnaissance comes before vulnerability analysis.

You need to know what is exposed before you can understand the risks.

Second, service versions matter.

A software version can help identify potentially relevant vulnerabilities.

Third, scanner results require validation.

A CVE reference is not the same thing as a confirmed vulnerability.

Fourth, unsupported software is a serious problem.

An End-of-Life operating system can remain vulnerable because security patches may no longer be available.

Fifth, insecure protocols still matter.

Services such as traditional FTP can introduce risks because credentials may not be protected during transmission.

Finally, vulnerability scanning is a process.

It is not:

Run tool → Get result → Finished

A better process is:

Discover
↓
Enumerate
↓
Scan
↓
Analyze
↓
Validate
↓
Prioritize
↓
Remediate

Final Thoughts

This hands-on practice helped me connect two important areas of cybersecurity:

Network reconnaissance and vulnerability assessment.

Using Nmap, I discovered the target's exposed services, software versions, and probable operating system.

Using GVM/OpenVAS, I performed a more comprehensive vulnerability assessment and reviewed findings based on severity.

The biggest lesson for me was that tools are only the starting point.

The real skill is understanding the output.

Why is this port open?

What service is running?

Is this version actually vulnerable?

How serious is the finding?

What should be fixed first?

These are the questions that turn a scan into a meaningful security assessment.

I will continue practicing vulnerability assessment and penetration-testing fundamentals through authorized labs and hands-on environments.

Always scan only systems and networks that you own or have explicit permission to test.