Name: Irais MAGANDA

Date: 10/27/2022

Lab 05: Analyzing Types of Attacks and Mitigation Techniques

Objective:

In this lab, you will perform the following tasks: Compare and contrast types of attacks,
Perform Brute forcing SSH attacks, Perform dangerous Linux commands

How can the objectives be applied outside the educational environment:

The objective can be applied outside the educational environment because these
attacks happen in the real world so we should be able to identify them and know how
they are performed in order to combat them.

Synopsis / Summary

In this lab, you will be conducting host security practices using the command line along
with scripts.

Lab Work (Screen caps with descriptions at least 6 screen captures)

I typed in service sshd status in Ubuntu to make sure that the SSH service was running. I typed
in q to quit. The password was NDGlabpass123!
On the Kali machine, I typed in ssh [email protected] “uptime” This was done to test the
SSH connection to the Ubuntu machine. When it asked me if I wanted to continue I said yes. I
typed in NDGlabpass123! As the password and viewed the load average.

I went on the Ubuntu machine and went to the Terminal window. I typed in grep “Accepted
password” /var/log/auth.log | grep “203.0.113.2” because the lab instructions said to type in grep
-a “Accepted password” /var/log/auth.log | grep -a “203.0.113.2” but it didn’t work. This was
done to grep the log entry recorded from the SSH connection which was initiated by the Kali
machine previously. The screenshot indicates that the system accepted the SSH request from
the Kali machine.

On the kali machine in the terminal window, I typed in ncrack -help to see what options were
available that could be used with ncrack. I initiated the ncrack tool against the Ubuntu ssh
service by entering ncrack pv 172.16.1.10 –user sysadmin -P /usr/share/wordlists/fasttrack.txt -p
ssh. By using the command, a predefined password list was utilized (fasttrack.txt) I let ncrack
run for about 2 minutes until the password was found.
I moved to the Ubuntu machine terminal window where I typed in sudo nano
/etc/sshguard/sshguard.conf in order to change the sshguard configuration. I used the arrow
keys to move the cursor and so I changed Block and detection time to 60 then I saved the
changes with Ctrl + S. This was done to make the lab easier because the detection and block
times are key to how malicious actions are blocked or dealt with.

I checked the firewall setting on the Ubuntu machine by typing sudo iptables -S. I also typed in
the password NDGlabpass123! To start the sshguard I had to type sudo service sshguard start.
There was an extra entry of -N sshguard created which gave sshguard the ability to inert firewall
rules to block malicious hosts.
I typed in sudo iptables -A INPUT -p tcp -m tcp –dport 22 -j sshguard. This was done to
configure the sshguard to auto block attacks.

I went back to the Kali machine. I ran ncrack to attack the UBuntu machine. I typed in ncrack -v
172.16.1.10 –user sysadmin -P /usr/share/wordlists/fasttrack.txt -p ssh in order to run the attack.
However, the attack failed because the sshguard blocked it.
I moved back to the Ubuntu machine. To see the change in the firewall, I had to type sudo
iptables -S. The last entry in the iptables was created to block the access from 203.0.113.2, the
Kali machine.

I typed in ssh [email protected] on the Kali machine. This was done to see if it would
work as it was blocked the first time.
I analyzed the Ubuntu’s auth.log file for failed password attempts. This was done with the use of
grep “Failed password” /var/log/auth.log | grep “203.0.113.2” once again the use of -a did not
work so I had to omit it. I had to clear the terminal afterwards.

On the Ubuntu machine, I typed in htop. The point of this command is to monitor the CPU live.
This is also used to monitor the memory usage within the terminal window.

I had to open a new Terminal window by right clicking on the Terminal icon and then
selecting New Window. I had to display the terminals side by side. I typed in :(){ :|: & };:
this was done to initiate a fork bomb attack on the Ubuntu machine. At around 4
minutes, the CPU usage spiked, almost reaching 100%, the memory and swap memory
also spiked. The UBuntu machine is running out of memory because it is making
multiple copies of itself that is setting off a chain reaction which results in it rapidly
utilizing the system’s resources. Because the system is overwhelmed so the htop
application was slow. I then had to power off and power back on the machine.
I typed in sudo iotop to be able to monitor the I/O activity. I positioned the terminals side by side
once again. I typed in sudo dd if=/dev/zero of=/dev/sda in order to mimic an HHD attack if the
attacker had access to a physical machine within a network infrastructure. Heavy I/O activity is
taking place in the terminal. I waited approximately 3 minutes until the system crashed. I then
turned off the device.

I waited around 2 minutes before turning it back on. Then I waited around 3 minutes
until the screen above appeared, indicating that no operating system was available. The
dd command was successful because the damage was done, the device was flooded to
the point it could no longer function because it had overwritten files.

Questions and Prompts within the Labs

No questions or prompts.

Reflection

I learned what a fork bomb was. I had a general idea of what DoS attacks were but I
was a little unsure what they meant by fork bomb. Basically, a fork bomb is a type of
DoS attack in which the fork system call is repeatedly utilized until all system resources
are “exhausted” and can no longer keep going because it is overloaded and unable to
respond to input. The point of sshguard, as the name implies, is to protect hosts from
brute-force attacks against SSH. I learned the :(){ :|: & };: command which I don’t recall
seeing before. Some of the commands I remember seeing briefly or recognize the
structure/style of it but the fork bomb command I hadn’t seen before.
Configuration Files or Your Code