My Cybersecurity Progress 1: My Pentesting Lab Blueprint

While learning cybersecurity, I realize that this field is not just about theory. Theory tells us the definitions of keywords used to describe the terms, systems, tools, attack surfaces, and so on. It also tells us how to detect intrusions and data breaches. But to actually recognize the threats, mitigate risks, and recover damages, practice is without doubt required. So, I decided to build my own lab to practice what I have learned in courses.

There are a lot of labs that are already provided by organizations, such as HackTheBox, but I think I would like to understand how to build a secure network, how to defend a system, and how to respond to an incident rather than just to perform offensive actions.

The lab I built runs on Docker because it is lightweight, and I need several containers that run simultaneously to simulate attacks and defenses.

In this lab, I made four networks, Internal Network (172.18.10.0/24), Database Network (172.18.20.0/24), Management Network (172.18.30.0/24), and External Network (172.18.40.0/24). Besides the segmented networks, I created containers that represent systems used in real world running the services. Below is the introduction to these containers.

The attacker container represents a user trying to access the web service or attack it. It will access the service through the proxy container that is already mapped to the domain www.lab.com. The proxy container intercepts the requests made by the attacker using Nginx, filters them, then forwards them to the web server. Then the web server processes the requests, fetches the data, or stores it inside the database container. Every attempt to access the service will generate logs, and they will be collected by the SIEM container.

With this topology, I as an attacker can't directly access the database to steal data. I have to compromise the proxy or the web server container, then make lateral movement to the database with the credentials existing in the web server. And I as a developer or administrator can make defensive strategies to mitigate the risks, analyze the logs, respond to the incidents by performing actions, such as containment, and recover the damage after the incidents have been solved.

The attacker container has offensive tools like Nmap, Gobuster, and Exploitdb. Whereas the proxy container has Iptables and Fail2ban. The defensive tools are only installed inside the proxy container in order to keep the web server and the database lightweight.

I also made containers that have services with certain versions famous for having vulnerabilities. I put these containers in the external network. They are used to test these vulnerabilities and learn how to patch them and mitigate the risks.

I made a container that is built from Apache 2.4.49. This version of Apache is notorious for having Path Traversal and Remote Code Execution vulnerabilities. I gave it the IP Address 172.18.40.51/24.

Besides Apache 2.4.49, I am planning on installing other services with versions that have notorious vulnerabilities.

Besides this lab, I prepared Virtual Machine to perform actions that need a separate kernel, such as Privilege Escalation. Because Docker shares the same kernel as the host, the root user in Docker is actually the root user of the host.

Besides Privilege Escalation, I use Virtual Machine to learn Windows systems. Because the OS used in enterprises is not just Linux, but also Windows. So, it is important to understand it if I am tasked with securing or penetrating it. Then, I use this Virtual Machine to try malwares, to understand how they work, and to understand how they are cured.

In the next articles, I would like to describe what I will have done, the offensive attacks like reconnaissance, XSS, SQLi, RCE, and so on, along with the defensive strategies and responsive actions.

To see my lab, you can visit my github repo.