top of page

A Beginners' Journal to Practicing Cybersecurity, Part 1

Writer: Jarod Yeager
Jarod Yeager
Oct 21, 2024
7 min read

Updated: Oct 28, 2024

Hello reader!

If you're viewing this, you're probably perusing my professional development projects on my website or viewing my LinkedIn posts. Or you're a supportive friend or family member. In either case, welcome! I'm Jarod. I graduated with a degree in graphic communications from Clemson University in 2022, hoping to secure a graphic and web design job. However, while this was a career in which I knew I could excel, I also realized that I could only go so far. So this year, I deviated from this path, starting a Master's in Cybersecurity at Western Governors University to fulfill a lifelong dream of mine - a career in science and technology. I have very little practical experience in tech besides a solid understanding of user experience and design on the front end, so I concluded that if I wanted to make it in the industry, I would have to learn a few practical skills. This blog documents that journey of research, learning, and the misadventures of someone just getting started in the ever-changing cybersecurity field.

Because I'm so new to the tech industry, Writing about this is the perfect way to show my unique perspective to both beginners and more seasoned cybersecurity veterans alike and document my experience and the results I've come to find on my own. So, I hope to write this and subsequent blog posts in a way that can professionally showcase my findings while also being entertaining and readable by non-tech readers or people just getting into the field, like myself. I'll also list my sources as I go for anyone who might be inspired to try this for themselves.


The Plan



After some research, I've decided that the first project will be building a web server. This is advantageous for my portfolio for several reasons: It builds upon my skills in UX/UI and design for creating the actual website, and it eventually enables me to build skills in vulnerability management and penetration testing by both finding vulnerabilities and fixing them, and it's a very budget-friendly option, as I had an unused PC - an HP Victus 15L gaming laptop (The 'Gaming' label was suspicious at best) - just taking up space that would be perfect for practice. And thus, the pieces were laid out. The first step was research: how was I going to do this? Was there a special program to download to turn an old Windows tower into something that holds website files? It turns out, as with many things in the tech industry, there was no straight answer. But, I knew my specifications: I wanted to build a web server and make this as low-cost as possible, which helped to narrow down my options. Surprisingly, that ruled out using Windows OS for this server - Take the video I linked at the top of this section: it does a great job of outlining the basics of what a server does and the hardware upgrades for one, but almost all the software involved has a subscription cost.

However, there was a solution I had heard about but had never tried - using the Linux OS, specifically, the Ubuntu Server. It's a command-line-only system, but it was completely free to install, and any software I needed, like Apache, also came with no subscription strings attached, so it was the perfect option. Besides, many of my current studies involve Linux commands anyway, so this was yet another opportunity to put my education into practice. With this knowledge and plan, it was time to build my server.


Installing The Server

I have never installed an operating system onto a computer before - the closest I have ever come to that was reinstalling Windows every few years to keep my computer performance optimal. So, when I was looking into installing one - that I have never used, mind you - onto one of my computers, I was a little nervous; however, for those who have never installed an OS before, I was not expecting how easy it was. Most OS developers have a disk image that can be downloaded from their websites as a .iso file at no cost. This was incredibly handy, as I just had to go to the Ubuntu website and download the image file onto a flash drive. As an added benefit, I have an install file for Ubuntu for any computer I want to turn into a server. Anyway, with the drive in hand, literally, it was time to start installing.

Indeed, the most difficult part of installing a new operating system is not downloading, formatting, or even the installation itself. It is finding the right key input and shutdown/restart combination to get to the basic input/output system (BIOS) menu, especially with HP devices such as my Victus 15L. Reaching the menu that allowed me to reboot using a USB flash drive was trial and error. But now, looking back, I realize that this almost blind approach to troubleshooting is pretty common in the tech industry, as I'll touch on later in this entry and quite possibly more in this whole series. Reaching BIOS notwithstanding, installing Ubuntu on the computer was equally as easy as downloading it to the flash drive: selecting the option to download from the USB drive and setting Ubuntu 20.04 up as a server.


Troubleshooting

Ubuntu was downloaded and installed easily enough, but now, configuration management would take its course, and it would not be an easy fix. The main problem came in the form of Secure Shell (SSH), a protocol used to remotely connect one device to another to execute commands from the remote computer. The plan is to access the server from my main work computer via the home network using SSH as the connection. This worked fine after installing and running the server with default settings. The problem came after setting a static IP address.

For the uninitiated, here are some Internet basics: The IP address of a device is like a home address or a phone number for your home: it's how other computers know where to send their information so that communication can happen between devices. This is one of the most fundamental principles for the internet today. Your home network is like a cul de sac of the internet - its own enclosed space with similar address names, differing by a subset of numbers. This is a major simplification, but it helped me a lot when I started learning about networking.

With complete default settings, an Ubuntu server has a dynamic IP, which means it rotates its IP address after a specified time. This is a safe security practice, but I need that address to remain the same so I can connect with it from my main computer and start working on my web server without needing to check it every few days to learn the new address. This is a security issue I have already made a note to explore later in this journey.

With this information in mind, setting a static IP address in a Linux-based command line comes from the Netplan file folder in the configuration files. A great guide for setting this up is on freecodecamp.org, found in the sources at the bottom of this post. From here, it's only a question of what IP address you choose for the server.

All this is to say that my main work computer's remote SSH connection to the server was not working after setting the static IP address. The error was:


'ssh server connect to host (IP-Address-here) on port 22: Connection timed out.'


It is important to know network topology and what is happening on your network in a situation like this, which made this a very good learning situation for me. I began diving into commands to explore the network, each test bringing me closer to the answer.


Here's what I tried:

  • SSH was enabled and active on both the server and remote computer.

  • Both the server and computer firewalls are active, and I established a rule to allow port 22 in and out.

  • Pinging google.com from the server yields data, which tells me that the internet can be reached from the server.

  • Pinging from any computer to any other computer on the home network is the same: 'Request timed out.'

  • SSH throws the same timeout error whether I'm attempting to reach the server from a computer or another Windows machine from my home machine.

  • I changed the port to a nonstandard port (2255), updated the firewall rules to allow traffic both in and out, and tested this method with unchanged results.


Based on this information, I concluded that the problem area is from within the network. A firewall rule in the router or network switch must not allow traffic to flow through.


Conclusion

By taking the first step into networking and troubleshooting, I've been able to take my knowledge further than just reading theory alone. For one, I know more about problem-solving and gleaning information from networks and computers using Windows Powershell, Linux command line language, and error messages than I once did. What was unfamiliar territory to me is now like a new language I can read with a wealth of information on the invisible lines connecting computers. And while I've learned a lot, I can also say much is left to do. I now have an empty shell of a server to be molded into a web server, and the scope just got bigger. The next step is to start modifying the network to allow connections. But I'll have to leave this for Part 2. For now, I hope you enjoyed reading my first real journey into the technological world of networking, and I hope you will stick around for part two.


Links

 
 
 

Comments

bottom of page