Firewall Log Analysis #itp #understanding-networks
As a part of the first assignment for the Understanding Networks course at ITP, I set up an Internet host using Amazon Web Services (AWS). On the AWS EC2 Dashboard, I created a virtual server instance from one of the preconfigured Amazon Machine Images named ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-20240801
. I noticed that the IP address changes after every reboot, so I went ahead and created an elastic IP to assign it to my virtual server instance. Finally, I have an Internet host with a persistent IP address, which I can conveniently access via an SSH client from my computer.
I was supposed to analyze my firewall logs, more specifically, the log file generated by ufw
. However, I was not able to see any log files at /var/log/ufw.log
. It turned out that the logging level of ufw
was set to low on my host, I was able to set the logging level to high with below command:
sudo ufw logging high
After this, ufw
started to log into /var/log/ufw.log
, but I still did not see any blocked connection even after a couple of days, which was surprising to me.
I suspected that the connections that I was hoping to see in the log were probably blocked by EC2’s own firewall before they were ever able to reach my instance. As expected, the inbound rules I had set up for my virtual server instance only allowed connections from my own computer’s IP at port 22
, which is the default port for SSH. After adding an additional rule that allows all traffic with any protocol at any port, I immediately started seeing connection attempts that were blocked by ufw
in its log.
Two days later, following the instructions from Tom, I used the command below to convert all spaces in the log to tabs and saved it as a .tsv
file, which I later imported to a Google spreadsheet.
sudo cat /var/log/ufw.log | sed -e 's/\s/\t/g' > ~/ufw-log.tsv
Since all lines of the log were not in the exact same format, I had to do a little bit of cleanup before all columns were properly lined up so as to be ready for filtering and sorting.
For roughly two whole days, there were 32,126 connection attempts that were blocked by ufw
. These connection attempts were from 6,515 unique IP addresses. The top three IP addresses in terms of the number of attempts are 172.31.80.67
with 40,942 attempts, 169.254.169.123
with 9,489 attempts, and 79.110.62.107
with 3665 attempts.
In addition, below is a screenshot of the top 14 IP addresses for those who are curious.
According to ipinfo.io, the first two are bogon IPs. While I understand that the first IP address is the private IP address of my host, I still wonder what these attempts were made for and what the second bogon IP address is.
The 3rd IP address, according to ipinfo.io, is located in Amsterdam of North Holland. It also shows that this IP address (79.110.62.107
) is associated with Emanuel Hosting Ltd. After reading further into the spreadsheet, I found that this host has been attempting to connect to my host throughout the day for the entire duration that my virtual server has been running (after I added the rule that allows all traffic). I wonder if this is simply the hosting company for the hosts that attempted to connect to my virtual server, or that people from this hosting company were trying to connect to my server.
Out of curiosity, I looked up two more IP addresses from the blocked list (83.222.190.106
and 139.99.17.118
). They are from Pernik and Singapore respectively.
I was partially shocked and partially not so surprised to see so many hosts attempting to connect to my virtual server in a relatively period of time. This finding is bringing up so many questions: Who is behind Emanuel Hosting Ltd and why are there so many attempts from them? Who else are making all these other attempts to connect to my virtual server? I wanted to keep digging to find out more but I’m also hoping the Understanding Networks course will help me slowly uncover these mysteries.