Objective
The objective of this lab was to become familiar with the initial setup process of a Palo Alto firewall and observe its behavior during boot and connection to the network.
Overview
In this lab session, I worked with a Palo Alto firewall device. Although I did not perform any advanced configurations or in-depth tasks, the session was helpful in understanding some key operational characteristics of the device, particularly during startup.
Procedure
Power on the Palo Alto firewall.
Connect a console or network cable to observe startup messages and monitor the connection status.
Wait for the device to initialize and establish a network connection.
Observe and record the duration and behavior during this process.
Findings
After powering on the Palo Alto firewall, I noticed that it does not connect to the network immediately.
It took approximately 5 minutes from the time the device was powered on until it became fully operational and network connectivity was established.
During this period, the system was initializing internal components and services, which is normal behavior but important to be aware of during setup or troubleshooting.
No further configurations were made during this session, but the delay in connectivity was a key learning point for future deployments.
Conclusion
Although minimal configuration work was performed in this lab, I learned an important operational detail: Palo Alto firewalls require a few minutes to fully initialize after powering on. This delay should be taken into account during troubleshooting or when planning device restarts. Understanding this behavior helps prevent unnecessary concern or misdiagnosis of connectivity issues immediately after startup.
In this module, I completed hands-on training in vulnerability management, focusing on the use of Nessus Essentials and OpenVAS as vulnerability scanning tools. I learned the differences between vulnerability assessments and penetration tests, and how tools like Nessus and OpenVAS help identify potential weaknesses in systems without exploiting them.
The module also covered vulnerability scoring systems, specifically CVSS and Microsoft DREAD, which are used to evaluate the severity and risk of discovered vulnerabilities. I gained experience interpreting these scores and understanding how different metrics—such as impact on confidentiality, integrity, and availability—contribute to overall risk levels.
Additionally, I practiced installing, configuring, and running scans in both Nessus and OpenVAS. Through this, I learned how to interpret scan results, recognize false positives, and understand the importance of authenticated vs. unauthenticated scans. Overall, the module helped me build a solid foundation in identifying, prioritizing, and reporting vulnerabilities as part of an effective security program.
In this module, I explored the full penetration testing process, from initial client engagement to post-engagement activities. The module broke down each stage of the process—Pre-Engagement, Information Gathering, Vulnerability Assessment, Exploitation, Post-Exploitation, Lateral Movement, Proof-of-Concept, and Post-Engagement—and emphasized the importance of flexibility, documentation, and legal compliance throughout.
I learned how to properly scope and structure a penetration test, including defining rules of engagement, signing NDAs, and setting goals with clients. The module also highlighted the legal frameworks in different regions that govern ethical hacking practices, making it clear how important it is to operate within legal boundaries.
Each phase was detailed with examples and explanations to show how findings from one stage inform the next. I gained a better understanding of how penetration testers escalate privileges, move laterally across networks, and document their findings through proof-of-concept development and final reporting.
Overall, this module gave me a strong foundation in penetration testing methodology and helped me understand the professional and ethical responsibilities involved in performing offensive security assessments.
Objective
The objective of this lab was to begin building a scalable, remote-accessible cloud lab environment using Dell PowerEdge servers, Proxmox VE, and a Ubiquiti firewall. This setup will allow future students to remotely access virtual machines and complete pre-configured labs.
Summary of Work Completed
Installed Proxmox VE on Dell PowerEdge servers to serve as the primary hypervisor.
Configured a Ubiquiti firewall to handle routing and manage network traffic between lab resources and external access.
Deployed initial virtual machines, including:
A Windows Server VM
A Ubuntu Server VM
These virtual machines were intended to serve as the base images for future lab activities.
Planned but Not Completed
Although I did not personally work on it, the plan was to use Ansible as an automation tool to take snapshots of these VMs. These snapshots would allow instructors to quickly reset the environment or deploy consistent lab instances for future students. The idea was to streamline lab management and ensure students could always start from a clean, known-good state.
Challenges and Progress
While the lab is not yet complete, the foundational setup was a valuable learning experience. Working with enterprise-grade equipment and real-world virtualization and network tools provided insight into how production environments are built and maintained.
Reflection
This lab gave me my first hands-on experience with commercial server hardware and tools used in professional IT infrastructure. Even without completing every component, I gained practical knowledge in server setup, virtualization with Proxmox, and firewall configuration using Ubiquiti devices—skills that are directly applicable to modern IT and cloud environments.