Remote access RT-3200 ?

[rirusssma]

What setting do I change to REMOTE access the router?

Thanks

 

[pete y testing]

What setting do I change to REMOTE access the router?

Thanks

a 2 second google gives me this

https://www.asus.com/support/faq/1000926/

is that what you are after ?

 

[L&LD]

But a better method is to use a VPN back to your network instead.

 

[sfx2000]

But a better method is to use a VPN back to your network instead.

Concur - if anything, that might be a good reason for VPN (and there are knock-on benefits)

Exposing an Admin interface to the WAN side - these days - not recommended in the slightest - there's been too many security issues found across different Router/AP's, and the speed to fix is too long as well... if a fix is even pending at that...

 

[rirusssma]

Thank you guys, this has been really helpful for us. Regards.

 

[Trentors]

Concur - if anything, that might be a good reason for VPN (and there are knock-on benefits)

Exposing an Admin interface to the WAN side - these days - not recommended in the slightest - there's been too many security issues found across different Router/AP's, and the speed to fix is too long as well... if a fix is even pending at that...

Well that may be true but in the enterprise world it is all about cloud controlling devices - which is essentially the same thing. Cisco Meraki, Ubiquiti Unifi etc. is all about exposing the devices on the WAN to a central cloud administration. Taken into account how security always is top priority in this field, it seems strange that they would build their entire products up on this – if it is indeed so insecure?


As long these devices can be accessed and/or controlled by a cloud service they are all basically just as exposed as an Asus router with WAN administrator access (with https). Maybe even more since they do not have an open source community that contributes with security fixes as usually seen in firmware updates from Asus.

 

[sfx2000]

As long these devices can be accessed and/or controlled by a cloud service they are all basically just as exposed as an Asus router with WAN administrator access (with https). Maybe even more since they do not have an open source community that contributes with security fixes as usually seen in firmware updates from Asus.

Yes and no...

When we look at Cloud Architectures like OpenStack, security is built in with regards to levels of trust extended inside and outside... trust me, this is stuff I do these days - working on OpenStack development in a large scale environment with many partner networks - so security is an absolute must... it cannot be patched in after the fact.

The challenge with the "big honking routers" such as what Asus, Netgear, Linksys, DLink, etc. in the consumer market is that most are actually built off a platform that has it's genesis in a GPL drop from Linksys back in the WRT54G days.

Within that drop - functionality is there - but everything basically runs as root - the web server, the various configuration scripts, add-on daemons like Samba and OpenVPN, along with uPNP and miniDLNA (and others, but these are typical). The HTTP and uPNP interfaces are common and easily exploited targets, and since there is no privilege separation, once that interface is broken, one basically has root and owns the box...

So when exposing "big honking routers" to the public internet - it is unwise at best, and foolhardy to expose interfaces without a true understanding of the risks involved.

These days - consumer routers are a primary target for many security focused groups - the blackhats looking for openings to exploit and further their objectives, and the white hats that do research and try to find the holes before the blackhat's do..

The "cloud" oriented consumer vendors need to be wary of this, as they can become a very large target, and exploits there have massive leverage if they're cracked open.

Hence my recommendation - only open up threat surfaces as a necessity, e.g. a must-have need, and consider if this is just a "want" because it's nice to have... esp. on the gateway itself - forwarding ports, then the concern is the security and stability of that application, but one must consider the Gateway as something to protect, esp. since the basic architecture is fairly insecure in the first place...

Just my thoughts...

 

[Trentors]

Yes and no...

When we look at Cloud Architectures like OpenStack, security is built in with regards to levels of trust extended inside and outside... trust me, this is stuff I do these days - working on OpenStack development in a large scale environment with many partner networks - so security is an absolute must... it cannot be patched in after the fact.

The challenge with the "big honking routers" such as what Asus, Netgear, Linksys, DLink, etc. in the consumer market is that most are actually built off a platform that has it's genesis in a GPL drop from Linksys back in the WRT54G days.

Within that drop - functionality is there - but everything basically runs as root - the web server, the various configuration scripts, add-on daemons like Samba and OpenVPN, along with uPNP and miniDLNA (and others, but these are typical). The HTTP and uPNP interfaces are common and easily exploited targets, and since there is no privilege separation, once that interface is broken, one basically has root and owns the box...

So when exposing "big honking routers" to the public internet - it is unwise at best, and foolhardy to expose interfaces without a true understanding of the risks involved.

These days - consumer routers are a primary target for many security focused groups - the blackhats looking for openings to exploit and further their objectives, and the white hats that do research and try to find the holes before the blackhat's do..

The "cloud" oriented consumer vendors need to be wary of this, as they can become a very large target, and exploits there have massive leverage if they're cracked open.

Hence my recommendation - only open up threat surfaces as a necessity, e.g. a must-have need, and consider if this is just a "want" because it's nice to have... esp. on the gateway itself - forwarding ports, then the concern is the security and stability of that application, but one must consider the Gateway as something to protect, esp. since the basic architecture is fairly insecure in the first place...

Just my thoughts...

I see your point. It is a good security policy to prevent root access everywhere but even this does not make things secure without patching. Take Android as an example. I principle it is also encapsulated by not allowing root access to apps but still something like "Stagefright" could happen because it was not persistently implemented. Such thing happens and patching is the only solution.


Other OS like Ubiquiti and MikroTik use has also been hacked in the past because of unpatched devices. And Ubiquiti is exposing their Unifi range to the cloud by default if users are deploying Cloud Keys (or using cloud hosted controllers).


Anyway I think you are right in the user needs to understand the risk and if the WAN administration is exposed then at least change the default port and use https. And always think security first and only use features that are needed.


I believe that features like AIProtection (and Synology’s Security advisor) are good tools to help ordinary uses be aware of the risks they are exposing the devices to.