Set Up A Host Assignment

PIN

Setup

On September 8th, 2020, I spun up a virtual server through the Digital Ocean service to Tom Igoe’s assignment specifications. Our assignment was to leave our server running for a week with an Uncomplicated Firewall (ufw) and to observe and analyze the firewall’s logs of attempted connections to our server. On September 14th, I extracted my logs using the method outlined in a supplementary video provided by Tom Igoe. I could not find the log files using the Unix “ls” file listing function – I will follow up with Tom to discern why I could still access these logs when the log files were not immediately listed in the home directory of my server.

Summary of Attempted Connections

As of 20:00 on September 14th, there were 7943 attempted connections to my server, from 2296 unique IP addresses. Interestingly, all of these connection attempts began on September 13th, with 4326 connection attempts made on the 13th, and 3617 connection attempts made on September 14th. I have provided information on the top 20 IP addresses that attempted to send the largest packets, the top 20 IP addresses with the most attempts to contact my server, and their respective locations of origin and communication protocols. I found out information such as affiliated companies and countries of origin of my logged IPs using the Hurricane Electric Internet Services and LiveIPMap tools.

Top 20 IP Addresses by Packet Size

IPLocationPacket LengthProtocolAffiliations
80.82.77.212The Hague, Netherlands1500UDPIP Volume VPN
119.203.31.40Daejoen, South Korea949TCP*KT Telecom
218.92.0.207Nanjing, China932TCP*China Telecom
“*
“*
908“*
“*
“*
“*
“*
222.186.42.213Zhenjiang, China908TCP*
103.145.13.9Tallinn, Estonia663TCP*Severius Holding, Data Center
TCP*
TCP*
146.88.240.4Ann Arbor, Michigan655UDPArbor Networks
113.31.125.177Shanghai, China540TCP*Shanghai UCloud Information Technology Company (Cloud Server)
195.154.40.99Paris, France502UDPScaleway Cloud Server
51.75.86.211Limburg an der Lahn, Germany500UDPOVH Cloud Server
106.12.144.57Beijing, China492TCP*Beijing Baidu Netcom Science and Technology Co., Ltd.
* Implies packet size triggered “Don’t Fragment”

Top 20 IP Addresses by Number of Connection Attempts

IPLocation# of Connection AttemptsProtocolAffiliations
94.102.51.29The Hague, Netherlands407TCPIP Volume VPN
94.102.49.114The Hague, Netherlands220IP Volume VPN
44.55.32.34San Diego, California132Amateur Radio Digital Communications
195.54.160.228St Petersburg, Russia131Arkada LLC
185.41.186.11Moscow, Russia126MTW Cloud Server
87.251.74.3Moscow, Russia126“IP Chernyshov Aleksandr Aleksandrovich” Spam Server
141.212.123.193Ann Arbor, Michigan89University of Michigan Engineering School
185.175.93.37Kostroma, Russia87“Ip Chistyakov Mihail Viktorovich” Spam Server
185.176.27.26Sofia, Bulgaria80“IP Dunaev Yuriy Vyacheslavovich”
185.176.27.23478
185.176.27.3078
185.176.27.10277
195.54.161.85St Petersburg, Russia75Arkada LLC
193.27.229.224St Petersburg, Russia67
195.54.167.89St Petersburg, Russia67
195.54.167.91St Petersburg, Russia67
45.129.33.6Nuremberg, Germany64IP Volume VPN
194.15.36.196Frankfurt, Germany61MyLoc Cloud Server
195.54.167.174St Petersburg, Russia61Arkada LLC
45.129.33.40Nuremberg, Germany61IP Volume VPN
It should be noted that there is no overlap in IP addresses in both charts

For individuals with NYU credentials, I have included all the logged information from my firewall and my analyses. My server will be taken offline September 15th.

Insights

1. I am confident that I was hacked. Probably just port scanned.

I believe this to be the case because my server was port scanned by Arbor Networks (the Ann Arbor based IP addresses). Arbor Networks is a subsidiary of NetScout Systems, a network protection contractor, that is known to use the IP address 146.88.204.x (found in my list) when scanning threats. When I reached this conclusion, I decided to forgo an analysis of timestamps of attempted connections, as this resource provided by Tom Igoe made clear that hackers frequently alter time logs.

Edit: Tom Igoe thinks I was just port scanned, I hope this is the case.

2. Actors that try to send large packets are more likely to use UDP.

This pattern may be attributed to “fragmentation” in TCP protocols. Fragmentation breaks up packet transmissions that are above a certain size, called Maximum Segment Size, and re-assembles them. This process occurs specifically using the IPv4 protocol. While UDP is likely to drop certain packets during communication (by design), critical packets of TCP may be dropped in the fragmentation process, particularly if the packages are large. I am still figuring out the implications of how frequent fragmentation could have affected my server – more information on fragmentation can be found here.

3. VPN and cloud server services are popular among “less coordinated” actors.

I categorize “less coordinated” actors as groups of 3 or fewer IPs that share similar properties. To be clear, these insights are only based off of my top 40 charted IP addresses, though the distinction between “more coordinated” and “less coordinated” actors is readily apparent within this sample. A “less coordinated” group from the Netherlands was both the most persistent in their connection attempts, and attempted to send the largest packet. I have struggled to find information about the true origin of these Dutch actors, as they used a VPN with many nodes. I am still confused by the IP addresses registered to pseudonyms, such as IP 87.251.74.3 registered to “Chernyshov Aleksandr Aleksandrovich” – an IP that was traced to a Twitter account that was churning out malicious porn links.

Two “less coordinated” actors stood out to me, leading me down strange research rabbit holes. First, was IP 106.12.144.57, registered to Beijing Baidu Netcom Science and Technology Co., Ltd. At first glance I thought this was Chinese search engine Baidu port scanning my server, however, they used a TCP protocol and tried to send an enormous package to my server, whereas port scanning is usually conducted using UDP. I will conduct more research to find out what the implications of this are. Second, was IP 44.55.32.34, registered to the Amateur Radio Digital Communications organization in San Diego, California. This organization provides free network tunnels similar to VPNs for radio and networking hobbyists. I’d like to believe that the intent of this actor was for educational and benevolent purposes only.

Edit: In trying to figure out what’s up with Baidu, I found out that TCP port scanning is a thing, and when attempts to send packages are done in the process this type of attempted access can constitute an “attack”.

4. “More coordinated” actors were Russian and Chinese.

“More coordinated” Chinese actors were more likely to send large packets from the same IP address, while the “more coordinated” Russian actors of St Petersburg used different IP addresses that tried to connect most frequently. All the St Petersburg IP addresses were registered to Arkada LLC, an Azeri construction company that I think is a front for something more insidious. While I need to do more research, I believe that the “more coordinated” actors in Bulgaria are related to the St Petersburg ring.

Personal Note

Much of the qualitative insights in this posts are assumptions, subject to my personal bias, and require more research to be substantiated. Tom Igoe has pointed out that a registered IP location does not always indicate the true locale of an actor, and there are many reasons why an actor may obfuscate their true location.

Moving Forward

I would like to reach out to Arbor Networks and Amateur Radio Digital Communications to see why they were trying to connect to my server, as they seem to be the least dangerous of the groups that tried to connect to my server. Additionally, I would like to answer the questions that I have posed throughout this blog post.

You May also Like

Leave Your Comments