This is a write up on my capstone while at my time in WGU. I am unsure whether I can show the whole document, but I can probably show it on request for non-students and as long it it’s for the right reasons (Refer to CONTACT at the bottom of the page). Anyways, I think linking my Gitlab repository for the code I used in the project is okay: https://gitlab.com/lcrosendo/network-engineering-capstone-innotek. The code is all mine. There are no references to WGU or things specific to the capstone course.
The project took me around a month from creating the design (around a couple of days), to building it in GNS3 inside the virtual lab (this took me like 1-2 weeks building functionality as well as dealing with technical problems using the virtual lab), and the testing and write-up (this took me a week to get everything right; this lead to a successful one try submission). It was such a big relief to be done with it all. The project probably took longer than it should have because I wanted to try out things I hadn’t really touched before like Reverse Proxy in Nginx, Samba file server, DHCP reservation in DNSMasq, full implementation of pfSense, DNS blocking, Security Onion and Snort rules, Syslog integrated with SO’s ELSA SIEM, and login banners not just limited to SSH but also GUI and via web page. I considered using WordPress and a Forward Proxy in the project, but decided not to, because I didn’t want to deal too much with the scope creep.
These are excerpts taken from my paper. The first excerpt summarizes the basic topology of the network. The second excerpt mentions automation, which was a big part showcased by the capstone project.
Note: In the scenario, Innotek is a fictional organization basically requiring a secure SOHO-type network. The simulation uses GNS3. I am purposely keeping details about the course here at a minimum, but note, there are certain requirements to be fulfilled for the project to be called a success.
The network starts from the edge or perimeter router connecting to a mock internet side, with a mock ISP router connected to a mock outside host that will be used later and a GNS3 NAT device for internet access inside the lab. The Vyos edge router has firewall rules restricting all traffic except for ICMP echo requests to its WAN side IP address and HTTP traffic being port-forwarded to a reverse proxy server in the DMZ, which proxies the company web server. The router allows all traffic coming from the internal side and uses NAT or PAT for all outgoing connections, and since the firewall is stateful, it will allow established and related connections back in. The router connects down to a pfSense firewall with rules controlling access in, out, and between the different parts of the network.
The internal network consists of the IT VLAN(tag:10), Office VLAN(tag:20), and Guest VLAN(tag:30). The IT VLAN contains the NetAdminHost or network administrator node, which can SSH into all the devices on the network, the Network Server, which provides DNS, DHCP, and NTP services for the rest of the IT VLAN as well as the Office VLAN, and the File Server, which hosts a Samba file server for the Office VLAN. The Office VLAN is meant for all other normal users in the organization and consists of an example Windows 10 (OfficeWindows) and Linux Mint (OfficeLinux) host. The Guest VLAN is meant for guest users who need temporary access to the network and consists of a Windows 10 (GuestWindows) and Linux Mint (GuestLinux) host as well. Outside of GNS3, this side of the network could add Wireless Access Points for guest wireless devices.
The DMZ consists of a Web Server, Reverse Proxy Server, and a Guest Network Server, which provides DNS and NTP services to devices inside the internal network’s Guest VLAN, all in its own DMZ VLAN (tag:50). The reverse proxy is a middleman for HTTP requests to the web server (actual implementation will ideally have a domain name registered as well as certificates for HTTPS set up) which will host the company website advertising services accessible from the internet.
Firewall rules can be summarized as follows:
| Source | Rule | Port / Protocol | Destination |
| IT, OFFICE, GUEST | Allow | HTTP, HTTPS | Internet |
| IT, OFFICE, GUEST | Allow | HTTP | Reverse Proxy Server |
| GUEST | Allow | DNS, NTP | Guest Network Server |
| Network Server, Guest Network Server | Allow | DNS, NTP | Firewall |
| IT, OFFICE, Internal Switches | Allow | ICMP Echo Request | Internal Interface |
| Edge Router | Allow | ICMP Echo Request, Syslog | WAN Interface |
| Edge Router | Allow | NTP | Firewall |
| All (*) | Allow | OSPF | All (*) |
| Internet | Allow | HTTP | Reverse Proxy Server |
| NSM | Allow | All (*) | All (*) |
| All other traffic is blocked by default | |||
The actual rules in pfSense might be slightly different, but they generally follow the above table.
The firewall is connected to the perimeter router via its WAN interface. The firewall is connected to the Layer 3 DMZ EXOS switch via IP to its DMZ interface. The firewall is connected to the Layer 3 Core Switch of the internal network via IP to its Internal1 interface (in my lab, I have two internal interfaces, the other one I disabled, so when I mention internal interface, I am referring to the Internal1 interface that can be found on the pfSense firewall). The firewall is connected to the Network Security Monitor running Security Onion via its NSM and SPAN interfaces. The firewall uses IP to communicate with the management interface on the SO host via its NSM interface. The firewall mirrors traffic that passes through its WAN, internal, and DMZ interfaces to the SO hosts’ SPAN port via its own SPAN port. The lab uses an older version of Security Onion due to issues integrating with GNS3; the actual implementation could use a newer version of Security Onion or another NSM solution.
All the hosts have a host-based firewall enabled. Linux hosts have UFW enabled. Windows hosts use Windows Firewall. All the nodes have SSH open to the NetAdminHost. The NSM host has Syslog open. The Network Server has DHCP, DNS, and NTP open from the IT and OFFICE VLANs. The Guest Network Server has DNS and NTP open from the GUEST VLAN. The Web Server has HTTP open from the Reverse Proxy Server and the reverse proxy has HTTP open from anywhere. ACLs on the Core Switch for the internal network VLANs will be discussed in Test Case 2.
The organization requires a secure network that has segments with limited and managed access to one another to reduce attack surfaces as well as unauthorized use of resources. The use of firewalls and access controls help with that.
All the nodes on the network have an SSH server running on them that allow SSH access (TCP 22) from NetAdminHost. All the network nodes also have loopback interfaces with IP addresses that make connecting to devices more managable. The NetAdminHost mainly uses Ansible for automating configuration management.
To test the automated process of updating login banners on each device in the network, we can run through how using the Ansible playbooks works. The testing is divided into updating SSH login banners and updating GUI login banners or messages. All the devices in the network will be configured besides guest devices and devices outside the EdgeRouter.
Note: You can refer to the GitLab link I posted to get a feel for the automation I did for the project, which mostly used Ansible.
The organization requires network security monitoring to gain better visibility into their network. The NSM should be able to detect attacks on the network. The NSM includes Snort, an intrusion detection system (IDS). Flagged behavior should trigger a rule in Snort, which the alert can then be seen in Sguil, an interface for different alerts in the NSM. Since the company is just starting up and small, but they still want a more than suitable security posture, the one operating the NSM they requested would probably also be from IT. When the company grows, the team organization can start with a single designated cybersecurity specialist or analyst to operate the NSM and then toward a fuller SOC team as well as more sensors and better distributed placement of NSM tools.
To test network security monitoring capabilities, we can initiate flagged behavior from OutsideHost, which can simulate an attacker, and go into NetworkSecurityMonitoring to check if Snort detects and alerts the traffic.
To test Syslog and NTP is working correctly on edge devices, we can demonstrate sending a restricted connection like SSH from the OutsideHost to the EdgeRouter. The connection will be blocked, and a system log will be sent to the NetworkSecurityMonitor, which will process it in ELSA (Enterprise Log Search and Archive). The NetworkSecurityMonitor and EdgeRouter should have the same NTP source within the network to better synchronize log timestamps.
