Router Security Test Your Router Website by     
Michael Horowitz 
Home Site Index Bugs News Security Checklist Tests DNS Resources Stats Search Popular Pages
Also see my Defensive Computing Checklist website
 
Table of Contents
DNS Server TestsFirewall Testers
TCP Ports to TestUDP Ports to Test
UPnP TestersLAN side port testing
HNAP TestingURLs to try from your LAN
TCP/IP Port Information  Modem Tests
IP Version 6 TestersAndroid apps
WebRTCAds

DNS Server Tests  top

The topic of Testing Your DNS Servers has been moved to a new page. It explains DNS and lists multiple websites that report on the currently in effect DNS server(s). It is never obvious, yet it is critically important, to know whose DNS servers you are using.

Firewall Testers  top

Level setting: Every computing device on the Internet is assigned a number. Some have two numbers. The numbers are known as IP addresses. Most also have names. The computer where this website resides goes by the name www.RouterSecurity.org and the IP address 216.92.136.14. The firewall tests below communicate with what they see as your public IP address. Usually, this IP address belongs to the router your computing device (tablet, phone, computer) is connected to. All devices connected to the same router have the same public IP address.

There are, however, three instances where the firewall tests are not communicating with your router. If you are connected to a VPN, the public sees the VPN server, rather than your router. Likewise, with Tor you end up testing the Tor exit node rather than your router. The third case involves the box your router is directly connected to. If it is just a modem, all is well. However, if it is a gateway device (combination modem, router and perhaps even a telephone adapter) from your ISP, then the device visible to the outside world may be the gateway rather than your router. For your router to be your public face on the Internet, the gateway needs to be put in Bridge mode. This dumbs it down to function only as a modem.

Port Status: An "open" port responds to unsolicited incoming requests. A "closed" port (a.k.a. "refused" in Nmap lingo) is accessible, but there is no application listening on it. A status of "stealth" (a.k.a. "filtered" to Nmap) means data sent to the port generates no response at all. This is the most secure status.

TCP Ports to Test  top

Note that while connected to a VPN, these tests test the VPN server, not your router. Same for Tor. An "open" port responds to unsolicited incoming requests. A "closed" port (a.k.a. "refused" in Nmap lingo) is accessible, but there is no application listening on it. A status of "stealth" (a.k.a. "filtered" to Nmap) means data sent to the port generates no response at all. This is the most secure status. This list is extremely incomplete.

UDP Ports to Test  top

Note that this list is quite incomplete.

UDP Port testers

The links above, that test individual UDP ports, look like this
www.speedguide.net/ portscan.php?udp=1&port=999
This example would test port 999 (ignore the space in the URL). SpeedGuide can also test individual ports at their Security Scan page where you can enter any port number and chose to test UDP and/or TCP.

Another website offering UDP port tests is the UDP Port Scan with Nmap page at PentTest-Tools.com. It can test a range of UDP ports, a list of UDP ports or individual ports.

Yet another site is the UDP Port Scanner at ipvoid.com. It can scan any public IP address but you need to solve a CAPTCH for each request. If you opt for Common Ports it scans: 53, 68, 69, 123, 137, 161, 389, 636, 1900, 5353 and 11211. It uses nmap terminology.

UPnP Testers  (Major revisions: Nov 30, 2018)   top

There are two core security problems with UPnP: what it does on the LAN, by design, and keeping it off the Internet.

On the LAN side, UPnP is dangerous because it lets computing devices (typically IoT devices) punch a hole in the routers firewall. This exposes devices to the Internet where their poor security, such as default passwords, can be abused. LAN side devices can do much more, in terms of configuring the router they sit behind, but puncturing the firewall is the classic issue.

UPnP on the WAN/Internet side of a router is a totally different problem. UPnP was never meant to be exposed on the Internet. The protocol has no security at all. No passwords, no encryption, no identity verification, nothing. It was designed to be used between trusted devices. Back in January 2013, Rapid7 found over 80 million devices exposing UPnP on the Internet. There should have been none. I blogged about it at the time: Check your router now, before Lex Luthor does.

And, many of those 80 millions devices were running UPnP software that was buggy to boot. You can't make this stuff up.

So, just disable UPnP? Not so fast. While it is certainly safer to disable UPnP, it may not be a perfect solution. For one thing, there is a chance a router may only disable UPnP on the LAN side, since it was never supposed to be exposed to the Internet in the first place. Then too, routers have their bugs, and disabling UPnP may well do nothing at all. Back in 2013, when Steve Gibson created his UPnP test (see below) he found examples of both issues, saying: "We have confirmed that there are some routers that leave it on outside, even if it's off inside, and some that don't actually turn it off inside." Clearly, we need to test for UPnP.

UPnP is relatively hard to test for as there are two components to the protocol. The first component lets a UPnP enabled device discover other UPnP enabled devices. The second is the ongoing conversation between UPnP enabled devices. The initial discovery of UPnP-enabled devices is done with the Simple Service Discovery Protocol (SSDP) which listens on UDP port 1900. The actual communication between UPnP devices is done via HTTP on varying TCP ports. Initially, SSDP tells clients which TCP port to use for the subsequent HTTP conversations. According to Rapid7, the HTTP TCP port number varies by vendor and is often chosen at random. Ugh. As for non-random ports, they say that some Broadcom, D-Link and TP-Link routers use TCP port 5431, some devices use port 80 and still others use 2869.

In April 2018 Akamai found over 4.8 million devices were vulnerable to UDP SSDP (the UDP portion of UPnP) inquiries. Of those, roughly 765,000 also exposed their vulnerable TCP implementations.

ONLINE UPnP TESTERS

I am still looking for a LAN side UPnP tester. One possibility is Universal Plug-and-Play Tester for Windows by Noël Danjou.

DISCONTINUED: Rapid7 used to offer an online UPnP Check but they discontinued it. Rapid7 also discontinued their installable ScanNow program that scanned a LAN for UPnP enabled devices and reported if the devices were running buggy versions of UPnP software. This was useful to insure that your router was also not responding to UPnP on the LAN side. The program only ran on Windows and required 32 bit versions of either Java 6 or Java 7. As for why they abandoned ScanNow see ScanNow DLL Search Order Hijacking Vulnerability and Deprecation.

LAN side port testing  top

TELNET: Individual LAN side ports can be tested from a computer on the LAN with Telnet. Windows users will have to first install the Telnet client using: Control Panel -> Programs and Features -> click on "Turn Windows features on or off" in the left side column -> Turn on the checkbox for Telnet Client -> Click OK. On OS X ....

To use telnet on Windows, open a Command Prompt window, type "telnet ipaddress portnumber". For example: "telnet 192.168.1.1 80". There needs to be a space on both sides of the IP address. If the port is closed, Windows will complain that it "could not open connection to the host on port 80: connect failed". If the port is open, the responses vary, you may just see a blank screen. You can also telnet to a computer by name, such as "telnet somewhere.com 8080"

From Synology: How do I know if a TCP port is open or closed?. The article explains, with pictures, how test test ports from Windows, Linux (both with Telnet) and a Mac computer before macOS 11 Big Sur. Typical of Synology there is no date on the article.

ID Serve: ID Serve is a small, portable, Internet Server Identification Utility for Windows, created by Steve Gibson. It was written in 2003 and has not been updated since. The initial screen explains its purpose, the Server Query tab is where it does its work. You can query a computer by name (www.amazon.com) or by IP address. It defaults to port 80, but you can force a different port by adding a colon and the port number after the computer name or IP address (no spaces). If data comes back from the query, ID Serve displays it all. This data may identify the server software. If data does not come back, the message, in my experience, will either be "The port is closed, so our connection attempt was refused" or "No response was received from the machine and port at that IP. The machine may be offline or the connection port may be stealthed". ID Serve is limited to TCP (no UDP) and does not support HTTPS.

ClientTest: ClientTest is another small, portable Windows program. It is from Joe of joeware.net and was last updated in 2005. You point it at the IP address of your router, specify a port number and try to connect.

BROWSER: You can also test a port with a web browser. For example, http://192.168.1.1:999 would test TCP port 999 (of course, modify the IP address as necessary for your router). I don't think a browser can test a UDP port, it is limited to TCP.

NMAP: This command tests UDP ports 11 through 13 on the device at IP address 1.2.3.4
  nmap -sU -p 11-13 1.2.3.4

TCP/IP Port Information  top

HNAP Testing  top

The Home Network Administration Protocol is a network device management protocol dating back to 2007. There are four problems with HNAP. One, is that it has a long history of buggy implementations. It can also tell bad guys technical details of a router making it easier for them to find an appropriate vulnerability to attack. The fact that a router supports HNAP may not be visible in its administrative interface. Worst of all, HNAP often can not be disabled. Four strikes, you're out.

You can test if a router supports HNAP by typing

  http://1.2.3.4/HNAP1/

where 1.2.3.4 is the IP address of your router. Of course, every router has two IP addresses one on the public side and one on the private side. I suggest testing for HNAP on each.

You can learn your public IP address at many websites, such as ipchicken.com and checkip.dyndns.com. For the LAN side of a router, see my Sept. 2013 blog Find the IP address of your home router.

If HNAP is enabled, this test displays basic device information about your router in an XML file. See sample output. If it fails, there will be some type of error about the web page not being able to be displayed, perhaps a 404 Not Found error.

If HNAP is enabled, try to turn it off in the router administrative interface and then test again. You may not be able to turn it off. For more, see the HNAP page.

October 26, 2018: Multiple bugs in Linksys E-Series routers were revealed by Talos in October 2018. What was not revealed was a simple way for Linksys owners to check if their routers were vulnerable. According to Jared Rittle, who found the flaws, HNAP can help. Owners can navigate to the official HNAP URL (http://1.2.3.4/HNAP1/) to see the currently installed firmware version (1.2.3.4 is the LAN side IP address of the router). This has the advantage of not needing to know the router password. For the E1200, if the firmware is at or below version 2.0.09, the router is vulnerable. For the E2500, if the firmware is at or below version 3.0.04, it is vulnerable. Owners of other E Series Linksys routers are on their own.

URLs to try from your LAN  top

In these examples, 1.2.3.4 represents the LAN side IP address of the router.

In June 2020 we learned that 79 different Netgear devices shared the same flaw. A bad guy can learn the exact model and firmware of a Netgear router using a URL like
   http://1.2.3.4/currentsetting.htm
and customize an exploit specifically for that router. If you have a Netgear router, try this URL. If it returns information about your router, look for the most recent firmware. Hopefully, it will have been released after June 2020. At the time when the flaw was made public (June 15, 2020) Netgear had done nothing regarding a fix.

In October 2019 we learned of 10 D-Link routers with critical flaws that will not be fixed. If you have any of these D-Link routers, don't bother testing, just get a new router: DIR-655, DIR-866L, DIR-652, DHP-1565, DIR-855L, DAP-1533, DIR-862L, DIR-615, DIR-835 and the DIR-825. For confirmation, CERT has a Proof of Concept web page that will disconnect a vulnerable D-Link router from the Internet for a minute.

In January 2019 we learned of two information disclosure bugs in some Cisco routers. More details are on the Bugs page. If the URL below shows details about your Cisco router, that is bad. A public/WAN side version of this is auto-generated on the Shodan page.
   http://1.2.3.4/cgi-in/config.exp
   http://1.2.3.4/cgi-bin/export_debug_msg.exp

As per Scott Helme's 2014 description of his BrightBox router, try the URL below, where 1.2.3.4 is the IP address of your router. A good result returns nothing but an error message. Here is a sample of a bad result.
   http://1.2.3.4/cgi/ cgi_status.js

In December 2016, Pedro Ribeiro reported on flaws in the Netgear WNR2000 router. If you own a Netgear router, it can't hurt to check for information leakage with the URL below. It may leak the device serial number.
   http://1.2.3.4/ BRS_netgear_success.html

Many Netgear routers had a security flaw in December 2016 (see here and here for more). The command below tests a Netgear router. If this results in a web page with the word "Vulnerable", then the router is vulnerable. Netgear has issued fixes for all vulnerable routers.
  http://www.routerlogin.net /cgi-bin/;echo$IFS'Vulnerable'

This issue with port 32764 is explained above in the TCP Ports to Test section.
   http://1.2.3.4:32764

In September 2017, security firm Embedi found port 19541 open on many D-Link routers. It responds to commands such as one to reboot the router. They did not find any way to close the port. The default IP address is 192.168.0.1 but the router may also respond to dlinkrouter.local.
   http://1.2.3.4:19541

If there is a video surveillance system on your LAN, then hopefully it was not made by Xiongmai. In October 2018, SEC Consult published a big expose about the many ways these systems are not secure. The number of security flaws is huge. These devices are re-branded by at least 100 other companies, so to detect a Xiongmai system, they suggest viewing this page from the LAN
  http://[cameraipaddress] /err.htm
If the page exists and it refers to 'Xiongmai' at all, then read the article by SEC Consult. They also offer other suggestions for identifying Xiongmai hardware. SEC Consult feels that the security is so bad it can not be fixed and that the hardware should be discarded.

Modem Tests  top

A modem is a computer and it too, can have bugs. Chances are the modem as an IP address such as 192.168.100.1. If nothing else, you should try to access the modem by its IP address so that technical information about your Internet connection is available to you. Also, you want to see what information is available without a password, some modems expose too much. If there is a password, then change it from the default.

As per ARRIS Cable Modem has a Backdoor in the Backdoor try to view the page below. An error viewing the page is the good result. See a video of this hack.
http://192.168.100.1/cgi-bin/tech_support_cgi

As per ARRIS DG860A NVRAM Backup Password Disclosure you should try to view the URL below. Again, an error is the good result.
http://192.168.0.1/ router.data

For better security, a router may be able to block access to the modem by blocking its IP address. I blogged about modem access from the LAN side of a router in February 2015. While it can be helpful to directly access the modem, it can also be dangerous. See Talk to your modem and Using a router to block a modem. Some routers can do this, some can not. Dumbed down routers, such as the consumer mesh systems (eero, Google Wifi, Ubiquiti AmpliFi, etc) can not do this.

A great way to see if a modem is accessible from the LAN side is to ping it using the command below. Hopefully, the command fails.
ping 192.168.100.1
If it is pingable, then test Telnet access to the modem with the command below. Failure is the secure outcome.
telnet 192.168.100.1
An other good test is nmap. The simplest command is
nmap 192.168.100.1
For a much more comprehensive look at the LAN side of the modem use the below:
nmap -v -A -p 1-65535 192.168.100.1

IP Version 6 Testers  top

I know of no reason for IPv6 to be enabled on a home router. If it is enabled on yours, try to disable it then verify that it's really off. All the sites below are only available via HTTP.

Android Apps  top

WebRTC  top

Technically, WebRTC is not a router thing, it is a web browser thing. This section is here just for the heck of it. Anyone using a VPN needs to run these tests. WebRTC can expose your public IP address which is normally hidden by the VPN. If you use more than one browser, you need to run these WebRTC tests on each one.

Ads  top

Some routers have been hacked to generate income from showing ads. This website has no ads. If you see any ads while viewing this web page, then something has been hacked. Perhaps your router, perhaps your computer, perhaps your web bowser.

If you are trying to block ads and trackers, then Eduard Ursu has an adblock tester page at d3ward.github.io/toolz/adblock.html.


Honorable mention goes to the Shadowserver Foundation that scans the Internet for all sorts of things that should not be there.
See The scannings will continue until the Internet improves.

Top 
Page Created: December 5, 2015      
Last Updated: April 10, 2024 2PM CT
Viewed 1,709,307 times
(522/day over 3,274 days)     
Website by Michael Horowitz      
Feedback: routers __at__ michaelhorowitz dot com  
Changelog
Copyright 2015 - 2024