Setting Up a Home Hacking Lab

I’ve been hard at work setting up my new pen-testing lab, which will operate over the network I have set up in my room. This article will be both a documentation of my progress as well as advice for others who wish to set up similar labs in their own homes. The purpose of the hacking lab is twofold: to learn about exploits that have been developed in the past and get hands-on experience using them, and to test new exploits that one has come up with oneself.


Step 1: Isolate your network

This is important for two reasons: First, it prevents any malware that you’ve crafted from escaping your network and infecting other people’s machines, potentially resulting in criminal liability. Second, it prevents anyone outside the network from seeing that you have a vulnerable server up and deciding to break into it and/or infect you with malware.

There are two ways to isolate your network: one is physical isolation (completely disconnect everything from the outside world) and the other is to put everything behind a hardware firewall. I am using the latter method for now, because currently I’m only experimenting with unauthorized access to servers. In the eventuality that I start testing viruses and worms on my network, I will take additional precautions, including total physical isolation. This is due to the extra configuration I would have to go through disabling and re-enabling outbound traffic to prevent malware from escaping. Might as well just take it offline entirely.

The other tip that I think is very important is to completely disable WiFi on any vulnerable devices. The network for a hacking lab should be wired only. Make your devices WiFi-enabled and you open yourself up to any WiFi leeches outside who know how to get into your network (which is trivial to do if you have an XFinity hotspot) and if they are sufficiently tech-savvy, run a port scan, find your vulnerable devices, and launch an attack.


Step 2: The command center

There are a few options you can use for the computer you will be doing your hacking from. Personally, I have Kali Linux set up in a virtual machine, which I can launch attacks from using the myriad of hacking tools Kali Linux provides. Some attacks I won’t need Kali for, especially if they’re exploits that I’ve crafted myself, so I can just launch them from plain ol’ Windows. For malware that spreads easily, I would recommend going a step further and booting from a live medium, and not accessing your hard drive at all. This will prevent viruses and worms from infecting your permanent filesystem.

Kali Linux


Step 3: The HackMe server

As the centerpiece of my hacking lab I have set up a server that I will practice hacking into remotely. Some people use a VM for this, but I prefer something that isn’t on the same computer as my command center, because then I get the authentic feeling of gaining unauthorized access to a remote system over a network. The server I have set up is based on a Raspberry Pi running an Apache web server with PHP and MariaDB. I have set it to boot to the CLI so that it will run faster, and additionally I have set up a PHP Info page that I can use to view a quick readout of all the web services offered, which can be of great use in finding vulnerabilities to exploit. I’ve also changed the hostname to “hackme”.

phpinfo

I plan to experiment with other servers in the future. Possibilities include an email server, a DNS server, an FTP server, an NTP server, and a VPN, to try out the respective exploits associating with these protocols.


Step 4: Backups

If you’re going to be wreaking havoc on your own machines, it’s probably a good idea to back them up. That way you can easily revert any malicious changes you’ve made and restore them to their original state. After installing the software I wanted and setting the desired settings, I booted my battlestation into Arch Linux and made an image of the Micro-SD card for my HackMe server using the dd command.


Step 5: Virtualization (for botnet devices and legacy exploits)

Virtualization can come in very handy in pen-testing, for obvious reasons. I have a sacrificial computer that I plan to run a botnet cluster on when I’m working with viruses and worms. You set up these botnet VMs like you would any other VM, except that it’s very important you set the networking mode to “bridged” rather than “NAT”. This will make it so each botnet VM is visible on the network as a separate device that you can infect.

I also have some VMs that I’ve set up (or plan to set up) for legacy exploit testing. This means testing of exploits that will have been patched in the software running on my HackMe server. The purpose of this is not so much to learn practical hacking skills to apply in the future as it is to learn about the history of hacking and cyber-security and get hands-on experience applying exploits that would have been used in the past.

The specific platforms I have set up for doing this are MS-DOS 6.22 and Mandrake Linux 6.0. The latter of these was the only legacy Linux distro I could find on WinWorldPC.com – it dates back to 1999 and Linux kernel version 2.2. Originally I tried installing it in a Mandriva VM, only to get the following error screen:

Mandrake Linux kernel panic

I then set up a Linux 2.2 VM and that solved the problem, though I still can’t seem to get X11 to work. Here’s the login screen for Mandrake, with ANSI art of Tux the penguin:

Mandrake-login-screen

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s