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
| IP | Location | Packet Length | Protocol | Affiliations |
| 80.82.77.212 | The Hague, Netherlands | 1500 | UDP | IP Volume VPN |
| 119.203.31.40 | Daejoen, South Korea | 949 | TCP* | KT Telecom |
| 218.92.0.207 | Nanjing, China | 932 | TCP* | China Telecom |
| “ | “ | “ | “* | “ |
| “ | “ | “ | “* | “ |
| “ | “ | 908 | “* | “ |
| “ | “ | “ | “* | “ |
| “ | “ | “ | “* | “ |
| “ | “ | “ | “* | “ |
| “ | “ | “ | “* | “ |
| 222.186.42.213 | Zhenjiang, China | 908 | TCP* | “ |
| 103.145.13.9 | Tallinn, Estonia | 663 | TCP* | Severius Holding, Data Center |
| “ | “ | “ | TCP* | “ |
| “ | “ | “ | TCP* | “ |
| 146.88.240.4 | Ann Arbor, Michigan | 655 | UDP | Arbor Networks |
| “ | “ | “ | “ | “ |
| 113.31.125.177 | Shanghai, China | 540 | TCP* | Shanghai UCloud Information Technology Company (Cloud Server) |
| 195.154.40.99 | Paris, France | 502 | UDP | Scaleway Cloud Server |
| 51.75.86.211 | Limburg an der Lahn, Germany | 500 | UDP | OVH Cloud Server |
| 106.12.144.57 | Beijing, China | 492 | TCP* | Beijing Baidu Netcom Science and Technology Co., Ltd. |
Top 20 IP Addresses by Number of Connection Attempts
| IP | Location | # of Connection Attempts | Protocol | Affiliations |
| 94.102.51.29 | The Hague, Netherlands | 407 | TCP | IP Volume VPN |
| 94.102.49.114 | The Hague, Netherlands | 220 | “ | IP Volume VPN |
| 44.55.32.34 | San Diego, California | 132 | “ | Amateur Radio Digital Communications |
| 195.54.160.228 | St Petersburg, Russia | 131 | “ | Arkada LLC |
| 185.41.186.11 | Moscow, Russia | 126 | “ | MTW Cloud Server |
| 87.251.74.3 | Moscow, Russia | 126 | “ | “IP Chernyshov Aleksandr Aleksandrovich” Spam Server |
| 141.212.123.193 | Ann Arbor, Michigan | 89 | “ | University of Michigan Engineering School |
| 185.175.93.37 | Kostroma, Russia | 87 | “ | “Ip Chistyakov Mihail Viktorovich” Spam Server |
| 185.176.27.26 | Sofia, Bulgaria | 80 | “ | “IP Dunaev Yuriy Vyacheslavovich” |
| 185.176.27.234 | “ | 78 | “ | “ |
| 185.176.27.30 | “ | 78 | “ | “ |
| 185.176.27.102 | “ | 77 | “ | “ |
| 195.54.161.85 | St Petersburg, Russia | 75 | “ | Arkada LLC |
| 193.27.229.224 | St Petersburg, Russia | 67 | “ | “ |
| 195.54.167.89 | St Petersburg, Russia | 67 | “ | “ |
| 195.54.167.91 | St Petersburg, Russia | 67 | “ | “ |
| 45.129.33.6 | Nuremberg, Germany | 64 | “ | IP Volume VPN |
| 194.15.36.196 | Frankfurt, Germany | 61 | “ | MyLoc Cloud Server |
| 195.54.167.174 | St Petersburg, Russia | 61 | “ | Arkada LLC |
| 45.129.33.40 | Nuremberg, Germany | 61 | “ | IP Volume VPN |
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.