This past week I discovered that a part of my home network had an admin panel with a generic login. If that wasn’t scary enough, after updating the credentials I found that various of my network logs showed warnings for DoS attacks and other weird behavior. Finally, I was also running into internet connectivity issues where I would have to restart my network devices almost daily.
I decided to investigate (see my legal disclaimer a couple of paragraphs down). I started with WireShark, an effective packet sniffer with a convenient and useful GUI. This very quickly gave me an idea of what my network traffic looks like. On the other hand, there were many odd source addresses and very little context to make any determinations. There were no obvious red flags that would indicate something like a DoS or DDoS, but the odd source addresses, for example there were many different Amazon EC2 instances, gave me pause.
I needed a way to make sense of the traffic. I compared timestamps and port numbers between WireShark and my network logs. I quickly realized that my network log warnings were very rare compared to the general traffic (another indicator that I didn’t need to worry about DoS). I also found that although my network device logged one warning on port 80, I didn’t find any corresponding packets in my WireShark grab. That was reassuring because it meant that was deflected, noone was sitting on it, or it wasn’t a threat to begin with. But it was not enough to satisfy me.
I did a simple Google search on the kind of network warnings I had in my logs and found reputable sources confirming that the EC2 instances were likely from a service like Netflix and that sometimes they can cause this warning. Again, reassuring, but not quite enough.
I decided to run a couple nmap (network mapper) commands. Note that because this was my personal network with devices I own there were no legal issues with me using these tools. However (legal disclaimer), if you are planning to use these tools make sure you understand the legal ramifications in your jurisdiction first. Nmap has a webpage explaining some things to consider, but ultimately only an expert in law can tell you for sure.
I ran the following nmap commands:
nmap -sT <host> nmap -sV <host>
The first command returned a list of ports that nmap connected to on my network. The second command returned a list of software versions running on those ports.
At that point I felt I had a very good idea of what was happening on my network and everything looked pretty ok. For example, the software running on most of the ports was exactly what I expected. However, just to check a couple of odd ball ports that were running what appeared to be software updaters, I ran one final command on each port:
lsof -i tcp:<port>
This ‘list open files’ command, using the show-all-connections flag, returns all processes running tcp on that port on your local machine. Just as I suspected, running this command returned nothing because the processes running them were on another machine. This was enough for me at the time because it met my expectations which put me at ease.