@yuxin.zou and @alzhao please check.
If I just use this google dork I will be able to find a lot of DDNS open to WAN routers!
inurl:glddns.com -inurl:www
You should add something to stop google and other bots to index such pages (like ban by location or maybe user agent)!
That's not "extremely" nor "urgent". People using DDNS and providing services must know that they need to invest in security. You can't ban Google because those pages are not served by the router itself.
Everyone using DDNS and opening WAN ports must think about it before.
So not GL fault here.
well they could have used a robots.txt to show google its not allowed to crawl.
But the problem is it is already crawled, that is harder to get rid off.
Though theres many spiders who still crawl without respecting robots.txt so its not water proof.
robots.txt are just cosmetics. They are no protection at all. You can always use shodan.io to search for open ports, websites or favicons.
Running a router needs knowledge. Even if people don't think about it.
So it would be even better to hide those "advanced" (lol) features and provide a simple vs. advanced GL GUI.
Tbh i find the wan access feature strange, also because so many make the mistake.
It makes more sense if they made some type of template system, it makes it more beginner friendly.
It can be mitigated by:
And they have Goodcloud. I vote for WAN access total removal.
If you don’t want to use Goodcloud, you can use WireGuard launched on router, else use goodcloud, another way is for advanced geeks to enable access via SSH.
P.S: SSH WAN access should also be removed
None of these will protect against something like Shodan.
Google dorks are nice but nothing a "hacker" would search for.
In this case only whitelists or total feature removal as I mentioned above
Or just don't enable it. Easy. 
For me it is easy to even use SSH. But I posted this to help to protect regular people. Not many people like me are security geeks
Yeah, might be. But what do you expect now? Removing a feature because people are too uneducated to use it? Sounds not like a plan for me.
A big warning would be fine, but the feature should stay because you need it from time to time.
Plus at least second password or automatic disable after some period of time. And block user agents not from browsers to remove them at least from google
At the end GL must decide this. But as I said before: Being uneducated isn't an excuse for doing stupid things. So people need to understand what they are doing instead of just flipping switches and pressing buttons.
luci is a 3rd party plugin and OpenWrt already decided that they will not protect it because it should not be exposed to the internet. Yep, that's what they said.
Accessing the router using WAN is helpful in any kind of situation where your WAN port isn't the internet but an upper network.
Besides this: Every "protection" you mention will not help against people using port forwards. I found several "services" behind GLDDNS addresses. But for all of them it's the same: You can't blame the router because the router does not even receive the HTTP/S request...
A robots.txt is a file on a http service. But the DDNS service is registering the Domain Name as pointer to a changing dynamic IP... No http involved at all.
If someone exposes a http server to the internet, this person should know this and configure the http service.
You all demand, GL.iNet should open a http service, when DDNS is activated to provide a robots.txt.
But most users want to have a VPN endpoint, not a public http service.
I am not a security guru, but in my observation any httpd (nginx, Apache, lighthttpd, IIS, ...) is more vulnerable than no active service.
(To be fair: Not all, I think @admon got this point already)
Actually i just checked ddns.net its exactly the same so its normal, but im not worried because most of the ports are shielded by the wireguard server where i do internal portforwarding from.
my only concern was if it was not a misconfiguration by OP and the feature did something extra, but luckily thats not the case.
What does this even mean?
DDNS is not open. It is a translator from domain name to IP. There is nothing open.
If a port on the WAN router is open and a vulnerable service is listening behind, this is not a DDNS issue.
And even if, how would you compensate the downside? Without DDNS you need another (more secure?) solution for all the users that want to reach their home VPN.
I really want to keep it short. But this is so not a security topic.
Shortest: A GL-iNet router does not expose ports to the WAN by default.
If someone opens a port, because this one is smart enough to fit the related page in the docs, it can compromise the LAN integrity, even without DDNS... So they should deactivate this feature, too?
Read my post again. Routers open to WAN VIA DDNS
The issue is about to be indexed by search engines (ex google).
Not remove DDNS! Remove ability to access SSH and web panel via DDNS (from WAN). If user needs to access them he can first configure DDNS based Wireguard server on router and using it access SSH or web panel
I meant remove option to access SSH and web panel directly from WAN
The post NOT about DDNS!
Post about routers being available (SSH and web page) to access from WAN via DDNS and being indexed by search engines
Think again ... Routers are reachable via DDNS. Routers are not open via DDNS. This is a false statement.
For me it is new that Google is indexing ssh ... But I am not an expert on googling.
In that case you should change the topic ... The first word could be misleading.
No need to be an expert here because the statement of @sec_guru is simply wrong (or at least not totally correct). They are reachable via DDNS, but this is because... well... that's how DDNS works. It won't cause the router to publish ports; the user does.
No. Just don't enable it, and everyone is happy.
We are talking about a router based on OpenWrt which indicated that the people need to have more knowledge than the people just using ISPs default routers. If they don't have, it's a pitty, but don't blame the router for it.
In default SSH and HTTPS on WAN is blocked.
We will check if all of these things. Must have some room to improve.
These are not promised or it is slow to do.
Now pls simply disable WAN access. Use a wireguard to connect to your network.