Internal Network Security Evaluation | Projects

Mapping an undocumented network

This third-year Computer Networking 2 assessment used a supplied internal lab scenario: an organisation had no usable network documentation and needed its connected systems mapped and evaluated. I worked from an assigned Kali Linux host and treated the exercise as both a network-discovery problem and a security assessment.

I began with the address and subnet assigned to the test machine, calculated the local network boundary, and discovered reachable hosts. Each new route or host revealed more of the topology. The final report documented multiple routed subnets, routers, endpoint systems, servers, a DMZ, and a firewall rather than presenting the environment as a flat list of scan results.

Assessment method

I treated the topology as an evidence problem. The initial Kali system provided only its local interface, subnet mask, and default route. From there, I recorded:

each responsive host and the services it exposed
which router interface connected to each network
directly connected and OSPF-learned routes
trust relationships created by NFS, SSH keys, and reused accounts
the route or pivot required to reach every later finding
the difference between a service being present, being misconfigured, and being usable as part of an access path

The toolset covered discovery, service review, web enumeration, authentication testing, local evidence analysis, and controlled exploitation of supplied vulnerable services.

Tool or facility	Use in the assessment
Nmap	Host discovery, service identification, version checks, and selected vulnerability scripts
SSH	Administration of reached hosts and tunnel transport between isolated lab segments
VyOS route and interface data	Reconstruction of directly connected networks, next hops, and OSPF paths
NFS inspection	Review of exported paths, identity mapping, and exposed authentication material
Dirbuster, WPScan, and Nikto	Web-content discovery and application or server enumeration
Hydra and John the Ripper	Controlled testing of weak authentication and recovered password hashes
Metasploit	Validation of known vulnerabilities in the deliberately vulnerable lab services
`iptables` and local routing	Forwarding and route control on systems already reached during the exercise

I kept screenshots and command output in the assessment appendices so that each conclusion could be traced back to an interface, route, scan, configuration, or observed result.

Moving through the lab

Some networks were not directly reachable from the initial position. I used compromised lab hosts as controlled pivots and created routes through them to continue mapping. The report records SSH tunnelling across intermediary systems and access beyond the firewall into additional network segments.

The exercise required keeping track of where each observation came from: the subnet currently connected, routes available through a host, services exposed on the next network, and the permissions gained on each system. That prevented individual findings from being detached from the path that made them reachable.

The supplied environment contained a mixture of network devices, Linux endpoints, NFS services, SSH, web services, and older software. I gained access across several lab hosts, including root-level access on multiple systems, through combinations of weak credentials, exposed shares, vulnerable services, and permissive local configuration.

Building the topology from routes and interfaces

The environment used /27 endpoint networks and /30 point-to-point router links. VyOS routers exchanged routes with OSPF, while a pfSense firewall divided the later LAN and DMZ segments.

I started from the Kali host’s address, mask, and default gateway. A local scan identified the first Linux endpoint and router. After accessing the router in the controlled lab, its interface and routing tables exposed:

the connected /27 network
the next /30 transit link
a separate server network
OSPF-learned routes and their next hops

I repeated that process at each router. Interfaces established which networks were directly attached; route tables showed which networks existed further away; host scans then tested whether the expected systems were reachable.

One Linux host had an additional interface on a network that was not advertised through OSPF. That segment could not be found from the initial routing tables. It appeared only after examining the host itself, which demonstrated how incomplete routing visibility can hide a connected enclave without actually securing it.

The report’s subnet table and the route-led discovery produced the following working map. These are retired addresses from the university lab.

Network	Role in the assessment
`192.168.0.192/27`	Starting endpoint network containing the assigned Kali host, the first Linux endpoint, and the first router
`192.168.0.224/30`	Point-to-point link from the first to the second VyOS router
`172.16.221.0/24`	Separate web-server network attached to the first router
`192.168.0.32/27`	Endpoint network reached from the second router
`192.168.0.228/30`	Transit link towards the next routing stage
`13.13.13.0/24`	Additional network visible only from a dual-homed Linux endpoint
`192.168.0.128/27`	Routed endpoint network before the firewall-facing transit
`192.168.0.232/30`	Point-to-point link towards the pfSense boundary
`192.168.0.240/30`	Small server segment containing the host used to reach the firewall management side
`192.168.0.64/27`	DMZ-side network behind the firewall
`192.168.0.96/27`	Internal LAN behind the firewall

The /30 networks gave the router links two usable addresses each, while the /27 networks allowed up to 30 hosts. The report considered whether some /27 segments were larger than their demonstrated need, but also recognised that unused address capacity allowed expansion. I kept that capacity discussion separate from the security findings.

Nested tunnels and the firewall boundary

The hidden and firewalled networks required routed SSH tunnels rather than a simple local port forward. In the lab, I enabled tunnel interfaces on the intermediary Linux systems, assigned point-to-point addresses to each end, and added only the routes required for the next network.

The first tunnel exposed the unadvertised subnet. A later pivot from the DMZ side provided a path to the firewall’s management-facing network. Reaching the final two segments required a second tunnel nested through the first.

That arrangement had a routing problem of its own. If the route to the second pivot was sent into the new nested tunnel, the tunnel’s control connection could route back into itself and fail. I kept the route to the intermediary host on the first path, then moved only the destination networks onto the second tunnel.

This part of the assessment was as much networking as exploitation. The access path depended on:

knowing which interface could reach the next hop
separating tunnel transport from tunnelled traffic
enabling forwarding on the controlled pivot
applying network address translation where required
updating the tester’s routes in the correct order

The final result showed that the firewall blocked direct access from the starting subnet, but a compromised host on an allowed path could undermine that boundary.

Findings across systems and services

The final report grouped the recurring weaknesses rather than treating every host as unrelated. The main themes were:

default credentials left on infrastructure
password reuse between accounts and systems
remote management over plaintext protocols
no account lockout policy
NFS exports exposing files beyond their intended users
known vulnerable software, including Shellshock and Heartbleed in the lab
broad sudo permissions
firewall rules that allowed more inter-network traffic than required

The NFS findings were especially useful for connecting network exposure to local permissions. A share could reveal account or SSH material even when the local file mode looked restrictive, because the export and identity mapping changed who could reach the data.

The router and firewall review also showed that segmentation has to be enforced, not simply drawn on a diagram. The lab had separate networks and a DMZ, but permissive management protocols and rules created paths that weakened those boundaries.

I documented the findings as connected conditions rather than isolated scanner output:

Condition	Observed effect in the lab	Underlying control failure
Default infrastructure credentials	Administrative access to routing and firewall interfaces	Deployment hardening had not replaced vendor defaults
Reused passwords and SSH material	Access obtained on one host could be tried or reused elsewhere	Identities and keys were not unique to their intended systems
Broad NFS exports	Remote access to system files, home directories, keys, or writable authentication paths	Export scope and identity mapping did not match the local permission model
Excessive `sudo` access	A normal account could become full system control	Privilege was assigned broadly rather than per administrative task
Plain-text management	Administrative traffic could be observed or altered on an accessible segment	Telnet and HTTP remained enabled for management
Missing lockout or throttling	Password guessing could continue against SSH and WordPress	Authentication controls did not constrain repeated failures
Known vulnerable services	Web-facing hosts provided routes to system-level access	Patch management and service isolation failed together
Permissive firewall paths	A reached intermediary host exposed networks that were not directly accessible	Rules trusted network position without sufficiently limiting source, destination, and service

NFS and host trust

Several Linux endpoints exposed NFS shares. The export scope varied:

one exposed most of the root file system
another exposed a user’s home directory and .ssh material
another allowed the remote client to create a new authorised-key path

Because the testing host had local root privileges, weak identity mapping on the exports translated into access to files that ordinary remote users should not have been able to read or modify. Password hashes, private SSH keys, and authorised-key files then provided access to other hosts.

The same administrative account and password appeared on more than one system. A key recovered from one exported home directory was accepted by a different host. Broad sudo access and weak root-account configuration turned user access into full control.

These were not isolated NFS and password findings. The share configuration exposed authentication material, the authentication material crossed host boundaries, and the privilege model magnified the result.

The assessment also separated three permission layers that can otherwise be confused:

The NFS export defined which clients could mount a path and how remote identities were mapped.
The local ownership and mode bits controlled access once the identity reached the server.
SSH and sudo configuration determined what the recovered account or key could do next.

A restrictive file mode did not compensate for an export that mapped a remote privileged user too generously. Likewise, a correctly scoped export would still leave risk if reusable keys were stored without suitable protection.

Routers and management services

The VyOS routers retained documented default credentials and exposed both SSH and Telnet. The pfSense management interface also retained its default credentials and was available over HTTP from a network that became reachable through the pivot chain.

Compromise of the routing layer gave access to interface configuration, route tables, and the traffic paths between broadcast domains. Plain-text management also meant that credentials and administrative commands could be observed by anyone able to capture the relevant traffic.

The router data was also part of the discovery evidence. Interface output identified directly connected segments, while the OSPF table exposed learned prefixes, next hops, and path cost. This allowed me to distinguish a network that was absent from routing from one that was advertised but blocked by the firewall.

Web and DMZ services

The first web server exposed a WordPress installation with an enumerable administrator account, a weak password, and no effective protection against repeated login attempts. The underlying HTTPS service also used an OpenSSL version affected by Heartbleed in the supplied lab.

The DMZ server exposed system information through its web service and contained a CGI endpoint affected by Shellshock. Both vulnerabilities were deliberately old teaching targets. Their role in the assessment was to show how an internet-facing service can become the first host in a deeper network path when patching and isolation fail together.

The report kept these findings separate from the network map, then connected them during risk analysis: service compromise supplied a foothold, NFS and account weaknesses supplied credentials or keys, and permissive routing supplied reach.

Firewall rule review

The pfSense configuration separated a WAN-facing routing segment, a DMZ, and an internal LAN. The rule review found that:

the WAN-side policy allowed OSPF traffic so the routers could exchange network information
the LAN policy allowed broad outbound access and retained the management anti-lockout rule
the DMZ policy allowed traffic to a particular intermediary host while denying access to the rest of its subnet and the LAN
the management interface was addressed in rules as a single interface address rather than consistently using the firewall-wide destination object

The controls were not absent, but their effectiveness depended on which host had already been reached. Once an allowed intermediary became a pivot, source-network trust no longer represented the origin of the activity.

From access paths to remediation

I wrote the recommendations around the causes that enabled multiple access paths:

remove or change default accounts and credentials during deployment
use unique passwords and enforce an account lockout policy
replace Telnet and unencrypted management interfaces with protected administration channels
restrict NFS exports and align remote access with local identity and permission requirements
patch or remove services affected by known vulnerabilities
reduce sudo privileges to the commands each role requires
tighten firewall rules around explicit source, destination, service, and direction requirements

For NFS, the report recommended narrowing exports to required clients and directories, correcting ownership and permissions, introducing suitable authentication, and monitoring access to sensitive paths. For authentication, unique credentials and stronger second factors would prevent one recovered secret from unlocking several systems. SSH retry limits or a control such as Fail2ban could constrain repeated failed logins, while application-level rate limiting was needed for the WordPress administration interface.

The router chain also created a reliability problem. Its largely linear shape meant that one failed router could isolate every network beyond it. I recommended adding redundant paths rather than treating the security assessment and availability design as separate concerns.

For monitoring, the report proposed host and network intrusion detection, centralised logs, and endpoint collectors feeding an Elastic-style analysis platform. Useful alerts in this environment would include:

use of default or shared administrative accounts
changes to sshd_config, forwarding, or authorised keys
NFS access outside expected clients
unusual tunnel interfaces and long-lived SSH sessions
access to router or firewall management from non-administration networks
repeated authentication attempts
traffic crossing a segment boundary without an approved service

The same evidence would support a focused retest. Default accounts should fail, management interfaces should accept only encrypted connections from an administration network, exported paths should be inaccessible from unapproved clients, reused keys should no longer authenticate across hosts, and inter-segment traffic should match the documented rule set.

What the assessment developed

This was not a scan-and-report exercise. I had to build a working model of an unfamiliar environment, identify which systems could become pivots, understand the trust created by network services, and then explain how individual weaknesses combined.

It also improved the way I write security findings. A service version or open port is only the start; the report needs the reachable path, the configuration condition, the access obtained, the systems affected, and a remediation that addresses the cause rather than one test command.

The assessment is retained as historical university work. The lab software and techniques reflect a 2022/23 teaching environment, while the network reasoning - scope, routing, trust boundaries, service exposure, and remediation - carries into later security engineering and operations work.