Hi, I am looking for topics around security hardening in the forum but not able to find any substantial info, so if anyone’s interested, I can put them in this post as a checklist with tutorials? Anything anyone needs assistance with?
There is not really alot you can secure, when you mean from wan to inbound.
OpenWrt is already secure by their default rules, you may want to disable icmp, but some isps require ping, and icmp is also needed for ipv6, you can look to these rules in luci under the traffic rules tab in firewall.
If it is device specific, my take on this is to look and categorize device categorys, pcs will have their own network, but the television is on the network only for tv and isp tv box, iot for iot.
If there is a compromise going on from tv or iot it will not reach your computers, with network firewall zone isolation you could potentionally isolate network worms.
You can also make one zone only be able to communicate to a other zone, but let the other zone not communicate first.
What I don't recommend:
DMZ:
DMZ can be usefull it has smilarities with bridge mode, but never do this when the router itself is the direct isp router, this means the dmz device has no firewall protection and gets fully exposed to the internet.
Port forwarding:
I won't recommend forwarding from wan, even for games unpnp or forwarding is 70% times not necessary, most games use port hole punching, which essentially mean: anything your router sent is for the other side allowed to respond back on the same line, so often games use a hub to connect players in where the line between you and hub becomes expanded to other players on this exact line.
^ also in alot of situations open ports expose danger for ddos or other attacks, my advise is to port forward over wireguard server, simply because wireguard does not respond and because it uses udp the port is invisible for most port scanners.
What do you mean by zone?
The firewall zones which you can find in luci.
I tend to feel that the a big risk with GL.INET firmware is security softening.
I think it can be tempting to try many of the features on offer, for example GoodCloud feels like an attack vector I would not want to expose. Likewise, beta features like Tailscale (I would like to use Tailscale but not the beta implementation currently available to me in the router - and it is known to have gaps in it’s killswitch) and AstroWeb and possibly DPI (although I suspect that is less of a potential attack vector but not sure, and its potential to mitigate other threats leaves me on the fence).
Coming from pfSense, gl.inet it feels a bit like the wild west and I am feeling a bit naked metaphorically speaking. Out of date kernels, proprietary code, beta features in stable FW etc. I have to be honest I feel a little unnerved to the point I am considering going back to my happy place of pfSense. It also feels like a bit of a gamble taking the latest stable firmware, sure, you need to plug newly uncovered vulnerabilities ASAP, but it feels like new stable firmware isn’t always as stable as one might like it to be so holding off until others have kicked the tyres feels the better option.
Other than that, I do agree with the above about segmenting IoT and TV devices from other stuff. Low rent IoT devices with minimal updates feel like the sort of thing I don’t want mixing with anything else. I’m kind of lucky as my IoT foot print is actually very small anyway.
This is true, you have to trust GL-iNet if they keep the software safe by backporting, but there is no true visibility.
However from my own experience I know that GL-iNet atleast tries to listen, some other vendors with closed firmware pretty much neglect their routers, I know that Asus was caught as well into that.
However if that is a issue, I would go to use OpenWrt vanilla.
On my own Flint 2 I even build my own firmware without the gl ui, but with baked configuration to advance my network even more, and on the master branch directly 
, for me it is purely because my configuration becomes too conflicting, though with the upcomming vlan changes I might consider to try it, it becomes less restrictive to have vpn policies on other interfaces within their vpn software which is good.
Yep, that’s why I was thinking of doing some tutorials on the more technical items. I’ve picked up the firmware still has some CVE’s that still need to be patched so I avoid enabling those services publicly.
I am Making use of scanning tools like shodan.io and Ghost ESP to identify security concerns and attempt to mitigate and share them with Glinet aswell.
I am a certified web app pentester and expanding into IoT Pen testing.
if you guys are interested, I can start posting those things here, or perhaps on the discord channel.
“However from my own experience I know that GL-iNet at least tries to listen, some other vendors with closed firmware pretty much neglect their routers”
That's a very good point, I’m heartened that the vendor is engaged, this forum is an example of that. I trust gl.inet more than many other vendors. It's quite possible the problem is more me tbh. A quote from a book I read earlier today that feels maybe appropriate for my outlook:
“You’re overthinking it”…” I have anxiety. I have no other type of thinking available.” Matt Haig, The Midnight Library.
This is kind of true also, it sounds conflicting and very unsecure to say.
But alot of those exploits still does not make the router vulnerable to a extend a remote attack via wan can do something with it.
Alot can be local based exploits, I don't say they are not dangerous, no.
But they can become dangerous if a local device has a compromise, or a docker instance/third party package is being malicious.
But if those custom setups are not used in this extend and there are no local devices compromised the severity is still lower, but I still agree it needs to be patched anyway there is no excuse to do not.
But I do have seen a bunch of vulnerabilities like those with dnsmasq which also can be remotely used, then yes the severity is alot more higher.
P.S I won't use docker on OpenWrt simply because it uses a stripped down version of busybox, likely you miss also some form of process user isolation, there are users or groups in /etc/shadow but I won't trust docker in a OpenWrt instance, I rather use a Debian VM with docker 
Isn't this true of most router companies? They all use an old build of Linux. I haven't seen any evidence that GL.iNet routers are unsecured. That said, I haven't tried enabling other features like Tailscale in the firmware. I feel like less is more when it comes to routers, so hopefully less surface area for potential bad actors to infiltrate.
Yes to my own experience it is true, maybe even a little worse.
I have seen some isp equipment people trying to get OpenWrt on it, and it had a base version of OpenWrt 12 (Attitude Adjustment) with kernel version 3, it is kind of shocking lol...
But I also have seen it with cheap chinese router brands too.
You need to question the company if you can believe them they actually backport security fixes on such low kernel, I could easily say to stay away from them, GL-iNet still seem to do more effort than those companies
So there’s still a CVE on the web server if remote access on the WAN side is enabled on 433. Can’t remember it offhand but picked it up via shodan. I need to check if it’s still there with the 4.9.0 update.
it does highlight the need to be more vigilant so attacks can come from the WAN side
This is for me one reason to segment all my portforwards over wireguard
This way their port scan attemps appear closed for them and even then they need a way to get into the tunnel before they can access these services
Why would you configure the external web server (port 443, I am sure you just had a typo)? As stated, best to enable something to get to the interface on an internal port / vpn endpoint than to enable web access publicly. That said, it would be nice if they could clean that up if it still exists in current firmware revisions.