Any security concerns?

Technical Support for Routers
1

I am not looking to get slammed by these questions as I just want to get info from those that use these. I already bought a few different GLi models to use as a travel router to connect to my open OpenVpn server. Doing this will add the necessary info to connect to my internal network to the router. I know the firmware is based on OpenWrt but is also customized so just wanted to hear from others if they have any concerns (or tested) on how secure that custom firmware is, from just general vulnerabilities to possibly sending config details to some destination. One thing that concerned my was the DDNS value on the home page of the router config. Not sure how those are determined and added to each router (in checking the files it appears to be a static value on the page - still not sure if it is different for each router and if so how it is valued). I thought even the plain OpenWrt firmware is still not completely stock (not certain). Plus the custom front end does make setting things up easier.

I am not trying to insinuate anything of anyone involved with these products (if anyone takes it that way sorry, just could not find a better way to ask) just trying to hear from those that may have checked the code, ran security tests, etc.

If you want to reply with something like “then do not use them” please refrain as I am truly looking for legitimate answers.

Thanks in advance.

 

3 Likes
2

Hello!

I had the same concern as you initially. So I decided to to a quick TCPDump on every bit of traffic coming out of my MT300A, running a brand new fresh install of the GL-Inet firmware. What I found was to be expected. If your convenience, I uploaded the “glinet.cap” dump file if you want to take a look for yourself in wireshark, this TCPDump was taken from the moment the router booted up until about 5 minutes later.

Link to tcpdump: https://www.jgndata.biz/jgoetz/file2/glinet.cap

(Note for that file, ignore the SSDP packets from 172.16.100.10, that has nothing to do with the GL-Inet router, just something on my LAN unrelated to gl-inet thats being logged in the TCPDump).

If we break down the TCPDump file we can see in detail what the router was doing when connecting to the outside world. First thing it did was make an HTTP connection to gl-inet.com checking for a firmware upgrade. Next, it made an HTTP requests to the IPs 216.146.38.70, which is the site that hosts “checkip.dyndns.org”, a way for the router to find your public IP for GL-Inet’s DYDNS Service (which can be disabled from the /etc/config/glconfig file via SSH)

Next, it makes another connection to 103.17.8.19, which hosts “myip.com.tw”, which much like the checkip.dyndns.org checks for your public IP. I assume the router connects to both services for redundancy if one is down at the moment or something of the like. Logging into the router itself, all this information fits with the scrip that does the dynamic DNS updating, so no funny business is going on there. (If your interested, here it is: https://paste.aseriesoftubez.com/p/1475729211-eNUwP.txt)

Finally, it makes another connection to gl-inet.com, this time with a request for 404 Page not found - GL.iNet and fills in the rest of the URL with the info.
In total the router connected to 3 services, two being the IP checker services and the gl-inet website itself.

Now, I can’t say with 100% certainty that theres nothing nefarious going on, as I haven’t dissected the firmware line by line, but judging by the tcpdump data and my experience with using gl-inet products for the past 6 months, I highly doubt that Alfie and friends are up to anything bad :slight_smile:

Regarding your question about the stock firmware not being truly “stock”, from what we’ve found it is. The only main difference we could find from stock is that the image uses gl-inet.com’s openwrt package mirror. We could technically use the public openwrt mirror, but we have some issues with packages not installing due to kernel dependency errors. So I assume that there are some custom packages built for the device itself that GL-Inet provides via its mirror. But other than that, from all that we’ve seen, the stock images are pretty much stock.

All in all, I’d personally say GL-Inet is very trustworthy and I would be more than happy to trust my OpenVPN config files on them. In fact where I work, we’ve setup at least 40 GL-Inet routers now that power city-wide wifi access :slight_smile:

2 Likes
3

Thanks Justin. You can zip the file in order to upload.

Yes you have checked all our script. From v2.2 you can just disable ddns and all the ip checks will be gone. You can can just disable /usr/lib/ddns/glddnsupdater.sh

The script for firmware update is /usr/bin/glautoupdater, you can delete this file as well. Then, there is really no background connection any more.

So, all script trying to connect outside is in shell scripts.

As the clean firmware, you can compile by yourself. You can just get out patch and patch the code from openwrt.

4

Hi @alzhao I am wondering what is /usr/bin/gl_health running in the background.

What is the function of this program?

Thanks

5

Justin thanks very much for the detailed response and testing. That was what I was looking for.

Alzhao thanks for the details on disabling ddns checks. As for compiling openwrt you mention to get your patch and patch openwrt - what is that patch?

Thanks

6

@heavymetal, it is the daemon used to connect saved repeater stations. It doesn’t send any data outside.

@je66, all the patches to openwrt-cc is here: openwrt-cc/patches at master · domino-team/openwrt-cc · GitHub , you can get this patch and patch your own openwrt cc1505.1. But I am not sure it will be able to patch the latest openwrt-cc, as openwrt cc 1505.1 also has new commit after we pull.

7

 

alzhao wrote:

“Yes you have checked all our script. From v2.2 you can just disable ddns and all the ip checks will be gone. You can can just disable /usr/lib/ddns/glddnsupdater.sh”

“The script for firmware update is /usr/bin/glautoupdater, you can delete this file as well. Then, there is really no background connection any more.”

 

Hi.
Can you kindly implement a check box in your GUI to make this easier? I do not want any “outside” activity / “call-backs” without my express permission.
Also, with the firmware update enabled, does this “call-home” before or after my VPN service kicks in (ie. does the connection go through the VPN or otherwise)?

 

Regards,
Glitch

8

Also, I just found this: /etc/config/mwan3, which appears to have a load of DNS settings, namely Google (arrgghhh, I don’t trust them with anything!) and OpenDNS.
Can someone kindly explain what this file does?

Glitch

9

@Glitch, there is a check box already in recent firmware. You just untick it to disable WAN access and ddns will be disabled.

The call home function goes through VPN, which is not what we wanted. It should not go through VPN. Yet we didn’t implement this.

mwan3 is used for load balancing when you have multiple WAN, e.g. cable, repeater and 4G at the same time. It has to use active ping to determine if one connection is live. The IP of google and OpenDNS is used for ping, not for DNS.

10

@Glitch, the mwan3 is a stock OpenWrt package, which handles multiple Wan connections (redundancy, load balancing, etc.). It checks periodically if the Wan connection is up by pinging some outside services: Google and OpenDNS in my tests. I can see 4 pings every 5 seconds on my network. These pings exist even if you don’t have multiple Wan connections.

I just removed the packages luci-app-mwan3 (which gives the Network => Load balancing page in LuCI web interface) and mwan3 (which contains the /usr/sbin/mwan3track executable). Then you can remove also the /etc/config/mwan3 config file.

From the command line:

opkg remove luci-app-mwan3 mwan3
rm /etc/config/mwan3
2 Likes
11

Please @Alzhao can you give us some more info about the gl_health daemon? I see that it incorporates pieces of other software, like the wpa_cli client, and I don’t understand what are the functions it provides, beyond OpenWrt software.

What if I disable /usr/bin/gl_health altogether?

Is the source code of gl_health available somewhere?

Thank you very much for any hints.

12

I use for private purposes a pair gl-mt300n routers with poe modules at my own risk and knowing that at the start of the firewall it rises in the last stages and before that the router is transparent. You can use dd-wrt on the site written as flash firmware, or clear yourself compiled open-wrt for MTK. In information technology can not be trusted even (especially) very large companies remember the scandals associated with Cisco or Juniper, D-link, the list can continue indefinitely …

13

gl_health is the repeater manager. I only checks your repeater connection. It will auto connect to your saved SSIDs. If none can be connected it will just disable sta. There is no information sent to the Internet during this process.

14

Can’t tell you, because when I plugged it in and NMap’d it, it had Telnet and Samba (smbd/nmbd) ports open. I didn’t have time for a full security audit, but that appeared concerning enough, so I just reflashed it with the latest LEDE and that’s working great.

I have no idea what benefits the factory images has, apart from a more user friendly UI than LUCI (which would be an understandable thing to change from a mass-market vendor perspective).

I still wish LEDE/OpenWRT were based on a more hardened foundation, like Alpine Linux uses (but would need more instruction set and boards support than Alpine offers).

15

LEDE is another fork OpenWRT with very small developer team…
Almost a year from them nothing is audible.

16

@dm What I consider one of the important features of the GLi firmware is the station management tools. this allows one to choose from multiple saved stations and add new stations. There is no easy way to do this in OpenWrt\LEDE (Luci is NOT easy or fast). The GUI is also usable on a phone and the OpenWrt\LEDE gui is not.

As a road warrior I consider this tool set a must. I have tried a number of other tools and this is the easiest to use.

I also like the included USB support.

I have taken the steps to disable the DDNS server described here and in other posts, but otherwise comfortable that the device is secure.

17

@passter, What do you mean nothing is audible from LEDE? It’s an enormous number of improvements on OpenWRT and vastly more secure. The good news, is that they’re in discussions to merge again.

LEDE 17.01.0 – First Stable Release – February 2017

 _________
/ /\ _ ___ ___ ___
/ LE / \ | | | __| \| __|
/ DE / \ | |__| _|| |) | _|
/________/ LE \ |____|___|___/|___| lede-project.org
\ \ DE /
\ LE \ / ———————————————————–
\ DE \ / Reboot (17.01.0, r3205-59508e3)
\________\/ ———————————————————–
The LEDE Project (“Linux Embedded Development Environment”) is a Linux operating system emerged from the OpenWrtproject. It is a complete replacement for the vendor-supplied firmware of a wide range of wireless routers and non-network devices. See the Table of Hardware for supported devices. For more information about LEDE Project organization, see the About LEDE pages.

Get LEDE Firmware at: Index of /releases/

Highlights In LEDE 17.01.0

The LEDE Community is proud to announce the first stable release of the LEDE 17.01 version series. It incorporates thousands of commits over the last nine months of effort. With this release, the LEDE development team closes out an intense effort to modernize many parts of OpenWrt and incorporate many new modules, packages, and technologies. These are some of the highlights compared to OpenWrt Chaos Calmer:

  • Linux kernel updated to version 4.4.50 (from 3.18 in Chaos Calmer)
  • Update of essential software:
    • dnsmasq updated to 2.76 (from 2.73 in Chaos Calmer)
    • busybox updated to 1.25.1 (from 1.23.2 in Chaos Calmer)
    • mbedtls version 2.4.0 (updated from polarssl 1.3.14 in Chaos Calmer)
    • openssl updated to 1.0.2k
    • Improved Security Features
      • Use SHA256 instead of MD5 to validate source code for upstream packages
      • mbedtls: disable SSLv3 support
      • OpenSSL: disable support for compression, heartbeats, NPN, Whirlpool, and J-PAKE
      • Memory Corruption Mitigation Methods
        • gcc -Wformat -Wformat-security
        • User space Stack-Smashing Protection (Regular)
        • Kernel space Stack-Smashing Protection (Regular)
        • buffer-overflows detection (FORTIFY_SOURCE) (Conservative)
        • RELRO protection (Full)
        • Improved Networking Support
          • Smart Queue Management (SQM) minimizes bufferbloat by using the cake and fq_codel qdisc’s. More…
          • Improvements to the WiFi stack eliminating bufferbloat on ath9k, mt76 and some ath10k chipsets
          • Airtime fairness scheduler for ath9k to prevent slow stations from hogging too much airtime
          • Various stability and regression fixes to the Linux wireless stack and ath9k in particular
          • Provide alternative Candela-Tech ath10k-ct driver
          • IPv6 hardening
          • Updated toolchain
            • musl 1.1.16
            • gcc 5.4.0
            • binutils 2.25.1
            • Platform and Driver Support
              • Lantiq
                • Added redistributable DSL firmware
                • Updated DSL phy drivers
                • Added new targets:
                  • apm821xx (AppliedMicro APM821xx)
                  • arc770 (Synopsys DesignWare ARC 770D)
                  • archs38 (Synopsys DesignWare ARC HS38)
                  • armvirt (QEMU ARM Virtual Machine)
                  • ipq806x (Qualcomm Atheros IPQ806X)
                  • layerscape (NXP Layerscape)
                  • zynq (Xilinx Zynq 7000 SoCs)
                  • Reorganized x86 target:
                    • Drop dedicated Xen DomU target, merged with x86/generic
                    • Enable AES-NI support
                    • Removed targets:
                      • realview, replaced by armvirt
                      • ppc44x, disabled due to code brokeness
                      • netlogic, dropped due to no available hardware
                      • Build system improvements
                        • Separation of base system and community feeds to simplify distribution of binary package updates
                        • Fixes and enhancements in package dependency handling, better support for virtual provides
                        • Per-device rootfs images to better tune package selection to each individual device profile
                        • New image build code improving compilation times and simplifying device profile declarations
                        • New package/…/check make target to run a series of standard diagnostics on Makefiles
                        • Support for fetching sources using Curl
                        • Generate reproducible source tarballs when packing SCM checkouts
                        • Image Builder / SDK
                          • Rework library bundling to allow for better portability between different Linux distributions
                          • Add support for building kernel modules using the SDK
                          • Added support for a many new routers and boards
                            As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters.

                            Have fun!

                            The LEDE Community

18

Well that copy-paste went terribly… Looked great in WYSINWYG. :slight_smile:

19

@RangerZ, How does the station management compare to TravelMate on LEDE/OpenWRT? (Sorry, I didn’t get to try it.)

Yeah, LUCI isn’t great for newcomers. Haven’t tried the newer alpha Luci2 version.

I hope you’re able to maintain security well. Don’t take my switch personally, it’s just that without knowing you, I have more existing trust in larger upstream distribution communities to be able to continue releasing security fixes on time. I have no reason or knowledge to believe you can’t personally, it’s just been my experience with the vast majority of device vendors, that it’s been easier to go upstream for me. (Plus I want newer kernel features, etc)

20

I’d much rather see any software improvements (like station management) upstreamed, or made available as optional packages.

I wouldn’t see firmware as a significant competitive market differentiator. Most vendors seem to think it is.

The major reason I just bought my first GLi, was the great hardware. Particularly, compatible hardware and the ability to flash LEDE on it. The hardware’s been FANTASTIC too! This is DEFINITELY not my last GLi purchase.

I’m currently doing another postgrad, Masters in Cybersecurity. Just completed a “Wireless, Mobile and IoT Security” unit, with a strong focus on Wi-Fi. It’s been great to be able to install the full “wpad” (not mini), FreeRadius v3, SSL libraries etc on such a portable device and configure WPA2 Enterprise EAP-TLS/TTLS (for strong mutual certificate authentication). Although not strictly necessary, I’ve added a second radio for performance when as a bridge (TL-WN722N via USB). With VPN added (WireGuard), I’ll be able to can securely connect to the GLi, then have traffic over untrusted networks (whether it’s hotel Wi-Fi, ethernet WANs, etc) protected to an upstream (e.g. my own cloud-hosted VPN server, regularly rotated). Router admin UI, captive portal authentication and the VPN protected networks, all on separated onto different Wi-Fi SSIDs (Admin UI not available during regular browsing) and each SSID only accessed from dedicated hosts (e.g. for captive portal auth, a disposable VMs).

I recommended GLi hardware to others in the course too. It’s fantastic to be able to buy cheap enough that even if I somehow managed to brick it, it wouldn’t be a catastrophic financial disaster.

I guess the other reason I like community builds, is that too many vendors stop releasing updates after a year or so. They’ve moved on to new models and can’t afford to support lots of older ones. Meanwhile, the devices either become botnet members, or have to end up as landfill. I hope you’re not one of those vendors, but understand it’s tough for them. Anyway, long-term availability is another reason I usually go for community builds when I can.