Check an Update Against Its Network Change Plan

NmapBeginner
Practice Now

Introduction

Willow Makers approved moving registration to a new port. Its catalog and status service must remain available, and the debug service must remain absent. Your task is to review the resulting network changes and deliver an accurate handover review, including anything that prevents acceptance.

The environment prepared a real baseline scan, then performed a local maintenance scenario. This is training preparation, not a claim about last night's production history. All records are synthetic; the real HTTP services share one container. Use Terminal throughout. Only 127.0.0.4 and TCP ports 8410,8420,8430,8440,8450 are in scope. Preserve the baseline, plan, service code, data and original current processes. You create scans, downloads and a review; you do not repair this observation-only scene.

Basic terminal input and paths are sufficient. The required Nmap, Ndiff, HTTP and shell syntax are explained. Finding the Live Workshop Service is useful preparation, but no programming is required.

Read the Plan and a Working Service

In this step, you will establish what was approved and see a normal response before interpreting changes. Start in Terminal. cd changes this shell's working directory; relative filenames below refer to it. Repeat this command if you open another terminal.

cd /home/labex/project/nmap-change

cat displays a text file. Read the approval plan:

cat plan.csv

CSV means comma-separated values: the first line names the columns, and each later line is one record. old_port and new_port describe the service relationship, not the order you should scan. The rows approve moving registration from 8410 to 8420, keeping catalog on 8430 and status on 8440, and keeping debug on 8450 absent. An open new registration port is therefore an expected change; any other opening is not automatically approved.

The prepared before.xml is genuine Nmap XML from before this training update. before-business.csv contains the complete registration response obtained at that time. Read the normal business sample:

cat before-business.csv

Expect three records for registration at MAKERS-DAY: R01/Clay session, R02/Print session and R03/Wood session. You will require the same complete business after the move.

HTTP is the request/response protocol used by these services. curl fetches a URL. The combined -fsS options fail on an HTTP error, hide the progress meter and still show errors; -o saves the response to the following filename. The address selects the destination, the port after the colon selects its listener, and /manifest.csv selects the resource. Download the unchanged status service:

curl -fsS -o status.csv http://127.0.0.4:8440/manifest.csv
cat status.csv

Expect status/MAKERS-DAY/S01/Ready below the header. This successful response is your control, not proof that every planned service survived. If a filename is mistyped, read the error, use pwd to show the current directory, and repeat the initial cd before retrying the corrected command. Do not edit the prepared files or servers.

Collect a Comparable Current Scan

In this step, you will scan the same target and complete port set as the baseline. Stay in Terminal in /home/labex/project/nmap-change. TCP ports identify listening endpoints. open means a connection was accepted; closed means the scan received a rejection. An observation belongs to this source, target, protocol and time.

Nmap discovers and examines network services. Its default port set is not this approval plan. -sT chooses TCP connect scanning without raw-packet privileges; -Pn skips the preliminary host-discovery decision so every selected port is examined. It does not itself prove that the target is alive. -n skips reverse name resolution, -p selects the permitted ports, and -oX writes structured XML as well as normal terminal output. Missing a port would make the comparison incomplete, not prove that its service vanished.

The Nmap Scripting Engine, or NSE, can make focused application requests. Use --script-help to read the selected script's help first:

nmap --script-help http-title

http-title reads an HTML title. All candidates in this local scenario are declared HTTP endpoints. The leading + explicitly runs this one script even when the port database does not recognize a candidate; it is appropriate within this known HTTP scope, not a reason to force arbitrary scripts on unrelated services. --script-args passes its named argument, and http-title.url=/about selects the descriptive page.

nmap -sT -Pn -n --script=+http-title --script-args=http-title.url=/about -p 8410,8420,8430,8440,8450 -oX after.xml 127.0.0.4

Wait for Nmap done. Ports 8420, 8440 and 8450 should be open; 8410 and 8430 should be closed. Read the real title responses: registration moved, status remains, and debug is reachable. A conventional SERVICE name alone does not identify the business. No exact product version is required.

If you interrupted the scan or used the wrong scope, rerun the complete corrected command to replace after.xml. Renaming plain text to XML cannot create structured evidence.

Separate Differences from Execution Errors

In this step, you will use Ndiff to read changes without treating every difference as a fault. Stay in Terminal. Ndiff compares two Nmap XML files; it does not know your approval plan.

A shell command returns a numeric exit status. $? refers to the immediately preceding command, and echo prints it. Keep each two-line comparison together so another command does not replace that status. First compare the baseline with itself:

ndiff before.xml before.xml
echo $?

Expect 0: no meaningful difference. Ndiff ignores scan timing alone. Now compare before and after. > replaces the named output file with the command's standard output; use only the editable changes.txt destination:

ndiff before.xml after.xml > changes.txt
echo $?

Expect 1, meaning differences were found. This is an intentional nonzero status, not a failed comparison. A missing or unreadable input produces status 2, which is an execution error; correct its path and rerun rather than interpreting a missing report as no change.

cat changes.txt

A - line describes the earlier observation and a + line the later observation. Read these pairs:

-8410/tcp open
+8410/tcp closed
-8420/tcp closed
+8420/tcp open
-8430/tcp open
+8430/tcp closed
-8450/tcp closed
+8450/tcp open

The real output also includes headings, service names and titles. Status on 8440 has not changed and is normally omitted from the default difference view. You must still review its keep requirement. The old/new registration pair can be approved while catalog loss and debug exposure block handover.

Deliver the Business and Change Review

In this step, you will confirm the actual moved business and deliver a complete review. Stay in Terminal. A title or open port does not prove that the original records survived. Download the new endpoint's complete response:

curl -fsS -o current-business.csv http://127.0.0.4:8420/manifest.csv
cat current-business.csv

cmp compares two files byte for byte. It prints nothing and returns zero when they match:

cmp before-business.csv current-business.csv

You should see all three original MAKERS-DAY registration records and a successful comparison. If a URL was mistyped, correct it and repeat the download. Do not edit records to make the comparison pass. A real business mismatch would be a handover problem even with matching page titles.

The review CSV has four columns: service, the current state at its old port, the current state at its new port, and the decision. When an item keeps one fixed port, including a keep or absent requirement, its old and new ports are the same, so their current states repeat. Use - only when there was no old port; it never means a closed port. Decisions distinguish approved-move, approved-addition, kept, unexpected-loss and unexpected-open. A migration whose old/new relationship is incomplete would be migration-incomplete; a missing approved addition would be missing-addition, while a forbidden endpoint that remains closed is kept-absent.

A quoted here-document writes the following literal lines to cat. > replaces only your review file; the final CSV must appear alone on its line. Write the four plan items:

cat > change-review.csv <<'CSV'
service,old_port_now,new_port_now,decision
registration,closed,open,approved-move
catalog,closed,closed,unexpected-loss
status,open,open,kept
debug,open,open,unexpected-open
CSV
cat change-review.csv

This review says to hold handover: the approved move works, but the required catalog is missing and debug is unexpectedly exposed. You have completed the review even though the scene needs later repair by its owner. Preserve that evidence; do not stop debug or restore catalog in this task.

Finally, use the original status service again:

curl -fsS -o status.csv http://127.0.0.4:8440/manifest.csv

It must still supply the same Ready record. Keep before.xml, before-business.csv, plan.csv and every original current service unchanged.

Summary

You collected comparable Nmap evidence, interpreted Ndiff exit statuses, confirmed the complete migrated business, and reviewed every approval relationship. Approved differences, unexpected openings and lost required services are distinct findings. An accurate review can require holding handover while preserving the original scene.