Project 1 --- Secure Linux Network & SSH Administration Lab

📌 Project Overview

This project is a hands-on network and security lab built in GNS3 using a Cisco router and two Ubuntu Linux Docker guests.

The objective was to build a small routed network, provide Internet access through NAT, configure Linux networking, expose an SSH service, perform service discovery with Nmap, establish remote SSH access, and investigate the resulting authentication logs.

This project demonstrates practical skills relevant to Network Engineering, Linux Administration, and Entry-Level Cybersecurity/SOC roles.

---

🏗️ Lab Topology

                    Internet
                       |
                    GNS3 NAT
                       |
                 R1 — Cisco Router
              Fa0/1: 192.168.42.172
              Fa0/0: 192.168.10.1
                       |
                      ESW1
                    /      \
                   /        \
             Guest-1      Guest-2
          192.168.10.10  192.168.10.20
            Ubuntu          Ubuntu
          SSH Server     Nmap / SSH Client

---

🛠️ Technologies & Tools

• GNS3
• Cisco IOS
• Ubuntu 24.04 LTS
• Docker-based Ubuntu guests
• Nmap 7.94SVN
• OpenSSH 9.6p1
• rsyslog
• IPv4
• Cisco NAT
• Linux ip networking tools

---

🌐 IP Addressing

Device Interface IP Address Purpose

---

R1 FastEthernet0/0 192.168.10.1/24 LAN gateway R1 FastEthernet0/1 192.168.42.172 WAN/Internet Guest-1 eth0 192.168.10.10/24 Linux server Guest-2 eth0 192.168.10.20/24 Client/security workstation

Default gateway for both Ubuntu guests:

192.168.10.1

---

🔧 Configuration & Implementation

1. Linux Network Configuration

Guest-1 was configured with:

ip addr add 192.168.10.10/24 dev eth0
ip link set eth0 up
ip route add default via 192.168.10.1

Guest-2 was configured with:

ip addr add 192.168.10.20/24 dev eth0
ip link set eth0 up
ip route add default via 192.168.10.1

The resulting routing table included:

default via 192.168.10.1 dev eth0
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.x

---

2. Cisco Router Configuration

R1 was configured with the LAN interface:

FastEthernet0/0
IP: 192.168.10.1

The WAN interface received:

FastEthernet0/1
IP: 192.168.42.172
Method: DHCP

Both interfaces were brought up and verified with:

show ip interface brief

---

3. NAT Configuration

The LAN interface was configured as the NAT inside interface:

interface FastEthernet0/0
 ip nat inside

The WAN interface was configured as the NAT outside interface:

interface FastEthernet0/1
 ip nat outside

NAT statistics were then used to verify translated traffic.

---

🌍 Connectivity Testing

Connectivity was tested progressively instead of assuming the network was working.

Gateway Test

From Guest-1:

ping -c 4 192.168.10.1

The gateway responded successfully.

Internet Test

From Guest-1:

ping -c 4 8.8.8.8

The host successfully reached the Internet.

DNS Test

Initially, DNS failed because /etc/resolv.conf did not contain a nameserver.

A DNS resolver was added:

echo "nameserver 8.8.8.8" > /etc/resolv.conf

After this, the following worked:

ping -c 4 google.com

Troubleshooting Lesson

This demonstrated an important troubleshooting distinction:

• IP connectivity can work while
• DNS resolution is still broken.

The problem was isolated by testing an IP address first and then a hostname.

---

🔎 Nmap Service Discovery

Guest-2 was used to scan Guest-1.

Initial service discovery:

nmap -sV 192.168.10.10

After SSH was installed and started, Nmap identified:

PORT   STATE  SERVICE VERSION
22/tcp open   ssh     OpenSSH 9.6p1 Ubuntu

A targeted scan was also performed:

nmap -sV -p 22,80,443 192.168.10.10

Result:

22/tcp  open    ssh
80/tcp  closed  http
443/tcp closed  https

What this demonstrates

The scan demonstrates the ability to:

1. Identify whether a host is reachable.
2. Discover exposed TCP services.
3. Determine which common web services are not exposed.
4. Identify the SSH implementation and version.
5. Use targeted scanning instead of blindly scanning every port.

---

🔐 SSH Server Configuration

Guest-1 initially contained the SSH client but did not have the SSH server installed.

After Internet connectivity was established:

apt update
apt install openssh-server -y

The SSH service was started:

service ssh start

The listening socket was verified:

ss -tulnp

The result showed SSH listening on:

0.0.0.0:22
[::]:22

The SSH configuration was syntax-checked before restarting the service:

sshd -t
service ssh restart

---

👤 SSH Authentication Test

Guest-2 connected to Guest-1 using:

ssh root@192.168.10.10

The connection succeeded and provided a remote shell on Guest-1.

This demonstrated:

• Network reachability
• TCP/22 accessibility
• SSH service availability
• Password authentication
• Remote Linux administration

---

📝 Authentication Logging

The Ubuntu guest initially did not have an active authentication log available.

rsyslog was installed and manually started in the minimal environment.

The default configuration contained:

auth,authpriv.*    /var/log/auth.log

After a successful SSH login, /var/log/auth.log contained an authentication event similar to:

Accepted password for root from 192.168.10.20

This provided evidence that the SSH connection from Guest-2 was successfully authenticated and recorded.

---

🛡️ Security Analysis

The project demonstrates a basic security-event chain:

Guest-2
192.168.10.20
     |
     | SSH connection
     v
Guest-1
192.168.10.10
     |
     | Authentication
     v
Successful login
     |
     v
/var/log/auth.log

From a SOC/security perspective, this provides an introduction to:

• Network reconnaissance
• Service enumeration
• Exposed-service identification
• Remote authentication
• Authentication logging
• Basic security-event investigation

---

🧪 Troubleshooting Performed

During the lab, several real configuration problems were encountered and resolved:

Problem 1 --- Missing Linux route

The Ubuntu guest initially had no usable route.

Resolution:

ip route add default via 192.168.10.1

Problem 2 --- Router interface state

R1 interfaces were initially administratively down.

Resolution:

The appropriate interfaces were configured and enabled.

Problem 3 --- No Internet connectivity

The GNS3 NAT connection was added to provide WAN access.

R1 subsequently obtained:

192.168.42.172

and successfully reached:

8.8.8.8

Problem 4 --- DNS resolution failure

/etc/resolv.conf was empty.

Resolution:

echo "nameserver 8.8.8.8" > /etc/resolv.conf

Problem 5 --- SSH server unavailable

Only openssh-client was initially installed.

Resolution:

apt install openssh-server -y
service ssh start

Problem 6 --- Authentication log unavailable

The minimal Ubuntu environment did not initially have active rsyslog logging.

Resolution:

rsyslog was installed/configured and started manually, after which SSH authentication events appeared in /var/log/auth.log.

---

📸 Evidence

The project includes screenshots demonstrating:

1. GNS3 topology
2. R1 interface configuration
3. Guest-1 network configuration
4. Internet connectivity
5. DNS resolution
6. Nmap service discovery
7. SSH remote login
8. SSH authentication logging
9. NAT operation

Screenshots should be stored in the project's screenshots/ directory.

Recommended naming:

screenshots/
├── 01-gns3-topology.png
├── 02-r1-interface-status.png
├── 03-guest1-network.png
├── 04-internet-and-dns.png
├── 05-nmap-service-discovery.png
├── 06-ssh-login.png
├── 07-authentication-log.png
└── 08-nat-evidence.png

---

🎯 Skills Demonstrated

Networking

• IPv4 addressing
• Subnetting
• Default gateways
• Routing
• Cisco IOS
• Interface configuration
• NAT
• WAN/LAN configuration
• DNS troubleshooting

Linux Administration

• Ubuntu administration
• ip networking commands
• Routing-table inspection
• Package management
• SSH server configuration
• Service management
• Socket inspection with ss
• Process inspection
• System logging

Cybersecurity

• Network reconnaissance
• Port scanning
• Service/version enumeration
• SSH security
• Authentication testing
• Authentication-log analysis
• Basic security-event investigation

---

📈 Project Outcome

The completed lab successfully demonstrated end-to-end communication between two Ubuntu hosts through a Cisco router.

Guest-1 was able to:

• Reach the LAN gateway
• Reach the Internet
• Resolve DNS names
• Run an SSH server

Guest-2 was able to:

• Reach Guest-1
• Discover the SSH service using Nmap
• Confirm that HTTP/HTTPS were closed
• Connect to Guest-1 through SSH

The successful SSH authentication was subsequently visible in the Linux authentication log.

---

🧠 Key Learning

The main lesson from this project was to troubleshoot systematically rather than simply execute commands.

The troubleshooting process followed a practical sequence:

Interface
   ↓
IP Address
   ↓
Routing
   ↓
Gateway Connectivity
   ↓
Internet Connectivity
   ↓
DNS
   ↓
Service Availability
   ↓
Service Enumeration
   ↓
Authentication
   ↓
Log Analysis

This approach connects networking fundamentals with practical security operations.

---

🚀 Future Improvements

Possible extensions to this lab include:

• Create a dedicated non-root SSH user.
• Replace root/password authentication with SSH keys.
• Add firewall rules using UFW.
• Add a web server and analyze HTTP traffic.
• Add Wazuh/SIEM monitoring.
• Generate failed SSH authentication events.
• Investigate and correlate authentication logs.
• Add another network segment/VLAN.
• Add a second router and practice routing protocols.
• Perform controlled vulnerability assessment against intentionally vulnerable lab systems.

---

📚 Project Status

Status: Completed --- Version 1

Focus: Network Engineering + Linux Administration + Cybersecurity Fundamentals

Environment: GNS3 / Cisco IOS / Ubuntu Linux