I’d like to come back to an issue I faced yesterday with one my servers. I think that this story could be a good example as part of an IPv6 awareness program…
One of my servers in my home lab runs several virtual machines. This server is reachable from outside via a VPN. On Sunday morning, I tried to access from a remote location and was ejected with a nice “connection timeout” for the SSH port. After some checks, the server looked to be ok, all the other services were running fine, the VM’s were working as expected. As I always bind sshd to a non-standard port, I tried the standard one (22) thinking about a misconfiguration. Same result… I tried from a another box in my LAN, same result. Than I realized that I upgraded the iptables rules installed on the server a few days before. Damned! Reboot the box? It won’t solve the issue as the rules will be automatically reloaded and could cause corruption of files used by the VMs! The only way to solve the problem would be to log via the console but I was far from home… In a corporate environment, an out-of-band access is common but not in this case!
Suddenly, an idea: I logged again on another box in my home LAN which is IPv6 enabled. And from this box, I tried to SSH into the server using his IPv6 address. Bingo! It worked. I successfully logged in and fixed the iptables rules to allow my SSH port again.
What to remember from this story? First, shame on me, my mistake (we all make mistakes) was to forget to enable the IPv6 firewall on the server. In this case, I was lucky and able to take again the control of the box. But, what in case of an real attacker? IPv6 is more and more deployed on networks and sometimes people are even not aware of this. Thanks to the auto-configuration enabled in most systems, devices will receive an IPv6 address and be reachable via both stacks!
This is not the first “bad” story that I faced with IPv6 (read here and here). IPv6 will become becomes a challenge in corporate environments. Keep this in mind!