Merlin FW: Quick Tutorial to Lock-Down (Secure) the Router

[Logi]

I have an RT-AC5300 with the Merlin 380.58 Firmware, please could you share the best practices or quick guide on how to secure the router, maybe the default parameters are OK but I am not sure, thanks

 

[DrPozo]

Be sure to check the default policies of the iptables chains. I am uncomfortable to see that ASUS configured some firewall chains with a default policy of ACCEPT, instead of DROP. I think each firewall chain should always target DROP. So when you restart the firewall it don't leak. However, my skills are low and I could be wrong. What does a pfSense firewall look like?

 

[Logi]

Be sure to check the default policies of the iptables chains. I am uncomfortable to see that ASUS configured some firewall chains with a default policy of ACCEPT, instead of DROP. I think each firewall chain should always target DROP. So when you restart the firewall it don't leak. However, my skills are low and I could be wrong. What does a pfSense firewall look like?

Do you mean to install an additional appliance like the pfSense SG-2220?

 

[DrPozo]

I don't own a pfSense yet. I'm just saying that when you restart an ASUS firewall, there's a window of opportunity where something can go wrong, you're away from home, and now your front door is left wide open.

 

[Logi]

I don't own a pfSense yet. I'm just saying that when you restart an ASUS firewall, there's a window of opportunity where something can go wrong, you're away from home, and now your front door is left wide open.

Got it, where should I check in the web interface for "Be sure to check the default policies of the iptables chains."? Thanks

 

[DrPozo]

As I said before, I could be wrong because my firewall knowledge is low. However, this is what I see:

# iptables -L -v -n|grep policy

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
Chain FORWARD (policy DROP 0 packets, 0 bytes)
Chain OUTPUT (policy ACCEPT 651K packets, 1878M bytes)

# iptables -t nat -L -v -n|grep policy

Chain PREROUTING (policy ACCEPT 2943 packets, 198K bytes)
Chain INPUT (policy ACCEPT 1673 packets, 128K bytes)
Chain OUTPUT (policy ACCEPT 4173 packets, 260K bytes)
Chain POSTROUTING (policy ACCEPT 4440 packets, 290K bytes)

# iptables -t mangle -L -v -n|grep policy

Chain PREROUTING (policy ACCEPT 6369K packets, 5459M bytes)
Chain INPUT (policy ACCEPT 2733K packets, 2012M bytes)
Chain FORWARD (policy ACCEPT 3678K packets, 3453M bytes)
Chain OUTPUT (policy ACCEPT 1544K packets, 2169M bytes)
Chain POSTROUTING (policy ACCEPT 5210K packets, 5622M bytes)

 

[RMerlin]

Having default policies of ACCEPT in nat and mangle chains is normal. These are not meant for filtering, they are meant for packet processing. Any packet that does not need to be processed (i.e. doesn't require being NATed or marked) has to be left through the rest of the iptable chain, hence the ACCEPT policy. Ultimate filtering has to be done strictly on the filter table.

OUTPUT is set to ACCEPT because the router does no filtering of outbound traffic (so that chain is completely empty).

The INPUT chain does have a default policy of ACCEPT, however it's last rule is a DROP from ALL to ALL. Don't know why it was originally designed that way (it goes back to either Asuswrt's Tomato origins, or something Asus changed after they forked from Tomato back in 2011 - I don't know). Therefore, that chain is also safe.

 

[RMerlin]

I have an RT-AC5300 with the Merlin 380.58 Firmware, please could you share the best practices or quick guide on how to secure the router, maybe the default parameters are OK but I am not sure, thanks

Depends on your specific needs. First rule is to disable anything you don't need. By default, most of these are already disabled in Asuswrt, except for UPNP that defaults to enabled - you might want to disable it if you're sure you don't need UPNP on your LAN. Check under USB -> Media servers and disable services you don't need if you have a USB disk plugged in.

Switching the webui to https might be a good idea, however if you trust your own LAN it might not be that critical (considering it will have a performance impact on the webui itself).

For wifi, the usual applies: disable WPS, use a strong WPA2 passphrase, setup a separate Guest network if you occasionally need to share Wifi access with visitors.

 

[Logi]

Depends on your specific needs. First rule is to disable anything you don't need. By default, most of these are already disabled in Asuswrt, except for UPNP that defaults to enabled - you might want to disable it if you're sure you don't need UPNP on your LAN. Check under USB -> Media servers and disable services you don't need if you have a USB disk plugged in.

Switching the webui to https might be a good idea, however if you trust your own LAN it might not be that critical (considering it will have a performance impact on the webui itself).

For wifi, the usual applies: disable WPS, use a strong WPA2 passphrase, setup a separate Guest network if you occasionally need to share Wifi access with visitors.

Thanks a lot for the suggestions. My current settings are:

UPNP = OFF
Media Servers (USB) = OFF
WebUI = HTTPS
WPS = OFF
Wifi = WPA2- Personal (very strong password)
WPA Encryption = AES
Hide SSID = YES
Guest Network = OFF
WAN Access (SSH/WebUI) = OFF
Router Security Assessment = ALL GREEN
AirCloud = ALL OFF
VPN = OFF
Enable SSH = YES
Allow only specified IP address WEBUI = Yes (only my computer)

Should I change Enable SSH Brute Force Protection to YES?

 

[RMerlin]

Thanks a lot for the suggestions. My current settings are:

UPNP = OFF
Media Servers (USB) = OFF
WebUI = HTTPS
WPS = OFF
Wifi = WPA2- Personal (very strong password)
WPA Encryption = AES
Hide SSID = YES
Guest Network = OFF
WAN Access (SSH/WebUI) = OFF
Router Security Assessment = ALL GREEN
AirCloud = ALL OFF
VPN = OFF
Enable SSH = YES
Allow only specified IP address WEBUI = Yes (only my computer)

Should I change Enable SSH Brute Force Protection to YES?

Re-enable "Hide SSID". It doesn't provide any security (your router still broadcasts itself, only with an empty SSID name), and it also creates problems with some clients.

Enabling SSH brute force protection is a good idea, even if SSH is only available over LAN, in case you get a compromised computer which tries to brute force their way through your router's SSH.

 

[Logi]

Re-enable "Hide SSID". It doesn't provide any security (your router still broadcasts itself, only with an empty SSID name), and it also creates problems with some clients.

Enabling SSH brute force protection is a good idea, even if SSH is only available over LAN, in case you get a compromised computer which tries to brute force their way through your router's SSH.

Currently I have around 30-40 network clients, between Webcams, Apple devices, Microsoft Devices, Printers, Wireless Repeaters and all of them are working fine with the Hide SSID, I like the idea of not making public the Wifi name

 

[pete y testing]

and all of them are working fine with the Hide SSID, I like the idea of not making public the Wifi name

however it provides no level of security at all and is of no benefit so in real terms pointless

see

The six dumbest ways to secure a wireless LAN
http://www.zdnet.com/article/the-six-dumbest-ways-to-secure-a-wireless-lan/

this blog has been around for years and yet ppl continue to go on in the belief that hiding ssid is of any benefit at all and ppl continue to pass this idea around as a good thing to do , go figure

and i will quote

SSID hiding: There is no such thing as "SSID hiding". You're only hiding SSID beaconing on the Access Point. There are 4 other mechanisms that also broadcast the SSID over the 2.4 or 5 GHz spectrum. The 4 mechanisms are; probe requests, probe responses, association requests, and re-association requests. Essentially, youre talking about hiding 1 of 5 SSID broadcast mechanisms. Nothing is hidden and all youve achieved is cause problems for Wi-Fi roaming when a client jumps from AP to AP. Hidden SSIDs also makes wireless LANs less user friendly. You dont need to take my word for it. Just ask Robert Moskowitz who is the Senior Technical Director of ICSA Labs in his white paper Debunking the myth of SSID hiding.

and just for good measure

MAC filtering: This is like handing a security guard a pad of paper with a list of names. Then when someone comes up to the door and wants entry, the security guard looks at the person's name tag and compares it to his list of names and determines whether to open the door or not. Do you see a problem here? All someone needs to do is watch an authorized person go in and forge a name tag with that person's name. The comparison to a wireless LAN here is that the name tag is the MAC address. The MAC address is just a 12 digit long HEX number that can be viewed in clear text with a sniffer. A sniffer to a hacker is like a hammer to a carpenter except the sniffer is free. Once the MAC address is seen in the clear, it takes about 10 seconds to cut-paste a legitimate MAC address in to the wireless Ethernet adapter settings and the whole scheme is defeated. MAC filtering is absolutely worthless since it is one of the easiest schemes to attack. The shocking thing is that so many large organizations still waste the time to implement these things. The bottom line is, MAC filtering takes the most effort to manage with zero ROI (return on investment) in terms of security gain.

 

[RMerlin]

Currently I have around 30-40 network clients, between Webcams, Apple devices, Microsoft Devices, Printers, Wireless Repeaters and all of them are working fine with the Hide SSID, I like the idea of not making public the Wifi name

Do a speed benchmark with and without hiding SSID. For some obscure reason, hiding the SSID had a negative impact on wireless throughput according to some users that tested it a few months ago. I think even the RSSI value would fluctuate a lot more with an hidden SSID than when displaying it.

Also back in the WinXP days, a laptop that was configured to connect to a hidden SSID would start broadcasting that SSID whenever trying to determine if the SSID in question was available, which totally defeated the purpose of hiding one's SSID. (even worse - that SSID was being broadcast even while NOT within range of your network). While Microsoft fixed this in Vista, I do not know if other clients have been known of doing the same thing. So, just something else to keep in mind, just in case it might still apply.

 

[Logi]

Do a speed benchmark with and without hiding SSID. For some obscure reason, hiding the SSID had a negative impact on wireless throughput according to some users that tested it a few months ago. I think even the RSSI value would fluctuate a lot more with an hidden SSID than when displaying it.

Also back in the WinXP days, a laptop that was configured to connect to a hidden SSID would start broadcasting that SSID whenever trying to determine if the SSID in question was available, which totally defeated the purpose of hiding one's SSID. (even worse - that SSID was being broadcast even while NOT within range of your network). While Microsoft fixed this in Vista, I do not know if other clients have been known of doing the same thing. So, just something else to keep in mind, just in case it might still apply.

Make sense, I will disable that option, thanks

 

[RMerlin]

Make sense, I will disable that option, thanks

If privacy was your primary concern, I could recommend using a more "anonymous" SSID. For instance, "mywifi" instead of "johnswifi".

 

[Cake]

May I suggest "_mywifi_nomap".