Partner or alone, but working with a partner is good...more than one set of eyes on the wireshark output.
Hand in to pentesting/portscanning.pdf in your CS231 repository.
This exercise is our first foray into the field known variously as penetration testing (or pen testing), white-hat hacking, and ethical hacking. There are, as you might imagine, arguments about fine distinctions between these terms, but ultimately, they all concern the discovery, exploitation, and repair of vulnerabilities in computer systems.
Regardless of our goals, before performing ethical hacking we need permission of the owners of the target systems, as well as a clearly defined scope of action (e.g. what we're allowed to do, and when). In an educational context, our goals are to learn about the techniques of hacking and the corresponding techniques of securing systems. In a typical penetration testing context, a pen-tester will be hired by the system's owners to search for vulnerabilities and make recommendations for improving the system's security. In both situations, permission to hack is needed.
In our case, I have cleared our classroom activities ahead of time with the ITS and Math/CS staff responsible for the security of the systems we'll be working with. Most of our activities will involve the two VirtualBox virtual machines (VMs) installed on each of the computers in Weitz 138. We'll be attacking the Metasploitable VM from the Kali VM, in which context we can approach the task with no holds barred. But occasionally (including today), we'll also reach out to external machines, in which case explicit and specific permission is essential. If you want to take your experiments significantly beyond these lab exercises, talk to me, and we'll figure out a way to get the right setups and permission.
Regardless of the context of our hacking, we will often talk about our work in terms that sound like we're sneaking around. For example, we'll talk about doing "stealth scans" to avoid having our actions show up in log files or get noticed by system administrators. That kind of language is natural and appropriate, but we can't forget that the reason we're trying to avoid detection is to demonstrate to the sysadmins how their systems could be compromised, and to work with them to fix the vulnerabilities.
As you work on this stuff, you will have lots of questions. Write them down. Follow them up. Bring them up on Slack. Ask me when I ask "any questions?" at the start of class. Be curious. Pay attention to details. And definitely, definitely don't expect to understand it all quickly. There's an enormous amount of detail in this material. I'll expect you to understand a layer or two, but there's always more to know.
Today, we'll take a look at a few of the essential first steps in the search for vulnerabilities in a target computer system. To get started:
Suppose you already know the domain name or IP address of the host whose security you're trying to evaluate. There are many online data sources that can help you learn important information about your target. Using these sorts of tools is referred to as passive information gathering because it doesn't involve communicating with the target system itself. Active techniques run the risk of showing up on the target system's log files, alerting the system administrators, etc., so if you can learn something using passive techniques, it's best to do so.
What to hand in:
Sometimes you know the network you're interested in targeting, but not the specific IP addresses. Host detection is the process of finding active hosts on the network.
If you're interested in learning more details about host discovery, here is a handy summary of host discovery techniques, all executable using nmap.
What to hand in:
Once you know the IP address of the host you want to target, it's time to learn more about it. One of the most important things to learn is which ports on your target system have servers listening on them. For example, at this writing, mirage.mathcs.carleton.edu has exactly one port open: port 22, for SSH logins. (SSH access is the entire purpose of mirage in Mike Tie's world. Because Mike is cautious and smart, he has made sure there are no other ports open, so as to reduce the likelihood of anybody exploiting bugs associated with the services on other ports.)
Technically, any server process can listen on any port. That said, there are many ports that are conventionally associated with specific services. SSH is normally on port 22, HTTP is on 80, HTTPS on 443, etc. These port/service combos are called well-known ports. You can see a list of them at the Wikipedia link I just gave you, or by running "cat /etc/services" on a Unix system like Kali.
The process of learning about the available services on a host is called port scanning, so let's scan some ports!
(Want to know how nmap performs a port scan? Go ahead and capture the packets in Wireshark and see what you can learn. That's not mandatory in this part of our exercise, and it's rare that a hacker would worry about the specific packets contained in a port scan, but it's pretty illuminating when you're learning.)
What to hand in: