The D-Link DIR860L router -- how secure can it get?

The 860L does not log anything about changes made to the router configuration. It also does not track logons at all, either successful ones or failed attempts. However, if you are using the web interface and it times out on you, that gets logged. Go figure. 

When a new device associates with the 860L the MAC address of the device is logged. This can be helpful in verifying that neighbors are not getting in to your network. 

To me, one of the most important events to record, are unsolicited incoming connection attempts. If you see computers from another country trying to access certain ports on your router, you can research what the ports are used for, try to close or stealth them, or maybe forward them to a non-existing local IP address. If nothing else, it helps to illustrate the importance of router security. The 860L does not log unsolicited incoming connections. 

If the logs get full, the documentation says that it continues writing to the logs, losing the oldest information. I did not test this. 

Speaking of documentation, there is none at all for the messages in the log. Some were self-explanatory but many were not. D-Link customers have to figure out the meaning of messages like the one below on their own.

ATT:001[SYN-ACK][74.125.141.95][WAN-1]

The logs are wiped clean when the device powers off.

The 860L can send an email message when a log fills up, but that seems to be the only error condition it is capable of emailing about.

I ran a regular NMAP scan (format: nmap 1.2.3.4) from the WAN side of the router to see what the 860L would log. In response to a thousand ports being scanned, four identical messages were written to the log. Each warned of SYN-FLOODING and included the source IP address. I also ran the same regular NMAP scan from the LAN side and again the 860L warned four times about SYN-FLOODING.

I also tested the firewall by scanning all 65,000 odd TCP ports from the WAN (Internet) side of the router, again with NMAP. As you would hope, there were no open ports.

There were, however, some firewall related options that I, frankly, do not understand: Anti-Spoof Checking, NAT Endpoint Filtering and SPI.

The only explanation for the Anti-Spoof Checking option is that it protects "your network from certain kinds of "spoofing". It was off by default.

Likewise the "Enable SPI" option was also off by default. SPI is "stateful packet inspection" and, according to D-Link it is also known as "dynamic packet filtering". They say it "helps to prevent cyber attacks by tracking more state per session. It validates that the traffic passing through that session conforms to the protocol". The extra state data that's tracked, and the protocol that packets are supposed to conform with, is a mystery. There are many protocols on the Internet.

I am reasonably familiar with networking, but I have never seen an option like NAT Endpoint Filtering. The router offers three modes of operation, and TCP and UDP are configured independently. The modes are:

• Endpoint Independent - Any incoming traffic sent to an open port will be forwarded to the application that opened the port. The port will close if idle for 5 minutes.
• Address Restricted - Incoming traffic must match the IP address of the outgoing connection.
• Port and Address Restricted - Incoming traffic must match the IP address and port of the outgoing connection.

As far as I knew, all routers operated in the last mode. If anyone reading this understands why the other two modes exist, please let me know. My guess is that the first one has to do with UPnP applications opening ports.

I also scanned the router from the LAN side with NMAP.

As expected port 80 was open; as noted earlier, local access to the router can not be restricted to HTTPS. Port 443 was also open as local HTTPS access can not be assigned to an alternate port. Port 49152, used for UPnP was open, but as soon as I disabled UPnP, the port was closed.

TCP Port 53, used for DNS, was open which was a surprise. For one thing, I thought DNS used UDP rather than TCP. Also, my main router processes DNS without TCP port 53 being open on the LAN side. I checked some other routers and found one Asus model with the port open on the LAN side and one without. A Ubiquity router also had it open.

Most interesting however, was that NMAP reported the software listening on port 53 was dnsmasq 2.45. Version 2.45 of dnsmasq is ancient, it was released back in July 2008.

As noted earlier, the last firmware for the 860L was released in March 2014. At the time, dnsmasq was at version 2.68. The updates that D-Link failed to include in their firmware were versions 2.46, 2.47, 2.48, 2.49, 2.50, 2.51, 2.52, 2.53, 2.54, 2.55, 2.56, 2.57, 2.58, 2.59, 2.60, 2.61, 2.62, 2.63, 2.64, 2.65, 2.66, 2.67 and 2.68.

Dnsmasq is actively maintained, it is currently at version 2.75 which means that the 860L is 30 releases behind. Needless to say, version 2.45 contains known bugs.

The two final TCP ports open on the LAN side of the router were 139 and 445, both used for Windows file sharing. They were open despite the Web File Access feature being disabled. My guess is that these ports are open to allow sharing files on a USB flash drive plugged into the router. There is no option to disable this type of file sharing. 

Speaking of sharing files plugged in to the USB port of a router, D-Link was among the companies that SEC Consult found were vulnerable to the NetUSB flaw. The disclosure of the flaw was more than a year after the last firmware release for the 860L. However, my scans did not find port 20005 open on either the LAN or WAN sides, so the 860L should not be vulnerable (I blogged about NetUSB back in June).

Working with the web interface of the router had its ups and downs. On the one hand, the security is enhanced by a timeout feature - after a period of inactivity the router logs you off. On the other hand, there is no control over the timeout interval and it seems to be pretty short. I was constantly logged out. But, the interface was zippy and few changes required a reboot.

I did not test the mydlink cloud service. Many router companies offer a cloud service, but for security reasons, I prefer to avoid them. I also did not try any of the three D-Link smartphone apps (Quick Router Setup, mydlink SharePort and mydlink Lite).

One way to test the security personality of a router company is how they dealt with the Misfortune Cookie flaw that Check Point revealed back in December 2014. The flaw affected an estimated 12 million routers and there is no reliable test of whether any particular router is vulnerable or not.

Some vendors (Peplink, ActionTec) issued statements that their routers were not vulnerable. ZyXEL updated the firmware on their current models, but not on older ones. Then, there were the companies that hid their heads in the sand and said nothing.

Not sure where D-Link stood, I went to the tech support section of dlink.com and searched for "misfortune". Nothing. The Security Advisories section of the site accepts bug reports, rather than list previously issued advisories. There are no press releases and the forum devoted to firmware has nothing about the 860L. In fact, the last posting of any type on the firmware forum was five months ago.

Clearly D-Link has sand in their hair, even though Check Point specifically mentioned that some of their routers are vulnerable.

Which brings me to my soapbox, that consumer routers are best avoided.

As we saw here, support for bug fixes is very short lived. The last firmware update for the 860L was about a year after it hit the market. Business class routers should be supported for a much longer time. That has been my experience with Peplink, my preferred router manufacturer. 

The 860L illustrated another big problem with consumer routers - the inclusion of old buggy software. That its running software from 2008, that is 30 releases behind the times, did not surprise me. In the case of the Misfortune Cookie, millions of routers were found in 2014 to be running web server software containing a bug that had been fixed in 2005.

Finally, a word about this blog.

A router review focused on security, may well be a first. Time will tell if this starts a trend or ends up as a Unicorn. To illustrate how different this approach is, see the September 2013 SmallNetBuilder review of the same router. SmallNetBuilder is an excellent website, but it's like we're not speaking the same language.

- - - - - - - - 

Update: November 21, 2015. The newer version of the DIR-860L, hardware version B, had updated firmware released in 2015 (not sure if it was April or October) that fixed a security flaw involving HNAP Privilege Escalation. So, the router reviewed here, no doubt, is vulnerable to this HNAP flaw.