I tried digging deeper and see which of my processes are connecting to this server and it say's com.apple. It means some native Mac OS process, behind my back, is connecting to this server in New York for a reason I don't know.
I went back to the remote router's web interface, checkout the client list. There are 2 connected devices to this router listed.
I tried to enable SSH on the router so that I could tunnel to the devices with no success because the changes doesn't get persisted. I spent few hours trying to know more about this router and why is it publicly opened. I setup a Wireshark listener to listen to the wire and look at the packets being sent and received to this router and I left it running overnight. Then I slept at 5:00 AM.
The morning after, the first thing I did was to check the Wireshark trace and was disappointed to not find any entry. When I scanned my active connections again, it seemed that the IP address is no longer there in the list of active connections. But I am seeing new ones and again check them in browser. I was suprised that for another IP address, I was getting exactly the same web interface of an ASUS router. The IP address is also geo-located in New York and owned by Amazon.
When I check the client list (the devices connected to the router), I got exactly the same devices with exactly the same MAC addresses. I realized this must be the same router. But the problem is that when I did a reverse DNS and a trace of the 2 IP addresses, they do not agree. The DNS server is saying that those 2 IP addresses does not belong to the same server. The trace is also being routed differently between the 2 IP addresses. It got me scratching my head for a while.
I stopped for a while, brewed some coffee and spent few minutes over a coffee recalling what i have done so far to investigate. I am running out of options so I went to google. Guess what I searched for? I searched "Jieming-PC" hoping to find some guys also having the same problem with whoever this Jieming is. The first 2 results was from a domain "demoui.asus.com". So all this time, I was looking at a demo UI of ASUS routers. Whew! That explains why they look the same, with the same clients. That is just one problem solved because I still don't know why a Mac OS (com.apple) would connect to a demo UI of an ASUS Router somewhere in New York.
I suspected that maybe because I am opening the my Router administration page and that this page is trying to connect to that server. I investigated further by looking at the source code of the ASUS router admin page and finally I confirmed that the page is connecting to that remote IP address to check for Firmware upgrade. I still have one little problem why did the lsof command say that it was "com.apple" who is connecting to that IP and why not "Firefox" (I am using firefox) ? I did a little and found the exact apple library responsible for the connection. It was apple's WebKit which is obviously used by Firefox.
What Really Happened?
What really happened was that when I opened up my router administration page, the first thing it did was to check if there are new version of Firmware available. I updated the firmware. It connected to www.asus.com and downloaded and installed the firmware. The router rebooted. I had to re-open the router administration page. Again it checked for available firmware versions through www.asus.com. Because of load-balancing it got forwarded to some another server (another IP address). This explains why it connected to 2 different IPs. It also turned out that the server used for firmware upgrades are the same server hosting the Demo UI.
Whew!!! Now everything is solved. I can now sleep well knowing that my home network is safe and Jieming is not a Chinese hacker. One lesson I learned and that is I should stop being paranoid.
But anyways, it was a good exercise. I haven't done this kind of things for a long time and now I felt like I'm Sherlock! :D :D
In Software, orchestration often means control, synchronization, mediation and scheduling of decoupled application services in order to ful...
Part 4/4 - Deploying Openshift/OKD 4.5 on Proxmox VE Homelab This is the last part of a 4-part series on Running Openshift at Home. Some inf...
Part 1/4 - Homelab Hardware Part 2/4 - DIY Silent Server Cabinet Part 3/4 - Installing a Two-Node Proxmox VE Cluster Part 4/4 - Deploying O...
Due to an unfortunate event related to the coronavirus pandemic, I have been repatriated back to the Philippines from Singapore. I have now ...