IPv6 servers beat IPv4 in security -- for now

IPv6 servers beat IPv4 in security -- for now
Credit: Lauren Manning

Security by obscurity is real. Sucuri's CTO found that while IPv4 servers can get compromised in minutes, IPv6 servers are safe from attack because no one is looking for them

Security company Sucuri CTO Daniel Cid recently conducted a small experiment: How long would it take for attackers brute-forcing SSH accounts to compromise IPv4 and IPv6 servers? While the IPv4 servers fell within minutes -- no surprise there -- not a single IPv6 server got hit.

As part of the experiment, Cid configured five IPv4 servers and five IPv6 servers with open SSH ports across two cloud hosting providers, Digital Ocean and Linode. Attackers typically run through a list of common passwords to find the user account using that string, so all the test servers had "password" as the root password.

It didn't take long for the first server to be compromised -- 12 minutes, in fact. It took the attacker only 20 seconds to brute-force the SSH password. The first server to fall was an IPv4 unit, and the remaining four followed suit within minutes of the first. The IPv6 servers, on the other hand, remained intact. After one week, none of them had been scanned, probed, or attacked, much less compromised.

The IPv6 servers didn't benefit from a built-in security feature or an inherent security superiority over the older protocol. The attackers simply didn't find them.

Years after the last IPv4 address blocks were allocated to regional internet registries and the world proclaimed there were no more IPv4 addresses left, IPv6 servers are few and remain relatively obscure. Some criminals may be targeting IPv6 servers, but they are small in number compared to the attack volume against IPv4 systems.

It also helps that the larger address space (2^128 potential addresses to IPv4's 2^32) makes it harder to scan and find potential IPv6 targets. In contrast, it's easy to find scan lists of IPv4 addresses with IP ranges of several well-known hosting providers, through various online sources. These lists provide attackers with a starting point in finding IPv4 servers.

"What we can draw from this is that the obscurity of IPv6 helps to minimize the noise of attacks," Cid said.

As an aside, the attackers who compromised the IPv4 servers didn't waste any time. As soon as they were in, they downloaded three distributed denial-of-service attack scripts -- dos.py, down.pl and viteza.py -- from three Romanian sites and modified init files to load the Linux DDoS toolkit Linux/Xor.DDoS during boot. To make sure they didn't lose control over the machine, the attackers also installed backdoors and set up an hourly cron job to re-enable the malware if it gets removed.

While all five IPv4 servers were injected with the same malware, only one appeared to have been used in an active campaign. Digital Ocean detected one of the servers participating in a massive 800Mbps-plus SYN packet flood against three customers on a Chinese IP address before it disabled networking on the problematic droplet.

"We didn't expect attackers to use it so quickly after the initial compromise," Cid wrote, noting they needed to be more careful with these experiments. Networking should have been disabled as soon as the machines were compromised.

Bottom line, administrators shouldn't underestimate how quickly attackers move. It may be tempting to save time by setting up servers with a weak or default password and plan to change it to a secure password later. But it isn't worth the potential time savings when they can lose control of the box within a 15-minute span. Attackers are clearly still using SSH brute-force attacks, so servers need strong credentials from the start.

Using IPv6 servers keeps the attackers at bay for now, but that doesn't excuse bad habits. Servers should already have strong credentials and configure all the security mechanisms before they are connected online. There is no time for later.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies