Security Forem: Samuel Adeduntan

Network Monitoring with PRTG

Samuel Adeduntan — Tue, 07 Oct 2025 15:03:22 +0000

Building a Centralized Monitoring Framework with PRTG

Introduction

Centralized monitoring is essential to preserving visibility, performance, and availability across network assets as part of the larger network security and management plan. In this stage, I put Paessler's PRTG Network Monitor (PRTG) into use to create a cohesive monitoring system that went well with the FortiGate firewall setup.

The objective was to provide a single pane of glass that offers real-time information on device status, bandwidth usage, network health, and service availability. Using industry-standard protocols like SNMP, WMI, and ICMP, PRTG's agentless architecture enabled smooth integration with FortiGate and other network components.

I was able to keep an eye on important metrics by setting up custom sensors, such as the firewall's CPU consumption, interface throughput, memory usage, and VPN tunnel status. Performance trend analysis and capacity planning were made possible by the collection of historical data, and alerts and notifications were adjusted to guarantee a quick reaction to abnormalities.

By offering constant visibility into the security posture and network performance, this centralized configuration not only made network management easier but also enhanced operational awareness and insights. I created a proactive monitoring environment using PRTG's user-friendly dashboard, which can identify and resolve potential issues before they impact customers or services.

PRTG Network Monitor is the main tool for observing server and network performance.
I began by installing it on a Windows Server, which allowed me to track system resources like RAM, CPU, and disk usage. PRTG served as the foundation for building visibility into all devices on the network, giving me real-time updates on uptime and service health.

Understanding PRTG Protocols

Here, I described how the Simple Network Management Protocol (SNMP) is used by the majority of network monitoring tools, including PRTG, to connect to endpoint devices. Because it allowed PRTG to query devices, gather performance information, and identify anomalies over standard ports (often UDP 161), SNMP was essential. This guarantees smooth communication between workstations, servers, routers, and switches of any manufacturer.

Downloading and Installing PRTG

These detailed the process of downloading and setting up PRTG on Windows:
I searched for PRTG in my web browser and downloaded it from the official Paessler site.

After launching the installer, I followed the setup prompts and selected the default installation mode.

Once installation completed, PRTG automatically launched a web instance on port 8080 using the system’s IP address.

This stage marked the successful deployment of the monitoring environment.

Logging In and Accessing the Dashboard

Once installed, I accessed the PRTG web interface using my administrator credentials. The interface was intuitive, featuring sections such as:
- Dashboard: Displayed overall network health.
- Devices: Listed all monitored systems.
- Sensors: *Represented specific metrics (CPU load, memory, services).
*- Alarms: Displayed alerts and downtime events.

This became my central management console.

Network Discovery

PRTG automatically began network discovery, scanning the subnet to detect reachable hosts. Discovered devices were displayed on the dashboard, allowing me to:

Rename devices.
Organize them into groups.
Assign or remove sensors manually.

This automatic process saved significant setup time and ensured no device was left unmonitored.

Adding Devices Manually

After the automatic discovery, I manually added both Windows and Linux systems for more control. For Windows, I used WMI credentials to pull system data. For Linux, I configured SNMP and SSH connections.
Each device automatically received a set of sensors (like uptime, ping, and CPU usage).

Configuring Auto-Discovery and Sensors

PRTG’s auto-discovery feature scanned each device for active services.
For example:
I enabled FTP on a Kali Linux system.
PRTG detected it and created an FTP sensor automatically.
This saved me from manually identifying and adding every service on the network.

*Adding a windows machine *

Monitoring System Information

Exploring the functionality of the deep scan of PRTG on a particular device. For instance Windwos server
Here, I explored the detailed data PRTG collected per device:

Hardware specs (CPU type, memory, disk drives).
Software installed on the system.
Logged-in users and background services. If any service had issues, I could quickly verify its status through PRTG before performing manual troubleshooting.

System inforation under the particular endpoint you are monitoring

Hardware information

Information of Software running on the operating system

Users that are on the system

Details of Services orunning on the endpoint

Service Downtime Simulation

To test real-time monitoring, I intentionally stopped services such as:

The Wazuh Agent.
The RDP (Remote Desktop Protocol).

PRTG immediately detected the changes, showing warning alerts on the dashboard. When I restarted the services, the alerts cleared automatically.

I want to turn off the wazuh agent

This confirmed PRTG’s ability to monitor uptime accurately.

Pausing and Resuming Sensors

I demonstrated how to pause sensors during maintenance activities to prevent unnecessary alerts. This was especially helpful when testing or updating software. After maintenance, I resumed the sensors, and monitoring continued without triggering false alarms.

Reason why a service sensor can be paused is when a particular service is under maintanace, and you do not want idefinate alarm of down service, so you have to pause the service sensor untill the service is up and runing. So this is how to go about it

To turn ON the service sensor Alarm back

Monitoring Linux Endpoints

I then focused on monitoring a Linux machine (Kali Linux). I started the FTP service and used PRTG to collect data such as:

System uptime.
CPU and memory usage.
Active ports and services.

This proved that PRTG effectively supported cross-platform monitoring.

Configuring Notification Triggers

I configured notification triggers to alert me when specific conditions were met. Examples included:

CPU usage above 90%.
Disk space below 10%.
Service down for more than 5 minutes. Notifications could be sent via email, SMS, or external integrations like Slack.

Alarm simulation, Shoting down the RDP protocol

Integrating PRTG with Slack

This part covered the full Slack integration workflow:
- Created a new Slack workspace and channel.

Dashboard Overview

Creating New channel

Adding people to your newly created team

- Generated an incoming webhook URL.
Why do we need webhook URL?
Webhook are a way to post messages from apps into slack. Creating an incoming webhook gives you a unique URL to which you send a JSON payload with the message text and some options.

The slack app is meant to be linked to your slack channel

Created a Slack App and enabled webhooks under its settings.

Locate incoming webhook under features

Turn ON the webhook

Select the name name of the channel on the app

- Copied the webhook URL and pasted it into the PRTG notification template.

How I connected the generated webhook URL to PRTG instance

Setting up the notification template

Simulation of an event

Testing the Slack Integration

To verify the integration, I simulated another RDP service shutdown.
PRTG triggered an alert and instantly sent a notification to my Slack channel. The Slack message included the service name, device, alert type, and timestamp. When I restarted the RDP service, the notification updated to reflect that it was back online.

Event simulation notification after RDP was shut down

Turn ON the RDP service.

Conclusion

In summary, this hands-on project gave me comprehensive experience in:

Installing and configuring PRTG on Windows Server.
Adding and monitoring Windows/Linux devices.
Creating and managing service sensors.
Simulating alerts and testing real-time notifications.
Integrating PRTG with Slack for proactive incident management.

This experience improved my technical understanding of network monitoring, automation, and alert handling key skills for cybersecurity and SOC operations.

Lesson Learned

I gained important knowledge about how centralized monitoring improves operational effectiveness and security visibility in an enterprise network from working with PRTG Network Monitor. I gained the following important insights from this practical deployment:

- Centralized visibility simplifies management: *My responsiveness to service interruptions was enhanced and troubleshooting time was significantly decreased by having all network devices and services viewable from a single pane of glass.
*- Understanding protocol is essential: I learned how these communication protocols serve as the foundation for device monitoring by correctly configuring SNMP, WMI, and SSH connections. I came to see that even a small configuration error could result in false alerts or prohibit reliable data collecting.
- Automation reduces effort: Without requiring human input, the auto-discovery capability was particularly useful in identifying new endpoints and services. This guaranteed that no device was left unattended while also speeding up the setup process.
- Alerts need to be adjusted: ** I got too many notifications at first, some of which weren't urgent. The alerting system was improved by modifying thresholds and designing unique triggers, ensuring that I only received actionable alerts via Slack.
**- Collaboration is strengthened through integration: The power of combining monitoring tools with communication platforms was illustrated by connecting PRTG to Slack. Without continuously monitoring dashboards, real-time notifications made incidents instantly visible.
- Proactive monitoring minimizes downtime: I was able to verify that proactive warnings enable prompt action before problems worsen, reducing the impact on business, by mimicking service outages.
- False positives are avoided by being aware of maintenance: By learning how to pause and resume sensors during planned maintenance, the monitoring system was kept dependable and alert fatigue was prevented.
- Cross-platform visibility promotes operational trust: I was able to get a thorough picture of the network by keeping an eye on both Windows and Linux endpoints, which helped to guarantee that all vital systems continued to function and be safe.

#DAY 8: Monitoring, Logs & Troubleshooting

Samuel Adeduntan — Tue, 07 Oct 2025 00:30:27 +0000

From Event Logs to Effective Issue Resolution

Introduction

A firewall needs to be regularly observed and evaluated to make sure it is operating as intended. Its efficacy does not stop with configuration. With its extensive suite of logging and monitoring capabilities, FortiGate offers managers comprehensive insight into system health, network traffic, and possible security risks.

The foundation of troubleshooting is logs. Examining thorough logs helps determine the underlying source of problems and guarantees prompt resolution, whether they are caused by dropped packets, broken connections, or strange activities. Correlation of events and early anomaly detection are made feasible by FortiGate's support for real-time log monitoring, historical log analysis, and integration with external logging systems like FortiAnalyzer or SIEM platforms.

During this stage, I concentrated on monitoring network activity and enhancing incident response through the use of event logs, traffic logs, and system alarms. By employing FortiGate’s troubleshooting capabilities, such as packet captures, flow-based monitoring, and diagnostic commands, I was able to proceed from problem discovery to successful resolution, ensuring the firewall continually maintained secure and dependable network operations.

Checking logs & monitoring

What does it mean for a firewall to monitor and manage devices?

A firewall must actively monitor network traffic to and from connected devices in order to detect possible security threats and implement policies that restrict access, stop malicious activity, and guarantee adherence to security regulations.

DHCP Monitored Device on firewall

Adding another VM to be monitored on the DHCP

New Device added

How to set up a firewall policy to allow internet access on these connected devices

Initially, the devices connected to this interface were not able to access the internet on the other side of the network.

The rules and configurations that control how the firewall handles network traffic are specified by the firewall policy and configuration component. To defend the network against threats and unwanted access, it entails defining connections that are permitted or prohibited, establishing access restrictions, and setting up security protocols.

How to know that traffic is getting to the firewall by default predefined rule.e

I tried to do a ping again

Recetrafficfic volume

Overview of the Traffic log and report

Conclusion

The significance of ongoing monitoring and log analysis in preserving a safe and reliable firewall environment was emphasized on Day 8. Through proactive monitoring of system health, device activity, and traffic flow, I successfully troubleshooted connectivity difficulties, verified security policy enforcement, and identified possible concerns. The FortiGate firewall maintained its dependability and resilience by utilizing diagnostic tools, including flow monitoring and packet captures, which increased response time and accuracy.

Success Goal Achieved

successfully used DHCP tracking to keep an eye on linked devices.
Traffic flow visibility was confirmed using firewall logs and reports.
Firewall settings were configured and modified to allow monitored virtual machines to access the internet again.
Ping tests were used to verify traffic reachability, and log entries were used for confirmation.
increased operational confidence through the use of troubleshooting tools (predefined rules, traffic volume analysis, and system logs).

Lessons Learned

Monitoring is proactive security — it’s not just about fixing problems but detecting them before they escalate.
Logs are invaluable for troubleshooting — they provide the evidence trail needed to isolate and resolve issues quickly.
Policy misconfiguration is a common cause of connectivity failures — reviewing rules against log data ensures accurate corrections.
Visibility drives accountability — knowing which devices are active, what traffic they generate, and whether they comply with policy improves governance.
Integration with external tools (FortiAnalyzer, SIEM) can further enhance analysis and long-term visibility for enterprise deployments.

#DAY 7: Users & Authentication

Samuel Adeduntan — Tue, 07 Oct 2025 00:30:15 +0000

Strengthening Security Through Identity Management

Introduction

True security necessitates limiting who has access to resources, even though firewall rules and security profiles regulate traffic at the network and application levels. FortiGate's user and authentication management makes sure that only people with permission may access the network and that their actions can be tracked and managed.

Granular identity-based access control is made possible by FortiGate through the creation of user accounts, the definition of user groups, and integration with external authentication servers like LDAP, RADIUS, or Active Directory. This method lowers the possibility of unwanted access to vital systems while simultaneously increasing accountability.

I set up users and authentication techniques during this step to improve firewall identity management. I made sure that security regulations were applied consistently by directly connecting access permissions to user identities, which improved network visibility and protection.

What is Users and authentication?

The processes and procedures used to confirm the identification of people gaining access to a system or network in order to guarantee that only authorized users are permitted entry are referred to as users and authentication.

By controlling access through identity verification, users and authentication help to increase security by making sure that only those with permission can access systems and resources.

Creating users & groups

User & Authentication

Login credential set up

New User Added

Requiring authentication in policies

How to enable the user/group on the
firewall policy

Simulation

Conclusion

By directly linking rules to user identities, Day 7 improved firewall access control. By limiting access to sensitive resources to authenticated users, identity-based enforcement lowers the possibility of unwanted access. By incorporating user management into the security framework, network governance was enhanced and responsibility was raised.

Success Goal Achieved

Local user accounts were successfully created and maintained.
User groups were formed to streamline policy administration.
Identity-based regulations that demand authentication prior to access were enforced.
To ensure that users were being confirmed correctly, authentication was simulated.
increased accountability and transparency of user activities across the firewall.

Lessons Learned

Integrating identities is essential because without linking access to particular individuals, security is insufficient.
Applying rules to individual users is more difficult than managing policies in groups.
It is necessary to test authentication policies because incorrect setup could prevent authorized users from accessing them.
Scalability and enterprise-level flexibility are added by external server integration (LDAP/RADIUS/AD).
Accountability is increased by audit trails, which now display who accessed what in addition to the device.

#DAY 6: Security Profiles: Web Filtering & Application Control

Samuel Adeduntan — Tue, 07 Oct 2025 00:30:03 +0000

Enforcing Safe Browsing and Application Usage

Introduction

FortiGate's security profiles offer comprehensive examination and management of web traffic and apps, going beyond simple firewall rules. Firewall regulations decide which connections are permitted, but Web Filtering and Application Control make sure that the permitted traffic is suitable and safe.

By classifying and banning undesirable or hazardous websites, web filtering helps shield consumers from unsafe content, phishing efforts, and malicious websites. Application Control, on the other hand, identifies and controls application traffic at a fine level, giving administrators the ability to restrict bandwidth-intensive services, prioritize business-critical apps, and prevent dangerous apps.

I set up security profiles during this stage to regulate network application usage and enforce safe surfing practices. I increased network efficiency, decreased user vulnerability, and reinforced user protection by implementing these profiles into firewall policies.

What is Security Profile
In network security systems, security profiles are configurations that specify how traffic is examined and controlled. To enforce security regulations and defend against threats, they incorporate capabilities like intrusion prevention, web filtering, application control, and antivirus scanning.

Enforcing safe browsing and controlling application usage are crucial security measures that safeguard networks from threats and guarantee compliance. These profiles include web filtering and application management.

What is web filtering?
Web filtering is a security feature that limits or regulates access to particular websites or content categories, lowering the risk of cyber attacks and assisting users in avoiding inappropriate or dangerous content. Web filtering is meant to define what a user can or cannot do on a particular organization's network.

Three rules or policies come with a firewall by default: one to monitor all visited URLs, another one to monitor Wi-Fi traffic, and the default one as well. The three default rules or policies that are commonly found in firewalls are:

Allow Established/Related Traffic: Permits traffic that is part of an already established connection.
Deny All Traffic: Blocks all traffic that does not match any other rule, serving as a security baseline.
Log Traffic: Logs information about traffic for monitoring and analysis purposes.

Configuring web filtering

FortiGuard web filtering: Category-Based Filter

*How to set up a new web filtering policy *

Web filtering policy set up

Adding the new web filtering policy to the security profile

Security Profile set up

Testing web filtering

Event simulation on web filtering

Enabling application control

Choosing the application signature → Application control → Application and filter Overrides Turn on the firewall policy's application control → Application control simulation

Application control

Application and filter Overrides

Selecting the application signature

Enable the application control on firewall policy

Conclusion

The capabilities of the firewall were extended on Day 6 from just permitting or rejecting traffic to intelligently regulating its quality and security. Through the configuration of Web Filtering and Application Control, I implemented regulations that shield users from damaging information, minimize their exposure to malware and phishing, and maximize bandwidth for apps that are essential to the operation of the business. By taking this step, network hygiene was improved overall, and administrators gained more exact control over how users interact with apps and the internet.

Success Goal Achieved

successfully developed and implemented web filtering rules to limit undesirable or dangerous website categories.
Application control profiles were enabled to limit bandwidth-intensive or high-risk apps and govern application usage.
To guarantee real-time enforcement, these functionalities were incorporated into firewall policies.
By evaluating traffic behavior against the policies and simulating events, the settings were confirmed.
improved user security, adherence to regulations, and effective use of network resources.

Lessons Learned

**Firewall policies are not enough: **adding security profiles provides deeper visibility and enforcement at the content and application level.
Web filtering categories matter: choosing the right categories avoids overblocking legitimate sites while still protecting against risks.
Application signatures are dynamic: keeping them updated is crucial since apps frequently change behavior and traffic patterns.
User experience vs. security balance: strict filtering improves safety but can frustrate users; careful tuning is essential.
Layered security is key: when combined with NAT, firewall rules, and logging, profiles create a defense-in-depth strategy.

#DAY 5: Firewall Policies, NAT & Logging

Samuel Adeduntan — Tue, 07 Oct 2025 00:29:50 +0000

Securing Communication Through Policies and NAT

Introduction

The foundation of a secure network is its firewall rules, which specify which traffic across various interfaces and zones is permitted or prohibited. These policies enable access control, security rule enforcement, and communication prevention in a FortiGate firewall. Network Address Translation (NAT), in conjunction with policies, is essential because it allows internal devices to access external networks while concealing private IP addresses.

Logging is equally crucial since it offers insight into traffic patterns, the application of rules, and possible dangers. Issues may go unreported without logging, making it challenging to identify harmful behavior or troubleshoot problems.

This phase involved using NAT to enable secure internet access, setting up firewall settings to control communication between LAN and WAN, and turning on thorough logging for auditing and monitoring. As a crucial line of protection for the deployment as a whole, these actions made sure that network traffic was both safe and traceable.

Understanding default behavior

Firewall policies, NAT, and logging are essential components of network security. Understanding their default behavior is critical for effective configuration and troubleshooting. Firewall has a default policy called implicit deny, which is to deny every traffic.

Creating a basic internet access policy
Establish the categories of permitted and limited access, set up user authentication if necessary, and make sure that appropriate logs and compliance monitoring are in place in order to establish a basic internet access policy.

How to create a simple policy for the firewall to allow the device to get connected to the internet → Name, Schedule, and action → Schedule → Source & Destination → Logging option

Name, Schedule and action

Schedule

Source & Destination

Logging option

Verifying new policy operation

Simulate event traffic.
Review Traffic Records.
Confirm matching logs to verify successful rule application.

Back to my VM

Trafic Records after I refresh the page

To View the matching logs

Adding a new network interface

Configure the new interface in the GUI.
Assign to Internal Network port3 with proper IP setup.
Verify changes from the overview page.

Open the GUI and refresh the page

Internal Network port3 configuration

Overview of the new interface added

Conclusion

In order to reinforce the firewall's function as a gatekeeper and an enabler of secure communication, Day 5 was an essential step. I was able to turn the FortiGate from a passive system into an active security enforcer by putting firewall regulations into place, turning on NAT for internal-to-external access, and setting up thorough logging. In addition to controlling network traffic, this made sure that it was constantly monitored for compliance and threat visibility.

Success Goal Achieved

successfully developed and implemented firewall rules to control communication between LANs and WANs.
NAT was enabled to conceal private IPs and give internal hosts safe access to the internet.
Set up logging to monitor, examine, and diagnose all important network operations.
Real-time traffic simulation and log examination were used to confirm the efficacy of the regulation.
Added a third interface (port 3) to the configuration in order to segment the internal network.

Lessons Learned

Implicit deny is always in use. Traffic will be prohibited unless each new policy is clearly established.
In order to safeguard private networks, NAT is a must for real-world internet access.
Without logging, troubleshooting and auditing are practically impossible. Logging is the firewall's memory.
The order in which the rules are set up has a direct impact on how traffic is handled.
In order to prevent conflicts, proper IP assignment and consistent documentation are necessary when planning for network expansion and adding new interfaces.

#DAY 4: Interfaces & Internal Network Setup

Samuel Adeduntan — Tue, 07 Oct 2025 00:29:34 +0000

Defining Connections for Secure Communication

Introduction

To regulate the flow of data between various network segments, a FortiGate firewall depends on interfaces that are set correctly. Interface setup has a direct impact on security and performance since they serve as the points of connection for management, external, and internal traffic. Communication between devices stays safe, dependable, and in line with the original network design when they are set up properly.

I concentrated on establishing the internal network configuration during this phase by giving interfaces IP addresses, dividing traffic, and implementing security zones. This created a safe framework for network communication, made it possible for detailed policy control, and clearly distinguished between internal and external resources.

Objective
On Day 4, I focused on establishing the internal network configuration by assigning IP addresses, disabling unnecessary DHCP services, and creating secure communication zones. This setup allowed clear segmentation of resources, reliable connectivity testing, and groundwork for traffic control policies.

Fortigate Firward Dashboard Overview

Once logged into the GUI, the dashboard overview provided visibility into the existing configuration and available interfaces.

Configuring additional interfaces

Configuring Additional Interfaces. I Added a second network adapter to the FortiGate VM through the virtualization platform.
In the FortiGate GUI, navigated to:
Network → Interfaces → Create New

Created and named the new interface (port2), then assigned it to the internal network segment.

→ Adding a new Network → Creating a new network interface

→ Disabling the DHCP
Disabled the DHCP service on the internal interface to maintain manual IP control and avoid conflicts. This ensured that IP assignment would remain consistent and predictable across devices.

Assigning IP to client VM

Power On the VM
Turn on the VM to see if the firewall has assigned an IP to the VM → Ping, to check the connectivity of the two devices

Access the firewall GUI from the web browser

Dashboard Overview
This confirmed correct routing and access through the second network interface.

Setting up the network interface for port 2 on the firewall
This was the second Network Adapter I configured on the VM., I need to set it up here on the firewall as well, with the IP address

Editing Interface Settings
Edited port2 properties to fine-tune roles and services:
Allowed access: HTTPS, PING, SSH (restricted to internal use). Assigned descriptive alias: Internal LAN.

Ping, to check the connectivity of the two devices
These tests verified that internal devices could reach the firewall and that routing was correctly established.

Traffic shaping & interface roles

Defined the roles of the two network interfaces:

Port1 (Administrative/External): Management + Internet-facing.
Port2 (Internal): LAN connectivity and internal device protection.

Implemented basic traffic shaping policies to ensure fair resource usage across the two interfaces.

Traffic Shaping → The two network interfaces: The administrative Network interface, the Internal Network interface

Conclusion

The successful configuration of internal interfaces and network segmentation marked the end of day four. I created a safe and dependable internal network foundation by designating responsibilities for every interface, turning off DHCP, and allocating static IPs. These setups made it possible for seamless communication, policy-based management, and the eventual expansion into more complex firewall rules.

Lessons Learned

- Security through Segmentation: By keeping internal traffic and management apart, the attack surface is decreased.
- Manual IP Control: By turning off DHCP on the firewall, lab setups can avoid unforeseen problems.
- Connectivity Verification: Routing and access may be verified with ease using basic ping tests.
- Interface Roles: Creating security policies is made easier with a clear division between internal and external roles.

#DAY 3: Accessing GUI, Licensing, and Patching

Samuel Adeduntan — Tue, 07 Oct 2025 00:29:17 +0000

Managing GUI Access, License Activation, and Firmware Updates

Introduction

Making sure the system is licensed and up to date, as well as having safe access to the management interface, are the first steps in properly managing a FortiGate firewall. An easy-to-use platform for firewall administration, monitoring, and configuration is offered by the GUI (Graphical User Interface). In order to preserve security and stop unwanted modifications, access to the GUI must be properly managed.

Advanced FortiGuard functions like intrusion prevention, web filtering, antivirus protection, and application management are also unlocked by activating licenses, and these enhance the firewall's security posture considerably. Because it offers stability advantages, feature enhancements, and defense against recently found vulnerabilities, upgrading the firmware regularly is equally important.

I concentrated on three main duties during this phase: deploying firmware upgrades, managing and activating licenses, and securing GUI access. When combined, these actions guaranteed that the firewall was current, fully operational, and prepared to provide enterprise-level security.

Accessing GUI, Licensing, and Patching

Managing GUI Access

I accessed the firewall’s Graphical User Interface (GUI) through the management interface using a web browser (HTTPS).

Accessing the Firewall Dashboard

I logged in with secure credentials to configure policies, monitor logs, and manage system settings.

FortiGate license page

I ensured that GUI access was restricted to trusted IPs within the internal network to reduce exposure.

License Activation

I activated the firewall licenses to enable advanced features such as IPS, web filtering, application control, and VPN capabilities.
The activation was completed directly through the GUI with internet connectivity, but I also validated the option of uploading an offline license file.
I confirmed that license validation allowed continued access to updates, security signatures, and vendor support.

System Rebooting

Firmware Updates (Patching)

I performed firmware upgrades to patch vulnerabilities, improve stability, and gain new features.
The updates were scheduled and applied from the GUI after downloading the latest firmware.
I carried out the updates during a safe maintenance window, ensuring that backup configurations were saved for rollback if required.

Automatic Patch Upgrade

#DAY 2: Basic FortiGate Configuration

Samuel Adeduntan — Tue, 07 Oct 2025 00:28:59 +0000

Establishing Core Security Settings

Introduction

The next crucial step after installing the FortiGate firewall is to complete the fundamental setup that provides secure connectivity and lays the groundwork for more sophisticated functionality. The device may effectively manage traffic, safeguard internal resources, and offer visibility into network activity if it is initially configured correctly.

During this stage, I concentrated on setting up fundamental configurations, including user access controls, firewall policies, network interfaces, and routing. By establishing a foundation for safe internet access, traffic filtering, and system monitoring, these setups made it possible to later deploy more sophisticated security features like intrusion prevention, web filtering, and VPNs.

Objective
I concentrated on creating firewall policies, interface assignments, routing, and basic access settings on Day 2. By establishing a baseline for traffic filtering, monitoring, and safe internet access, these actions prepared the ground for the later implementation of more sophisticated security services like VPNs, intrusion prevention (IPS), and web filtering.

Enter the default Login credentials

Login Credentials: Upon first boot, I accessed the FortiGate VM using the default credentials:
Username: admin
Password: (blank, press Enter)

This granted access to the CLI for initial setup.

Port configuration
Identifying FortiGate VM IP Address: To configure the network interfaces, I first located the default IP address assigned to the management port.

The command get system interface physical was used to view available interfaces and their IPs.

Port Configuration

Using CLI, I configured the management and internal interfaces.

config system interface
edit port1
set ip 192.168.1.99/24
set allowaccess ping http https ssh
next
edit port2
set ip 10.0.0.1/24
next
end

Inputting the prot configuration script

This ensured the management port was reachable for web-based access, while port 2 connected to the internal LAN.

How to get the gateway IP address

Default gateway configuration
To allow internet connectivity, I set the default route:

config router static
edit 1
set gateway 192.168.1.1
set device port1
next
end

This allowed outbound connections for updates and external communication.

DNS Configuration
I configured DNS servers to allow domain resolution using:

config system dns
set primary 8.8.8.8
set secondary 8.8.4.4
end

With this, the firewall could resolve domain names and support internet-bound traffic.

Connecting to FortiGate VM GUI
After assigning the management port IP, I accessed the FortiGate Web GUI via a browser:
URL: https://192.168.1.99

The login page loaded successfully, confirming GUI accessibility.

Conclusion

By the end of the second day, the FortiGate VM's baseline configuration was completely operational. Web access to the firewall interface was confirmed, along with the successful configuration of essential elements such as user login, port setting, routing, and DNS. This produced a safe and controllable environment that was prepared for more personalization and security strengthening.

Lessons Learned

- CLI First, GUI Later: While the CLI offers faster and more flexible initial setup, the GUI makes long-term management simpler.
- Gateway & DNS are Critical: The firewall cannot resolve domains or interact externally without the gateway and DNS.
- Best Practices for Access Control: Always limit administrative access to IP addresses and ports that are trusted for administration.
- Structured Setup Flow: Misconfigurations were decreased by adhering to a logical sequence (interfaces → gateway → DNS → GUI).

#DAY 1: Gathering assets on FortiGate Firewall Deployment and Configuration journey

Samuel Adeduntan — Tue, 07 Oct 2025 00:28:44 +0000

Gathering Essentials for a Successful Firewall Setup

Introduction

In order to provide a secure network environment, a FortiGate Firewall must be installed. FortiGate is an enterprise-grade security system with strong features like application control, VPN connectivity, intrusion prevention, and traffic filtering. From obtaining the virtual image to deploying it in a virtualized environment, I followed a methodical, step-by-step installation process to obtain hands-on experience.

The main goals of this step were to set up the firewall image, prepare system resources, and make sure there was adequate connectivity for first access. The platform for later customizations, including interface assignments, security rules, and routing, was made available by the installation's successful completion.

Objective

I concentrated on the preliminary setup and installation procedure on Day 1. Getting the firewall image, configuring system resources, and making sure there was enough connectivity for first access were all part of this. Additional configuration chores, such as interface assignments, firewall policies, and routing setup, were made possible by the installation's successful completion.

FortiGate Firewall Installation Procedure

Account Creation & Image Download: I first created a user account on the Fortinet Support Portal with my login credentials.

Navigated to the download section and selected the latest FortiGate VM image for VMware ESXi.

Downloaded Asset:A ZIP file containing the FortiGate VM image.

Selecting the latest version of FortiGate on VMWare ESXi to be downloaded

The downloaded zip file of the VM image

Extracting the VM image file

Importing VM & Initial VM Setup

Importing the FortiGate VM
I open my VM to import the VM image → Select the image file, next accept the User license agreement → Name the VM and import”

Open the VM to import by clicking on Open a virtual machine

Selecting image

Accept the license agreement

Name the VM to FortiGate VM and import
![Image1(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ip4z7go30co2f55jtwwi.png)

Configuring my VM network adapters

Network Configuration
The process of establishing and maintaining the parameters and settings necessary for devices to communicate within a network is known as network setup. This entails setting up routers, switches, and firewalls, allocating IP addresses, and making sure that the right security and connectivity procedures are followed. There are two types of firewall interface they are: - Management interface, monitoring interface, and internet interface - Other interfaces that connect to the private network

Types of Firewall Interfaces

Management / Monitoring / Internet Interface

This interface is primarily used for administration, monitoring, and external internet connectivity.
It allows administrators to log in, configure the firewall, and ensure communication with external/public networks.

Private / Internal Interfaces

These interfaces connect to the internal or private network segments.
They provide secure communication between internal hosts, servers, and other network devices, ensuring segmentation and controlled access.

Power On the VM

Conclusion

The FortiGate virtual machine was successfully installed in the virtualized environment at the end of the first day. I made sure the firewall was prepared for additional customization and security hardening in the following stages by finishing the installation and initial setup.

Lessons Learned

- Preparation First: *The import procedure was made easier by having the appropriate virtual machine image and license files on hand.
*- Learn about Interfaces: To prevent misconfiguration, it was essential to understand the difference between private and administration interfaces.
- Compatibility and Licensing: For a seamless deployment, FortiGate virtual machine versions must correspond with the virtualization platform.
- Practical Application: Experiential implementation yielded a more profound comprehension than merely theoretical research.

#Pre-Day 1: Preparation

Samuel Adeduntan — Tue, 07 Oct 2025 00:28:24 +0000

Introduction

As the first line of defense against malicious traffic, illegal access, and potential breaches, firewalls continue to be a fundamental component of network security. I deployed and configured a FortiGate firewall in a virtualized environment to deepen my expertise in enterprise-grade security solutions.

This project followed a methodical process that began with image deployment and preparation, followed by network configuration, policy development, and security service integration. I was able to get practical experience with key FortiGate functions, including interface administration, firewall rules, NAT setup, and traffic monitoring by completing each step.

My technical abilities were improved by the deployment, which also reaffirmed recommended firewall setup methods that strike a balance between security, usability, and performance.

Some of the security policies we can use a firewall to implement on endpoint devices

Firewalls can enforce several security policies on endpoint devices to enhance their protection and ensure secure network communication. These policies include:

Access Control: By limiting or permitting access to particular programs, services, or websites in accordance with pre-established regulations, firewalls can stop unwanted access to private information.

Incoming and outgoing network traffic is monitored and filtered by Network Traffic Filtering, which stops suspicious or harmful activity like malware or phishing attempts.

Application Control: To guarantee adherence to corporate security guidelines, firewalls might impose rules that restrict or prohibit the use of specific programs.

Intrusion Prevention: Firewalls can identify and stop intrusion attempts by examining traffic patterns, shielding endpoint devices from outside threats.

VPN Enforcement: To ensure encrypted communication, firewalls might mandate the usage of virtual private networks (VPNs) for safe remote access.

Content Filtering: By limiting access to offensive or dangerous content, policies might lower the chance of being exposed to dangers.

Device Isolation: To stop threats from spreading, firewalls can separate compromised or non-compliant endpoint devices from the network.

Data Loss Prevention (DLP): Firewalls can include rules to stop private information from being sent outside the network without permission.

Firewalls are essential for protecting endpoint devices and maintaining network security by implementing these regulations.

Conclusion

The foundation of my FortiGate firewall deployment was preparation. I ensured I had the necessary framework for an organized and successful deployment by assembling resources and reviewing the fundamental security rules that firewalls enforce.

Lessons Learned

Success Is Defined by Preparation: Compiling images, licenses, and network information in advance decreased deployment errors.

*Policy Knowledge Is Essential: * It became clearer how each setup step relates to actual security requirements after learning about firewall-enforceable policies.

*The Key Is Balance: * Robust firewall regulations must protect without unduly limiting lawful corporate activities.

Endpoint Security Depends on the Firewall: The security of devices is determined by the rules controlling their access and traffic.

My Hands-On Experience with Network Monitoring Using PRTG

Samuel Adeduntan — Mon, 06 Oct 2025 23:04:54 +0000

Introduction

I began my journey with PRTG Network Monitor by installing it on a Windows Server with the aim of gaining practical experience in monitoring both servers and network devices. Once deployed, the tool provided me with the ability to track critical system resources such as RAM usage, storage health, and network performance. This setup gave me real-time visibility into the overall health of my environment and enabled me to respond quickly and effectively to potential issues.

Protocols

During the setup, I learned that PRTG, like most monitoring tools, relied heavily on the Simple Network Management Protocol (SNMP) to collect logs and system information from endpoint devices. Understanding SNMP helped me appreciate how the tool communicated with different systems, regardless of vendor or operating system.

Installation

After downloading the installer, I completed the setup on my Windows Server. Once the installation finished, PRTG automatically launched a web interface on port 8080, using the machine’s IP address. From there, I accessed the login page and dashboard, which became my control center for all monitoring activities.

*Installation Completed *
The moment the PRTG finish installing, it will automatically lunch a wbe instance. Its automatically pick the ip address of the machin and open port 8080, and then lunch the serveice on that same port 8080

Login interface

PRTG Dashboard Overview

Device Monitoring

I then began adding devices to my PRTG environment. I included both Windows and Linux machines. Using the auto-discovery feature, PRTG scanned the network and detected available systems. I configured specific services such as FTP and RDP as sensors.
When I performed a deep scan on these devices, I was able to view detailed information such as:

Hardware configuration.
Installed software.
Logged-in users.
Active services.

This level of insight made troubleshooting much easier whenever a service had issues.

Adding Linux Operating system

Basic Device settings

Auto-discovery setting

Configuration of specific services such as FTP and RDP as sensors.

Basic FTP sensor set up

Succesfully added

Adding a windows machine

Windows server added with many sensors opened

Exploring the functionality of the deep scan of PRTG on a particular device. For instance Windwos server

System inforation under the particular endpoint to be monitored

Hardware information

Information about the Software that are running on the operating system

Users on the system

Details about the Services that are running on the endpoint

Service Monitoring & Alerts

To test the alerting mechanism, I simulated failures. First, I turned off the Wazuh Agent service, and PRTG immediately flagged the issue with an alert. I also shut down the RDP protocol, and a warning notification popped up. Once I re-enabled the services, the alarms cleared automatically.

I also learned how to pause a sensor. This was useful during scheduled maintenance because it prevented unnecessary alerts from repeatedly reporting a known service outage.

Simulation on how the promption notification look like during the service is downoutage, using wazuh agent as a case study.

I Turned off the wazuh agent

RDP protocol Alert simulation

To validate it, I simulated another event by shutting down RDP on the local server. Immediately, PRTG sent an alert, and a notification appeared in my Slack channel. This confirmed that my setup worked and that I could receive proactive alerts even without logging into the PRTG dashboard.

Shoting down the RDP protocol

Alart of RDP protocol outage

I Turned On the RDP again

Linux System Monitoring

I extended my monitoring to a Linux environment. For example, I started the FTP service on my Kali Linux machine and added it as a monitored sensor in PRTG. Just like with Windows, the tool gave me system details, which proved how well PRTG handled cross-platform monitoring.

I Start up the FTP port on kali

Notifications & Integrations

Finally, I explored integrating notifications with Slack. I created a new Slack workspace and channel, then generated an incoming webhook URL. After linking this webhook to PRTG, I set up a notification template.

How I set up notification trigger: I Created a new workspace on slack.com

Slack Dashboard Overview

Creating a New channel

How I generated the webhook URL
Why do we need webhook URL?
Webhook are a way to post messages from apps into slack. Creating an incoming webhook gives you a unique URL to which you send a JSON payload with the message text and some options

Creating the slck app. The slack app is meant to be linked to your slack channel

I had to Select the name name of the channel on the app

Copied the webhook url

How I connected the generated webhook URL to PRTG instance

Setting up the notification policy template

Simulation of an event: I Stoped the RDP service on the local server

Event simulation notification after RDP was turned off

I turned ON the RDP service back

Conclusion & Success Goal Achieved

Through this hands-on project, I successfully deployed and configured PRTG Network Monitor on a Windows Server, added both Windows and Linux machines, and validated system monitoring through proactive alerts. I tested different services such as FTP, RDP, and the Wazuh agent, and verified that the platform immediately detected outages, triggered alerts, and cleared them upon recovery.

Finally, I integrated PRTG with Slack to receive real-time notifications outside the dashboard, making the monitoring setup more practical and responsive.

Success Goal Achieved

The objective of using PRTG for multi-platform device monitoring, service tracking, and proactive notification delivery was fully accomplished. I built a monitoring environment that gave me visibility, alerts, and integrations that mirror enterprise practices.

Lessons Learned

- PRTG Provides Deep Visibility: Its auto-discovery and deep scan features gave insights into hardware, software, and active services across systems, reducing troubleshooting time.
- Proactive Alerts Are Critical: By simulating outages, I experienced how vital immediate notifications are in reducing downtime and improving response times.
- Cross-Platform Monitoring Adds Value: Being able to monitor both Windows and Linux environments under one platform broadened the system’s flexibility.
- Integration Enhances Responsiveness: Slack integration demonstrated the importance of pushing alerts into daily communication tools, ensuring no incident is missed.
- Maintenance Considerations: Pausing sensors during scheduled maintenance avoided alert fatigue and unnecessary notifications, a valuable practice for real-world operations.

#DAY 12: My Project Summary & Learning Journey.

Samuel Adeduntan — Mon, 06 Oct 2025 07:11:55 +0000

Project Summary: 12-Day Uptime Kuma Monitoring Deployment

Introduction

Over the course of twelve days, I designed, deployed, and refined a comprehensive monitoring framework using Uptime Kuma. This project began with foundational service checks and gradually expanded to include advanced monitoring techniques, cross-platform integration, real-time alerting, and external transparency through public status pages. Each phase introduced new layers of functionality that strengthened system reliability, enhanced visibility, and improved overall resilience.

The journey was not only about building a monitoring system but also about gaining hands-on experience with incident simulations, automation, and proactive alerting. By the end of the twelve days, I had developed a holistic monitoring strategy capable of validating both availability and functionality while ensuring timely communication with stakeholders. This project served as both a technical achievement and a valuable learning journey that deepened my skills in system monitoring, infrastructure management, and operational readiness.

Executive Summary

My Goal
My goal was to design and implement a structured 12-day monitoring deployment using Uptime Kuma. I set out to build a system that went beyond basic availability checks by integrating advanced monitoring, proactive alerts, cross-platform visibility, and external transparency.

What I Achieved

I successfully deployed a holistic monitoring framework that validated both service availability and functional reliability. Over the course of the project, I configured diverse monitors (HTTP, TCP, DNS, API JSON), integrated Telegram for real-time alerts, simulated outages to test readiness, and added a Windows host for cross-platform monitoring. I also enhanced security with a reverse proxy (Nginx) and built a public status page to communicate service health. Collectively, these achievements resulted in a resilient, transparent, and responsive monitoring environment.

The System I Designed & Built

To bring together all the elements of my 12-day monitoring project, I designed a unified system architecture that integrates monitoring, alerting, and security into a single framework. The system was built to ensure service reliability, proactive detection of issues, and transparent communication with stakeholders.

Here is the architecture diagram I created to visualize the system. It clearly illustrates how all the components I configured interact from monitored services, to the Uptime Kuma core, to Nginx as a reverse proxy, and onward to Telegram alerts and the public status page. This architecture highlights the flow of data, alerting mechanisms, and security layers that collectively strengthen the monitoring environment.

Core Technologies Mastered:
Throughout this project, I gained hands-on experience and practical mastery of several core technologies that strengthened both my monitoring and systems administration skills:

Uptime Kuma: Configured diverse monitors (HTTP, TCP, DNS, API JSON) and implemented public status pages for transparent service visibility.
Nginx Reverse Proxy: Deployed and configured Nginx for secure traffic routing, SSL termination, and reliability improvements.
Telegram Bot Integration: Set up proactive real-time alerts for faster incident response.
Linux (Ubuntu and Kali): Managed server configuration, service deployment, and troubleshooting within Linux environments.
Windows Host Monitoring: Integrated Windows systems into a unified monitoring framework for cross-platform oversight.
Networking Protocols: Applied knowledge of DNS, TCP, SSH, and HTTP for both internal and external service monitoring.
Incident Simulation & Response: Conducted fire-drill outage tests to validate monitoring effectiveness and system readiness.

My Day-by-Day Implementation Journey

This was my phased approach, where each day I added a new, critical skill.

Day 1: Foundation: I set up my Ubuntu Server 22.04 LTS VM with a static IP and installed Docker Engine. This was the bedrock of the entire project.

Day 2: Core Deployment: I ran Uptime Kuma as a Docker container for the first time, configuring persistent storage so my data wouldn't disappear on a reboot.

Day 3: Internal Monitoring: I installed and configured services like FTP and SSH on my Linux server and created my first monitors in Uptime Kuma. I learned to validate my work by simulating outages.

Day 4: Expansion & My First Big Hurdle: I hit a snag with a Docker container naming conflict that broke my setup. This was a key learning moment: I troubleshooted by checking logs and ports, then used docker rm to resolve the conflict. This taught me real-world container management.

Day 5: Proactive Alerting: This was a game-changer. I integrated a Telegram Bot API, so my phone now gets push notifications the moment something goes down.

Day 6: Organization: I organized all my monitors into clear groups and launched a public status page. This showed me the importance of usability and transparency in DevOps.

Day 7: "Fire Drill": I deliberately broke things! I stopped services to test my alerting system end-to-end. It worked perfectly, proving the system's reliability.

Day 8 & 9: Conquering Cross-Platform Monitoring: I added Windows machines to the mix. The challenge? Windows Firewall was blocking my probes. I solved this by creating custom inbound rules for ICMP and specific ports (80, 445), proving I can manage heterogeneous environments.

Day 10: Advanced API Checks: I moved beyond simple "up/down" checks by configuring a JSON Query monitor to validate the actual data returned by an API.

Day 11: Security & Polish: I installed Nginx as a reverse proxy and used Certbot to get a free Let's Encrypt SSL certificate for my custom domain (status.mydomain.com). This gave the project a professional, secure front-end.

Quantifiable Infrastructure:

Service Types Monitored: 6+ (HTTP, HTTPS, TCP, Ping, DNS, JSON Query)
Operating Systems Covered: 3 (Ubuntu Linux, Windows Server, Windows 10)
Individual Monitors Configured: 15+
Notification Channel: Telegram mobile push notifications.

Key Challenges I Overcame

Docker Conflict (Day 4): This taught me to always manage the full container lifecycle and not just run new instances without cleaning up the old.
Windows Firewall (Days 8 & 9): I learned the intricacies of configuring host-based firewalls for monitoring, a critical skill for any sysadmin/DevOps role.
SSL Certificate (Day 10): I learned that Certbot failures are often DNS-related. I verified my DNS records and firewall rules, which resolved the issue and granted me a trusted certificate.

The Business Value I Delivered (Through This Project)

Proactive Awareness: I transformed monitoring from a passive check into an active alerting system.
Unified Visibility: I now have a single pane of glass for the health of my Linux servers, Windows machines, and external APIs.
Rapid Response: My MTTR (Mean Time To Resolution) is now near-zero thanks to instant mobile alerts.
Cost Efficiency: I built an enterprise-capable monitoring system for less than $10/month on a single VM, a fraction of the cost of commercial tools.

My Evidence & Portfolio Checklist

[Day 1] ──► Docker Installed
Terminal output on Ubuntu VM

[Day 2] ──► Uptime Kuma Dashboard
Accessible via IP: Port

[Day 3] ──► Monitor List
TCP checks for FTP & SSH

[Day 5] ──► Telegram Bot Alerts
Successful test notifications

[Day 6] ──► Monitor Groups + Public Page
Organized layout screenshot

[Day 7] ──► Fire Drill Alert
Telegram outage + acknowledgment

[Day 8 & 9] ──► Windows Host Monitors
IIS & Ping show "UP" status

[Day 10] ──► JSON Query Monitor
Advanced config screenshot

[Day 11] ──► Secure Status Page
HTTPS padlock + custom domain

[Final] ──► Architecture Diagram
Full system overview

This project has given me concrete, demonstrable skills in Docker, reverse proxies, SSL, API integration, and cross-platform system administration. It's a cornerstone piece for my technical portfolio.